对于单元测试的自动化，我的感觉是入门容易精通难，你会发现，如果你有较好的开发背景，那么去学习一个单元测试框架或者工具是很容易的，但是要把这个框架很好地应用到实际项目中去就会碰到非常多的阻碍，其中包括打桩失真的处理，复杂结构的初始化，大量桩函数的管理等等。这里就不再继续具体展开了。
二、集成测试阶段的自动化测试技术
其次是软件集成测试，软件集成测试的依据是软件的架构设计和一部分模块设计。根据目前业界的情况，软件集成测试可以划分为两个不同的层面：传统意义上的软件集成测试和软件持续集成。
先看传统意义上的软件集成测试，这个从测试用例的设计与测试代码的结构来看都非常类似于单元测试，但其关注点主要是在软件模块之间的接口调用以及数据传递，相对于单元测试而言，两者最大的区别在于集成测试代码不允许打桩，必须调用真实的底层代码，单元测试代码必须打桩，以上这点就决定了集成测试“自动化”的内涵将与单元测试非常相似，尤其是在实际操作层面，比如测试用例的设计方法，测试用例代码的组织与管理，数据驱动思想的应用等等。但是很显然，集成测试对于测试框架的要求就非常高了，也就是说我们的测试框架必须可以顺利装载我们自己的并且相互依赖的软件模块，做到被测软件模块Runnable。很不辛，据我所知目前还没有哪个测试框架能够很普适的应用于不同软件项目的代码级集成测试，所以对于软件集成测试的自动化，通常的做法是借鉴单元测试框架（比如XUnit）的设计思想，自行开发适合于特定软件的测试框架。前段实际我就负责过一个这样的大型项目，我们自行设计并开发集成测试框架，该框架的主要功能是根据软件架构设计依次分层加载被测模块，组织管理大量测试用例，执行测试用例的驱动代码并参数化测试输入，参数化判断测试结果，测试用例执行后的现场恢复和提供整个测试过程的log信息等等。另外，向像C++Test这样的测试工具也是适用于某些项目的软件集成测试的，前面有提到C++Test支持“抽桩”技术，所谓“抽桩”技术是指在单元测试用例中，我们可以人为把桩代码替换成真实的代码，显然这样的技术非常适合于软件的代码级集成测试，而且大量的单元测试用例和测试数据可以和集成测试用例复用。
……………………
查看全文请点击下载：http://www.51testing.com/html/13/n-241113.html
三、确认测试阶段的自动化测试技术
最后，就是软件的确认测试阶段了，软件确认测试的依据是软件的需求规格说明书。通常软件确认测试阶段所面对的被测对象都是最终交付的软件，所以这个阶段的测试中很大一部分工作集中在基于GUI的功能测试和基于协议层面的性能测试。这也就是我们平时讨论最多的传统意义上的自动化测试了。
对于基于GUI功能测试的自动化，主流的测试工具非常多，主要有HP的QuickTest Professional，IBM的Rational Robot等。除此之外，比较优秀的还有基于TDD的RobotFramework和Web GUI自动化的Ruby+Watir/FireWatir和Selenium等等。GUI层面的自动化测试的主要难点在于对象的识别、检查点的稳定性、测试脚本的可扩展性以及可维护性。
……
查看全文请点击下载：http://www.51testing.com/html/13/n-241113.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
