一本带有插画的软件测试书为你揭开探秘之旅

• 本书的重点不是讲解一个个已有的测试设计方法，是秉着“从实际问题出发，而不是从方法出发”的思路，站在测试分析和测试设计人员实战的角度，讲解软件测试可循的规律和方法；

• 本书旨在告诉读者：好的测试人员不是发现很多bug或使很多的开发人员感到羞辱的人；好的测试人员是促成合适的bug得以修复的人；

• 作为一本技术书，本书内容结合大量由十几位专业的插画师联合制作的插图，加上彩色的图书印刷，使其在同类书中更加突出；

• 本书由业界知名的测试专家、苹果测试总监James写序并推荐。

这本书的书名中有三个关键词，分别是：海盗派、测试分析、MFQ&PPDCS，这里简单解释下，更详细的内涵，就要等您阅读这本书了。

关键词一：海盗派

海盗派Testers是这样一群测试人员：

• 他们持有相同的测试理念

• 他们相信测试人员是测试中的核心，高于测试流程和测试工具

• 他们努力磨炼自己的测试匠艺，提升自己的测试技能

  ......

如何识别一个海盗派的Tester呢？

关键词二：测试分析

本书的 5 个主体章节是：

第01章　了解测试任务（KYM）

第02章　测试覆盖大纲（TCO）

第03章　建模（Modeling）

第04章　测试设计（TD）

第05章　测试执行（TE）

这是一本关于测试分析的书，前面几个主体章节包括KYM、TCO、Modeling都是讲如何做测试分析，之后的一章是测试设计，最后在测试执行这章，会聊一些测试执行与测试分析关系的话题。

阅读这本书，学习测试分析，就像经历一场爬山一样，只要您有足够的勇气和毅力，再加上一点好奇心，一定可以顺利登顶！

关键词三：MFQ&PPDCS

海盗派的Tester究竟是怎么做测试分析的？

他们有一样法宝叫做MFQ&PPDCS，这是一套测试分析框架（Framework），这个框架包含KYM、TCO、MFQ、PPDCS这四大组成部分。

MFQ体现了从测试角度分析一个被测对象时 3 个主要维度，分别是：被测对象由哪些单功能组成（MD）、功能之间由哪些复杂的功能交互点值得测试（FI），以及需要关注哪些非功能的质量属性方面的测试（QC）。

针对M部分，PPDCS提供了一个“选择合适的模型对单功能建模”的思路，每个字母分别代表了一种模型特征。

提起MFQ&PPDCS的起源，故事要追溯到 2008 年。

2008 年，是作者在华为公司做软件测试的第 8 个年头，也是从“负责某个具体特性的功能测试”到“负责整个部门的测试技能提升”工作转型后的第二年，当时她正在参与一个测试过程改进项目。所谓的测试过程改进，简单点讲，就是找到当前测试工作中的薄弱点、寻求改进措施、开展改进实施和跟踪等。作者当时敏锐地感觉到测试设计是一个值得改进的工作方向（当时还不知道测试分析与测试设计的区别），于是主动请缨，开始了测试设计改进的探索之旅。

作者分析现有特性的测试设计文档，访谈开发人员、测试人员和项目管理人员，收集大家在测试设计中遇到的各种疑惑和问题等，学习业界测试设计方法，阅读测试设计相关书籍和文章，最终写出了一份叫做《Test Design Problems Investigation》（测试设计问题调查）的调查报告。其中谈到了测试设计中比较突出的两个问题：一个问题是，薄弱的单功能测试分析，测试人员没有将一个被测对象细分成不同的部分单独进行测试，只是针对这个被测对象整体的一些功能和非功能属性进行了测试，MFQ的提出就是为了解决这个问题；另外一个问题是，已有的测试设计技术并没有得到系统地使用，PPDCS的提出正是为了解决这个问题。

任何一个被测对象，无论是一个特性还是一个系统，都是结构化的。每一个“整体”的被测对象都可以被划分成多个“部分”，每一个“部分”承担着一定的功能，作者把这个可以单独对其进行测试的“部分”称为“单功能”，由于经常用模型对单功能建模开展测试分析，所以，又称为“基于模型的单功能”，可以用MD简化表示，熟悉MFQ的人干脆就用一个字母M来表示了；此外，单功能和单功能之间、整个特性/系统与其他特性/系统之间可能存在着一些需要测试的交互的点，这个称为“功能交互”，可以用FI表示，更简单一点的话，就用一个字母F来表示；针对某个单功能或者整个特性/系统，有些非功能的“质量属性”需要测试，同样，本书也把QC用一个字母Q来简化表示。

作者在做测试设计调查时发现，很多特性考虑了特性整体上的一些功能点的测试（F）、该特性与其他特性之间交互的测试（F），以及一些非功能的测试（Q），却很少考虑M的测试，也就是说，没有把该特性划分成多个单功能，然后针对每个单功能进行测试。这就好像是有一幢大楼，所有人都在关注楼的外观是否美观大方、整体楼的质量是否安全可靠、每一层楼的结构是否合理等，却鲜有人问津每一个房间的质量如何，甚至是每一块砖的质量如何一样。当然，M和F、部分与整体的概念是相对的，您可以在TCO这章获取更多这方面的信息。

在调查中也发现，很多test ideas的得出是通过“拍脑袋”的方法，而测试行业发展半个多世纪以来，十几种，甚至几十种测试设计技术并未被系统而广泛地使用。是什么原因呢？是这些技术只是停留在理论层面，在实践中并无用武之地？抑或是我们的产品太特殊了，这些技术都不大适合？还是测试人员都没有听过或学过这些方法，不会使用？还是有其他的什么原因？

作者挑选了十几种常用的测试设计技术，包括等价类、边界值、判定表、因果图等，对每一种方法进行学习、练习、分析其特点；然后随机挑选了产品中的一些特性，尝试着使用 2 种到 3 种测试设计技术对其分析和建模，对比孰优孰劣。几个月的摸索后，一个念头在作者的脑海中若隐若现，被测对象和测试设计技术，就像两个互相啮合的齿轮，选用哪一种测试设计技术对某个具体的被测对象进行建模分析，一定是有某个因素起了关键的作用，才使得两个齿轮可以很好地咬合在一起，是什么关键因素呢？

在一次次的尝试和思考中，某种规律性的东西渐渐浮出了水面：仔细研究这些基本的测试设计技术，发现它们大体上可以归为几大类别，每一类别有其独特的“特征”；而研究被测对象的规格描述文档时，发现被测对象的内部逻辑也可以抽象出某种“特征”来表达；那么，当这两种“特征”吻合时，就可以用这种测试设计技术来分析这个被测对象了，PPDCS的想法因此应运而生，每一个字母分别代表一种“特征”的英文首字母缩写。您可以在建模（Modeling）这章了解更多关于PPDCS的信息。

本书的作者邰晓梅，她是一名独立软件测试顾问，一个海盗派的Software Tester，一个热爱学习的Learning Geeker，一个随手涂鸦的Fresh Doodler。她提倡测试应该以tester为中心，将测试当作一门匠艺，不拘泥于外在形式，不断提升个人的测试思维和测试技能，尽可能低成本而高效地把测试做好。 

对于那些软件测试从业者，或者对如何分析一个事务感兴趣的非软件测试人员，他们有系统地学习软件测试分析技能，或者了解软件测试分析这件事的需要。这本书正是为他们而写。

之所以将读者群定位为“软件测试从业者”而不是“软件测试分析人员”，有两个原因。

原因一：书中谈到的软件测试技能是普适性的

普适性的测试技能，不仅仅对从事软件测试分析工作的人有益。也可以反过来说，学会从测试的角度分析一个被测对象，是每一个测试从业者的必备技能。

原因二：作者并不赞同设置“软件测试分析员”这样一个专属岗位

“软件测试分析员”和“测试执行人员”这种岗位的划分比较容易促成测试分析设计与测试执行的分离，“软件测试分析员”极少再去做测试执行了，因为这不属于他们的工作范畴；“软件测试执行人员”也较少有机会去做测试分析和测试设计的工作。

“测试分析与测试设计”和“测试执行”属于软件测试的基本活动，但没有人规定一定要串行地、顺序地、按阶段来执行这些活动，更不必人为地划分成“某些人仅可以从事某一类测试活动”。实际上，这两类活动是如此地紧密关联，只有两者相互呼应、频繁反馈、互相配合，才能相得益彰，取得最佳效果，正如James Bach所说：“试图把一个综合的认知活动分成两部分，还单独运作得很好，这是很难的。”

本书所适合的读者群“软件测试从业者”，不仅无需从测试岗位划分，也无需从测试执行的方式来区分，无论您是手工测试人员还是自动化测试人员，相信书中谈到的诸多测试技能也会对您的工作有益；更不必从测试经验的多寡来区分，无论您是刚刚进入测试行业的新手，还是已经从事软件测试十几年的老兵，书中定有或多或少的观点带给您启发。当然，不同的人阅读本书的收获和启发会有所不同，本书脚注中罗列了很多相关的参考学习资源，如果您愿意探查下去、顺藤摸瓜，一定可以最大程度地挖掘本书的价值。

如果您不是一个软件测试从业者，比如您是软件开发人员，或者是产品需求分析人员，或者您并不是IT从业人员，只要您对“如何分析一个事务感兴趣”，也可以翻翻这本书。

在当前信息多元化的世界，很多创新思想来源于“跨界”的行为。Steven Johnson曾研究一系列不断重复出现的创新发明的共有特点和发展模式，“创新就是一扇扇不断打开的门”，他提出的一个很重要的创新模式就是“相邻可能（adjacent possible）”。当我们经常勇于跨越一步，踏出我们熟悉的领域边界，常会发现，在另一个相邻的领域内，有很多问题、思想、理念和知识是相通的，就好像主动打开了一扇门，为探索新的“相邻可能”提供了条件。

实际上，本书中有很多小的创意思想就是作者在阅读非测试理论书籍时受启发而想到的。

比如本书的 5 个主体章节的划分是受一本叫做《Adventures in Experience Design》的书的影响。作者将用户体验设计的过程用 5 个S来表示（Sponge、Spark、Splatter、Sculpt、Storytell），而这 5 个S又是受到软件开发生命周期5个D（Discover、Define、Design、Develop、Deploy）的启发而来的。

再比如，书中谈到的“Curation and Subtraction Heuristic（过滤与剔除启发式方法）”是借鉴于涂鸦领域的一本书《The Doodle Revolution》。对于一个Infodoodler而言，经常需要从一大堆文字或现场的演讲或讨论中，快速地，甚至是实时地提取出关键信息，然后将其可视化出来，这与测试人员要具备的信息的快速提取与展示是何等相像。

所以，期待这本讲述软件测试分析的书对部分非软件测试从业人员也有一定的借鉴作用：

• 如果您是做“软件分析”，可以重点参考前面几章“KYM”“TCO”和“建模”；

• 如果您是软件项目的管理者，可以重点参考“KYM”“TCO”和“测试执行（TE）”章节，了解其他章节；

• 如果您所从事的行业需要快速提取关键信息并进行结构化呈现，“KYM”和“TCO”章节可供参考；

• 如果您对“用简单的图形化模型表达一个复杂的逻辑思想”感兴趣，可以参考“建模”这章。

这本书以测试分析为核心内容、以MFQ&PPDCS为实施框架来撰写，系统地阐述了测试分析这件事涉及的方方面面的测试技能，并辅以大量的实践案。

刚做测试那几年，作者并没有区分“测试分析”与“测试设计”有什么不同，甚至极少提到“测试分析”这个词，更多谈到的是“测试设计”，感觉测试设计是一个比较模糊的过程：输入是需求，然后经过测试设计这么一个神奇的黑盒子后，测试实例就出来了。实际上，就像开发人员不会拿到需求直接写出代码，而是中间经过了一系列的需求分析、功能设计、技术设计等过程（在敏捷项目中，这些过程短而迅速），然后才编写具体的代码一样，测试人员也需要经过一个“系统化的、增量的、分析的过程”，然后再开展测试，设计出具体的测试实例。

我们通常所说的“测试分析与设计”，在某种程度上，将“测试分析”与“测试设计”混淆在一起了，将二者的区别模糊化，或者说，没有强调“测试分析”的重要地位。作者在做上述的测试设计问题调查时，恰巧读到Mike Smith的一篇文章，发现他们的观点不谋而合。Mike Smith希望人们不要笼统地说“测试分析与设计”，而是要表达为“测试分析与测试设计”，因为“测试分析”与“测试设计”是两个不同的测试活动。他认为“Test Analysis”是个“What Issue”- What are the measures & targets of success for testing？（测试成功的目标和标准是什么？），“Test Design”是个“How Issue”- How will those measures and targets be achieved？（这些目标和标准如何达成？）。

与此类似的观点还有TorbjÖrn Ryber，作者在 2008 年初有幸参加了TorbjÖrn Ryber的测试分析与测试设计课程，课程中极大地感受到他对测试分析过程的重视。TorbjÖrn Ryber喜欢把测试的过程看作是一个问题的过程，具体地说，“测试分析”可以对应为“How Issue”- How do I ask questions? （我怎么问问题？），“测试设计”可以对应为“What Issue”- What questions do I ask?（我应该问什么问题？）。

“KYM”“TCO”“Modeling”这几章谈的都是关于“测试分析”的问题，“TD”这章重点谈“测试设计”。

做好测试分析需要很多技能，下图列出了部分测试技能，本书都会谈到。

揭开探秘之旅

Adventures in Testing Analysis

读到这里，您是否已经准备好踏上这个关于测试分析的探险旅程了呢？这一路，我们会经历5个探险点：KYM、TCO、Modeling、TD和TE。如前所述，这5个点的设置也是受《Adventures in Experience Design》的影响，书中提到软件开发生命周期可以表示为 5 个D：Discover、Define、Design、Develop、Deploy。

（点击图片，查看全书）