代码即文档：逻辑清晰、规范至上的自动化测试实践

　　去年劳动节值班，凌晨三点被监控告警炸醒——测试环境的负载突然飙到90%，可明明没有新版本部署啊。我原以为又是哪个开发偷偷跑压力测试，结果跳板机密码又过期了，等重置完密码登录进去，发现是自动化测试脚本把磁盘inode吃光了。最离谱的是，那脚本还是半年前写的，现在连原作者都记不清它到底在测什么——你说这文档要是有用，能搞成这样？

文章配图，仅供参考

　　我原以为“代码即文档”就是句漂亮话，结果发现它真能救命。那天小哥调的脚本是测支付接口的，原作者在代码里写了三行注释：“每100次请求轮转日志，防止inode爆炸，2023年1月5日”。这注释比wiki上的文档新了八个月，比开发口述的“可能有问题”准了十万倍。更绝的是，脚本里还嵌了自动清理的逻辑——要是日志超过500M，就自动压缩并删除旧文件。这逻辑要写成文档，得写半页；可代码里就三行if语句，一目了然。

　　可不是所有团队都吃这套。上周五跟开发组吵架，他们非说测试代码不用写那么细——“反正运行结果对了就行”。我当场甩出两个案例：一个是去年双十一前，测试脚本漏了检查缓存穿透，结果线上服务被打爆；另一个是今年春节，新脚本没处理异常分支，导致测试环境卡了三天僵尸进程。我说：“你们觉得代码不用写注释，可等出问题的时候，谁还记得当年是怎么想的？”开发老张叼着烟说：“那你们测试就该背锅。”我差点把键盘摔他脸上——背锅？背个屁！要是代码能当文档，出问题直接看代码，谁还扯皮？

　　但说归说，真要推行“代码即文档”，阻力比想象中大。上周三我让测试组把所有脚本的注释补全，结果小王问我：“注释写多长算合格？”我说：“能让三个月后的你，看一眼就知道这脚本是干啥的。”他挠挠头：“那得写多少啊？”我指了指他屏幕上的脚本——测用户登录的，就200行代码，结果注释只有两行：“1. 模拟用户登录 2. 检查返回状态码”。我说：“这注释跟没写一样，你得写清楚：模拟的是正常用户还是异常用户？检查的是200还是302？要是返回401，是走重试逻辑还是直接报错？”小王嘟囔：“这得写半页吧？”我冷笑：“半页都算少的——等线上出问题，你写十页检讨都不够。”

　　机房冷风机一直在响，吵得我头疼。我起身去倒水，路过开发组工位，看见老张正在改代码——他面前并排开着三个终端，一个跑测试，一个看日志，一个查文档。我凑过去一看，文档窗口里是半年前的测试报告，日志窗口里是今天的错误堆栈，测试窗口里是正在跑的脚本。我说：“老张，你这查文档呢？”他头也不抬：“查个屁，文档里没写这情况，我得看代码。”我乐了：“那你还看文档干啥？”他愣了一下，把文档窗口关了：“艹，忘了。”

　　其实“代码即文档”最狠的地方，是它能优胜劣汰。上周我们重构了一套测试框架，把所有老脚本都迁移过去。迁移的时候发现，有30%的脚本根本跑不通——不是依赖缺失就是逻辑错误。更离谱的是，有10%的脚本连原作者都找不到——这些人早就离职了，留下的代码像天书一样。最后我们直接把这些脚本删了——反正没人敢保证它们能正常工作，留着也是隐患。而那些逻辑清晰、注释完整的脚本，迁移起来顺风顺水，甚至不用调试就能跑通。你说这是不是自然选择？

　　可老板不这么想。上周例会他拍着桌子说：“测试组效率太低！别人家一天能跑1000个用例，你们才跑500！”我差点笑出声——那1000个用例的团队，脚本里连注释都没有，出问题得花三天定位；我们500个用例，脚本里注释比代码还多，出问题五分钟解决。老板不懂技术，他只看数字——可数字能当饭吃吗？上次线上事故，我们靠清晰的代码注释半小时定位问题，要是换那1000个用例的团队，估计得等到用户投诉才反应过来。

　　现在测试组有个不成文的规定：写脚本必须遵循“三秒原则”——任何一段代码，看三秒必须能明白它是干啥的。要是看三秒不明白，就得加注释；要是加注释还说不清楚，就得重构。刚开始大家不适应，觉得太麻烦；可三个月后，所有人都真香了——现在出问题，大家第一反应是看代码，第二反应才是喊人。上周小李的脚本出了个奇葩bug，他自己看了十分钟没搞定，结果发到群里，五分钟就有三个人指出问题——其中两个是其他组的，根本没参与过这个项目。为啥？因为代码写得清楚，注释写得明白，谁都能看懂。

　　当然，“代码即文档”也不是万能的。上周我们遇到个奇葩问题：测试环境的数据量突然暴增，导致脚本跑超时。查了半天发现，是某个开发偷偷往测试库灌了100万条数据——他说“为了模拟线上环境”。我差点气笑——模拟线上环境？线上环境的数据量是动态的，你灌100万条静态数据有什么用？更离谱的是，他灌完数据没通知任何人，导致三个测试脚本因为超时失败。后来我们在脚本里加了数据量检查的逻辑，还在注释里写了：“测试数据量超过10万条时，需手动调整超时时间，2024年4月15日”。现在这注释成了测试组的“防坑指南”——谁要是再灌数据不通知，直接看注释就能怼回去。

　　现在我最怕的是啥？是新人入职。上周来了个实习生，我让他先看代码熟悉项目。结果三天后他找我：“师兄，这代码里的注释怎么比代码还多？”我乐了：“多就对了——注释多的代码，说明原作者怕你看不懂；注释少的代码，说明原作者自己都搞不明白。”他将信将疑，结果第五天就真香了——他负责的脚本出了个边界问题，看注释直接定位到“当输入为空时，返回400错误”，五分钟就改了。要是没注释，他估计得折腾半天，还得问我“这里到底该返回啥”。

　　当然，我也知道“代码即文档”有局限。比如有些复杂逻辑，光靠注释说不清楚，还得画流程图；有些历史遗留问题，代码里可能藏着坑，注释里未必会写。但至少，它能让大多数问题在萌芽阶段就被解决——而不是等到线上爆炸，大家才手忙脚乱地翻文档、查日志、问原作者。原作者？呵呵，原作者可能早就离职了，或者换了部门，或者根本不记得自己写过这代码。

　　所以我现在的结论是：“代码即文档”不是口号，是生存法则。在这个连跳板机密码都会过期的时代，唯一不会过期的，就是代码里的逻辑和注释。你可以不写文档，但你必须让代码能当文档用——否则，下次凌晨三点被炸醒的，可能就是你。

（编辑：草根网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!