“自动化”测试本身分为多个层面，在每个层面，“自动化”一词将具有不同的内涵，下面将简单与大家分享一下各个层面的“自动化”测试内涵以及在各层面常用的自动化测试框架。

　　首先，在单元测试阶段，有所谓的单元测试自动化，可能有人会说单元测试不都是写完单元测试代码后再以自动化的方式运行的吗。这个观点非常正确，所以单元测试阶段的“自动化”内涵就不是简单地指测试执行的自动化了，而是指单元测试用例生成的自动化以及测试数据的表格化，在单元测试阶段，很多测试用例都是数据驱动的，这个为测试用例的自动生成和数据表格化提供了很大的应用空间。以C/C++为例，单元测试阶段比较好的测试工具有C++Test和Visual Unit，以JAVA为例有JTest等，这些工具都可以基于被测试代码自动生成相应的单元测试框架，并可以很好的应用数据驱动编写组织测试用例。

　　其次是软件集成测试，这里又可以细分为两个不同的层面。先看传统意义上的软件集成测试，这个非常类似于单元测试，但关注点主要是在软件模块之间的调用接口，对于我们做测试而言，两者最大的区别在于集成测试代码不允许打桩，必须调用真实的底层代码，单元测试代码必须打桩，以上这点就决定了集成测试“自动化”的内涵将与单元测试非常相似。但是很显然，集成测试对于测试框架的要求就非常高了，也就是说我们的测试框架必须可以顺利装载我们自己的并且相互依赖的软件模块，做到被测软件模块Runnable。很不辛，据我所知还没有哪个测试框架能够很普适的应用于不同软件项目的集成测试，所以对于软件集成测试的自动化，通常的做法是借鉴单元测试框架（比如JUnit，TestNG等）的设计思想，自行开发适合于特定软件的测试框架。前段实际我就负责过一个这样的项目，自行开发集成测试框架，该框架的主要功能是根据软件架构设计依次分层加载被测模块，执行驱动代码并参数化测试输入，参数化判断测试结果，测试用例执行后的现场恢复和提供整个测试过程的log信息等等。软件集成测试的另一个层面就是目前比较流行的持续集成（Continuous Integration），严格意义上讲，持续集成属于软件开发实践的范畴，不属于测试的范畴，但是又和软件测试的自动化有着不可分割的关系，也就是说持续集成具有自动化测试的很多特征。我们可以使用持续集成框架/系统在非工作时间自动完成Sourcecode update和Daily Build，之后自动执行代码的静态检查，然后自动开始运行单元测试用例并统计白盒覆盖率，进一步地可以自动运行被测软件并执行基于GUI的自动化功能测试，最后将整个过程的Log以及相关的多份测试报告以邮件的形式通知各个干系人。这里我推荐可以在自己的开发项目中试用一下Husdon持续集成框架。

　　最后就是功能测试层面，这也就是我们平时讨论最多的传统意义上的自动化测试了。这个层面的自动化测试框架非常多。QTP本身就为此类框架的设计与开发提供了很好的平台，比较优秀的还有基于TDD的RobotFramework和Web GUI自动化的Ruby+Watir/FireWatir等等。其实每个框架都有很多内容可以讨论，限于篇幅，这里不再进一步展开了。

　　另外还想提一下的是STAF/STAX这个高层次的测试框架，个人觉得很有发展潜力，可以很好的应用于网络环境的自动化配置和测试。

原帖地址：http://bbs.51testing.com/viewthread.php?tid=313165&extra=&page=1

版权声明：本文由会员dhrbc首发于51Testing软件测试论坛“我要做专家-你问我来答”活动第五期。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。