写在前面

上篇文章给大家罗列了测试兵器谱,简单给 “十八般兵器” 做了分类,今天跟大家聊一下测试框架的那些事儿。
业内流行一句话叫“Don’t Reinvent The Wheel, Unless You Plan on Learning More About Wheels”,不要重复造轮子,相信大家已经耳熟能详,并且 “熟视无睹” 吧?广义上的轮子往往都是一些各式各样的 “框架”。暂且不讨论造轮子的对与错,先理解一下框架该如何定义。

需求的起源

框架源于人们对 “复用” 的诉求。它的发展路线一般都是这样的:

单从字面意思上理解,框架可以理解为针对某个领域的特定 “骨架”,其内部封装了该领域内需要用到的控制流程和处理逻辑,以及基本的操作单元,而框架则支撑着这些操作单元按照一定的流程来实现逻辑行为。之所以带入领域的概念,是因为市面上有大量的行业领域,而每一种领域都需要有针对性的框架来解决特定的问题,譬如单元测试框架 JUnit、BDD 测试框架 Cucumber、前端框架 VUE、分布式服务框架 Dubbo 等等。
然而没有一种万能框架能解决所有领域的问题,哪怕是测试领域,也区分了单元测试框架、接口测试框架、UI 自动化框架等等诸多方向。

选型之痛

虽然我们反复强调不要重复造轮子,但是在实践过程中会发现很难践行这一准则。困扰我们的有几个方面:

好框架的特质

个人总结有以下几点应该优先考虑:

另外,在选择框架的时候,是倾向于大而全还是小而精,要结合我们现有项目的实际情况来分析,并充分考虑到后期的功能扩展、平台扩展、产品形态变更等风险。建议让项目经验丰富的人,比如架构师来敲定框架的选型,再结合业务测试经验丰富的成员共同讨论方案,适合你的才是最好的

介绍一些轮子

按照测试框架的特性,我把现有的一些测试框架可以分为通用框架应用框架两种。

通用框架

通用框架所解决的是 “普适性” 问题,它可以与不同的应用框架结合起来使用,只做一些通用的流程控制。比如我们常见的通用框架(不限于以下数量)有:

应用框架

与通用框架相比,应用框架更关注于特定领域的特定问题。由于不同领域的特殊性,应用框架需要有很多针对性的 API 来解决特定的行为事务,它们通常需要和通用框架结合起来使用,才能更好的、更高效的为业务服务。
举个例子,我们常见的移动端 UI 自动化测试框架就是特定领域的应用框架,这里简单介绍一些:
• Instrumentation:Android 自带的一个测试框架. 在同进程中加载被测组件. Android4.3 之后 Instrumentation 引入了 getUiAutomation 接口的实例进行跨应用测试
• Robotium:基于 Instrumentation 框架的基础, 开发的一个更高效的框架. 对常用的操作进行了易用性的封装. 是目前使用最广的框架之一
• Uiautomator:Google 在 Android4.3 以后推出的新框架。因为 Instrumentation 被设计为不能跨进程测试. 所以 Uiautomator 就是用于弥补这个不足的.Uiautomator 支持跨进程和 UI 级别的基础测试.
• Appium:支持 Android 和 iOS 的测试框架. 兼容 Webdriver 协议. 可以使用 Selenium 的方式做 Android 的自动化.底层基于 Selendroid 和 Uiautomator.
• Selendroid:基于 Instrumentation 的一个框架. 完全兼容 Webdriver 协议.
• Cafe:百度出品的一个框架. 基于 Robotium, 并提供了跨进程的测试解决方案
• Athrun:淘宝出品, 支持 Android 和 iOS, 提供了简化的控件封装. 目前基本不维护
• MonkeyTalk:一款可以在 iOS 及 Android 设备上真实的、功能交互的自动化测试的框架,支持录制回放功能,支持原生及混合的应用测试,有专业收费版
• Calabash:一款同时支持 Android 和 iOS 的开源测试框架,基于 cucumber 框架,目前支持 ruby 开发语言
• Robolectric:一个 Android 单元测试框架,可以在 JVM 中运行 android 项目,从而脱离 Android 环境的依赖
• Monkeyrunner:Android SDK 自带的测试工具,提供 API 模拟各种手机操作,相对于 Monkey,其具备的优势是可以加入操作逻辑
• Espresso:Google 开源的 Android UI 测试框架,基于 Instrumentation,相对于 UIAutomator 更快,API 更强大,但是它不能操作系统设置,可以与 UIAutomator 配合使用

总结

上面内容中我们把框架理解为” 骨架 “,就像素描一样,先观察、再构图、然后塑造、最后调整。前面的内容帮助我们完成了” 观察 “和” 构图 “两个阶段,剩下来就需要塑造和调整。
塑造阶段建议注意三点:

剩下来的比如日志记录、测试报告、邮件通知,以及脚本的容错性、健壮性、retry、失败截图等扩展,都是根据项目实际需要进行增加。每个人有每个人的实现方式,本文不做过多的赘述。


↙↙↙阅读原文可查看相关链接,并与作者交流