在上一篇关于自动化测试的文章 解密敏捷自动化测试 中，为大家介绍了敏捷自动化测试，以及 Choerodon 猪齿鱼自动化测试的落地。在这篇文章中，给大家介绍一下 Choerodon 自动化测试的技术方案的设计思路以及实现。
为什么自动化测试需新建测试应用
自动化测试的本质是使用一些测试框架开发测试代码，运行测试代码即对已有的业务应用进行相应的测试。对于一个项目来说，测试应用与普通的业务应用应该是同等重要的。
从代码开发上来说，一个自动化测试应用的代码量可能比一般的业务应用要大，多人协作开发也是目前自动化测试的大趋势，所以代码托管可以更好地进行测试代码开发与维护。
之前有用户来咨询，在测试应用与业务应用的对应关系上是如何落地实践的。是否需要每个业务应用都需要对应一个测试应用。猪齿鱼平台本身是基于微服务架构进行开发的，它有很多的后端服务，但这些中有一些的耦合度是比较高的。所以在开发人员的测试实践过程中，并没有针对每个应用一一对应建立测试应用，而是基于大的功能模块进行拆分。比如敏捷管理模块有一个 mocha 框架的测试应用，测试管理模块也有一个。像这样基于大功能模块的拆分免去了很多 feign 内部调用重复测试的冗余测试代码，且易于进行测试代码开发的任务分配。
为什么自动化测试应用要执行 GitLab CI
在 Choerodon 的 DevOps 模块控制下，当一个应用提交代码后触发一次 GitLab CI，就会为这个应用生成一个版本号，并打出可以部署运行的镜像、Chart 包，对于测试类型的应用也是如此。Choerodon 的自动化测试运行也是基于 helm 进行的部署操作，对应的，也需要对于代码进行构建打包。
并且，测试管理模块对于自动化测试用例的回扫功能是基于测试报告文件以及代码注释进行的（这部分在本文最后章节会进行展开介绍）。对测试代码进行版本控制也就意味着对测试用例进行了版本控制。在一个测试应用可能被定时、反复运行的场景下，如果能保证已有测试用例的时效性并且加以复用就可以最大程度上减少冗余数据的产生。Git 的版本控制刚好就可以保证相同版本下的代码一致性。
Choerodon 提供的模板有什么特别之处
Choerodon 平台现在提供了三个测试应用的模板，分别是 mocha+chai，TestNG+Assured，TestNG+Selenium。
这些测试模板都对于 helm chart，Dockerfile，gitlabci 等进行了加工，并在其中封装了简单的 demo 代码，例如登录接口测试的简单实现。通过 demo 代码可以快速上手进行测试代码的开发。
并且为了方便对“测试数据”，“预期结果”这两个测试步骤的字段进行维护，我们对官方提供的可以在测试报告中加注释的方法进行了封装并进行数据提取，可以满足步骤信息的维护需求。
这其中 TestNG+Selenium 的模板通过对于官方镜像的修改，支持了在部署过程中独立启动 chrome-standalone 浏览器核心。猪齿鱼基于官方 chrome-standalone 镜像的基础上加入了 servlet 的生命周期管理，可以通过接口调用的形式对浏览器核心的进程进行管理。在 TestNG+Selenium 的应用部署时，一个 pod 对象中存在两个 containers 对象，其中一个是 WebDriver 浏览器核心，一个是我们的 TestNG 应用。后者基于 pod 中的内网进行浏览器核心调用，并在 Dockerfile 的最后通过 curl 结束 WebDriver 的生命周期。这样就省去了 Selenium 框架对于外部浏览器核心的依赖需求。
如下图所示：
拉取模型 OR 推送模型
在 Choerodon 如何运行自动化测试这个问题的选型初期，使用推送模式还是拉取模式一直是一个比较纠结的问题。团队研究过 GitLab CI、qTest 等平台的部署运行方案并进行了参考，而他们的定位、出发点和猪齿鱼平台又不尽相同。
例如在 GitLab 中他们的方案是单独部署 runner，即需要部署一个 agent 主动进行任务拉取然后调度执行返回结果。而这样的方案无疑会增加部署的成本，就像我们自己搭建一个 GitLab 一样，搭建好了并没有 runner 节点可以直接使用，而是需要额外进行 runner 的搭建与注册到 GitLab 平台的操作。这样提高搭建成本的操作对于本身搭建要求已经较高的猪齿鱼平台来讲并不是非常友好。
所以猪齿鱼选型的最终结果是使用推送模式进行自动化任务的处理。用户在激活自动化测试运行的时候由测试管理模块后端发送请求至 DevOps 模块后端，然后通过 WebSocket 连接 agent 进行任务调度。并将自动化测试功能集成在现有的集群 agent 上，可供用户选择运行自动化测试的环境即为环境流水线中注册的环境。从而减少平台的组件数，并且降低搭建的成本。
测试结果是如何进行回扫的
Choerodon 测试管理模块对于自动化测试结果的处理是在测试应用的 Dockerfile 中通过 curl 访问测试管理模块的接口，将测试报告打包并回传测。在接收到文件后并将其保存加以解析从而导入到测试用例、测试执行中的。
例如 TestNG 框架，将 Suite 级别对应成一个用例文件夹，那在一个 Suite 中的 Java 类即为一个测试用例，这个类中的方法就是这个用例的测试步骤。并且解析 ReporterUtil 类中打印在 xml 报告中的日志对结果、预期字段进行填充，就完成了测试用例的扫回。
在有了测试用例之后就为其新建测试阶段，然后按照测试报告的结果进行测试执行状态的更新。如有报错日志等信息都会维护在对应步骤的注释字段中。
测试结果扫回逻辑如下图：
关于猪齿鱼
Choerodon 猪齿鱼是一个全场景效能平台，基于 Kubernetes 的容器编排和管理能力，整合 DevOps 工具链、微服务和移动应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台，同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。
大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：