测试影响分析的兴起

套件和标签的创建

单元、服务和功能 UI 的主要分组。在单元测试中，对有意义的子分组进行标记，包括一个“快速”标记，它对其他标记进行子集采样。

在运行“购物车”测试后，除了一个测试外，所有测试都通过了。这里。

这种方法适用于递归构建技术，例如 Ant、Maven、MSBuild、Rake 等。

从历史上看，团队会放弃让他们的测试无限快地运行，而是使用套件或标签来定位任何时候的测试子集。通过创建套件和标签，可以对测试子集进行口头描述。例如，“购物车的 UI 测试”。标签或套件可以暗示应用程序的业务领域，或者暗示技术或分层分组。定义标签和套件需要专家的人工设计创造力。至少为了推动最佳分组。这意味着它们也可能分组不足、不精确和分组错误，这很常见，即使对人类来说很难确定。同时执行的测试太少和太多，对于只运行一个套件来说是一个很大的可能性——浪费了计算资源和时间，而且还存在让错误溜过去的风险。团队可能会选择让 CI 作业使用每个提交的较小子集，然后也让夜间构建作业运行所有测试。显然，这会延迟坏消息，并违背了 持续集成 的目标。

然而，套件和标签是大多数软件开发世界组织其测试代码库的方式。

源代码与测试的预先计算图

276 个测试及其名义上的“大小”指定。

为给定提交执行的测试，有两个失败的结果。碰巧的是，其中一些结果很小，一些结果中等，一些结果很大。我只描绘了一棵树/分形，因为它有助于解释概念（它并不完全是这样）。

谷歌传奇的内部构建系统 Blaze 这些年来已被复制到一些开源技术中。最值得注意的是 Facebook 的 Buck 和谷歌的 Bazel。Twitter、Foursquare 和 Square 的 Pants。谷歌内部的 Blaze 在整个单一存储库中导航单个有向图。Blaze 具有将测试直接与生产代码关联的机制。该机制是生产源代码和相关测试源代码的细粒度目录树。它通过 BUILD 文件进行显式依赖声明，这些文件也被签入。这些 BUILD 文件可以由开发人员维护和演变，但也可以通过自动化工具验证其正确性或错误性。随着时间的推移，这个过程不断重复，这在很大程度上使有向图变得正确且高效。

重要的是，该工具可以指出关于依赖关系的冗余声明。因此，对于给定的目录/包/命名空间，开发人员可以非常轻松地启动测试子集——但只有通过 BUILD 文件中的有向图才能实现的测试。最终的省时方法，无论是对于开发人员的 预集成 还是集成基础设施，都是基于这种内置智能的扩展 CI 基础设施“Forge”（后来的 TAP），它可以自动对每个提交运行的测试进行子集划分。

在 驯服谷歌规模的持续测试 中，有很多令人惊叹的统计数据。在我看来，这些东西让谷歌花费了数千万美元，但多年来也为他们带来了数十亿美元的收益。也许远远超过了收益：工资比率。

微软在 TIA 方面的广泛工作

微软在将测试影响分析的想法投入生产方面付出了最长久的努力，并为这个概念命名了它的名称及其缩写。

他们目前有一系列博客文章，涵盖了 2017 年 3 月到 8 月，到目前为止：使用测试影响分析加速持续测试 - 第 1 部分，第 2 部分，第 3 部分，以及 第 4 部分。

他们关于此的较早文章可以追溯到八年前

1. Visual Studio 2010 中的测试影响分析 (2009)
2. 使用测试影响分析简化测试流程) (2010)
3. 自上次构建以来应运行哪些测试？ (2010)
4. 如何：收集数据以检查代码更改后应运行哪些测试 (2010)
5. 测试影响分析 (2011)

微软的 Pratap Lakshman 详细介绍了他们实现的演变。关于他们 TIA 技术的当前演变，Pratap 说：[1]

        Testcasemethod1 <--> a.cs, b.cs. d.cs
        Testcasemethod2 <--> a.cs, k.cs, z.cs 

关于 TIA 在 TFS 和 Visual Studio 中的头几年，他说

通过传统代码覆盖工具和脚本进行测试影响分析

当我还在 HedgeServ 工作时，我有一个想法，就是将现代的现成代码覆盖工具整合到相同的冲击分析中。从这个想法出发，我创建了两个概念验证博客条目（在 Github 上有相关代码）：一个用于 Maven & Java[2]，另一个用于 Python[3]。当然，就像一个 eejit 一样，我认为我有一个新颖的发明，但我当时并不知道在这个领域已经有很多先例（微软就是其中之一）。我展示的技术在您的工具链中开发成本低廉，即使它在您的 CI 基础设施中运行可能会有成本。

测试冲击分析理念的简单实现需要您事先进行一项活动

1. 运行单个测试并收集其代码覆盖率
2. 从测试触及的生产源文件中，创建一个临时映射，将生产源文件（键）映射到测试路径/名称（值）。
3. 更新包含主映射的源文件，替换该测试的所有先前条目。
4. 将这些更改后的映射源文件提交到 VCS（只有相关的 CI 作业应该有权限执行此操作）。
5. 清除覆盖率数据（以免将每个测试的覆盖率报告纠缠在一起）。
6. 返回到步骤 1，进行下一个测试（最近更改的源文件/测试优先？）。

在逐个运行所有测试后，您将获得一个全面的映射，将生产代码连接到覆盖它们的测试。

然后，当您稍后对某些生产代码进行更改时，您可以找出哪些测试执行了该代码，因此在运行时可能会有信息量。产生的任何测试失败都证明是更改所导致的唯一可能发生的测试失败。上面提到的两个概念验证包含少量 Python 代码，试图

• 提前计算 TIA 映射
• 在 预集成 情况下使用 TIA 映射（稍作修改，也可以在 CI 作业中使用）。

HedgeServ 的测试库由常规的快速单元测试组成，然后是集成测试，这些测试是 Microsoft Excel 电子表格，这些电子表格间接调用 Python。共有 12,000 个。这些测试是数小时的广泛而高级的算法测试，如果没有一些“减少运行次数”的策略，在 CI 基础设施中每进行一次集成就进行一次测试是不可能的。他们的 DevOps 团队将概念验证操作化为“测试缩减器”（我最初给这个技术起的名字），最快的排列现在只需要十分钟。这是一个巨大的进步。开发人员和测试工程师可以在 预集成 时运行它们，CI 基础设施也可以这样做。HedgeServ 的软件开发总经理 Kevin Loo 告诉我，“开发人员依赖于更快的测试运行，由于信心的增强，开发速度也加快了”。

由于使用了通用的代码覆盖工具，因此 TIA 方面必须一次运行一个测试，这会产生前期成本。因此，分析产生的映射被检入源代码控制并逐步更新。因此，它必须是文本形式且有序的，以便差异可以简洁且有意义。将映射检入源代码控制也有利于 CI 基础设施和希望在集成（和代码审查）之前运行更少测试的个人开发人员。

这种 TIA 设计由于代码覆盖工具的性质而存在局限性：为了计算准确的冲击图，一次只能运行一个测试。为了使用映射数据，需要运行“git status”（或 git show >hash>），然后解析输出以找到“更改/添加/删除”的生产代码源文件。这些是冲击映射的键，它们会生成要运行的测试列表。只有数据收集 CI 作业存在“一次运行一个测试”的限制，这就是为什么您或多或少地认为它一直在运行的原因。

正如您所见，测试技术可能与您为生产代码选择的语言完全不同。在 HedgeServ 的情况下，他们的算法测试是在源代码控制下的 Microsoft Excel 文件中进行的（即使业务分析师也参与其中）。如果这可能，那么 SmartBear 的 TestComplete、HP 的统一功能测试 (UFT - 前身为 QTP) 以及 Selenium 也是如此。唯一的要求是测试可以被脚本化，以便一次运行一个测试（在您构建 TIA 映射时）。您还必须承诺在初始创建后定期更新映射 - 使用您的 CI 基础设施。

然后，您需要决定将映射数据存储在何处。您可以选择文件共享、文档存储或关系模式。我选择（并推荐）将文本文件存储在与生产源代码相同的存储库/分支中的目录中。这样至少可以让分支工作（无论您的分支模型是什么）并可能具有不同的冲击映射，反映代码的不同性质。

最近，我为一个客户查看了一个使用 KDB 和 Q 的项目，并试图就如何缩短测试时间向他们提供建议。这些语言没有代码覆盖技术，所以谈话就到此结束了。

VectorCAST/QA - 应用

VisualStudio 的 NCrunch