五分钟快速理解自动化测试

什么是自动化测试

把人做的事情交给机器做，这就是自动化。其实我是不认同的，应该是把人多次重复的工作交给机器做。而自动化测试则是把测试工作交给了机器，测试环境和被测对象是不变的。下面是人工测试和自动化测试的变化
用例 -> 自动化用例
断言 -> 自动化断言

自动化用例和普通测试用例

自动化测试因为需要给到机器去测试，所以在用例变更时，不仅要定义用例步骤，还要对应完成用例实现。所以一个常常改变的系统不应该为此编写自动化用例。

自动化断言和普通断言

如上面所述，断言也是需要我们编写的，当然借助现有的一些框架，我们可以避免很多的编写。第二个我要说的是，如果你从事过 UI、AI 方面的测试工作，你会发现在反复执行的过程中你会发现某一次会出现一些返回的偏差，这一偏差是由被测对象决定的。设备会在某种环境下，渲染失败或者是异常，而 AI 本身就是一个概率的模型，结果本身就是随机的。所以我们需要编写复杂断言来处理这类问题吗？答案是否定的，我们应该先人工测试保证被测对象的稳定性。甚至我们对于这些用例回到手工测试。

自动化测试用例的颗粒度

在自动化测试中，被测对象和测试环境都是影响自动化测试稳定性的因素。所以针对这两者，我们可以控制用例的颗粒度来降低我们的维护成本。
假设有这样的一个接口，支持门店名称 (name) 和业务员手机号 (phone) 的模糊查询，接口响应数据如下:

测试用例如下,我们针对不同的元数据进行了断言，分别是门店和门店的相关信息。

下一个版本中，业务员和门店从一对一变为一对多的情况我们只需修改门店相关的用例即可。

自动化的环境问题

被测环境如何保证数据稳定性，这一问题其实是测试用例的问题，只不过在手工测试中，我们主动避障了，造不了 A 数据，我们去造 B 数据了。在自动化测试中，由于程序没有我们人那么智能，所以这个问题十分明显。但是这一问题往往是运维的问题，不过我们可以假设我们拥有一个和线上数据库结构一致的数据库，里面没有数据。我们通过 setUp 和 teardown 保证不同用例间互不干扰、和可重复执行，而 setUpClass 和 tearDownClass 则是用于我们有一个基础数据来保证环境已经满足一定的前提条件，全部用例完成后保证环境如测试前一致，它们还是保证我们的用例互不干扰，只是维度更高。

上面的讨论，需要一些运维技巧，包括如何部署数据库、中间件、服务器、等等的一些东西。如果系统架构过于复杂、硬件资源紧张、运维能力不足，可能我们不能奢望我们拥有一个可控的环境。你大概只能编写更加复杂断言来保证你健壮，维护成本会响应提高。

自动化的维护成本

从上面的讲述中，我们的维护成中由维护环境和维护用例组成，在用例维护中，用例逻辑维护和数据维护，是相互影响的 (请不要将测试步骤和测试数据分离当成是测试数据和用例分离，在自动化测试用例中测试数据和用例是一起的) 。我们应该更加倾向于低逻辑维护、高数据维护的这样一种模式。高逻辑会带来一些逻辑错误，从而导致我们使用 bug 来测试 bug。而我们可以用过 execl，数据库，造数平台来提高我们维护数据的效率。

总结

自动化测试并没有和手工有巨大的不同，它的优势在于可以多次执行和大量执行 (批处理是计算机相对人的优势)，执行次数越多，节约工时越多。
对于接口类的自动化测试基本上都可以替代手工测试。对于 UI 测试，AI 测试，嵌入式程序测试等需要人为主观判断的测试，自动化的覆盖率相对有限。自动化测试不能完全替代手工测试。
一个良好的测试环境，有利于自动化测试的开展。
合理的编写自动化测试用例，一份低维护成本的测试用例，是每个测试人员都需要的。