详解ChinaCache分层自动化测试平台

AlexQin

目标功能架构

按照分层测试的思想，对代码层、服务层、界面层进行覆盖测试，其中还需要对设备进行监控（移动设备的监控、虚拟机测试环境的监控）。

AlexQin

目标技术架构

技术架构是以之前的API测试平台为原型，沿用Python+Django，基础服务Jenkins、Sonar提供RESTful的API调用（如遇特殊业务场景，可以直接从Sonar数据库查询，再整合聚合报告展示），当然读者会问？怎么没有考虑分布式呢？目前架构设计轻量级就足够了，而且业务量并没有超出承载能力，水平扩展也是容易的，例如基础服务Jenkins支持Master/Slave。

如何发挥测试价值？可以从分层的测试范围来简述一下：

AlexQin

UnitTest层

单元测试是第一道测试关卡，以前研发过程中，开发人员不关注代码质量，无单元测试投入，对代码规范无有效的审查、驱动改进的措施，使用平台之后：

• 建立提测项目的单元测试环节，从代码仓库（Svn|Git）check out项目；
• 构建项目，进行编译、单元测试、静态代码分析；
  
  • 如果编译不通过，则打回该项目给提测人员，并且记录错误作为提测质量的依据；
  • 编译通过则进行单元测试，单元测试失败、或者覆盖度不符合约定标准，同样打回，并且记录打回的环节；
  • 单元测试通过，则进行静态代码分析，并且汇总结果邮件通知相关研发负责人和测试负责人，评估质量；
    
    
• 以上所有环节通过之后，则可以进入Service Test层的提测。
  
  

AlexQin

Service Test层

服务层测试是第二道测试关卡，例如API测试，《HTTP API自动化测试从手工到平台的演变》，有详细讲解，

改进前：传统手工测试

测试用例掌握在测试人员手里，研发人员无法运行，修复bug之后，只能等待测试人员验证，交付过程繁琐、效率低。

改进后：HTTP API自动化测试

研发、测试协作同步，研发人员可以及早通过平台执行用例，验证功能可用性、正确性，测试人员可以释放部分劳动力，重点关注业务数据正确性；修复bug之后，研发人员无需等待，可以自助配置用例执行、查看结果，驱动过程质量的提升，同时做到夜间构建、邮件通知，工作时间review、bug fix。

在第二道关卡中，研发人员完成代码开发之后，可以使用平台进行API冒烟测试（流程上测试人员编写API自动化测试用例应当比研发人员完成代码编写时间早，这就是涉及到团队协作流程问题），勾选测试人员标记的冒烟测试用例，通过之后，可以进行深度的系统测试（关联系统测试用例）。在冒烟测试、系统测试环节，如果不通过，都会记录并且发送邮件通知研发人员，研发人员根据测试报告，排查存在问题的API，进行修复之后，再次提测，直到问题解决和通过为止。

AlexQin

界面层

并不是所有项目都有三层，不用生搬硬套，例如Portal有三层划分，HPCC缺没有UI层。Portal的UI层是如何做测试呢？在UnitTest、Service Test都通过之后，UI提测才更加有意义。

平台接受Portal的UI提测之后，会从代码仓库获取相应的UI自动化测试脚本（基于RobotFramework运行，使用selenium类库编写的测试用例），以及前面两层的项目代码，使用Jenkins与测试服务器进行交互，调用脚本部署Portal系统（当然，更加便捷的方式，可以把通过测试的发布包，推送给自动化运维平台完成部署工作，返回成功部署的服务器配置信息）。这里根据ChinaCache的业务场景，没必要划分严格的不通过准则，UI测试运行完毕，发送测试报告给相关利益者皆可，报告包括功能模块、测试用例，通过率等等。

AlexQin

总结

以上是我在ChinaCache工作5年来最大、最长的自动化测试实践经历。平台化的东西，以前不敢想，是因为没有业务需求来驱动，以及如何说服老板来支持都是个大问题。

目前测试的种类繁多，导致需要人工验证的环节反复出现问题，当存在重复劳动的时候，就要琢磨有没有办法加速测试，提升效率呢？任何事情的演变以及进步，都是从小到大，积少成多；没有单元测试的推行，没有API自动化测试，没有UI自动化测试，平台也只是个摆设，每个层次都需要打好基础之后，接入平台只是流程的问题。

接下来要做什么呢？根据自己负责项目的业务复杂度，制定有效的自动化分层测试策略，说服你的老板，支持你！

AlexQin

http://www.infoq.com/cn/articles/ChinaCache-CIP

AlexQin

good job