测试用例评审流程

上一篇 / 下一篇  2014-02-07 10:35:09

1.      过程描述

1.1.   入口准则

1.        本阶段的测试用例已编写完成;

2.        用户需求说明书、软件需求说明书已完成并入库。

1.2.   输入

1.      XX项目测试用例;

2.      用户需求说明书;

3.      软件需求说明书。

4.      产品原型。

1.3.   过程描述图

1.3.1.     制定评审计划

测试人员依据产品需求编写完成测试用例,建议对测试用例自行检查一遍后,制定测试用例评审计划。

注意如下几点:

u 评审人员:项目经理、产品经理、主要的开发人员、测试人员。

u 本阶段的测试用例已完成,并且需在测试提交前评审完成。

u 需制定一个测试用例反馈的截止时间,并在截止时间之前进行评审反馈。

u 主持人一般为项目的测试主要负责人。

u 建议准备重点说明一般说明评审人员的评审范围或者一些需要重点评审的功能用例。

u 尽量避免测试人员评审自己编写的用例,可以采用交叉评审的方式。

u 相关资料主要说明测试用例存放的位置,需要通过何种方式筛选出评审的测试用例,另外还可以说明产品需求等文档存在的位置。

u 测试用例评审跟踪表评审计划制定后,点击初始化形成各个评审人员的工作表。

1.3.2.     用例评审

主持人制定评审计划后,将《测试用例评审跟踪表》发送给参与评审的各个人员,评审人员收到评审计划后进行用例评审。

用例评审人员的主要评审内容为:

u 是否覆盖产品需求上的所有功能点。

u 测试用例本身的描述是否清晰,是否存在二义性。

u 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确;期待结果是否有明显的验证方法。

u 优先极安排是否合理。

u 是否存在冗余的用例或验证点。

u 是否从用户层面来设计用户使用场景和使用流程的测试用例。

u 是否包含充分的负面测试用例。充分考虑产品的异常流程,并编写测试用例进行覆盖。

注意如下几点:

u 评审人员发现问题后,填写到各自的工作表中,填写字段:提出者、问题描述、严重程度、问题来源(文件、章节)、建议。

u 评审后填写评审时长。

u 评审完成后将评审结果发送给主持人。

1.3.3.     修改和验证评审问题

主持人收集各个评审人员反馈的问题,将问题指派给相应的用例编写的人员进行修改。用例编写人员接收到问题后,针对问题进行分析并修改并答复给问题提出人。问题提出人对修改的问题进行验证并反馈。

注意如下几点:

u 用例修改人员填写引入活动、接受、修改、解决方案、解决人、解决时间字段。

u 用例修改人员若对提出的问题有疑问或不理解,可以与问题提出人员再进行沟通。

u 用例修改人员对问题进行答复后,发送给问题提出人员进行验证。

u 问题提出人对问题的解决情况进行验证,若同意修改结果在关闭人字段填上自己的名字;若不同意修改结果再与用例修改人员进行沟通直到达成最终的修改意见,在关闭人字段写上自己的名字,将结果发送给主持人。

1.3.4.     评审结果分析和审核

在评审的问题全部解决和验证通过了,主持人查看评审的问题、评审数据,进行评审分析,填写评审分析和评审结果。将评审的结果发送给审核人审核,审核人员审核后周知项目组。

注意如下几点:

u 主持人填写评审分析及评审结果的评审结论与意见。

u 审核人填写评审结果的审核修正后的工作成果。

u 审核人一般为项目经理或产品经理,对评审的结果进行审核。若对最终的测试用例不满意可以要求重新进行用例维护和用例评审直至最终满足要求。

1.4.   输出

1.        XX项目测试用例》;

2.        XX项目测试用例评审跟踪表》。

1.5.   出口准则

XX项目测试用例》、《XX项目测试用例评审跟踪表》纳入配置管理


TAG:

引用 删除 flyingbirdxjw   /   2016-02-22 16:07:39
5
 

评分:0

我来说两句

我的栏目

日历

« 2024-03-28  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 55317
  • 日志数: 29
  • 建立时间: 2008-05-20
  • 更新时间: 2014-05-09

RSS订阅

Open Toolbar