海量测试用例如何优化:用状态矩阵解决有序操作的case爆炸问题

作者：网络转载发布时间：[ 2012/9/27 9:54:59 ] 推荐标签：

　　一、简介

　　我们在测试中可能都会面对case爆炸问题。有的case组合是无序的，我们可以通过pict[1]组合case，让pict成优化的case组合，在保证覆盖率的同时控制case数，这个方式在业界使用广泛，收效也不错。

　　但是对于有序操作的case爆炸，pict不能支持。目前没有很好的办法，总是让我们很伤脑筋。

　　本文从状态矩阵出发，讨论了用遍历状态矩阵、先生成所有case、再组合case的方法来解决有序操作的case爆炸问题。

　　二、基于ajax的网站测试遇到的问题

　　1. ajax简介[2]

　　有序操作的case爆炸问题在java scripts 测试或是应用ajax技术的产品测试中，尤为明显。

　　AJAX(Asynchronous JavaScript and XML)，异步 JavaScript 和XML，不是一种新的编程语言，而是一种用于创建更好更快以及交互性更强的Web应用程序的技术。

　　传统的web应用允许用户填写表单(form)，当提交表单时向web服务器发送一个请求。服务器接收并处理传来的表单，然後返回一个新的网页。这个做法浪费了许多带宽，因为在前後两个页面中的大部分HTML代码往往是相同的。由于每次应用的交互都需要向服务器发送请求，应用的响应时间依赖于服务器的响应时间。这导致了用户界面的响应比本地应用慢得多。

　　与此不同，AJAX应用可以仅向服务器发送并取回必需的数据，它使用SOAP或其它一些基于 XML的web service接口，并在客户端采用JavaScript处理来自服务器的响应。因为在服务器和浏览器之间交换的数据大量减少，结果我们能看到响应更快的应用。同时很多的处理工作可以在发出请求的客户端机器上完成，所以Web服务器的处理时间也减少了。

　　但应用ajax技术也面临着许多问题。无可避免的第一个问题即是浏览器的兼容性问题。各家浏览器对于JavaScript/DOM/CSS的支持总有部分不太相同或是有Bug，甚至同一浏览器的各个版本间对于JavaScript/DOM/CSS的支持也有可能部分不一样。这导致程序员在写 Ajax应用时花大部分的时间在调试浏览器的兼容性而非在应用程序本身。

　　Ajax技术之主要目的在于局部交换客户端及服务器之间的数据。如同传统之主从架构，无可避免的会有部分的业务逻辑会实现在客户端，或部分在客户端部分在服务器。由于业务逻辑可能分散在客户端及服务器，采用异步交互的方式，而javascript语言本身之能力可能不足以处理复杂的业务逻辑，这导致 Ajax应用程序极难维护。

　　2. 测试中遇到的问题

　　测试过java script的同学都知道，js有一些功能，单独验证时不会有问题，而将几个功能组合起来时，却很容易出现bug。一些bug可能需要3~4次操作才能够发现。

　　基于ajax的网站测试中，关于组合操作的测试设计通常依赖测试人员的经验和开发者的设计文档，将可能发生关联的case组合起来。测试执行时也加入一些 “随意测试”，即随意组合各种操作，以发现组合操作的问题。这个测试方法在较简单的场景中取得了一定的效果，可以用较小的投入发现问题。但随着网站的 ajax技术越来越复杂，更新越来越快，这样做可能存在一些问题：

　　1. 测试设计的覆盖率不能保证。只凭测试人员的经验，可能不能覆盖到大多数情况，容易漏掉一些分支。

　　2. 测试执行时的“随意测试”没有依据，测试效果可能因测试人员的不同或测试人员的状态而异。

　　因此，我们亟待解决的一对矛盾是：

　　 测试设计的覆盖率。

　　 测试case要在有限的范围内。

　　三、现成的解决方案?

　　想解决覆盖率和case爆炸的矛盾，目前了解到的解决办法有：

　　1. pict[1]

　　 优势：

　　有一些组合可能是我们不需要进行测试的。通过给组合间加入条件限制，pict可以自动生成需要测试的组合。通过pict的优化和筛选，case组合可以有效的减少。pict工具成熟，应用很广泛，取得了不错的效果。

　　 不足：

　　pict所处理的组合之间是无序的，也是说用pict得到的是一个“组合”而不是“排列”。有时候我们需要处理的是一个操作序列，例如 1-2-3、1-3-2、2-3-1 都是不一样的。而pict对这种顺序关系不能区分。