企业网站关键词排名,什么网站类型,类似+wordpress+建站,wordpress悬浮代码线上会存在一种任务#xff0c;定时或者手动出发#xff0c;我们称之为“脚本”#xff0c;也可以称之为“job” 一、脚本的特性 无过程#xff1a;只有开始和结束#xff0c;过程迅速且黑盒。无交互#xff1a;脚本处理的业务场景都几乎没有交互#xff0c;只有数据被… 线上会存在一种任务定时或者手动出发我们称之为“脚本”也可以称之为“job” 一、脚本的特性 无过程只有开始和结束过程迅速且黑盒。无交互脚本处理的业务场景都几乎没有交互只有数据被改变。后续逻辑才有交互。速度快脚本处理速度快一般在从开始到结束在ms级别。风险高脚本逻辑如果有误一般会导致数据错误容易引发较严重的线上故障。数据修复成本高。无预发目前job类服务是不支持预发环境验证的不能语法环境验证只能直接上线。 二、脚本可能用在什么情况 数据清洗同库同表情况下数据资源替换数据库同步数据到内存缓存每N时间同步一次数据库信息到内存流水对账结算相关使用脚本对营收流水数据对账结算X内容结算为Y货币使用脚本进行数据结算T1生成数据货币等审核数据同步活动玩法一次性的晋级淘汰玩法之类的大量数据拉取信息一般用在活动结束后需要拉取特定条件的信息方便产品做后续的数据测算批量报名一般用于活动多阶段时使用脚本完成赛段之间的数据拉取和报名数据检查、补偿按分钟进行数据检查补偿发放奖励等逻辑定时任务、触发告警部分业务会用定时任务按阈值触发告警发送告警信息轮询监听databus信息我司很多服务都使用脚本方式进行信息监听 三、深入分析脚本和测试脚本 端到端的测试中可能并不去测试脚本如果涉及到需要测试脚本尝试自己去执行不要过度依赖研发的执行命令在测试研发代码的时候对他的任意代码只可参考保持怀疑他的执行命令也是我们需要测试的产物 3.1 日志测试法 对应的场景活动玩法/数据清洗等。适用于内部逻辑复杂接口交互较多没有过多数据落地和页面交互的脚本。 以某活动 决赛匹配部分 举例该赛事交互方多分别有pk部分榜单部分房间信息部分主播信息部分且pk匹配时间有限 以上是决赛赛段的全部匹配逻辑 蓝色部分为明显能感知到退出的部分绿色的部分为数据库表能够看到的表现其它所有服务端逻辑都是无法直接看到的。 对于这种服务端逻辑较重中间数据流转逻辑复杂没有过多页面交互和数据落地的脚本。最适用日志测试的方式例如可以依赖日志观测到的逻辑点如下 红色箭头为判断逻辑判断逻辑需要有日志可以查询到一次脚本中拉取到的数据和实际判断的逻辑信息。黄色部分为调用其他服务获取到的主播或者房间信息外部调用链需要有接口请求信息和response信息。可以为问题排查和逻辑判断提供数据依据。红色方框部分为很重要的服务端使用数据结构做数据处理的部分这部分需要日志信息。防止数据结构使用不当等问题的发生。 日志判断的合理位置 有条件判断的地方 ifelsecase三目运算符等位置。 有外部接口调用的位置需要准确得到被调用方返回的数据信息。 数据结构使用的位置需要明确感知到数据结构处理前后逻辑和数据是否合理。 循环调用的过程需要明确能够看到执行路径和次数防止循环提前退出或者发生处理异常的情况。 日志的增加需要考虑服务的压力日志不是越多越好过多的日志会使脚本执行速度变慢。能够清晰看到某一条执行路径即可。超出这部分的日志路径会缺失或者错误。如果业务逻辑过于复杂可以加一部分测试时使用的日志回归测试阶段删除或者注释掉即可。 附日志分级规范等我写完再贴上来 3.2 数据库和缓存 数据验证法 对应的场景数据库同步数据到内存缓存中/流水对账/结算/T1生成数据等。适用于内部数据处理逻辑较简单且数据来源和数据处理结果有实时落地的脚本。 以活动的 文档举例依赖databus处理数据的数据源来源是数据库和redis缓存处理数据结束后数据落地于数据库 以上是某个赛段的全部结算逻辑绿色部分为投递databus的时候可控制的传参蓝色部分是明确落地的数据库和redis的数据源和处理结果。 对于这种偏重脚本内部逻辑较简单数据源和处理结果都落在数据库和redis的情况比较适用于依赖数据库和缓存数据的验证方式用例设计可以偏重于数据校验和设计层面 截取部分用例如下 红色箭头为多张数据库表关联逻辑的预期数据 分支条件为databus数据依据。黄色的部分是涉及的redis key的设计。 数据库和redis的判断预期 明确数据库中字段的关系和预期值。 明确了解数据库中多张表的关联关系。 redis的数据流转和变化关系redis的字段设计。 数据处理的时机和不同状态下数据的变化。 这部分需要严格确认redis key的过期时间和幂等键的合理性。以及数据库中的每个字断准确性特别注意extra_data的数据准确性。 上线前需要跟进为测试提供的日志的优化和删除 3.3 脚本特殊逻辑review 补充法 对应的场景部分场景下脚本逻辑的流程图不能够详尽的画出细节需要测试的过程中发掘测试点。适用于数据拉取翻页等场景。 以某项目脚本替换资源举例 上述案例细节挖掘如下 全屏动画是如何判断的用了哪些字断知晓这里可以分析出不同礼物类型被影响的情况生成动画id会不会影响已有资源生成方式细节以此来推算id生成规则是否合理防止发生id重复的问题或者服务重启id的生成 review代码可以看到判断的条件和生成id的方式–担心敏感所以未放图。 适合脚本做细节挖掘点的情况如下 条件判断的逻辑字断细节数据拉取处理的翻页逻辑多个脚本的情况下脚本之间调用链路 3.4 工具/脚本辅助测算 任务调度执行平台 可视化任务管理/运行各环境与接口自动化打通建设自动化case 四、脚本必测的通用异常case经验总结