关于自动化实施过程思考（2）

模式选择：全员皆可写接口

之前我们的模式是自动化小组成员翻译功能用例，功能测试人员提供场景用例。我们系统因为是两三年前写的，目前在运维阶段，有些bug因为新的发版导致以前功能出现问题，大概统计了下，约占有5%，于是决定已有功能主干回归。这样导致的问题是自动化人员业务不熟悉，沟通成本提高，而功能用例人员写接口，调试比较慢，导致时间成本比较高。于是乎，开始培训，培训大家基础的RF工具使用，前期比较慢，但是后期工具熟悉了之后，速度也是跟上了。本来想做到TDD模式，但是发版任务比较多，导致写接口会延迟，而且本组女孩子比较多，所以很难推动。我们现在模式功能人员自己完成自己模块的接口用例，测开人员开发小工具，提高效能。小工具：生成测试 报告，每日邮件汇报测试情况等

自动化检验工具：覆盖率    

前面总结了自动化工具以及项目的选型，最近一段时间在做代码覆盖率，这个事情本来是开发做的事情，单元测试之后有覆盖率作为支撑，但是大多数公司开发应该都不会去做单元测试，更别提覆盖率提升了。我们是以java项目作为试点，我之前的博客中也有jacoco部署的博文。覆盖率工具，是检测接口自动化到底能不能被信任的工具。在做覆盖率的过程中，很多以前的代码逻辑测试人员都不知道，就好比每次测试覆盖都是这些，有些压根都不知道测试以外的业务，当然有些意外的bug发生也是常理之中。通过代码覆盖率工具，进一步补充了自动化接口用例，对业务也进行梳理了一遍，从代码角度，校验了更多的异常。但是对于测试，需要基本的java知识，因为我自己写python脚本，所以前几天看java代码还是晕头转向的，而且和开发沟通，还要看开发脸色（毕竟这个不是开发任务）。知道了业务覆盖缺失，你还要将以前的业务梳理出来，流程怎么如何如何，也是各种问，总之很不顺畅。不过最后除了一些异常操作难以覆盖，还有第三方系统的，除去冗余代码，覆盖率达到了95%左右。

最后：

自动化只是测试手段，是为了功能服务，只是辅助手段。只有用好了，才能发挥最大的价值，不然就是鸡肋。