来聊聊自动化测试框架
首先自我介绍一下，呵呵，本人sunshinelius，曾担任loadrunner版版主五年多，后因工作方向转移，已不在性能测试一线工作，恐不能胜任，于是2008年向51论坛管理员请辞去loadrunner版主头衔，目前正在关注自动化测试框架领域，希望能够和各位同行共同交流探讨学习。在软件测试日新月异发展的今天，自动化测试正在成为软件测试领域里的一个非常瞩目的趋势和潮流，很多软件公司正在或已经在企业测试团队内部实施软件自动化测试流程和框架，同时也把自动化技能作为人才衡量和业绩考核的重要技能指标，比如国外的微软，IBM，国内的金山等软件企业，都已经开始实施了自动化测试框架。
这些都不是偶然的事情，因为：
困境
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.怎样呈现自动化测试报告？
第三阶段：软件流程框架
这个阶段可以说是软件自动化测试炉火纯青的时候了，达到了”天人和一”，经过多年修炼，在这里软件自动化测试和软件开发再次做一个整合，从自动化流程上， 能够达到真正的测试驱动开发，比如coding与unit testing做整合。目前已经达到这个阶段的有微软，IBM等。
经验
目前国内软件公司软件自动化测试的实施情况大多处于第一阶段或从第一向第二过渡的阶段。所以我在下面着重谈谈软件自动化测试框架的设计原则和一些风险的规避：
1.框架要集中精力解决自动化测试中的突出问题
看起来这是个很简单明了的原则，不是么？自动化测试框架本质是一个软件产品，它旨在满足自动化测试中的必然需求，而不是大包大揽软件工程中所有的问题。我在某个测试网站曾看过一个测试框架的设计原型，真叫人叹为观止，从脚本代码的版本同步管理到bug的提交和存储，都通通塞入框架解决方案之中，包罗万象， 无所不能。我虽猜不中这框架的开始，但我能猜到这框架的结局，无非两种情形，要么技术资源不够而流产，要么实施起来太过复杂，自动化成本大大高于产出，总 之结局一个字：死。
一个经验丰富的自动化测试架构师应该既能够敏锐捕捉到当前自动化测试中的关键问题，又能巧妙利用现有企业资源为我所用，在上面的例子中，可以把脚本版本管 理工作交给企业中已有的源码管理系统，比如clearcase，Vss，把bug的存储交给bug管理系统，而框架集中精力解决自动化测试中的无人值守运 行，报告生成等问题，总之在框架设计的初期阶段，一个明确切实的实施目标是十分重要的。
2. 框架设计中的扩展考虑
毫无疑问，自动化测试框架是一个软件，在设计时同样遵循软件设计原则：模块的高内聚和低耦合，这些都是基本原则，不再赘述。需要注意的一点是由于框架作为 企业环境的一部分，必然涉及与其他系统的多种接口，比如和case数据库连接实现自动化测试案例自动获取，和mail服务器连接实现邮件实时通知，和 bug数据库连接实现bug的自动提交，因此，在接口设计上要尽量保证扩展性和兼容性。
3.框架实现中的数据驱动思想
数据驱动在这里有两层意思，第一，框架实现上完全数据驱动，不能存在hard-code的问题；第二，框架要提供规范和策略，使得脚本同样必须遵守数据驱动 的原则。
4. 与手工测试的整合
我们的企业不是试验的学校，也不是花拳绣腿的作秀场，在企业里做事往往从务实和实际效益出发，以结果为导向，因此，“自动化测试”在我们看来，重点在“测试”，而“自动化”只是一种手段而已。我们更关心测试整体的效果，不是么？
待续 1.框架要集中精力解决自动化测试中的突出问题
说得好。。学习了 谢谢楼上
在业界自动化测试实施有两种倾向。第一种狂热型，特点是对自动化测试盲目崇拜，表现是不考虑实际情况，试图用自动化的方法解决一切手工测试工作量，甚至bug的验证工作。第二种是怀疑型，与狂热型相反，怀疑型对自动化测试没有信心，往往采用隔岸观火的现实主义态度，看见效益，立刻上马，看不见效益，撤得也干净。
这两种类型其实本质上是一样的，对自动化测试没有过去经验的总结，也没有对现状理性的分析，更没有切实明确的长远目标。呵呵，说起来容易，做起来难，后面会慢慢讲到。 做自动化测试久了，越来越有体会：自动化测试的成败不在于具体的技术，而是整体的方向思路。
回复 4# 的帖子
对这一点相当赞同！ 谢谢楼上，应该是老朋友吧 微软似乎每个项目组结合自己项目的特点，在通用自动化库的基础上，开发了自己的自动化测试框架。流程什么的都贴近于每个项目的实际需求，能解决多年手工经验积累的对自动化的需求。国内公司即使是失败的案例，仍然有技术积累留下来了，还是有用的。在实施过程中，如果阶段评估发现自动化框架效果不好，需要及时换用手工等方式弥补，以免到了项目末期被动。 值得探讨,楼主工作几年拉
回复 6# 的帖子
呵呵老朋友啊以后还要请大哥在自动化整体解决方案方面多多给予指点啊！ 如果想了解一下框架思路，可参看我一本近期上市的新书《软件自动化测试框架设计与实践》，人邮出版社。呵呵，不厚道地打自己的广告。蓝天伟，我可以考虑送你一本，前提是能从出版社那里多争取几本样书。
回复 10# 的帖子
呵呵 谢谢你的好意了！我还是厚道点去书店买本吧，好好拜读下。:)
这本书不好
我买了一本来看了一下，坦白地说：一点都不好！包括对自动化的认识，自动化测试架构的认识，以及提到一些所谓的测试架构。。。我个人认为作者对些认认识不够深入！更谈不上把自己的经验和体会表达出来！ 自动化的架构也小有研究，架构自然要源于项目或者说产品，不同的内容需要的架构既然不能相通，这和软件开发同理！ 关注，学习:) 都是前辈我们晚辈学习 都是前辈我们晚辈学习 能不能考虑一下把目前的自动化测试工具和具体的自动测试框架联系一下啊？例如CETK、QTP、LoadRunner等，每种框架的组成结构以及实现方式呢？具体联系起来思考.....我觉得学习起来会深入点，但我目前还不太明白.....还望请教 都是高手 。多多结合具体案例会比较容易懂一些。
页:
[1]
