多测师-多培养一些优秀的测试工程师
网站地图 |   收藏本站   |   

17727591462

软件测试培训之功能切面隐含测试项用例设计

发布日期:2022-09-30 09:28:00 作者:多测师 浏览次数:

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

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

  (2)、后台的特殊处理

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

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

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

软件测试培训之功能切面隐含测试项用例设计

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

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

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

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

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

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

如需了解更多测试技术信息请关注:https://www.duoceshi.cn/jswz/深圳多测师软件与技术服务有限公司


查看更多 >>

推荐阅读