此文转载自测所：http://www.cesoo.com
在
软件测试日新月异发展的今天，
自动化测试正在成为软件测试领域里的一个非常瞩目的趋势和潮流，很多软件公司正在或已经在企业测试团队内部实施软件自动化测试流程和框架，同时也把自动化技能作为人才衡量和业绩考核的重要技能指标，这些都不是偶然的事情，因为：
1. 软件质量的重视和提高。
软件产业虽然只有短短几十年的历程，但是其应用范围已经从最初的科研专用转变为渗透入我们社会中生产
生活各个方面，起着非常重要的作用，我们人类社会对软 件的依赖正在越来越强，根据牛顿第的反作用力定律，那么软件问题对我们的影响也在越来越大。比如2007年发生的奥运订票网站在开通首日不能登陆的问题， 导致上百万人购票失败；中国工商银行黄金交易系统出现漏洞，两名大学生通过低买高卖获利三千多万元，这样的新闻在报纸或网络上还能找到更多，要避免这样的 事情发生，就要使这些问题能够在软件上线之前被发现和解决，换句话说，软件质量必须要提高，而软件测试就是保证软件质量的一个重要并且非常有效的手段。因 此现在软件公司越来越重视软件测试，体现在老板那里就是对软件测试”舍得花钱，舍得投人“，测试执行起来就是”多测“，”测多”，“多测”就是时间上测试 执行频率加快，以前一个版本测一轮，现在一次编译就要测一轮，“测多”就是测试更加完整，覆盖更多的功能模块。这就为软件自动化测试提供了强有力的需求和 生长空间。
2. 软件系统规模的扩大，复杂性的提高
我们记得在单机系统时代时，几千行代码就能写出一个商业软件，比如WPS，CCED这些一代软件枭雄。但随着网络时代的到来，分布式系统的发展，软件系统 越来越重视交互和协作，多个模块服务的交叉调用，网间的交互安全等等，这大大提高了软件系统的复杂度和规模。
Oracle曾经开发过一个邮件客户端 Outlook的插件，这个插件是安装在outlook上，提供一些常用功能，比如收发mail，calendar创建等等。但oracle的测试部门仅 仅为这个插件就设计了6000多个
test case！这个数目是如此巨大，使得测试执行和产品周期产生了深刻的矛盾。这个矛盾体现在：当每个新版本发布时，如果做一遍完整测试，一个人手工测试执行 一遍6000多个test case就要半个月，而产品版本的发布周期也就一周左右，也就是说测试的速度远远跟不上产品的发布速度。在这种情形下，如果没有自动化测试帮忙，手工测试 只能望洋兴叹了！
以上两个软件的根本现状，决定了软件测试自动化的趋势不是人云亦云，昙花一现，而会蓬勃发展，强劲有力，成为势不可挡的潮流。很多软件公司已经看到了这个 潮流，很早就开始做软件自动化测试的预研和实施，比如
微软，oracle等已经在企业内部测试团队整合了自动化测试流程，实施了自动化测试框架，并且已经 按时更新换代，进入稳定应用的周期。但在国内，由于软件自动化测试时间不长，测试人员技能水平等因素影响，软件自动化测试的研究和实施大多还处于一个起步 摸索的阶段，我们看到普遍的情形是”做的人不少，成功的不多“，这种现状一方面有技术的问题，另外也有方向上的问题。因为在业界可供借鉴的成功实施经验或 案例比较少，所以在起步阶段可能就会走弯路，这是摸索必然要付出的”学费“。
那么怎样能够把握软件自动化测试方向和思路呢？下面笔者结合业界的现状分析，以及未来展望，对软件自动化测试的作出三个层次的划分：
第一阶段：测试的自动化
这是最原始的起步阶段，其目的就是将原先手工测试所作的
工作转化为自动化代劳。显著的特征就是以工具为中心，比如
QTP的应用，原先靠人工来执行的测试案 例，比如点击，录入等，现在由QTP来完成，如果QTP不能支持我们的系统，我们就要寻找解决方案，或改用
其他工具，总之大多数的自动化工作重点是在每个 case上，也就是技术层面上的问题。但随着技术上的解决，自动化测试规模的进一步增大，我们很快就面临下面的问题之一或全部：
1. 自动化测试脚本的类型和数量越来越多，怎样有效管理和复用这些脚本？比如有1000个脚本，有QTP的，有Winrunner的，还有perl的等等，每 种脚本又实现了多个case，那我们怎样统一管理和调度这些脚本，使之能够组成一个大的自动化测试目标？要知道单个的测试脚本和单个的测试案例一样，对于 公司的老板来说，他们是不关心这些细节的，只有它们组合起来成为一个壮丽的图本，才能体现出来它们的价值。也许老板们刚开始对自动化的执行感到新奇和惊 喜，但当他们意识到这些并不能为他带来什么价值时，他就会厌倦并放弃。
2. 自动化测试如何与手工测试整合？我们知道自动化测试是不能100％完全替代手工测试的，那么自动化测试必须要和手工测试整合在一起，才能反映出其价值。这 意味着，自动化测试要全方位和手工测试执行，包括前期的案例管理，测试的执行，以及最后的报告呈现。
这些问题是助产士，它们促成软件自动化测试第二个阶段的到来。
第二阶段：自动化的测试
如果说第一阶段是在一个点上下功夫，那么第二阶段就是在一条线上作战了。“自动化的测试”的内涵更加丰富，它意在将软件测试里的所涉及的各个环节作为一个 统一的整体考虑，从测试案例的管理，测试案例的执行到测试报告的展现都有相应的策略及自动化实现，故称“自动化的测试”。在这里，自动化测试框架横空出 世，自动化测试框架是一系列策略思想，规范和代码的集合。它要解决第一个阶段的困局，就要回答下面这些问题：
1.怎样管理多个自动化测试案例？
2.怎样无人职守地运行测试脚本？
3.怎样呈现自动化测试报告？
AC（Automation Center）是“www.cesoo.com"提供的基于QTP的软件自动化测试框架，它的回答是：
1.回答：测试组件的创建和划分
2.回答：增强自动化测试的健壮性，提供re-run机制，抓图策略等等
3.回答：采用
web服务接口和标准的xml技术，既可web页面展现，又可灵活地与手工测试报告整合
其中在Oracle等公司已经成功实施了AC，并取得了非常好的效果。
第三阶段：软件流程框架
这个阶段可以说是软件自动化测试炉火纯青的时候了，达到了”天人和一”，经过多年修炼，在这里软件自动化测试和软件开发再次做一个整合，从自动化流程上， 能够达到真正的测试驱动开发，比如coding与unit testing做整合。目前已经达到这个阶段的有微软，
IBM等。
评论
目前国内软件公司软件自动化测试的实施情况大多处于第一阶段或从第一向第二过渡的阶段。所以我在下面着重谈谈软件自动化测试框架的设计原则和一些风险的规避：
1.框架要集中精力解决自动化测试中的问题
看起来这是个很简单明了的原则，不是么？自动化测试框架本质是一个软件产品，它旨在满足自动化测试中的必然需求，而不是大包大揽软件工程中所有的问题。我 在某个测试网站曾看过一个测试框架的设计原型，真叫人叹为观止，从脚本代码的版本同步管理到bug的提交和存储，都通通塞入框架解决方案之中，包罗万象， 无所不能。我虽猜不中这框架的开始，但我能猜到这框架的结局，无非两种情形，要么技术资源不够而流产，要么实施起来太过复杂，自动化成本大大高于产出，总 之结局一个字：死。
一个经验丰富的自动化测试架构师应该既能够敏锐捕捉到当前自动化测试中的关键问题，又能巧妙利用现有企业资源为我所用，在上面的例子中，可以把脚本版本管 理工作交给企业中已有的源码管理系统，比如clearcase，Vss，把bug的存储交给bug管理系统，而框架集中精力解决自动化测试中的无人值守运 行，报告生成等问题，总之在框架设计的初期阶段，一个明确切实的实施目标是十分重要的。
以AC为例，紧紧以QTP自动化测试为中心，全力解决最实际最关键的问题：
1.自动化测试案例的管理
a)基于xml的测试组件的定义
b)基于xml的被测实例管理
2.无人值守的案例执行
a)案例关联关系校验，大大缩减自动化测试执行时间
b)Case级别Transaction的定义及实现，提供transaction的re-run和超时设定机制，从而减少因测试环境不稳定引起的失败
c)Recovery自定义机制，大大提高脚本的健壮性
3.基于xml的测试报告和测试
日志a)Xml标准，极强的扩展性，提供标准接口，用户可二次开发与手工测试报告进行合并，或直接写入
数据库。
b)灵活的抓图机制，所有抓图最后生成一个网页，作为测试报告的一部分提交。
2. 框架设计中的扩展考虑
毫无疑问，自动化测试框架是一个软件，在设计时同样遵循软件设计原则：模块的高内聚和低耦合，这些都是基本原则，不再赘述。需要注意的一点是由于框架作为 企业环境的一部分，必然涉及与其他系统的多种接口，比如和case数据库连接实现自动化测试案例自动获取，和mail服务器连接实现邮件实时通知，和 bug数据库连接实现bug的自动提交，因此，在接口设计上要尽量保证扩展性和兼容性。
AC采用的数据接口为xml，这有两个显然的好处
1.xml是数据存储的标准规范，可与其他系统保持非常强的兼容性
2.xml的utf-8可支持多种字符，不用担心乱码的问题
3.框架实现中的数据驱动思想
数据驱动在这里有两层意思，第一，框架实现上完全数据驱动，不能存在hard-code的问题，比如被测server信息，测试案例等信息以xml配置文 件的形式放在框架外面，要换个server或运行另外一套测试案例，只需更改xml文件即可；第二，框架要提供规范和策略，使得脚本同样必须遵守数据驱动 的原则。
AC提供excel数据全局加载机制，所有的数据都可以放在外部的excel里，AC会在case运行时加载数据，case则只需调用接口即可获得数据，数据驱动实现十分方便。
自动化测试与手工测试流程的整合
我们的企业不是试验的学校，也不是花拳绣腿的作秀场，在企业里做事往往从务实和实际效益出发，以结果为导向，因此，“自动化测试”在我们看来，重点在“测试”，而“自动化”只是一种手段而已。我们更关心测试整体的效果，不是么？
下图是自动化测试与手工测试的整合流程，在此流程架构中，自动化测试以smoke test为中心，旨在保证产品版本的稳定性；手工测试以negative test为中心，意在验证产品的功能和健壮性。两种测试互为补充，相得益彰，大大提高了测试整体的效益
