【目标】:让机器像人一样去测试未知的web页面。(这里变换一下思路,其实是研究基于人工智能的用例生成系统)
【涉及到的问题】:驱动机器去测试的一些列动作逻辑从何而来?每个动作所携带的数据入口在哪儿?
【涉及到的难点】:如何让机器像人一样去理解新页面,如何让机器使用动作逻辑+数据对页面进行测试?断言该怎么引入?
【探索的方向】: 1. 基于前端埋点的数据大量收集整理 2. 模型驱动方法 3.监督学习下的图像识别分析方法 ...(如有不同见解请留下宝贵意见)
下面结合问题、难点对探索方向做进一步的分析:
埋点+大数据归类分析
该方法的大前提是在线上环境的源码中“插桩”,植入一段js,将用户操作时的一系列动作轨迹和结果信息保存下来,回传给数据库,这样做最终问题留给了数据分析,期望从一堆杂乱的数据中去抽取大概率的路径覆盖,这样做的结果会有3方面问题:
1. 源码插桩,开发会考虑性能问题;属于强行介入式的,简单粗暴;不易达成共识;
2. 用户尚若发现自己的操作持续被窥探中,后果将不堪设想;信息外泄事情就更大了;因此这个方案看似简单,实则考虑甚广;
3. 一堆杂乱的使用数据没有先后顺序,诸如先干啥后干啥此类信息不明;全为并列关系;
4. 最核心的问题来了,即使是大量用户使用也无法做到功能的全覆盖,换句话说,用户只是使用了自己认为最常用的那些功能,而没用到的功能或者没有走过的路径不敢保证其没有问题;漏测。
模型驱动
模型的目的就是用来为构造测试用例而进行的被测系统描述。一个测试模型可以由箭头和节点组成如下图所示:
Start顶点: start顶点不是必需的。如果使用,则必须有1个(且只有1个)顶点名称为:start.
从start顶点出发只能有1个边。start顶点不会包括在任何生成的测试路径中,它只表示一个开始位。
顶点或边的名字(name): 名称是第一个单词,位于标签中边或顶点的第一行。
标签(Lable): 标签是点或边上的所有文字描述。
守卫(Guards)仅用于Edge: 守卫guard是一种只与边相关的机制。他们的角色与if语句相同,并且使边有资格或者没有资格被访问。守卫guard是一个用方括号括起来的JavaScript条件表达式只有一个。[loggedIn == true]上面意味着如果属性loggedIn等于true,则边是可访问的。
操作(Action)仅用于Edge: 动作是仅与边相关联的机制。这是我们要在模型中执行的JavaScript代码。它放在正斜杠之后。Action可以有多个,每个语句必须以分号结尾。/loggedIn=false; rememberMe=true; action是动作代码,它的执行结果将作为数据传递给守卫。
路径生成器: 生成器是决定如何遍历模型的算法。不同的生成器将生成不同的测试序列,并且它们将以不同的方式遍历模型。多个发生器可以串联。
random( some stop condition(s) )
以完全随机的方式浏览模型。也称为“醉汉走路”或“随机步行”。该算法通过随机从顶点选择出边,并且在下一个顶点时重复此过程。
quick_random( some stop condition(s) )
尝试运行通过模型的最短路径,但以快速的方式。这是算法的工作原理:
1. 选择一个尚未被随机访问的边。
2. 使用Dijkstra算法选择到该边缘的最短路径
3. 走该路径,并将所有执行的边标记为已访问。
4. 当在步骤1中达到选定的边缘时,从头开始,重复步骤1-> 4。
该算法对于非常大的模型工作良好,并且生成合理的短序列。缺点是当与EFSM结合使用时。该算法可以选择被守卫block的路径。
a_star( a stop condition that names a vertex or an edge )
将生成到特定顶点或边的最短路径。
shortest_all_paths ==> (Not released yet)
将计算并生成通过模型的最短路径。每个边缘的成本设置为1. 不建议使用此算法,因为对于较大的模型,并且使用模型(EFSM)中的数据,将需要相当长的时间来计算。
看起来,模型驱动的本事很大,可以从图像中分析出边和节点的关系,形成测试路线, 叠加数据形成测试用例;但是实操起来,该中方式依然存在两个方面的问题:
1. 测试人员不得不去先画这个测试逻辑+数据的关系图,而随着页面复杂度的提高,最终这个图表也会面临维护难度大的问题
2. 画图耗费了大量的前期人力,而且测试本身没有测重,没有优先级,没有重点,不利于策略模式下的定制化测试;最终的结果是一种策略,一副逻辑图,重复造了轮子。
监督学习下的图像识别分析方法
为什么使用监督学习?因为机器学习的能力尚不稳定,没有结合已知知识体系自我思考的过程,在学习过程中时常会引入不必要的错误数据(系统误差数据),因此必须清晰划定界限给予明确分类标准以减少系统误差。
使用图像识别的考虑是在不完全依赖于网站源码的基础上,能结合人工智能,在N个网页中学习出一套模糊的知识体系,能用于第N+1个未知网页的模糊匹配,得出一个概率队列,根据设置的权重参数,最后能得出准确的结论;由于不同公司的前端开发风格不同,因此无法从源码上直接下手。
该方法面临的挑战:
1. 思考如何获取到动作逻辑
2. 动作数据从何而来
3. 若以VUE为前端框架写的站点,源码如何获取?(思考:FirePath的侵入方式)
先写到这里,等后面彻底解决上述问题之后再来丰富,目前暂时只能突破到这里了!(欢迎探讨)
时隔1周,在之前遗留问题的基础上重点解决【动作逻辑】和【操作数据】问题,如今有了新的突破,先来看测试实时日志:
通过“数据字典”和“行为轨迹”的建立,能够1.创建出指导机器行为的一系列“动作”(当然,包括先后顺序关系)2.绑定“数据”到动作上(例如:一个【输入】动作,携带一个【参数】)
上述问题解决后,系统全覆盖模拟生成一系列的【测试用例】,交由“回放系统”进行回放,实时记录操作日志;注意:全程不用人写测试用例,也不用画逻辑图,机器只负责学习然后测试。大家可能会问个问题,机器究竟学了什么?可以告诉大家,两个方面:
1. 学习页面,机器自己熟悉新页面的构造(图像识别)
2. 学习过去的自动化用例(大数据分析),这里有些许壁垒,如果没有特定的用例中间层,这个大数据分析可能得不到想要的东西。至于什么是“特定的用例中间层”,请大家翻看我之前的文章【Web端自动化】所介绍的录制工具;“中间层”由这款录制工具得来。
接下来做什么?
准备使用朴素贝叶斯机器学习对生成的这些用例逐个求一个准确率,最终衡量一下这套理论的可行性!谢谢大家阅读,欢迎讨论!