为啥会需要进行复位场景

好久没分享了，抽取一个比较重要的做分享吧。首先自动化门槛不高，但是深入还是会跟随代码能力很大变化，你目前所见都不是终点。
自动化遇到脚本不稳定或者动图没有识别到导致当前脚本失败，影响后面脚本，重新跑是在浪费自动化平台的 task。
这个方案是可以不用使用埋点，埋点主要需要其他部门去共建添加，共建如果不是一个组的，还是沟通会比较慢的。
很多时候新写一个关系图或者很长的 Yaml 太麻烦了，这个就是解决这个问题的。

这个功能也可以衍生开发，触发后记录脚本不稳定区域，比如在触发需要复位行为的时候，记录下自动化当前运行的时间。
如果这次复位失败，通过自动前进到视频播放的时间去抽取图片然后做出动图或者截取视频，这个不在本次分享，属于未来的朱雀巡检组件。
组件和平台概念，组件不一定是服务，有一些简洁的接入方式。平台就是一个服务。

根由

1.从 NodeJs 找 node_moudle 的思想
2.通过日志上下行方面检索。

第一个的根由是 NodeJs 找 node_moudle 的顺序是最近原则和用户公共区域原则，Node 里面的模块系统遵循是 CommonJs 规范。
第二个通过内部中间文件转换的日志服务，日志自动化分析是要取上文和下文的，一般来说日志行为 key，内容为 value。传入一个数字，负数为依次-1 往前行记录，正数是往后，用于展示。

条件模式

运行方式：运行 client 或者节点端用进程，不用共享内存，做到变量隔离。
自动化的 TestCase 模式，要实现这个有几个必要字段（如果没有平台可以用 excel 进行管理或者数据库的）
自动化字段序号自增，文件名.类名，成员函数名字，检查点界面名称，数据沉淀区域
序号自增（int）：不用解释了 也是会和功能测试映射
文件名.类名 (string) 是说明代码路径，一个文件一个类，拿到后在进行分割.转换
成员函数名称 (string) 是代码路径对应类下面的成员函数，也可以通过反射拿到。填写是为了和功能测试映射
检查点界面（string[]）：每个 case 尽量就一个检查点，如果有 2 个就是用,分割。
数据沉淀区域 (string[])：用于复位续跑，需要复位的类变量或者公共函数，复位可以理解为部分是 clear()，部分需要 - 一定的数字做为回退。
这里可以存数据库，存数据库优势是比较直观，也可以不存。

核心函数

这个函数函数，作用是评估界面名称是否支持恢复，返回是布尔类型， 这个函数也可以有多个参数，比如有回退按钮和直达路径。
核心函数也可以用多个状态（上面就有 2 个）去评估，这个是否可以用设置多个参数
多个参数用二进制 0101 比如这个是 4 个，在转成 10 进制，10 进制适合做枚举类，结果会调用通过 handler 处理函数，这个函数会进行复位的同时，把数据沉淀区域也恢复到同个 caseId.比如下面的 100 开始恢复到 97，对应需要复位的状态就在数据沉淀区域可视。

同步场景如何做

需要一个 goto 场景的函数用于回退方式。
1.返回上个场景/界面面再次进入
2.直达路径（游戏产业太少了，自动化 + 性能测试退出再进就不准了）
3.返回多个场景/界面再次进入（走最短路径）
数据沉淀区域和上面的都是根据 caseID 的，数据沉淀区域只需要做一些批量的 clear() 和做一些数字 +-和恢复具体某个数据的，所以会有多个函数。
一般数据不会很多的，如果都存在数组套数组里面，拿到数据沉淀的数组就是下标，下标就是 caseID+1.

具体例子

第 100 条 case 需要触发复位，那就是传入第 100 号 case，往前-1 依次寻找，然后调用核心函数去评估。
从 caseId 往上找对应一行自动化 case 的检查点界面名称，函数就是评估检查点界面名称的。
不同公司可以根据自己去开发评估，看到这里就知道不用去记录界面层级了。