软件测试的底层逻辑是什么？
原创 Test Ninja 软件质量报道 2021-12-08 07:55
什么是底层逻辑？
按照刘润老师的解释就是：
“事物间的共同点，就是底层逻辑。
只有不同之中的相同之处、变化背后不变的东西，才是底层逻辑。
......
底层逻辑+环境变量 = 方法论”
他还说：“只有底层逻辑，才是有生命力的。”
所以我们要来探讨一下：软件测试的底层逻辑是什么？
1. 对软件测试的基本认知
对软件测试的基本认知，使我们达成共识，从而基于这个共识，更容易去讨论软件测试的底层逻辑。对软件测试的基本认知，需要精简到一句话来描述，即抓住软件测试的本质，以简洁的方式描述正确的软件测试价值观，但不是某个人的软件测试价值观，而是能被大多数人接受的软件测试价值观。
在我写的《全程软件测试（第3版）》第1章中，深度讨论了对软件测试的认知，
-
软件测试是验证软件功能特性是否满足需求；
-
软件测试就是发现软件中存在的缺陷
-
软件测试包含了静态测试——需求、设计、代码的评审活动
-
软件测试是系统、完整地评估软件产品质量，提供质量信息
-
软件测试是暴露、揭示产品质量风险
-
软件测试不仅是技术性活动，而且是社会性、心理等多方面的综合性活动。
-
软件测试是通过投入质量保障性成本来极大地减少劣质成本
根据这些对软件测试的认知，用一句话来说明软件测试的基本认知，那就是：基于对用户真实需求的理解，通过各种手段获得软件产品真实的、全方位的质量信息。无论是验证软件功能特性是否满足需求、评估产品的质量还是揭示产品的质量风险，都是基于获得的有关产品的真实的质量信息做出判断的，而缺陷可以看做是这个活动过程中的副产品。
-
这里强调对用户真实需求的理解，一方面体现“没有用户就没有质量，质量相对用户而存在”，我们必须从用户角度出发来完成测试，另方面是用户的真实需求，而不是虚假的、错误的需求，业务的需求最终要分解成用户角色的需求，而系统的功能/非功能性需求也是为了满足用户的需求。
-
这里提到的“软件产品”不局限于程序，还包括数据、需求文档、设计文档、代码、用户手册、技术手册等。
了解了“什么是软件测试”之后，下面就可以讨论软件测试的底层逻辑。
2. 软件测试的底层逻辑
软件测试的底层逻辑可以概括为三个问题的回答：
-
为什么测？
-
测什么？
-
如何测？
而且在回答这三个问题的过程中，要能适应不同的测试对象（如Windows/MacOS native应用、 web软件、移动app、嵌入式软件 ）、不同的测试类型（如功能测试、性能测试、安全性测试、兼容性测试等）、不同的测试层次（如单元测试、集成测试、系统测试等）、不同的团队和不同的产品等，成为放之四海而皆准的答案。虽然上下文不同，会有不同的测试方法、技术和实践，但我们能抽象出它们的共同点。
基于这样的考虑，那下面就来回答这三个基本问题：
-
为什么测？只要是人做的工作，就不能保证万无一失，会存在问题。如果软件带着问题出去，就很有可能给客户带来损失或让客户不满意，最终导致企业的利益受损。过去无数的质量事故，也证明了这一点，在交付给客户之前，软件需要得到充分的测试，否则后果严重。
-
测什么？取决于交付的质量目标，即从质量目标出发，进行目标分解，然后针对每一个特地的子目标来确定要获得的有关被测对象的质量数据，从而确定其测试范围或测试项。如果再进一步，我们根据用户对质量特性、功能特性的感受不同来决定测试项的优先级。这部分属于测试分析的工作，并涉及测试风险和测试策略。
-
如何测？就是找到获取被测对象的质量数据的方式、方法或手段，包括测试方案设计、场景设计、测试用例或测试数据等的设计。
也就是 For Quality, from Quality objectives and by getting Quality data (为了质量而测，从质量目标出发、想方设法获取质量信息）。
之前也写过一篇文章：软件测试灵魂三问，如何怼回去？ 对文中“灵魂三问”的回答，是不是也体现了软件测试的底层逻辑？
第 1 问：为什么这个 Bug 测不出来？
第 2 问：测试怎么测得？到底会不会测？
第 3 问：测试快点啊！为什么总是测试拖后腿，最后才报 Bug？
其实也体现了“软件测试”的另一层逻辑，即：
-
第1问的答案所呈现的底层逻辑：测试是不能穷尽的，测试总是有风险的，而且开发写出的Bug越多，测试漏掉的Bug越多；测试只能证明已发现的缺陷是缺陷，不能证明软件没有缺陷，因为测试是一个样本实验。
-
第2问的答案所呈现的底层逻辑：对所做的测试工作（包括测试目标的制定、测试分析的过程以及对应的测试设计方法）能解释清楚，而且测试不是孤立的工作，受需求（如需求模糊）、系统设计（如耦合性、复杂性）、编程（如偷偷修改代码）等影响，测试要与产品、开发等紧密合作。
-
第3问的答案所呈现的底层逻辑：我们可以在开发写完代码之前完成测试分析、测试计划和测试设计，但系统层次的测试执行需要等待开发完成版本构建，测试执行是后期工作，测试时间容易被开发前期工作挤掉一部分，项目的延期容易造成错觉——测试拖后腿。
测试的底层逻辑（概率思维）：测试是一个样本实验，需要精心分析和设计，努力以最小的代价并尽早地去揭示质量风险。既然是一个样本实验，缺陷的分布是正态分布的，质量可以从3sigma提升到6sigma，但永远达不到100%。
3. 测试流程的底层逻辑
测试流程符合一般工程项目流程，经过分析、计划、设计、实施和评估的过程，任何一个环节不可缺失，每一个环节都重要，但前面的环节会影响后面的环节，所以越在前面的环节越重要。测试分析是基础，依次是设计、实施和评估，构成一个金字塔模型。
测试流程的另一个底层逻辑：形成闭环。如果经过评估，发现测试过程有问题，需要重新分析、修改计划、修改设计......再经过一个完整的过程，构成一个新的闭环。从测试流程改进来看，也需要构成PDCA那样的闭环。从今天DevOps的角度看，测试是为了让用户更满意，但同时要进行用户调查，收集用户反馈，构成闭环，如我16年前所画的闭环。
从缺陷带来的成本来看，测试进行的越早越好，因为劣质成本是指数级增长。
概括起来：测试是贯穿整个研发周期，形成闭环，并持续改进。
4. 测试分析的底层逻辑
测试分析的底层逻辑是基于系统思维、结构化思维去思考，需要从项目背景、产品结构、质量要求等各个方面进行系统地思考，不容忽视一些蛛丝马迹，顺藤摸瓜，完整地呈现测试范围，识别出各种测试风险，最终明确测试项及其优先级。
系统思维可以让我们看清楚被测对象的输入/输出、前置条件和后置条件、周围环境和面临的各种场景。
结构化思维帮助我们制定更有效的测试方案和测试策略，如分层测试、面向接口的测试等。同时，测试总是有风险的，所以测试分析时一定要采用基于风险的测试策略，并应用80/20原则，确定20%最严重的风险集中在什么地方、哪些功能是用户最常用的20%功能、哪些测试项是属于重点测试的20%等。
参考之前写的文章：
测试分析的底层逻辑之一：测试分析是层层剥离、逐步深入的系统分析过程。从业务需求、用户行为、系统功能、应用场景等不同维度对被测对象进行系统的分析，最终确定测什么。
测试分析的底层逻辑之二：测试分析也是一个博弈、选择直至平衡的过程，需要定力和洞察力，做出取舍，如运用80/20原则，抓主要风险，有时需要舍弃一些次要风险。
测试分析的底层逻辑之三：以终为始，从测试目标出发最终回到测试目标，如从考虑如何衡量测试充分性的要求出发，最终分析的结果——各测试项完成是能够满足测试充分性的要求的。
5. 测试设计的底层逻辑
测试设计是基于测试分析的结果，运用合适的方法完成测试数据、测试场景或测试用例的设计。按照工程思维的方式，解决方案不只一个，要设计多个方案，从中选出更优或最优的方案。
测试设计的本质是以更有效的方式覆盖测试需求，从场景覆盖、逻辑覆盖、路径覆盖和数据覆盖等不同覆盖策略中选择一种或几种。测试设计也是一个循序渐进的过程，不断完善的过程。
测试设计是辩证统一的思维过程，既有严密的逻辑思维，也有跳跃式、发散性的创造性思维；既是黑盒测试方法和白盒测试方法的对立统一、静态测试和动态测试的融合，也是主动测试和被动测试的融合......只有这样才能更彻底地满足设计要求，更快地完成测试以实现测试目标。
测试设计的底层逻辑：测试设计是艺术，更要创新、融合。
6. 测试自动化的底层逻辑
测试自动化就是要充分发挥工具的作用或价值，例如工具能百分之百地执行命令、任劳任怨，所以自动化测试适合机械、单调的测试工作，如回归测试、性能负载测试、压力测试、兼容性测试、BVT（版本构建验证测试）等。
测试自动化的脚本开发和执行是建立在测试分析和设计之上，如果测试分析和设计存在问题，依靠工具是无法解决这类问题的。有更好的测试分析和设计，才有更好的自动化测试，所以我们清楚测试分析/设计与自动化测试的关系显得非常重要。
工具的开发和使用、脚本的开发和使用都是由人完成的，所以人还是第一位的，工具是第二位的。测试自动化还受到文化、流程的影响，测试自动化能否成功不是一个技术问题，今天来看，技术上已经没有障碍了，障碍往往出现在企业的文化、研发流程和开发质量（如软件实现的规范性、可测试性等）等方面。
测试自动化的底层逻辑之一：工具重要，但人才是决定的因素；
测试自动化的底层逻辑之二：自动化测试是建立在测试分析与设计的基础之上；
测试自动化的底层逻辑之三：一切适合自动化的测试工作都尽可能地被自动化，同时要创造有利于自动化测试的环境。
7. 测试人员的底层逻辑
最后谈谈测试人员的底层逻辑。测试人员是否有价值，不取决于他/她目前的工作态度、知识与技能，而是取决于态度、知识与技能的进步速度，因为我们无法改变过去，但可以改变未来。只要持续学习、持续反思，就能快速完成自己的进化，快速成长起来，就没有人能挡得住你的壮丽前程。
之前写过几篇文章，讨论测试人员如何学习、如何反思和如何成长：
如果我们掌握了软件测试的底层逻辑，只有探寻到万变中的不变，才能动态地、持续地看清软件测试的本质。看清软件测试的底牌，我们就能始终如鱼得水。
测试人员的底层逻辑：只要你持续地学习与反思，没有人能够挡得住你成长为测试专家。
结论
软件测试的底层逻辑是：尽早尽快地获取必要的质量信息、揭示质量风险。
为此，延伸出来的软件测试底层逻辑有：
-
贯穿整个研发周期，形成闭环，并持续改进测试流程
-
基于风险的测试策略是必不可少的
-
以终为始、系统地分析测试需求，在资源和测试目标之间寻求平衡
-
测试设计是艺术，更要创新、融合
-
在分析和设计的基础上，尽可能地实现自动化测试
-
讲好测试故事，和各方一致、协同工作