构建自动化测试体系的考虑因素

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      

注：如上引用自http://www.luckyframe.cn/allwz/testdao-31.html，记录后续作为参考