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

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

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

尽管有平台化和智能化的支持，可是很多时候我们看到的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 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，又写了大半晚上，希望能对大家在自动化测试思想上有所帮助和提升，出去面试自动化测试的理解，按上面这么说，绝对让面试官眼前一亮。

原文来自下方公众号，转载请联系作者，并务必保留出处。

想第一时间看到更多原创技术好文和资料，请关注公众号：测试开发栈