日志不是摆设，是出事时的第一反应
跑自动化测试的时候，最怕的不是报错，而是报错之后啥都不知道。比如一个登录流程突然失败，你点开执行结果，页面只写‘测试未通过’，连在哪一步卡住都没说——这种时候，没有日志就跟黑灯瞎火找开关一样。
日志记录做得好，能一眼看出是账号没输进去、验证码没加载，还是网络超时。它不光告诉你‘坏了’，还得告诉你‘怎么坏的’、‘什么时候开始坏的’。
该记什么？别只留一句‘开始执行’
很多人以为打印个‘Test started’就叫日志了。其实真正有用的信息得具体。比如在点击按钮前，记下当前页面URL和元素是否可见；提交表单时，把输入的数据脱敏后也记下来。
举个例子，你在跑一个下单流程，到了支付页突然中断。如果日志里只有‘进入支付页’，那几乎没用。但如果写了‘跳转至 https://pay.example.com/order?id=12345，等待加载支付方式超时（等待10秒）’，问题范围立马缩小到网络或接口响应。
结构化输出让排查更高效
纯文本日志看多了容易眼花。建议用JSON格式记录关键步骤，方便后续提取和搜索。比如：
{"timestamp": "2024-04-05T10:23:15Z", "level": "INFO", "step": "fill_login_form", "data": {"username": "user***", "password_filled": true}, "status": "success"}这样的格式可以直接导入ELK这类工具做集中分析，哪类操作失败最多，一查就知道。
别忘了异常堆栈和上下文
当测试崩溃时，只记‘测试失败’等于没记。必须捕获异常并打印完整堆栈。更重要的是带上当时的上下文：浏览器版本、测试环境IP、用例编号、甚至当前重试次数。
比如某个用例在CI流水线里偶尔失败，有日志显示‘第3次重试仍无法连接数据库，错误码: ECONNREFUSED’，结合时间戳发现总出现在每天上午10点，很可能就是定时任务占满了连接池。
控制日志量，别让噪音淹没关键信息
也不是日志越多越好。有些框架默认每行代码都打一条debug日志，几千条里才有一条有用的，反而影响排查效率。合理设置日志级别，生产或CI环境中用INFO以上，调试时再打开DEBUG。
另外，敏感信息如密码、token要自动过滤。可以用正则在输出前替换掉，避免泄露。
日志要能追溯到具体执行实例
多个用例并行跑起来，日志混在一起怎么办？每个测试运行分配一个唯一ID，并在每条日志前加上[TEST-7X9A2]这样的标记，查问题时用grep一筛就出来整条链路。
配合CI系统的话，把这个ID关联到构建编号，点开流水线详情就能看到完整日志流，不用登录服务器翻文件。