如何保证自动化测试的可信性？

对于自动化测试的可信性，这是一个与自动化测试ROI（投资回报率）紧密关联的关键问题。自动化测试的可信性，不仅关乎自动化的持续性和价值，更重要的是它是否能够准确、真实地反映产品的质量状态。

举例来说，假设你的自动化测试报告显示"我的收藏"用例执行失败了，但是在我们检查运行日志信息后发现，失败的原因是试卷列表接口调用失败，无法获取试卷ID，而非业务场景本身的问题。同理，如果你的API自动化测试报告一直显示成功，然而在生产环境缺出现问题，分析原因原来其中一个API的响应数据中有一个字段的类型早已从int变成了str。但是自动化测试未能检查到这个字段，因此漏掉了这个问题，使得产品出现了缺陷。

以上两个例子都揭示了一个重要的事实，那就是自动化测试的可信性是衡量其是否能准确反映产品真实质量状态的重要指标。如果自动化测试经常误导报告的使用者，那么其快速可靠的价值就会大打折扣。因此，如果你的自动化测试项目存在可信性不足的问题，那么解决这个问题就显得尤为重要。

可信度分析

我们首先对自动化测试报告的可信度进行深入分析。我们将测试结果（成功或失败）与产品功能（正确或错误）进行组合分析。

结合上图我们可以看到四种情况：

自动化测试执行通过，产品功能正常。
自动化测试执行通过，产品功能出现问题，漏检。
自动化测试执行失败，产品功能正常，噪音。
自动化测试执行失败，产品功能出现问题。

我们期望的结果是情况1和情况4，这两种情况下，自动化测试的结果准确地反映了产品的功能质量。

然而，我们需要避免的是情况2和情况3，因为在这两种情况下，自动化测试的结果并未正确地展示产品功能的质量状态。具体来说，情况3会导致无谓的维护时间浪费，我将其定义为"测试噪音"。

而情况2可能会导致问题在生产环境中出现，我将其定义为"Bug漏检"。为了避免情况2和情况3的发生。

我们可以采用数据分析法，该方法可以分为两步：首先，我们需要找出问题的原因；其次，我们需要找到解决这些问题的策略。

度量方法

那我们有哪些度量方式呢？我们来说说一些实现思路。

基于BUG数

我们在自动化测试过程中，用例执行失败我们会自动在缺陷管理平台新建一个问题，如果问题确实功能存在问题，就会指派给对应开发进行修复，如果提交的问题是非bug，我们就直接标注为非bug，脚本问题，进行关闭。

我们每个月都会统计自动化提交了多少缺陷，真实问题多少个，非bug多少个。

同理，我们会记录线上bug的缺陷数，我们对所有的问题进行分析、归类，将自动化覆盖到的功能漏测的bug也标注一个状态，自动化已覆盖。

虽然基于Bug的量度在理论上听起来可行，但在实际操作中，我们会遭遇到一些挑战。主要有两个因素会导致我们的度量不全面：首先，这将增加人工的工作负担；其次，人的主观判断可能会对度量结果产生影响。

这两个因素可能导致度量的收集不全面，也可能导致其准确性受到影响。例如，如果没有标记Bug，它就不会被统计在内；如果Bug被错误地标记，那么结果就会有所偏差。标记错误是一种常见的情况，比如一些人可能会把Bug归类为UI自动化测试的漏洞，而另一些人可能会认为它是API自动化测试的漏洞。不同的人对同一Bug的归类可能会有所不同，从而导致统计结果的差异。

如果我们依赖这种基于Bug的度量方法，我们的改进目标可能会难以实现，原因在于数据可能会被篡改或者造假。实际上，这种方式违背了度量原则，即度量数据应当源于未经人为处理的原始数据。因此，我们需要继续寻找更为合适的度量方法。

程序代码

那么，是否存在一种方法可以通过编程代码来判断失败是由漏检还是噪音引起的呢? 也就是说，在自动化测试运行失败时，我们的代码能否自动识别这是产品的问题，还是自动化测试代码本身的问题呢？

我们已经确定了一个方向，即应用关键问题法，我们可以提出以下问题：“产品的错误和测试代码问题存在哪些区别？”。

def test_resource_lib_addLecture(self,beike_user_session) :
"""资料库添加备课"""
self.core_fm.get_xkw_resource_list(beike_user_session,json=params)
res = self.core_fm.resource_lib_addLecture(beike_user_session,json=data)
with assume :
assert res.json()["body"]["message"] == "此资源添加备课成功哦~"
assert res.json()["body"]["code"] == 0

这是一个资源库添加资源到备课的功能，操作逻辑如下：beike_user_session 获取用户登录信息，get_xkw_resource_list获取资料列表信息，resource_lib_addLecture进行添加备课操作，断言响应信息的一个 message 和接口响应code码。

这段代码可能出现的问题如下：用户登录异常、资料获取失败、加备课失败等，这些任何一个问题的出现都会导致资源库添加资源到备课的功能失败。

我们来分析一下这些失败情况，哪些是噪音、哪些是漏检、哪些是真实业务问题呢？

用户登录异常、资料获取失败等情况属于噪音，是自动化测试代码本身的问题，需要自动化测试人员来解决。而加备课失败则属于真实业务问题，代表着一个产品的错误，需要开发人员来处理。

通过分析代码，我们可以确定这些噪音和真实业务问题的失败出处。其中，产品错误是通过 assert 语句捕捉到的，这些 assert 语句是关键的测试逻辑。而除了 assert 语句之外的代码是辅助测试构建的，它们需要保证健壮和稳定。

到此，我们就得出一个合理的规则，可以区分出产品错误和噪音问题：assert 检查点的失败，是产品错误，其它的失败都属于自动化测试代码健壮性的问题。

通过这个结论，产品错误和噪音的度量公式我们就找到了，即：

产品错误率 = assert 语句引起的失败次数 / 自动化测试失败的总数

噪音率 = 1 - 产品错误率

通过程序代码的数据采集是可以完全自动化的，不需要人工参与。前提是程序代码度量方式需要基于一个规则，那就是测试人员把验证逻辑都用assert语句进行判断。因为我们可以在自动化框架里面拦截 assert 失败的情况。

漏检这个我们还是需要通过人工的方式进行，因为这是通过其他人反馈才能拿到的数据，需要经过人工识别判断，我们只能通过增加更多的检查点来进行，基于这个逻辑，我们可以把验证点的数量 / 测试案例作为一个度量，就是每个测试案例中出现的验证点数量，来驱动自动化测试人员养成在测试案例多做检查点的习惯，最终达到减少漏检的目标，但是这又涉及到成本、收益、范围的问题。

完整度量周期

一个完整的度量周期可以分解成四个阶段：

定义度量：建立度量指标，设置度量目标
数据收集：收集原始数据，聚合成度量指标
问题归因：查看度量数据，并找出问题
优化提升：提出和应用解决办法

经历完四个阶段后，一个度量循环周期便圆满结束。此后，我们可以再次启动第一阶段"定义度量"，进入下一个循环周期，以实现持续优化直至度量满足设定目标。一旦达成这一目标，我们便可以思考更换新的度量指标以进一步提升性能。如下图：

就拿前面我们说的噪音率度量为例。在第一个循环周期，我们先采集出来噪音率是多少，比如是 70%。

接着我们从第二个循环周期开始，设置噪音率的目标是控制在 30%，推动团队想尽办法，通过技术或流程，来降低噪音率。然后是第三个周期，如果得到噪音率是 30%，那说明办法奏效了，继续努力，直到最终噪音率目标达到 5%。

为了保持，我们可以把噪音率保留在度量列表上，这样，一旦有什么变动影响到了噪音率，我们可以快速得知，做出对应调整。

第一步的度量设计和第四步的改进办法，需要测试Leader带领团队完成。而第二步和第三步，数据的采集和分析，应该自动化来完成，不需要人工的干预。

怎么提高可信度

在实践中，我们可以通过以下几种方式来提高自动化测试的可信性：

完善自动化测试用例场景：保证测试用例覆盖所有重要的业务场景，并且对每个测试用例进行详细的描述，包括预期结果和实际结果。
完善的执行记录信息：当测试失败时，应该有足够的信息来帮助我们定位问题。这可能包括日志信息、截图、甚至是视频录像。
提高测试的稳定性：提高自动化脚本的容错处理能力，例如增加异常判断、重试等机制保证用例的正常执行。
定期评估和调整：自动化测试不应该是一次性的任务，而应该是一个持续的过程。我们应该定期评估测试的效果，根据产品的变化和测试结果来调整测试策略。
增加结果验证的深度和广度：对接口测试来说，不仅要验证返回的状态码，还要验证返回的数据是否正确，甚至要验证接口调用后的数据库变化、系统日志等是否符合预期。
增加代码审查和持续集成：在自动化测试的编写和执行过程中引入代码质量检查和持续集成，可以提前发现并修复问题，从而提高测试的可信性。