一本带有插画的软件测试书

悠悠小仙仙

【转】一本集插画、测试于一体的书你见过吗？推荐这本书，也是因为作者对这本书的排版、画作都亲自参与，版面精致，内容易读不乏味。本书的插画由作者、作者的宝宝以及插画师共同完成。
海盗派测试分析 MFQ&PPDCS

版式展示：






海盗派Testers是这样一群测试人员：
他们持有相同的测试理念
他们相信测试人员是测试中的核心，高于测试流程和测试工具
他们努力磨炼自己的测试匠艺，提升自己的测试技能
本书的愿景阐述为：
对于（那些软件测试从业者，或者对如何分析一个事务感兴趣的非软件测试人员）；
他们有（系统地学习软件测试分析技能，或者了解软件测试分析这件事）的需要；
这本《海盗派测试分析：MFQ&PPDCS》是一本（以测试分析为核心内容、以MFQ&PPDCS为实施框架的书）。
本书（系统地阐述了测试分析这件事涉及的方方面面的测试技能，并辅以大量的实践案例），
与（市面上大多数讲解测试设计的书）不同，
本书（的重点不是讲解一个个已有的测试设计方法，而是秉着“从实际问题出发，而不是从方法出发”的思路，从测试分析和测试设计人员的角度出发，当接手一个新的被测系统或被测特性的时候，如何运用各种测试技能，一步步地分析被测对象 ，最终成功地完成测试任务）。
读本书之前，了解如下六个问题，它将告诉你要不要选择
问题1：为什么适合的读者群是“软件测试从业者”？
对于（那些软件测试从业者，或者对如何分析一个事务感兴趣的非软件测试人员），
他们有（系统地学习软件测试分析技能，或者了解软件测试分析这件事）的需要。
之所以将读者群定位为“软件测试从业者”而不是“软件测试分析人员[4]”，有两个原因。
原因一：书中谈到的软件测试技能是普适性的
普适性的测试技能，不仅仅对从事软件测试分析工作的人有益。也可以反过来说，学会从测试的角度分析一个被测对象，是每一个测试从业者的必备技能。
原因二：我并不赞同设置“软件测试分析员”这样一个专属岗位
“软件测试分析员”和“测试执行人员”这种岗位的划分比较容易促成测试分析设计与测试执行的分离，“软件测试分析员”极少再去做测试执行了，因为这不属于他们的工作范畴；“软件测试执行人员”也较少有机会去做测试分析和测试设计的工作。
“测试分析与测试设计”和“测试执行”属于软件测试的基本活动，但没有人规定一定要串行地、顺序地、按阶段来执行这些活动，更不必人为地划分成“某些人仅可以从事某一类测试活动”。实际上，这两类活动是如此地紧密关联，只有两者相互呼应、频繁反馈、互相配合，才能相得益彰，取得最佳效果，正如James Bach所说：“试图把一个综合的认知活动分成两部分，还单独运作得很好，这是很难的。[6 ]”
本书所适合的读者群“软件测试从业者”，不仅无需从测试岗位划分，也无需从测试执行的方式来区分，无论您是手工测试人员还是自动化测试人员，相信书中谈到的诸多测试技能也会对您的工作有益；更不必从测试经验的多寡来区分，无论您是刚刚进入测试行业的新手，还是已经从事软件测试十几年的老兵，书中定有或多或少的观点带给您启发，这一点已经在我的“MFQ&PPDCS：软件测试分析与测试设计”线下培训课程中被验证过多次了。当然，不同的人阅读本书的收获和启发会有所不同，本书脚注中罗列了很多相关的参考学习资源，如果您愿意探查下去、顺藤摸瓜，一定可以最大程度地挖掘本书的价值。
问题2：为什么也适合“对分析一个事务感兴趣的非测试人员”？
对于（那些软件测试从业者，或者对如何分析一个事务感兴趣的非软件测试人员），
他们有（系统地学习软件测试分析技能，或者了解软件测试分析这件事）的需要。
如果您不是一个软件测试从业者，比如您是软件开发人员，或者是产品需求分析人员，或者您并不是IT从业人员，只要您对“如何分析一个事务感兴趣”，也可以翻翻这本书。
在当前信息多元化的世界，很多创新思想来源于“跨界”的行为。Steven Johnson[7]曾研究一系列不断重复出现的创新发明的共有特点和发展模式，“创新就是一扇扇不断打开的门”，他提出的一个很重要的创新模式就是“相邻可能（adjacent possible）”。当我们经常勇于跨越一步，踏出我们熟悉的领域边界，常会发现，在另一个相邻的领域内，有很多问题、思想、理念和知识是相通的，就好像主动打开了一扇门，为探索新的“相邻可能”提供了条件。
实际上，本书中有很多小的创意思想就是我在阅读非测试理论书籍时受启发而想到的。
比如本书的5个主体章节“KYM”“TCO”[8 ]“Modeling（建模）”“TD（Test Design测试设计）”“TE（Test Execution测试执行）”的划分是受《Adventures in Experience Design》[9]这本书的影响，作者将用户体验设计的过程用5个S来表示（Sponge、Spark、Splatter、Sculpt、Storytell），而这5个S又是受到软件开发生命周期5个D（Discover、Define、Design、Develop、Deploy）的启发而来的。
再比如，书中谈到的“Curation and Subtraction Heuristic（过滤与剔除启发式方法）”是借鉴于涂鸦领域的一本书《The Doodle Revolution》[10]，对于一个Infodoodler而言，经常需要从一大堆文字或现场的演讲或讨论中，快速地，甚至是实时地提取出关键信息，然后将其可视化出来，这与测试人员要具备的信息的快速提取与展示是何等相像。
所以，期待这本讲述软件测试分析的书对部分非软件测试从业人员也有一定的借鉴作用：
如果您是做“软件分析”，可以重点参考前面几章“KYM”“TCO”和“建模（Modeling）”；
如果您是软件项目的管理者，可以重点参考“KYM”“TCO”和“测试执行（TE）”章节，了解其他章节；
如果您所从事的行业需要快速提取关键信息并进行结构化呈现，“KYM”和“TCO”章节可供参考；
如果您对“用简单的图形化模型表达一个复杂的逻辑思想”感兴趣，可以参考“建模”这章。
问题3：MFQ&PPDCS是什么？
这本《海盗派测试分析：MFQ&PPDCS》是一本（以测试分析为核心内容、以MFQ&PPDCS为实施框架的书）；
该书（系统地阐述了测试分析这件事涉及的方方面面的测试技能，并辅以大量的实践案例）。
MFQ体现了从测试角度分析一个被测对象时3个主要维度：被测对象由哪些单功能组成（MD）、功能之间由哪些复杂的功能交互点值得测试（FI），以及需要关注哪些非功能的质量属性方面的测试（QC）[11]。
针对M部分，PPDCS提供了一个“选择合适的模型对单功能建模”的思路，每个字母分别代表了一种模型特征。
提起MFQ&PPDCS的起源，故事要追溯到2008年。
2008年，是我在华为公司做软件测试的第8个年头，也是从“负责某个具体特性的功能测试”到“负责整个部门的测试技能提升”工作转型后的第二年，当时正在参与一个测试过程改进项目。所谓的测试过程改进，简单点讲，就是找到当前测试工作中的薄弱点、寻求改进措施、开展改进实施和跟踪等。我当时敏锐地感觉到测试设计是一个值得改进的工作方向（当时还不知道测试分析与测试设计的区别），于是主动请缨，开始了测试设计改进的探索之旅。
我分析现有特性的测试设计文档，访谈开发人员、测试人员和项目管理人员，收集大家在测试设计中遇到的各种疑惑和问题等，学习业界测试设计方法，阅读测试设计相关书籍和文章，最终写出了一份《Test Design Problems Investigation》（测试设计问题调查）[12]的调查报告。其中谈到了测试设计中比较突出的两个问题：一个问题是，薄弱的单功能测试分析，测试人员没有将一个被测对象细分成不同的部分单独进行测试，只是针对这个被测对象整体的一些功能和非功能属性进行了测试，MFQ的提出就是为了解决这个问题；另外一个问题是，已有的测试设计技术并没有得到系统地使用，PPDCS的提出正是为了解决这个问题。
任何一个被测对象，无论是一个特性还是一个系统，都是结构化的（structured），每一个“整体”的被测对象都可以被划分成多个“部分”，每一个“部分”承担着一定的功能，我把这个可以单独对其进行测试的“部分”称为“单功能（Discrete Function）”，由于经常用模型（Model）对单功能建模开展测试分析，所以，又称为“基于模型的单功能（Model based Discrete function），可以用MD简化表示，熟悉MFQ的人干脆就用一个字母M来表示了；此外，单功能和单功能之间、整个特性/系统与其他特性/系统之间可能存在着一些需要测试的交互的点，这个称为“功能交互（Function Interaction）”，可以用FI表示，更简单一点的话，就用一个字母F来表示；针对某个单功能或者整个特性/系统，有些非功能的“质量属性（Quality Characteristic）”需要测试，同样，本书也把QC用一个字母Q来简化表示。
我在做测试设计调查时发现，很多特性考虑了特性整体上的一些功能点的测试（F）、该特性与其他特性之间交互的测试（F），以及一些非功能的测试（Q），却很少考虑M的测试，也就是说，没有把该特性划分成多个单功能，然后针对每个单功能进行测试。这就好像是有一幢大楼，所有人都在关注楼的外观是否美观大方、整体楼的质量是否安全可靠、每一层楼的结构是否合理等，却鲜有人问津每一个房间的质量如何，甚至是每一块砖的质量如何一样。当然，M和F、部分与整体的概念是相对的，您可以在TCO这章获取更多这方面的信息。
在调查中也发现，很多test ideas[13]的得出是通过“拍脑袋”的方法，而测试行业发展半个多世纪以来，十几种、甚至几十种测试设计技术并未被系统而广泛地使用。是什么原因呢？是这些技术只是停留在理论层面，在实践中并无用武之地？抑或是我们的产品太特殊了，这些技术都不大适合？还是测试人员都没有听过或学过这些方法，不会使用？还是有其他的什么原因？
我挑选了十几种常用的测试设计技术，包括等价类、边界值、判定表、因果图等，对每一种方法进行学习、练习、分析其特点；然后随机挑选了产品中的一些特性，尝试着使用2种到3种测试设计技术对其分析和建模，对比孰优孰劣。几个月的摸索后，一个念头在我的脑海中若隐若现，被测对象和测试设计技术，就像两个互相啮合的齿轮，选用哪一种测试设计技术对某个具体的被测对象进行建模分析，一定是有某个因素起了关键的作用，才使得两个齿轮可以很好地咬合在一起，是什么关键因素呢？
在一次次的尝试和思考中，某种规律性的东西渐渐浮出了水面[14]：仔细研究这些基本的测试设计技术，发现它们大体上可以归为几大类别，每一类别有其独特的“特征”；而研究被测对象的规格描述文档时，发现被测对象的内部逻辑也可以抽象出某种“特征”来表达；那么，当这两种“特征”吻合时，就可以用这种测试设计技术来分析这个被测对象了，PPDCS的想法因此应运而生，每一个字母分别代表一种“特征”的英文首字母缩写。您可以在建模（Modeling）这章了解更多关于PPDCS的信息。
问题4：测试分析与测试设计的关系？
这本《海盗派测试分析：MFQ&PPDCS》是一本（以测试分析为核心内容、以MFQ&PPDCS为实施框架的书）；
该书（系统地阐述了测试分析这件事涉及的方方面面的测试技能，并辅以大量的实践案例）。
刚做测试那几年，没有区分“测试分析”与“测试设计”有什么不同，甚至极少提到“测试分析”这个词，更多谈到的是“测试设计”，感觉测试设计是一个比较模糊的过程：输入是需求，然后经过测试设计这么一个神奇的黑盒子后，测试实例就出来了。实际上，就像开发人员不会拿到需求直接写出代码，而是中间经过了一系列的需求分析、功能设计、技术设计等过程（在敏捷项目中，这些过程短而迅速），然后才编写具体的代码一样，测试人员也需要经过一个“系统化的、增量的、分析的过程”，然后再开展测试，设计出具体的测试实例[15]。
我们通常所说的“测试分析与设计”，在某种程度上，将“测试分析”与“测试设计”混淆在一起了，将二者的区别模糊化，或者说，没有强调“测试分析”的重要地位。

做好测试分析需要很多技能，本书都会谈到。

巴黎的灯光下

好像挺有趣的样子，看着插画学起来应该挺开心的。