您可以轻松地观察到，新建的桥梁仅允许10辆汽车中的9辆通过，还是由无法完全对齐的部分组成。 不幸的是，在数字项目中，等效缺陷通常会被接受。 桥梁是有形的三维结构，而数字结构则不是。 您如何确保可能具有无限尺寸的项目的质量？ 您如何测试？
测试自动化是解决软件项目质量保证中不断增加的工作量的明显解决方案。 人为错误更少，覆盖范围更广，资源更少以及能够扩展重复任务是自动化的一些众所周知的好处。 但是，要真正从自动化中受益，有必要在此过程中降低复杂性。 这篇文章介绍了上下文驱动的自动化，作为隐藏不必要的复杂性层的解决方案，以便测试人员可以将精力集中在最有意义的地方。
“要真正从自动化中受益，就必须在整个过程中降低复杂性。”
质量检查团队接受自动化并开始推广之后，他们通常会经历可预测的学习过程。 此过程的各个阶段将在后面描述，但可以总结如下：
首先，测试用例是一个一个地构建的，以复制手动完成测试的方式。 这称为线性或1：1自动化。 然后，随着与越来越多的独立测试用例相关联的维护工作量变得不受控制，人们意识到必须以一种更智能的方式完成测试自动化。 自动化旅程的第二阶段全部涉及跨多个测试用例优化和重用零件。 它通常涉及将数据源插入自动化流以运行数据驱动的自动化。 该练习可以显着减少维护工作量，但是却以瘫痪复杂性为代价。
大多数测试团队将其提升到了第二个层次：他们实现了数据驱动的自动化，但是却在不知道如何处理的情况下迷失了复杂性。 解决方案是上下文驱动的自动化，这是自动化学习曲线的最后阶段。 很少有公司（例如Amazon和Google）在自动化方面达到这种成熟水平，但这不应该使您气our！ 继续阅读，有机会熟悉上下文驱动的自动化的概念。
阶段1：线性自动化
如上所述，自动化部署通常始于测试团队通过逐个构建自动化案例来逐渐使他们的测试套件自动化。 自动测试通常只是手动测试流程的副本。 这是一种“鹦鹉”式的自动化方法，因为手动流程只是一对一地重复，而测试自动化工程师无法对被测业务流程有更深入的了解。
线性自动化缺乏被测系统的直升飞机视野，因此这种方法具有一些固有的局限性。 现实生活中的一个例子：一个测试团队已经建立了1,600个独立的测试用例（要测试的功能16个，每个功能100个测试）。 其中的每一个都需要测试人员进行连续维护，因此自动化带来的收益可能会因不断增加的维护工作量而被抵消，尤其是当被测产品更换时。
“线性自动化缺乏对被测系统的直觉了解，并存在测试自动化工程师无法对被测业务流程有更深入了解的风险。”
阶段2：数据驱动的自动化和可重用测试用例
通过构建可在各个测试案例之间重用的组件，可以在某种程度上减少测试案例的维护。 例如，使用LEAPWORK自动化平台，可以将自动化流程的任何部分转换为“自定义构件”或子流程，以便在其他流程中重复使用。 显然，这可以节省建筑自动化流程的时间。
可重用组件对构建自动测试用例的测试人员隐藏了一层复杂性。 但是，这种简化带来了创建纠缠引用的迷宫结构的风险，其中到给定点的路径不止一个。 有些路径是死胡同，另一些则会绕圈走。 如果测试人员迷宫般迷路，他或她会很快失去视野，并会开始怀疑“我是否测试最重要的东西？ 测试用例是否满足要求？ 我什至可以相信这些测试用例吗？”
数据驱动的自动化与进一步优化自动化测试有关。 您不必为每个测试方案构建自动化流程，而使用一个或多个数据源来提供流程。 在执行流程时，它将循环访问源中指定的数据条目，并对每个条目执行相同的过程。
数据驱动的自动化是一种尝试对被测流程进行解构以更好地理解它们的尝试。 该练习通常揭示了跨测试用例的一些共同点，即数据输入。
通过自动化数据使用（例如，将电子表格连接到自动化流程），上面示例中的1600个单独的测试用例现在被“重新打包”了，现在仅用200个数据驱动就可以实现相同级别的测试覆盖率测试用例。
“数据驱动的自动化是一种尝试对所测试的流程进行解构以更好地理解它们的尝试。”
数据驱动的自动化为测试人员隐藏了另一层不必要的复杂性，测试人员不必再担心单个数据条目，而只需要知道如何将数据源插入其自动化流程即可。 在这个阶段，对于任何测试团队来说，测试用例的数量都更加易于管理，但是复杂性却转移到了测试数据上，在该数据中还有许多维度需要导航。 一个包含100多个参数的测试数据集，其复杂性难以理解，其中大多数参数要么未用于每个测试用例，要么分布在多个数据源中。
阶段3：上下文驱动的自动化
上下文驱动的自动化将其简化到一个新的水平。 这是一种隐藏复杂性的方法，测试人员仅关注测试用例中的基本内容。
上下文驱动的自动化依赖于数据源，其中数据之间的相互关系是在源本身中预先配置的。 这样，在构建自动化流程时不必指定关系，这使得重用组件（例如LEAPWORK中的子流程）更加容易。 从理论上讲，上下文驱动的自动化将多维项目减少到三个维度或更少，从而使人工测试人员更易于管理。
在实践中，可以通过让工程师对数据源和关系进行所有技术上的预配置，然后在自动化流程中使用它们，来实现上下文驱动的自动化。 复杂性分为几层，每一层都处理了复杂性的一部分。 这样，流量就被“减少”到业务流程本身。 预先配置包括在组织中测试系统所需的任何自定义（即您的上下文），这意味着测试人员可以构建自动化流程，而不必考虑被测系统的自定义改编。
因此，可以将整个测试套件简化为与上下文相关并与周围上下文的更改兼容的几种流程原型，例如测试环境，数据源，系统定制，多个产品版本等。
“整个测试套件可以简化为几种流程原型，这些原型是上下文相关的，并且与周围上下文的更改兼容。”
扩展前面的示例：通过将上下文配置从用例本身移到其他数据源，可以将200种数据驱动的自动化用例进一步简化为几种原型。
上图中所示的三种原型支持几种测试方案，其中涉及多个参数。 例如，单个业务流程的单个原型可以支持：
- 3申请
- 4个网络浏览器
- 3个设备
线性自动化将需要：
3x4x3 = 36个测试用例，以达到相同水平的测试覆盖率
对于这种简单的设置，数据驱动的自动化可能需要30个参数，其中80％的数据将是冗余的。
总结一下：
1个上下文驱动的自动化案例= 36个测试案例
所有测试用例，即使是上下文驱动的，都需要维护，但是通过将36个用例减少为1，您可以实现：
维护工作量减少97％
想象一下，如果一个业务参数仅添加了两个可能的值，那么受支持的测试用例的数量将增加一倍，达到72个，效率将提高99％。 添加具有多个可能值的多个业务参数以支持多个用户角色（即谁登录到被测系统中）的情况并不少见。 在这种情况下，通过利用上下文驱动的自动化来减少维护工作量，潜在的效率提高将大于99.9％。
上下文驱动的自动化哲学与LEAPWORK完全一致 。
借助LEAPWORK自动化平台 ，无论开发人员，技术专家还是业务通才，无论其技术水平如何，都可以自动化先进的跨功能测试和流程。 所有复杂性层都在“底层”，用户可以通过连接可视化构建块来构建自动化流程。 每个块都包含驱动自动化引擎的隐藏代码，可以根据需要对其进行参数化和预配置，从而实现上下文驱动的自动化。
从逻辑上讲，这种方法很有意义。 为了显示：
- 要开车，您不需要知道引擎中发生的所有基本过程。
- 要将电子邮件发送给同事，您不想花费时间来了解使电子邮件能够发送和接收的系统。
除了明显的效率提高以外，上下文驱动的测试自动化还降低了复杂性，因此测试人员可以从最终用户的角度验证功能的工作原理，而不仅是验证功能是否有效。
“驾驶汽车，您不需要知道引擎中发生的所有基本过程。”
简而言之，上下文驱动的自动化使测试人员能够更好地执行其主要任务：通过不断挑战被测产品，而不是花时间浏览成千上万个相互关联的测试用例及其周围的框架，从而充当最终用户大使。
最后一点：上下文驱动的自动化最令人兴奋的事情之一是，它适用于除软件测试之外的其他自动化方案，例如RPA（机器人过程自动化）。 上下文驱动的自动化以最简单的形式隐藏了复杂性层并揭示了流程，因此，它支持这样的论点，即测试自动化和RPA都是相似的学科。
- 通过LEAPWORK开始您的自动化之旅
- 凯捷丹麦提供的测试自动化服务 （丹麦文）
- 使用LEAPWORK参加自动化课程 （丹麦语）
