测试驱动的开发——概述(2)

　　第二个进行web应用自动测试的主要方法就是通过编程API。这样你就有了测试框架，软件库可以检查条件是否满足，报告错误的数量和类型，你可以在测试代码中调用这个框架。你的测试代码就是继承自测试框架的一套类，它们从应用代码中初始化对象，调用方法来验证给定输入会得到预期的结果。采用编程API方案的包括JUnit、HttpUnit、各种单元测试和黑盒web测试的工具等等。这种方案非常灵活，大多数情况下它大大减少了测试代码的维护时间，并且使应用中的复杂功能测试成为可能，尤其是服务器端应用。这种测试可交替的调用 programmatic testing，API-driven testing，或者programmatic API-driven testing。

　　相对于recorded macros模式来说，基于API的自动测试方法的第一个弱点是它的需要更长创建时间。当你的问题是鼠标移动和点击时很难减少设置时间。第二个问题是绝大多数客户不会写测试程序的。客户了解的是业务过程，而不是技术，客户可能觉得移动鼠标和点击鼠标容易得多，这一点非常重要，如果你想让客户在开发过程中就参与进来的话，客户参与是极限编程的鼓吹者推荐的方法。

　　虽然如此，基于API的方法在许多方面存在着优越性，可以在大多数应用中使用，因为应用程序随时间改变的程序非常大，所以花在测试程序维护上的时间比测试程序的创建时间占的比例更大。而且recorded macro方法有一个致命限制：只有在应用代码写完之后你才能建立测试。如果你们的开发习惯是不在程序完成前测试，那非常好。否则，如果你坚持测试先行的习惯，正如作者推荐的，那非常不幸recorded macros不适合你，因为在记录宏进行重放之前，你必须有一个能运行的应用程序。

　　好的方案可能既有recorded macros测试，又有基于API的程序化测试。通过鼠标拖点式测试你可以让最终用户参与到测试中来，保证你的程序满足业务需求。通过程序化测试则可以在技术角度确保程序组件按预计的情况工作。

　　使用程序化测试，你有两种选择：功能测试和单元测试。功能测试也叫做黑盒测试，是指在不知道(或者忽略)内部实现的情况下，在一个较高的层次上进行测试。功能测试用于验证程序是否完成业务需求，它模拟采用与最终用户一致的方式与程序进行交互。最终用户可能是使用基于web应用的业务人员，也可能是通过你所提供的API来使用你的类库的开发人员。如果你一定要纠缠概念，功能测试和黑盒测试还是有一些区别的，因为技术上功能测试可以在容器内进行(如果要测得是web程序的话)，但实际上绝大多数功能测试是在黑盒中做，除了公布的接口外你一无所知。相反，单元测试包括底层代码的验证，为了对确保内部组件没有问题，必须了解程序的内部结构。你还需要知道那些类和方法的实现。如果要测的程序是给开发人员使用的软件库，你的单元测试包括所有重要的类和方法，甚至在发布给用户的API文档中没有列出的内容。功能测试与程序交互的方式是通过点击按钮和信息入口，进入程序可见的forms。单元测试与程序的交互是通过Java方法调用来访问。

　　对前面提到的手工测试的四个缺陷，自动测试都给出了很好的解决：

　　排除重复。用自动测试你可以把这项工作交给计算机去办，它们将严格按照你每次测试的流程进行操作。

　　减少错误。计算机每次都用同样的方式执行重复操作。而且，因为测试是cumulative，而且容易调用，即使某一些代码修改在直接影响范围之外很远的地方造成破坏，你仍然能找到这个错误，因为你以前写的检查那些(被破坏的部分)代码的测试会告诉你。自动测试的cumulative是一个非常有用的特点，也是相对手工测试来说一个重要的优点。用手工测试来检查程序的其它部分是不切实际的。

　　允许组件的独立测试。自动测试，至少其中的基于API的程序化方式，可以让你测试程序的不可视部分，例如你认为是程序核心的业务逻辑。编程测试在其它程序(测试代码)中调用你的代码。粒度由你自己把握。如果不考虑程序的任何内部实现，你可以模拟一个 web浏览器或者使用鼠标操作桌面的用户，进行黑盒或功能测试。你也可以调用类库德公共API，因为你不考虑API内部的实现，这也可以算作一种黑盒或功能测试。你还可以调用隐藏类或公共类的内部方法，来验证它们按你想的方式工作，因为针对的是独立的方法和类，而且你会知道算法等内部实现细节，这就是单元测试。你要做什么测试，就选择什么级别的细节。

原文转自：http://www.uml.org.cn/Test/200911101.asp