迷宫》单元测试、集成测试、端到端测试、安全测试、性能测试、压力测试、契约测试、冒烟测试、验收测试、API测试、UI测试、兼容性测试...”不确定您是否像我一样被所有这些不同的“测试”所淹没。作为一个有抱负的开发人员，自然要确保编写的程序和构建的系统具有良好的质量。但面对这些千奇百怪的考验，难免心灰意冷。只能说服自己，“让专业的人做专业的事”，然后把测试工作推给QA，自己写代码。不仅考试种类繁多，而且每个人对某个考试的理解也不尽相同。以大家最熟悉的“单元测试（unittesting）”为例，问题的关键在于“单元（unit）到底是什么？”有人说是方法，有人说是类，有人说不对，应该是最小的业务单元（至少在API层面）。也有人提出了IntegrationUnitTest的概念，即在集成层面进行单元测试。不止是我等软件小白，就连很多IT界的大神级人物也经常为此争论不休。俗话说，一千个人脑子里有一千种单元测试，这似乎是有道理的。列表法（listmethod）这是昨天陪女儿做作业的时候，看到她用一种叫做“列表法”的方法来解决小学二年级的一道逻辑题。女儿说这个方法很神奇。原本看似一波三折的问题，画个表钩，画个十字就可以解决了。然后又查了下：“列表法是小学数学中经常用到的一种方法，很多复杂有趣的问题都可以用列表法来解决。用列表法来分析思维，找思路，解决问题。就是经常用来解决类似鸡兔同笼的经典问题...”虽然一直没弄明白为什么要把鸡和兔关在同一个笼子里，但是回到测试迷宫的问题上，这种小学好像是三年级才教的。也可以应用方法。测试矩阵（TestMatrix）测试种类繁多，难以理解，难以交流。我认为主要原因是我们混合了两个测试类别的维度。第一个维度是测试实施的级别或粒度。说白了就是测试的水平，也可以理解为测试在什么地方测试。它是一种方法吗？是一堂课吗？它是一个API吗？它是一个单一的服务吗？它是一对服务吗？还是申请？还是一个系统？对不同类型的测试进行分类的维度。但是当我们说到这些测试的时候，其实隐含了一个概念，那就是它们在测试什么？这就是测试的目的。比如我们在上面提到单元测试、API测试、端到端测试的时候，隐含的想表达的是单元级的功能测试、API级的功能测试、端到端的功能测试。这时候你肯定会想，这不是废话吗，我不测试功能还测试什么？这就是我要讲的测试分类的第二个维度：我们测试的主题，或者说测试的目标。如果说第一个测试维度是基于“wheretotest”，那么第二个维度就是基于“whattotest”。比如我们经常提到的：功能测试、集成测试、性能测试、安全测试、压力测试、兼容性测试、契约测试，都是基于这个维度来区分不同类型的测试。他们不是关注我们去哪里测试，而是更关注我们要测试什么：业务功能是否正确？能否如期整合？合同有保障吗？安全性能否满足要求？业绩是否达到预期和要求？大多数情况下，测试是为了验证功能是否正确，所以我们往往会忽略第二个维度，只关注测试的地方。第二个维度只有在我们测试性能、安全等非功能性需求的时候才会想到，但是有意思的是，这个时候我们往往会忽略第一个维度，比如当我们听到有人提到性能测试的时候，其实并不是明确测试的是方法的性能，API的性能，还是UI的性能，导致理解不一致和混乱。换句话说，可以看出，之前我们被测试迷宫困扰的本质原因是我们没有明确区分这两个维度，甚至混淆了它们，这使得我们对“XX测试”的定位和理解"，包括沟通。模糊而不准确。如果我们不再提“单元测试”和“性能测试”这些模棱两可的概念，而是在测试矩阵上采用二维定位的方式，将名称改为“方法级功能测试”和“API级性能测试””，我想我们在测试乃至学习和实施上的交流和讨论会更加清晰和简单。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
