自动化测试之随机化测试思想

发表于:2017-08-25来源:测试开发栈作者:测试开发栈点击数: 标签:自动化测试
自动化测试发展到今天,已经越来越平台化和智能化了。就平台化而言,我们可以在平台上管理元素对象、管理用例、调度执行、生成结果和报告,从而让我们写的代码中更多的只体现

自动化测试发展到今天,已经越来越平台化和智能化了。
平台化而言,我们可以在平台上管理元素对象、管理用例、调度执行、生成结果和报告,从而让我们写的代码中更多的只体现具体用例的实现逻辑,简单画个图表示:


 


智能化而言,我们可以数据驱动测试,关键字驱动测试,自定义代码模板,自动生成测试类和方法,基于模型测试等;

尽管有平台化和智能化的支持,可是很多时候我们看到的UI自动化测试实际实现方式,仍停留在写线性代码,配置指定的专有测试数据,大量使用平台提供的工具类,写出的代码就像流水线生产出来的一样……这样的代码写出来有时候自己都觉着不太靠谱(回归自信心不足,还得手工来一遍),自然也存在测试环境和正式环境数据不同就导致测试失败,界面UI更新自动化代码改动范围大等令人头疼的“尖锐”问题。

在确定和实践随机化测试思想之前,我也经历过上面的种种问题,代码从最简单的线性拼凑,到逐渐封装、数据分离、剥离出框架,使用平台……自然也遇到过种种数据、环境、UI变动、测试不稳定等问题。经过探索,最终确定了随机化思路在自动化测试中的应用,其实可以说这就是实现自动化测试智能化的一种手段。从个人角度而言,其实我本人是不太推崇公司或部门搞得自动化测试平台化,美其名曰:让小白都可以写自动化,可是那样局限了测试代码编写人的思路,也限制着代码能力和自动化技术水平的提高,我建议有一定基础的同学要逐渐抛弃平台(但是可以自己试着去构建平台化),脱离平台走自己的路,这样才能体验代码重构的乐趣和技术水平飞速提升的愉悦。当然从公司或部门的角度,平台化可以更好的管理、交接和产出。

说了这么多,好像还没有说到主题上?其实前面铺垫那么多,就是想说明的是不能只会用某技术、某框架,要学会或者领悟其思想。本篇主题突出随机化这个思想,其实很容易理解,数据随机化,操作随机化、流程随机化(暂时只想到这么多),后面会具体说明,那么使用随机化思想有什么好处呢,减少数据对测试的影响,减少代码的不稳定性,增加测试覆盖率,增加测试发现bug的能力……试着理解下,比如验证按指定日期和某下拉项查询:
1> 通常用例实现:日期数据固定指定具体某天,下拉项固定某个选项,然后查询对比结果;
2> 下面我们按随机化思想来实现:日期随机取某天(每次随机的取数都可能不一样,如果测试执行多次,那么就增加了日期的选择范围),下拉项随机选择某个选项(同样增加了下拉选项的覆盖),然后再查询对比结果。


 


这就好像抽奖转盘,有了上面的例子,是不是很好理解了?那么我们看具体如何实现随机化:

1、测试数据随机化:
1>这里以Java为例,Python等其他语言肯定也有对应的函数,利用Java已有的Random对象和Math类生成随机数据,例如:
int randomInt = new Random().nextInt(100); //[0,100)
randomInt = Math.random() * 100;//[0.0,100.0),查看源码可以发现Math.random()其实等同于new Random().nextDouble();

2>有些时候我们的数据并不是上述简单的数据,这就需要对数据进行采集,将其放到数组或者集合中进行储存,再通过随机生成数组或集合的下标,进而构造相应的随机数据,例如:需要对一批日期范围进行随机,数据采集后定义日期数组:
String[] queryDates = {"今天","昨天","最近7天","最近30天","上一个月","最近一年"};
String randomDate = queryDates[new Random().nextInt(queryDates.length)];

2、测试操作随机化:
基于数据随机后,可以更进一步的对界面的元素集合(如:下拉列表框选项集合、复选框集合、单选按钮集合、数据表格行或列集合、按钮集合、链接集合等)进行随机指定,例如:
List<WebElement> optionList = driver.findElements(By.xpath("XXXXX"));
int randomIndex = new Random().nextInt(optionList.size());
optionList.get(randomIndex).click();


3、测试流程随机化:
对于测试流程或者用例步骤的随机化,可以上升到智能自动化测试领域,比如基于模型的自动化测试(MBT),典型的测试模型有以下几类:
1>有限状态机,比如线程状态图:


 

2>UML模型
3>马尔可夫链
4>文法模型
在实际应用中, 用得最多的是有限状态机模型和UML模型,有限状态机(FSM:Finite State Machine),简称状态机,是表示有限多个状态以及在这些状态之间转移和动作的数学模型,构建有限状态机模型,常常需要对模块与模块、页面与页面,甚至元素与元素之间构建出有向状态图或有向关系图,如下图所示:


 

然后通过算法(最短路径、最长路径等)找到一条具体的路径,进而测试流程就可以按照这个路径进行。按照最短路径算法,上图的有向状态图就可以产生如下路径:
start——>状态1——>状态2——>状态4——>end
start——>状态1——>状态3——>状态4——>end
如果忽略进入条件start,那么对于每一个状态按最短路径算法就可以产生路径:
状态1——>状态2——>状态4——>end
状态1——>状态2——>状态4——>end
状态2——>状态4——>end
状态3——>状态4——>end
这里具体在代码中怎么应用,就需要自己写算法去实现了(如果不记得了,顺便回去补下《数据结构》 /斜眼笑,后面我这边如果有时间且可以整理的出,到时候再写一篇具体的实现文章)。

OK,又写了大半晚上,希望能对大家在自动化测试思想上有所帮助和提升,出去面试自动化测试的理解,按上面这么说,绝对让面试官眼前一亮。



作者:测试开发
链接:http://www.jianshu.com/p/2fc1b73bacda
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

原文转自:http://www.jianshu.com/p/2fc1b73bacda