关闭

测试用例设计——如何提高测试覆盖率

发表于:2010-9-07 11:44

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:iamseaing    来源:51Testing软件测试博客

  2、功能切面隐含测试项用例设计:

  (1)、数据完整性的测试

  当某数据被其它功能引用;或当前功能要引用其它来源的数据,就会涉及到数据完整性的测试。最常见的如被引用的数据删除了,或关键字被修改了,引用的数据会否出错;两个途径进入的数据会否冲突或重复;此外还有因为相关的几个功能由不同人员编码,从而导致彼此的控制不一致,如A功能进入的数据在可允许的极端情况下,到B功能中引用会否异常(最常见如用户名录入时允许长度10,但引用到某个单子填写时允许长度是8,此时就会异常了)。

  (2)、后台的特殊处理

  是指某功能除了表面所见以外的程序处理。比如订单录入,表面所见的就是订单的保存,但后台还会有重复数据的判断、非法数据的处理、业务逻辑上冲突情况的处理以及其它种种根据需求设计所特有的处理。又比如备份功能,在备份前可能有数据的清空、备份目录的清空、备份目标是否存在的校验、备份文件重复时的处理等等。类似这些在分析设计中就未必会写全了,还是要测试人员多花心思去思考挖掘。

  (3)、功能业务之间的关联与转换

  相关联的几个功能之间数据的传递,会否产生影响。比如新增录入的某种特殊字符,要查询时会引起查询SQL语句异常;又如某下载文件名中存在中文等字符,下载时由于编码问题导致乱码的出现;再有报表填写时到小数点后四位,生成报文时会不会被忽略成两位了等等。象这种问题,通常只能是在每个功能设计用例时,尽量保证用例中的数据能涉及到允许范围的各种情况,即充分运用等价类划分+边界值的方法设计出各种“稀奇古怪”的数据,并需验证这些数据从头流到尾,都还是能保持其正确性,而不仅仅是在当前功能中正确。

  (4)、从设计实现发掘测试点

  这个就是我们测试中最难捉的BUG了,它往往是由编码人员自己在编码时创造出来的,连设计人员都不会知道。

  比如内部管理系统中,正常的产品,其类别通常是2位数字;如果是模块,其类别就以产品代码来取代。这时如何来判断该产品是模块呢?最保险的当然是校验其产品类别字段的值能否在产品表中找到;也有比较简单的方法就是直接判断类别代码大于2位还是小于等于2位。此时若能确切知道采用的是哪种实现方法,就可以直接找到其漏洞所在。比如采用后一种方法,当产品类别长度变化时,明显系统会出错。那么即使确认该实现方式不改,测试人员也应将其作为限制写入测试报告,。让大家知道这个产品类别长度是不能随意变化的。

  而让人郁闷的是,类似这样的实现,有太多的编码人员都是随性处理的,它们细而隐蔽,在系统数据正常情况下根本不会被发现;而在漫漫的软件使用道路中,由于需求变更等原因对原有一些设计做维护变化,这种问题就会突然暴发出来让人措不及防。所以要杜绝这类漏洞,除了测试人员要做土拨鼠,不停地对软件各功能的实现细节进行挖掘外,也要多给编码人员灌输完美实现的理念,多用复杂但抗压性高的代码,来替代简单但依赖性强的代码。

  (5)、并发操作时的测试

  即两个或多个用户同时操作同一功能时,会否引起数据的混乱。通常在C/S结构下,如果有同时操作的可能,是需要作此测试的;而在B/S结构下由于其特殊性,此问题通常难以解决。除非就是某用户一旦使用过某功能后,在一定时间内锁定不允许再用,但这也会带来实际应用中的不便,所以除非是特别核心的数据,一般我们也不会去做此控制,当然对于可能出现的并发冲突也就作为系统的限制进行遗留了。

  3、特定切面用例设计

  所谓特定切面,其实就是从另一个角度切割出来的用例面,所以具体的用例撰写方式其实与功能切面是一致的。

  4、隐含切面用例设计

  隐含切面分以下几种情况:

  (1)、无界面的后台功能

  对这类测试项,需要通过参数设置、代码调用等方式来实现测试,但具体的测试设计其实与普通功能测试并无二致。这里要注意,因为测试时往往前台、后台是分开来分别进行的,而实际运行时两者很可能是交集的,所以测试时要多注意后台功能的执行与前台的一些功能执行会否产生冲突?比如后台有个文件搬运的服务,那有没有可能在前台文件生成过程中,后台执行文件搬运了?若有可能就要注意会否出现问题了。

  (2)、与业务流相关的测试

  这类测试用例的设计,就要从完整业务角度来设计数据了。从理论上来讲,应该要将各个功能可能出现的各种数据排列组合到一起,按业务流程逐一进行测试。但实际上我们不可能去做全覆盖。所以设计这类用例时,最好有一张草稿,将所有相关功能按业务流程逐一列示,然后再将每个功能可能出现的特定数据一一标上,最后将图中最可能出现的、最可能出错的、最核心的数据取出来,分别组合成一个个完整的业务数据用例,来进行测试。这样就可以按清晰的思路,找出最实用、最有效的测试数据。

  (3)、其它测试类型

  这一类的测试通常都有其特定的方法。如要测可靠性就准备大量数据不停地执行;要测安全性就考虑数据的加密、数据的传输、数据的破坏;恢复性一般从网络、电源方面着手;配置安装则根据系统可支持的配置,搭建相应环境进行功能验证,此处的验证也要掌握技巧,即要多测试那些涉及到:数据库读写、磁盘文件读写、文件上传下载、文件加解密、数据统计、图表展现、打印等方面的功能。

43/4<1234>
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • 754354300
    2015-3-30 10:14:22

    已学习,多谢楼主

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号