本文部分内容借鉴于博客需求评审的关注点
需求评审、SPEC评审
1、评审前期准备
评审是要在写代码前发现问题，不要吝啬将时间花在前期上，因为这会大大减少我们中后期的意外，避免做很多的无用功。在评审之前，我们要仔细阅读相关的评审资料，了解每个点是干什么的。
2、评审中需要关注的点
（1）文笔
描述是否存在错别字，特别是界面上的文案。例如，登陆->登录
描述是否清楚，是否存在歧义
没有统一术语，多处地方用不同词语来表示同一概念
是否杂乱无章，不便于阅读和查找信息
（2）逻辑性
流程的出入口：是否明确，是否过多（连用户都会昏头转向）
条件与规则说明是否清晰明了
缺少说明数据的来源、类型、精度、取值范围、默认值、显示格式、计算处理方式
是否考虑其它功能或需求的关联影响
用户体验如何
（3）实现
人力、时间等资源是否存在困难
实现难度较大
遗留的坑会导致出严重bug的概率大，风险高
性能不佳，会造成用户体验差
是否有比产品经理想到的更好的方案
能否复用已有的逻辑或使用业界更通用的有开源实现的做法
后续的迭代考虑，是否在设计上预留可扩展性
不重要的部分（例如后台系统）由开发自行决定界面和交互
3.其他
在评审前我们阅读完相关资料后，就可以走整理我们想要提出的问题或是建议了
在评审的过程中，我们要站在用户的角度去思考，站在用户的角度去提出问题
对于新需求来讲，若出现开发和设计人员争执的情况，这时试人员就需要作为第三方站在用户的角度去剖析问题。否则，有些需求实现之后，在进行FUT测试的时候，才发现不合适，那之前做的工作都白做了，这就是资源的一种浪费
用例评审、归档用例
一个测试人员设计出的测试用例，可能会存在考虑不周的问题，如果没有及时的发现这些问题，就可能会出现用户发现问题导致对产品产生不好的影响。所以测试用例设计出来后，如何保证它的质量呢？这时我们将多位测试人员聚集在一起，集思广益，就有了用例评审。用例评审又分为正式评审和非正式评审。
1、评审方式
- 同行评审
测试用例的评审有很多种，但是最敏捷应当是临时的同行评审。同行评审，尤其是临时的同行评审，应当演变成类似结对编程的一种方式。从而体现出敏捷的“个体和交互比过程和工具更有价值。”要体现出测试用例设计者之间的思想碰撞，可以通过讨论、协作完成测试用例的设计。原因很简单，编写的测试用例需要尽可能的覆盖全部需求，而测试人员的思维总会存在缺陷，一个人的思维总是存在局限性，所以需要大家一起来设计。
结对编程：一种敏捷开发的方式，指两个程序员在一台计算机上共同工作。一个人输入代码，另一个人审查他输入的每一行代码。输入代码的人叫做驾驶员，审查代码的人叫做观察员（或导航员），两个程序员经常互换角色。
- 用户检查
除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序。
- 项目组评审
由测试负责人组织开展会议，用例编写人对用例就行讲解，参会人员有异议的当场提出。
2、用例评审内容
在进行用例评审的时候，我们要准备的材料除了测试用例之外，还有测试方案。一般我们都用xmind工具来编写测试方案，
3、归档用例
归档用例就是在用例评审结束之后，将评审中的意见建议修改之后的用例提交到对应的平台上，这就叫做用例的归档。最迟的用例归档时间是在项目版本集成之前。归档用例主要是给其他的测试人员看的。