敏捷测试驱动模式-项目质量保障体系

结合敏捷项目管理,测试驱动模式,让测试跑起来...

我给这套体系的定义就是 “保障质量的同时保证项目进度” ,四个节点及时反馈及时沟通,有效的让产品、研发和测试都动起来,避免任意一方的停滞。

质量的四层把控:

1、测试人员更早的介入需求

2、需求用例+功能用例

3、每天一个功能秀

4、严控用例执行规范

指标维度 核心指标 测试周期 要求指标 衡量标准
测试用例执行规范 测试用例执行率 第一版本 优先级1 100% (差):≤85%,没有根据测试用例执行管理目录进行管理,不能根据测试用例执行,导致测试不全面;缺少执行记录。
第二版本 优先级2 100% (基本合格):85%<测试用例执行率<95%
第三版本/第四版本/第五版本 优先级3/优先级4/优先级5 100% (合格):≥95%,根据测试用例执行管理目录进行管理。能够根据测试用例执行测试,并及时记录执行状态。
测试用例覆盖率 第一版本 用例覆盖率50% 100% (差):≤85%,没有根据测试用例执行管理目录进行管理。不能根据测试用例执行测试,缺少执行测试用例条数的执行记录
第二版本 用例覆盖率30% 100% (基本合格):85%<测试用例覆盖率<95%
第三版本,第四版本,第五版本 用例覆盖率20% 100% (合格):≥95%,根据测试用例执行管理目录进行管理。能够根据测试用例执行测试,并及时记录执行测试用例条数
测试缺陷发现率(严重级别) 第一版本 严重级别缺陷率80% 100% (差):≤85%,没有根据测试用例执行管理目录进行管理。不能根据测试用例执行测试,并及时记录发现的缺陷
第二版本 100% (基本合格):85%<测试缺陷发现率<95%
第三版本,第四版本,第五版本 严重级别缺陷率20% 100% (合格):≥95%根据测试用例执行管理目录进行管理。能够根据测试用例执行测试,并及时记录发现的缺陷
规范要求        
测试负责人或指定人员需要进行每日测试情况发布
测试负责人需要每周进行周计划跟踪和调整
每个版本需要确认开发执行BAT才能接受测试
非发布版本需要对fixed和reject问题进行确认,不允许此两个状态的缺陷遗留到下一个版本。
发布版本不允许存在非close、delay、nobug缺陷存在
其他,需要根据测试管理过程、缺陷管理子过程、测试标准执行。
 
原文地址:https://www.cnblogs.com/Javame/p/5286354.html