该文原创为新潮质量保障技术团队中的 “上进的中年软件测试从业者”，用于技术交流分享

这个公众号分享的东西基本上都是与测试平台的建设相关，亦或是测试工具的使用及推广、技能提升等。但是很少有介绍功能/手动测试相关的流程优化、测试体系优化的等等，所以很多朋友都会有我是不是不参与功能测试这个疑惑。实则不然，我们组内涉及到的项目测试工作，不管是新项目、还是老项目的大范围改动我基本上都会参与进去。另外当测试资源很难协调的时候，我基本上也就是一颗螺丝钉，哪里需要就去哪里。我会参与新项目与重大变动的项目原因主要有以下几点：
- 了解框架选型
- 参与新服务搭建
- 主导 CI/CD 流程等自动化流程部署
- 通过功能验证了解核心业务
- 准备数据迁移脚本，验证数据一致性
- 梳理接口性能测试指标、执行验证并用于资源申请
- 短时间内完成首次发布
- 与项目成员建立信任关系，协同推广测试流程

功能验证是测试平台建设过程中的试金石，能够让平台得以充分验证；同样也不至于让测试平台成为闭门造车后的一个无关紧要的产物。

开篇

今天参加了两个分享，收获颇多。也非常赞同其中一位分享者的一句话：没有经过市场/公司业务检验的架构/框架绝不是一个好框架/架构。互联网上有各种开源的/需要 license 的半开源的解决方案、产品、架构、中间件、数据库等，总有那么一款或者几款，在社区评价很高，同时也具备了解决你当前痛点的能力。你总是会在这几款中，优先选择接入成本最低那个，但往往这个只能解决燃眉之急，却无法根治/或者总会给你带来那么一点点的小缺陷，让有洁癖的你每每想起总是那么不舒服。而你却不能说你选择的这个不好，可能只是不适合你当前的应用场景。就如同你用 mongo 去实现数据依赖性较大、但数据量本身不大的业务场景，确实也可以用，但是在性能上面，绝对与关系型数据库是没法比。mongo 本身没有问题，只是不适用你当前的场景罢了。

今天参加的另外一个分享是我们这边最近在研究的一个自动化的框架，严格意义上来不算是框架，只能算得上是对当前现存问题的一个较为优化的解决方案。

做测试的同学，不管是正统学过软件测试、还是参加培训机构速成的，基本上都听过/用过 RF(Robotframework)。对于 RF 本身，这里就不做过多的介绍了。有一个特别的奇怪的现象我想大家应该都注意到了，网上/机构对 RF 的基础教学基本上都是围绕 RF+selenium，甚至有一种 RF 和 selenium 合体了的感觉，完全是在误导。

背景

公司之前的自动化目录结构和使用方式，在一定程度上限制了关键字的开发和复用。尤其在提出平台概念以及做了服务拆分后（具体请参照测试平台之服务拆分），如何平台化、模块化以及服务所能提供的服务能力上面，让我们对 RF 的使用上面不得不做一次变革。

调研

针对当前的自动化用例编写过程中的痛点、以及我们的远期规划，大概的整改思路有以下三个方向：

- 通过二次封装 BuitIn 关键字集来丰富关键字，实现复用。
- 在项目同级目录新增公共资源，并封装关键字用于其他项目使用。
- 通过新增关键字服务的方式，提供远程服务。

三种实现方式对比

• 成本：包括开发、部署、发布、项目迁移
• 易用性：包括用例编写、关键字调用过程等
• 维护性：包括使用过程中的可维护性、以及维护本身的代价

• 平台化：包括服务能力提供、三方接入成本等

  通过以上四种纬度的对比，我们不难发现，不管是从成本、实用性以及未来的平台化角度来看，远程服务是现阶段对我们最合适的解决方案，至此，测试平台家族又新增一服务，即 RF 关键字服务。
  

备注：红色部分未规划但暂未接入；CI／CD 引擎暂时所承载的功能还未达到我们想要的一个效果，所以之前一直未做过多的介绍，目前正在为第二阶段准备中。

实现过程

服务提供

- 远程关键字集合类：包含了自研开发的所有关键字
- 服务启动地址：对外提供服务的接入 IP 和端口，因为我们采用了容器化部署，所以这里地址和端口不是客户端接入的地址，最终的接入地址为容器启动过程中映射出来的宿主机 + 映射端口
- 持久化 + 安全配置：不允许远程关闭

客户端接入

- 接入地址：即连接服务提供地址。

- 配置文件：感兴趣的同学可以去搜索 getVariables 这个特有方法，可以实现自动化用例执行过程中的根据不同的执行参数（一般为用例执行环境）来加载不同的变量。

关键字引用

我现在的电脑上没有装 RF 的 IDE，所以这里没法截图和掩饰。直接 F5 调出关键字后选择 Remote，就可以看到远程关键字服务提供的关键字了。各位自行脑补吧。

## 思考

Remote 的关键字提供方式，调用过程为 RPC。熟悉我们平台建设过程的小伙伴应该知道，前面架构图里提到的工具服务就是以 RPC 服务的形式提供的。那么问题来了：

- 要不要整合资源，远程关键字直接由工具服务来提供？？？

- 当远程关键字服务足够稳定，是否可以作为公司开放平台的一个模块，对外提供关键字服务？？

对于第一个问题，我们的想法是需要独立出来，工具服务承载的应该更纯净的工具能力，不应该缠在任务业务逻辑。虽然这里关键字服务看上去并不是业务服务，但是我们可以理解它就是一个抽象出来的业务服务，比如说有这样的一个场景，我们需要对执行过程数据进行整合，结合上面的架构图，那我们肯定就会在 RF 关键字服务提供这个能力，而不会在工具服务上面实现。

对于第二个问题，我不知道。我能做的就是在这条路继续走下去，能走多远我不知道，那我不如就再走一会再说。这也是写这个公众号的初衷，充实和提升自己，来弥补沟通和表达能力的不足。

## 结语

至此自动化优化的整体过程到此结束，同时也强迫自己又还了一次技术债务，平时工作中我给大家的印象应该是没有拖延症的，但是实际上，这周还是欠了一个债周天是必须要还的。如果这个时候不是欠债，而是兜里富裕了一些，那将是多么愉快的一个周末。

业务的日常迭代是框架的试金石，同样更多的交流和实践也是个人知识和技术检验的有效途径。期待与各位交流更多关于测试方面的知识。我们下期见。