软件测试工作中对问题的发现和改进
上一篇 /
下一篇 2012-08-17 09:29:34
/ 个人分类:测试经验
1G%_v1m2x
Mj0 软件测试并不是一项一成不变的工作,南京达内提醒大家要善于发现软件测试中存在的一些问题,通过不断改进的测试方法来让自己进步。
s;RK-o!j*\:d,NS0VMe2I?u/a0 一、软件测试用例设计的不同维度51Testing软件测试网0]"G`
d:T
51Testing软件测试网M.~n}"ck;M 软件测试用例设
计的时候,可以有不同的维度来考虑。一般来说,是按照开发的流程和数据的准备过程设计的测试用例。由于逻辑较多、数据流较复杂,造成用例图很大,分支很
多。进行case评审,讲解的时候比较麻烦。对case进行设计,可以按照用户的维度或者说是功能的维度进行考虑。例如涉及到字段逻辑的,列出来有哪些字
段,按照每一个字段的逻辑来书写case,这样讲解的时候会比较直观,同时后续接手的时候看起来也会比较清晰。51Testing软件测试网]3|F FK
zse,l vfIK;o0 当逻辑较少时,两者相差无几;但是逻辑字段较多,第二种用户维度的case设计就有了较大的优势,直观,能够为测试执行提供一个清晰思路,不会漏测,也不会做重复的无用功。51Testing软件测试网U
n4y+T&tD2Lw:U
,Q HQXQ2p:h7V0 二、软件测试用例的粒度51Testing软件测试网a$lr7B4K%q;a
51Testing软件测试网4hI8hkX
软件测试用例设计的粒度,是否应该包括测试数据的准备全过程。一个完整的测试用例,是需要包含测试数据的准备过程的。即测试用例图中,针对每一个功能
点,包含完整的数据流,可以完全按照测试用例的分支构造数据,而不需要别的文档辅助。但是这样会有一个问题,每一个分支只能覆盖一个功能,也就是说,每一
条测试数据,仅能够覆盖一个功能的分支,在测试执行方面会比较花时间。尤其是同一条数据,可以验证多个相似功能点,但由于测试用例设计中将多个相似功能的
区分开,执行时需要构造多条数据。测试的时间大部分花在重复构造数据阶段了。
2i-n(lQF'DmGO02M8}`.Cats9E0 对于比较复杂的逻辑,在设计软件测试用例的时候,可以有两
份,一份是很完整的包含测试数据准备的,每一条分支划分很细致的用例;另一份是用来测试执行的,将能够一次覆盖的多个分支合并到一起的用例,两个用例图互
相参照。对于测试人员的思维来说,是一个先分再合的过程,先将逻辑拆散,细化到每一个分支,再将相似或者相同的分支合并,这里面使用了等价类划分的测试执
行方法,即正常用例的时候,一次尽可能多的覆盖。51Testing软件测试网4~Xhm.Hv]
51Testing软件测试网M\B;f.s_ _ 三、软件测试用例传承
|/tdB(]k0YiO T+RV(W0 有的时候
看之前wiki的内容,虽然有软件测试用例图,但是看不太懂,接手的时候还是需要再问。如果需要在线上对逻辑进行验证,花的时间很多。从需求设计文档的文
字到测试用例的图形,是有一个归总的规程。每个人的思维不同,归纳整理的思路也是不同的。以后的业务逻辑整理到wiki的时候,能够在保留用例图的同时,
将文字的描述也写进去,同时写清冒烟的时候该怎么找验证。即wiki包含三部分内容,一部分是从数据源到输出结果,即需求设计文档描述的,经过软件测试人
员思维整理细化的文字描述;另一部分是从输出结果反推到数据源的过程,即根据输出,追溯到输入数据,验证输出是否是由输入数据经过规定的逻辑得来的;最后
一部分是测试用例图。这样后续接手会方便,冒烟的时候哪怕不了解这个业务的逻辑,按照wiki手把手的讲解,也可以顺利验证问题。
+Q9OLr\6P%X;R051Testing软件测试网$Qb%ArY5fB{OGJ 发现问题,找出办法,解决问题,是每一行每一个人想要进步的普遍定律。
#If4H'Mi]#AAJ0
收藏
举报
TAG: