从用例到测试用例
 
        每个入口点都必须与相应的用例匹配。某些情况下可以忽视这一步，因为类名的自记录可以实现自动匹配，比如Saxon中的转换类可以实现XSL转换，查询类可以进行XQuery转换。
        其它情况则要复杂得多。通常用例描述的功能只能以横切关注点的方式存在，不能用任何单独的类进行例证。只有几组类交互时或满足一定条件时，才能观察到功能行为。这种情况下，测试的初始化程序会比较长，或者可以用setUp()方法提供需要的测试环境。
        而调用代码的运行程序应该尽可能地设计成一行，以减少与被测试代码的关联，这可以有效避免对边缘效应与不稳定实现细节的依赖。测试的检查阶段是复杂的，因为这个阶段经常需要添写非测试用代码。测试时可能需要对结果进行严格的分析以确保其符合要求。有时甚至需要将这个过程分为几步来完成，以取得测试可以识别的结果。在XSL转换中，这两种情况都是可能的，结果储存在文件中，然后以XML格式读入内存并进行准确性分析。

        Saxon中有个相对简单的例子。已有XML文件和XPath表达式的情况下，Saxon可以执行表达式并返回匹配列表。Saxon中的XpathExample样本类是用来执行这种任务的。基于以上分析，可以设计如下的测试流程：

    public void testXPathEvaluation() {
      //initialize
      XPathEvaluator xpe = new XPathEvaluator(
        new SAXSource(new InputSource("/path/to/file.xml")));
      XPathExpression findLine =
        xpe.createExpression("/some/xpath[expression]");
      //work
      List matches = findLine.evaluate();
      //check
      assertTrue(matches.count() > 0);
    }

        两次输入的都是字符串常量，输出的则是所匹配的列表，可以用来验证匹配结果的正确性。这些工作都由一行代码完成，这行代码只是简单地调用了被测试的方法。
        另一种可能的情况是XPathEvaluator没有调用createExpression()方法。因为表达式不存在，这时可能会显示错误信息。
        将输入的源文件名和表达式保留在测试用例中不是个好习惯。某些项目（服务器名、用户名和密码等）不应该出现在测试文件中，它们应该可以根据情况自由设置。并且，测试用例的设计应该方便测试驱动和测试数据的分离、测试驱动对大范围数据的可重用性和测试数据对测试驱动的可重用性。另一方面，不要将一个简单的测试用例实现设计地过于复杂。一般来说，测试用例已经说明了系统的大部分状态，并可对其进行参数描述，所以无需在测试中进行过于详细的参数描述。
        许多代码段可能出现在不止一个测试用例中。有经验的面向对象开发人员会尝试对其进行重构并创建通用类和有效方法。有时候这样做非常有用，比如登录过程应该设计成所有测试用例可用的方法。 但是，不要过度设计测试，这些Java类仅仅是用来验证应用程序的功能行为而已。

        测试用例是脆弱的。比如，如果开发人员更改了testXPathEvaluation测试中输入文件的位置，或者creatExpression方法签名有所变动，测试脚本会失效。
        对于应用程序的测试用例实现来说，大量的重复性工作与改动是不可避免的。因此，可跟踪性对于所有的测试用例都是至关紧要的。出现问题的时候，如果能为开发人员指出相应的测试用例说明和用例说明将有利于提高修正bug的速度。
        因此，测试用例注释中应标明原始说明文档的引用位置。这可以是一个简单的代码注释，也可以对每条测试都注释相关用例和所测功能，这样当测试出现问题时开发人员会收到一条相关信息。因此，在代码中加入参考并维护可追踪性是很重要的。

设计运行时事件表
 
        要了解测试覆盖的范围，必须先了解所测试代码如何运行，以及各种静态类如何形成描述程序状态的动态对象图表。
        有许多模拟这种行为的方法，包括Granovetter图和物件互动图。其基本思想是用图形化的方式研究代码以了解测试中涉及到的运行时部分。这些技术都可用运行时事件表（Runtime Event Diagrams）来描述，因为这些图表显示了程序运行时发生的事件，而非理论上类可以控制的事件。这些图表非常重要的原因包括：
        首先，这些图表便于从高层上理解代码，并提供有用的说明文档。这个文档与代码的内联文档不同。这些图表显示代码的运行时表现，是产生代码功能的地方，也易于对系统的了解；大多数设计模式和架构在用对象和参考表示时要比用类和域表示容易得多。
        另外，这些图表将测试执行的代码分类列表，并确定测试是否会受到将来对任意代码改动的影响。如果开发人员确定测试A是建立在B、C和D的基础上，她可以确定如果对B、C或D做出改动需要对A进行重新测试（确保向后兼容）。
        以尽可能少的步骤模拟系统是个好方法。总的来说，实际调用与此无关，重要的是系统如何作为整体运作以获得预期目标。可以用简化的模拟系统实现这个目的，该系统只关心对象间的基本交互，并用自然语言描述交互中发生的事件。
        做出运行时事件表后，可以将其整合到类文档中。需要注意的是，为表添加一些限制可使其对类的修改更有弹性。首先，一般不能使用方法名，因为它们会随时间发生变化。取而代之的是更易理解的自然语言描述。其次，这些图表主要是关于系统中各部分的交互。这是高层架构上的设计方案，一般不会再做改动。后，图表是建立在类型而非特定类的基础上。只要基本类型不变，为维持交互协议的正常运行，这些图表不需要更新。
        一旦图表创建成功，可以在许多方面获得应用。比如，一个图表可以用来获取系统如何运作，以及如何运用其交互部件实现功能的概览。在某种程度上这是一种简化了的UML语言，它只描述关系到整体功能的系统部件：实例及其类型、其它引用的实例，以及组件可以实现的功能。
        这些图表也可以用来分析系统的复杂性以及如何进行简化。要确定简化系统的方法，可以查找系统中使用过一到两次的对象，并为其寻找其它可能更合适的位置。也可以查找重复的任务，将其封装到方法或类中。
        然而，重要的是图表在测试中的应用。通过对系统状态的总结，图表可以帮助解决系统中出现的问题。出现问题时，图表中的信息便可用作参考。因为只需要将系统目前状态与预期状态作比较即可，这样确定问题产生的原因也变得比较简单了。对小组件的改动不应该影响整体架构，因此可以通过对照运行时事件表以保证系统仍然正常运行。并且，当有重要组件发生变动时，可以用运行时事件表对照系统当前状态以获取系统修正方案。由于将系统作为整体和对预期功能的描述，运行时事件表也可以看作是一种结构化的单元测试。如果系统有变动，可以更容易地做出修正以维持系统的正常功能。
        如果经常因细节问题影响对全局的把握，应该使用图表。其高层本质可以用来分析软件的设计模式，像反模式一样。还有许多其它用途，并且当运行时事件表、测试用例说明和用例说明没有描述所需的细节时，它还提供了直接进行代码分析的路线图。

利用功能测试进行回归测试
 
        后，为回报你在功能测试上做出的努力，配置一个与自动生成的程序相应的自动化测试程序。这个程序不只从功能上测试代码，还可以同时进行常规的回归测试。现在大多开发项目都建立在庞大的代码库基础上，如果不能对代码库进行充分测试，开发团队将无从决定对程序的修正是否会破坏现有的功能，结果是很难对这种代码进行扩展或优化。与此相反，如果开发人员可以在全面的功能测试基础上进行回归测试，优化或扩展代码时不必担心可能会引发不可预料的问题。毕竟，没有比做完回归测试后发现一切正常更令人心情愉快的事了。