使用JUnit高效完成功能测试(3)

　　另外，这些图表将测试执行的代码分类列表，并确定测试是否会受到将来对任意代码改动的影响。如果开发人员确定测试A是建立在B、C和D的基础上，她就可以确定如果对B、C或D做出改动就需要对A进行重新测试(确保向后兼容)。

　　以尽可能少的步骤模拟系统是个好方法。总的来说，实际调用与此无关，重要的是系统如何作为整体运作以获得预期目标。可以用简化的模拟系统实现这个目的，该系统只关心对象间的基本交互，并用自然语言描述交互中发生的事件。

　　做出运行时事件表后，就可以将其整合到类文档中。需要注意的是，为表添加一些限制可使其对类的修改更有弹性。首先，一般不能使用方法名，因为它们会随时间发生变化。取而代之的是更易理解的自然语言描述。其次，这些图表主要是关于系统中各部分的交互。这是高层架构上的设计方案，一般不会再做改动。最后，图表是建立在类型而非特定类的基础上。只要基本类型不变，为维持交互协议的正常运行，这些图表就不需要更新。

　　一旦图表创建成功，可以在许多方面获得应用。比如，一个图表可以用来获取系统如何运作，以及如何运用其交互部件实现功能的概览。在某种程度上这是一种简化了的UML语言，它只描述关系到整体功能的系统部件：实例及其类型、其它引用的实例，以及组件可以实现的功能。

　　这些图表也可以用来分析系统的复杂性以及如何进行简化。要确定简化系统的方法，可以查找系统中使用过一到两次的对象，并为其寻找其它可能更合适的位置。也可以查找重复的任务，将其封装到方法或类中。

　　然而，最重要的是图表在测试中的应用。通过对系统状态的总结，图表可以帮助解决系统中出现的问题。出现问题时，图表中的信息便可用作参考。因为只需要将系统目前状态与预期状态作比较即可，这样确定问题产生的原因也就变得比较简单了。对小组件的改动不应该影响整体架构，因此可以通过对照运行时事件表以保证系统仍然正常运行。并且，当有重要组件发生变动时，可以用运行时事件表对照系统当前状态以获取系统修正方案。由于将系统作为整体和对预期功能的描述，运行时事件表也可以看作是一种结构化的单元测试。如果系统有变动，可以更容易地做出修正以维持系统的正常功能。

　　如果经常因细节问题影响对全局的把握，就应该使用图表。其高层本质可以用来分析软件的设计模式，就像反模式一样。还有许多其它用途，并且当运行时事件表、测试用例说明和用例说明没有描述所需的细节时，它还提供了直接进行代码分析的路线图。

　　利用功能测试进行回归测试

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

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