实测系列是纯硬核技术文章，并且是博主亲自演示已经落地取得一定成果的技术和原创教程，无偿进行分享，大家一键三连，支持一下！
上一节，我们大致明白了钱学森弹道技术应用在软件测试领域的背景和意义，算是补足了一个小技术黑洞。本节课我们就来讨论下实现的方案有哪些？毕竟是要在无数个随机方向事件后能确定走到目标的技术，在外界眼里看起来，这发导弹或者说自动化driver，就像在故意做着很多战术性欺骗动作，最终冷不丁的突然实现目的。
下面开始说说实现思路，大致有以下几点：
1. 完全随机碰撞法
在ui自动化的过程中，我们把模拟人手进行操作的驱动driver比作是这枚按照钱学森弹道的导弹。完全随机碰撞法，姑且先叫这个名字。
意思就是driver的具体操作是没有方向的，完全凭随机，在driver走到每个节点(页面)后都会完全随机的操作而去到另一个节点或促进另一个步骤，所以在A->E的过程中，运气最好的最短路程是直接A-B-C-D-E，运气不好的情况下，就可能是A-B-A-B-C-B-A-B-C-D-B-...（n多步骤）...-D-E，当然，步骤越多，就越偏离真实用户的操作，所以可以给这个办法设置一个最大步骤数，比如还是房源下单流程，正常下单是5步，那我们就可以划定范围为最大20步，当我们的程序启动后，会生成很多个路线，其中但凡超过20步，就直接终止废弃，经过相当长时间后，查重率接近90%（或某个其他阙值）后，终止程序。此时我们就会获得相当数量的低于20步的路线用例了，然后可以用driver去自动执行这些用例即可。
这个方法的优点是算法比较简单，很容易实现，相当于在传统monkey的基础上，增加了目标点(即：终止条件)，又规定了最大步骤数，又可以记录路线用例，又进行去重。但其中的回头路走的实在太多，确实不太像正常用户的行为。下面介绍改进方案：
2. 免回头随机法
依然是这个driver，在各个节点的随机动作中，进行了方向的指定，避免了走大量回头路的可能（或者规定最多走一步回头路，比如下错订单返回修改，然后修改后继续提交）。
所以在这个过程中，我们需要监控，一旦driver在节点随机时出现了回头现象，也就是走刚走过的节点，就进行记录，超过最大可回头数就直接过滤掉更古老的回头节点。
比如规定最大回头数0 ，即不可回头：A-B-C ，当driver在C节点继续随机下一步的时候，就要自然而然的过滤掉刚刚走过的B节点。
如果规定最大回头数1，即最多回头1次：A-B-C，当driver在C节点继续随机下一步的时候，我们是允许走回B节点的，但要过滤A节点。也就是说：我们允许【A-B-C-B-A之外节点】，但不允许【A-B-C-B-A】，如果C可以直接返回到A的话也不允许【A-B-C-A】。
这个方法下，我们可以直接避免大量回头太多的现实场景基本不出现的路线用例，性价比得到了显著提高。但，本质上，仍然是随机法，不具备钱学森弹道的目标趋向性，也极有可能出现死循环路线，如【A-B-C-B-C-B-C....】，也就是说，距离最真实用户行为还是有差距。所以继续看优化方案：
3.行为模拟随机法
其实，如果你能拿到你们线上服务器的用户日志或埋点数据，就可以统计出很多信息，比如各个页面的用户操作占比。
举个例子：用户在某产品详情页，点开评价的行为占比50%，点开商铺主页的行为占比10%，直接下单的占比30%，返回上一层的占比10%。
此时你就会发现，这其实并非完全随机的概率，并非是等分1/4。所以，用更少的用例来，覆盖最真实的场景，就成了性价比更高的方案。此时在我们的driver算法中，在某个节点后，在下一个操作的随机选择算法中，就要按照具体的日志统计，来强行改变概率。
比如你随机的列表是[评价,主页,下单,返回] ，此时随机就是1/4。如果改成如下方案[评价,评价,评价,评价,评价,主页,下单,下单,下单,返回] ，即可模拟出大致概率，这个列表页并非我们手动设置，只需要去读取线上日志自动生成即可，并不难。难的是，影响概率的情况是比较多的，不能取单一的片段，比如早上和晚上，工作日和节假日，双十一和平时。而软件产品的性能和线上服务器的动态调控负载均衡等问题，也可能会影响测试效果，这些都需要和开发运维同事合作来制定具体计划哦~ 。
但这种方案是需要大量线上日志来模拟出用户真实动作的，如果我们不具备这个条件呢？我只是个小测试，没有调取线上生产环境服务器日志的权限。所以你要来看看更优化的方案：目标趋向随机法
