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

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

什么是底层逻辑？
 

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

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

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

...... 

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

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

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

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

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

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

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

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

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

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

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

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

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

Based on these cognitions of software testing, I will use one sentence to explain the basic cognition of software testing, that is: based on the understanding of the real needs of users, obtain real and all-round quality information of software products through various means . Whether it is to verify whether the software functional characteristics meet the requirements, evaluate the quality of the product, or reveal the quality risk of the product, the judgment is made based on the obtained real quality information about the product, and the defect can be regarded as a by-product of this activity process. .

• Here the understanding of the real needs of users is emphasized. On the one hand, it reflects "there is no quality without users, and quality exists relative to users". We must complete the test from the perspective of users. On the other hand, it is the real needs of users, not false and wrong The needs of the business, the needs of the business must eventually be decomposed into the needs of the user role, and the functional/non-functional requirements of the system are also to meet the needs of the users.

• The "software product" mentioned here is not limited to programs, but also includes data, requirements documents, design documents, codes, user manuals, technical manuals, etc.

After understanding "what is software testing", the underlying logic of software testing can be discussed below.

2. The underlying logic of software testing

The underlying logic of software testing can be summarized as answers to three questions:

1. Why measure?

2. What to measure?

3. How to measure?

And in the process of answering these three questions, it is necessary to be able to adapt to different test objects (such as Windows/MacOS native applications, web software, mobile apps, embedded software), different test types (such as functional testing, performance testing, security testing, etc.) test, compatibility test, etc.), different test levels (such as unit test, integration test, system test, etc.), different teams and different products, etc., have become universal answers. Although the context is different, there will be different testing methods, techniques and practices, but we can abstract their common ground.

Based on this consideration, let’s answer these three basic questions:

1. Why measure? As long as the work is done by humans, it cannot be guaranteed to be foolproof, and there will be problems. If the software goes out with problems, it is very likely to bring losses to customers or make customers dissatisfied, which will eventually damage the interests of the enterprise. Numerous quality accidents in the past have also proved this point. Before delivery to customers, software needs to be fully tested, otherwise the consequences will be serious.

2. What to measure? It depends on the delivered quality goal, that is, starting from the quality goal, carrying out goal decomposition, and then determining the quality data about the measured object to be obtained for each special sub-goal, so as to determine its test scope or test items. If we go one step further, we determine the priority of test items according to the user's different feelings about quality characteristics and functional characteristics. This part belongs to the work of test analysis and deals with test risk and test strategy.

3. How to measure? It is to find the way, method or means to obtain the quality data of the object under test, including the design of test scheme design, scene design, test case or test data, etc.

That is,  For Quality, from Quality  objectives and  by  getting  Quality  data  (measure for quality, start from quality objectives, and find ways to obtain quality information).

I also wrote an article before: Three questions about the soul of software testing, how to get back? Does the answer to the " Three Questions of the Soul "  in the article also reflect the underlying logic of software testing?

Question 1 : Why can't this bug be tested?

Question 2 : How is the test measured? Will it be tested?

Question 3 : Test quickly! Why do the tests always lag behind and report bugs at the end?

In fact, it also reflects another layer of logic of "software testing", namely:

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万去上海听了一场雅尼的音乐会

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

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

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

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

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

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

结论

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

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

• 贯穿整个研发周期，形成闭环，并持续改进测试流程

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

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

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

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

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