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

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

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

质量的四层把控：

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