代码改变世界

UI自动化测试随笔

2012-05-25 23:46 by 横刀天笑, ... 阅读, ... 评论, 收藏, 编辑

昨天给开发的同事讲我们正在做的自动化测试,同事问了句:为什么API的测试不需要写代码了,而UI的测试还需要写那么多代码呢? 能不写代码么? 

目前我们的自动化测试的现状:

目前主要覆盖两个部分:API的测试和UI的测试。对于API的测试经过框架的封装,基本上只需要编写一个xml描述的test case就可以了,xml里描述了输入,调用和断言。框架就根据这个xml来测试具体的API,基本上(99%)不需要写代码了。而UI的测试在这方面框架封装的却比较少(力所能及的封装一些通用控件),更多的是制定一些分层的规范。

 

我当时回答:

因为API的输入和输出比较明确,而且目前的API的测试还仅仅是关注在单个API上,而UI这方面输入输出不明确,变化也较多,而且主要关注业务流程,用户场景。

同事又问:

API也会变化啊,UI也可以做到明确啊。

 

显然我的回答,同事并不满意。后来我也在思索,为什么UI测试就不能像API测试那样不写任何代码,只用一个类似xml的case文件描述一下即可呢?

下班回家在地铁里突然想到,其实对于UI来讲,UI上的每一个可输入的最小的可复用单元都算是一个“接口”,这个接口等价于API测试中的那个接口(REST, RPC等)。如果我们要给UI中的最小输入单元编写测试基本上是可以做到不写代码的(测试人员可以不写代码,由测试框架提供)。而复杂的UI其实也是这些最小接口组合而成的。通过将这些最小”接口“组合成大一些的”接口“,最后组合成页面级的”接口“,其实也可以做到不写程序代码测试UI。后来自己都笑了,这不就是Keyword Driven么。

联想到昨天吴老师 @吴穹 讲到:DSL不仅仅是针对某个领域的,每个项目也可以有自己的DSL。

那么如果我们能够在项目的前一两个迭代,利用Keyword Driven总结出这个项目的DSL,那么后面的测试的开发就会越来越快了啊。