怎样使用数据度量测试
在测试项目中会遇到一些难点,如测试进度量化、测试表现量化、工作量和预期时间的管理。作为一名致力于往管理方向靠的同学应该都会思考的问题。每个人执行的内容不一样,遇到的问题不一样,测试难度不一样,还有一些不确定的客观和主观因素,那如何才能在实际的项目组很好的使用数据度量测试呢?主要从下面几个方向进行分析,测试进度,测试有效性和测试工程师的表现。
测试进度:
测试计划与实际测试的差异往往是不可忽视的,作为测试经理或主管在测试计划的时候就需要对整个相关的开发周期和里程碑时间确定清楚。然后根据测试内容进行量化评估,以确保合理安排人力和排期顺利交付合格产品。
测试计划:
- 项目里程碑:通常项目都会与一个开发时间计划里程碑表,在各个时间阶段需要交付对应的产品。以确保后续产品能够按照预订时间进行发布上线。一般情况,是不会轻易变动的,这里我们默认固定时间。
- 工作量评估:测试工作需要对测试内容,测试项,多寡以及自动化程度,测试人力可投入资源等多方评估后才能确定。
- 专项测试:性能专项、兼容专项、安全专项、弱网专项等
- 功能测试:主要以模块负责的方式进行责任制管理,将模块耦合度高的尽量做拆分
- 人力资源:现阶段测试人力,每天投入与产出评估,人力不足时需要调整测试策略或增加人手已满知足项目测试需求
- 测试内容:项目按照模块划分后,对应模块的工作量化。需要对模块复杂程度和测试点判断,然后给出工时。
- 测试计划:测试计划排期主要是根据任务量所需工时,然后结合里程碑时间进行各个阶段的测试计划。
- 测试准备:前期准备阶段,需要与开发跟进需求,需求评审后就开始陆续编写用例和用例评审,环境准备等
- 测试执行:按照用例执行,并做好相关记录。(需要收集执行用例数量,发现bug数量,执行时长等相关数据)
- 专项并行:这部分在功能验收阶段可以根据测试包体的完整性进行择机测试。在测试计划中体现大致的时间范围。
- 预留时间buff:项目开发本身是变化的,因此,在设计测试计划时预留buff时间,以应对各种突发情况。
实际测试时间:
- 实际时间:测试工程师不可能100%投入到工作中,根据数据统计每天的经力的60%时间投入属于正常。测试工程师在执行过程中还需要应对各种问题,如沟通,会议,学习等
- 执行记录:做好用例执行记录,以版本维度做好模块执行耗时、用例数量、bug数量,严重级别等数据
- 修正计划:通过真实数据,对测试计划进行适当的修正,使其更合理
结果偏移:
- 实际完成时间和计划时间的差异就是结果偏移,在日常执行的过程中合理范围内做一些内容的前置,每天多做一点,以保证如期交付。
测试有效性:
测试有效性(Test Effectiveness,TE)是指执行用例发现的有效bug的数量。公式:测试有效性 = 有效bug数/执行用例数 ;在版本迭代,模块管理过程中可以通过此预测该版本或者模块大致会有多少bug。比如:版本——测试有效性为:0.060 ,目前还有30个用例没有执行,这个时候我们可以预测还有大概2个bug。工程师——测试有效性:工程师B的有效性为0.099,如果还有40个用例没有执行,那可以预测还会发现4个bug。
不同维度,可以让我们直观的看到版本在迭代过程中质量的变化。如下趋势是说明版本越来越稳定,bug数量呈现收敛,且严重级别高的bug修复,符合发布标准。
版本维度:
版本 | 缺陷 | 用例执行数 | 缺陷/用例执行数 | |||
新增 | 总计 | 发布 | 总计 | 发布 | 总计 | |
开发版本1 | 34 | 34 | 570 | 570 | 0.060 | 0.060 |
开发版本2 | 47 | 81 | 1230 | 1800 | 0.038 | 0.045 |
开发版本3 | 39 | 120 | 890 | 2690 | 0.044 | 0.045 |
开发版本4 | 18 | 138 | 490 | 3180 | 0.037 | 0.043 |
开发版本5 | 6 | 144 | 220 | 3400 | 0.027 | 0.042 |
版本 | 严重级别 | ||||
致命 | 严重 | 一般 | 建议 | 总计 | |
开发版本1 | 7 | 13 | 13 | 1 | 34 |
开发版本2 | 4 | 11 | 30 | 2 | 47 |
开发版本3 | 2 | 3 | 34 | 0 | 39 |
开发版本4 | 1 | 2 | 12 | 3 | 18 |
开发版本5 | 0 | 0 | 6 | 0 | 6 |
工程师维度:
工程师 | 工程师A | 工程师B | 工程师C | 工程师D | 工程师E | 总计 |
用例执行数 | 151 | 71 | 79 | 100 | 169 | 570 |
有效bug | 9 | 7 | 6 | 3 | 9 | 34 |
缺陷/用例 | 0.060 | 0.099 | 0.076 | 0.030 | 0.053 | 0.060 |
测试工程师的表现:
测试工程师的表现,最终通过绩效方式直接提现,那我们怎么才能激励员工的同时尽可能通过数据公平决策。实际项目中评价绩效,一言难尽,很多时候都没有标准,确实也是个难题。
在上述过程中,我们在执行用例过程中就已经开始做这部分工作了。基本衡量维度有:用例执行数量、bug数量。但是直接粗暴的比较会出现很多弊端,比如恶性竞争只追求数量不要求质量。
用例执行数量:阶段时间所执行的用例数,如一个月或一个季度
bug数量:阶段时间发现的bug数量,如一个月或一个季度
评价方式:用例执行量为总的执行量的占比,bug数量为总的bug数量的占比,通过占比进行计算。同时增加不同等级bug的权重如:
致命 | 严重 | 一般 | 建议 |
10 | 5 | 3 | 1 |
通过调整权重,使得评价更加客观多元化。当然,理论上,这样做是非常可行的,但是在执行的过程中,还会有很多问题。如这些数据的收集整理(日常工作就挤破头了,根本没有时间做好记录,所以规范化流程化管理是非常必要的),其他维度贡献的评价。
总结:
本文提供一些量化方向,可以使得我们在管理和计划过程中有数据做支撑,而不是一味的拍脑袋决策。同时,在量化过程中也间接的做好了执行过程的监督和抽查工作。作为一个成熟的测试负责人,不至于被动,可以通过数据进行判断当前版本质量变化及时的发现测试进度问题,灵活的做出调整,高质量交付。