从一个真实项目入手分析测试有效性
上一篇 / 下一篇 2012-10-26 09:20:21 / 个人分类:杂谈
-Ze[0jz"c9_7jP [ V0 去年底做了一个Android应用的项目,代码总计2万多行,测试周期4个月,项目虽小,但涉及到手机终端适配、网络环境兼容等多个方面。项目阶段一结束后,我们简单总结了一下测试方法有效性的问题。发出来与大家共享。51Testing软件测试网aS y N B5vi%\P3F
51Testing软件测试网2Q8B6VQ7Boi#i这个Android应用的主要功能很简单,附加功能较多,基本都属于锦上添花类。测试的实际情况如下:51Testing软件测试网B"G|0aU5H%Y9J$Gd.B
51Testing软件测试网'^7{4]T6?K1、资源投入:持续时长4个月,人力6人+,测试机型30款+
N5ta0KIfl0~"hjyG\&s0 2、测试执行:23轮功能测试,7轮系统测试,8轮健全测试,3轮机型兼容测试,3轮性能测试,1轮MTBF测试,1轮PD/UI验证测试。
)dA%[}%X051Testing软件测试网mD J4m;Y4V5p但是这其中有很多不足之处,较明显的如下:
&u4_:TbIfz6b051Testing软件测试网1nA4RLVn1、前期功能测试和健全测试一天一轮,频度太快且测试费时,效果不好。51Testing软件测试网Kjz sW P8ew
51Testing软件测试网8o-P1]X3El2、初期的测试用例设计全面,但未精确定义编写粒度,描述过程过细,后期因需求变更导致维护成本较高。
u p H2h^4_0B6S9tDKy]z0 3、因项目流程和过程控制影响,无法明确划分测试阶段,且初期没有找到最佳敏捷测试方法,测试流程冗余僵化,导致大量重复性的工作,灵活性偏低。
1ZLG`3`6q^-b"I051Testing软件测试网4}(rj8B {D(J#{2aiBQh在测试进程中我们已发现测试策略的问题,并及时调整,在阶段二开始使用新策略——使用两阶段测试模型:51Testing软件测试网U"V,r*ThHwI
*A wIs_u~i0 1、阶段一<自由测试>:按照探索性测试(Exploratory Testing)模式,布置有针对性有重点的自由测试,以“把软件使用坏掉”为目的,尽可能多发现bug。
z7MqO\6SA7E051Testing软件测试网,_$w3@ lv2、阶段二<覆盖测试>:执行各项测试用例,以“全面测试”为目的51Testing软件测试网q:C'@a:l
51Testing软件测试网P/vw _0u(D6b,OG#k+]具体的时间安排如下:
%BB].~v Fl-_km0v#t+h$rm"q7\*dh`0 1、先期产品开发阶段,即Alpha release之前,做功能测试、健全测试、缺陷验证+自由测试。51Testing软件测试网B8N ZWH7I%d-sj
51Testing软件测试网%E/{,QlWh0BpD2、项目中期,Alpha ~ Beta之间,执行全面的系统测试、兼容性测试、性能测试,并开展自动化脚本开发、环境搭建等工作。
({ m([sG6Lo qIx/zv051Testing软件测试网g;FH1G \|7tc,a3、Beta release之后,在产品发布前的2~3周,就开始确定稳定版本Release Candidate,在此版本基础上做最后一轮全面测试、重点子模块的健全测试、缺陷主导的ET等,完成最终报告并交由项目组领导、QA审核发布。51Testing软件测试网$eDlD9OJ
51Testing软件测试网W X(I2B sF本次测试有效性总结我们引入了两个质量来衡量:软件质量指标和测试过程质量指标。
H+U#@5@{-X051Testing软件测试网6I^I*EW%M9G软件质量指标包括:
\1p@8T A"CS*aicv_0|Y:\ x$]a7mhQ.]0 (一)需求功能点覆盖率:51Testing软件测试网9Dt;^P$kWT
1V(r,a~4| }0 计算测试用例总数之和除以与之一一对应的功能点数之和,主要查看是否有功能点遗漏测试的情况。用例覆盖需求矩阵,一个需求对应多个功能点。
Mz-_7q&w o,|U051Testing软件测试网.R3i7@LDU需求覆盖率=∑测试用例数(个)/∑功能点(个)=1055/147=7.18
%P9G_zO+k0#CGXRTvpt K0(二)用例执行覆盖率:
'LC QJp;[0计算测试用例执行总数除以与之一一对应的测试数之和,主要查看是否有测试用例执行遗漏或有效的情况。
/{yA2nP&xR(g0用例执行覆盖率=∑执行的测试用例个数(个)/∑测试用例个数(个)*100%51Testing软件测试网D}z/@9H laG/|b
功能测试276条,系统测试779条,用例执行覆盖率达到99%。51Testing软件测试网 J}/@0\*M:K{
51Testing软件测试网 L\NH9X测试过程质量指标包括:
S w u)lc051Testing软件测试网+JG[,~g~7x,QQ(一)缺陷探测率:51Testing软件测试网X;Z.^7f8]FF h_%M
~pyO&u1tW0 计算内部发现的缺陷数除以内部发现的缺陷数与用户发现的缺陷数之和,主要查看内部发现缺陷的能力。说明:缺陷探测率越高,即内部发现的bug数越多,发布后客户发现的bug数就越少,质量成本就越低。
N?Wt;t&`#]051Testing软件测试网-xI7C9]R%q缺陷探测率=内部发现的缺陷数(个)/(内部发现的缺陷数(个)+用户发现的缺陷数(个))*100%51Testing软件测试网"B6H yJ} \a
51Testing软件测试网l)FpY N#o7MI缺陷数=636(有效),用户发现缺陷数=1(当前)51Testing软件测试网QOv"Xat
Y9J4?5i#Gxv9m`0 缺陷探测率=636/637=99.84%
z:cD ao051Testing软件测试网7Z`? I V q0BAu[|"I(二)有效缺陷率:
G!J#fo`9@ Xf@051Testing软件测试网yI"Dmt计算被开发人员确认的BUG数总和除于本人上报BUG的总和,可用于查看测试人员的个人测试质量,也可用于查看整个测试组的测试质量。51Testing软件测试网M)?;E1j$C
H/d]&n9NY7LAp0 无效BUG状态包括:问题重复、不是问题、不可复现状态。这项指标用于考察测试人员发现的、被确认为缺陷的缺陷数高低或者百分比,数和比率越高测试质量越高。51Testing软件测试网'X&E)yE/r+b3n \
Rcj@(TI;Z0 注意:由于系统框架根本性的、初始化参数设置错误引发的、错误数据、错误环境等而开发人员因无法修正、可以通过改变环境而无需修改程序、重新导入数据、再次发布而解决的BUG为有效BUG51Testing软件测试网n5mLJ OL:x
K'C{ |yVL0 有效缺陷率=测试人员发现的有效缺陷数(个)/测试人员发现的总缺陷数(个)*100%=636/689=92.31%51Testing软件测试网O[?p'C
51Testing软件测试网J2^2~ [$C4aF ~*l FC(三)用例执行效率:
l.A2?0^a051Testing软件测试网^ Bi-f(WL计算测试人员执行的用例数除以执行测试的时间,主要查看测试人员执行测试的效率51Testing软件测试网$g-g/mO\@ g$\