浅谈为什么测试晚会导致失败，如何避免这种情况，以及其他常见的软件测试反面实践。
测试介入太晚
最常见的软件测试错误做法之一是测试介入过晚。在传统的质量保证模型中，软件通常在发布周期的最后阶段由开发人员移交给测试人员，导致QA成为“守门人”或“瓶颈”，这是很不理想的。此外，发现问题越晚，修复的成本就越高。通过将测试“左移”，可以更早地发现问题，降低问题修复成本。
当我谈到“左移”时，这意味着将流程的一些内容向早期移动。以设计→代码→测试→交付→维护的典型生命周期过程为例，“左移”意味着将测试过程向左移动。理想情况下，测试不应孤立地进行，而应作为每个步骤的组成部分。
软件测试后置的陷阱
测试本质上是对开发人员的反馈循环，用来确认他们的代码是否按预期运行。如果没有达到预期，这意味着软件存在缺陷。从这个角度看，测试太晚就意味着反馈周期过长。
为什么测试会启动得太晚？ 这通常是多种软件测试反面实践和开发习惯的结果，例如过度依赖手动测试、开发与测试/质量保证团队的隔离，以及缺乏对整个开发过程质量的责任意识。
后果
- 修复后期发现问题的成本更高。
- 由于修复成本较高，可能并不会修复所有发现的问题，从而降低了产品的整体质量。
- 错过截止日期，因为重大缺陷可能会导致软件发布延迟。
- 团队面临压力，甚至可能出现倦怠。
- 对客户体验、满意度和信任的影响：持续存在的质量问题会损害品牌声誉，削弱客户的信任。
替代方案和最佳实践
当我们将测试视为一个反馈循环时，应该让这个循环尽可能短且有意义。测试左移（即提前进行测试）能够实现这一点，通过左移测试，测试在软件开发生命周期中尽早开始，从而缩短反馈周期。有许多方法可以提前引入测试，例如：
- 需求测试
- 设计评审
- 代码评审
- QA发布
- 测试驱动开发（TDD）
- 早期测试计划
- 单元测试
- 结对测试
- 持续集成和持续部署（CI/CD）
- 自动化测试
- 风险分析和基于风险的测试
- 增加测试人员与开发人员之间的沟通与协作
其他常见的软件测试反面实践
除了上述测试介入晚的质量陷阱，再来看看其他一些测试方面的反面实践。
过度依赖手动测试
首先必须强调，手动测试是一种非常有效的工具，对于构建稳健的质量方案至关重要。然而，由于手动测试可能耗时且需要大量人力资源，在使用时需要谨慎考虑。
通常，手动测试是在代码“完成”后由一个独立的团队进行的。无论是手动测试还是自动化测试，等待代码“完成”并“扔到墙那边”，都是导致测试发生太晚的主要原因之一。
纠正措施：
- 查看你的代码/测试覆盖率指标，并将其与Pyramid测试模型（大量的单元测试，少量的集成测试，只进行必要的系统测试，以最小的努力尽早发现问题）和Trophy测试模型（将集成测试置于最重要的地位）进行比较。哪些地方可以添加更多的非手动测试？在软件开发生命周期的早期，哪些地方可以增加更多的测试？
忽略非功能要求
忽视产品的非功能方面质量，如可用性、安全性和性能，会导致软件可能满足要求，但并不能满足用户期望。
纠正措施：
- 在产品需求文档中明确包含非功能要求。
- 将非功能测试添加到测试计划中。
低质量测试数据和测试数据管理
低质量的测试数据和测试数据管理可能会导致发布出有缺陷的软件，从而影响用户体验和满意度。低质量的测试数据可能会导致不正确的测试结果，进而问题被遗漏或出现原本不存在的问题。此外，在管理方面，测试数据处理不当可能会暴露敏感或机密信息。在测试环境中使用生产数据可能会无意中造成安全漏洞。
纠正措施：
- 创建、维护并保护能够准确代表真实场景的测试数据。有许多工具可供选择，帮助进行测试数据管理。
缺乏测试环境和配置管理
缺乏适当的测试环境和或配置管理可能会导致“在我的机器上能用”综合症，通常会进一步造成问题被遗漏，因为预生产环境与生产环境不匹配。
纠正措施：
- docker镜像、Puppet、Chef或Ansible等工具可以确保预生产环境与生产环境相匹配。
拓展讨论
- 在开发过程中，您发现哪些策略在实施左移测试方面是有效的？
- 您发现缩短软件开发和测试中反馈循环的最有效方法是什么？
- 您使用了哪些方法来防止测试成为发布周期的瓶颈？
