测试矩阵

迷阵

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

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

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

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

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

列表法

image.png

（列表法）

这是昨天陪闺女写作业的时候，看到她使用了一种被称作“列表法”的方法去解一个小学2年级的逻辑题。闺女说，这种方法很神奇，原本看起来弯弯绕的问题，画个表勾勾叉叉就解决了。

随后我也查了一下：“列表法是小学数学学科中经常使用的一种方法，使用列表法可以解决许多复杂而有趣的问题。运用列出表格来分析思考、寻找思路、求解问题，经常用来解决类似于鸡兔同笼的经典问题……”

虽然我一直没有搞清楚为啥要把鸡和兔子放到一个笼子里，但回到测试迷阵的问题，好像这种小学3年级就教授的方法也能适用。

测试矩阵

image.png

（测试矩阵）

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

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

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

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

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

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

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

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

换个叫法

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

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