13 | 自动化测试：DevOps的阿克琉斯之踵

作者回复: 其实说到底开发也好，测试也好都是为业务服务的，比如我之前内部创业的时候做了一个游戏平台，业务的目标非常激进，可以说在原型产品化的过程中，是没有测试环节的，基本就是产品经理在试用，研发自测的模式，因为业务的快速拓展和迭代是最重要的。 回到你说的这个问题，如果想要跟上快速研发的节奏，在投入产出比能够接受的前提下，只有单测能在迭代周期里面同步实现，原因就是单测覆盖率是纳入到质量门禁指标里面的。对于接口测试来说，挑战不在于接口自身，而在于测试数据的准备和环境的准备方面，另外如何研发测试可以基于同一个接口管理平台来进行接口的定义，开发，调试，这对于实现你所说的拥抱变化会更有帮助，工具层面类似swagger这种框架使用到的还是蛮多的。

作者回复: 这个问题特别好！其实我发现，很多公司对于单元测试的态度都是覆盖率驱动的，也就是先定义覆盖率，再后补单元测试用例，写单测的目的就是为了通过覆盖率检查，这样做虽然结果覆盖率上去了，但实际就会出现你所说的问题，花了大力气却没啥提升，核心原因是从一开始的目标就错了。 我们这边也在推单元测试，但做与不做，覆盖率要求多少，由团队自己决定，平台团队只提供工具和数据量化的支持，先解决为了做而做的问题。在保证核心逻辑被覆盖之后，比较好的做法是通过发生的缺陷和问题适当的补充单元测试case，保证这类问题不再发生，并且重新审视测试的逻辑是否覆盖了多种场景。考查的指标在于有多少缺陷可以被单元测试覆盖，当然不建议把这个指标跟KPI挂钩，而只是为了团队内部学习，甚至适当的奖励识别出最多可以被覆盖问题的成员。 另外，在团队内部是否可以沉淀一个持续更新的单元测试手册也是很好的习惯，在手册中可以积累如何写一个好的单元测试，命名规范是怎样的，哪些场景需要优先覆盖，常见的错误是怎样的，这会帮助团队成员不断学习。 至于你的问题本身，说的其实还是如何度量生产力的事情，我推荐一篇文件给你： [https://www.martinfowler.com/bliki/CannotMeasureProductivity.html](https://www.martinfowler.com/bliki/CannotMeasureProductivity.html)

作者回复: 是的哈，这也是为什么自动化在回归领域比较推荐的原因，通过固化一定的测试用例集合，配合自动化的方式，来让繁琐的操作简单化，人力投入到更有价值的测试类型中。

作者回复: 哈哈，感同身受，IT的进步就是历经磨难的过程，以我自己做开发的经验来说，完全封闭即便在公司内部也很难实现，即便一家公司的业务流程是E2DD模式的（Excel&Email驱动开发），在搬到线上化的过程也很难采用封闭革命的方式来颠覆现有流程，对自动化来说适当的灵活性和扩展性非常必要，一方面可以同已有的工具快速打通，不用什么都重新实现一边，另外一方面给有能力做一些扩展的团队留出余地，这一点蓝鲸的产品就比较值得借鉴，也是自动化成熟后的必经之路吧。

作者回复: 我们使用的不是什么高深的技术，TestNG就可以实现了，主要是框架的能力要支持，当控件定位发生改变时，不会影响我们在操作层的方法封装代码，把一处控件改动对应多处引用修改的一对多关系变为一对一关系，即无论引用了多少处此控件，只需要修改一处代码。 解决办法：为了使操作层在获取控件时与控件的定位方式解耦，在操作层通过获取自定义ID的方式来得到控件对象。此ID需要在控件的配置文件中定义好，再通过操作层之下的代理层来统一处理。