让我们来聊一下UI自动化测试(3)

发表于:2016-11-09来源:来自地球的移动测试作者:来自地球的移动测点击数: 标签:UI
下面我们来开开脑洞,大家有木有想过用例可以生成,生成用例自动化: 描述好Action和State生成的Map 最简单的用例生成就是基于数据驱动的自动化测试,
 
  下面我们来开开脑洞,大家有木有想过用例可以生成,生成用例自动化:
 
  描述好Action和State生成的Map
 
  最简单的用例生成就是基于数据驱动的自动化测试,生成基于不同的数据输入的用例。当然,用例的逻辑肯定要是一致的,就如QQ的状态变更能力,用例用选择输入不同的状态变更,如离线,繁忙,在线等等,最后检查状态栏的情况。如果输入之间有排列组合的关系,则可以利用pairwise来减少用例的个数,但是保持一定的覆盖率。
 
  另外一种用例生成,则是用例逻辑的自动生成,想想,只要定义好每个Action在不同状态下切换到的新状态,状态机算法就帮助我们生成一系列的用例。这个技术叫MBT, Model Base Testing。现在各种语言都有Model Base Testing的库,跟UI自动化结合起来就可以了。python的就例如pyModel。但是为什么这么好的东西一直没有做起来呢? 1. 入门稍微困难了一点,需要理解一下状态机本身的算法。这个对测试本身的素质要求更高 2. 如果说UI自动化测试的维护大部分在于排错,那么基于MBT的自动化,则排错更加困难了。原因是什么呢?因为脚本逻辑是生成的,所以对于依赖固定逻辑的Assert会变得非常复杂,但是也不是不可行。况且,退一步说,验证CRASH这种简单的Assert是没有问题的。只要能把排查错误的能力在普通UI自动化测试下做到极致,排查时间能够控制在几分钟之内,那么结合MBT当然也就不是梦想了。另外,最能证实可行性的证据,应该就是“即时战略”游戏里面的电脑,他们就是状态机编程的结果,比一个应用复杂得多,都尚且能无差无错的完成。
 
  再开个脑洞,前面说的UI自动化都是长长的用例,所以才有了分Step。但是这些UI自动化测试的用例有没有可能变短,例如我们测试QQ聊天,我们不需要在界面上登陆,我们直接打开就是聊天窗口,甚至里面各种类型的消息都准备好了。要做到这不需要什么,只需要一点,“解耦”,聊天窗口跟别的类的关联是清晰的,简单的。如果能,例如在android,用接口测试操作,获取QQ聊天窗口必须的SKEY等等资源,然后绕过登陆,搜索好友这些步骤,直接起来QQ聊天界面, 简单,快捷,稳定。可惜解耦不是开发天然做到的,需要逼, 国外用来逼的方式就是UnitTest,国内呢?
 
  总结
 
  UI自动化是一种能力,常常无法回避。
 
  UI自动化会给人幻觉,要看清现实与价值。
 
  UI自动化最适合一句话,喜欢是放肆,爱是克制。而克制是UI自动化能发挥作用的关键。

原文转自:http://www.uml.org.cn/Test/201611021.asp

...