软件测试的底层逻辑可以概括为三个问题的回答：为什么测？？测什么？？
如何测？？
哪怕是微小的努力，也要让我们每天的生活，变得明快、愉悦，把这件事看得高于一切，才是真正的【有品】
而且在回答这三个问题的过程中，要能适应不同的测试对象（如Windows/MacOS native应用、 web软件、移动app、嵌入式软件 ）、不同的测试类型（如功能测试、性能测试、安全性测试、兼容性测试等）、不同的测试层次（如单元测试、集成测试、系统测试等）、不同的团队和不同的产品等，成为放之四海而皆准的答案。虽然上下文不同，会有不同的测试方法、技术和实践，但我们能抽象出它们的共同点。
基于这样的考虑，那下面就来回答这三个基本问题：
01为什么测？
只要是人做的工作，就不能保证万无一失，会存在问题。如果软件带着问题出去，就很有可能给客户带来损失或让客户不满意，最终导致企业的利益受损。过去无数的质量事故，也证明了这一点，在交付给客户之前，软件需要得到充分的测试，否则后果严重。
02
测什么？
取决于交付的质量目标，即从质量目标出发，进行目标分解，然后针对每一个特地的子目标来确定要获得的有关被测对象的质量数据，从而确定其测试范围或测试项。如果再进一步，我们根据用户对质量特性、功能特性的感受不同来决定测试项的优先级。这部分属于测试分析的工作，并涉及测试风险和测试策略。
03
如何测？
就是找到获取被测对象的质量数据的方式、方法或手段，包括测试方案设计、场景设计、测试用例或测试数据等的设计。
也就是 For Quality, from Quality objectives and by getting Quality data (为了质量而测，从质量目标出发、想方设法获取质量信息）。
软件测试灵魂三问，如何怼回去？
第 1 问：为什么这个 Bug 测不出来？
第 2 问：测试怎么测得？到底会不会测？
第 3 问：测试快点啊！为什么总是测试拖后腿，最后才报 Bug？
其实也体现了“软件测试”的另一层逻辑，即：
第1问的答案所呈现的底层逻辑：测试是不能穷尽的，测试总是有风险的，而且开发写出的Bug越多，测试漏掉的Bug越多；测试只能证明已发现的缺陷是缺陷，不能证明软件没有缺陷，因为测试是一个样本实验。
第2问的答案所呈现的底层逻辑：对所做的测试工作（包括测试目标的制定、测试分析的过程以及对应的测试设计方法）能解释清楚，而且测试不是孤立的工作，受需求（如需求模糊）、系统设计（如耦合性、复杂性）、编程（如偷偷修改代码）等影响，测试要与产品、开发等紧密合作。
第3问的答案所呈现的底层逻辑：我们可以在开发写完代码之前完成测试分析、测试计划和测试设计，但系统层次的测试执行需要等待开发完成版本构建，测试执行是后期工作，测试时间容易被开发前期工作挤掉一部分，项目的延期容易造成错觉——测试拖后腿。
测试的底层逻辑（概率思维）：测试是一个样本实验，需要精心分析和设计，努力以最小的代价并尽早地去揭示质量风险。既然是一个样本实验，缺陷的分布是正态分布的，质量可以从3sigma提升到6sigma，但永远达不到100%。