“这段代码能跑但总觉得哪里不对劲。”如果你在审查代码时有过这种感觉说明你已经嗅到了代码的坏味道。作为软件测试从业者我们往往比开发人员更早感受到坏味道带来的痛苦——一个看似简单的变更导致回归测试大面积失败一个边界值测试要绕过层层嵌套的条件才能命中一段重复逻辑让测试用例本身也陷入复制粘贴的泥潭。语法错误编译器会告诉我们但真正的质量隐患藏在那些不会报错、却让系统日渐臃肿的坏味道里。本文从测试视角出发梳理代码审查中最该关注的五个坏味道帮助你在评审中更早地发现风险减少返工。一、重复代码测试用例膨胀的元凶重复代码是最容易识别、却最容易被容忍的坏味道。同一个验证逻辑出现在三个接口里同一段价格计算被复制到订单、退款、对账模块中开发人员常常因为“时间紧”或“怕影响已有功能”而选择复制粘贴。但对测试人员来说重复代码意味着三倍的风险你需要为每一处重复编写相似的测试用例而一旦业务规则变化修改遗漏任何一处都会导致线上事故。审查时不要只看当前文件。当发现一段逻辑与另一处高度相似时立刻追问“这两处真的需要独立存在吗”如果是同一个类内的重复可以建议提取公共方法如果是兄弟子类间的重复应把公共逻辑上提到父类如果是完全不相关的类出现重复则需要提炼出独立的工具类或服务。从测试角度你可以用一句话推动重构“这段逻辑如果改了你能保证所有复制的地方都同步修改吗”这个问题往往能让开发人员意识到风险。重构后的代码不仅减少了测试用例数量更重要的是让业务规则有了唯一出口。当价格计算逻辑只存在于一个方法中时你只需要围绕这个方法设计等价类和边界值而不必担心某个角落还藏着另一套算法。二、过长方法理解成本与测试盲区一个方法几百行从参数校验、业务处理到日志打印全塞在一起这是测试人员最头疼的审查对象。过长方法的问题不是“代码多”而是“职责多”。当你试图为它设计测试用例时会发现很难孤立地验证某一环节想测异常处理必须先构造正常流程的前置条件想覆盖某个分支要读懂前面八十行的上下文。审查这类代码时可以关注三个信号方法名中出现了“And”或“Or”如 validateAndProcess说明它做了不止一件事方法体内有明显的注释分段如“//第一步校验参数”说明开发人员自己也在用注释划分职责存在大量临时变量在不同阶段被反复赋值说明这些阶段本可以独立成方法。推动重构的策略是“提取方法”。建议开发人员按照“校验-处理-组装返回”的结构拆解让每个小方法只做一件事。对测试人员来说这带来了直接的好处你可以为每个小方法单独设计单元测试组合起来又能覆盖完整流程测试金字塔的底层会更稳固。同时当某个环节出现缺陷时定位也更快——你不会在一个五百行的方法里逐行排查而是直接锁定对应的小方法。三、数据泥团被忽视的边界风险总是成对出现的参数比如姓名和身份证号、经度和纬度、起始日期和结束日期如果它们在多个方法签名中反复同时出现就形成了数据泥团。这种坏味道在动态类型语言中尤其容易被忽视因为开发人员习惯了传递多个独立参数而不是封装成对象。对测试人员而言数据泥团隐藏着严重的边界风险。当起始日期和结束日期作为两个独立参数传递时校验逻辑往往分散在各个方法中有的方法校验了起始早于结束有的忘了校验有的甚至允许结束早于起始。你不得不在每个用到这对参数的接口里重复测试日期顺序的边界情况而一旦某个接口漏测数据混乱就会流入数据库。审查时如果发现一组数据在三个以上方法的参数列表中出现就应该建议封装成值对象或数据类。例如将起始日期和结束日期封装为“DateRange”类并把“起始不能晚于结束”的校验逻辑内聚在这个类中。这样一来所有使用DateRange的方法都不再需要重复校验你的测试也只需要围绕DateRange的构造器设计边界用例而不必在每个业务接口中重复覆盖。四、发散式变化与霰弹式修改回归测试的噩梦这两个坏味道是一体两面都指向“修改成本高”的问题。发散式变化是指一个类因为不同原因被频繁修改比如订单类今天因为支付规则改、明天因为物流规则改说明这个类承担了太多职责。霰弹式修改则相反一个业务规则的变更需要同时修改七八个类比如增加一种优惠类型要改动订单类、用户类、优惠券类、结算类等。测试人员对这两种坏味道的感知最直接发散式变化意味着每次修改都可能引入不相关的副作用你的回归测试范围被迫扩大霰弹式修改意味着开发人员很容易遗漏某个修改点导致线上出现“改了但没完全改”的缺陷。审查时可以关注类的修改历史。如果一个类最近十次提交涉及了三个以上不同的业务模块就是发散式变化的信号如果一个需求改动涉及了五个以上的文件就要警惕霰弹式修改。推动重构的方向是让类职责单一把支付相关逻辑移入支付类把物流相关逻辑移入物流类。对于霰弹式修改则需要把散落各处的相同变化原因的逻辑集中到一个类中。重构后你的回归测试策略会更清晰修改支付逻辑时只需重点回归支付模块而不必把订单、物流全部跑一遍。五、过度亲密与中间人测试桩的复杂度陷阱当两个类互相访问对方的私有成员或者一个类的一半方法都在转发调用另一个类时就出现了过度亲密和中间人坏味道。这种设计会让单元测试变得异常困难你想测试A类却发现必须实例化B类并设置一堆内部状态你想Mock掉B却发现A对B的调用深入到了私有细节Mock无法覆盖。审查时如果看到一个类频繁使用另一个类的Getter来获取内部数据再做计算这就是“依恋情结”的信号——这段计算逻辑更应该放在数据所属的类中。如果看到一个类的大部分方法只有一行代码直接调用另一个类的同名方法那这个类很可能只是无意义的中间人可以移除。推动重构的建议是“搬移方法”把依赖其他类私有数据的方法搬移到那个类中让数据和操作它的行为待在一起。对于中间人可以直接让调用方绕过它访问真正的服务类。重构后你的单元测试不再需要构造复杂的对象图Mock策略也更简单直接测试用例的可维护性会明显提升。代码审查不是语法检查而是设计质量的集体守护。作为测试人员你的优势在于对变更风险和测试成本的敏感。当你从这五个坏味道的角度审视代码时你提出的就不只是“这里有个Bug”而是“这种写法会让后续测试越来越难维护”——这恰恰是开发人员最容易接受的重构理由。下一次代码评审会上试着不再沉默用坏味道的语言描述你看到的问题你会发现团队的质量对话进入了更深的层次。