功能测试或集成测试是关系到整体系统功能的测试，而不只是牵涉到小段代码（单元）。这需要将已经单独测试好的模块组装起来，以保证其连接时也能像预期一样正常工作。JUnit是进行Java程序测试常用的测试框架。
大多数Java开发人员都善于解决逻辑结构测试问题，比如如何建立测试预设环境、利用断言？添加测试方法、用setup方法进行初始化等。然而，如果Java开发人员能更深入地了解如何设计功能测试集来有效地检验代码是否正常运行，他们将获得更多的益处。
这篇文章介绍了可以建立有效JUnit功能测试集的策略。包括：
确定测试用例覆盖所有程序行为。
确定代码入口点：测试程序整体功能的主要代码段。
匹配入口点与相应的测试用例。
根据初始化/运行/检查流程创建测试用例。
设计并利用运行时事件表进行测试。
我将结合Saxon（一个可以处理XPath、XQuery和XSLT的XML工具）的源代码来具体阐述这些策略。Saxon由约50000行Java代码组成，它是开源的，代码风格优良，注释文档详尽。
确定用例
功能测试有两个相辅的目标：覆盖率与粒度。为确保完整性，功能测试必须覆盖程序提供的所有功能，且必须在各组件水平上分别进行测试。一个测试可以建立在另一个测试的基础上，但任何测试都不能用来验证两项功能。
建立一个全面的功能测试集，第一步是列出程序可以实现的所有行为。这可以通过使用特定的用例模拟外部因素（程序使用者或其它软组件）执行系统内部的功能来实现。
一个典型的企业Java程序应该包含各种用户所需的详细文档，包括用例说明、非功能性要求、测试用例说明、用户界面设计文档、模型、用户个人信息以及其它各种人工生成的信息。一般来说简单的应用程序只有一个简单的说明文档。
借助这些文档，你可以快速确定需要测试的用例。每个测试用例都描述了应用程序可以执行的一项功能。用规模相近的测试方案确定的功能是一个好习惯，而较大的方案可以根据其检验的功能拆分为较小的方案。
有许多种建立用例模型的方法，其中简单的便是输入/输出匹配法。在Saxon的query类中，简单的用例是传送一个查询文件、一个查询请求和一个输出文件路径。输出文件若不存在，将根据要求创建，并在文件中显示查询结果。
更复杂的用例可能需要输入更多的信息或输出更多的结果。然而，用例并不关心功能是如何在内部实现的。对它们来说，软件像是一个“黑盒子”，只要运行正常，即使真正实现软件功能的是盒子里的侏儒也无所谓。这是很重要的一点，因为输入/输出匹配用例很容易直接转换为测试用例，使得复杂的说明与简单的测试吻合，确定该运行的功能正常运行，而不该运行的功能如预期一样失效。
如果类相对比较简单，或者已有列举类所有功能的说明文档，为指定入口点描述用例将很容易。如果不是这样，或许需要研究类可能有的所有行为（确定类的目的与用法）。如果你想知道所有调用代码的地方，也可以从代码中提取用例。
可能的情况是，根据开发人员提供的类的一些基本说明文档，可以完全确定这些类应有和不应有的行为。基于此，设计一套准确的用例集。
转换测试用例
每个测试用例都由两部分组成：输入和预期输出。输入部分包括所有创建变量或为变量赋值的测试用例语句。预期输出部分则表明应该得到的输出结果，它应该显示断言成立或“没有异常”（不存在断言语句时）这样的信息。
基本的输入/输出模式是理解测试用例模型简单易用的办法。它采用一般函数（传递参数，获取返回值）和大多数用户行为（按某个键实现某项功能）惯用的模式。然后，可以用该模式进行：
初始化：建立测试预设环境。代码初始化可以在测试开始时进行或通过调用setUp()方法实现。
运行：调用被测试的代码，记录所有值得注意的输出和数据。
检查：使用断言语句确保代码正常运行。
举例来说，假设要测试Saxon库的转换类入口点。其中一个用例是将XML文件转换为HTML文件，当然前提是已有描述这个转换的XSL文件。输入这三个文件的路径，应该输出HTML文件的内容。这可以直接转为下面的测试：
public void testXSLTransformation() {
/* initialize the variables
(or do this in setUp if used in many tests) */
String processMePath = "/path/to/file.xml";
String stylesheetPath = "/path/to/stylesheet.xsl";
String outputFilePath = "/path/to/output.xml";
//do the work
Transform.main(new String[] {
processMePath，
stylesheetPath，
"-o"， outputFilePath } );
//check the work
assertTrue(checkOutputFile(outputFilePath));
}
每一步都可以根据需要进行增减。这里声明的变量也可以简单地通过调用方法来赋值。预期输出的实现是由几个步骤组成。如果成功得到预期输出，有时可以省略检查步骤。
虽然这个模式简单且灵活可变，但是第二步必不可少。这个模板没有告诉我们寻找要测试代码的方法，也不能保证代码以方便测试的方式运行。这是个需要认真考虑的问题。
功能测试
通过确定执行程序功能的主要代码段，可以将测试建立在一个更有效的环境下。由于这些类提供了从系统外部进行测试的途径，所以也是代码的入口点。
因此，功能测试的整体目标是确定一组可以访问系统功能的高层接口类。这些类的独立性越高越好。毕竟，如果能将类从环境中分离出来，测试起来会更加容易。
确定作为入口点的代码是一个简单的过程。在代码库中，通常有几个控制该库所有功能的入口点。这些外部类作为客户端代码，与库的中介对象将开发人员从复杂的代码分析中解脱出来。这些便是应当首先对其方法进行测试的类。
比如，Saxon有一小组类作为逻辑入口点提供对库的访问。通过对外部类进行编码操作，比如转换、设置和查询，客户端代码可以访问库的许多功能类，而无需考虑类的接口问题，甚至无需担心这些类是否存在。这些外部类用高层易用的接口提供一个简单的方式对系统功能进行测试，这正是一个优良的库的特征。
程序代码中的各个功能模块通常是各自独立的。在某些代码中，甚至可以认为这些模块各自对应不同的、可通过大量外部类访问的库。这些类查找高层接口的逻辑位置。插件结构通常都采用这种设计模式：每个插件程序都有一个可以有效执行内部代码全部功能的简单接口。
在一些非严格描述的系统中，通常有一个所有程序行为的中介点。在MVC架构中，这个中介类一般作为“控制器”，负责配置系统各部分的请求路由。整体系统的功能主要由这个控制器连接的类实现，因此，这些类是测试的主要对象。
比如在Applet程序设计中，java.applet.Applet的派生类是所有代码的中心处理单元。根据代码的分解程度，测试焦点可以放在Applet子类或与其连接的类上。
连接各个模块的代码也是测试的主要对象。将应用程序请求转换为数据库查询的类，以及有相似功能的适配类是其次应该考虑的测试对象。
各种基于MVC（模式-视图-控制器）架构的组件可以用其它的测试框架（比如Junit的扩展）进行测试。例如，Struts的action类好使用JUnit的扩展StrutsTestCase进行测试；服务器端的组件（如Servlets、JSP和EJB）好用Catus进行测试；而HttpUnit则是对Web应用程序进行黑盒测试的好框架。本文讨论的所有技术都可应用于这些框架环境下的测试。
