大多数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));
}
每一步都可以根据需要进行增减。这里声明的变量也可以简单地通过调用方法来赋值。预期输出的实现是由几个步骤组成。如果成功得到预期输出，有时可以省略检查步骤。
虽然这个模式简单且灵活可变，但是第二步必不可少。这个模板没有告诉我们寻找要测试代码的方法，也不能保证代码以方便测试的方式运行。这是个需要认真考虑的问题。
文章来源于领测软件测试网 https://www.ltesting.net/