代码的“行车记录仪”，如何借助日志做测试？

[内部资源] 想拿年薪30W+的软件测试人员，这份资料必须领取~

Python自动化测试全栈+性能测试全栈，挑战年薪40W+

后疫情时代，已经不对感染人群做分析了，那过去我们是如何追踪的？依靠链路追踪，通过数据分析，然后分块治之，精准定位。

测试也是如此，准确识别每一个被测逻辑的执行路径，准确定位过程，才能知己知彼，百战不殆。行业内有许多的测试手段，如静态代码分析、动态代码扫描、功能测试用例穷举、单测用例覆盖等等，本文不做赘述和分析。

本文浅谈一下代码的“行车记录仪”----日志，在测试技术中的应用。

一 、代码和日志相辅相成

码农界有传言“线上问题定位不到的时候，才知道该在哪里打日志”，代码的每一次运行都可能因为不同的干扰因素，使其“脱离正轨”，每一次执行都可能因为某些异常、判断条件而执行不同的代码段。

日志的链路追踪，代码的执行过程记录，在生产中尤为重要。日志不仅能够记录代码执行路径；也可以作为监控分析的数据来源；可以及时提示代码异常；也能够为基础监控建设提供可靠依据；更为测试工作提供更多的执行过程信息。

日志不止是开发者要关心的部分，测试同学对日志的记录情况，日志的书写规范和日志的必要性也要有独特的见解，如此，才能更好的为线上质量保驾护航。

二、日志辅助测试的案例化分析

那什么场景必须用到日志来做辅助测试呢？    

黑盒的玩法设计    

什么是黑盒的玩法设计？我们来举个例子：当开发对一个抽奖的sdk设计了A、B、C、D四种精细化的算法，每一种算法都根据随机概率选择的选中一个奖品，最终输出该奖品结果。

可以看到，概率性这个概念就很模糊了，正如数学概率题一般，我们即使知道概率是多少，也不能完全准确预判出结果。那么这个选择的过程就尤为重要，到底命中了哪种算法？又以多少概率选中了结果？ 

类似于这样的，具备以下特征的，我暂且称为较黑盒的玩法：

1.无持久化过程：只有开始和结束，没有持久化的设计，过程迅速且黑盒。

2.无交互：处理的业务场景都几乎没有交互，只有数据被改变，后续逻辑才有交互。

3.速度快：处理速度快，一般在丛开始到结束，在ms级别。

4.风险高：逻辑如果有误，一般会导致数据错误，容易引发较严重的线上故障。数据修复成本高。

5.未知依赖：依赖上下游信息，一般不可考证上下游信息准确度，数据和信息准确度及逻辑未知。

下面我们结合案例分析来看一下日志在测试中的重要作用：

以pk玩法，赛道划分及比赛逻辑的技术设计图为例，我们可以看到下图中逻辑的中转和出口相较于整个玩法逻辑的设计是较少的。大部分的中间状态和逻辑很难从功能角度观察到。

（蓝色表示逻辑出口，绿色部分为数据持久化部分）

测试工作最重要的是以事实为依据，所以，我们绝对不能仅通过对结果的预测和比较来判断代码的运行逻辑是否正常。

所以，针对上述案例，对于这种服务端逻辑较重，中间数据流转逻辑复杂，没有过多页面交互和数据落地的玩法，有效的通过日志手段的测试方式如下：

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

日志判断的合理位置：

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

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

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

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

三、日志可带来的

风险识别和故障预警效用

日志在日常的项目是很有效的一种可以追溯用户行为的方式。不仅可以作为问题响应和发现的指示灯，也可以用作服务健康巡检的指标。除此之外，用来进行数据统计，用户行为分析，进行线上质量运营和后期优化也是一种不错的数据收集的手段。

线上日志多用来进行监控的建设，线上的质量分析，问题的追溯以及服务健康的指标制定。也是线上用户行为分析的一项有利的数据参考依据。甚至日志和监控数据还可用于生成过程中的海量样本仿真建设。在生产的过程中有着非常重要的作用。

四、日志不是万金油，不可滥用

既然日志的用处这么多，那是不是打日志越多越好呢？显然不是!

日志的增加需要考虑服务的压力和服务的框架设计，日志不是越多越好，在同步流程中，过多的日志会使代码执行速度变慢，会给服务带来无形的压力。能够清晰看到某一条执行路径即可，如果业务逻辑过于复杂，可以加一部分测试时使用的日志，或者使用日志等级降级策略即可。

日常生产的过程中，要着重关注以下几点：

1.唯一的id（uid、traceid等）：日志也需要唯一的身份id，以一个唯一id，贯穿整个路径最好。查找日志的过程中，执行路径便会像一个叙事有条理的故事般，逻辑脉络清晰，过程娓娓道来。
2.数据信息简单：不可要求日志中加入统计类运算类日志，日志需要能够直白明确表达出代码执行状态即可。当下有什么数据，便打印什么数据。切忌对日志做逻辑处理。统计和逻辑类的数据操作要使用异步方式去完成。
3.日志等级划分意识：日志在日常的使用和规范中，需要明确划分等级，方便对问题日志进行监控和线上服务故障体系划分（以下做参考）。

日志等级划分：

• 1.ERROR

  影响程序正常运行、程序出现请求中发生的异常情况。

  如：接口请求失败；第三方对接的异常；程序功能异常，抛出错误堆栈信息；p0级别业务功能异常等

• 2.WARN

  有告警，但是不影响正常使用，但是出现频率需要严格关注。

  如：找不到对应逻辑配置，走兜底逻辑；容错情况发生；px级别业务逻辑异常返回发生；系统资源告急。 

• 3.INFO

  记录过程信息，对接第三方的源数据信息等，一般无需关注，可用作追踪问题，建设用户数据画像使用。

  如：调用第三方时的调用参数和调用结果；数据源获取到的信息；逻辑处理结果和过程信息；定时任务的开始执行与结束执行。

• 4.DEBUG

  记录调试信息，可以对系统每个关键性的过程进行更精确地记录。

• 5.TRACE

  更加详细的服务调用流信息，一般使用(一般请使用DEBUG级别替代)

经常有人说；“好的日志可以一定程度上反映线上服务的质量和问题处理效果”。上述说了很多和日志相关的细节，我们在测试的过程中也要结合过程和结果来衡量一个服务的质量，缺一不可。

---

资源分享

下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】