基于人工智能的用例生成方法研究（Web）
【目标】：让机器像人一样去测试未知的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端自动化】所介绍的录制工具；“中间层”由这款录制工具得来。
接下来做什么？
准备使用朴素贝叶斯机器学习对生成的这些用例逐个求一个准确率，最终衡量一下这套理论的可行性！谢谢大家阅读，欢迎讨论！
