构建自动化测试体系之道

近些年，科技创新风把金融支付行业推到了风口浪尖，行业的技术从业者则成为了浪尖上的弄潮儿，测试人员更是在这个特殊行业中面临更大的责任与担当、更具挑战性的技术革新。

随着整个金融行业的业务规模越来越庞大，系统级别的交互越来越多，业务耦合越来越复杂，给测试团队带来的最大挑战是如何去保障大量业务系统之间的正常交互，以及保障系统在不断的开发优化过程中已有的功能不受到影响。在这个前提下，测试团队开始了自动化测试体系的建设。

自动化体系的建设初期面临了很多问题

• 无法使用目前市面上的开源自动化测试工具。

  因为这部分的工具大多基于桌面客户端，弊端明显，缺乏系统性的过程管理，无法适应公司级别的自动化体系建设。比如像ride RF、postman、soapui等等，小范围和轻量级的应用都非常的好。但是一旦项目和用例多了，协作开发脚本的测试人员多了，那么就满足不了了。

• 自动化用例得不到统筹科学的管理，难以在业务层面构建完整的测试场景。

• 自动化用例、脚本、数据的可维护性太低，后续优化成本大。

  可维护性我们可以从测试架构层面分成两个方面看：

  一方面是如果自动化框架分层做得不够好，脚本与数据、用例之间的粘度太大，灵活度不够。

  另一方面是测试框架封装程度不一致，要不框架封装得太泛，导致脚本维护太麻烦，自动化成本大。要不就是框架封装过于严密，可扩展性不够。

• 缺乏展示工作成果的平台，项目自动化方面建设的沟通成本巨大。

  
  

我们从公司的实际情况分析，自动化方向的选择有两方面，一个是实施难度，一个是自动化价值。

如果要按实施难度排序，那么界面自动化肯定是最简单的，接口其次，单元测试最难。

如果要按它的价值排序，那么接口自动化的能发挥的价值是最高的，单元测试其次，界面自动化的价值最低。

所以综合下来，我们做自动化优先实施了接口自动化。

还有一个比较容易忽视的问题，就是做事(自动化方面)的持续性不够

有些团队前期各方面的工作做得非常好，整个框架流程也都起来了，但是过半年发现，自动化的那些东西完全没起到作用，接口更新了没去调整，业务流程更新了没有维护，这些都很可能会导致自动化前功尽弃。

如果要保持好持续性的工作，有两个方面要注意：

• 一方面自动化脚本的维护一定是一件随时随地的事件，而不是等一个时间节点一个版本迭代结束才要做的事情，也就是要想到什么场景，马上行动加一条用例。往往测试人员喜欢等一个迭代结束了再慢慢来维护自动化用例，这很容易导致一个问题，等到真正想维护用例的时候，发现前面累积的思路已经变得不清晰了。

• 另一方面一定要随时关注每一次任务的执行情况，拿我们自己的团队来讲，其实也有这个毛病，测试任务跑完了，很多失败的用例不去关注，那么就不知道到底问题在脚本还是项目，也不知道要不要去优化用例。这样下来，自动化完全没有发挥应该有的作用。

很多中小型公司在组建测试团队的时候，喜欢招聘自动化测试工作师这个岗位，专岗负责测试脚本，这么做从我个人来看其实是有问题的。

因为这个岗位实际做的事情比较尴尬，因为他可能在团队的位置中处于一个灰色地带，不但对业务不够了解，对开发技术也不够了解。

所以在我们测试团队，只有两个岗位：

一个测试开发，专门负责测试工具的开发，而不是去写脚本。

一个是全栈式的测试工程师，他们负责写脚本，负责功能测试，负责测试环境，负责其他很多的事情。

这么规划，对于测试人员职业通道来讲，是比较合理的。测试开发实际就是开发，他们有开发人员一样的职业通道，全栈式的测试工程师也能真正的体现出他们的价值，会做功能测试，会写脚本，全能型的人才。

葛大爷说：21世纪最重要的是人才，从管理者的角度来说，最重要的是把合适的人，放在合适的岗位上。

自动化相关工作的测试工程师能力模型可以分为8大块，其中软技能模型跟硬技能各占一半左右。

角色A：实际就是测试开发，要求熟悉开发语言，基本的开发框架，既有一定的技术视野又要有一定的测试架构能力，负责工具的开发、选型以及工具的推动使用。

角色B：全栈式的测试工程师，强调对业务的理解深度以及对测试基础能力的掌握情况，为设计出更多的自动化场景，同时又要有一定的学习能力，能很快的适应工具的使用跟项目应用。

整个测试平台前期的大致规划分成四个部分：

• WEB的管理平台，前面已经说到自动化的体系管理目前行业通病是缺乏系统科学的过程管理，那么WEB端的管理平台主要承担了这么一个角色。

• 计划调度任务的模块，主要负责定时以及手动测试任务的启动。

• 客户端子系统，负责自动化用例的执行以及测试日志收集。

• 再加上一些外部集成开源系统，比如jenkins、sonar之类的，做一些代码检测、项目构建、项目质量数据统计之类的功能。整个平台这样就能形成一个比较好的项目质量闭环。