小程聊微服务-增艺眼中的自动化测试

本文主要是介绍小程聊微服务-增艺眼中的自动化测试，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

如果说“生活不只有眼前的苟且，还有诗和远方”的话，那么自动化测试可以说是很多测试人员心中的“诗和远方”。

这里写图片描述

“诗和远方”OR“禁果”

测试自动化，需要持续改进。但由于其本身是一种过于激动人心的想法：用程序去测试程序——解放了测试人员的生产力，节省大量的人力成本，这就有点“禁果”的意思了。

一个常见的行动模式是：在实施自动化测试时，设定一些量化指标，例如根据业务、接口、模块设置的覆盖率。技术团队在完成指标的过程中，以完成指标为中心而忘记了为什么要进行自动化测试。其结果是各项指标都完成了，但是没人能说清自动化测试的效果和价值，而技术人员也没有热情再继续下去。最终，自动化测试只能“被完成”了。

那如何避免自动化测试的诱惑，或者降低诱惑的影响呢？

三观，你的三观要正

自动化测试，有开发的过程，有测试的过程，说到底，依然是测试的过程。所以自动化测试，依然遵循测试活动的基本内涵：反馈信息——它是帮助技术团队获得关于软件产品质量信息的反馈手段，这是实施自动化测试的中心。评判自动化测试是否有效的标准，就是自动化是否能够帮助技术团队获取质量信息，其关键就在于自动化测试的测试分析与设计。

没错，自动化测试的测试分析与设计

什么？自动化测试也需要进行测试分析与设计吗？不是就把手动执行的用例自动化就可以了吗？

确实，自动化测试实施的一个常见的活动模式是：选择工具或者脚本语言、确定哪些手工执行的用例需要执行，录制或编写执行的脚本，配置测试数据，执行测试。这个模式中就没有自动化的测试分析和设计。而对工具的研究学习通常是开展自动化测试的第一步，特别是对于以往做功能测试的同学而言，掌握工具比测试分析和设计是更显而易见的技能加分项。但工具却不是自动化测试的能否有效的关键。

测试分析与设计是测试活动能否有效的关键，自动化测试也不例外。例如，在数据库表结构变更的场景中，我们需要分析如何确认需要进行验证的数据特征？如何构造这些测试数据？如何验证数据结构变更前后，程序对数据新老数据的处理是符合需求的？这些都可以使用自动化的达到手工测试不同的效果。

但这好像和我们认为的自动化测试不太一样呀。是的，自动化测试并非是将手动执行的用例自动化，它有自己的测试领域，像生成大量的测试数据、多组合的测试数据、发起大量的请求、触发资源竞争、执行严格的结果检查、快速报告结果等等，它在帮助你完成手工难以完成的事，而不是帮你完成手工可以完成的事。你的每一次测试活动，如果有手工无法完成的事，那么你就应该考虑自动化测试，并对自动化进行测试分析和设计。而如果没有手工无法完成的事，我们则需要考虑是不是遗漏了什么。

那把手动执行的用例自动化作为回归测试不可行吗？

“啪啪啪”，有可能是打脸

看情况。自动化是否用于回归测试？用例是否自动化？等等，选择一个合适的自动化测试策略，需要关注：测试需求、软件系统结构、人员能力。对于需要从业务的角度进行的回归测试而言，更需要关注产品的迭代节奏或者生命周期。毕竟复杂的业务逻辑、修改已失效的测试的时间成本，通常都会给认为自动化测试能够节省人力成本的人狠狠的一记耳光。

但这并非说业务测试的回归就不能自动化，其关键在于划定业务范围。一个经验是使用“业务逻辑－失效风险”的分析，将业务逻辑按照功能失效后带来的风险进行分析后，圈定高风险业务逻辑进行自动化，严格保证高风险业务的可靠性。另一种方法则可以使用幂律分布，我们常说的2/8原则就是其一个体现：根据生产业务的使用情况，将常用业务逻辑进行自动化，保证其可靠性。

这里我们依然坚持的理念是让自动化帮助我们完成我们手工做不了的，而不是替代手工测试。

“没有两片相同的叶子”，也没有两次相同的手工测试

测试，给人的一个错觉就是重复性，包括有些公司在招测试人员的时候会有一条叫“能够胜任重复性工作”。但试问，谁会手工运行N次相同的测试呢？一个测试人员，他在执行什么测试不重要，他为什么要执行这个测试——背后的分析思考才重要。自动化的测试，能够替代的是相同的执行，却无法替代人的分析与思考。而软件产品在研发迭代的过程，是团队不断地把新的分析思考注入其中的过程。测试工作面对的是始终在不断变化的测试需求。所以测试的分析思考，包括手工和自动化的测试也需要不断地迭代改善。

“只有改善，没有成功与失败”

对于有专门自动化测试的小组而言，通常会以项目的形式开展自动化，制定任务的行动计划表或者里程碑等进行跟踪管理。而个人实施自动化，则相对自由宽松。但无论小组还是个人，为了能够保持持续改善的动力，最重要的一点是让每一步工作是有效的，实施团队或个人能够从自动化测试的过程中及时得到正向反馈。对于小组的负责人而言，这是让团队保持动力的关键。一个经验是，任务拆解细化，参考OODA环，周期性进行回顾调整。另一个负责人必须关心的事是，需要周期告知自动化测试的利益相关方目前的情况，例如技术团队、领导层、上下游合作方等。让大家看到一个持续改进的过程，树立对自动化测试的信心。