在软件测试中，我们常常会面临一个问题：很多工作确实是我们可以去做到的，似乎做这些事也理所当然，但很多时候，这些事情往往收效甚微。从过度自动化到频繁运行不必要的回归测试，不一而足。

随着技术发展，测试人员手中拥有的工具让我们可以完成更多事情，但并不意味每个选择都是明智的。有些工作，盲目地去做，往往会影响真正重要的产出、效率、可维护性等要求。

本文列举了在测试工作中八个“能做，但不应做”的工作。有时候，退一步可能是更聪明的选择。

1. 自动化所有测试

可以做到： 现代的测试自动化工具让我们几乎可以自动化任何测试用例，从用户界面的每一次点击到API的每一次调用，技术上来说，都可以通过自动化来进行驱动。

但不应该： 仅仅因为可以实现自动化测试，却并不意味它是最佳选择。比如：某个产品的用户界面非常动态，设计师每周都会进行调整。如果你选择将所有测试都自动化，每次UI改动后，相关的自动化测试都可能面临失效的风险。

这种情况下，手动测试可能更有效。

2. 自动化脚本中使用过于复杂的定位器

可以做到：Selenium, Playwright 等自动化工具中，借助XPath和CSS选择器，我们能够精确定位到页面中最深层的元素。

但不应该：过于复杂的定位器往往会让测试变得脆弱。比如：使用复杂的XPath去定位一个菜单，但当开发团队重构HTML结构后，往往导致多个测试失败，团队不得不花费大量时间修复。

这时，其他方法可能对自动化用例的稳定性更为有效，比如和开发团队约定增加元素的 test-id 属性。

3. 每次提交都运行完整的回归测试

可以做到：在现代CI/CD管道中，每次代码提交都可以轻松触发完整的回归测试。

但不应该：但实际上，这种做法往往是过度的。想象一下，一个小的代码修复导致整个回归测试运行，而这个过程可能需要几个小时，甚至更长时间。

如果在没有将自动化覆盖率提升到一定程度的团队，这种提交后进行完整回归更是噩梦。更好的做法，其实还是及时掌握变更内容，并根据变更和影响实现精准测试。

 4. 在API测试中过度模拟

可以做到：模拟API响应可以大幅提高测试速度，消除对外部服务的依赖。

但不应该：然而，过度模拟会让我们失去与真实环境的连接。大量的Mock API 确实可以提升调试和验证效率，但却背离了真正的测试需要。真实场景下的测试是不可或缺的，就像我们不能预知所有的异常一样

5. 为琐碎问题撰写极其详细的缺陷报告

可以做到：借助辅助测试工具，我们可以捕捉到类似很多细小的UI层、提示信息等缺陷，也可以按照用例规范编写极为详尽的缺陷报告。

但不应该：并不是每个小问题都值得进行事无巨细地全面报告。发现Bug的目的最终是为了解决bug而不是bug本身，况且Bug的价值也有高下主次之分。

 6.在没有人工监督的情况下使用AI生成测试用例

可以做到： AI的发展，其实已经可以做到，利用AI工具，基于需求文档快速生成大量测试用例，覆盖大量场景。

但不应该： 然而，现阶段的AI，特别是针对特定的业务，缺乏人类的上下文理解以及各种内部沟通获取的综合信息，可能导致用例冗余或遗漏关键测试用例。

7. 在测试中过多地使用断言

可以做到：结合自动化工具和AI，我们确实可以做到在一个测试中验证大量字段、属性和UI元素。

但不应该：然而，过多的断言只会让测试变得巨大且复杂，难以调试。当部分断言失败，往往需要耗费大量的精力去排查

8. 在每个可能的设备和浏览器组合上执行测试

可以做到： 针对兼容性测试，现代的跨浏览器和跨设备测试工具让我们能够在许多操作系统和设备上运行测试。

但不应该： 测试所有可能的组合既不必要也不切实际。重点是覆盖用户实际使用的关键场景。而且开发技术的发展如响应式编程等，也大大减少了兼容性问题的风险。

在软件测试中，“有能力做” 却并不总意味着是最佳选择。我们需要在技术能力和实际可行性之间找到平衡。通过避免这些“因为可以做到”的陷阱，去建立一个精简、高效且真正有价值的测试集，对产品的质量保障更有意义。

更多软件测试相关推荐：

软件测试更多干货文章

软件测试就业培训

  文章来源：网络  版权归原作者所有

上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8103)，我们将立即处理