有了自动化测试就万事大吉？
点击上方“马蜂窝技术”，关注订阅更多优质内容
从「测试灵魂三问」说开去
「不被重视，总是背锅」，相信很多测试圈的人或多或少有过这个感受。从「测试已死」到「去 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。如下图所示：
（3）当 AOS 部署后就会触发用例集的执行，执行完成后平台会收集测试报告，并把结果展示到平台上。
这样就简单完成了代码变更到部署到自动测试的整个流程。
3. 加点调味料数——数据工厂
我们在利用这套机制时，不仅能够服务于自动化测试，还可以用来解决 Mock 数据的问题。
我们知道，一般我们需要其他业务的业务数据，大多是联系业务测试人员，然后等待。这样其实浪费了双方的时间，等待时间和创建时间。我们利用 HAWK 平台的整个运转机制，将 Mock 数据的脚本也接入到平台，让需要数据的人在平台上自行创建即可获得数据，大大节省了效率，达到了很好的效果。
现在平台支持三种业务数据的构造：创建订单、创建商品、创建定制订单。这种模式让接入成本大大下降，可以很快产出页面，增加创建类型。
图：创建商品
图：创建订单
4. 成品出锅——提效成果
最后，说下提效的成果。自动化脚本已经有很大的量了。其中接入到平台并持续运行的用例集，提升了回归的效率在 30% 左右；通过数据工厂自动创建业务数据也为测试人员节省了大量时间。
未来方向
在未来方向上，结合DevOps 理论，HAWK 平台还需要做很多的建设进行优化和扩展。DevOps 覆盖了研发+运维的整个周期，测试人员在其中也应该充分发挥自己的作用，让整个过程流转的更高效更有质量保障。
我们规划上的建设，包括：
Sonar 流程体系：将 Sonar 代码扫描纳入到研发过程中，特别是发布过程中，让开发、测试、产品都可以感知到代码的质量状况；
接口测试的 API 化：接口文档需要更方便的跟随应用代码、应用状态的发展而变化，对开发应该更友好，使用上提升体验；
数据工厂的多样化：构造的业务数据类型可以更加丰富，包括不同的业务属性的数据、不同的类型数据，比方：SQL，MQ 消息等
用例集连接：将用例集与研发流程中的更多环节实现连接。
性能测试的平台化和 App 测试平台化建设
目标只有一个，就是更好的支持业务更好更快的交付，从而实现业务的最大价值。
本文作者：孔祥云，马蜂窝测试开发工程师。
（责任编辑：于雪）
End
你「在看」我吗？
