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