软件测试怎么做需求分析
拿到需求文档第一件事，软件别急着写测试用例。测试我见过太多测试人员打开PRD就开始列功能点，做需结果用例写到一半发现逻辑走不通，求分回头找产品经理对质，软件对方来一句“这里我还没想清楚”。测试三天工作量，做需两天在返工。求分
需求分析不是软件把文档读一遍。它是测试你站在测试角度，把这份需求重新拆解一遍的做需过程。产品经理写的求分是“用户能做什么”，你得想的软件是“用户在什么情况下做不了”。这两种思路的测试差距，就是做需bug藏身的地方。
我习惯先做一轮粗筛：把需求文档里所有涉及状态变化、数据流转、权限控制的段落标出来。这三类地方出错率最高。比如一个订单状态从“待支付”变成“已支付”，中间要经过支付网关回调、库存扣减、优惠券核销。产品文档可能只写了一句“支付成功后更新订单状态”，但你需要追问：回调超时怎么办？库存不够怎么处理？优惠券在支付瞬间被其他订单用掉了呢？
把这些疑问列成清单，直接找产品经理和开发对。别攒着，别等到用例评审才提。我一般会在需求评审会上当场问，哪怕显得啰嗦。有一次我追问一个“用户可随时取消订单”的需求，产品说对，开发说接口不支持部分取消。当场就吵起来了。这种冲突越早暴露越好，等到提测再发现，改代码的成本翻十倍。
问的时候注意方式。别用“这里你没写清楚”这种指责语气，换成“我想确认一下，如果A情况发生，系统应该怎么响应”。把问题包装成场景，对方更容易给出具体答案。我还会顺手记下开发对某些边界条件的口头承诺，比如“这个字段最长不会超过50个字符”，回头写用例时直接引用，开发想赖都赖不掉。
需求分析的另一半工作是画流程图。不是给领导看的那种，是自己用的。把主流程、异常流程、分支流程用不同颜色标出来。我常用纸笔画，画完拍张照存手机里。画的过程中会发现很多文档里没写的“隐形需求”。比如一个登录功能，文档只写了账号密码登录，但你画流程时发现，密码输错三次后账号锁定，锁定后怎么解锁？解锁后原来的密码还能用吗？这些全是测试点。
还有个笨办法但很管用：把需求文档里的每一句话都当成“可能有问题”来读。看到“系统自动处理”，就问自动处理的触发条件是什么，处理失败有没有重试，重试几次后放弃。看到“用户可自定义”，就问自定义的范围有没有限制，特殊字符能不能输入，保存后能不能修改。这种逐句拆解很累，但能挖出大量隐藏需求。
最后一步，把分析结果整理成测试范围清单。左边列功能模块，右边列对应的测试类型：功能、性能、兼容、安全。每个模块后面标注风险等级。高风险模块重点覆盖，低风险模块抽检。这份清单不用给所有人看，但你自己心里得有数。提测后时间永远不够，知道哪里该多花时间，比盲目跑用例重要得多。
需求分析做得好，后面写用例、执行测试、报bug都会顺很多。做得不好，就是无穷无尽的扯皮和返工。花两个小时把需求吃透，省下的是两天甚至两周的无效劳动。