分层测试（五）：端到端测试
分层测试系列文章
https://www.cnblogs.com/yuxiuyan/tag/分层测试/
1. 什么是端到端测试
端到端测试（End-To-End Testing, 简称E2E测试）是一种从头到尾测试整个软件产品以确保应用程序流程按预期运行的技术。它定义了产品的系统依赖性，并确保所有集成部分按预期协同工作。
端到端测试的主要目的是通过模拟真实用户场景并验证被测系统及其组件的集成和数据完整性，主要从最终用户的体验进行测试。
2. 端到端测试的模型
在我们当前的业务实践中，端到端测试由测试同学主导编写，用例代码和业务模块独立仓库管理。
下面按照用户使用银行卡申购指数基金为例，说明端到端测试的依赖关系：
可以看到，端到端测试的用例模块是跟业务模块独立存在的，并且逻辑也比集成测试用例和接口测试都要复杂，通过模拟真实用户行为、打通系统全周期的测试方式，来验证系统的全链路流程。
3. 端到端测试的优点
- 扩大测试覆盖范围
- 确保应用程序的正确性
- 缩短发布时间
- 降低成本
- 检测Bug
- 通过添加比其他测试方法（如单元和功能测试）更详细的测试案例，帮助团队扩大他们的测试范围。
- 通过运行基于终端用户行为的测试用例，确保应用程序的正确执行。
- 帮助发布团队缩短上市时间，允许他们自动化关键用户路径。
- 通过减少测试软件的时间，降低构建和维护软件的总体成本。
4. 端到端测试的挑战
端到端测试也不是万能的，任何收益必然伴随着成本。端到端测试的挑战如下：
4.1 编写耗时长
端到端测试需要对产品服务流程有完整的了解才能编写测试用例，因此编写的耗时很长。如果你的产品属于大型产品，那用户在产品中就有很多的浏览途径。我们不能针对每个路径进行测试。
所以，通常做法是更频繁地使用单元测试、接口测试，只对最高优先级的用户工作流使用端到端测试。
4.2 测试用例设计难度大
因为端到端测试是模拟用户的真实行为，因为在设计这些测试用例时就需要考虑多许多因素。
比如，一个在多浏览器运行的web程序，每个浏览器都有不同的规范。这意味着我们需要针对不同浏览器编写测试。时间成本很高。
在开发过程中，不能依赖端到端测试来快速寻找代码反馈，而是应该使用单元测试和接口测试。
4.3 容易终端且难以维护
端到端测试因为要走完完整流程，流程长，涉及系统多，非常容易中断，用例的前置依赖也非常多，这些都强依赖一个稳定的服务测试环境。整体维护成本非常高。
4.4 站在用户角度
用户不是在体验功能，而是通过产品解决他们的某些问题。所以端到端测试应该侧重于如果有效有效地解决用户问题。
并不是所有的开发团队都详细了解用户意图的。所以在开发期间就必须尽快部署，快速收集用户反馈。
5. 端到端测试的最佳实践
要进行端到端测试，遵循以下概述的做法至关重要，以确保测试顺利进行和成本可控。
5.1 优先考虑最终用途
- 模拟用户：创建测试用例时，像用户一样进行测试。了解第一次使用该应用程序的人的心态。
- 易用性：是否容易找到所有选项？特征有标注吗？用户能否通过两步或三步得到他们想要的东西？
- 文档先行：使用有助于阐明用户观点的验收测试文档和用户故事，相应地设计测试用例。
- 考虑投入产出：将 E2E 测试重点放在失败会导致最大问题的应用程序功能上。从这些特性开始，设计更精细的测试用例来验证它们。
5.2 避免异常测试
E2E 测试最适合用于测试常见的用户场景。对于特殊的用户场景，使用单元测试或接口测试。
5.3 维护整体用例的代码结构
- 由于 E2E 测试涵盖整个应用程序，因此测试用例必然很复杂。
- 每个系统组件都必须进行测试，这增加了故障点以及调试每个异常的难度。
- 结构和组织在 E2E 测试中至关重要。
- 通过单元测试和接口测试等底层测试消除简单的错误。
5.4 优化环境和清理机制
- 确保测试环境随时可以开始测试。
- 测试完成后，务必清理测试数据，以便环境恢复到原始状态，从而准备好再次进行测试。
鉴于端到端测试的重要性，需要从项目一开始就对其进行规划。端到端测试最好手动进行，因为它允许测试人员设身处地为用户着想。如果需要自动化测试，最好将其限制在只需要重复操作的低风险功能上。
