在软件开发过程中应用自动测试

随着人们对软件的要求越来越高，软件也相应越来越复杂，在开发过程中要求采用新的测试方法。测试可以分为两类，即所谓的“白盒”测试和“黑盒”测试，但无论哪种方法用手工方式都存在很多问题。本文介绍如何在软件开发过程中应用自动测试，从而提高错误覆盖率，缩短产品的测试周期。 

当今社会软件和电子技术已渗透入商业和个人生活领域的方方面面，我们日常生活中使用到的很多装置都要由软件来控制。例如在陆地、海洋和天空中运行的交通工具里，有软件负责行程的安全；在现代通信设施中，软件起着至关重要的作用；在家用电器方面，软件也使我们的应用更加方便可靠。我们希望软件可以完成的任务越来越复杂，而软件的复杂程度也相应将会提高。 

与此同时，要求缩短软件开发周期的压力也越来越大，如果一个公司希望保持并提升它在市场上的地位，必须尽可能地缩短开发时间。因此公司成功的基本条件是看它是否能比竞争对手提前将创新产品投放市场，但另一方面，复杂的软件又要求软件开发商在开发先进软件系统时必须进行长时间测试。 

随着软件复杂程度日益提高，软件测试过程中需要解决的问题也呈指数倍上升。理想情况下，软件要采用所有可能的各种输入向量进行充分测试，且这些测试应尽可能少地占用资源，测试周期也要经济实际。品质保证专家正在努力定义系列测试事件，以尽可能覆盖所有源代码。通常测试采用手工方法完成，并将结果记录下来，但这时测试事件的实际覆盖情况却无法确切地知道，而且手工定义与执行测试序列需要花费大量的时间和人力。 

不同的测试方法大体上可以分为两类。一类称为“黑盒”测试，此时被测系统(IUT)从外面几乎看不到。该方法将适当的输入事件或向量混合在一起激励IUT，根据从外部观察到的反应来评估系统的性能，它将IUT显示的实际结果记录下来，与我们所期望的性能相比较，如有任何差异则说明存在错误，产生的根源可能是内部结构或源代码错误。另一类称为“白盒”测试，即监控被测系统的内部结构，以便找出源代码出错位置。一般来说，为了要达到一定质量水平，以及对于为达到该水平所使用的资源而言，采用黑盒测试和白盒测试相结合是有效的方法。 

自动黑盒测试目前无论测试什么样的软件产品一般都是用人工方式来完成，测试事件和指令序列也由人来制定，通常针对一个特定的产品，因此即使是类似的其它软件产品也不能重复应用。有很多出错原因都与这种测试方法有关，例如人工生成的测试事件可能没有完全覆盖软件功能范围，或其定义过于简单；手动执行测试以及将测试结果与目标相比较也有危险，如测试指令序列也许没有完全执行，或者解释结果的时候也可能出错。 

尤其对于复杂的产品更是这样，因此我们要做的是开发出一种方案，能自动执行测试指令序列。为了加快测试环节，很多公司已经在内部进行了这样的开发，然而手工测试规范所带来的不确定性并不能通过自动执行测试序列而减少，测试结果的精度仅与输入有关。 

创建一种可靠自动测试流程的先决条件是测试事件和测试指令序列的规范化描述，与具体软件开发商无关的标准规范化表示有下列优点： 
?它是准确而清楚的，每个人对它的理解都一样。 
?采用规范语言的测试描述能自动生成，因而预先保证不会出错(假定相应的发生器运行正常)。 
?测试描述可以自动执行，避免执行过程中的错误。 
?规范化测试描述可以重复利用。

TTCN是一种规范的测试描述语言，它的作用已在通信业中得到了证明。初这种语言是为明确指定测试指令序列而开发的，它与内部实现没有关系，协议执行测试作为OSI参考模式(即通信堆栈)的一部分。TTCN是标准化语言(ISO/IEC 9646-3)，它与具体开发商无关。 

现在我们已有了TTCN-3语言，TTCN-3不仅仅是旧标准的新版本，在很大程度上它实际上是一种新语言。它由ETSI(ES 201873-1)开发出来，当时成为ITU测试推荐内容(Z.140)。开发TTCN-3及其内部所包含的思想是希望保留TTCN-2在通信领域“边试边测”的优势，再加上新语言的帮助，弥补它在其它领域的不足。如今TTCN-3已是很多系统测试中先进灵活的语言，可用于多种应用中。TTCN-3的语法与传统程序语言相兼容，包括同步和异步通信机制，还能够选择定义动态并行测试。有了这些功能，TTCN-3不仅可以测试协议，而且可以测试模块、基于 CORBA的平台以及应用界面(API)等等。 

TTCN-3另外一个突出的地方是TTCN运行时的界面(TRI)，该界面能使现有可执行测试指令序列适应特定的被测系统。用一个与TRI兼容的TTCN-3工具将测试指令序列抽象描述转换成可执行代码后，即使工具改变这种编译还可以使用，这样投资得到了保障。 

开发统一模型语言UML 2.0的测试纲要工作由目标管理组(OMG)完成，有了这个纲要可以从规范化UML得出并验证测试规范，因此产生测试指令序列的时间会减少，还可以避免手工测试指令序列的错误。TTCN-3将成为被推荐的UML测试语言之一。 

虽然TTCN-3是新开发出来的产品，它也包含了许多TTCN-2的概念，故对一个有TTCN-2经验的人来说不会有很大困难，并且还可以选择以前熟悉的显示窗口。此外通过自动转换工具，TTCN-3的测试描述还可从现有的TTCN-2测试中产生，通过配置适当的工具，TTCN-3的各项优点都能得到利用。例如支持TTCN-3的工具Tau/Tester，它是一个综合环境，只需要一台普通台式电脑和熟悉的工作界面可以支持整个测试。 Tau/Tester可以提供测试设计、开发、分析、实施以及各种调试功能，有了这个工具可在整个公司对不同应用使用同一个测试平台，从而取代那些昂贵的内部专用解决方案。 

Tau/Tester的特点是自动化程度很高，它完全以TTCN-3标准为基础来实现测试。项目组可以集中精力在测试内容上，测试的产生、实施和结果记录则将自动执行。这样项目组的工作效率可以非常高，更重要的是所有测试都是一样的，需要的时候可以重复。当然测试指令序列还能扩充，可通过内部或外部资源如标准委员会得到现成的测试事件。 

TTCN-3一个重要的创新在于它还可以定义复杂并行运行的分布式系统测试指令序列，这一功能Tau/Tester也考虑在内，它对大型项目(包括分布在不同地域的项目)提供专门的支持，并将它们与先进的配置和管理工具很好地整合在了一起。 

白盒测试

当然，系统性能除了表面上要合乎要求之外，还应知道测试时源代码确实已被完整测试过，如果不能完整测试，多数是因为测试指令序列不全或代码错误，使有些代码根本没有被执行(称为“废码”)。从程序本身来看，废码也许没有什么害处，但是废码的存在说明有严重的概念错误或运行错误。 

所定义的测试指令序列是否完全覆盖源代码的问题可以这样来回答，即源代码是在可执行代码产生前装载好了，然后在运行测试指令序列时执行。结果是一个报告和图表展示，记录每个模块的测试覆盖情况。这个结果是清楚客观的，而且随时可以重新生成，以这些标准值为基础，测试指令序列可以不断优化，使测试源代码覆盖率达到。 

本文结论 

如今产品开发不再是孤立的单独行为，而应看作是整个产品生命周期的基本组成部分，它包括需求分析、建模、规范制定、测试及文档系统建立。先进的支持产品生命周期的过程概念对产品质量管理尤其重要，它是保证及提高产品整个过程质量的重要措施。以前测试在某种程度上地位比较低，现在随着产品复杂程度的日益增加，测试已经成为产品是否能被接受的关键。同时人们也越来越认识到，对产品进行有效测试并不是终目的，而是应该在流程早期要考虑的事情，它在产品的生命周期内会反复产生影响。 

正因如此，在测试阶段采用什么样的测试方法和工具很关键，各公司用的模型和规范都应同样处于高要求。规范化语言、适当的方法和相应的工具有助于在自动测试和设计时简化测试方法、定义和执行。TTCN-3具备了标准化条件，Tau/Tester在实际项目中可以发掘出TTCN-3的内在潜力。测试覆盖的辅助测量(如利用Tau Logiscope协助)是对应用领域的实际测量，此时低错误率非常关键。 

作者：Renate Stuecka 
德国Telelogic公司 
Email: renate.stuecka@telelogic.de 

Matthew Graney 
美国Telelogic公司 
Email: matthew.graney@telelogic.com