测试矩阵是什么，小孩子都懂的，你该不会不知道吧

迷阵

“单元测试，集成测试，端到端测试，安全测试，性能测试，压力测试，契约测试，冒烟测试，验收测试，API测试，UI测试，兼容性测试……”

不知道你是不是像我一样，曾被这些各种各样的“测试”搞得晕头转向。作为一个有追求的开发人员，保证所写的程序、所构建的系统具备良好的质量自然是分内之事。但是面对这些千奇百怪的测试难免会望而却步，只能劝自己一句“专业的事情还是交给专业的人去做吧”，然后把测试的工作一把推给QA，闷头写自己的代码去了。

不光是测试种类众多，每个人对于某一个测试的理解也都不一样。就拿大家最熟悉的“单元测试（unit testing）”来举例，问题的关键就被聚焦到了“到底如何才算是一个单元（unit）有人说是一个方法，有的人说是一个类，有的人说都不对，应该是一个最小的业务单元（至少是API级别的）。还有人提出了Integration Unit Test的概念，即集成级别的单元测试。

不光是我等软件小辈，就连很多IT界的神级人物也常常为此争论不休。

古话说的好，一千个人心中有一千种单元测试，看来说的是有道理的。

列表法

（测试矩阵）

测试的种类繁多，难于理解，难于沟通。我觉得主要是在于我们将两个测试分类的维度混杂在了一起。

其中第一个维度是测试实现的层次或粒度，说白了就是在哪个层次上的测试，也可以理解成测试到底测的是哪儿。是方法类API单个Service两两Service是应用是系统是平台/p>

我们常说的单元测试，API测试，端到端测试，UI测试都是侧重于按照这种维度去分类不同的测试种类的。

但是我们在谈论这些测试的时候，其实隐含了一个概念就是他们测的是什么就是测试的目标。例如当我们提到上面的单元测试、API测试、端到端测试的时候其实隐含的想表达的是单元级别的功能测试，API级别的功能测试和端到端级别的功能测试。

这时候你肯定会想，这不废话么，不测功能我测什么/p>

这就是我想说的第二个测试分类的维度：我们测试的标的物，或是说测试的目标。如果说第一种测试维度是根据“测哪儿”区分的，那第二个维度就是根据“测什么”区分的。

例如，我们常常提到的：功能测试、集成测试、性能测试、安全测试、压力测试、兼容性测试，契约测试都是这种按照这个维度去区分不同的测试种类的，他们都不是关注于我们要测哪儿，而是更侧重于我们到底要测什么：业务功能是否正确否能按预期集成约是否被保证全能否达到要求能是否满足预期和要求/p>

只不过我们日常工作中，大多数情况下测试都是在验证功能是否正确，所以我们常常忽略了第二个维度，只关注于测哪儿。只有当我们去测试像性能和安全这种非功能需求的时候才会想到第二个维度，但有趣的是往往我们这时候又会忽略第一个维度，例如当我们听到有人提及性能测试的时候，并没有明确的表达测的是方法的性能、API的性能，还是UI的性能，进而导致了理解的不一致和混乱。

换个叫法

可见，之前之所以被测试迷阵困扰，其本质原因就是并没有明确区分开这两个维度，甚至将之混为一谈，从而使我们对于“XX测试”的定位和理解包括沟通都变得模糊而不准确。

如果我们不再提“单元测试”、“性能测试”这种含糊不清的概念，而是通过测试矩阵上的二维定位法，改称“方法级别的功能测试”和“API级别的性能测试”，我想我们对于测试的沟通讨论甚至学习实现将明确的多，也简单的多。

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8820 人正在系统学习中

来源：程序员张无忌