测试内容驱动型 Web 应用后端
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
测试 Web 应用的后端是开发流程和任何持续监控的关键部分。另请参阅前端的测试。
测试驱动型开发
在测试驱动型开发 (TDD) 中,应用要求会在全面实现之前转换为测试用例。在开发过程中,这些测试会先编写,随着应用的构建而依次实现。明确的要求(即测试用例)可确保最终代码结构合理、满足所有要求且正确无误,这在开发的早期阶段尤为重要。
持续集成和自动化测试
持续集成 (CI) 测试会针对任何代码更改自动运行测试,例如在代码审核期间或将代码合并到代码库时。自动化测试可降低开发过程中出现损坏或回归问题的风险,从而提高所提交代码的整体质量和置信度。建议您为自己的环境设置自动化测试系统,以确保应用的运行状况良好。使用由您的架构、平台和语言支持并无缝集成到开发流水线中的系统;例如,使用适用于 CI 工作流的 GitHub Actions 或在云端内置的自定义 CI 流水线(针对您的配置进行自定义)。
详细了解自动化测试背后的原则以及如何改进测试。详细了解持续集成测试以及实现、设置和衡量成功的最佳实践。
接下来,请考虑使用自动持续交付 (CD) 流水线来自动部署应用的更改和更新。
单元测试
单元测试是指单独测试较小的独立代码部分。针对后端语言或框架使用推荐的单元测试框架。例如,对于基于 Java 的单体式应用,请使用 JUnit;对于基于 JavaScript 的无服务器应用(包括 Dart 或 TypeScript),请使用针对 JavaScript 测试构建的框架(例如 Jest)。
大多数现代后端框架都有专用测试资源。可以考虑将这些功能集成到 CI 流水线中,以自动执行测试。确保单元测试提供良好的应用代码覆盖率。大多数测试框架都提供了用于分析和报告测试覆盖率的功能,并允许集成到构建流水线中。
集成测试
集成测试是指一起测试较大的模块或应用的某些部分。与单元测试(侧重于代码的各个部分)相比,集成测试侧重于集成架构的各个部分。这可能还包括涵盖应用中多个步骤和模块的端到端流程。
集成测试可以涵盖应用中可能需要与外部服务(如数据存储、文件系统或付款)进行交互的不同模块。考虑构建应用,通过依赖项注入或后端框架提供的类似功能来支持这些服务的抽象。
行为和功能测试
如果将后端(或各个模块/组件)视为一个不透明的框,功能测试则侧重于系统的输入和输出。虽然行为测试在前端可能较为常见,但它在确认后端系统的端到端完整性方面也起着至关重要的作用。这些类型的测试可以确认系统是否能够按预期对不同的输入做出反应和行为。
回归测试
回归测试是指确认应用是否仍按预期运行的测试。对于任何新更改,系统会重新运行之前成功完成的测试,以确保这些更改不会再次引入以前的任何问题。当应用中的 bug 得到修复时,应添加单元测试或集成测试,以确保 bug 不会重复出现。回归测试应集成到常规测试和构建流水线中。
冒烟测试
冒烟测试又称构建验证测试,侧重于验证后端应用最关键的功能。冒烟测试不局限于集成测试(将某些功能和外部依赖项抽象化),也涵盖应用的关键用例。在将应用提升到预演环境之前,冒烟测试可以作为额外的验证层,以确保行为准确无误。冒烟测试可能包括自动化单元测试或由 QA 团队进行的手动功能测试。
生产环境和预演环境
预演环境是生产环境的副本,已进行沙盒化以方便测试。专用部署可以降低生产环境出现问题的风险并更轻松地执行质量保证。通过预演环境,您可以测试接近实时生产环境的系统。
受费用或后端架构复杂性等因素的影响,拥有生产环境的一对一副本可能不可行。请考虑后端的哪些部分最关键,并针对预演环境优化这些部分。
针对生产环境中使用的数据进行测试对于测试应用使用真实数据的行为方式具有很大的好处。请务必考虑此类预演环境对隐私的影响和数据存储需求,并仔细设计后端系统使用的数据。您应严格控制对此类环境的访问,尤其是在使用生产数据时。
请考虑系统的规模以及站立环境是否适合您的应用。可以通过持续交付系统自动部署的滚动式预演环境也提供了每天或每周构建测试的更多机会,并在发布之前对其进行额外的审查。
另一种方法是更加依赖持续集成测试和自动化系统,而不是完全部署的预演环境。请考虑团队的工作流、系统运行状况、代码覆盖率和技术要求。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-25。
[null,null,["最后更新时间 (UTC):2025-07-25。"],[[["\u003cp\u003eBackend testing, including unit, integration, and functional testing, is crucial for ensuring web application quality and stability.\u003c/p\u003e\n"],["\u003cp\u003eTest-driven development (TDD) involves writing tests before implementation, leading to well-structured and reliable code.\u003c/p\u003e\n"],["\u003cp\u003eContinuous integration (CI) automates testing for code changes, reducing risks and improving code quality.\u003c/p\u003e\n"],["\u003cp\u003eStaging environments provide a safe space for testing against production-like data before deployment.\u003c/p\u003e\n"],["\u003cp\u003eConsider various testing strategies, such as regression and smoke testing, to address specific needs and ensure comprehensive coverage.\u003c/p\u003e\n"]]],["Backend testing involves various methods, including Test-Driven Development (TDD), where tests are created before code. Continuous integration (CI) automates tests on code changes, enhancing quality. Unit testing checks isolated code parts, while integration testing assesses larger modules working together. Functional and behavioral testing check system input/output and end-to-end behavior. Regression testing ensures fixes persist, and smoke testing verifies core functionalities before staging. Staging environments mimic production for realistic testing.\n"],null,["# Testing content-driven web app backends\n\nTesting the backend of a web application is a critical part of the development\nprocess and any ongoing monitoring. Also, see testing for the\n[frontend](/solutions/content-driven/frontend/testing).\n\nTest-driven development\n-----------------------\n\nIn [Test-Driven\nDevelopment](https://en.wikipedia.org/wiki/Test-driven_development)\n(TDD), application requirements are translated into test cases before an\napplication is fully implemented. During development, these tests are written\nfirst and successively implemented as the application is built. Clear\nrequirements (ie. test cases) ensure that the final code is well structured,\nmeets all requirements, and is correct, which is especially important during the\nearly stages of development.\n\nContinuous Integration and Automated Testing\n--------------------------------------------\n\nContinuous integration (CI) testing automatically runs tests against any code\nchanges, such as during code reviews or when code has been merged into your code\nrepository. Automated tests improve the overall quality and confidence in the\nsubmitted code by reducing the risks of breakages or regressions during\ndevelopment. It is recommended to set up an automated testing system for your\nenvironment to ensure the health of your application. Use a system supported by\nyour architecture, platform, and language and seamlessly integrated into your\ndevelopment pipeline; for example, use [GitHub Actions for a CI\nworkflow](https://docs.github.com/en/actions/automating-builds-and-tests/about-continuous-integration)\nor a [custom CI pipeline built-in the\ncloud](https://cloud.google.com/solutions/continuous-integration), customized\nfor your configuration.\n\nLearn more [about the principles behind automated\ntesting](https://dora.dev/devops-capabilities/technical/test-automation/)\nand how to improve your tests. Learn more [about continuous integration\ntesting](https://dora.dev/devops-capabilities/technical/continuous-integration/)\nand the best practices for implementing, setting up, and measuring success.\n\nAs the next step, consider an [automated continuous delivery (CD)\npipeline](/solutions/content-driven/backend/deployment#cd-and-ci) to\nautomatically deploy changes and updates to your application.\n\nUnit testing\n------------\n\n[Unit testing](https://en.wikipedia.org/wiki/Unit_testing) refers\nto testing small, self-contained parts of code in isolation. Use a unit testing\nframework that is recommended and popular for your backend language or\nframework. For example, for a monolithic Java-based application, use JUnit, or\nfor a JavaScript-based serverless application (including Dart or TypeScript),\nuse a framework built for Javascript testing, such as\n[Jest](https://jestjs.io/).\n\nMost modern backend frameworks have dedicated resources for testing. Consider\nintegrating these features into your CI pipeline to automate testing. Ensure\nthat your unit tests provide good [code\ncoverage](https://en.wikipedia.org/wiki/Code_coverage) of your\napplication. Most testing frameworks provide features to analyze and report on\nyour test coverage and allow for integration into your build pipeline.\n\nIntegration testing\n-------------------\n\n[Integration\ntesting](https://en.wikipedia.org/wiki/Integration_testing) refers\nto testing larger modules or parts of your application together. Compared to\nunit testing (which focuses on individual parts of code), integration testing\nfocuses on the integration of individual parts of your architecture. This may\nalso include end-to-end flows covering multiple steps and modules across the\napplication.\n\nIntegration tests may cover different modules of your application that may\nrequire interaction with external services, such as data storage, filesystems,\nor payments. Consider structuring your application to support abstractions for\nthese services through [dependency\ninjection](https://en.wikipedia.org/wiki/Dependency_injection) or\nsimilar features provided by your backend framework.\n\nBehavior and functional testing\n-------------------------------\n\nApproaching the backend (or individual modules or components) as an opaque box,\n[functional\ntesting](https://en.wikipedia.org/wiki/Functional_testing) focuses\non the input and output of the system. While behavioral testing may be more\ncommon for the frontend, it also plays a vital role in confirming the end-to-end\nintegrity of a backend system. These types of tests confirm that the system\nreacts and behaves as expected to different inputs.\n\nRegression testing\n------------------\n\n[Regression\ntesting](https://en.wikipedia.org/wiki/Regression_testing) refers\nto tests that confirm that the application still behaves as expected. Tests\nsuccessfully completed previously are re-run for any new changes to ensure that\nthe changes have not reintroduced any previous issues. As bugs get fixed in an\napplication, unit or integration tests should be added to ensure the bug doesn't\nrecur. Regression tests should be integrated into the usual testing and build\npipeline.\n\nSmoke testing\n-------------\n\n[Smoke\ntesting](https://en.wikipedia.org/wiki/Smoke_testing_(software)),\nalso called build verification testing, focuses on verifying the most critical\nfunctions of your backend application. Extending beyond integration testing,\nwhich abstracts some features and external dependencies, smoke testing covers\nthe critical use cases for your application. Smoke testing can serve as an\nadditional layer of verification before an application is promoted to the\nstaging environment to ensure accurate behavior. Smoke tests may consist of\nautomated unit tests or manual functional tests conducted by a QA team.\n\nProduction and staging environments\n-----------------------------------\n\nA staging environment is a copy of your production environment, sandboxed to\nfacilitate testing. A dedicated deployment reduces the risk of issues with the\nproduction environment and makes it easier to conduct quality assurance. The\nstaging environment lets you test a system close to the live production\nenvironment.\n\nHaving a 1-for-1 copy of the production environment may not be feasible due to\nfactors such as cost or the complexity of the backend architecture. Consider\nwhat parts of the backend are the most critical and optimize those for a staging\nenvironment.\n\nTesting against data used in production offers a great benefit to test how the\napplication behaves with real-world data. Be sure to consider the privacy\nimplications and data storage needs for such a staging environment, and\ncarefully design the data used by your backend system. Access to such an\nenvironment should be tightly controlled, especially if production data is used.\n\nConsider the scale of your system and whether a standing environment is\nappropriate for your application. Rolling staging environments that can be\nautomatically deployed through a [continuous delivery\nsystem](/solutions/content-driven/backend/deployment#cd-and-ci) also offer\nadditional opportunities to test daily or weekly builds and give them additional\nscrutiny before release.\n\nAnother approach is to rely more heavily on continuous integration tests and\nautomated systems rather than a fully deployed staging environment. Consider\nyour team's workflow, system health, code coverage, and technical requirements."]]