20软件测试需求分析评审
需求分析过程包括：收集文档、研读文档、提出问题、解决问题、整理信息、功能拆分、整合整理的信息和功能拆分、编写测试点。
在研读文档的过程中，获得需求信息，同时产生许多问题，需要提出和解决这些问题，并且整理需求信息。之后，对整理后的需求信息进行功能拆分，对每个功能输出具有逻辑、规则、流程的业务步骤，从正反两方面整理为通顺的需求，再将拆分后的功能、原始需求、需求整理写到需求分析说明书。然后，通过全部的用例设计方法编写测试点。接着，对需求进行评审。
1.1 意义
- 对软件需求进行正确性的检查。主要对测试写的需求分析进行正确性检查。
- 保证软件需求的可测试性。软件能控制的、能做的为可测，否则不可测。
- 通过产品需求文档的评审，与市场、产品、开发等各部门相关人员沟通，使得大家认识一致，避免在后期产生不同的理解，引起争吵。
- 通过产品需求文档的评审，更好地理解产品的功能性和非功能性需求。
- 在需求文档评审过后，测试的目标和范围就确定了（通常测试计划时就有了目标和范围）。虽然此后会有需求的变更，但可以得到有效的控制，这样可以降低测试的风险。评审过后，相当于有了需求的基线，有了基线后，需求不可随意变更，需进行严格审核通过后方可变更。
- 评审是否完成是以需求文档获得多方“邮件确认”或“签字”通过为标志的。这不应该只体现在“签字”形式上，更重要的是达到下面的结果。
（1） 所有参与方达成一致。
（2） 已发现的问题被阐述清楚、被修正。
1.2 需求评审的质量要求
使用评审清单来记录和提问。
（1） 正确性。
（2） 完备性。
（3） 易理解性。
（4） 一致性。
（5） 可行性。
（6） 易修改性。
（7） 可测试性。
（8） 可追溯性。
1.3 需求评审的参加人员
用户(代表)、开发、测试必须参与。
（1） 用户代表。
（2） 需求人员。
（3） 项目经理。
（4） 开发人员。
（5） 开发经理。
（6） 测试人员。
（7） 测试经理。
（8） 市场经理。
（9） 质量保证人员。
1.4 测试人员参与评审时的注意事项
- 明确自己的角色和职责。
- 熟悉评审内容，为评审做好准备，做细做到位。
- 在评审会上，针对问题阐述观点，而不是针对个人。
- 可以分别讨论主要的问题和次要的问题。
- 在会议前或会议后可以就存在的问题提出自己建设性的意见。
- 提高自己的沟通能力，采取适当的、灵活的 表述方式。
- 对发现的问题跟踪下去。
- 应该在需求形成的过程中进行分阶段的多次评审，而不是一次评审。
- 测试人员要善于提问，多思考。
（1） 这些需求都是用户提出来的吗？
（2） 有没有画蛇添足的需求？没有漏掉什么需求吗？
（3） 和竞争对手的产品做过比较吗？我们的产品优势体现在哪里？
（4） 是否正确的描述了每个需求？这条描述是否存在二义性的问题？
（5） 我的理解和文档作者的理解一致吗？
小梯子有话说：
每一次需求评审都是团队智慧的碰撞，每个提问都是质量防线的加固。当我们以开放心态拥抱不同视角，用严谨态度雕琢每个细节，就能将冰冷的文档转化为温暖的质量承诺。记住：优秀的软件从来不是一个人的杰作，而是一群人的共舞。