测试矩阵

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

最近在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级别的性能测试”等等。这样,使测试内容变得更加清晰。

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