标签：是否 流程 测试人员 评审 用例 测试用例 测试 研发
- 功能评审定义：由研发经理主推，测试协助推进
由研发经理和测试负责人定义，相关测试人员负责推进
小功能由研发和测试自行定义 - 人员
研发人员
测试人员
研发经理
需求人员 - 时间
由测试人员编写完测试用例和思路后，进行评审，评审时间必须根据预期时间（提前预期24小时）给出，如有延误提前通知与会人员。
考虑需求功能交互疑问的地方，认为不合理，或者不理解的地方-->文档 - 地点
会议室 - 资料准备
提前调试好设备投影
测试思路，用例文档，
需求功能交互疑问的地方，认为不合理，或者不理解的地方，是否需要研发协助提供相关数据支持-->文档
打印测试思路和需求以及功能实现疑问。此处需要给出制式表格，提前一小时分发给参审人员。 - 评审流程
- 开始
由测试人员根据测试思路和用例结合需求原型和设计文档进行测试策略的讲解：评审人员进行评审
过程中提出当前功能的所有疑问点：相关评审人员进行回复 - 评审内容
测试思路是否合理，不合理，那些不合理，提出意见
测试是否有缺失点，有，有哪些，明确指出具体位置和功能
测试提出的疑问是否为有效问题，有，是什么问题，如何解决
参审人员是否有自己需要补充的地方，有，补充问题
测试用例是否有结构性，流程性，比如根据用户的操作流程，或者测试整体的构思
当前测试人员和研发人员随时做好所有争论问题记录和解决方案，后续对功能进行拓展和删减
用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
优先极安排是否合理。
是否覆盖测试需求上的所有功能点以及用户的交互流程
用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
是否有无效冗余的用例。有哪些，此处研发需要注意
是否包含充分的负面测试用例。充分的定义，
是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
是否能够形成有效的：冒烟测试，回归测试，系统测试 - 结束
评审内容进行完毕
无争论存在
有争论考虑是否给出二次评审计划和时间
功能预期实现定义，按照此次沟通实现，或者需要重新考虑和设计处理（可分为一期，二期，三期后续加强）
- 信息记录
测试和对应研发人员做好信息记录
标签：是否,流程,测试人员,评审,用例,测试用例,测试,研发 来源： https://www.cnblogs.com/python-robot/p/12886636.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。