线上会存在一种任务，定时或者手动出发，我们称之为“脚本”，也可以称之为“job”

一、脚本的特性

• 无过程：只有开始和结束，过程迅速且黑盒。
• 无交互：脚本处理的业务场景都几乎没有交互，只有数据被改变。后续逻辑才有交互。
• 速度快：脚本处理速度快，一般在从开始到结束，在ms级别。
• 风险高：脚本逻辑如果有误，一般会导致数据错误，容易引发较严重的线上故障。数据修复成本高。
• 无预发：目前job类服务是不支持预发环境验证的，不能语法环境验证，只能直接上线。

二、脚本可能用在什么情况

• 数据清洗：同库同表情况下，数据资源替换；
• 数据库同步数据到内存缓存：每N时间，同步一次数据库信息到内存；
• 流水对账：结算相关，使用脚本对营收流水数据对账；
• 结算：X内容结算为Y货币，使用脚本进行数据结算；
• T+1生成数据：货币等审核数据同步；
• 活动玩法：一次性的晋级淘汰玩法之类的；
• 大量数据拉取信息：一般用在活动，结束后需要拉取特定条件的信息，方便产品做后续的数据测算；
• 批量报名：一般用于活动，多阶段时，使用脚本完成赛段之间的数据拉取和报名；
• 数据检查、补偿：按分钟进行数据检查，补偿发放奖励等逻辑；
• 定时任务、触发告警：部分业务会用定时任务，按阈值触发告警，发送告警信息；
• 轮询监听databus信息：我司很多服务都使用脚本方式进行信息监听；

三、深入分析脚本和测试脚本

端到端的测试中，可能并不去测试脚本，如果涉及到需要测试脚本，尝试自己去执行，不要过度依赖研发的执行命令（在测试研发代码的时候，对他的任意代码只可参考，保持怀疑，他的执行命令也是我们需要测试的产物）；

3.1 日志测试法

对应的场景：活动玩法/数据清洗等。适用于内部逻辑复杂，接口交互较多，没有过多数据落地和页面交互的脚本。

以某活动 决赛匹配部分 举例：（该赛事交互方多，分别有pk部分，榜单部分，房间信息部分，主播信息部分，且pk匹配时间有限）

以上是决赛赛段的全部匹配逻辑： 蓝色部分为明显能感知到退出的部分，绿色的部分为数据库表能够看到的表现，其它所有服务端逻辑都是无法直接看到的。

对于这种服务端逻辑较重，中间数据流转逻辑复杂，没有过多页面交互和数据落地的脚本。最适用日志测试的方式，例如，可以依赖日志观测到的逻辑点如下：

红色箭头为判断逻辑，判断逻辑需要有日志，可以查询到一次脚本中拉取到的数据和实际判断的逻辑信息。黄色部分为调用其他服务获取到的主播或者房间信息，外部调用链需要有接口请求信息和response信息。可以为问题排查和逻辑判断提供数据依据。红色方框部分为很重要的，服务端使用数据结构做数据处理的部分，这部分需要日志信息。防止数据结构使用不当等问题的发生。

日志判断的合理位置：

1. 有条件判断的地方 if，else，case，三目运算符等位置。

2. 有外部接口调用的位置，需要准确得到被调用方返回的数据信息。

3. 数据结构使用的位置，需要明确感知到数据结构处理前后逻辑和数据是否合理。

4. 循环调用的过程，需要明确能够看到执行路径和次数，防止循环提前退出或者发生处理异常的情况。

   日志的增加需要考虑服务的压力，日志不是越多越好，过多的日志会使脚本执行速度变慢。能够清晰看到某一条执行路径即可。超出这部分的日志路径会缺失或者错误。如果业务逻辑过于复杂，可以加一部分测试时使用的日志，回归测试阶段删除或者注释掉即可。

附：日志分级&规范（等我写完再贴上来）

3.2 数据库和缓存 数据验证法

对应的场景：数据库同步数据到内存缓存中/流水对账/结算/T+1生成数据等。适用于内部数据处理逻辑较简单，且数据来源和数据处理结果有实时落地的脚本。

以活动的 文档举例：（依赖databus，处理数据的数据源来源是数据库和redis缓存，处理数据结束后，数据落地于数据库）

以上是某个赛段的全部结算逻辑：绿色部分为投递databus的时候可控制的传参，蓝色部分是明确落地的数据库和redis的数据源和处理结果。

对于这种偏重脚本内部逻辑较简单，数据源和处理结果都落在数据库和redis的情况，比较适用于依赖数据库和缓存数据的验证方式，用例设计可以偏重于数据校验和设计层面

截取部分用例如下：


红色箭头为多张数据库表关联逻辑的预期数据， 分支条件为databus数据依据。黄色的部分是涉及的redis key的设计。

数据库和redis的判断预期：

1. 明确数据库中字段的关系和预期值。

2. 明确了解数据库中多张表的关联关系。

3. redis的数据流转和变化关系，redis的字段设计。

4. 数据处理的时机，和不同状态下数据的变化。

   这部分需要严格确认redis key的过期时间和幂等键的合理性。以及数据库中的每个字断准确性，特别注意extra_data的数据准确性。

   上线前需要跟进为测试提供的日志的优化和删除

3.3 脚本特殊逻辑review 补充法

对应的场景：部分场景下脚本逻辑的流程图不能够详尽的画出细节，需要测试的过程中发掘测试点。适用于数据拉取，翻页等场景。

以某项目，脚本替换资源举例：

上述案例细节挖掘如下：

1. 全屏动画是如何判断的，用了哪些字断（知晓这里，可以分析出不同礼物类型被影响的情况）
2. 生成动画id，会不会影响已有资源，生成方式细节（以此来推算id生成规则是否合理，防止发生id重复的问题，或者服务重启，id的生成）

review代码：（可以看到判断的条件和生成id的方式）–担心敏感所以未放图。

适合脚本做细节挖掘点的情况如下：

1. 条件判断的逻辑字断细节
2. 数据拉取处理的翻页逻辑
3. 多个脚本的情况下，脚本之间调用链路

3.4 工具/脚本辅助测算

任务调度执行平台：

1. 可视化任务管理/运行（各环境）
2. 与接口自动化打通，建设自动化case

四、脚本必测的通用异常case（经验总结）