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

目录

前言：

一、所谓自动化是为了软件发布服务的，并不只是为了测试服务

二、不要事后去计算人工替代率，而是要参考自动化测试有效性

三、度量一个自动化测试的可实施性可以从其可控制性或者可测试性上来考虑

四、试点推进自动化测试

五、自动化测试框架的重要作用之一是为了职责分层

六、可以的话，让开发一起参与自动化测试

七、自动化测试是可以成为一种习惯的，尽早自动化

八、自动化应该立即见效，见效后应该慎重评估

九、不要指望用自动化测试平台一下子解决所有的问题

十、将所有的测试资源都版本控制起来

十一、 时刻反省自动化测试过程

---

前言：

        自动化测试是软件测试中的重要环节，它可以提高测试效率、减少人为错误，并加速软件交付。然而，实施自动化测试也面临一些挑战和教训。

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

一、所谓自动化是为了软件发布服务的，并不只是为了测试服务

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

二、不要事后去计算人工替代率，而是要参考自动化测试有效性

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

三、度量一个自动化测试的可实施性可以从其可控制性或者可测试性上来考虑