我做过不少项目也踩过不少坑。这几年最大的体会是一个项目到最后能不能顺利交付早在开工前几周就已经注定了。原因很简单需求没想清楚的时候后面写的每一行代码都可能是在给错误的方向添砖加瓦。这次想和你认真聊一个系列从需求分析到测试报告完整走一遍“先想清楚、再动手做”的流程。项目背景是一个小型电商购物系统既包含了商品浏览、购物车、下单、支付、订单管理这些典型业务也加入一条贯穿始终的副线——用AI自动生成测试用例把需求文本直接变成可执行的测试计划。为什么选这个组合因为电商系统的业务规则足够典型而AI辅助测试又是目前落地价值最高的场景之一。这一篇是开篇定位非常明确搞定需求分析与技术选型这两件事。如果你正准备开始一个新项目或者正卡在“业务说不清楚、技术定不下来”的状态里这一篇能帮你在动工前把地基打牢。1. 需求分析开工前最值得花时间的一件事1.1 需求分析不是“问别人想要什么”很多人一听到“需求分析”第一反应就是“找业务方聊一聊记下他们要什么”。如果只是这样那叫开会不叫需求分析。真正的需求分析是把一个模糊的愿望变成一组明确、可验证、能指导开发的规格说明。它要回答的不只是“做什么”更重要的是“做到什么程度算完成”“哪些边界情况要处理”“业务规则到底是什么”。拿电商购物系统最普通的一个功能来说用户想“下单”。这句话听起来很简单但仔细拆一下全是问题下单时库存不足怎么办是拦截订单还是允许预下单支付超时未支付订单应该在什么状态多少分钟之后自动取消收货地址怎么校验省市区是选列表还是允许手填优惠和库存的扣减顺序是什么先锁库存还是先算价格并发叠加时会不会超卖取消订单之后已经支付的金额怎么退回这些内容如果不在需求分析阶段定清楚开发阶段就会变成“开发同学猜着做”测试阶段变成“测试同学想着测”最后上线出现各种逻辑漏洞再回头改一堆代码。我的经验是需求分析阶段每多花1小时后期开发和测试至少能省出3小时。这个账怎么算都划算。1.2 用三种语言描述同一个需求需求分析里最容易犯的错就是只写一种描述方式。要么全是大白话开发看不懂边界要么全是术语业务听不懂要么全是功能清单验收时不知道什么叫“做完”。我常用的做法是同一个需求用三种语言来表达用户故事说清楚“为谁做、要什么、为什么”让团队理解需求背后的动机。用例描述说清楚“主流程怎么走、异常情况怎么处理”让开发知道代码要覆盖哪些路径。验收标准说清楚“满足什么条件才算通过”让测试有据可依。以一电商系统里“用户提交订单”这个典型需求为例三种表达分别是这样用户故事“作为一个已登录用户我希望把购物车中的商品生成订单这样我能统一完成支付。”用例描述用户从购物车选中商品点击“去结算”进入确认页系统展示商品清单、金额、收货地址用户提交订单系统校验库存、生成订单号、把订单状态置为“待支付”用户完成支付后状态变为“已支付”。异常情况包括库存不足时提示具体哪件商品无货本次下单失败订单生成后超过30分钟未支付系统自动取消并释放库存。验收标准Given 我已登录且购物车中有库存正常的商品When 我提交订单Then 系统生成状态为“待支付”的订单并展示正确订单金额和订单号Given 某商品库存仅剩1件且同时有2个用户提交订单When 两人同时下单Then 只有一个用户能成功下单另一个用户收到明确的库存不足提示Given 待支付订单超过30分钟When 系统定时任务扫描超时订单Then 订单状态变为“已取消”库存回补。你看同一条需求用三种方式描述之后团队里每个人都能找到自己需要的信息。业务方确认用户故事和关键规则开发照着用例和验收标准写逻辑测试直接把验收标准转成测试用例。这条链路从需求阶段就已经为后面的测试铺路了。1.3 画E-R图之前先梳理清楚实体关系很多初学做需求分析的人一上来就画E-R图甚至直接建表。这是本末倒置了。E-R图的输入是业务概念不是数据库字段。你得先想清楚业务里有哪些关键实体它们之间是什么关系然后才谈得上怎么画图、怎么建表。对于电商购物系统来说核心实体我梳理出六类用户系统的使用者有账号、昵称、收货地址等属性。商品平台售卖的内容物有标题、价格、库存、分类等属性。购物车项用户和商品之间的临时关系一条记录代表“某个用户把某个商品加进了购物车”。订单用户一次购买的凭证有订单号、总金额、状态、下单时间等属性。订单项订单里的具体商品快照因为下单后商品可能改价或者改名所以必须把下单时的信息固化下来。支付记录订单的支付凭证关联到具体订单有支付金额、支付方式、支付时间、流水号等属性。实体之间的关系是这样用户和订单是一对多一个用户可以有多个订单订单和订单项是一对多一个订单包含多个商品条目订单项和商品是多对一多个订单项可能指向同一个商品用户和购物车项是一对多购物车项和商品是多对一订单和支付记录是一对一一笔订单对应一条主支付记录。这些关系确定之后后续建表的大方向就已经清楚了。E-R图在这里的作用是让需求和开发双方确认“业务模型就是这样的别等到代码写了一半才发现少了一张表或者两张表之间的关系从一开始就搞错了。”我建议你在需求分析阶段就画一张粗糙但完整的E-R图不用纠结风格用draw.io或ProcessOn随手拖一下就行。关键不是画得好看而是把实体、属性和关系讨论清楚。这个阶段的E-R图会被后续的开发计划、数据库设计、测试数据构造反复使用值得多花一点心思。2. 技术选型不是选最火的而是选最匹配的2.1 选型前先列约束条件技术选型是个很有意思的环节。新人容易犯的毛病是“什么火选什么”老手则容易犯“什么熟选什么”。这两者都不够好。技术选型的正确打开方式是先列约束条件再逐一套到候选方案上筛。约束条件从哪里来从需求分析的结果来。我把这次电商系统的约束条件理了一下第一项目规模和团队投入是可控的。这不是一个几十人团队的大型分布式系统而是一个要能够快速开发、快速演示、结构清晰的单体应用。我需要尽量控制复杂度不要一上来就搞微服务、消息队列、分布式事务这些都是在小项目里给自己挖坑。第二业务场景有清晰的并发和一致性要求。电商核心链路是“下单扣库存”必须保证数据一致性不能超卖支付状态要准确。这些决定了数据库必须选用事务支持成熟的关系型数据库而不是为了图方便用文件存储或者非关系型数据库扛主业务。第三测试自动化是刚需。这个系列的主线是“从需求分析到测试报告”意味着测试不能等开发完成之后才补而要从技术选型阶段就考虑测试的便利性。API设计规范、接口文档、测试框架的成熟度都直接影响AI生成测试用例的落地难度。第四AI能力的接入要顺滑。我们要做“AI自动生成测试用例”技术栈里必须给大模型API留好位置并且让需求文档、接口定义、代码结构都能被程序化读取和处理。2.2 技术栈逐项对比在这些约束条件下每个关键决策点都值得做一次小范围的对比。我把这次选型过程中几个主要对比拉出来讲一下也方便你以后自己选型时参考。前端框架候选Vue和React。Vue在国内的中小型项目里生态更顺手Element Plus这样的组件库对后台管理系统式的界面支持很好上手成本低React生态更庞大但对我们这种以业务表单、列表、流程为主的项目Vue的模板写法效率更高。最后选了Vue 3搭配Vite开发体验和构建速度都满意。后端框架候选FastAPI和Spring Boot。Spring Boot在企业项目里地位牢靠但Java本身的开发效率对我这个体量的项目来说还是偏重FastAPI是Python系天然支持Pydantic数据校验能自动生成OpenAPI文档这一点对后续让AI读取接口定义、生成接口测试用例是巨大的优势所以最终选了FastAPI。这个决策的关键不在谁的性能更强而在谁更适合当前约束。数据库候选MySQL和PostgreSQL。两者都是关系型数据库王者MySQL生态在国内普及度无可挑剔PostgreSQL在扩展功能和性能细节上略胜一筹。这次项目里数据一致性、事务支持和部署便利是核心MySQL的运维资料和云服务支持更好所以选了MySQL。如果你个人更熟PostgreSQL也没问题别在这个层面纠结太久。接口风格果断选RESTful配合OpenAPI文档。原因很简单AI生成测试用例需要一个机器可读的接口契约OpenAPI就是事实标准。把接口文档生成好后端的接口测试用例就能自动生成很大一部分。测试框架后端用Pytest前端配合Vue Test Utils再加上Playwright做端到端测试。这套组合是目前Web项目测试方案里性价比最高的后续在测试报告章节会详细展开。下面这个表格是选型过程的速览选型项候选方案最终选择核心决策理由前端框架Vue 3 / ReactVue 3 Vite Element Plus开发效率高中后台生态好模板写法直观后端框架FastAPI / Spring BootFastAPI自动生成OpenAPI文档对AI读取接口极友好数据库MySQL / PostgreSQLMySQL 8事务成熟、运维资料多、部署稳定接口风格RESTful / GraphQLRESTful OpenAPI契约清晰便于自动化测试和AI解析测试框架Pytest / JUnit / PlaywrightPytest Playwright前后端覆盖均衡生态完善适合生成用例大模型接入OpenAI API / 本地模型大模型API生成测试用例需要较强的文本理解和结构化输出能力2.3 把“AI自动生成测试用例”写成技术需求现在聊这个系列最有意思的部分AI如何从第一天就参与进来很多人把AI辅助测试理解成“写完代码之后把代码丢给AI让它帮忙写测试”但我的思路不太一样。我想在需求分析阶段就定好一套规范让AI直接从需求文本生成测试用例。传统测试用例是测试工程师看需求文档提炼场景再逐个手写。这个过程有两个痛点一是需求文档写得不够结构化提炼过程靠个人经验产出因人而异二是回归场景多手工维护用例成本高。AI的介入方式是让需求文档变成机器可读的结构化输入然后大模型负责把它翻译成覆盖主流程和异常路径的用例草稿测试人员再做评审和补漏。这个思路拆开来本质上变成一条自动化的流水线需求文档 → 需求结构化抽取 → 测试场景生成 → 测试用例生成 → 测试数据建议。我计划在后续章节实现的核心功能就是这样一个流水线输入是需求文档输出是一份可直接导入测试管理系统的用例集。这也解释了为什么后端必须选FastAPI而不是别的——OpenAPI文档给AI提供了一个干净的接口契约。AI能知道后端有哪些接口、每个接口的入参出参、字段格式和校验规则再结合需求文档里的业务规则生成接口级用例就变得很自然。选型这件事和业务目标是一个整体不能拆开单独看。3. 把需求拆成能落地的开发计划3.1 需求优先级划分需求清单摆在那里不代表所有功能都要一次做完。我给这个电商系统划分优先级时用了经典的MoSCoW法Must have不做不行用户注册登录、商品列表和详情、购物车、下单、订单管理、支付状态回调。Should have应该做尽量做商品分类筛选、订单取消与退款流程、库存超卖防护。Could have有余力再做商品评价、用户积分、推荐列表。Wont have这一版本不做多商户、秒杀活动、复杂的营销系统。这套优先级直接决定了后续的开发节奏。第一批只做Must have保证一个最小可用闭环能跑通Should have放在第二个迭代Could have看时间Wont have明确砍掉或者进下一版。很多人不敢砍需求总怕少做个功能影响完整性。但事实是一个功能边界清楚、规则明确的最小系统比一个功能多但处处都是半成品的系统体验好得多。测试也一样需求少而明确测试才能做得深。3.2 阶段、交付物与验收标准需求定完了技术选型定完了接下来就是排阶段、定交付物。我做项目习惯明确每个阶段“进来的是什么、出去的是什么”否则很容易干着干着就乱了。这次项目的阶段划分和交付物如下阶段核心输入核心输出验收标准需求分析项目目标、业务规则需求文档、E-R图每个需求有用户故事、用例、验收标准技术选型需求文档、约束条件技术栈清单、架构草图每个选型点有对比理由能对应到需求原型设计需求文档页面原型、接口草案核心流程走通所有页面有明确入口前端开发原型、接口草案前端代码页面功能与原型一致联调通过后端开发需求文档、E-R图后端代码、API文档接口契约与OpenAPI一致数据规则全部实现测试执行需求文档、OpenAPI测试用例、测试报告AI生成的用例评审通过缺陷收敛复盘交付全部产物总结文档、后续计划项目目标逐项对照输出经验结论这个系列文章会跟着这些阶段走下来。今天这一篇是“01 开篇”后面会有原型设计、后端实现、AI用例生成、测试报告等内容。每个阶段我都会把当时的思考过程、关键操作和踩坑记录写出来而不只是放一个漂亮的成品。3.3 测试用例前置需求阶段就开始写测试思路最后这一点是我特别想强调的。传统流程里测试是开发完成之后才开始的需求阶段的产物和测试完全脱节。这次我打算把测试用例的思路前置到需求阶段让测试人员或者说测试视角从第一天就参与。具体做法是需求文档里每个用户故事、每个用例、每条验收标准都必须能映射到未来的测试用例上。验收标准我直接采用Given/When/Then的格式写它本身就是可执行的测试场景。这样到后面做AI生成时输入数据的质量是天然有保证的。举个AI生成用例的例子。假设需求文档里有这样一段描述“用户提交订单后如果超过30分钟未支付系统自动将订单状态修改为已取消并释放该订单占用的库存数量。”给AI的指令设计大致是这样请根据以下需求描述生成测试用例 需求待支付订单超时自动取消并回补库存。 要求 1. 覆盖正常场景、边界场景和异常场景 2. 每条用例包含前置条件、操作步骤、预期结果 3. 关注库存回补的数据一致性。把这段输入给大模型它很容易就能给出“下单未支付等待31分钟后订单取消且库存回补”“两个订单争抢同一件商品库存一个超时取消后另一个用户能成功购买”“支付成功瞬间触发超时扫描订单不能被错误取消”这类场景。这些用例可能不会100%完美但可以作为很好的草稿测试人员在此基础上修改补充速度快很多。这个流程的关键点在需求文本的规范性。需求本身写得混乱AI再强也生成不出好用例。所以我在需求阶段特别强调结构化这个投入会在后面的测试报告阶段获得回报。4. 避坑实录需求分析与选型阶段的教训4.1 别把需求文档写成散文我见过很多项目需求文档写得像产品博客大段大段的文字描述看下来感觉功能很丰富可是一到开发就开始吵“这个按钮文案算需求吗”“这个报错提示要后端返回还是前端写死”“库存是下单时扣还是支付时扣”问题全问在细节上而文档里一个都没写清楚。我的改进办法是给需求文档立规矩能并列就列表能结构化就结构化能表格就表格所有规则必须写到“数字级别”。比如“30分钟未支付自动取消”就是明确规则比“超时未支付订单会被取消”强一百倍。结构化文本是后续AI可以处理的输入这也是做AI辅助测试的前提条件。4.2 追新技术的代价技术选型阶段我一度被某个新兴的数据库吸引它宣称性能极强、语法兼容MySQL还在社区里火了一阵。但是等我去查资料时发现它的运维文档少、云上支持不完善、遇到性能问题时的排查经验基本找不到。对于一个需要稳定交付的项目这东西就是个坑。后来我放弃了所有“看起来很厉害但自己没法驾驭三年内演进方向”的技术。我的判断标准就三条团队能不能上手踩坑时搜不搜得到答案生态里有没有同类的大规模案例。三个条件有一个不满足就不选。别把项目当作新技术的试验田试验田的成本往往比想象中高得多。4.3 别等开发完再想测试还有一个教训来自我以前的习惯先把功能跑起来再补测试。结果呢大量时间花在本不需要存在的手工回归上测试用例写出来的时候需求已经变了好几轮用例成了废纸。这次项目把测试前置之后最大的变化是需求里的每一个“Given/When/Then”都有专人盯着每一个关键规则从一开始就设计好了测试场景。到后面AI生成用例时这些前置设计直接成了高质量的种子数据。测试不是一个里程碑不是一种收尾动作而是从需求分析开始就要考虑的一整条链路。你越早把它纳入技术选型和技术规划后期就越省力。4.4 一个可复用的开篇检查清单如果你也要开始一个类似的项目这里有一份可以直接抄的开篇检查清单走完一遍再动手写代码需求清单所有核心功能是否都拆到了用户故事、用例、验收标准三层数据模型E-R图是否画了实体关系是否经过至少两个人确认约束条件项目的时间、人员、运维、性能约束分别是什么选型对比每个关键技术选型是否有至少两个候选方案和一份决策理由测试策略需求文档、接口文档是否能被程序读取AI辅助测试的入口在哪里阶段计划每个阶段的输入、输出、验收标准是否写清楚了这套清单看着朴素但每一条都用血泪换来的。我遇到过太多项目卡住的地方不在代码而在这些基础工作没做扎实。最后分享一点我个人做项目到现在最深的一个体会项目开始那一刻所有人最兴奋的往往是“用什么技术”“怎么写代码”但真正决定成败的是在兴奋之前有没有把“为什么要做、做成什么样、做到什么程度算好”这三件事想清楚。需求分析和技术选型就是回答这三件事的环节也是整个项目里性价比最高的一段时间。接下来的系列文章里我会继续沿着“从需求分析到测试报告”这条线往下走下一篇会讲如何基于这份需求产出原型设计同时开始设计AI生成测试用例的输入规范。如果你正准备做自己的项目不妨在动工之前把这篇里提到的需求模板、选型对比、阶段计划先跑一遍我相信你也会感受到“前期想得越清楚后期做得越轻松”这句话的分量。
需求分析与技术选型怎么做？电商项目实战开篇指南
我做过不少项目也踩过不少坑。这几年最大的体会是一个项目到最后能不能顺利交付早在开工前几周就已经注定了。原因很简单需求没想清楚的时候后面写的每一行代码都可能是在给错误的方向添砖加瓦。这次想和你认真聊一个系列从需求分析到测试报告完整走一遍“先想清楚、再动手做”的流程。项目背景是一个小型电商购物系统既包含了商品浏览、购物车、下单、支付、订单管理这些典型业务也加入一条贯穿始终的副线——用AI自动生成测试用例把需求文本直接变成可执行的测试计划。为什么选这个组合因为电商系统的业务规则足够典型而AI辅助测试又是目前落地价值最高的场景之一。这一篇是开篇定位非常明确搞定需求分析与技术选型这两件事。如果你正准备开始一个新项目或者正卡在“业务说不清楚、技术定不下来”的状态里这一篇能帮你在动工前把地基打牢。1. 需求分析开工前最值得花时间的一件事1.1 需求分析不是“问别人想要什么”很多人一听到“需求分析”第一反应就是“找业务方聊一聊记下他们要什么”。如果只是这样那叫开会不叫需求分析。真正的需求分析是把一个模糊的愿望变成一组明确、可验证、能指导开发的规格说明。它要回答的不只是“做什么”更重要的是“做到什么程度算完成”“哪些边界情况要处理”“业务规则到底是什么”。拿电商购物系统最普通的一个功能来说用户想“下单”。这句话听起来很简单但仔细拆一下全是问题下单时库存不足怎么办是拦截订单还是允许预下单支付超时未支付订单应该在什么状态多少分钟之后自动取消收货地址怎么校验省市区是选列表还是允许手填优惠和库存的扣减顺序是什么先锁库存还是先算价格并发叠加时会不会超卖取消订单之后已经支付的金额怎么退回这些内容如果不在需求分析阶段定清楚开发阶段就会变成“开发同学猜着做”测试阶段变成“测试同学想着测”最后上线出现各种逻辑漏洞再回头改一堆代码。我的经验是需求分析阶段每多花1小时后期开发和测试至少能省出3小时。这个账怎么算都划算。1.2 用三种语言描述同一个需求需求分析里最容易犯的错就是只写一种描述方式。要么全是大白话开发看不懂边界要么全是术语业务听不懂要么全是功能清单验收时不知道什么叫“做完”。我常用的做法是同一个需求用三种语言来表达用户故事说清楚“为谁做、要什么、为什么”让团队理解需求背后的动机。用例描述说清楚“主流程怎么走、异常情况怎么处理”让开发知道代码要覆盖哪些路径。验收标准说清楚“满足什么条件才算通过”让测试有据可依。以一电商系统里“用户提交订单”这个典型需求为例三种表达分别是这样用户故事“作为一个已登录用户我希望把购物车中的商品生成订单这样我能统一完成支付。”用例描述用户从购物车选中商品点击“去结算”进入确认页系统展示商品清单、金额、收货地址用户提交订单系统校验库存、生成订单号、把订单状态置为“待支付”用户完成支付后状态变为“已支付”。异常情况包括库存不足时提示具体哪件商品无货本次下单失败订单生成后超过30分钟未支付系统自动取消并释放库存。验收标准Given 我已登录且购物车中有库存正常的商品When 我提交订单Then 系统生成状态为“待支付”的订单并展示正确订单金额和订单号Given 某商品库存仅剩1件且同时有2个用户提交订单When 两人同时下单Then 只有一个用户能成功下单另一个用户收到明确的库存不足提示Given 待支付订单超过30分钟When 系统定时任务扫描超时订单Then 订单状态变为“已取消”库存回补。你看同一条需求用三种方式描述之后团队里每个人都能找到自己需要的信息。业务方确认用户故事和关键规则开发照着用例和验收标准写逻辑测试直接把验收标准转成测试用例。这条链路从需求阶段就已经为后面的测试铺路了。1.3 画E-R图之前先梳理清楚实体关系很多初学做需求分析的人一上来就画E-R图甚至直接建表。这是本末倒置了。E-R图的输入是业务概念不是数据库字段。你得先想清楚业务里有哪些关键实体它们之间是什么关系然后才谈得上怎么画图、怎么建表。对于电商购物系统来说核心实体我梳理出六类用户系统的使用者有账号、昵称、收货地址等属性。商品平台售卖的内容物有标题、价格、库存、分类等属性。购物车项用户和商品之间的临时关系一条记录代表“某个用户把某个商品加进了购物车”。订单用户一次购买的凭证有订单号、总金额、状态、下单时间等属性。订单项订单里的具体商品快照因为下单后商品可能改价或者改名所以必须把下单时的信息固化下来。支付记录订单的支付凭证关联到具体订单有支付金额、支付方式、支付时间、流水号等属性。实体之间的关系是这样用户和订单是一对多一个用户可以有多个订单订单和订单项是一对多一个订单包含多个商品条目订单项和商品是多对一多个订单项可能指向同一个商品用户和购物车项是一对多购物车项和商品是多对一订单和支付记录是一对一一笔订单对应一条主支付记录。这些关系确定之后后续建表的大方向就已经清楚了。E-R图在这里的作用是让需求和开发双方确认“业务模型就是这样的别等到代码写了一半才发现少了一张表或者两张表之间的关系从一开始就搞错了。”我建议你在需求分析阶段就画一张粗糙但完整的E-R图不用纠结风格用draw.io或ProcessOn随手拖一下就行。关键不是画得好看而是把实体、属性和关系讨论清楚。这个阶段的E-R图会被后续的开发计划、数据库设计、测试数据构造反复使用值得多花一点心思。2. 技术选型不是选最火的而是选最匹配的2.1 选型前先列约束条件技术选型是个很有意思的环节。新人容易犯的毛病是“什么火选什么”老手则容易犯“什么熟选什么”。这两者都不够好。技术选型的正确打开方式是先列约束条件再逐一套到候选方案上筛。约束条件从哪里来从需求分析的结果来。我把这次电商系统的约束条件理了一下第一项目规模和团队投入是可控的。这不是一个几十人团队的大型分布式系统而是一个要能够快速开发、快速演示、结构清晰的单体应用。我需要尽量控制复杂度不要一上来就搞微服务、消息队列、分布式事务这些都是在小项目里给自己挖坑。第二业务场景有清晰的并发和一致性要求。电商核心链路是“下单扣库存”必须保证数据一致性不能超卖支付状态要准确。这些决定了数据库必须选用事务支持成熟的关系型数据库而不是为了图方便用文件存储或者非关系型数据库扛主业务。第三测试自动化是刚需。这个系列的主线是“从需求分析到测试报告”意味着测试不能等开发完成之后才补而要从技术选型阶段就考虑测试的便利性。API设计规范、接口文档、测试框架的成熟度都直接影响AI生成测试用例的落地难度。第四AI能力的接入要顺滑。我们要做“AI自动生成测试用例”技术栈里必须给大模型API留好位置并且让需求文档、接口定义、代码结构都能被程序化读取和处理。2.2 技术栈逐项对比在这些约束条件下每个关键决策点都值得做一次小范围的对比。我把这次选型过程中几个主要对比拉出来讲一下也方便你以后自己选型时参考。前端框架候选Vue和React。Vue在国内的中小型项目里生态更顺手Element Plus这样的组件库对后台管理系统式的界面支持很好上手成本低React生态更庞大但对我们这种以业务表单、列表、流程为主的项目Vue的模板写法效率更高。最后选了Vue 3搭配Vite开发体验和构建速度都满意。后端框架候选FastAPI和Spring Boot。Spring Boot在企业项目里地位牢靠但Java本身的开发效率对我这个体量的项目来说还是偏重FastAPI是Python系天然支持Pydantic数据校验能自动生成OpenAPI文档这一点对后续让AI读取接口定义、生成接口测试用例是巨大的优势所以最终选了FastAPI。这个决策的关键不在谁的性能更强而在谁更适合当前约束。数据库候选MySQL和PostgreSQL。两者都是关系型数据库王者MySQL生态在国内普及度无可挑剔PostgreSQL在扩展功能和性能细节上略胜一筹。这次项目里数据一致性、事务支持和部署便利是核心MySQL的运维资料和云服务支持更好所以选了MySQL。如果你个人更熟PostgreSQL也没问题别在这个层面纠结太久。接口风格果断选RESTful配合OpenAPI文档。原因很简单AI生成测试用例需要一个机器可读的接口契约OpenAPI就是事实标准。把接口文档生成好后端的接口测试用例就能自动生成很大一部分。测试框架后端用Pytest前端配合Vue Test Utils再加上Playwright做端到端测试。这套组合是目前Web项目测试方案里性价比最高的后续在测试报告章节会详细展开。下面这个表格是选型过程的速览选型项候选方案最终选择核心决策理由前端框架Vue 3 / ReactVue 3 Vite Element Plus开发效率高中后台生态好模板写法直观后端框架FastAPI / Spring BootFastAPI自动生成OpenAPI文档对AI读取接口极友好数据库MySQL / PostgreSQLMySQL 8事务成熟、运维资料多、部署稳定接口风格RESTful / GraphQLRESTful OpenAPI契约清晰便于自动化测试和AI解析测试框架Pytest / JUnit / PlaywrightPytest Playwright前后端覆盖均衡生态完善适合生成用例大模型接入OpenAI API / 本地模型大模型API生成测试用例需要较强的文本理解和结构化输出能力2.3 把“AI自动生成测试用例”写成技术需求现在聊这个系列最有意思的部分AI如何从第一天就参与进来很多人把AI辅助测试理解成“写完代码之后把代码丢给AI让它帮忙写测试”但我的思路不太一样。我想在需求分析阶段就定好一套规范让AI直接从需求文本生成测试用例。传统测试用例是测试工程师看需求文档提炼场景再逐个手写。这个过程有两个痛点一是需求文档写得不够结构化提炼过程靠个人经验产出因人而异二是回归场景多手工维护用例成本高。AI的介入方式是让需求文档变成机器可读的结构化输入然后大模型负责把它翻译成覆盖主流程和异常路径的用例草稿测试人员再做评审和补漏。这个思路拆开来本质上变成一条自动化的流水线需求文档 → 需求结构化抽取 → 测试场景生成 → 测试用例生成 → 测试数据建议。我计划在后续章节实现的核心功能就是这样一个流水线输入是需求文档输出是一份可直接导入测试管理系统的用例集。这也解释了为什么后端必须选FastAPI而不是别的——OpenAPI文档给AI提供了一个干净的接口契约。AI能知道后端有哪些接口、每个接口的入参出参、字段格式和校验规则再结合需求文档里的业务规则生成接口级用例就变得很自然。选型这件事和业务目标是一个整体不能拆开单独看。3. 把需求拆成能落地的开发计划3.1 需求优先级划分需求清单摆在那里不代表所有功能都要一次做完。我给这个电商系统划分优先级时用了经典的MoSCoW法Must have不做不行用户注册登录、商品列表和详情、购物车、下单、订单管理、支付状态回调。Should have应该做尽量做商品分类筛选、订单取消与退款流程、库存超卖防护。Could have有余力再做商品评价、用户积分、推荐列表。Wont have这一版本不做多商户、秒杀活动、复杂的营销系统。这套优先级直接决定了后续的开发节奏。第一批只做Must have保证一个最小可用闭环能跑通Should have放在第二个迭代Could have看时间Wont have明确砍掉或者进下一版。很多人不敢砍需求总怕少做个功能影响完整性。但事实是一个功能边界清楚、规则明确的最小系统比一个功能多但处处都是半成品的系统体验好得多。测试也一样需求少而明确测试才能做得深。3.2 阶段、交付物与验收标准需求定完了技术选型定完了接下来就是排阶段、定交付物。我做项目习惯明确每个阶段“进来的是什么、出去的是什么”否则很容易干着干着就乱了。这次项目的阶段划分和交付物如下阶段核心输入核心输出验收标准需求分析项目目标、业务规则需求文档、E-R图每个需求有用户故事、用例、验收标准技术选型需求文档、约束条件技术栈清单、架构草图每个选型点有对比理由能对应到需求原型设计需求文档页面原型、接口草案核心流程走通所有页面有明确入口前端开发原型、接口草案前端代码页面功能与原型一致联调通过后端开发需求文档、E-R图后端代码、API文档接口契约与OpenAPI一致数据规则全部实现测试执行需求文档、OpenAPI测试用例、测试报告AI生成的用例评审通过缺陷收敛复盘交付全部产物总结文档、后续计划项目目标逐项对照输出经验结论这个系列文章会跟着这些阶段走下来。今天这一篇是“01 开篇”后面会有原型设计、后端实现、AI用例生成、测试报告等内容。每个阶段我都会把当时的思考过程、关键操作和踩坑记录写出来而不只是放一个漂亮的成品。3.3 测试用例前置需求阶段就开始写测试思路最后这一点是我特别想强调的。传统流程里测试是开发完成之后才开始的需求阶段的产物和测试完全脱节。这次我打算把测试用例的思路前置到需求阶段让测试人员或者说测试视角从第一天就参与。具体做法是需求文档里每个用户故事、每个用例、每条验收标准都必须能映射到未来的测试用例上。验收标准我直接采用Given/When/Then的格式写它本身就是可执行的测试场景。这样到后面做AI生成时输入数据的质量是天然有保证的。举个AI生成用例的例子。假设需求文档里有这样一段描述“用户提交订单后如果超过30分钟未支付系统自动将订单状态修改为已取消并释放该订单占用的库存数量。”给AI的指令设计大致是这样请根据以下需求描述生成测试用例 需求待支付订单超时自动取消并回补库存。 要求 1. 覆盖正常场景、边界场景和异常场景 2. 每条用例包含前置条件、操作步骤、预期结果 3. 关注库存回补的数据一致性。把这段输入给大模型它很容易就能给出“下单未支付等待31分钟后订单取消且库存回补”“两个订单争抢同一件商品库存一个超时取消后另一个用户能成功购买”“支付成功瞬间触发超时扫描订单不能被错误取消”这类场景。这些用例可能不会100%完美但可以作为很好的草稿测试人员在此基础上修改补充速度快很多。这个流程的关键点在需求文本的规范性。需求本身写得混乱AI再强也生成不出好用例。所以我在需求阶段特别强调结构化这个投入会在后面的测试报告阶段获得回报。4. 避坑实录需求分析与选型阶段的教训4.1 别把需求文档写成散文我见过很多项目需求文档写得像产品博客大段大段的文字描述看下来感觉功能很丰富可是一到开发就开始吵“这个按钮文案算需求吗”“这个报错提示要后端返回还是前端写死”“库存是下单时扣还是支付时扣”问题全问在细节上而文档里一个都没写清楚。我的改进办法是给需求文档立规矩能并列就列表能结构化就结构化能表格就表格所有规则必须写到“数字级别”。比如“30分钟未支付自动取消”就是明确规则比“超时未支付订单会被取消”强一百倍。结构化文本是后续AI可以处理的输入这也是做AI辅助测试的前提条件。4.2 追新技术的代价技术选型阶段我一度被某个新兴的数据库吸引它宣称性能极强、语法兼容MySQL还在社区里火了一阵。但是等我去查资料时发现它的运维文档少、云上支持不完善、遇到性能问题时的排查经验基本找不到。对于一个需要稳定交付的项目这东西就是个坑。后来我放弃了所有“看起来很厉害但自己没法驾驭三年内演进方向”的技术。我的判断标准就三条团队能不能上手踩坑时搜不搜得到答案生态里有没有同类的大规模案例。三个条件有一个不满足就不选。别把项目当作新技术的试验田试验田的成本往往比想象中高得多。4.3 别等开发完再想测试还有一个教训来自我以前的习惯先把功能跑起来再补测试。结果呢大量时间花在本不需要存在的手工回归上测试用例写出来的时候需求已经变了好几轮用例成了废纸。这次项目把测试前置之后最大的变化是需求里的每一个“Given/When/Then”都有专人盯着每一个关键规则从一开始就设计好了测试场景。到后面AI生成用例时这些前置设计直接成了高质量的种子数据。测试不是一个里程碑不是一种收尾动作而是从需求分析开始就要考虑的一整条链路。你越早把它纳入技术选型和技术规划后期就越省力。4.4 一个可复用的开篇检查清单如果你也要开始一个类似的项目这里有一份可以直接抄的开篇检查清单走完一遍再动手写代码需求清单所有核心功能是否都拆到了用户故事、用例、验收标准三层数据模型E-R图是否画了实体关系是否经过至少两个人确认约束条件项目的时间、人员、运维、性能约束分别是什么选型对比每个关键技术选型是否有至少两个候选方案和一份决策理由测试策略需求文档、接口文档是否能被程序读取AI辅助测试的入口在哪里阶段计划每个阶段的输入、输出、验收标准是否写清楚了这套清单看着朴素但每一条都用血泪换来的。我遇到过太多项目卡住的地方不在代码而在这些基础工作没做扎实。最后分享一点我个人做项目到现在最深的一个体会项目开始那一刻所有人最兴奋的往往是“用什么技术”“怎么写代码”但真正决定成败的是在兴奋之前有没有把“为什么要做、做成什么样、做到什么程度算好”这三件事想清楚。需求分析和技术选型就是回答这三件事的环节也是整个项目里性价比最高的一段时间。接下来的系列文章里我会继续沿着“从需求分析到测试报告”这条线往下走下一篇会讲如何基于这份需求产出原型设计同时开始设计AI生成测试用例的输入规范。如果你正准备做自己的项目不妨在动工之前把这篇里提到的需求模板、选型对比、阶段计划先跑一遍我相信你也会感受到“前期想得越清楚后期做得越轻松”这句话的分量。
