ITPub博客

首页 > 数字化转型 > ERP > 软件测试工作中对问题的发现和改进

软件测试工作中对问题的发现和改进

原创 ERP 作者:shbwf 时间:2012-08-17 13:51:31 0 删除 编辑

  软件测试并不是一项一成不变的工作,南京达内提醒大家要善于发现软件测试中存在的一些问题,通过不断改进的测试方法来让自己进步。

  一、软件测试用例设计的不同维度

  软件测试用例设计的时候,可以有不同的维度来考虑。一般来说,是按照开发的流程和数据的准备过程设计的测试用例。由于逻辑较多、数据流较复杂,造成用例图很大,分支很多。进行case评审,讲解的时候比较麻烦。对case进行设计,可以按照用户的维度或者说是功能的维度进行考虑。例如涉及到字段逻辑的,列出来有哪些字段,按照每一个字段的逻辑来书写case,这样讲解的时候会比较直观,同时后续接手的时候看起来也会比较清晰。

  当逻辑较少时,两者相差无几;但是逻辑字段较多,第二种用户维度的case设计就有了较大的优势,直观,能够为测试执行提供一个清晰思路,不会漏测,也不会做重复的无用功。

  二、软件测试用例的粒度

  软件测试用例设计的粒度,是否应该包括测试数据的准备全过程。一个完整的测试用例,是需要包含测试数据的准备过程的。即测试用例图中,针对每一个功能点,包含完整的数据流,可以完全按照测试用例的分支构造数据,而不需要别的文档辅助。但是这样会有一个问题,每一个分支只能覆盖一个功能,也就是说,每一条测试数据,仅能够覆盖一个功能的分支,在测试执行方面会比较花时间。尤其是同一条数据,可以验证多个相似功能点,但由于测试用例设计中将多个相似功能的区分开,执行时需要构造多条数据。测试的时间大部分花在重复构造数据阶段了。

  对于比较复杂的逻辑,在设计软件测试用例的时候,可以有两份,一份是很完整的包含测试数据准备的,每一条分支划分很细致的用例;另一份是用来测试执行的,将能够一次覆盖的多个分支合并到一起的用例,两个用例图互相参照。对于测试人员的思维来说,是一个先分再合的过程,先将逻辑拆散,细化到每一个分支,再将相似或者相同的分支合并,这里面使用了等价类划分的测试执行方法,即正常用例的时候,一次尽可能多的覆盖。

  三、软件测试用例传承

  有的时候看之前wiki的内容,虽然有软件测试用例图,但是看不太懂,接手的时候还是需要再问。如果需要在线上对逻辑进行验证,花的时间很多。从需求设计文档的文字到测试用例的图形,是有一个归总的规程。每个人的思维不同,归纳整理的思路也是不同的。以后的业务逻辑整理到wiki的时候,能够在保留用例图的同时,将文字的描述也写进去,同时写清冒烟的时候该怎么找验证。即wiki包含三部分内容,一部分是从数据源到输出结果,即需求设计文档描述的,经过软件测试人员思维整理细化的文字描述;另一部分是从输出结果反推到数据源的过程,即根据输出,追溯到输入数据,验证输出是否是由输入数据经过规定的逻辑得来的;最后一部分是测试用例图。这样后续接手会方便,冒烟的时候哪怕不了解这个业务的逻辑,按照wiki手把手的讲解,也可以顺利验证问题。

  发现问题,找出办法,解决问题,是每一行每一个人想要进步的普遍定律。

本文转载自51Testing软件测试网,查看更多:http://www.51testing.com/html/news.html

[@more@]

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/11323760/viewspace-1059204/,如需转载,请注明出处,否则将追究法律责任。

全部评论

注册时间:2009-04-24

  • 博文量
    255
  • 访问量
    2399904