软件测试与日志

1.先了解日志的等级
    常用三个等级的日志：debug info error
    debug等级包含debug、info、error-------------------------测试阶段至少要打开debug日志
    info等级包含info、error---------------------------------info日志对测试阶段没有太大用处
    error等级就只有error------------------------------------error日志对测试阶段没有太大用处

    如何确定日志等级：找应用程序的任意一个日志来看即可。
    如何调整日志到指定的等级：
        1.让开发调整（通过配置程序的yaml文件）。  
        2.开发可能会给出链接来调整日志。找到这些链接对日志进行调整即可。

2.了解应用程序的日志记录情况
    不是所有应用都有完整的日志记录。
    比较完整的日志应该包括：
        1.后台程序关键步骤的日志。（开发写的info ，debug日志）
        2.后台程序每步处理涉及的完整sql，一般由框架打出来。
        
3.日志记录方式和清理日志方式
    3.1.先了解程序是单体结构还是微服务架构。
        一般单体结构的程序至少有一个服务日志。
        微服务架构的程序至少每个服务都有自己独立的日志文件。
        了解清楚后，就知道哪些服务看哪个日志了。避免出现做了业务找不到日志的情况。
    
    3.2.了解每个功能对应哪个服务。
        单体结构这个不用说了。所有功能都在一个服务里，日志也只看这个服务的日志。
        微服务架构就要弄清楚，哪些功能对应哪些服务。
        
    3.3.日志记录方式
        日志通过日志文件进行记录，日志文件会越来越大，所以一个服务每日会有多个日志文件。一般服务设置了日志文件达到多大，就会再生成一个新的日志文件，或者到达新的日期会有新的日志文件产生。一个服务当前的日志文件只有一个，但这个服务当天的历史日志文件有多个。

类似以下的树形结构

         /logs--

                         --crt.log

                                --crt.log.2024-01-08.5

                                --crt.log.2024-01-08.4

                                --crt.log.2024-01-08.3

                                --crt.log.2024-01-08.2

                                --crt.log.2024-01-08.1

                                --crt.log.2024-01-07.22

                         --ssy.log

                                --ssy.log.2024-01-08.05

                                --ssy.log.2024-01-08.04

                                --ssy.log.2024-01-08.03

                                --ssy.log.2024-01-08.02

                                --ssy.log.2024-01-08.01

                                --ssy.log.2024-01-07.22

Ssy和 crt可以理解为两个服务。其中crt.log和ssy.log为当前日志，其他都是历史日志。最外层的logs为这个程序的日志目录，这个目录专门存此程序的日志，并且设置了最初容量。

    
    3.4.清理日志
        随着应用程序运行时间越来越长，日志文件会越来越多，占服务器内存越来越多。如果设置的存日志文件的区域已经满了，则后面程序运行后，再去看服务器日志，会发现找不到最新的日志，只能看到历史日志。此时需要清理存日志的文件区域。
        一般存日志的区域全都是日志，清理的时候不能随意清理，而是按时间顺序，先清理历史的一部分日志。不建议全量清理，因为最近的日志可能保留起来，以备近期测试查询。
        清理日志文件，也需要通知项目组的开发、测试人员，大家没有异议再进行清理。

    此处附上清理日志的步骤。
        现象：运行程序后，查不到日志了，最近的日志文件都是历史数据。经排查是因为日志文件满了，需要清理日志文件。
        步骤：
            1.查看日志区域的内存情况。 df -h   注意要到你所在的日志文件外层目录去看内存占比。 用上图的日志结构举例，就是需要到logs的同级目录去执行df –h 命令。
            2.如果日志已满，则通知项目组成员需要清日志，并协商清理哪些日期的日志。
            3.得到同意后可以删除对应日期的日志文件。  echo "" > logfile.log   echo命令可以使用空内容覆盖文件内容
            4.再次查看日志区域的内存情况。
            5.跑程序，看日志是否写入日志文件。
            

4.看日志常用命令-linux命令
    此处就不列举了，可以看步骤5，根据自己常用的场景去收集命令，方便随时使用。

5.看日志的各种场景列举
    场景1：
        刚做的业务，后台报错了，立即去当前日志文件里查看。
        cat 当前日志文件|grep -A 30 -B 5 'Error'
        cat 当前日志文件|grep -A 30 -B 5 '业务数据ID'
        cat 当前日志文件|grep -A 30 -B 5 'globleId'
        cat 当前日志文件|grep -A 30 -B 5 '接口名称'
        有时不确定日志里是不是有这个Error字段（或rror字段去查也可以），则可以用业务数据Id去查询。查到后再识别出globleid之类的线程id，去看整个线程里是否有报错。如果知道当前所做业务的接口名称，则可以按接口名称去查日志。
        使用-A 30表示再多往下取30行，-B 5 是多往上取5行。这个方便我们查看前后几行的数据，方便确定找到的数据是不是我们想要的。
        
    场景2：
        想要找的数据是几个小时前做的了，当前日志文件可能找不到该数据了，则需要到历史文件里去找。
        cat 日志文件.*|grep -A 30 '查询关键字'
        
        
        文件名可以加上.* 模糊匹配，可以匹配不同日期的文件。如果自己知道业务数据就在当天，可以对当天的日志文件进行模糊匹配。如果知道业务数据在最近三天，可以对最近三天的日志文件进行模糊匹配。按此方法查询的内容只能对日志进行查看，但不知道日志在哪个具体的文件里。
        
    场景3：
        前端请求了一个接口，想查看这个接口的整个操作过程，对那些库表进行了查询、对那些库表进行更新、插入、删除等。
        
        vim 日志文件    先进入文件编辑模式
        /业务数据ID     再通过业务数据ID去查询globalId
        /globleId.*select   或 /globleId.*insert   或 /globleId.*update   或 /globleId.*from  或 /globleId.*数据库表名   分别查询sql里含这些关键字的日志片段
        也可以一次性查找/globleId.*insert|globleId.*update  用或的方式来查询多个条件
        此方法还可以减少眼睛去找耗费的经历，因为日志突出显示到有sql的语句上。
        
    场景4：
        面对一个不熟悉的业务，只知道有操作步骤是录入、复核、提交就到终态，但不知道每个操作步骤后入哪些库表。
        
        解决办法：手工操作一笔业务，进行录入、复核、提交，每一步操作后，都去看日志，参考场景3，去获取每个步骤进行的库表操作（一般就是入库、更新、删除这些操作）
    
    
    场景5：
        测试过程中，有时候需要对某些业务操作的日志进行备份。备份的原因可能是对日志进行分析，提取日志里的库表，以备后续查阅。
        一般备份日志都不是对整个日志文件进行备份。一般是对某笔业务的完整操作进行备份，用于对业务全流程的熟悉和了解（逐条日志阅读，以便了解整个处理过程，避免遗漏关键步骤）。所以备份思路是对一个完整业务的每个操作接口对应的日志进行备份。所以每做一步页面操作后，都需要去获取主要接口对应的日志globleId。再使用命令查询对应日志后保存为文件。
        
        cat 日志文件|grep -A 30 'globleId' > 备份文件.txt
        
        此处-A 30只是取了后30行，这个不是固定的，可以看最终生成的备份文件里是否有日志还有 -- 存在，如果存在，就是有些行没有显示完，则可以酌量增加-A后面的数字。直到日志里每行没有-- 为止。
        
    场景6：
        如果已经有某个业务全流程的日志备份文件，则可以从文件里获取每步操作的库表变动。
        如此可以达到虽然短时间没法熟悉系统业务，也找不到完备的资料，也能自己集全这个业务每步的库表操作了。

    场景7：

         多服务日志的查看。一般针对微服务架构，有多个服务。一个请求发起后可能需要多个服务依次处理。         

         查看日志的方式是先知道这个请求先走哪个服务，则先去那个服务里去读日志，一般在日志最后几行会打印去调用某个服务（其实就是发RPC请求），那么在当前日志里记录下来globleId(这个globleId是当前请求在几个服务流转的唯一凭证)，此时进入到被调用的服务，用globleId去查询，再详细看日志，一般在最后几行会显示请求处理成功或者再次调用其他服务。依次类推，如果调用了其他服务，就去其他服务里去看日志。如果处理成功，则返回第一个服务的日志里，去看该服务是否收到了处理成功的回复，是否正确更新了某些表。

         一个请求经历多个服务这种，在找错误日志时依然要多个服务挨着去找。例如：一个请求依次调用A,B两个服务。一般A，B两个服务里做的验证和数据处理不一样。如果发起请求，在A服务处理过程中报错了，则直接进入A服务就可以查看到错误日志。如果发起请求后是在B服务报的错，则我们看A服务日志时，可以看到报错，但是看不到详细的错误过程（因为B服务只返回了结论，没有错误细节），此时就要去B服务去看日志，找到详细的错误。