逐步分解，为测试执行制定路线图，以根据应用程序的演变扩展您的测试。
译自A 5-Step Framework for Test Execution，作者 Ole Lensmar。
在我们之前的文章中，我们指出将测试执行与 CI/CD 流水线耦合存在一些缺点，这些缺点随着应用程序或部署基础设施的复杂性和规模的增加而变得明显。现在让我们退一步，看看CI/CD在此背景下解决的初始需求：运行您的测试，也称为测试执行。与许多事情一样，在构建基础设施时对测试执行进行一些额外的思考和关注，可以为您带来多倍的回报。让我们来分解一下。
STLC 中的测试执行
软件测试生命周期 (STLC) 是软件开发生命周期 (SDLC) 中测试活动的分步分解，它是一个成熟的流程。从高层次来看，STLC 包括以下步骤：
- 需求分析: 了解需要测试的内容。
- 测试计划: 计划如何测试需求。
- 测试用例开发: 编写实际的测试用例。
- 测试环境设置: 准备您的测试环境。
- 测试执行: 在您的测试环境中执行您的测试。
- 测试周期结束: 确保所有测试活动都已完成。
Source:https://www.boardinfinity.com/blog/introduction-to-stlc-software-testing-life-cycle/
如您所见，测试执行是此生命周期中的一个特定步骤，它本身就是一个值得深入研究的领域。让我们来做一下。
测试执行的 5 步框架
随着组织中测试工具、CI/CD 系统、工程师和应用程序数量的增长，以可扩展且高效的方式执行测试并管理执行结果变得越来越复杂。让我们首先将测试执行分解为五个步骤，以帮助您决定如何以可扩展的方式执行测试。
- 定义: 您将如何定义测试的执行？
- 触发: 您将如何触发测试执行？
- 扩展: 您对测试执行有哪些可扩展性需求或限制？
- 故障排除: 您如何有效地排除（失败的）测试执行的故障？
- 报告: 您需要哪些报告来计划（未来）测试活动？
图片
让我们更详细地探讨每个步骤，以帮助您了解您可能需要在团队中回答哪些问题。
- 定义– 您将如何以一致的方式运行您的测试，考虑到：
您现有的（和未来的）测试工具和版本
用于数据驱动测试的输入数据
测试编排：例如，以协调的方式执行多个测试，可能跨多个/远程环境
- 触发– 您将如何触发测试的执行？
来自 CI/CD 工具，作为构建和部署流程的一部分？
定期计划执行？（例如，“每天运行我们的安全测试。”）
基于外部/内部异步事件触发器或 Webhook？（“每当这些组件在我们基础设施中更新时，重新运行端到端测试。”）
临时或手动？
通过 API/CLI 的自定义集成？
- 扩展– 当您扩展测试活动时，请确保您已评估：
您需要模拟多少负载？
您能使用您现有的/内部基础设施吗？
您如何与其他（测试）活动协调？
并行化以缩短执行时间？
异步调度而不是每次构建都运行？
您预计在“峰值测试时间”运行多少测试？
您是否有跨测试共享的/有状态的基础设施？您是否需要相应地限制测试执行？
您是否有运行时间很长的测试，需要：
测试应该在您的基础设施内部和/或外部运行（或两者）？
专门针对负载测试：
- 故障排除– 在复杂的应用程序基础设施中，排除失败测试的故障可能很痛苦：
您测试工具的日志和工件是否足够，或者您还需要测试中应用程序的日志和指标？
相关人员是否有权访问日志/基础设施进行故障排除？
所有故障排除都可以在一个地方完成，还是有多个访问点？
您需要保留结果多长时间？
日志或工件是否包含敏感信息？它们是否需要安全存储？
- 报告– 问问自己：
您需要随着时间的推移跟踪哪些指标，以及以什么粒度？例如，通过/失败比率、测试总数等。
您是否可以或应该将来自不同测试执行和测试工具的结果聚合到通用报告中？
访问控制：相关人员是否有权访问报告？
报告/指标是否可以按所需维度进行分析，例如团队/应用程序等？
测试执行结果是否需要推送到外部系统？例如：报告、事件管理、问题跟踪
报告应该如何内部分发并随着时间的推移进行访问——短暂/长期 URL？PDF？等等。
测试执行评估标准
除了上面概述的测试执行的战术方法之外，我们还可以定义一些需要评估和规划的标准，以便根据您的团队和应用程序的需求进行相应扩展。
- 一致性– 获得一致的测试结果是建立对质量指标和下游活动的信任的关键，为此，您的测试执行环境应尽可能同质，前提是您的应用程序的上下文。
- 解耦– 测试执行不应与基础设施中的任何其他特定框架或流水线紧密耦合。随着时间的推移，运行测试的需求将在战略和战术上发生变化，您的测试应该随时可用以执行。
- 集中化– 虽然您的测试可能在基础设施中的多个地方执行，但在一个地方管理这些执行及其结果可以为您提供测试活动的整体视图，从而使您能够随着应用程序和基础设施的扩展，始终如一地评估、分析和控制测试执行。
- 集成– 测试执行通常需要与您现有的工作流程和流水线集成——但不要紧密耦合！- 测试的执行需要从各种来源触发。
- 测试执行或失败的通知需要集成到协作平台和事件/问题跟踪中。
- 测试结果或指标可能需要由外部监控或报告工具捕获。
- 可扩展性– 大规模运行测试是采用主动测试执行方法的团队面临的最常见挑战之一。
- 需要水平扩展单个测试以提高执行时间或涵盖更多测试场景
- 多个团队需要使用受限资源（基础设施、共享数据库等）运行其测试
- 需要扩展负载测试以生成所需的负载，以确保应用程序和基础设施的性能和稳定性
- 安全和访问控制– 这有几个方面：
- 谁应该能够运行测试、查看结果等？
- 如果您的基础设施需要专门为测试执行进行配置，这是否会对安全造成任何影响？
为测试执行制定路线图
以上两个部分都不是要穷尽或最终确定它们各自的方法。每个应用程序基础设施都是独一无二的，因此您的团队对如何运行测试的需求也将是独一无二的。要点是让您思考测试执行，而不是“在 Jenkins 中运行我的 playwright 测试”——因为这肯定会遇到死胡同，并阻止您根据应用程序的演变来扩展测试活动。
一种动手的方法可能是：
- 将您的测试活动分解为 STLC 的不同步骤。您是如何执行这些步骤的？谁负责？您有什么需求？
- 将测试执行分解为上述五个步骤，并再次问问自己：您的需求是什么，谁负责等等。
- 将上面概述的测试执行评估标准纳入您的测试执行策略。确保您至少讨论了所有这些标准，即使您的行动方针是“忽略”。
- 确保合适的人员参与所有这些讨论（无特定顺序）：
QA 负责人/经理
DevOps/平台工程
系统架构（如果需要/适用）
产品所有权（如果需要/适用）
Testkube 用于测试执行
也许并不奇怪，我写这篇文章不仅是为了分享对测试执行的见解，也是为了向您展示Testkube如何提供帮助。
简而言之，Testkube 是一个用于测试执行的编排平台，符合上面讨论的许多（但不是全部）要点。上面概述的用于测试执行的五个步骤是如何使用 Testkube的基石：
- 定义使用强大的测试工作流程语法定义您的测试执行，该语法支持您可能使用的任何测试工具或脚本。
- 触发您的测试，无论您可能需要什么；CI/CD、事件/webhook、CLI、API 等。
- 扩展任何测试工具，水平或垂直扩展，以确保您的应用程序始终如一地进行测试，并大规模扩展。
- 排查使用 Testkube 结果和日志分析功能排查测试结果。
- 报告随着时间的推移报告测试结果，以指导您的测试工作和活动。
虽然 Testkube 无法解决上面讨论的所有问题，但它提供了一个扎实的起点。请访问testkube.io/get-started试用。有开源版本和免费版本可用。
