测试矩阵

谈谈对各种测试方法做二维定位后形成的测试矩阵.

最近在ThoughtWorks的#TW洞见#栏目看到了测试矩阵的概念和介绍，觉得很有意思。也让我在另一种层面上理解了各种测试方法。

你晕了没

相信大家在初学测试的时候一定听过下列测试名词：单元测试、集成测试、性能测试、API测试、UI测试、压力测试、冒烟测试等等。诸如此类，不胜枚举。这么多的“测试”不知道你晕了没，反正博主开始是挺晕的。

此外，不同的人对这些测试的理解也不尽相同，比如“单元测试”，在Java中，有人说一个类就是一个单元，有人说一个方法就是一个单元，甚至有人说一个完整的API就是一个单元。一千个人眼里有一千种单元测试。。。

测试矩阵

既然有这么多的测试方法，在实际的测试工作中，我们到底怎么测试呢。像上边说的，测试种类如此繁多，难于理解，所以在测试时也难以沟通。

其实，我们可以从两个维度来理解这些测试方法，并将其应用到实际工作中。

其中，第一个维度就是测试实现的层次和粒度，说白了就是测哪。是方法，类，还是API？是应用、系统、还是整个平台？

而我们常说的性能测试，功能测试，安全测试等等，都可以归为第二个维度，即测试的目标，也就是测什么，咋测。

这两个维度结合起来就形成了下边的测试矩阵：

测哪\咋测	功能测试	集成测试	性能测试	安全测试
端到端	test	test	test	test
API	test	test	test	test
类	test	test	test	test
方法	test	test	test	test

有了这样的认识，以后进行测试工作时工作起来就方便多了。我们可以进行“方法级别的功能测试”、“API级别的性能测试”等等。这样，使测试内容变得更加清晰。

事实上，，而常常忽略了第二个维度，即咋测。所以，根据测试矩阵进行测试，可以避免这种问题。在实际测试工作中，大多数情况下都进行的是功能测试。