需求评审知识
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、开发、测试、相关部门领导，要求细致应当检查需求文档中的每一个需求，每一行文字，每一张图，但在这个过程中可能出现各种情况例如参会人员对需求理解不明确，发散思维，偏离方向，需求点发生分歧争执僵持，对技术方案探讨不定，对问题点无限引申
