端到端 (E2E) 测试 会从头到尾审查应用程序的工作流,以确认整体功能是否正常。端到端 (E2E) 测试的最佳实践包括:仔细定义测试范围、使用真实场景、有效编写测试、跨职能协作以及充分利用自动化的能力。
从许多方面来看,在所有可用的不同类型的软件测试中,E2E 提供了最全面的测试方法。它不仅仅是对“应用程序是否按预期工作?”这一核心问题给出有限的“是”或“否”回答(就像某些“黑盒”形式的测试那样)。
端到端 (E2E) 测试通过描绘应用性能的更丰富细节,为该核心问题提供了更完整、更细致的答案。
然而,所有这些额外的视角都是有代价的。正是使端到端 (E2E) 测试如此全面且有价值的因素,也使其比其他类型的测试更慢、更繁琐。端到端 (E2E) 测试生成测试结果需要更多时间。与此同时,监督该过程的人也需要投入更多的参与和耐心。
这就使得遵循端到端 (E2E) 测试的最佳实践显得尤为重要。通过实施这些最佳实践,您可以帮助缓解端到端 (E2E) 测试中容易导致使用变慢的过高要求。人们的担忧也不仅仅局限于速度。这里概述的最佳实践可以提高 E2E 测试所生成数据的有效性,从而最终使整个测试过程变得更有价值。
在讨论进行 E2E 测试的最佳方法之前,我们首先要查看其主要优点,以确保此类测试最适合您的需求。E2E 具有某些优势,可帮助用户:
确实,并非每种类型的组织都非常适合进行端到端 (E2E) 测试,但这里列出的行业已经证明,它们确实适合。
其中一些行业处理的是当今最重要且受保护的信息。
测试人员需要格外小心地处理患者的敏感数据。E2E 测试帮助医疗机构实现这一目标,确保患者数据的使用安全且完全符合监管要求。
金融科技公司的关键运营组成部分,例如在线账单支付、用户登录程序和电子资金转账,确保此类组织继续转向 E2E 测试。
从 E2E 测试中获益最多的行业之一是电子商务,它可以验证在线营销中使用的整个购买流程。
E2E 测试使测试人员能够评估用户通知、内容共享以及网站入口的用户注册等功能。
基于云的应用程序必须在各种服务上运行,同时保持一致的显示质量和用户交互体验。E2E 测试允许云应用程序在各种服务上运行。
我们可以将 E2E 测试的最佳实践分为七个总体领域,每个领域都包含多个独立步骤的整合。
第一步主要是概念性的,涉及密集的测试规划。请记住,E2E 测试主要关注用户体验,因此从用户体验入手是整个测试流程的合理起点。
设身处地地将自己置于该应用程序的潜在用户角度,从用户的视角进行思考。他们希望获得怎样的用户体验?不同用户对该应用的预期是否可能存在较大差异?哪些是最重要的用户旅程,以及用户选择最频繁的旅程?
提出这些问题可以帮助您了解用户的期望,以及与该应用程序相关的常规功能和工作流程。
首先,指定哪些工作流是最重要的。此步骤包括常用流程,例如登录、结账(针对电子商务应用)以及关键集成。这些流程在确保系统稳定性方面发挥着最大作用,被视为运营完整性的重要环节。
在 E2E 测试的的这一阶段,最好考虑该应用的最坏用户场景。您需要预测系统应用程序故障可能在何处对其用户造成最严重的影响和破坏。测试人员通常使用基于风险的测试来帮助决定可以向应用程序添加哪些新功能,以优化性能并避免潜在问题。
或许“完美”这个词并不准确。真正的完美在此或许难以企及。但您可以打造出尽可能完善的测试用例,这一点至关重要,因为测试用例堪称 E2E 测试的成败关键。测试用例是实现 E2E 测试的工具。因此,正确的设计至关重要。
使用您在第 1 步中了解的用户需求和要求,开始开发测试用例。聪明的测试人员力求全面,尽可能捕捉在应用程序正常使用过程中可能遇到的每一种用户交互。
测试人员制定测试方案,概括不同的使用场景,因为它们涉及所有相关的单个组件,如前端、后端、数据库和应用程序编程接口。如果可能的话,更复杂的工作流应该更加集中,以使测试用例更易于处理和运行。
测试用例的管理同样重要,这一点至关关键,因为您可能需要处理多个测试用例。为了理清所有测试用例,必须对所有测试用例(以及以有序方式管理它们的测试套件)进行细致管理。
这意味着需要确保测试用例保持易于识别,并确认其标题能够清晰明了地传达内容。同样,任何先决条件都必须明确说明。测试用例应概述运行该测试所需的资源以及该测试的预期结果。
这听起来可能有些拗口,但请考虑一下。尽管第 2 步很重要,如果没有一个安全且功能齐全的测试环境来承载这些测试用例,那么这一点就毫无意义。测试环境必须高度模拟应用程序通常使用的生产环境,并且必须非常适合进行测试。
因此,测试环境应包含与 API 测试中使用的类似服务配置、数据库架构和 API 密钥类型。同样,测试环境应具有所有必要的组件,无论是面向硬件、基于软件还是与网络相关的组件。如果它位于生产环境中,那么它也应包含在测试环境中。
现在谈谈在测试用例中使用的数据。测试过程中很容易走到这一步就认为已经涵盖了所有可能的情况。如果您没有使用能够展示稳定性并接近真实使用环境的数据,那么情况可能并非如此。
为了获得高质量的数据,您可能可以重新利用以前的生产数据,其中的敏感数据已被删除。如果无法获取真实数据,也可以使用模拟生成的数据,这些数据应尽量模仿真实数据的特征。
最后,当测试完成后,应使用既定的拆解机制,以便收集和分析数据,并在新的设置措施下重新开始测试。
现在您已经开始努力开发有价值的测试用例,希望能够调用并重复使用它们。
引入自动化,它具备变革性的能力,可管理多个测试用例的日常运行,并可委托给任意数量的编程框架执行。
在回归测试中,测试自动化尤其方便,因为与手动测试相比,自动化可以显著节省时间并提高生产力。Selenium 等 E2E 测试框架可实现网络应用程序自动化,而 Appium 等框架则旨在简化和自动化移动应用程序的测试执行。
还有一些测试自动化工具(如 Katalon)使用低代码技术和人工智能驱动的功能,旨在提供简单的测试和同样轻松的测试维护。
为了扩展组织 E2E 测试的能力,具有前瞻性的公司会尝试将测试自动化集成到持续集成/持续交付 (CI/CD) 管道中。当这些组织将 E2E 测试作为其常规流程的一部分时,其收益包括测试的自动执行、更高效的测试以及对潜在性能问题的早期发现。
考虑到 E2E 测试通常既复杂又耗时,人们可能会希望它只是一个完全独立的过程。但事实并非如此:测试人员只有在 E2E 测试成为一个经常进行的流程时,才能获得最大收益。
测试及其相关指标需要持续监控和审查,以确保它们随着时间的推移仍然具有相关性。情况可能会急剧且突然发生变化,用户行为也同样会受到这些变化的影响。曾经非常有用的测试用例可能会变得不稳定,无法发挥应有的作用。这些测试需要立即关注,以防它们产生不准确的测试结果或增加相关的维护成本。
一个组织所遵循的测试策略需要包含可追踪的流程。这种方法可以让测试人员判断测试用例是否仍然具有相关性和价值,或者是否需要用新的测试用例进行替换。
诚然,E2E 测试能够完成一些其他类型的软件测试无法实现的任务。这些其他选项可以包括评估应用程序所提供的用户体验质量,以及从头到尾评估应用程序的整体性能。
但是,尽管 E2E 测试很有价值,但它不应该成为任何组织的全部测试策略。其他测试也以自己的方式具有价值,您应该运行其他类型的测试。
单元测试和集成测试对于处理许多低重要性错误非常有用。而且由于它们的范围不如 E2E 测试那么大,因此通常可以用更少的资源快速完成。
使用单元测试和集成测试还有另一个原因。如果您正在处理边界情况和异常测试(即观察超出正常操作特征的情况),方法可能会有所不同。在这些情况下,单元测试或集成测试的流程比 E2E 测试更为适合。
我们已经讨论过,将定期 E2E 测试作为常规应用程序维护的一部分是多么重要。E2E 测试的另一个关键方面是,它不应仅由某一名员工独自负责。能够至少间接参与的团队成员越多,对测试流程的整体健康越有利。
因此,您需要培养团队成员之间的协作意识,无论他们是在开发团队、QA 还是其他业务部门工作。这一过程的核心在于支持加强沟通,以便所有团队成员和其他相关方都能了解与测试覆盖相关的重要信息或进展。
同样,测试人员应该记录他们开发的测试用例,仔细记录特定测试的性质和所涉及的问题。这种透明度和清晰度对于推进团队实现 E2E 测试目标大有助益。
正如之前所说(例如在本文中),但这一点值得再次强调。要进行有效的 E2E 测试,您必须时刻牢记自己服务的目标用户群体。
真正尝试去了解用户的想法。他们对该应用程序有何期望?用户可能会以何种方式与该应用程序进行交互?这需要由您来确定,同时在开发测试用例时,您需要保持这种用户思维。
此外,明智的做法是在各种浏览器中测试应用程序,以确保无论使用什么浏览器,应用程序都能顺畅地运行。如今这一步是必不可少的,因为用户会使用各种浏览器和操作环境。
E2E 测试的一个主要目标是确认应用程序无论在何处或如何使用都能正常运行。E2E 测试足够广泛且全面,能够执行所需的广泛且复杂的系统测试,以确保跨平台兼容性。
要实现无错误的用户体验,需要非常出色的执行能力。幸运的是,E2E 测试完全能够支持这一复杂任务。
完全托管的单租户服务,用于开发和交付 Java 应用程序。
使用开发运维软件和工具,在多种设备和环境中构建、部署和管理云原生应用程序。
云应用程序开发意味着一次构建、快速迭代和随处部署。