测试评审——精选推荐

测试评审
⼀、测试需求评审
1. 需求评审的意义：充分熟悉软件需求，为编写测试⽤例打下基础；若发现软件需求中有不明确的地⽅，可以当场沟通，有利于推进测
试⼯作；和开发⼈员⼀起参与评审，有助于了解开发的技术⽅案，有利于测试⼯程师设计更有效的测试⽤例。

2. 完善的需求应具备的特点
完整性：每⼀项需求都必须将所有要实现的功能描述清楚，以便开发⼈员获得设计和实现这⼀需求
正确性：每⼀项需求都必须准确的陈述其要开发的功能
⼀致性：指与其它软件需求或者⾼层需求不相⽭盾
可⾏性：每⼀项需求都必须是系统和环境权能和范围内能实施
⽆⼆义性：对所有需求说明的读者都只能有⼀个明确统⼀的解释，由于⾃然语⾔极易导致⼆义性，所以尽量把每项需求简明的⽤户性的语⾔描述出来。

健壮性：需求的说明是否对可能出现的异常进⾏了分析，并且对这些异常进⾏了容错处理。

必要性：可理解为每项需求都是⽤来授权你编写⽂档的“依据”，要使每项需求都能回溯⾄某项客户的输⼊。

可测试性：每项需求都能通过设计测试⽤例进⾏测试或者其他⽅式进⾏测试。

可修改性：每项需求只应在SRS中出现⼀次，这样更容易保持⼀致性。

另外，使⽤⽬录列表、索引和相互参照列表⽅法使软件需求规格说明书更容易修改。

可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试⽤例之间建⽴起链接链，这种可跟踪性要求每项需求要以⼀种结构化的、粒度好的⽅式编写并单独标注，⽽不是⼤段的叙述。

分配优先级：应当对所有的需求分配优先级
3. 需求评审的形式
正式评审：是指通过开评审会的形式，组织多个专家，将需求涉及到的⼈员聚集在⼀起，并定义好参与评审⼈员的⾓⾊和职责，对需求评审进⾏正规的评审。

⾮正式评审：通过⾮正式的，⼀般通过邮件、电话、⽹络聊天等对需求进⾏评审。

两种评审各有利弊，在评审时视情况⽽定。

相互评审、交叉评审：甲⼄在两个项⽬组，处在⼀个领域，但⼯作内容不同，甲的⼯作成果交给⼄审查，⼄的⼯作成果交给甲审查，相互评审是⾮正式评审，但是⾮常有效的⽅式，在⼯作中经常使⽤。

轮查：⼜称分配审查⽅法，是⼀种异步评审⽅式。

作者将需要评审的内容发给各个评审员，并收集他们的评审意见，这是⼀种⾮正式评审。

⾛查：产品的作者将产品在现场向同事介绍，描述产品要有怎样的功能、结构，从头到尾⾛⼀遍，以收集⼤家的意见。

希望参与评审的同事能发现其中的错误，进⾏现场讨论这种⽅式处于正式和⾮正式之间，其应⽤普通。

⼩组评审：通过正式的评审会议完成评审⼯作，是有计划和结构化的评审形式。

评审定义了评审会议中的各种⾓⾊和相应的责
任，⼀般所有参与者在评审会仪的前⼏天就能拿到评审材料，并对该材料进⾏了独⽴研究。

审查：审查和⼩组评审很相似，但更为严格，是最系统、最严密、最系统化的评审形式，包含了制定计划、准备和组织会议、跟着和分析审查结果等。

4. 评审的注意事项
精⼼挑选评审⼈员
定制规范化评审流程
准备好评审材料
做好结果跟踪⼯作
⼆、测试计划评审
1. 测试计划评审的意义：让项⽬测试⼈员明确本次测试的介⼊时间和结束时间；明确测试的参与⼈员；明确测试需要的资源；明确测试
可能存在的风险。

2. 测试计划评审参与⼈员：⼀般有开发负责⼈、运营⼈员、运维⼈员、测试⼈员、其他项⽬负责⼈。

三、测试⽤例评审
1. ⽤例评审的⽬的：减少测试⽆效⼯作（执⾏⽆效case，条⽆效问题）；避免三⽅需求理解不⼀致；每个测试⼈⼈员的质量标准与项⽬
要求标准达成⼀致。

2. ⽤例评审过程与内容
准备⼯作
确定评审需求的原因
确定进⾏评审的时机
确定参与评审⼈员
明确评审的内容
确定评审结束的标准
提前⾄少⼀天将需要评审的内容以邮件的形式发送给评审⼈员。

并注明评审时间、地点及参与⼈员。

在邮件中注明评审会议相关⼈员⾄少简读⼀遍评审内容，并记录相关疑问，以便在评审会议上提出。

会议主持⽅（⼀般是⽤例编写者）应在会议前整理相关问题，⼀便在会议上提出。

开始评审
召开评审会议，与会者在设计⼈员讲解之后给出意见和建议，并进⾏详细记录。

通过邮件与相关⼈员沟通。

通过IM⼯具直接与相关⼈员沟通。

根据评审内容进⾏评审。

评审内容
⽤例的结果设计是否清晰、合理，是否有利于⾼效对需求进⾏覆盖。

优先级安排是否合理。

是否覆盖测试需求上所有的功能点。

⽤例是否具有很好的可执⾏性。

是否删除了冗余的测试⽤例。

是否充分包含了负⾯测试⽤例。

充分的定义，如果使⽤的是“28”法则，那就是4倍于正⾯测试⽤例。

是否从⽤户层⾯来设计使⽤场景和使⽤流程测试⽤例。

是否简洁，并具有复⽤性。

参与⼈员
部门评审：测试部门全体⼈员
公司评审包括项⽬经理、需求分析⼈员、架构设计⼈员、开发⼈员、测试⼈员。

客户评审：外包公司⽐较常见。