2013年测试工作总结
2013年测试工作总结
常常，我们会听到老板或者老总等领导说，你们测试团队的贡献率或是价值在哪？软件系统的稳定性如何？下面我将根据这两个问题，作出一些解答。
1. 测试投资回报率
企业为了获得利润，需花费大量的资金进行测试。在质量方面的投资会产生利润，例如提高产品质量会提高公司的声誉，使产品交付之后的维护成本减少，避免用户的抱怨。测试是一种带有风险性的管理活动，减少企业在未来因为产品质量低劣而花费不必要的成本。
缺陷探测率：
DDP=Bugtester/(Bugtester+Bugcustomer)
表1 客户发现bug数统计
|
月份 |
客户发现的bug数 |
|
6 |
7 |
|
7 |
0 |
|
8 |
2 |
|
9 |
3 |
|
10 |
0 |
|
11 |
3 |
|
12 |
1 |
|
合计 |
16 |
数据是从2013年6月份开始统计
表2测试人员发现bug数统计
|
由谁创建 |
总计 |
未解决 |
设计如此 |
重复Bug |
外部原因 |
已解决 |
无法重现 |
延期处理 |
不予解决 |
转为需求 |
有效率 |
|
周MM |
700 |
7 |
38 |
14 |
35 |
419 |
31 |
2 |
27 |
127 |
78.29% |
|
余GG |
1325 |
11 |
47 |
26 |
55 |
788 |
33 |
16 |
39 |
310 |
84.08% |
|
合计 |
2025 |
18 |
85 |
40 |
90 |
1207 |
64 |
18 |
66 |
437 |
82.07% |
数据统计时间：2013年1月1日到2013年12月31日，其中有效率的计算公式=（已解决+延期处理+转为需求）/总计*100%
属于质量预防方面的一致性成本只考虑软件测试的投资，把发布之前和之后发现及修改的错误堪称非一致性成本，根据表1和表2，发现的错误为2041个，故障成本已知，测试过程的估算如下：
各阶段花费在发现及修改错误的成本假设如下：
①在开发过程单元测试阶段，软件开发人员发现及修改一个错误需要50元；
②建立独立的测试进行集成和系统测试，测试人员发现错误，开发人员修改后，测试人员再确认，一个错误需要300元；
③在产品发布后，由客户发现，报告技术支持人员、相关开发人员修改，测试组再进行回归测试，一个错误需要2000元。
第1种情况，开发单位未建立独立测试队伍，有开发人员进行测试，发现680个错误，而产品发布后客户发现错误1361，只存在故障成本构成的总成本为50*680+2000*1361=2756000元，缺陷探测率为33.32%。
第2种情况，开发单位建立了独立测试队伍，进行手工测试。投资预算人员费用为100000元，测试环境使用费为8000元，测试投资（一致性成本）为108000元，除了开发过程中开发人员发现并修改680个（假设开发人员只能发现1/3的问题）错误外，测试过程中测试人员发现错误1345个，而产品发布后客户发现16个错误。总质量成本下降到50*680+300*1345+16*2000+108000=577500元（如表3所示），手工测试总质量成本节约了2756000-577500=2178500元，即为利润。投资回报率(ROI)为2017.13%，缺陷探测率为99.22%。
ROI = (原无独立测试质量成本i-独立测试质量成本j)/测试投资*100%
= （2756000-577500）/108000*100%
= 2017.13%
DDP=Bugtester/(Bugtester+Bugcustomer)*100%=（680+1345）/2041*100%=99.22%
表3 测试投资回报分析
|
质量成本项 |
测试成本项 |
开发测试 |
手工测试 |
|
|
一致成本 |
测试投资 |
测试人工费 |
100000 |
|
|
环境使用费 |
8000 |
|||
|
测试工具费 |
||||
|
测试总投资 |
108000 |
|||
|
非一致性成本 |
开发测试 |
发现错误数 |
680 |
680 |
|
每个错误成本 |
50 |
50 |
||
|
内部（开发）故障成本 |
34000 |
34000 |
||
|
独立测试 |
发现错误数 |
1345 |
||
|
每个错误成本 |
300 |
|||
|
内部（测试）故障成本 |
403500 |
|||
|
客户支持 |
发现错误数 |
1361 |
16 |
|
|
每个错误成本 |
2000 |
2000 |
||
|
外部故障成本 |
2722000 |
32000 |
||
|
质量成本 |
一致性成本 |
108000 |
||
|
非一致性成本 |
2756000 |
469500 |
||
|
总质量成本 |
2756000 |
577500 |
||
|
ROI |
投资回报率 |
N/A |
2017.13% |
|
|
DDP |
缺陷探测率 |
34.30% |
99.22% |
|
2. 系统可靠性分析
平均每千行代码bug数
后台代码总共342480行（由于前台代码较难统计，据开发人员估计是后台代码的3倍），系统总代码数是1369920，属于一个大规模系统，平均每千行代码约为2个bug。
平均无故障时间MTTF
若设T是软件总的运行时间，M是软件在这段时间内的故障次数。
内部平均无故障时间MTTF=T/M=365*24/2041=4.29小时；
外部平均无故障时间MTTF= T/M =(365-151)*24/16=321小时=13.375天。根据考察资料得知，航天科技一些精密系统平均无故障时间720小时对应90分的可信度，参考这个，相当于我们系统的可信度大约为40分。
下面用Shooman模型对平均无故障时间MTTF进行分析：
对一个长度为342480行代码的系统进行测试，根据记录下来的数据如下：
①测试开始，发现错误个数为0（假设为0，2012年测试出bug不计入统计）；
②经过了151天的测试，累计改正1137个错误，此时，MTTF=3.19小时；
③又经过214天的测试，累计改正2041个错误，此时，MTTF=4.29小时；
由Shooman公式： MTTF=1/K（ET/LT-ET(t)/LT）
其中，K 是一个经验常数，美国一些统计数字表明，K的典型值是200；ET 是测试之前程序中原有的故障总数；LT 是程序长度（机器指令条数或简单汇编语句条数）；t是测试（包括排错）的时间；EC (t) 是在0～t期间内检出并排除的故障总数。
公式的基本假定是：
单位（程序）长度中的故障数ET∕LT近似为常数，它不因测试与排错而改变。 统计数字表明，通常ET∕LT 值的变化范围在0.5×10-2～2×10-2之间；故障检出率正比于程序中残留故障数，而MTTF与程序中残留故障数成正比；故障不可能完全检出，但一经检出立即得到改正。
由已知条件②、③可解出K=31.22 ,ET = 4598 。系统中仍可能残留4598-2041=2557个问题。
评估系统稳定性还有哪些方法、模型、参数呢？希望经验人士多给意见。
【参考文献】
《软件评测师教程》
