软件测试的底层逻辑是什么？

“事物间的共同点，就是底层逻辑。

只有不同之中的相同之处、变化背后不变的东西，才是底层逻辑。

……

底层逻辑+环境变量 = 方法论”

所以我们要来探讨一下：软件测试的底层逻辑是什么？

1. 对软件测试的基本认知

对软件测试的基本认知，使我们达成共识，从而基于这个共识，更容易去讨论软件测试的底层逻辑。对软件测试的基本认知，需要精简到一句话来描述，即抓住软件测试的本质，以简洁的方式描述正确的软件测试价值观，但不是某个人的软件测试价值观，而是能被大多数人接受的软件测试价值观。

软件测试是验证软件功能特性是否满足需求；

软件测试就是发现软件中存在的缺陷

软件测试包含了静态测试——需求、设计、代码的评审活动

软件测试是系统、完整地评估软件产品质量，提供质量信息

软件测试是暴露、揭示产品质量风险

软件测试不仅是技术性活动，而且是 会性、心理等多方面的综合性活动。

软件测试是通过投入质量保障性成本来极大地减少劣质成本

根据这些对软件测试的认知，用一句话来说明软件测试的基本认知，那就是：基于对用户真实需求的理解，通过各种手段获得软件产品真实的、全方位的质量信息。无论是验证软件功能特性是否满足需求、评估产品的质量还是揭示产品的质量风险，都是基于获得的有关产品的真实的质量信息做出判断的，而缺陷可以看做是这个活动过程中的副产品。

这里强调对用户真实需求的理解，一方面体现“没有用户就没有质量，质量相对用户而存在”，我们必须从用户角度出发来完成测试，另方面是用户的真实需求，而不是虚假的、错误的需求，业务的需求最终要分解成用户角色的需求，而系统的功能/非功能性需求也是为了满足用户的需求。

这里提到的“软件产品”不局限于程序，还包括数据、需求文档、设计文档、代码、用户手册、技术手册等。

了解了“什么是软件测试”之后，下面就可以讨论软件测试的底层逻辑。

2. 软件测试的底层逻辑

软件测试的底层逻辑可以概括为三个问题的回答：

为什么测？

测什么？

如何测？

而且在回答这三个问题的过程中，要能适应不同的测试对象（如Windows/MacOS native应用、 web软件、移动app、嵌入式软件 ）、不同的测试类型（如功能测试、性能测试、安全性测试、兼容性测试等）、不同的测试层次（如单元测试、集成测试、系统测试等）、不同的团队和不同的产品等，成为放之四海而皆准的答案。虽然上下文不同，会有不同的测试方法、技术和实践，但我们能抽象出它们的共同点。

基于这样的考虑，那下面就来回答这三个基本问题：

为什么测？只要是人做的工作，就不能保证万无一失，会存在问题。如果软件带着问题出去，就很有可能给客户带来损失或让客户不满意，最终导致企业的利益受损。过去无数的质量事故，也证明了这一点，在交付给客户之前，软件需要得到充分的测试，否则后果严重。

测什么？取决于交付的质量目标，即从质量目标出发，进行目标分解，然后针对每一个特定的子目标来确定要获得的有关被测对象的质量数据，从而确定其测试范围或测试项。如果再进一步，我们根据用户对质量特性、功能特性的感受不同来决定测试项的优先级。这部分属于测试分析的工作，并涉及测试风险和测试策略。

如何测？就是找到获取被测对象的质量数据的方式、方法或手段，包括测试方案设计、场景设计、测试用例或测试数据等的设计。

软件测试灵魂三问，如何怼回去？

第 1 问：为什么这个 Bug 测不出来？

第 2 问：测试怎么测得？到底会不会测？

第 3 问：测试快点啊！为什么总是测试拖后腿，最后才 Bug？

其实也体现了“软件测试”的另一层逻辑，即：

第1问的答案所呈现的底层逻辑：测试是不能穷尽的，测试总是有风险的，而且开发写出的Bug越多，测试漏掉的Bug越多；测试只能证明已发现的缺陷是缺陷，不能证明软件没有缺陷，因为测试是一个样本实验。

第2问的答案所呈现的底层逻辑：对所做的测试工作（包括测试目标的制定、测试分析的过程以及对应的测试设计方法）能解释清楚，而且测试不是孤立的工作，受需求（如需求模糊）、系统设计（如耦合性、复杂性）、编程（如偷偷修改代码）等影响，测试要与产品、开发等紧密合作。

第3问的答案所呈现的底层逻辑：我们可以在开发写完代码之前完成测试分析、测试计划和测试设计，但系统层次的测试执行需要等待开发完成版本构建，测试执行是后期工作，测试时间容易被开发前期工作挤掉一部分，项目的延期容易造成错觉——测试拖后腿。

测试的底层逻辑（概率思维）：测试是一个样本实验，需要精心分析和设计，努力以最小的代价并尽早地去揭示质量风险。

3. 测试流程的底层逻辑

测试流程符合一般工程项目流程，经过分析、计划、设计、实施和评估的过程，任何一个环节不可缺失，每一个环节都重要，但前面的环节会影响后面的环节，所以越在前面的环节越重要。测试分析是基础，依次是设计、实施和评估，构成一个金字塔模型。

测试流程的另一个底层逻辑：形成闭环。如果经过评估，发现测试过程有问题，需要重新分析、修改计划、修改设计……再经过一个完整的过程，构成一个新的闭环。

4. 测试分析的底层逻辑

测试分析的底层逻辑是基于系统思维、结构化思维去思考，需要从项目背景、产品结构、质量要求等各个方面进行系统地思考，不容忽视一些蛛丝马迹，顺藤摸瓜，完整地呈现测试范围，识别出各种测试风险，最终明确测试项及其优先级。

测试分析的底层逻辑之一：测试分析是层层剥离、逐步深入的系统分析过程。从业务需求、用户行为、系统功能、应用场景等不同维度对被测对象进行系统的分析，最终确定测什么。

测试分析的底层逻辑之二：测试分析也是一个博弈、选择直至平衡的过程，需要定力和洞察力，做出取舍，如运用80/20原则，抓主要风险，有时需要舍弃一些次要风险。

测试分析的底层逻辑之三：以终为始，从测试目标出发最终回到测试目标，如从考虑如何衡量测试充分性地要求出发，最终分析的结果——各测试项完成是能够满足测试充分性的要求的。

5.测试人员的底层逻辑

最后谈谈测试人员的底层逻辑。测试人员是否有价值，不取决于他/她目前的工作态度、知识与技能，而是取决于工作态度、知识与技能的进步速度，因为我们无法改变过去，但可以改变未来。只要持续学习、持续反思，就能快速完成自己的进化，快速成长起来，就没有人能挡得住你的壮丽前程。