自动化测试实践经验和教训

                                                                 自动化测试实践经验和教训

        序言:在部门做自动化有好一段时间了，经历了自动化从无到有，然后到框架，到现在的平台，以及持续集成，回顾发现由于自己之前经验太浅，走过的弯路太多，现在也还在谨慎的前进着，上次又回顾了一遍”软件测试经验和教训”里的自动化测试章节，发现早前很多懵懂的经验，现在稍稍清晰，于是想着结合自己的历程精简出一些经验吧。现在经验还是尚浅，如果有更深认识的朋友，互相讨论，谢谢

一、所谓自动化是为了软件发布服务的，并不只是为了测试服务
        来源:自动化测试目标建设
        以前一直怀疑自动化测试的用处，我们之前花费大力气开发了大量的基于关键字方式的脚本，用来提高测试的覆盖率，每次测试耗费大量时间，但是发现的问题少之又少，虽然说，自动化测试不是用来发现问题的，是用来验证软件没有问题，但是有一个矛盾在于我如果不做自动化测试，问题还是那么少，那么做自动化测试我们难道只是为了追求一个心理感受吗？这个概率问题怎么平衡
        后来，这个经验是在与开发一起合作冒烟测试建设，到现在的持续集成建设，开始明白，自动化测试的好处是为了增强开发的灵活性和保证软件开发流程的有序性
        1)快速检测新版本的不稳定变更,即冒烟测试，能够快速验证当前build版本是否可以继续下一步或者提测，此处冒烟测试可以是单元测试、集成测试和基本功能覆盖测试，常用的框架和工具:Junit、TestNG和接口测试框架(soapui、httpClient等)、界面测试框架用于基本的界面测试(QTP、RFT、selenium)。
        2)尽可能的暴露回归程序的错误，即例行回归测试，测试部门在开发提测后，基于开发的测试单，手工重点测试变更内容，利用自动化有选择性的覆盖其他功能。此处更多的是到了系统测试层面。
        3)验收测试，在发布前应用自动化的各种手段进行一次基本功能验收测试，通过率在多少以上才可以提交发布，而且此处环节还可以加入非功能测试。
        所以说，我们做自动化测试的目标一切都是为了软件发布服务，也可以理解为部署软件生产流水线，在这里，推荐一本书，《持续交付-发布可靠软件的系统方法》

二、不要事后去计算人工替代率，而是要参考自动化测试有效性
        来源:自动化测试度量和ROI分析
        之前在年底做自动化测试度量的时候，要求每个产品线将自动化测试执行次数和时间进行统计，这样做的目的是为了统计自动化测试执行时间，然后要求测试人员算出每个模块的人工耗时，然后进行换算，得到自动化替换人工的时间，后来算完后，发现这样的数据其实是没有意义的
        1)测试的本质是不可以比较的，一次手工测试执行有可能比自动化测试执行也许是更有意义的。
        2)大多数的人工耗时都是拍拍脑袋想出来的
        3)运行只是表明自动化测试被执行，但不能证明这次执行是有效的，只有真正本来需要手工的测试被自动化执行时才有意义。
        所以，在度量上，一定要保持维度一致，可以横向比对，即不同模块之间进行比对，有效性上可以从自动化测试模块的应用场景和执行次数、执行频率去评估，成本上，即是自动化测试开发和维护成本

三、度量一个自动化测试的可实施性可以从其可控制性或者可测试性上来考虑
       来源:自动化测试可测性分析
        有的人说单元做自动化比较好，有人说接口测试做自动化比较好，但奇怪的是也有人说他们做界面自动化比较成功，其实说接口测试和单元测试比较好的人，单元测试往往是开发来定义的，所以开发来控制可测性，接口测试的话，接口协议都是约定好的，所以可控制性和可测性有保证，而界面的话，有些产品的界面可测性控制比较好，例如都有唯一的debug id，或者界面变动性很小，那么也是考虑可以用界面自动化的。所以说，我们在推广自动化测试过程中，不是人云亦云，而是要结合当时的环境，从可测性上去考虑自动化测试的开展。

四、试点推进自动化测试
       来源:自动化测试推广
        自动化思路重要，但是做自动化本身也是具有一定机遇性的，其环境相关性很大，所以在开展自动化测试前，一定不要过度自信，铺天盖地的推广，而是要找好试点项目。之前做过一个接口录制工具给测试人员推广使用，由于不是试点分析，每个组的测试人员拿着这个工具开发了一堆一堆的线性脚本，导致存积了大量的接口线性脚本，然后后来由于脚本的维护性和不稳定，慢慢的流于形式，甚是可惜。如果采用试点分析的方式，先在小范围进行使用，并且跟踪效果。
       业内有一个分层测试的理念很好，可以基于IP和地域选择性的发布新产品，根据使用效果，然后再根据情况逐步推向全国。

五、自动化测试框架的重要作用之一是为了职责分层
       来源:自动化测试推广和框架建设
        所谓软件框架功能，我觉得很重要的一点是能够将每一层次的责任细分出来，数据驱动框架就是将数据单独抽离，让测试人员能更有效的管理数据，例如:可以构造重复的、组合的、随机的或者大量的数据包;关键字测试框架就是将对象封装、任务封装、业务组装分层，这样，可以让代码能力稍强的人员面对对象和任务封装，让业务能力稍强的测试人员面对业务组装，这样可以通过框架将各个人员的职责细分，做自己所擅长的事。
       关键字框架推荐robot framework,利用其可视化界面ride，其中还有一些拓展包，例如selenium2Lib可以应用在web测试。

六、可以的话，让开发一起参与自动化测试
       来源:自动化测试可测性分析
        曾几何时，我基于RFT和QTP都试点推行了公司的界面自动化，但是效果不佳，究其原因还是界面的变化太大，加上一些自定义控件或者一些自定义图片展示的动态搜索无法查找，只能用存储对象的方式，后来大力发展接口自动化，将界面自动化先搁置了一段时间，后来开发自己做了一部分自动化，说是效果甚佳，去学习才发现，他们有一些图形和事件是基于xml配置定义文件描述的，这样利用JDOM技术，解析出文件，然后根据QTP的脚本编写规范，生成QTP脚本，而测试动作基本上涵盖增删改查。这种情况是我们测试之前无法知道的，因为开发流程原因，我们无法知道开发所采用的开发技术，所以说，我觉得可以和开发一起来评估自动化测试。

七、自动化测试是可以成为一种习惯的，尽早自动化
       来源：自动化测试推广
        之前，和几位华为的开发朋友聊天，问他们一个问题：你们自动化怎么样，我原来以为开发是不太了解自动化的，没想到他们给我的答案是，什么怎么样，这是必须做的工作呀。原来他们华为的持续集成过程，开发自己写测试脚本做冒烟测试，以前这是华为的规定，现在是他们开发人员的一种习惯。
所以，我觉得，推广自动化不一定一开始就要大张旗鼓的，也不是所谓的等到一切时机成熟，自动化测试是一种辅助测试的方法，不同的情况可以采用不同的方式，几行脚本，一个bat部署文件，一个数据统计，也是自动化的一种应用。用另外一种说法:不管黑猫、白猫，能抓到耗子的就是好猫。

八、自动化应该立即见效，见效后应该慎重评估
       来源:自动化测试推广
        有时候如果我们对目的不够清晰，不能抓好本质问题解决，就很容易走极端，有人说录制不好，我们就反对录制，有时候我们抓到一个录制工具就以为遇到了神器，孰知后面是一个一个的大坑；而我觉得，录制不是不好，而是如何将它用在合适的地方，录制的好处是无需编程技能即可快速上，但是他的缺点是相对脆弱，一旦UI或者接口变化测试就会受到影响，分散的脚本不可重用且难以维护，而且系统在测试前必须可用（也就意味着无法使用A-TDD方法）。因此这种方法并不适合大型自动化测试。而关键字驱动，将数据与关键字结合来描述如何使用数据执行测试，这种方法是具备数据驱动的优势，同时非编程人员也能建立新类型测试。所有测试由同一个框架来执行，无需不同的驱动脚本。然而初始成本很大，但是可以使用开源方案，因此非常适合大型项目。所以，我们刚开始的时候，选择合适的项目，可以采用脚本录制这种方式，让自动化测试立即见效，小范围推动项目进度，然后，就严格控制，开始设计框架，把握可测性。

九、不要指望用自动化测试平台一下子解决所有的问题
        来源:自动化测试平台建设
        当年在作自动化测试过程中，遇到瓶颈，就想当然的认为要开发业内所说的自动化测试平台，即先弄出一个线，然后再想办法去线上发展每个点，后来历时几个月，加班加点的，总算基于STAF开发出了一套分布式的自动化测试平台，但是后来用着用着就不了了之了，分析出原因是问题本身和目的都没有明确，单纯的开发出了一个架子，然后再去找衣服强塞进去是不可行的，架子本身是为放衣服服务的，所以平台本身是为让自动化更有序的进行而服务的，之后我们大力发展点，而平台是等点都满足需求后，开始将点串起来，自然而然的形成了一条线，然后再加以修饰，就成为了平台。所以说，不要舍本求末，追求花哨，而要踏踏实实的做好每一个点，以需求为导向，自然而然的才能把架子搭好。
       在这里也推荐几个用来搭建平台的较好的工具和框架:STAF, Jenkins,selenium grid可以用来做分布式测试执行和测试节点管理，sonar可以用来做质量管理平台，更多的是面向白盒测试分析。Toast也是一款不错的自动化测试平台，我觉得它的理念更多的像项目管理+jenkins。

十、将所有的测试资源都版本控制起来
       来源:自动化测试配置管理
        这个很重要，在我们的自动化建设过程中，因为我们是多产品线的，每个产品线的有些功能模块是共用的，我们的方法是将每个模块的功能抽象成关键字接口，所有产品线共用接口，只是实现上不一样，而这种方式前期的问题是版本管理的问题，因为一个产品线开发出一个模块后，各个产品线开始互相迁移，导致迁移混乱，还有一个问题是产品功能模块也在不断的更新，不同的产品版本要对应不同的测试脚本，所以后来，加入版本管理，而最终的测试脚本版本用V1.0.0进行跟踪，第一位表示接口版本、第二位表示产品特性，第三位表示当前产品线的脚本维护。
       版本控制中重要的两个概念就是分支与合并，随着开发的版本控制的不断深入，测试的版本管理也需要跟上，常用的版本控制工具是svn、cvs以及分布式版本控制git，和基于流的版本控制系统Clearcase，个人觉得，前期可以用手工的方式定义好版本，等到开发协作强大到一定程度后，可以采用这些版本控制系统。

十一、 时刻反省自动化测试过程
       来源:自动化测试推广
        自动化测试是一个长期的过程，我们即要低头走路，也要不时抬头看路，也需要不时的休息一下，回顾自己走过的路程，整理之后才可继续向前，所以需要我们每隔一个阶段，就要好好反省自动化测试的开展和推广过程，大家的时间都是很宝贵的，珍惜自己的时间，更要珍惜大家的时间。

        总结;因为时间仓促和水平有限，有些经验和教训不一定很全面，或者还有朋友在推广或者平时观察到有更好的自动化测试实践经验和教训，希望可以一起总结，总之，个人觉得，学习过程最有效的方式是理论和实践相结合，知行合一，在实践中发现问题，然后去推敲理论，解决问题，最终总结从而变成自己的东西。—散步的SUN

更多测试技能在线学习，更多测试文章，请访问http://www.zhibokeji.com/