写这篇文章的灵感，来自昨晚饭后在马路上散步时的一些想法，要聊的内容如标题所述：端到端测试。
我在前面的文章中，写过一些质量保障体系建设的文章，也写过对测试过程中一些执行环节的理解。从我的角度来看，所谓端到端测试，通俗理解就是从一端到另一端完整串联起来的测试方法。
当然，由于是漫谈，我会尝试通过对几个与端到端测试有关的问题思考，来聊这个话题。
什么是端到端测试？
按照较为标准的定义，端到端(End-to-End，简称E2E)测试，指的是用于验证整个系统从开始到结束的流程是否如预期工作的方法。这种测试方法模拟了用户在实际环境中与应用程序进行交互的过程，以确保各个组件、模块和服务之间的集成和协作是正确的。
端到端的测试目的主要为如下几个部分：
- 验证整个系统的功能是否满足需求。
- 检查系统组件之间的交互是否正确。
- 确保系统在不同环境和设备上的兼容性。
- 发现潜在的性能瓶颈和安全问题。
至于端到端测试的步骤，与常规的测试流程并无太大区别，都是从需求分析开始，到线上交付结束。
当然，端到端测试并非是特别新颖和独特的测试方法，早在16、17年，业内就有了类似的测试思路，如业务流、数据流。这种测试思路的核心理念在于：除了按照测试用例设计执行验证之外，还要关注测试场景的业务上下游，以及不同层级和模块之间的数据传递和处理是否符合预期。
监控领域的链路追踪，其实和端到端测试的思路有异曲同工之妙。通过对请求打上唯一的标识ID，然后通过日志记录该请求的时间、上下文和耗时等信息，提高问题定位和排查的效率。
E2E与传统测试的区别
在大家较为熟知的测试流程中，一般测试执行是从单元测试开始，接着是集成测试，系统测试，回归测试和线上发布验证这几个阶段。而在这几个测试阶段中，测试活动开展都是依据测试用例设计的上下文进行输入输出验证。
这种方法一次验证的范围只能局限于某一个具体的场景，测试完成的标志是本轮的测试用例全部执行通过。但实际上这种传统的方法其实只关注了整个软件系统的部分或单个模块的质量。
换个角度来说，传统的测试方法，最终的交付质量是由一个个小的模块组成的，不可控因素太多。
相比于传统的测试方法，端到端测试的特点在于测试的范围、目标、难度和价值。端到端测试更侧重于验证系统的整体，而传统测试更侧重于模块间的交互。
- 测试范围：端到端测试的范围是整个系统，包括用户的所有操作和系统与外部系统的交互。
- 测试目标：端到端测试的目标是验证整个系统是否满足用户的需求和期望。
- 测试难度：端到端测试的难度更大，需要考虑系统的复杂性和多变性。
- 测试价值：端到端测试的价值更高，能够提高系统的质量和用户满意度。
端到端测试的优势与不足
上面提到了端到端测试的难度相比于传统的测试方法更大，主要体现在业务和系统的复杂性会让端到端测试的实施成本随之水涨船高。重点表现为用例设计和执行，测试数据准备和验证，以及长期的维护成本。
与之类似的案例则是传统的性能测试和生产全链路压测之间的差异，以我之前工作过的某银行为例，当时也是传统压测占大多数。要完成一次完整的压测，需要经历下述多个环节才可以完成：
- 业务研发部门提出压测需求，压测团队和业务方沟通后确认是否执行。
- 业务部门提供压测范围、链路接口、数据并且准备相关的铺底数据和参数化数据。
- 压测团队和运维DBA沟通，准备相关的压测环境，开通防火墙及临时访问权限。
- 压测团队调试脚本，有问题需要业务研发协助定位解决。
- 开展压测，通过nmon、JDK自带工具获得压测数据，然后导出进行图表绘制，进行性能问题初步分析。
- 和业务研发、运维以及DBA沟通，一起排查定位问题。
- 优化发布后，再次验证（这个环节要持续多轮）。
- 压测完成，统计压测结果，手动编写压测报告。
将这个案例中的性能测试更换为功能测试，其实是一样的逻辑。要设计测试用例，就要提前梳理对应的端到端业务流程和数据模型；要执行端到端测试用例，就需要确保该链路的通畅性；同时还要完善端到端的监控覆盖，以及保障测试执行环境的稳定性(这是最大的影响测试结果的因素)。
因此，端到端测试更建议通过自动化测试的方式来执行，借助工具来提高测试效率和准确性。
当然，每个团队面临的问题和处境各不相同，不同的工具有不同的特点和优势，测试团队应根据项目的具体需求和团队的技术栈来选择最合适的工具。
今年以来各种技术大模型开始涌现，借助AI大模型的能力，在业务场景和数据模型梳理以及用例完善方面，也许能获得一定的助力。当然，如何实践还需要自己亲自去尝试，找到适合自己的方法。
端到端测试并不是特别新颖和独特的测试方法，多种测试方法结合，平衡成本和难度，最终才能形成自己团队的测试技术体系。
