“开发经常改坏原有功能！”测试要把这个观点刻到骨子里

两个漏测缺陷

做测试的都知道测试无法穷尽所有场景，所以难免有缺陷遗漏到客户现场。客户也能接受软件中存在缺陷，但没有客户能接受正常使用就能发现的简单缺陷。简单缺陷会极大影响客户对软件产品质量的信心，他们会质疑你到底有没有测试。

下面两个就是客户会认为系统没有被测试过的简单缺陷。

第一个是交易系统的期货指令交易的批量委托界面，客户升级后原来的下单按钮没了。这个页面的目的就是让用户下委托，结果下单按钮都没了，用户的心情可想而知。就好比拿着碗去盛饭，发现没有饭瓢就去找饭瓢，结果只盯着手里饭瓢，饭碗丢了都毫不知情。分析原因是在此页面增加了算法功能，当有算法权限时有了一个算法按钮，这个按钮把下单按钮挡住了。测试只关注新增的算法权限是否正常，而对下单按钮的消失毫无察觉。

第二个没第一个离谱，但出错的也是原来的关键功能。交易投资单产品的委托明细页面，原来默认显示主动产品数据，客户升级后发现主动产品数据无法显示。分析原因是新增一个参数用于控制投顾产品展示，由于控制条件逻辑写错，导致只能展示投顾产品，原来默认展示的主动产品数据无法展示。测试收到的需求是增加投顾产品展示，于是只测投顾产品，而对默认的主动产品数据未做测试覆盖。

如果你是客户，碰到上述这种缺陷，大概也要问一句：“你们到底有没有测试？”

开发为什么会把原功能改坏呢？

没有谁希望把原功能改坏，那到底是什么呢？主要原因有如下三个

1. 代码耦合度高，模块间依赖关系不清晰

初期设计缺陷：急于实现功能，未分层与模块化，违背设计原则，导致职责混杂。

迭代过程失控：面对紧急需求，开发人员为快速上线，采用 “打补丁” 方式修改代码，导致技术债积累（临时方案常态化），模块间直接耦合（如共享变量 / 数据库），未通过抽象解耦。

技术认知不足：滥用全局工具（如 Spring 自动注入）、未用中间层解耦，工具便利性掩盖依赖复杂性。

由于以上原因导致代码耦合高，改一处代码难以识别对其他代码的影响，所以非常容易出现修改A功能改坏B功能的情况。

2. 对系统整体逻辑理解不充分

文档缺失或断层：缺乏架构图 / 时序图，且文档未随代码更新，导致理解滞后。

分工过细：开发人员仅熟悉局部模块，不了解上下游逻辑及联动影响。

人员变动：系统迭代多次后，原有逻辑因人员变动出现 “知识断层”。

由于以上原因，开发不了解系统整体逻辑，只了解自己修改的这一部分内容，修改时考虑不全。

3. 自测不全面

时间压力：已到计划提测时间，只能压缩自测时间，仅验证核心功能，忽略边界条件和异常场景。

惯性思维：按 “预期路径” 测试，对自身代码逻辑盲点（如隐藏分支、依赖变更）缺乏警惕。

工具 / 环境限制：缺少自动化测试工具，或测试环境与生产差异大（如数据量、第三方服务模拟不足）。

对新开发的功能可能都自测不全，更不用说可能有影响的功能了。

测试如何防范此问题漏测呢？

1、靠人

1.1开发评估影响范围

开发根据自己代码修改情况评估可能影响范围， 测试根据影响范围做针对性测试。基于开发把原功能改坏的三个原因，要求他们把修改影响范围评估准确，有点强人所难。所以绝大部分开发评估就两个结果,要么很多内容没评估到，要么告诉你都回归测一下。

1.2 测试自己评估

那么开发不行，咱们测试自己上！测试根据自己以往经验和专业知识，识别出可能会影响的功能，执行测试。要做到这点对测试人员要求比较高，需要非常熟悉被测系统，同时具备非常高的测试专业能力。当前人员高速流动，每天有完不成的测试任务，要求他们把开发修改可能影响的范围评估出来，简直是纸糊的墙壁——不可靠！

2、靠工程

2.1回归测试兜底

回归测试做得足够充分，可以确保原有功能的正确性。随着产品的不断迭代，产品的功能越来越多，已有的测试用例会远远多于本次新增用例。项目开展过程中绝大部分精力要放到新功能测试上，回归测试只能抽样，肯定无法覆盖所有原有功能，当改错的功能不在回归测试范围内时就会漏测。

有人会想到自动化测试。不错，自动化测试可以在较短的时间内执行大量的回归测试用例，在相同时间内，回归测试的覆盖范围远远高于手工测试。但由于自动化测试也做不到穷尽所有场景，UI 自动化维护成本高，极端异常场景（如断网恢复）验证投入远超收益等原因，自动化测试也无法做到100%全覆盖。

所以回归测试也无法确保未识别到的修改功能得到充分测试。

2.2精准测试

精准测试是对修改的代码进行分析，自动识别出影响到的功能模块，并准确推荐回归测试用例，对影响到的功能进行测试。但是也存在以下原因，导致无法准确识别到可能有影响的功能。

动态依赖难捕捉：反射 / 配置等动态关联、跨服务调用链未全解析，导致影响路径遗漏。

数据与业务隐性关联：未分析数据流转及业务状态机联动，功能间隐性逻辑未识别。

工具分析维度单一：仅依赖代码变更或覆盖率，缺乏业务场景映射与全链路追踪。

3 测一步之遥的功能

以上列的方法虽然无法避免原有功能绝对不出问题，但只要做到位，可以拦住绝大部分缺陷。但是靠人对人要求很高；靠工程实现难度大，短时间内无法做到，我们需要找到成本更低，效果更好的方法。这时请记住一个词“一步之遥”，离得越近越容易受影响，我们测试与变动功能紧密相关的功能。

排插有两个挨着的充电器，分别给手机和耳机充电。当你拔掉手机充电器时，需要查看一下耳机充电器是否被碰到松动了，以免耳机一整天都没充上电，这就是测试与变动功能紧密相关的功能。

以下是一些测试中的实例。

交易系统的委托下单页面增加新的按钮，委托下达功能需要验证。

证券交易修改债券的买卖单位，此时我们需要验证股票买卖单位是否有影响。

交易系统的委托汇总报表页面，原来通过交易账户为条件的汇总查询，新增按证券代码汇总，原来的交易账号汇总需要验证。

查询页面修改了查询条件，原来不填任何内容是查全部，新增“全部”的选值，依然要支持不填任何内容查全部。

交易流水查询页面新增了一种交易类型，原有的交易类型也需要能正常展示。

总结

没有可以发现所有改坏原功能缺陷的银弹，我们要训练自己测试的专业意识，识别风险最高的场景，去找出里面可能的缺陷。“开发经常改坏原功能改”，把这个理念刻到骨子里，比掌握各种识别修改点的方法更重要。