功能测试实战【一】动态可维护数据源应用测试

没有如果

【引子】：

    想写个系列的帖子，既然是系列的，就想弄个引子，于是就有了这个引子。

    目前市面上较容易找到的教我们测试的书籍大多是测试理论，讲到方法也大多是等价类、边界值......我想写一个系列的实战经验，都是自己几年干活下来，总结出的一点东西。一个有经验的测试人员我相信看到一个系统，只要了解一下功能，看到界面脑袋里面就能冒出来一堆测试思路；而新人往往不知从何下手。

    我希望我写的东西达到2个目的：
    可以和老鸟们交流一下，我的思路能给大家一点启发我将荣幸之至，同时更希望有哪位仁兄（仁姐）能给我更多的指点，叫小弟也有所提高。
    可以叫新鸟看了之后，再次拿到一个系统，了解了功能之后，容易设计测试用例。

    我会每天讨论一个软件应用的技术或表单或只是一个小的输入框（可能几天说一个大的），然后陈述对这种应用的理解（发扬百度精神加个人理解），然后阐述自己的测试思路，网上找到的测试思路，还会维护跟帖的兄弟阐述的思路（会注明引用的哦）。

    废话就这些吧，进入正文。


【一】动态可维护数据源应用测试

      我们在测试软件时经常遇到这样一种程序应用：多个表单中的下拉列表或数据选择页面，读取的是一个数据源。这个数据源是一个可维护，会变化的列表，有些数据源的维护是由单独的，指定的模块来完成的，有些是由多个功能页面共同维护的。
   
    这种应用设计的好处在于可以统一管理数据源，实现数据源的管理和使用分开进行，方便分工和统一更新。

    我们姑且给软件中应用这种形式命名为“动态可维护数据源应用”【我起的名字，有知道这个明确定义的板砖我然后不吝赐教】。


    在进行此类应用的测试中，我的测试思路主要由以下几个方向：

    1、当数据源发生变更时，即对数据源中数据进行增、删、改操作，引用数据源的表单再次使用时，是否正确更新，同步显示数据源的变化情况。

    2、当数据源中删除记录时，已经引用了被删除数据的信息是否能够正确处理，我们经常遇到的一种情况是，引用了这个数据的记录，对应字段显示为null。
    有经验的开发设置人员，在设计数据源的删除功能时，应该考虑到此问题，一般采用假删除来规避这个问题。

    3、当数据源中修改记录时，已经引用了被删除数据的信息，是否应该更新为修改后的记录。我认为，这个是否应该更新，应该取决于需求定义，如果定义需要更新，则测试应该关注必须更新。如果需求定义不更新，则此处同样应该注意，是否保持原数据值（一般开发在这种情况，正确的做法应该是设置成读取数据源后另存数据）。

   4、有些数据源的维护是多个入口，我们要检查各个入口的控制是否统一。例如一个程序，在填写表单时，如果下拉列表中没有合适数据（这个下拉列表应用的就是这种技术），可以用户自定义添加，添加后的信息会自动维护到数据源中。数据源该字段的控制只允许输入字母，而下拉列表处的控制却可以输入汉字或特殊字符，这样下拉列表维护进的数据就可能成为整个数据源的脏数据。

    5、数据源维护是为了引用，而不同表单引用相同数据源可能会进行一些过滤。我们需要验证数据源维护后，是否对应表单能够正确过滤，尤其是将数据修改，从符合A条件，修改为符合B条件时，是否该数据项不再在A表单中显示，并能在B表单中显示。



    暂时想到这些，想到新的再补充。

shx-2001

我补充了几点：
1）考虑数据源的排序，与应用数据源的排序是否一致
2）当数据源中无任何数据时，应用数据源控件是什么情况
3）数据源字段的度是否与应用数据源长度一致

你看我笑

楼主，测试思路的第二点，不太明白假删除是什么意思，求解释

wallffpp

我觉得测试思路不应脱离需求。楼主想到的这些东西其实都应该是在需求中有体现的，需求中没体现的也就是不需要考虑的了。例如用户认为脏数据不影响使用，那么这个功能点就不应测试。当然测试人员可以根据经验给用户提出建议，但这通常应该在需求阶段进行。到了系统测试阶段再返回来做这些事情很容易在体制上导致混乱。测试的基本工作就是仔细的阅读需求，正规的按照等价类划分、边界值分析、场景法、因果图之类的方法进行用例设计，基本上就不会有遗漏了。当然某一种软件的测试经验丰富了也可以使用错误推测法。但基本的原则还是依托需求，使用正规的测试用例设计方法。不能东一榔头西一棒槌，这样很容易遗漏测试点。

楠族开心果

很好的文章

a5914361

主要应该考虑关联数据操作

a5914361

主要应该考虑关联数据操作后有什么反应

3396408

楼主加油，期待你得作品