使用 Espresso 实现完整覆盖的功能测试 | Ohmer's Blog
tags: Android, 测试
对于基于 UI 的功能测试的需求其实一直存在,理由其实很简单,不想一直让人去做重复机械的事情,而且可靠性完全是靠人力的堆积产生。然而现在行业大多数公司的功能测试工作依然主要是依靠人工来完成,从我们公司的实践来看我觉得有几个方面的因素的影响。
之前的 UI 测试框架的表现差强人意。就拿我们公司来说,其实测试部门在去年已经实现并推广一套主要基于 UIAutomator 实现的测试平台,但由于对复杂功能的处理能力较弱,基本只能实现部分功能的检测。这样导致的一个结果是,并不能有效减少测试的工作,而只能增加测试的额外工作,因此测试编写测试代码的积极性不是很高。同时由于测试代码的可重复利用性差,导致测试脚本的编写成本和维护成本偏高,实践中大家只用 UI 测试跑一些主流程业务,覆盖范围非常有限。
部分测试人员的编码能力不是很强。由于大部分测试人员可能并没有过多的开发经验,所以在编写测试代码时并不能很顺畅的完成自己想要的效果,这样也会导致测试代码项目的推广阻力会比较大。
对于怎么编写 UI 测试,并没有一个被大家接受认可的最佳实践。虽然我用 Espresso...阅读全文
对于基于 UI 的功能测试的需求其实一直存在,理由其实很简单,不想一直让人去做重复机械的事情,而且可靠性完全是靠人力的堆积产生。然而现在行业大多数公司的功能测试工作依然主要是依靠人工来完成,从我们公司的实践来看我觉得有几个方面的因素的影响。
之前的 UI 测试框架的表现差强人意。就拿我们公司来说,其实测试部门在去年已经实现并推广一套主要基于 UIAutomator 实现的测试平台,但由于对复杂功能的处理能力较弱,基本只能实现部分功能的检测。这样导致的一个结果是,并不能有效减少测试的工作,而只能增加测试的额外工作,因此测试编写测试代码的积极性不是很高。同时由于测试代码的可重复利用性差,导致测试脚本的编写成本和维护成本偏高,实践中大家只用 UI 测试跑一些主流程业务,覆盖范围非常有限。
部分测试人员的编码能力不是很强。由于大部分测试人员可能并没有过多的开发经验,所以在编写测试代码时并不能很顺畅的完成自己想要的效果,这样也会导致测试代码项目的推广阻力会比较大。
对于怎么编写 UI 测试,并没有一个被大家接受认可的最佳实践。虽然我用 Espresso...阅读全文