根据 JetBrains 博客上由 Kerry Beetge 撰写的一篇文章，仅在发布前测试应用程序已不足以保证现代软件的质量。核心观点是将质量检查分布在软件开发生命周期的各个阶段，使缺陷能够更接近其引入的时刻被发现，而不是在更多变更和复杂性累积之后才被发现。
文章将这一转变与对人工智能生成代码的日益依赖联系起来；文章援引 Stack Overflow 2025 年调查指出，84% 的开发者正在使用或计划在开发过程中使用人工智能工具。JetBrains 认为，这些工具生成的代码量增加，使得可重复且可扩展的审查更加重要，同时由于自动生成结果可能包含错误，人工验证仍然必不可少。
从发布前关卡到持续质量保证
文章区分了软件质量保证（SQA）与传统质量控制（QC）：软件质量保证在整个开发周期内关注是否符合运行、可靠性、安全和标准要求，而传统质量控制通常聚焦于最终产品，以被动方式处理缺陷。持续性方法能够在编写或集成代码时发现问题，此时修复成本更低，也更贴近变更的原始上下文。
文章指出，在现代开发环境中，发布周期已从数月缩短至数天，而 CI/CD 流水线能够在有限人工干预的情况下将代码从提交推进到生产环境。因此，不能依赖单一工具；每一层测试都会发现不同类型的问题。
这些工具在实践中覆盖哪些方面？
- 静态分析：在不运行代码的情况下检查代码，以发现缺陷、漏洞和违反编码标准的情况，Qodana 就是其中一个例子。
- 单元测试：验证函数和组件单独运行时是否正常，示例包括 JUnit、Jest、PyTest 和 NUnit。
- 集成测试：检查服务、API 和数据流之间的交互，相关工具包括 Postman 和 Soap UI。
- 功能测试和界面测试：使用 Playwright、Cypress 和 Selenium 等工具，通过浏览器模拟用户路径。
- 性能测试：测量负载下的行为，帮助发现瓶颈、内存泄漏和查询缓慢等问题，可使用 JMeter、LoadRunner 和 k6 等工具。
- 安全测试：结合 SAST、SCA、依赖项扫描、DAST，以及对被错误纳入代码的机密信息或 API 密钥进行发现。
如何选择工具并将其融入工作流程？
文章建议根据工具与 CI/CD 的集成能力、对所使用语言和框架的支持、自动化重复性工作的能力、随代码和团队增长而扩展的能力、提供可执行报告的能力，以及工具自身的安全实践来评估工具。
在实施层面，文章建议将检查前移到代码编写阶段，实现重复测试自动化，在每次提交或构建时运行测试，并通过代码复杂度、重复率和测试覆盖率等指标监控技术债务。文章还强调，应将安全检查纳入常规质量保证流程，而不是推迟到发布前的单独审查。
certi.news 的解读
文章提出的真正变化并不是增加一项新的测试，而是在开发周期内重新分配质量责任。这种方法有利于采用密集发布节奏或依赖分布式架构和外部依赖的团队，但它并不会取代人工测试或工程判断；自动化，尤其是依赖人工智能的自动化，可以加快问题发现，却无法单独保证覆盖范围的完整性或结果的正确性。此外，来源提供的是一般性指导和工具示例，但没有建立用于权衡这些工具的量化框架，也没有证明独立的性能比较结果。