一、测试需求评审
- 需求评审的意义：充分熟悉软件需求，为编写测试用例打下基础；若发现软件需求中有不明确的地方，可以当场沟通，有利于推进测试工作；和开发人员一起参与评审，有助于了解开发的技术方案，有利于测试工程师设计更有效的测试用例。
-
完善的需求应具备的特点
- 完整性：每一项需求都必须将所有要实现的功能描述清楚，以便开发人员获得设计和实现这一需求
- 正确性：每一项需求都必须准确的陈述其要开发的功能
- 一致性：指与其它软件需求或者高层需求不相矛盾
- 可行性：每一项需求都必须是系统和环境权能和范围内能实施
- 无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求简明的用户性的语言描述出来。
- 健壮性：需求的说明是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
- 必要性：可理解为每项需求都是用来授权你编写文档的“依据”，要使每项需求都能回溯至某项客户的输入。
- 可测试性：每项需求都能通过设计测试用例进行测试或者其他方式进行测试。
- 可修改性：每项需求只应在SRS中出现一次，这样更容易保持一致性。另外，使用目录列表、索引和相互参照列表方法使软件需求规格说明书更容易修改。
- 可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求要以一种结构化的、粒度好的方式编写并单独标注，而不是大段的叙述。
- 分配优先级：应当对所有的需求分配优先级
-
需求评审的形式
- 正式评审：是指通过开评审会的形式，组织多个专家，将需求涉及到的人员聚集在一起，并定义好参与评审人员的角色和职责，对需求评审进行正规的评审。
- 非正式评审：通过非正式的，一般通过邮件、电话、网络聊天等对需求进行评审。两种评审各有利弊，在评审时视情况而定。
- 相互评审、交叉评审：甲乙在两个项目组，处在一个领域，但工作内容不同，甲的工作成果交给乙审查，乙的工作成果交给甲审查，相互评审是非正式评审，但是非常有效的方式，在工作中经常使用。
- 轮查：又称分配审查方法，是一种异步评审方式。作者将需要评审的内容发给各个评审员，并收集他们的评审意见，这是一种非正式评审。
- 走查：产品的作者将产品在现场向同事介绍，描述产品要有怎样的功能、结构，从头到尾走一遍，以收集大家的意见。希望参与评审的同事能发现其中的错误，进行现场讨论这种方式处于正式和非正式之间，其应用普通。
- 小组评审：通过正式的评审会议完成评审工作，是有计划和结构化的评审形式。评审定义了评审会议中的各种角色和相应的责任，一般所有参与者在评审会仪的前几天就能拿到评审材料，并对该材料进行了独立研究。
- 审查：审查和小组评审很相似，但更为严格，是最系统、最严密、最系统化的评审形式，包含了制定计划、准备和组织会议、跟着和分析审查结果等。
-
评审的注意事项
- 精心挑选评审人员
- 定制规范化评审流程
- 准备好评审材料
- 做好结果跟踪工作
二、测试计划评审
- 测试计划评审的意义：让项目测试人员明确本次测试的介入时间和结束时间；明确测试的参与人员；明确测试需要的资源；明确测试可能存在的风险。
- 测试计划评审参与人员：一般有开发负责人、运营人员、运维人员、测试人员、其他项目负责人。
三、测试用例评审
-
用例评审的目的：减少测试无效工作（执行无效case，条无效问题）；避免三方需求理解不一致；每个测试人人员的质量标准与项目要求标准达成一致。
-
用例评审过程与内容
准备工作
- 确定评审需求的原因
- 确定进行评审的时机
- 确定参与评审人员
- 明确评审的内容
- 确定评审结束的标准
- 提前至少一天将需要评审的内容以邮件的形式发送给评审人员。并注明评审时间、地点及参与人员。
- 在邮件中注明评审会议相关人员至少简读一遍评审内容，并记录相关疑问，以便在评审会议上提出。
- 会议主持方（一般是用例编写者）应在会议前整理相关问题，一便在会议上提出。
开始评审
- 召开评审会议，与会者在设计人员讲解之后给出意见和建议，并进行详细记录。
- 通过邮件与相关人员沟通。
- 通过IM工具直接与相关人员沟通。
- 根据评审内容进行评审。
评审内容
- 用例的结果设计是否清晰、合理，是否有利于高效对需求进行覆盖。
- 优先级安排是否合理。
- 是否覆盖测试需求上所有的功能点。
- 用例是否具有很好的可执行性。
- 是否删除了冗余的测试用例。
- 是否充分包含了负面测试用例。充分的定义，如果使用的是“28”法则，那就是4倍于正面测试用例。
- 是否从用户层面来设计使用场景和使用流程测试用例。
- 是否简洁，并具有复用性。
参与人员
- 部门评审：测试部门全体人员
- 公司评审包括项目经理、需求分析人员、架构设计人员、开发人员、测试人员。
- 客户评审：外包公司比较常见
网友评论