被你轻视了的log测试

日志概述

对于web端测试，大家一般都会有一个清晰的认识，测试对象是什么，该怎样展开测试。但要说起服务端测试，可能很多人第一时间就只能想到对于接口的功能以及性能测试。其实不然，服务端测试所涵盖的内容也很广泛，除了刚才提到的API的功能以及性能测试，还可能会包括对于代码，以及更加靠后的数据库、缓存、中间件（包括各种服务器、消息队列）、文件系统等的测试。而在这些内容中，最容易被忽略的，可能是对于日志（即所谓的log）的测试。

有人可能会说，日志还需要测试？

考虑下面两个场景：

当程序在某个用户操作时发生错误，产品经理急急找你排查，你面带微笑，从容地登录服务器，打开tomcat日志，发现空空一片，根本无从查起，会不会有一万只神兽从你脑中奔腾而过？

当你在测试一个软件系统时，发现在正常的log打印中夹杂了很多类似“11111”，“22222”，“！！！”等奇奇怪怪的信息，会不会露出一丝疲惫又忧伤的表情？

我们说，对于软件系统而言，日志是必要的，也是有价值的，尤其是在分布式系统中。日志于我们而言，就相当于飞机上的“黑匣子”，在出现问题时应该提供给我们证据和解决问题的线索以排除故障。

那么问题来了，日志应该记录些啥？什么时候记录？其实这两个问题都取决于打印日志的目的。目的不同，决定了日志内容的格式，输出的频度，输出的目的地也不尽相同。我们根据日志打印目的的不同，对日志进行了如下四种分类。

日志分类

总结而言，日志可能会有如下四种类型：

调试开发

这种日志一般用于开发或者测试期间调试程序、验证bug所用，这种日志量比较大，不过一般没有什么实质性的意义，正常来说，只应该出现在开发测试期间，而不应该在项目上线之后输出。

运行日志

运行日志记录程序的运行状况，特别是非预期的行为、异常情况，这种日志，主要是给开发、维护人员使用，为以后排查系统逻辑错误提供依据。具体什么时候记录，记录什么内容，不同的开发可能会有不同的喜好，自主性比较高。但是呢，也不能开发同学想怎么记就怎么记，一般最基本也得记录什么时间、什么人、什么条件、操作了什么内容、甚至返回了什么结果，这样才好排查问题。当然，现在后端大多数都是API接口的形式，定义一系列比较规范的异常错误码对排查错误是很有帮助的。笔者所在团队对于错误码的规范有一些比较好的实践，现分享给大家：

a.接口鉴权类别，错误码范围 1000~1999

b.接口成功类别，错误码范围 200

c.业务参数类别，错误码范围 3000~3099

d.业务逻辑类别，错误码范围 3100~3999

e.内部服务类别，错误码范围 4000~4099

具体定义如下图：

用户行为日志

这种日志记录用户的操作行为，一般会用于大数据分析，比如监控、风控、推荐等等。这种日志，一般是给自己或者其他团队分析使用，而且可能是多个团队，因此一般会有一定的格式要求，开发者应该按照约定好的格式来记录，便于其他团队的使用。当然，要记录哪些行为、操作，一般也是约定好的。比如笔者所在的DSP业务（用于给用户推荐广告），请求量级在百亿级别，这些请求日志必须都得按照约定的格式记录下来，并用logstash将全国各地所有机房的日志收集起来。比如DSP业务中，tomcat日志一般会定义如下的打印格式（在log4j中配置）：

其中%m所指代的就是具体的需要打印的内容，在代码中会以log.info形式输出，如：

其他参数意义或者具体配置方法如有必要，各位同学可自行百度查找log4j配置指南。

在广告展现以及点击时，也会有固定格式的nginx日志，比如在nginx.conf中这样配置：

然后在nginx具体的虚拟server配置中定义如下：

access_log logs/access.log combinedio;

即可按照定义好的格式收集日志到对应文件中。

所有这些收集到的请求以及打点日志都会交给反作弊团队，而反作弊团队判断用户是否作弊、以及与媒体进行结算金额的确定，全部依据都是这些用户行为日志。而且，这些日志还会根据日志唯一ID进行聚合，join成更详细的结构化日志以供业务团队分析每个广告的展现以及点击数据，用以判断当前广告的合理性，优化广告推送。所以大家可以看到，在大数据的背景下，这部分日志会变得越来越重要，而这部分日志是否稳定，也有很重要的业务意义。

错误日志

系统在测试阶段没有发现的各种bug，比如，“空指针”，“下标越界”等等，这些错误预示着程序发生了问题，除了记录什么时间、什么人、什么条件、操作了什么内容外，还需要记录exception的详细堆栈信息，甚至代码位置。常见的做法，是在程序中捕获到异常时，打印出详细的堆栈信息，以供分析使用。

我们了解了日志的分类，那么具体而言，在日志测试中，应该关注哪些情况呢？

日志测试关键点

1、查看日志是否切割以及切割粒度是否合理。一般而言，会按照日志的数量，以天或者小时为单位。比如DSP业务每天产出百亿条日志，这种量级就会以小时为单位进行分割，其他量级小一些的可以按照天来切割，更小的可以以更长周期切割。

2、查看普通日志和错误日志是否分离。不同类型的日志，一般可以打到不同的文件中，比如常见的tomcat日志可能会把正常日志输出到xxx.log中，把catch到的异常信息输出到xxx.log.wf中，这样更加方便查找错误。

3、查看log级别是否合理。开发测试阶段根据业务场景可能需要打印trace、debug、info日志，生产阶段一般会关闭debug、trace日志，而info一般会酌情保留，warn和error则必须保留。日志打印太多，会浪费大量的磁盘空间，同时对业务系统的性能也有较大影响，随着log量越大，性能损耗可能陡增。虽说现在SSD硬盘、异步日志打印等方式可能在某种程度上缓解性能影响，但也并不是每种情况下都奏效。

4、日志中敏感信息是否隐藏或者脱敏。有时候，可能会有开发习惯打印用户登录时的用户名、密码、金额等敏感数据，这是万万不可取的，万一服务器日志泄露，会造成灾难性后果。所以一般不建议在日志中打印敏感信息，但是也要保留必要的信息以供开发排查错误，比如用户名、用户id等。

5、在一个接口中传入的相关参数，应该完整打印一条，最好不要打印多条，因为日志最麻烦的就是当有并发访问的时候，日志会混在一起，会使问题排查变得更加困难。

6、接口请求时，log本身是否按照约定格式记录，并且记录的日志是否全面以便有足够的信息排查错误。这个一般各个业务系统都不尽相同，需要根据实际需求和情况来进行测试。

7、调试开发测试过程中的非关键日志信息是否去除。一般而言，这些信息都是使用log.debug()进行输出，而线上日志最低级别应该是INFO或者WARNING。不过，需要注意开发是否在log.info()中也输出了调试信息，这些是应该去除的。

8、对于前端日志，可能需要关注的就是console.log语句，这些调试信息也应该遵循上面介绍的一些原则。之前曾经看过一篇新闻说某开发同学在控制台输出了不合适或者敏感的信息，结果造成了一些争议，所以这个也是需要关注的地方。

总结

一份记录良好的日志对业务系统的健康以及价值的挖掘有很重要的意义，是服务端测试重要的一环，希望大家不要再“轻视”。

Qtest是360旗下的专业测试团队！

是WEB平台部测试技术平台化、效率化的先锋力量！