原创 Test Ninja 软件质量报道 2021-12-08 07:55

什么是底层逻辑？

按照刘润老师的解释就是：

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

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

......

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

他还说：“只有底层逻辑，才是有生命力的，”

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

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

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

在我写的《全程软件测验（第3版）》第1章中，深度讨论了对软件测验的认知，

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

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

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

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

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

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

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

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

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

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

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

2. 软件测验的底层逻辑

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

1. 为什么测？

2. 测什么？

3. 如何测？

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

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

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

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

3. 如何测？就是找到获取被测物件的质量资料的方式、方法或手段，包括测验方案设计、场景设计、测验用例或测验资料等的设计，

也就是 For Quality, from Quality objectives and by getting Quality data (为了质量而测，从质量目标出发、想方设法获取质量信息），

之前也写过一篇文章：软件测验灵魂三问，如何怼回去？ 对文中“灵魂三问”的回答，是不是也体现了软件测验的底层逻辑？

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

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

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

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

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

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

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

测验的底层逻辑（概率思维）：测验是一个样本实验，需要精心分析和设计，努力以最小的代价并尽早地去揭示质量风险，既然是一个样本实验，缺陷的分布是正态分布的，质量可以从3sigma提升到6sigma，但永远达不到100%，

3. 测验流程的底层逻辑

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

测验流程的另一个底层逻辑：形成倍训，如果经过评估，发现测验程序有问题，需要重新分析、修改计划、修改设计......再经过一个完整的程序，构成一个新的倍训，从测验流程改进来看，也需要构成PDCA那样的倍训，从今天DevOps的角度看，测验是为了让用户更满意，但同时要进行用户调查，收集用户反馈，构成倍训，如我16年前所画的倍训，

从缺陷带来的成本来看，测验进行的越早越好，因为劣质成本是指数级增长，

概括起来：测验是贯穿整个研发周期，形成倍训，并持续改进，

4. 测验分析的底层逻辑

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

系统思维可以让我们看清楚被测物件的输入/输出、前置条件和后置条件、周围环境和面临的各种场景，

结构化思维帮助我们制定更有效的测验方案和测验策略，如分层测验、面向界面的测验等，同时，测验总是有风险的，所以测验分析时一定要采用基于风险的测验策略，并应用80/20原则，确定20%最严重的风险集中在什么地方、哪些功能是用户最常用的20%功能、哪些测验项是属于重点测验的20%等，

参考之前写的文章：

• 测无定法，测必有法：测验策略运用之道

• 软件测验的结构化思维（上）

• 软件测验的结构化思维（下）

• 看家本领之一：软件测验的系统性思维

• 看家本领之二：软件测验的分析性思维

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

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

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

5. 测验设计的底层逻辑

测验设计是基于测验分析的结果，运用合适的方法完成测验资料、测验场景或测验用例的设计，按照工程思维的方式，解决方案不只一个，要设计多个方案，从中选出更优或最优的方案，

测验设计的本质是以更有效的方式覆写测验需求，从场景覆写、逻辑覆写、路径覆写和资料覆写等不同覆写策略中选择一种或几种，测验设计也是一个循序渐进的程序，不断完善的程序，

测验设计是辩证统一的思维程序，既有严密的逻辑思维，也有跳跃式、发散性的创造性思维；既是黑盒测验方法和白盒测验方法的对立统一、静态测验和动态测验的融合，也是主动测验和被动测验的融合......只有这样才能更彻底地满足设计要求，更快地完成测验以实作测验目标，

测验设计的底层逻辑：测验设计是艺术，更要创新、融合，

6. 测验自动化的底层逻辑

测验自动化就是要充分发挥工具的作用或价值，例如工具能百分之百地执行命令、任劳任怨，所以自动化测验适合机械、单调的测验作业，如回归测验、性能负载测验、压力测验、兼容性测验、BVT（版本构建验证测验）等，

测验自动化的脚本开发和执行是建立在测验分析和设计之上，如果测验分析和设计存在问题，依靠工具是无法解决这类问题的，有更好的测验分析和设计，才有更好的自动化测验，所以我们清楚测验分析/设计与自动化测验的关系显得非常重要，

工具的开发和使用、脚本的开发和使用都是由人完成的，所以人还是第一位的，工具是第二位的，测验自动化还受到文化、流程的影响，测验自动化能否成功不是一个技术问题，今天来看，技术上已经没有障碍了，障碍往往出现在企业的文化、研发流程和开发质量（如软件实作的规范性、可测验性等）等方面，

测验自动化的底层逻辑之一：工具重要，但人才是决定的因素；

测验自动化的底层逻辑之二：自动化测验是建立在测验分析与设计的基础之上；

测验自动化的底层逻辑之三：一切适合自动化的测验作业都尽可能地被自动化，同时要创造有利于自动化测验的环境，

7. 测验人员的底层逻辑

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

之前写过几篇文章，讨论测验人员如何学习、如何反思和如何成长：

• 从对人负责的角度，重新理解软件测验

• 抛砖引玉，讨论如何更好地为测验而学

• 看家本领之三：软件测验的批判性思维

• 读了这篇文章，受益终身：敏捷测验思维模式

• 我见过最大的世面，是2013年负债1万去上海听了一场雅尼的音乐会

• 只要坚信自己，任何目标都是能实作的

• 【软件测验能力图谱】升级版

• 软件测验人员迷茫之中如何找到职业发展的方向？

• 永远无法改变别人、只能改变自己：持续学习是最好的途径

如果我们掌握了软件测验的底层逻辑，只有探寻到万变中的不变，才能动态地、持续地看清软件测验的本质，看清软件测验的底牌，我们就能始终如鱼得水，

测验人员的底层逻辑：只要你持续地学习与反思，没有人能够挡得住你成长为测验专家，

结论

软件测验的底层逻辑是：尽早尽快地获取必要的质量信息、揭示质量风险，

为此，延伸出来的软件测验底层逻辑有：

• 贯穿整个研发周期，形成倍训，并持续改进测验流程

• 基于风险的测验策略是必不可少的

• 以终为始、系统地分析测验需求，在资源和测验目标之间寻求平衡

• 测验设计是艺术，更要创新、融合

• 在分析和设计的基础上，尽可能地实作自动化测验

• 讲好测验故事，和各方一致、协同作业