测试 Web 应用的后端是开发流程和任何持续监控的关键部分。另请参阅前端的测试。
测试驱动型开发
在测试驱动型开发 (TDD) 中，应用要求会在全面实现之前转换为测试用例。在开发过程中，这些测试会先编写，随着应用的构建而依次实现。明确的要求（即测试用例）可确保最终代码结构合理、满足所有要求且正确无误，这在开发的早期阶段尤为重要。
持续集成和自动化测试
持续集成 (CI) 测试会针对任何代码更改自动运行测试，例如在代码审核期间或将代码合并到代码库时。自动化测试可降低开发过程中出现损坏或回归问题的风险，从而提高所提交代码的整体质量和置信度。建议您为自己的环境设置自动化测试系统，以确保应用的运行状况良好。使用由您的架构、平台和语言支持并无缝集成到开发流水线中的系统；例如，使用适用于 CI 工作流的 GitHub Actions 或在云端内置的自定义 CI 流水线（针对您的配置进行自定义）。
详细了解自动化测试背后的原则以及如何改进测试。详细了解持续集成测试以及实现、设置和衡量成功的最佳实践。
接下来，请考虑使用自动持续交付 (CD) 流水线来自动部署应用的更改和更新。
单元测试
单元测试是指单独测试较小的独立代码部分。针对后端语言或框架使用推荐的单元测试框架。例如，对于基于 Java 的单体式应用，请使用 JUnit；对于基于 JavaScript 的无服务器应用（包括 Dart 或 TypeScript），请使用针对 JavaScript 测试构建的框架（例如 Jest）。
大多数现代后端框架都有专用测试资源。可以考虑将这些功能集成到 CI 流水线中，以自动执行测试。确保单元测试提供良好的应用代码覆盖率。大多数测试框架都提供了用于分析和报告测试覆盖率的功能，并允许集成到构建流水线中。
集成测试
集成测试是指一起测试较大的模块或应用的某些部分。与单元测试（侧重于代码的各个部分）相比，集成测试侧重于集成架构的各个部分。这可能还包括涵盖应用中多个步骤和模块的端到端流程。
集成测试可以涵盖应用中可能需要与外部服务（如数据存储、文件系统或付款）进行交互的不同模块。考虑构建应用，通过依赖项注入或后端框架提供的类似功能来支持这些服务的抽象。
行为和功能测试
如果将后端（或各个模块/组件）视为一个不透明的框，功能测试则侧重于系统的输入和输出。虽然行为测试在前端可能较为常见，但它在确认后端系统的端到端完整性方面也起着至关重要的作用。这些类型的测试可以确认系统是否能够按预期对不同的输入做出反应和行为。
回归测试
回归测试是指确认应用是否仍按预期运行的测试。对于任何新更改，系统会重新运行之前成功完成的测试，以确保这些更改不会再次引入以前的任何问题。当应用中的 bug 得到修复时，应添加单元测试或集成测试，以确保 bug 不会重复出现。回归测试应集成到常规测试和构建流水线中。
冒烟测试
冒烟测试又称构建验证测试，侧重于验证后端应用最关键的功能。冒烟测试不局限于集成测试（将某些功能和外部依赖项抽象化），也涵盖应用的关键用例。在将应用提升到预演环境之前，冒烟测试可以作为额外的验证层，以确保行为准确无误。冒烟测试可能包括自动化单元测试或由 QA 团队进行的手动功能测试。
生产环境和预演环境
预演环境是生产环境的副本，已进行沙盒化以方便测试。专用部署可以降低生产环境出现问题的风险并更轻松地执行质量保证。通过预演环境，您可以测试接近实时生产环境的系统。
受费用或后端架构复杂性等因素的影响，拥有生产环境的一对一副本可能不可行。请考虑后端的哪些部分最关键，并针对预演环境优化这些部分。
针对生产环境中使用的数据进行测试对于测试应用使用真实数据的行为方式具有很大的好处。请务必考虑此类预演环境对隐私的影响和数据存储需求，并仔细设计后端系统使用的数据。您应严格控制对此类环境的访问，尤其是在使用生产数据时。
请考虑系统的规模以及站立环境是否适合您的应用。可以通过持续交付系统自动部署的滚动式预演环境也提供了每天或每周构建测试的更多机会，并在发布之前对其进行额外的审查。
另一种方法是更加依赖持续集成测试和自动化系统，而不是完全部署的预演环境。请考虑团队的工作流、系统运行状况、代码覆盖率和技术要求。