软件测试套件维护

软件测试套件维护 软件测试工具

 可能我们大多数人都不理解的是，一套自动化测试工具实际上就是一个软件系统，它本身也面临与它所测试的系统一样的问题。它很容易发生错误，尤其对变化非常敏感。所以，无论什么时候，当使用自动化测试脚本测试客户机一服务器系统时，实际上都是在处理两个需要维护的系统。这就使维护问题增加了一倍。

    我曾与一个VB程序员一起工作，他以前曾经为一个客户机一服务器系统梅建并维护过一套自动化测试用例。他面临的问题是性能永远不会不变，为了赶上所有的变化，他需要不断更新测试脚本。当然．他从投有赶上过。因此他发誓他再也不做测试了!f

    Steve Fuchs，微软Te吼的负责人(微软Test现在是Ratbl】al S0ft啪re公司的软件开发和测试产品知识库中的一个组件)认为主要测试工具的宏记录器功能导致了许多维护问题．因为测试人员可能会假设几件事情[1]：

    1)软件产品在其生命周期中会发生改变。

    2)如果这个产品成功了，那就会在其他语言中被复制。

    3)产品的下一个版本将有更好的用户界面。

    4)测试一个产品的后续版本将花费更少时间。

    他不同意一部分测试人员关于产品改变将导致脚本中包括无效事件的假设。他认为隔离并重新记录脚本中的那些部分内容的工作量是相当大的。他甚至更进一步认为，脚本将包含非常少的有关事件的上下文信息，这使得维护更加困难，而且脚本将包括许多硬编码的函数调用，对于这些调用来说，即使是很小的用户界面改变也需要广泛地对脚本进行更新。对于这一点他做了个总结，即使是简单的改变也能影响50％～90％的测试用例[2]。   

Fuchs的论点是有效的，因为新的系统发布确实影响了自动化测试套件毒当系统新版本中任何竹夼系统级(界面级、数据级或功能级)发生了改变时，被记录的测试程序最可能需要更新。可以这么考虑这件事：当我们改变一个软件模块时，我们必须询问这种改变影响了其他哪些模块，那么现在当我们改变卞个软件模块时．我们同样必须询问这样的改变将会影响哪些测试脚本。自动化溅试套件在自身系统上增加了新的约束。JamesBach(在LISENEq、新闻组，d)mp．s。ftw眦．t哦m喀)说：“从脚本构建的自动化系统非常复杂，难于维护。越复杂的系统就越可能失败。”[1]这也就是说测试用例本身就容易产生错误。那么我们该做什么呢——编写测试脚本来测试测试脚本吗?

    另一个问题是软件和／或硬件平台改变所造成的影响。Bach再一次说到：“这个平台的任何改变都会引起测试自动化的大范围失败，除非这个改变被明确预见到”。在进行DOS升级和向悄avdl网转变时，Bach经历过一些阻碍测试自动化方面的问题。为了使自动化测试能够工作，他不得不在其中加人一些与平台相关的额外处理。他发觋就是极微小的配置差异也会使自动化测试套件失败。

    抱着对自动化测试工具的销售商公平些舳态度说来，我们必须承认他们白孽产品从产生起已经有了很大的进步。导致早期测试套件失败的许多条件现在能够被捕获到并写入日志，而测试可以继续进行。所以说，测试套件比先前更健壮了。    、一条重要的建议是使用大量的注释，在复杂测试程序脚本的开始插人一条注释头。还有就是使用类似cyrai'K)的产品为测试套件存档。

原文转自：http://www.ltesting.net