如何改进测试自动化结果的报告和监控

目前，我们的新网络应用程序随着我们的主要产品每天发布数十个版本，找出端到端测试失败的原因变得更加重要。我们每天都在与测试缺陷（即与被测应用程序实际缺陷无关的失败）作斗争，基于 Selenium 的测试平均成功率已超过 99%。这意味着在通宵运行的稳定主分支上，失败的测试不到 1%，这表明偶尔的失败仍不可避免，可能会造成不确定性。这是众所周知的用户界面自动化问题，可能会经常发生，尤其是在我们没有模拟任何后端服务的暂存环境中。

我们认为，最佳答案是让每位质量保证工程师或开发人员都能轻松、快速地识别特定测试失败是否仅与检测到该失败的分支/PR 有关。因此，良好的报告工具和仪表板是必不可少的，它们可以让我们全面了解所有存储库工作流程中的测试执行情况。

当前设置

我们更新的端到端测试执行、报告和监控设置包括：

• GitHub Actions (GHA) 工作流

• 在Google Cloud (GCP) 上为测试工作定制运行程序

• 用于生成测试报告的Cluecumber Maven插件

• 用于存储测试报告的Google Cloud Storage (GCS) 存储桶

• 从Cucumber JSON报告文件生成Kafka日志条目的测试框架插件

• Kafka消息代理

• 用于处理 Kafka 消息的 Logstash

• 用于数据存储的 Elasticsearch

• 用于数据可视化和探索的 Kibana

• Grafana和Slack用于对重复出现的测试失败发出警报

测试报告云端存储

我们之前使用内部Jenkins实例进行测试执行，并且由 Cluecumber 插件（html 页面）生成的报告可以作为工件附加到每个运行的作业，并且当在浏览器中访问时，Jenkins 也会将它们作为网页提供。

现在，通过 GitHub Actions 触发测试执行，并在GCP上的自定义运行器中执行测试作业，我们需要找到一种存储和访问测试报告的解决方案。将它们作为压缩工件附加到每个 GHA 工作流程运行是第一个解决方案，但它很不方便，因为它需要下载和解压缩每个报告，也使仪表板的任何直接链接变得更加复杂。

我们考虑使用 trivago 技术堆栈中已有的内容，并特别选择利用 Google Cloud 存储，将测试报告上传到 GCS 存储桶，通过支持文件列表的 gcs-proxy 应用程序将其作为网页提供，其灵感来自于https://GitHub.com/springernature/gcs-proxy。这就是我们创建“测试报告服务器”来满足我们的需求的方式。

我们以前使用内部 Jenkins 实例执行测试，Cluecumber 插件生成的报告（html 页面）可以作为工件附加到每个作业运行中，在浏览器中访问时，Jenkins 也会将其作为网页提供。

现在，我们通过 GitHub Actions 触发测试执行，并在 GCP 上的自定义运行程序中执行测试作业，因此我们需要找到一种存储和访问测试报告的解决方案。第一个解决方案是将它们作为压缩工件附加到每个 GHA 工作流运行中，但这样做很不方便，因为需要下载和解压每份报告，也使从仪表板直接链接变得更加复杂。

我们考虑了使用 trivago 技术栈中已有的东西，并特别选择了利用谷歌云存储，将测试报告上传到谷歌云存储桶，通过支持文件列表的 gcs-proxy 应用程序将其作为网页提供，该应用程序受到 https://GitHub.com/springernature/gcs-proxy 的启发。这就是我们创建 "测试报告服务器 "的方式，以满足我们的需求。

测试执行完成后，当前的测试流程包括：

• 将测试结果（来自 Cucumber JSON 文件）记录到Kafka

• 使用 Cluecumber 插件生成带有附件的 html 页面测试报告

• 将生成的测试报告文件夹上传到“测试报告服务器”GCS存储桶

• 根据工作流程要求，将测试报告的链接作为 GitHub 状态徽章、PR 评论、Slack 消息等共享。

上传步骤很简单，需要gsutil在 GitHub Actions 作业中运行命令：

1. name: Upload test report to the GCS Bucket

2. id: uploadTestReport

3. if: ${{ always() }}

4. run: |

5. gcloud config set auth/impersonate_service_account serviceaccount-email@our-test-project.iam.gserviceaccount.com

6. gsutil -m rsync -r "${{ env.REPORT_LOCAL_PATH }}" "${{ env.DESTINATION_BUCKET }}/${{ GitHub.repository }}/${{ GitHub.workflow }}/${{ GitHub.run_id }}"

我们决定按存储库、工作流程和运行 ID 来组织报告。事实证明，这非常有效，当公司内更多团队开始在他们的项目中使用我们的测试报告服务器、存储端到端和 API 自动化测试报告以及 Webpack 捆绑分析器报告时，可以轻松扩展。

Kibana 和 Grafana

由于登录 Kafka 包含测试报告链接，因此我们不仅可以查看 Kibana 仪表板中已有的失败消息，而且只需一键单击即可轻松获取完整的测试报告，立即访问步骤执行详细信息、屏幕截图和视频记录。

一组不同的面板和过滤器允许我们的每个 QA 工程师和开发人员快速关注某个分支或测试结果。我们目前有一个仪表板的主模板，可重复用于不同的项目和测试工作流程，但具有详细数据的多个字段的可用性也使每个团队都可以构建自己的具有相关信息和过滤的仪表板。

最近对现有设置的进一步补充是，当单个测试场景跨多个分支/PR 失败时，利用 Grafana 触发到 Slack 通道的通知。这样我们就可以避免在白天主动扫描片状测试，并且它支持我们在应用程序主分支上过夜运行的缺陷检测作业。

Grafana 查询如下所示：

    doctype: "regression_tests_warp" AND (project: "warp_core_mobile" OR project: "warp_core_desktop") AND status: FAILED

我们按场景名称执行聚合，并对基本 URL 的唯一计数应用给定阈值，以确定发生故障的不同预览计算机的数量。由于基本 URL 与 PR/分支名称相关联，因此它提供了一种简单的方法来识别故障是特定于特定分支还是广泛存在。

如果满足查询条件，则会以 Slack 消息的形式发送警报通知，其中包含有关失败测试的指示以及指向更详细的 Kibana 仪表板的快速链接。

结论

测试结果报告和监控的原始方法一直依赖于 Kafka 和 ELK 堆栈，随着我们对这种方法的不断迭代，我们成功地通过快速提供广泛的反馈来大幅提高测试自动化的信任度，同时还在其中添加了 Grafana 警报功能。同时，云测试报告存储项目也被证明是其他采用该项目的团队的宝贵资源，因为它与特定的测试类型、测试框架或所使用的报告工具无关。

总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

1. 文档获取方式：

3. 加入我的软件测试交流群：680748947免费获取~（同行大佬一起学术交流，每晚都有大佬直播分享技术知识点）

这份文档，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！

以上均可以分享，只需要你搜索vx公众号：程序员雨果，即可免费领取