大型国企自动化测试转型

摘要

做了4年的功能测试，已经习惯了最常用的“点点点”测试，最多再加一些单接口测试，刚接触自动化的时候，对它的理解很简单很粗暴，扑上人去做就可以了，就是大家意识不够，用我最熟悉的手段——“项目推动”，一切都可以解决。当我一点点深入了解自动化之后，发现自己最初的想法好简单，因此，我经历了从信心勃勃走到失落沮丧。在这个过程中问过我的领导要怎么推，问过我信任的小伙伴，要怎么做，感谢他们能听我唠叨，在给他们讲的过程，也让我在一点点思考，理清了方向。
本文将讲述一个国企，怎么从零开始一步步走向自动化测试。记录我在实施自动化测试过程中踏过的坑，以及我是怎么解决的，希望对其他人在实施自动化的时候，给予指引。过程会犯很多错，希望大家以包容的心态看待。

初识自动化

在今年5月的时候接到领导的任命去推卡中心质量2.0升级，其中一个大块业务功能自动化。现在想想领导选择我去做这个事情，最主要的原因是我是一个好的“推手”，会灵活地使用“手段”去推项目。因为刚开始的时候，大家都有一个意识觉得自动化没有做起来是因为大家的意识不够，所以需要一个人去推，让大家有自动化的意识。
很荣幸我们已经有了一个叫“ITEST”的自动化工具，刚开始它就是一个类似于postman的工具，除了POSTMAN所具有的功能外，它还具有如下功能：

功能点	详细描述
用例管理功能	可以按照系统维度和工程维度管理用例
环境管理功能	可以配置多套环境，在不同的环境下跑相同的用例
参数提取功能	通过参数的方式提高数据的利用率，和数据传递
定时功能	可以配置定时任务，用于回归
报告功能	用例明细报表、用力评审报表、持续集成报表、定时任务报表
权限控制	根据系统归属划分权限，权限等级有owner,tester,developer

接下来将用问题解决的方式来整理。

问题1：怎么改变大家行为

问题描述

大家已经习惯在postman或者jmeter上调试接口，怎么改变大家行为，转用Itest？并且怎么提升ITEST上用例的占比，做到每天回归持续集成？

解决办法

1.培训

一共安排了三轮培训，每轮培训侧重点不一样，因为是内部资料，没办法提供具体的PPT，在此只是简单描述一下三次培训各是什么。

培训	培训目的
解决困惑	解决如下疑问：1、为什么要用ITEST，我用postman和jmeter已经很熟悉，为什么要换；2、我那么忙，功能测试都测不完，那里有时间做接口用例回归；3、把我的功能测试做完就好了，有没有接口测试同我有什么关系；4、我就只会做功能测试，接口测试那么难，学了有价值吗；5、天天让接口回归，数据环境一出问题，用例就失败，维护成本太高了，值得吗；6、ITEST我也用了，感觉好难用，有没有样本教程
工具使用	除了介绍基本的功能外，还需要定使用规范
样本讲解	拿出做得好的做样本进行讲解

2.报告优化

为了提升接入率，方便推广，因此提出了接入报告。我们以swager上维护的接口为接口基线。

主表：用于各系统之间的比较，每天出接入“红黑榜”，让各系统之间有竞争关系，提升接入效率。
子表：是详细信息，可以看见每一个工程接入的情况，便于查询原因。

3.基线分支完善

因为ITEST上用例与测试任务相关联，没有所谓系统用例基线的概率，导致同一个系统，用例分布在不同的测试任务中，要做到用例回归，就显得特别难。
在做用例管理时，无论是接口用例管理或者功能用例管理，都需要有基线，所有用例都是由基线来，测试完成后，回到基线里面去。下面画一个简单图，解释基线的作用。

其实在使用过程中，用户并没有这样良好的习惯，都习惯在基线里面直接做用例维护，因此我们放弃了版本分支管理的模式，让用户直接操作基线，每天回归也是用基线回归。

问题2：怎么提升执行成功率，降低维护成本

问题描述

自动化用例是有维护成本的，两个月推广，各系统已经逐步在ITEST上进行单接口的测试，把以前欠下来的债也补上了，但是因为接口测试需要依附于有一个稳定的环境，和有效的数据。因此，如果更好的提升用例执行成功率，降低维护成本。

解决办法

存在两个很大的问题，一个是环境，一个数据。在详细介绍这两个问题之前，先介绍一下现状。
1、环境问题
所有测试环境都由测试人员和对应的项目组搭建的，权限也在项目组内。我们使用的微服务架构，又加上系统众多，系统与系统之间的调用又很频繁。但是因为权限在项目组内，导致环境经常变动，时好时坏，回归也变成时好时坏。想快速复制一套环境出来，也特别难，环境联调需要花很多时间。并且浪费了很多资源，服务器利用率很低。
2、数据问题
银行系统有众多的卡类卡版，又有各种批处理，很多数据都是消耗性的，消耗型数据一旦用了，再回归，用例执行就会失败。那么如何养出对应的数据，支持回归验证，就变得尤其重要。
通过上面的说明可以看出我们有两个基石，需要铺垫好，才可以更好的做回归。

在后面的篇幅中，将重点介绍数据工厂和测试环境管理的方法。

1.数据工厂

数据工厂价值如下：
1、为自动化测试提供测试数据，特别是消耗型数，现实自动回归
2、测试数据加工功能，通过调用接口自动化，加工出各种测试数据
3、测试数据管理功能，批处理管理测试数据和手动维护测试数据
4、为功能测试和业务测试提供测试数据
该平台只是用于数据存储和对外提供服务，真正的造数实现都是在ITEST上，通过业务场景造出对应的数据。

以组件的思想，给每一种数据打上对应的标签，组件库是互用的

下面画一些简单原型说明功能

数据管理页面——为用户使用提供了查询功能，通过数据类型，数据使用的状态、使用人、消耗类型查询到所需要的数据。
提供了“导入”和“新增数据”两个功能，可以为功能测试人员提供数据新增入口，把手上的测试数据，批量或者单条导入到平台上管理。
这个界面比较简单，下面重点提几个相对重要的字段。
1、数据类型：是数据配置中为某一条数据取的名字，比如“万事达公务卡”
2、字段数据：用json格式存储的数据，比如
{“cardno”:“621322222222”,
“tel”:“152222222”,
“cvv2”:“123”}
3、自动化失败次数：该失败次数，可以提醒借用数据的人员，优先借用成功率较高的数据，失败次数太多将被定期清理，避免“僵尸数据”
4、使用结束时间：借用时会设置一个借用时间，在这段时间内，数据将一直被某人所用，其他人员看不见数据信息，也不能再次借用，也可以设置为“长期使用”，在使用状态时，自动化测试也不会去取对应的数据。
数据配置页面——该页面是用来管理造数，在该页面配置好后，可以触发后台批处理，触发批量造数。

值得关注：数据管理工具一定要避免出现“僵尸数据”，所提供的数据一定是可用的，还要尽量减少同一条数据被多人使用。设计上的小技巧如下：
1、消耗型数据，每次使用后对应的标签下架。
2、非消耗型数据，在执行自动化测试的时候，会记录自动化测试失败次数，达到设置的“批量清数阀值”将自动化清数。人工借用的非消耗型数据，达到有效期后，将释放出来用于自动化测试，达到上限后清数。
3、数据使用加了权限控制，只有点击借用后，才可以看见数据信息。

数据清理逻辑如下：

2.测试环境管理

为了做到自动化回归，一定要有一套稳定的环境支持，避免出现“破窗效应”。前面也说了测试环境存在的现状，因此分下面几个阶段进行：
1、测试环境信息收集阶段，将测试环境收集起来，并存放在数据库中
2、前端页面开发阶段，分别从横向和纵向展示环境信息
3、异常处理脚本化阶段，通过前端页面可以快速重启应用
4、接入监控和流水线阶段，接入监控平台，异常信息在前端页面上展示，接入流水线环境上线
下面将讲一下环境管理设计思想

问题3：怎么业务场景快速自动化

问题4：怎么体现自动化测试的价值

问题5：怎么优化人员组织架构

问题6：怎么自动化测试运维

问题7：自动化场景实例