1、软件的易测试性设计

　　Voas将软件的易测试性定义为一定测试策略迫使软件中存在的故障被暴露的概率。软件的易测试性包括可观察、可控制、可理解等几个方面。软件易测试性设计即是在软件的设计和编码中考虑测试问题，它借鉴了硬件易测试性设计的思想。为了减少测试集成电路的测试开销，提高产品的质量，工程师采用易测试性设计技术，即在集成电路上增加额外的引脚，通过这些引脚能够在测试时探测集成电路的内部，提高了可控制性和可观察性。内建式测试（Bulit-In Testing） 方法是一种易测试性设计技术，它在集成电路上引入测试电路或引脚，使得集成电路能够工作在测试模式下，并且传输测试输入，捕获输出。这种方法的进一步扩展是再增加测试输入生成电路，从而避免外界的输入。这是内建式自测试概念。

　　软件易测试性设计的目的是在不增加或者少增加软件复杂性的基础上，将易于测试的原则融合到设计和编码之中。软件易测试性设计符合软件测试的一个原则：尽早开始软件测试工作，不断进行软件测试工作。软件易测试性设计体现软件测试的如下观点：软件产品的质量是生产（包括分析、设计、编码、测试） 出来的，而不是仅仅依靠软件测试来保障。软件易测试性设计也体现了软件测试的一个发展趋势：向软件开发的前期发展，与软件开发的设计和编码阶段相融合。易于测试的软件本身所包含的缺陷也会减少。软件易测试性设计将有效地提高软件测试的效率和质量，提高软件设计和编程的质量，进而提高软件产品的质量。软件的易测试性设计方法包括合约式设计（Design by Contract） 、内，建式测试和内建式自测试等几种方法。

　　合约是管理对象之间的交互的一组规则。合约的来源是软件的规约，它指明了软件“做什么”而不涉及“怎样做”。常见的合约类型包括：前置条件、后置条件、不变式、循环变式P不变式和轨迹等。合约表明了过程调用方（客户方） 与实现方相互的职责和利益：客户方只有在满足前置条件的条件下才能调用对应的过程；实现方承诺当过程结束时，后置条件指明的工作将被完成，并且不变式仍然满足。合约可用于区分软件失效时的责任：如果前置条件被违反，则应该在客户方寻找错误；如果后置条件或不变式被违反，责任在实现方。合约有助于减少冗余的检查代码，提高软件设计的效率和运行的性能；利用自动检查合约的工具，能够减轻用户的负，减少用户犯错误的机会；并且合约被违反时引发异常，便于近定位故障。常见的合约式设计方法是在程序代码的注释中提供软件的合约。现在有一些对合约进行自动检查的工具，如针对Java 语言的iContract ， Jass ， JMSAssert 等工具。

　　软件的内建式测试方法是在程序中添加额外的测试机制，使软件能够工作在测试模式下。软件的内建式自测试方法是在此基础上再增加测试用例生成机制。

　　2、构件测试

　　当前社会的信息化过程对软件的开发方法与生产能力提出了新的要求，软件复用是提高软件产品质量与生产效率的关键技术。软件构件概念的提出为软件复用提供了技术基础。构件的高可靠性是构件能被成功复用的前提。构件测试是保障和提高构件的可靠性的重要手段。构件的开发者和复用者必须对构件进行充分的测试，以确保它在新的环境中工作正常。

　　与传统的软件测试相比，构件测试有着自身的固有特点： （1） 不能对构件的执行环境和用户的使用模式进行完全准确的预测，故构件开发者不能完全、彻底地对构件进行测试，并且很难确定何时结束测试； （2） 构件复用者和第三方测试人员通常无法得到构件的源代码及详细的设计知识，通常只能对构件进行黑盒测试，即调用构件的方法后只能通过观察执行的结果判断构件的行为是否正确，无法检查执行过程中的构件的内部状态，使得构件执行过程中的一些故障被隐藏。这些困难对构件测试提出了严峻的挑战。

　　国际上于20 世纪90 年代后期对构件测试开展了研究。近年来，出现了大量的文献报道。构件测试成为当前软件工程学术界和工业界的热点问题之一。大体上，对构件的测试可以从以下几个方面来进行分类。从构件测试的内容可分为：构件内部实现细节的测试，构件接口的测试，构件组装（构架） 的测试。从测试者与构件的关系可分为：构件开发者的测试（拥有构件的源代码）、构件复用者和第三方的测试（没有源代码） 。从测试过程中所采用的技术手段可分为：基于变异测试的方法，基于构件状态机的方法，对构件的回归测试，以及构件的易测试性设计等。

　　构件测试一个重要的发展方向是基于合约的构件易测试性设计。合约可以在运行时被检查，便于捕获构件执行过程中的一些故障，提高构件的易测试性。因此，基于合约的构件易测试性设计不仅为构件开发者开发高质量的构件提供帮助，而且在构件开发者与复用者之间架起一座桥梁，为构件复用者的测试提供支持，也为构件开发者捕获错误提供便利，便于区分构件开发者与复用者的责任。如果众多的构件开发者都采用合约式设计方法生产构件，那么失效时很容易定位到构件和其中的方法。为使基于合约的构件易测试性设计方法能够实用，需要研究解决以下问题：构件合约的描述、表达，构件中合约的获取，对构件合约的自动检查，以及针对构件合约的软件测试。

　　3、Web Services 测试

　　随着软件产业模式从以产品为中心的制造业转变为以客户为中心的服务业，WWW 从2层体系转变为3 层体系，B2B 从复杂专用的连接转变为简单通用的连接，分布计算中间件从Intranet 扩展到Internet ，CORBA、COM及EJB 等中间件技术已不能适应这些发展需求，因而导致了新型中间件技术Web Services 的产生。

　　当前，Web Services 越来越受到人们的关注，它使用了包括SOAP、WSDL 和UDDI 在内的标准协议。这些标准协议体现了互操作性，并用于应用的开发及运行时Web Services 的选择和调用。Web Services 的测试和评估对服务提供者和服务使用者来说都是相当重要的。WebServices 的测试相当于黑盒测试，可以获得规约，却不能得到设计或源代码。Web Services 规约是用WSDL 写的，而代码是用Java 、C # 或其他编程语言写的。

　　当前的WSDL 信息包括输入P输出的数量、每个输入和输出的变量类型、输入的顺序和输出返回的顺序和一个Web Service 应当如何调用的信息。但是，为了执行Web Services 的黑盒测试和回归测试，以上信息是远远不够的。

　　对用户而言，通常需要合并多个Web Services 来满足他们的需求，所谓的服务聚合是根据用户的要求合并现存的Web Services。这时需要一种标准语言来描述不同的Web Services 是如何集成在一起的，即描述Web Services 流的语言。当前有两种常见的Web Services 流描述语言WSFL 和XLANG。如果让用户自己来描述Web Services 流，很可能会导致错误。在发现错误之前，流中的许多Web Services 已经被调用了，其后果会导致事务回滚困难、引起网络拥塞，从而造成资源浪费。