本文部分参考了博客需求评论的热点
需求评论，SPEC评论1、评审前期准备
审阅在编写代码之前要发现问题，并不惜在前期花费时间。 因为那会大大减少我们中后期的事故，避免很多无用的工作。 评审之前，必须仔细阅读相关评审材料，了解每个要点在做什么。
2、评审中需要关注的点
(1)文章
说明是否有错字，特别是接口的副本。 例如，登录-登录
说明是否明确，是否有歧义
没有统一术语，很多地方用不同的词表示同一个概念
是否杂乱无章，不方便阅读和寻找信息
)2)逻辑性
流程出入口：是否明确，是否过多(甚至用户也会发疯) )。
条件和规则的说明是否清楚
没有说明数据的来源、类型、精度、可取值的范围、默认值、显示格式、计算处理方法
是否考虑了其他功能和需求的相关影响
用户体验怎么样
(3)实现
人力、时间等资源是否存在困难
很难实现
遗留的漏洞引起严重臭虫的概率高，风险高
性能不好的话，用户体验会变差
有比产品经理想的更好的方案吗
是否可以重用现有的逻辑，或者使用业界更常见的开源实现方法
在随后的反复讨论中，是否确保设计的可扩展性
不重要的部分，例如后台系统，开发者自己决定接口和交互
3.其他
在审阅前阅读相关资料后，可以整理我们想提出的问题和建议
在评论的过程中，我们必须站在用户的立场上思考，站在用户的立场上提问
针对新的需求，如果出现开发者和设计者争执的情况，被实验者需要作为第三方站在用户的立场上分析问题。 否则，在一些需求实现后，在进行FUT测试时，发现不合适，之前做的工作将会浪费。 这就是资源的浪费
用例审核、归档用例单个测试人员设计的测试用例可能存在未充分考虑的问题，如果不及时发现这些问题，用户可能会发现问题并对产品产生负面影响。 所以测试用例设计后，如何保证其质量？ 这时，我们召集了多个测试人员，集思广益，进行了用例审查。 用例审查分为正式审查和非正式审查。
1、评审方式
同行评审测试用例的评审有很多种，但最敏捷的应该是临时的同行评审。 同行评审，特别是临时的同行评审，应该向结对编程这样的方式发展。 这样可以体现出“个体和交互比流程和工具更有价值”的敏捷。 为了表达测试用例设计者之间的思想冲突，可以通过讨论、合作来完成测试用例的设计。 原因很简单，编写的测试用例应该尽可能地覆盖所有的需求，但测试人员的思维总是有缺陷的，而一个人的思维总是有局限性的，所以需要大家一起设计。
结对编程：一种敏捷开发方式，意思是两个程序员在一台计算机上协同工作。 一个人输入代码，然后确认另一个人输入的所有代码。 输入代码的人称为司机，审查代码的人称为清秀的精灵(或导航者)，两个程序员经常交换角色。
用户检查不仅要参与同行评审，还要尽可能地引入用户参与测试用例设计，让用户参与评审，体现敏捷“客户合作比合同协商更有价值”的原则。 这里的客户含义比较广泛，关键是如何定义测试，如果测试是对产品的批评，客户可以是最终用户或客户代表(内部可以是营销人员或领域专家)； 如果测试被定义为开发支持和支持，则客户显然是计划。
项目审查由测试负责人组织召开会议，用例作者对用例进行说明，参与者有异议时当场提出。
2、用例评审内容
在进行用例审查时，我们准备的资料除了测试用例外，还有测试计划。 我们通常使用xmind工具制定测试计划
3、归档用例
归档用例是指在用例审查结束后，将修改了正在审查的意见的用例提交到相应的平台，称为用例归档。 用例的归档时间最晚发生在项目版本合并之前。 归档的用例主要展示给其他测试者。