我有一个部分答案。我相当肯定，当我在 Microsoft 时，我们将其称为“测试选择性”，但 Google 搜索该词的次数也很少。在某些产品代码更改时查找有关仅执行特定测试的信息的更好方法可能是搜索使这成为可能的技术。您需要一个代码覆盖率工具，允许您测量每个测试用例的代码覆盖率，例如 Clover： http: //www.atlassian.com/software/clover/tour/java-code-coverage.jsp（只是我在谷歌上找到的一个例子，还有很多其他的）。然后，您需要某种方法将产品代码更改与这些测试用例相关联（区分代码，然后查明以前涵盖发生代码更改的相同方法的测试用例）。在快速的谷歌搜索中，我没有找到任何关于特定技术或工具的信息，这些信息可以让你建立这种关联并过滤你要执行的测试用例。我知道我们在 Microsoft 有一些内部工具，但我不确定在野外存在什么，您需要进行更多搜索才能找到这些工具。我会假设一些代码覆盖解决方案将这些功能捆绑在一起，但同样，需要更多的搜索。

我称之为一般实践测试选择。

当我使用一系列套件，以不同的频率或不同的条件运行时，我称之为test staging。

在我在 MS 的小组中，我们将其称为有针对性的回归测试，我在这里写了这篇文章 (http://www.testingmentor.com/imtesty/2009/11/18/the-minefield-myth-part-2-the-回归测试值/）。

您将需要一种方法来确定哪些二进制文件（exe、dll 等）已针对每个新构建进行了二进制更改。对 2 个目录中的文件执行二进制比较的工具是 Diff2Dirs (http://www.testingmentor.com/tools/generaltools.htm)。

接下来，您将需要一个工具，例如 Dependency Walker (http://dependencywalker.com/) 来帮助识别其他依赖模块。

当然，这也假设您的测试用例以某种方式映射或关联到它们所针对的产品二进制文件或二进制文件。我们组织我们的回归测试 dll，以便我们知道它们正在访问哪些产品代码二进制文件，而且还按优先级排序。因此，我们可以只针对更改的代码和依赖项，或者我们可以只运行 pri 1 或所有内容。

我不知道有任何具体的术语。我个人称其为“有针对性的回归”（与您要检查所有内容的一般回归相反）。

在我的雇主构建的软件中，有一个庞大的代码库，具有极高的复杂性（分散在系统中的 100 多个配置标志的组合数学已经够糟糕了，而不考虑软件实际所做的事情），所以我们的回归脚本有，多年来，演变成一系列特定于功能的脚本运行，每个运行或多或少都是独立的。

它们不像“更改文件 Y 的 X 行会触发测试 Z”那么精细，但如果我们知道某个特定功能发生了变化，我们会进行有针对性的回归。