I recommend that developers spend 25-50% of their time developing tests - Kent Beck
上周末在云栖 Techday 分享了自动化相关的一些内容,有很多同学来要 PPT,统一回复下,这是会场用的 slide。
下面对没提到的一些点也做些总结。前几篇文章都是在简要介绍 Macaca 在各个平台的配置和使用。本篇文章总结下做自动化测试的一些知识和心得,重点介绍如何写好 Macaca 的测试用例。
测试文档我们基本都是遵从IEEE 829标准,常规的测试工程周期如下:
标重的是常被认为容易忽视的环节。
我曾在这里提过,自动化的本质是软件开发。我们一般会以覆盖率指标来衡量一个产品的用例覆盖程度,如下图,在 UI 黑盒中,我们会使用 TC 通过率来衡量。很多朋友会陷入一个误区认为用例数量多总是好的,侧面反应出产品的覆盖程度很高
,完全没必要因为追求数量而写大量用例,反而应该关注用例的有效性。优秀的用例还需要考虑很多方面,比如模块化。
模块化做的是否高质量,用例架构设计是否合理,直接决定后面的复用性,和整体的维护成本。
Node.js
基于CommonJS
,对模块化的支持非常好,每个.js
文件都是一个模块,依赖管理,分包都非常方便。如果想引入一个三方包,直接在根目录的package.json
中的dependence
字段中声明模块名就好了,如果若干模块在一定场景里具有普适性,还可以publish
到远端,多用户、多环境共用。
我们提到的模块化不止是代码结构上的模块化,而是从用例的可分层开始考虑,将各层次的测试按照业务生产上的需要,进行合理划分,做到真正意义上的模块化,下图示例一个常规 WEB 产品系统的测试分层。
有了清晰的分层,覆盖测试的思路就会变得清楚很多。覆盖的某些功能常常会依赖其他环境,只要有系统依赖就会有不稳定的因素存在。如果你恰好在使用 Macaca 做产品链路测试或者全功能测试,我们的原则是,只要不是此业务模块产生的问题,而是依赖的其他环境导致的问题,都归为误报。
为了减少误报,需要在用例里做好分支逻辑,比如依赖的环境导致链路无法进行或者进行到异常情况,允许使用 Mock 数据或者跳过某块覆盖,最终体现在报告上。
基于业务的适配层很重要,尤其是要成规模采用 Macaca 这套方案的时候。我们需要应对自身的业务和产品特性做一层适配,简单到提供一个模块封装,复杂到需要提供服务支持或者配置系统支持,具体实施看应用场景。这里说一个最简单的例子。webdriver-client 源码 就是个适配层的例子,可以发现其中有对 iOS 和 Android 两平台的兼容方法 login
。
在 iOS 中登录是这个样子:
module.exports = function(username, password) {
return this
.waitForElementByXPath('//UIATextField[1]')
.sendKeys(username)
.waitForElementByXPath('//UIASecureTextField[1]')
.sendKeys(password)
.sleep(1000)
.sendKeys('\n')
.waitForElementByName('Login')
.click()
.sleep(5000);
};
而 Android 中它可能就是这个样子:
module.exports = function(username, password) {
return this
.waitForElementsByClassName('android.widget.EditText', {}, 120000)
.then(function(els) {
return els[0];
})
.sendKeys(username)
.sleep(1000)
.elementsByClassName('android.widget.EditText')
.then(function(els) {
return els[1];
})
.sendKeys(password)
.sleep(1000)
.waitForElementByName('Login')
.click()
.sleep(5000);
};
提供了兼容封装或者业务上的适配,即可把模块发布到远端,团队成员之间,各个环境之间公用,当然这是个最简单的例子用于说明。
白盒过程中,我们可以很容易的控制测试流,数据流,覆盖分支情况和可预见的边界情况。自动化的过程可以使用数据驱动的方式,同时Node.js
对于文件处理和系统调用也是非常强大的。Node.js
生态几乎支持所有类型的数据库模块,对csv
, excel
等一些常用的归档格式文件处理也非常棒,例如 node-csv。
行为驱动更关注产品的使用预期,从使用行为角度进行用例覆盖,比较适合 UI 层面。在实际业务场景场景中,一定是多方案混合的,另外还有多种手段辅助诊断。** 例如截图对比的方式,针对一些特定场景,就是很好的辅助功能 **。但这并不意味着不纯粹。
不要追求 100% 的自动化覆盖,某些困难的部分,如果覆盖成本较高,可以考虑弃掉,甚至八二原则取舍。如果因为某些功能的覆盖,导致整体设计过于复杂,最终会造成可预见的大量维护成本,就得不偿失了。
自动化最大的意义除了完成人工无法胜任的那部分工作,沉淀和公开化测试过程。它的一个重要意义,我觉得在于可以做其他工作的驱动器,例如,某些特殊需求的场景里,我们还要做必要的专项,如下图。
UI 自动化是Continuous Delivery
中的一个重要环节。软件研发流程中需要静态扫描的紧密配合。当然,无论是语法 lint
,硬编码,初级的 BUG 扫描还是与 PMD 配合工作,Node.js
生态都已经有了很成熟的方案。
某些产品需要 UAT 阶段,图上并没有体现。UAT 在 SIT 后,一般由用户来承担测试角色。
录制是产生测试用例的一种方式,会在初次完成某测试行为大大降低成本。手工编写用例成本相对高,但是自由度高,可以完成任何需求。
Macaca 会在接下来的版本提供录制工具,方便测试用例的生产。录制也有很大的缺点,一旦产品进入频繁变化期,维护成本将会变得非常高。
为融合现有的测试体系,Macaca 是基于 Webdriver 标准的,C/S 架构是否支持多语言绑定应该不需要赘述了。
Macaca 的工具和服务端模块都是使用 JavaScript 语言开发的,同时推荐大家实践的语言体系也是 JavaScript。如果对 JS 比较陌生,可以看我提供的两部分内容。JavaScript 基础,JavaScript 实战,互联网上也有大量的资料可以轻松学习。
Node.js
是运行 JS 语言的平台,它是跨平台的 WEB 实时应用首选,事件驱动与非阻塞 I/O 模型使其轻量、高效,而且还有强大,一直在膨胀的生态。这也是当初我们为什么选择Node.js
,而不是python, ruby, java ...
。
用例调试这里不多说,推荐看这位同学写的文章:编写移动端 Macaca 测试用例 [单步调试]。另外,原 debug-tool 工具不再继续维护。
推荐如下一些模块用在 Macaca 方案里:
测试框架:
断言库:
覆盖率:
数据 Mock:
faker
对 i18n
支持很友好,曾使用 faker.js + react
开发过 数据 mock 工具。
其他的,很容易文档或 Google 到相关内容,这里不赘述了。
CI 相关后面会分享。
欢迎讨论,互相学习。
微博: http://weibo.com/xudafeng
Github: https://github.com/xudafeng