动机
从第一次接触自动化测试到现在已经6年有余, 期间有幸接触了很多优秀团队的优秀实践, 最深的感触, 是自动化本身基于实践, 是通过解决一个一个问题, 逐渐形成的软件工具方案. 虽然功能相近, 但是因为业务需求不同, 都有各自的侧重点和特异性. 想通过这样一篇文章引导读者能够从零开始结合笔者的经验, 构建一个完整的测试系统
我们需要自动化测试吗?
自动化测试有两点众所周知的优点:
- 作为持续集成的重要组成部分, 能够快速得到某一个构建的质量概况
- 代替人工, 有效的节约开支
虽然这两点非常吸引人, 但是如果想发挥自动化测试的长处, 就需要仔细的考虑是否已经满足自动化测试的引入条件:
- 是否已经有持续构建的基础条件? 团队是否已经习惯于这种作业方式?
- 目前的工作是否可以通过外包的方式完成? 使用自动化测试会节约多少人力?
系统概要
如果决定开始构建一个自动化测试系统, 不妨结合自动化测试明显的优点开始我们的设计:
- 可以运行测试
- 可以被自动触发
- 正确的反馈运行结果
- 执行可以加速
此外, 可能还需要, 但并不是必须的特性: - 可扩展
- 数据记录
自动化程序应该可以被除手动触发外其他的方式启动, 所以webApi, 命令行接口等可能是不可避免的. 有因为测试的结果需要能够反馈, 所以统一的Log模块, 以及测试报告生成的模块, 也是必须要有的. 因为执行可以被加速, 所以灵活的调度机制也是必须要有的.
那么, 我们稍微总结一下:
幻灯片2.png
是不是一个很简单自动化测试系统的雏形就出来了? 如果考虑到实际应用, 我们还要考虑到扩展性, 和数据的持久储存等, 我们可能还需要增加插件功能, 增加存储模块, 为了更灵活的调度, Engine最好支持队列的管理. 所以:
幻灯片2.jpg
到目前为止, 我们已经得到了一个自动化测试系统的RoadMap, 我们在后面会逐渐展开.
