有了自动化测试就万事大吉？

最新推荐文章于 2024-06-29 19:50:34 发布

马蜂窝技术

最新推荐文章于 2024-06-29 19:50:34 发布

阅读量403

点赞数

文章标签：大数据编程语言人工智能 java python

本文链接：https://blog.csdn.net/weixin_43846997/article/details/104567979

版权

点击上方“马蜂窝技术”，关注订阅更多优质内容

从「测试灵魂三问」说开去

「不被重视，总是背锅」，相信很多测试圈的人或多或少有过这个感受。从「测试已死」到「去 QA」，测试的存在感似乎历来不强。其实，这其中很大程度上来自于大家对测试岗位的固化认知。

上面的「灵魂三问」虽然只是玩笑，但我们还是应该问问自己，如何让测试更好地保障质量提高效率。

这其中很多人都会提到自动化测试，仿佛自动化就是银弹，只要有挑战性的问题，就抛给它。然而交给自动化，真的就万事大吉了吗？

「自动化」只是看起来很美？

问题 1：只有数量，没有结果

这个问题很普遍，很多时候为了解决某个具体问题，我们有针对性地产生了一些自动化的脚本。过了那个阶段，由于种种原因，好不容易创建的脚本就像我们床边的书一样，安静地躺在那里，根本没有被利用起来。

问题 2：无法渗透到整个研发流程中

这比不运行要好很多，在我们不忙的时候或者想起来运行的时候，自动化发挥了它的作用。但是，当有代码变更、应用版本变更、应用上线时，我们不一定会想起它。自动化还是没有真正为降低测试成本和提高产品质量服务。

问题 3：应用场景单一

自动化只能写测试脚本用于回归测试，其他时候我们不会想起它。还是老老实实用手工测试吧。

从上面的三个问题不难看出，要想让自动化真正发挥作用，需要不断的运行，使脚本实现重复利用，并且与整个研发流程实现打通。

传统解决方案的不足

基本上大家在做自动化时，很容易想到自动化框架。许多团队的自动化目标就是产出一个自动化框架。做完框架，就感觉这件事大功告成了，但最后的结果往往是很难落地，推行不下去，不幸沦为 PPT 上的一页。

还有一种解决方案将框架和测试平台进行结合，把脚本搬到测试平台上管理和运行，这样确实有一定的效果。但是因为执行过程大多需要用户手动触发，所以运行的情况却并不频繁。

既然自动化框架不是终点，平台运行的方式又不彻底，解决自动化测试的难题就真的没办法了吗？

当然不。自动化框架和测试平台结合的思路是对的，关键是如何做好这个结合。下面结合马蜂窝平台测试组关于测试工具集 HAWK 平台的打造实践，一起讨论我们关于自动化测试是如何破题的。

HAWK 平台：框架+平台+持续集成

HAWK 平台是马蜂窝平台测试组打造的一款测试工具集，主要目的是为研发内部提供提效工具。目前 HAWK 平台已经应用于接口测试、自动化回归测试、Mock 接口服务、一键构造业务数据等场景下。

1.架构设计

HAWK 平台的整体架构、能力和工作流程大致为：

首先测试人员依靠自动化框架形成自动化测试脚本，自动化测试脚本会在 GitLab 上进行版本管理，这样大家可以很好地协作写业务的自动化脚本。
进入 HAWK 平台后，用户可以在 HAWK 平台配置用例集。配置用例集的作用就是设定一个目标，即运行什么样的自动化脚本集合。用例集配置好后可以通过手动运行、GIT 代码触发、内部应用管理和部署平台 AOS 部署触发等多种方式执行。
执行完成 HAWK 平台会采集运行的结果，可以生成报告供用户查看。
另外还有一个能力是「数据工厂」。数据工厂的目的是为测试同学节省 Mock 数据的时间。同样的数据工厂脚本在用户的触发下，可以自动 Mock 业务的数据。

2. 功能与实现

关于 HAWK 平台的实践部分可以分成三个阶段，我认为这个过程就像炒一盘菜：首先准备食材，把食材切块，然后下锅后加上调味料加工，最后盛出装盘。HAWK 平台基于自动化框架、用例集管理、数据工厂三个步骤，让自动化贯穿于整个研发流程中，在回归测试和构造数据上进行突破，打造一个实用的测试流水线。

1. 准备食材——自动化框架

一般我们写自动化测试的脚本都会用到自动化框架，它的作用就是帮助我们快速构建出脚本用于自动化回归测试，节省时间成本。

我们在基础层用了 SeLion 的框架，主要是为了 UI 和 App 测试用的。然后自己做了一套接口测试框架。SeLion 是 Paypal 开源的产品，可以进行 WebUI、App 等自动化测试（具体的 SeLion 内容大家可以看官网，本文不再缀述）。下面主要介绍我们自己做的接口测试框架。

接口框架的主要作用是让框架辅助脚本的开发。于是，我们吸收了行业内比较好的实践，特别是 HttpRunner 的架构。HttpRunner 是基于 Python 写的 HTTP 协议的接口框架。它通过一个命令行工具和数据文件达到接口测试的目的。这个思路对于接口测试来说，是清晰并且实用的。所以我们借鉴了它的思想，加入了自己的团队特点，实现了通过 YAML 文件和 Test 类开发自动化脚本。

整个接口测试框架分层三层：用例层、框架层和引擎层。用例层是测试人员进行自动化脚本的编写，框架层和引擎层是接口测试框架提供的功能。引擎层现阶段只支持 HTTP 协议。框架层是将用例层的东西串联起来，形成接口测试运行过程。在辅助服务中，提供了一些辅助类，为了框架的丰富性。而驱动部分，仍然是 TestNG 作为组织，SeLion 提供了报告和配置功能。

可以看到在用例层编写脚本，YAML 文件是接口的数据描述，而 API Pool 是对接口的封装，Test 驱动脚本的运行，一些断言也是写在 Test 类的方法里的。

在框架层，我们对 YAML 的数据描述进行解析形成接口测试对象，提供了马蜂窝统一登录的处理（主要作用是在请求中注入 Cookie 信息），并将动态传入的参数注入到接口用例对象中。

在引擎层，我们使用 OKHTTP 进行真正 HTTP 和 HTTPS 请求的处理。通过这样的建设，用例层实现很薄，测试人员只需要简单的学习就可以快速上手写自动化脚本了。而且一旦熟悉了规则之后，后面只需要关注在接口返回数据的质量，是否跟预期一致，对于请求数据的组织就不用特别关注了。

2. 半成品加工——用例集管理

有了自动化脚本，应该怎么更好地运行呢？我们提出的解决方案是基于用例集。通过简单配置就可以创建出回归测试的场景，并且生成结果报告方便查看。

用例集简单来说就是想要运行的自动化脚本的集合。这个说上去有点抽象。我们举例子说明：假设现在要运行几个接口自动化脚本，就可以在 HAWK 平台上进入「用例集管理 (新)」，添加用例集。

这个配置就是要运行用例的配置。必须要填写的就是 Git 地址、分支和 XML 路径或者用例。平台需要知道要运行的用例脚本在哪、哪几个。而数据过滤表达式其实是框架的内容，详细的功能我就不在这里说了。我这里主要说下用例集如何配置 AOS 进行事件式回归测试的过程。

为什么需要 AOS 触发自动化测试？这是因为自动化测试其实在场景上来说更多用于回归测试。这也是自动化测试的最大价值所在。而回归测试不仅仅是测试人员感知到了再运行，需要结合不同研发阶段进行回归。比方说：代码 Push 时、部署时、上线时。AOS 是马蜂窝的应用管理和部署系统。它提供了在构建部署等阶段的 WebHook 功能。我们正好可以利用部署后的钩子进行回归测试，这样就自动化的实现某些测试场景的验证了。主要过程如下：

（1）在 HAWK 平台创建一个用例集，如上图所示。这个用例集就是用来运行接口用例脚本的。

（2）进入 AOS 的应用设置 WebHooks，把用例集的 Hook 地址添加上。我们新建了一个部署后的 Hook。如下图所示：