# 您听说过“脆弱测试”吗

关于什么是“脆弱测试”以及如何避免它们，有很多文章，博客文章，播客，会议讨论。

在介绍解决脆弱测试的技术之前，让我们了解一下测试片状/断续的典型原因。 测试中不稳定的原因 有许多原因导致测试可能不稳定/断断续续。 让我们看一些具体的例子，看看为什么在上面提到的每个方面测试都是不可靠的

# 同步/定时相关问题

例子：

由于前端处理，页面加载耗时，

异步处理

在后端API /服务器上加载导致响应延迟，

在测试实施中没有使用正确的“等待”策略，

装载框架/重物/内容物等

# 日期/时间相关

例子：

基于时区，午夜的错误时间计算

基于月/年的错误日期计算

使用每个特定服务呼叫要求的错误的日期-时间格式/时区

# 网络问题

例子：

网络中的数据包丢失

网络连接不稳定，

网络负载过重，导致连接速度较慢，

模拟慢速网络状况（例如2G速度）等时产品行为不一致。

# 浏览器相关问题

例子：

每个浏览器的行为都不同，并且使用不同的资源。

浏览器中安装的插件/扩展程序可能会增加渲染速度，内存使用量等方面的波动。

根据浏览器及其视口大小，需要使用不同的定位器识别策略。

# 数据依存关系

动态数据，可用数据的可用性或有效性发生的变化（由于其他同事/使用该数据的测试/对其进行更改/正在使用它）

缓存策略可能不正确

测试开始运行时，被测应用程序的状态不正确

# 定位器策略

例子：

怪异的xPath /定位器，由于数据/ UI中的微小（不相关）更改而发生更改

定位器根据被测应用程序的响应渲染进行更改

# 被测应用程序环境问题

例子：

不稳定的组件，正在进行的组件部署

环境中集成的3方组​​件/系统的不稳定性

其他持续使用的环境（可能是其他类型的测试，性能测试等）可能会使环境变慢，从而影响测试的执行

# 测试执行机问题

例子：

在并行/后台运行的其他进程/应用程序/浏览器会话将最终导致设备/浏览器资源的竞争和共享，从而影响测试执行

运行测试的机器的局限性（处理速度，内存等）

执行测试所需的软件版本不一致/不正确会导致测试在某些计算机上失败

# 测试执行排序问题-顺序更改时，测试是否会间歇性失败？

例子：

测试依赖于其他测试（用于设置被测应用程序的数据/状态）

# 并行执行问题

例子：

并行运行时测试间歇性失败

被测应用程序中的实际问题/缺陷

例：

# 加载应用程序

比赛条件

与其他系统/服务/数据库的间歇性连接 反模式–方法（许多）团队用来处理测试脆弱性！

反模式1：自动重新运行失败的测试

重试一次并祈祷测试通过

重试两次并再祈祷

重试三次并祈祷更多

……

如果团队很幸运，则测试会通过，并据此进行报告-即，将污垢推到地毯下面，声称一切都很好。

但是，我觉得团队在这种情况下并不走运–因为他们错过了在正确的时间，正确的位置找到，报告和实施修补程序的机会！

您认为这是个好方法吗？

我绝对不同意这种方法-它不会帮助任何人。

反模式2：测试中的智能重试

有些工具/解决方案具有有趣的功能，这些功能将允许自动重试，或者可以配置为自动重试测试中的某些操作以处理间歇性故障。 这些操作可能用于重试单击，检查元素的可见性，或者可能是一些网络API调用等。

但是，我认为这种方法也不正确。

如果重试成功但第一次由于性能问题或其他问题而失败怎么办？ 如果您的测试遇到此问题，那么最终用户也面临类似问题的可能性是什么？ 他们会重试吗？ 考虑一下。 实际上，测试的所有方面都应该考虑最终用户将如何使用您的产品，以及当他们与被测应用程序的交互产生意外行为时，他们将如何应对/处理情况。

不幸的是，我所指的工具将其突出显示为一项重要的新功能-这将促进恕我直言的不良做法。 测试实施

测试是否仅按特定顺序一致执行（按照预期）？

如果顺序运行失败或与其他测试并行运行，测试是否会间歇性失败？

测试是否在特定的浏览器/设备上间歇性地失败？

测试在特定环境中是否会间歇性失败？

测试数据是否更改/无效？

间歇性故障是否与计时/等待条件有关

环境/被测应用的稳定性

测试失败时是否发生任何部署/维护活动？

故障更频繁出现的任何特定时机趋势

测试失败时，环境上是否有异常负载？

服务器资源使用情况是否有任何异常统计信息？

网络分析

与网络团队合作确定

测试失败发生时网络连接是否有故障

测试失败发生时网络上的负载是多少

由于您可能无法非常轻松地复制故障，因此为了帮助进行此类调查，必须启用并提供大量日志记录至关重要。 减少测试中片状感的技巧和技术

现在，您已采取步骤进行适当的调查，并通过RCA查找间歇性故障的原因，查看您的应用程序的上下文，团队技能，基础架构等，从而提出解决问题的“正确”解决方案 在源头上。

作为解决方法，最糟糕的事情是盲目地增加等待时间或重新运行测试以希望它通过。 不要那样做！！

解决片状测试的“正确”方法可能意味着以下任何一项或多项，甚至更多–

架构审查和变更

基础架构设置和管理

服务/数据库/硬件的配置

实现快速反馈的做法

促进合作的过程

监控和可观察性，以实时了解部署系统的环境和状态

面向较低环境中的外部系统的智能服务虚拟化，可为您提供更多的控制，可预测性和能力，以测试正面，负面和边缘案例场景和工作流程 外部系统

日志记录–为了防止/减少为了重现间歇性问题而不得不重新运行测试的情况，默认情况下启用大量日志记录至关重要。

以下各种形式和类型的日志很有价值，因此是必需的：

测试执行日志

网络日志–即捕获网络流量，作为功能测试的一部分，以了解特定网络呼叫中的任何掉线/问题。 例如：HAR（HTTP存档格式）捕获可以为您提供很多见解

设备日志（如果适用）

屏幕截图（如果无法通过失败的视频录制）

对应的应用程序日志

系统运行状况日志–即服务器端内存/ CPU使用率和响应时间

在许多情况下，上述调查需要在各种角色之间进行协作，因为任何一个角色都可能没有整个系统的完整上下文。

外卖

认识到测试可能不稳定或断断续续的原因

批判创可贴方法修复测试中的脆弱性

讨论确定测试剥落原因的技术

解决根本原因，而不是症状，以使您的测试稳定，可靠和可扩展！

# author

石头 磊哥 seven 随便叫

# company

thoughtworks（离职了。。。。）

大家好，本人不才，目前依旧混迹于thoughtworks，做着一名看起来像全栈的QA，兴趣爱好前端，目前是thoughtworks 西安QA社区的leader，如果有兴趣分享话题，或者想加入tw，可以找我

# roles

QA（营生） dev（front-end dev 兴趣爱好）

# 联系方式

如果想转载或者高薪挖我 请直接联系我 哈哈

# wechat:

qileiwangnan

# email:

qileilove@gmail.com