浅谈软件开发各阶段的自动化测试技术(51Testing投稿).docVIP

浅谈软件开发各阶段的自动化测试技术 作者：茹炳晟 摘 要：本文根据软件开发的生命周期，依次探讨了各个软件开发阶段的自动化测试技术以及各阶段典型的测试框架与工具。使读者对软件开发各个阶段的“自动化测试”建立起全局的概念，并了解各阶段的主流测试框架与工具。 关键字：自动化测试、测试框架、单元测试、集成测试、确认测试 软件测试领域很多人都在谈论软件自动化测试，视乎自动化测试在软件测试领域是一个很时髦的词。但是绝大部分人对于自动化测试的认识还只是停留在GUI功能测试自动化的层面。其实自动化测试本身分为多个层面，在每个层面，“自动化”一词将具有的内涵，下面将与大家分享一下各个层面的“自动化”测试内涵以及在各层面常用的自动化测试框架。/thread-313165-1-1.html）。 一．单元测试阶段的自动化测试技术 首先，在单元测试阶段，有所谓的单元测试自动化，可能单元测试测试代码后再以自动化的方式。这个观点非常正确，单元测试阶段的“自动化”内涵不是测试执行的自动化，单元测试用例生成的自动化, short b），那么测试数据自动生成技术就会为int *p自动生成空的和非空的两个指针p去分别执行函数void fun（int* p, short b），并观察函数的执行情况，如果函数内部没有对空指针进行防护，那么fun的调用必定产生异常，从而发现函数的设计缺陷。同样的，对于short b会自动生成超出short范围的b去测试函数fun的行为。 （3）自动桩代码的生成。这个是指工具可以根据对被测试代码的扫描分析，自动为被测函数内部调用的其他函数生成可编程的桩代码，并提供基于测试用例的桩代码管理机制。此时，单元测试开发者只需重点关注桩代码内的具体逻辑实现即可。当然必要的时候，工具应该可以实现“抽桩”以适应后续的代码级软件集成测试的需求。 （4）被测代码的自动化静态分析。静态分析主要指代码的静态扫描，以识别出违反编码规则或编码风格的代码行。通常这部分工作是结合项目具体的编码规则和编码风格，由工具通过内建规则和用户自定义规则自动化地完成被测代码的静态分析。严格意义上讲，静态分析不属于单元测试的范畴，但实际上这个工作很多情况下是在单元测试阶段完成的，所以这里我也把它归入到了单元测试自动化的范畴。 （5）测试覆盖率的自动统计与分析。单元测试用例执行结束后，工具应该可以自动统计各种测试覆盖率，包括代码行覆盖率、分支覆盖率、MC/DC覆盖率等，以此体现单元测试用例集合整体的充分性和完备性，并以此为依据增补适当的测试用例以提高测试覆盖率。 接下来列举几个满足或部分满足以上特点的典型的单元测试框架或工具。以C/C++为例，比较的测试工具有C++Test和Visual Unit，以JAVA为例有JUnitC++Test是Parasoft针对C/C++的一款自动化测试工具Visual Unit是KaileSoft推出的国产C/C++单元测试工具，创新提出了一些全新的概念，我个人觉得还是值得推荐的。JUnit就不多介绍了，它是一个开放源代码的Java测试框架，广泛应用于Java代码的单元测试，另外根据JUnit的设计思想也陆续出现了一系列的XUnit框架，其中比较著名的有NUnit（针对.NET的单元测试）、CPPUnit(针对C++的单元测试)、DUnit(针对Dephi的单元测试)、PHPUnit(针对PHP的单元测试)等。TestNG（Test Next Generation）下一代的测试框架它是基于J2SE5.0的注释Annotations）特性的而构建的轻量级的单元测试框架。IBM Rational Test Real Time（RTRT）。RTRT使用了目标适配技术（Target Deployment Port），使得测试与编译器、连接器、调试器以及目标结构无关，实现了跨多开发环境、多目标结构其次是软件集成测试可以为两个不同的层面先看传统意义上的软件集成测试，这个非常类似于单元测试，但关注点主要是在软件模块之间的接口测试而言，两者最大的区别在于集成测试代码不允许打桩，必须调用真实的底层代码，单元测试代码必须打桩，以上这点就决定了集成测试“自动化”的内涵将与单元测试非常相似。但是很显然，集成测试对于测试框架的要求就非常高了，也就是说我们的测试框架必须可以顺利装载我们自己的并且相互依赖的软件模块，做到被测软件模块Runnable。很不辛，据我所知还没有哪个测试框架能够很普适的应用于不同软件项目的集成测试，所以对于软件集成测试的自动化，通常的做法是借鉴单元测试框架（比如Unit）的设计思想，自行开发适合于特定软件的测试框架。前段实际我就负责过一个这样的项目，自行开发集成测试框架，该框架的主要功能是根据软件架构设计依次分层加载被测模块，执行驱动代码并参数化测试输