|
【引子】:
想写个系列的帖子,既然是系列的,就想弄个引子,于是就有了这个引子。
目前市面上较容易找到的教我们测试的书籍大多是测试理论,讲到方法也大多是等价类、边界值......我想写一个系列的实战经验,都是自己几年干活下来,总结出的一点东西。一个有经验的测试人员我相信看到一个系统,只要了解一下功能,看到界面脑袋里面就能冒出来一堆测试思路;而新人往往不知从何下手。
我希望我写的东西达到2个目的:
可以和老鸟们交流一下,我的思路能给大家一点启发我将荣幸之至,同时更希望有哪位仁兄(仁姐)能给我更多的指点,叫小弟也有所提高。
可以叫新鸟看了之后,再次拿到一个系统,了解了功能之后,容易设计测试用例。
我会每天讨论一个软件应用的技术或表单或只是一个小的输入框(可能几天说一个大的),然后陈述对这种应用的理解(发扬百度精神加个人理解),然后阐述自己的测试思路,网上找到的测试思路,还会维护跟帖的兄弟阐述的思路(会注明引用的哦)。
废话就这些吧,进入正文。
【一】动态可维护数据源应用测试
我们在测试软件时经常遇到这样一种程序应用:多个表单中的下拉列表或数据选择页面,读取的是一个数据源。这个数据源是一个可维护,会变化的列表,有些数据源的维护是由单独的,指定的模块来完成的,有些是由多个功能页面共同维护的。
这种应用设计的好处在于可以统一管理数据源,实现数据源的管理和使用分开进行,方便分工和统一更新。
我们姑且给软件中应用这种形式命名为“动态可维护数据源应用”【我起的名字,有知道这个明确定义的板砖我然后不吝赐教】。
在进行此类应用的测试中,我的测试思路主要由以下几个方向:
1、当数据源发生变更时,即对数据源中数据进行增、删、改操作,引用数据源的表单再次使用时,是否正确更新,同步显示数据源的变化情况。
2、当数据源中删除记录时,已经引用了被删除数据的信息是否能够正确处理,我们经常遇到的一种情况是,引用了这个数据的记录,对应字段显示为null。
有经验的开发设置人员,在设计数据源的删除功能时,应该考虑到此问题,一般采用假删除来规避这个问题。
3、当数据源中修改记录时,已经引用了被删除数据的信息,是否应该更新为修改后的记录。我认为,这个是否应该更新,应该取决于需求定义,如果定义需要更新,则测试应该关注必须更新。如果需求定义不更新,则此处同样应该注意,是否保持原数据值(一般开发在这种情况,正确的做法应该是设置成读取数据源后另存数据)。
4、有些数据源的维护是多个入口,我们要检查各个入口的控制是否统一。例如一个程序,在填写表单时,如果下拉列表中没有合适数据(这个下拉列表应用的就是这种技术),可以用户自定义添加,添加后的信息会自动维护到数据源中。数据源该字段的控制只允许输入字母,而下拉列表处的控制却可以输入汉字或特殊字符,这样下拉列表维护进的数据就可能成为整个数据源的脏数据。
5、数据源维护是为了引用,而不同表单引用相同数据源可能会进行一些过滤。我们需要验证数据源维护后,是否对应表单能够正确过滤,尤其是将数据修改,从符合A条件,修改为符合B条件时,是否该数据项不再在A表单中显示,并能在B表单中显示。
暂时想到这些,想到新的再补充。 |
|