需求评审知识：软件测试的第一步

需求评审知识

1，什么是测试需求分析
测试需求分析是根据软件需求文档(原型工具axure-原型图-蓝湖-墨刀)，对软件的功能进行分析，整理出测试点及测试方法的过程。
2，需求评审的重要性
软件的缺陷并不是在编程的时候才出现的，需求和设计阶段都会产生问题，如果缺陷发现的越早，修复这个bug的成本就越低。（提前发现一些问题，并提出合理的建议）

3，进行需求评审的好处 /原则
a. 对软件需求进行正确性的检查，能发现需求定义中的错误，从而节约成本，使后续过程的变更减少，降低风险。
b. 保证软件需求的可测试性，即确认客户的需求是明确的（1.从客户的角度出发2.客户直接提出的需求），可预见的。可以用测试用例反应出来 。
c. 通过产品需求评审，可以使产品，设计，开发，测试等部门相互沟通，达成一致。 一致性
d. 通过产品需求的评审，（新同事）更好的理解产品的功能性和非功能性需求，为制订测试计划，测试范围，工作量等提供参考。

4，需求评审时常发生的情况 》》 将抽象的东西结合实际工作场景
a. 与会人员对需求的目标不明确（产品），易发散思维，最终偏离方向。（这个版本不需要单点登录，多设备登录）
b. 对某个需求点相持不下，认为该需求不合理/开发周期长不划算，从而导致场面混乱，长时间僵持下去。
（争论是正常，但必须要有结果，或者部门leader直接协商好，技术部老大）
c. 对技术方案探讨不定，对问题点无限引申。
d. 遗漏评审时的待改动的需求点，会后找相关人员再次确认。（待定）

5, 那如何进行有效的需求评审呢
a. 产品内部评审，确保需求逻辑的一致性。可以规避大部分需求不合理的地方，可以直接有效的提升需求评审的效率。
b. 提前把需求文档发出来，让与会者提前查看产品需求文档。提前标注出需求疑问点。
c. 提前通知评审时间和与会人员

6, 参加需求评审的一般都有哪些人？（了解）
项目经理、产品经理、UI、开发、测试、相关部门领导

7, 需求评审究竟评审什么?要细到什么程度?
产品经理编写的需求文档、原型图 》》评审的对象 ；
严格地讲，应当检查需求文档中的每一个需求，每一行文字，每一张图。
评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性（开发）、可验证性（测试）、可测性。>>> 准则

在软件需求分析阶段，测试人员评审需求文档目的主要有三方面：
　　a、及时检测出软件需求文档中具有不可测试性的需求点。（难点在哪？能不能测？）
　　不可测试：某功能模块输入可见，输出不可见，无法验证模块功能是否正确；或是该功能模块的输出无参考标准来衡定。
　　b、及时发现软件需求文档的不完整性，从而提醒需求分析人员弥补描述。
　　c、熟悉业务需求，保证与需求人员保持理解一致，及时发现文档中有歧义、二义性、模糊的描述，从而提醒需求分析人员以精确的文字来描述需求点。
　　在这三个评审目的的指导下，测试人员的评审行为包括：
　　a、找出不可测试的需求点
　　b、找出用户提出的、但未被完整描述的需求点
　　c、找出描述有歧义、二义性、模糊的需求点

需求评审会后及时输出会议纪要，罗列出会议中有争议仍待解决的问题、改动的部分和结论，将完善后最终更新过的需求文档发送给参会人员，通知需求评审已完成。

需求评审之后，确定项目周期:
a. 开发周期，什么时候可以提测
b. 测试周期，什么时候测试结束，可以上线

8，测试需求分析的步骤（重点）
仔细、反复阅读需求文档，深入理解
分析整理测试点：
列出所有可测的功能点
对每个功能点进行分层分析
分析功能点之间有哪些关联关系
考虑有哪些可能的异常流程
通用异常情况：
网络环境：网络中断、网络切换、丢包（数据包）延时
服务器资源：服务器无响应、响应慢、无法连接服务器
系统环境：被测系统文件缺失、PC或手机系统缺少必要组件、权限不足
异常中断：断电、通话中断
找到隐藏需求：
了解需求整体架构
熟悉所有实现细节
代入用户角色，实际场景中推测
9, 测试需求分析结果示例（一）

原始需求没有对群主的权限进行描述，需要和产品确认并补充。 细化，准确意图
最后测试负责人开始编写测试计划
》》 咱们公司是如何进行需求评审的啊？
需求评审这一个过程很重要，能够尽早的发现缺陷，修复，降低成本，主要由项目经理、产品经理、UI、开发、测试、相关部门领导，要求细致应当检查需求文档中的每一个需求，每一行文字，每一张图，但在这个过程中可能出现各种情况例如参会人员对需求理解不明确，发散思维，偏离方向，需求点发生分歧争执僵持，对技术方案探讨不定，对问题点无限引申