UI自动化测试随笔

昨天给开发的同事讲我们正在做的自动化测试，同事问了句：为什么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，那么后面的测试的开发就会越来越快了啊。