要不要读这本书?

我喜欢逛书店,喜欢买书,喜欢藏书。当我第一次拿到一本书,决定要不要买下它的时候,通常我会先读序言部分,所以这一部分就在于帮助您判断“要不要继续读这本书”。

T009.psd

虽然这有点类似销售人员,不过我的目的并不是将这本书“兜售”给尽可能多的读者,我是希望本部分有助于甄选出那些“适合于本书的读者(for the right readers)”。

这和做软件测试有点类似,发现bug[1 ]通常是软件测试人员干得最多的事,当测试人员向开发人员“兜售”这些bug时,并不是希望所有的bug都得以修复,对于整个项目来说,修复某些bug未必是最合适的选择,正如Cem Kaner在《Bug Advocacy》 [2]中所讲:“最好的测试人员并不是发现最多bug或使最多的开发人员感到“羞辱”的人。最好的测试人员是那些促成合适的bug得以修复的人”。(“The best tester isn’t the one who finds the most bugs or who embarrasses the most programmers. The best tester is the one who gets the right bugs fixed.”)

那么,本书是为谁而作呢?

本书的愿景

一个比较流行的阐述项目愿景的句式[3]

For (target customer)

Who (statement of the need or opportunity)

The (product name) is a (product category)

That (key benefit, compelling reason to buy)

Unlike (primary competitive alternative)

Our product (statement of primary differentiation)

本书的愿景阐述为:

对于那些软件测试从业者,或者对如何分析一个事务感兴趣的非软件测试人员);

他们有(系统地学习软件测试分析技能,或者了解软件测试分析这件事)的需要

这本《海盗派测试分析:MFQ&PPDCS》是一本(以测试分析为核心内容、以MFQ&PPDCS为实施框架的书)。

本书(系统地阐述了测试分析这件事涉及的方方面面的测试技能,并辅以大量的实践案例),

(市面上大多数讲解测试设计的书)不同

本书(的重点不是讲解一个个已有的测试设计方法,而是秉着“从实际问题出发,而不是从方法出发”的思路,从测试分析和测试设计人员的角度出发,当接手一个新的被测系统或被测特性的时候,如何运用各种测试技能,一步步地分析被测对象 ,最终成功地完成测试任务)。

我大胆猜测一下,围绕这个愿景您可能有些疑问,尤其是图中所示的6个方面,容我一一道来。

图像说明文字

六个问题

问题1:为什么适合的读者群是“软件测试从业者”?

对于(那些软件测试从业者,或者对如何分析一个事务感兴趣的非软件测试人员),

他们有(系统地学习软件测试分析技能,或者了解软件测试分析这件事)的需要。

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

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

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

原因二:我并不赞同设置“软件测试分析员”这样一个专属岗位[5]

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

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

2151.png

本书所适合的读者群“软件测试从业者”,不仅无需从测试岗位划分,也无需从测试执行的方式来区分,无论您是手工测试人员还是自动化测试人员,相信书中谈到的诸多测试技能也会对您的工作有益;更不必从测试经验的多寡来区分,无论您是刚刚进入测试行业的新手,还是已经从事软件测试十几年的老兵,书中定有或多或少的观点带给您启发,这一点已经在我的“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提供了一个“选择合适的模型对单功能建模”的思路,每个字母分别代表了一种模型特征。

1201.png

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

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

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

T026.jpg

任何一个被测对象,无论是一个特性还是一个系统,都是结构化的(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这章获取更多这方面的信息。

t011.psd

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

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

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

T028.psd

问题4:测试分析与测试设计的关系?

这本《海盗派测试分析:MFQ&PPDCS》是一本(以测试分析为核心内容、以MFQ&PPDCS为实施框架的书);

该书(系统地阐述了测试分析这件事涉及的方方面面的测试技能,并辅以大量的实践案例)。

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

我们通常所说的“测试分析与设计”,在某种程度上,将“测试分析”与“测试设计”混淆在一起了,将二者的区别模糊化,或者说,没有强调“测试分析”的重要地位。我在做上述的测试设计问题调查时,恰巧读到Mike Smith的一篇文章[16],发现我们的观点不谋而合。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喜欢把测试的过程看作是一个问题的过程[17],具体地说,“测试分析”可以对应为“How Issue”- How do I ask questions? (我怎么问问题?),“测试设计”可以对应为“What Issue”- What questions do I ask?(我应该问什么问题?)。

T012.psd

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

问题5:什么是“从实际问题出发,而不是从方法出发”的思路?

与(市面上大多数讲解测试设计的书)不同,

本书(的重点不是讲解一个个已有的测试设计方法,而是秉着“从实际问题出发,而不是从方法出发”的思路,从测试分析和测试设计人员的角度出发,当接手一个新的被测系统或被测特性的时候,如何运用各种测试技能,一步步地分析被测对象,最终成功地完成测试任务)。

除了参加TorbjÖrn Ryber的测试设计课程外,我也有幸参加过Lee Copeland[18]的测试设计课程。发现这些测试设计课程或者他们关于测试设计著作中的主体部分都是在详细地阐述一个个测试设计方法。本书的设计有所不同,本书不会详细讲解一个个具体的测试设计技术,如果读者不熟悉这些基本的测试设计技术,可以从网上以及各种书籍中获取相关知识。本书会以一个虚拟的项目“大富翁”桌游为例贯穿始终,从测试分析与测试设计人员的角度出发,当接手一个新的被测系统或被测对象的时候,如何更好地运用这些已有的测试设计方法,并结合测试人员的各种测试技能,一步步地分析被测对象,最终胜利地完成测试任务。

对于那些了解常用的测试设计技术并有过实战项目经验的人来说,阅读本书会更加容易一些。对于不了解这些测试设计技术的人,在阅读“Modeling(建模)”这一章之前,建议您先对“等价类”“边界值”“判定表”“状态图”等这些基本的测试设计技术有个大致的了解。本书虽然不会详述这些基本的测试设计技术,但会以具体的实例讲解如何运用这些成熟的测试设计技术来建模。

从实际问题出发的思路,也体现着一个重要的思想:测试是基于上下文的 [19](Testing is context driven.)。每个人接到一个测试任务的时候,所面临的问题是不同的,即测试上下文是不同的,因此应该采取不同的测试策略来应对,而测试分析与测试设计是为测试策略服务的,因此所采取的具体的测试分析与测试设计的活动也是有差别的。由于写作的需要,本书会按照一定步骤有序地讲解测试“大富翁”时的各个环节的活动,KYM、TCO、Modeling、得出Test Condition、得出Test Ideas等,但这并不意味着您在处理所面临的测试问题时也得这么做,实际上我非常鼓励您根据您当前所处的测试上下文有所取舍地应用这些内容。也就是说,虽然本书的核心在“分析建模”这4个字上,但是还有4个字也非常重要,那就是“收放自如”。

问题6:本书会谈到哪些测试技能?

与(市面上大多数讲解测试设计的书)不同,

本书(的重点不是讲解一个个已有的测试设计方法,而是秉着“从实际问题出发,而不是从方法出发”的思路,从测试分析和测试设计人员的角度出发,当接手一个新的被测系统或被测特性的时候,如何运用各种测试技能,一步步地分析被测对象,最终成功地完成测试任务)。

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

T027.psd

揭开探秘之旅

Adventures in Testing Analysis

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

测试分析与测试设计

软件开发生命周期

KYM

了解测试的用户及用户的需求

Discover

了解用户需求

TCO

大致确定测试的范围

Define

定义用户需求,大致确定系统的范围

Modeling

针对每一个测试内容,分析需要的测试点,以实现上述的测试需求

Design

开展顶层设计和底层设计,分析如何实现上述需求

TD

编写测试实例,实现测试需求

Develop

编码,实现需求

TE

发布给测试执行人员

Deploy

发布给测试和用户

准备好了吗?

我们即将开启探险之旅

图像说明文字

Know Your Mission(了解您的测试任务)


[1] 本书中会使用bug这个词笼统代表软件的缺陷,尽管也有很多其他的类似概念,如error、failure、fault、problem、defect,本书不做过多区分。按照Cem Kaner的观点,我也会尽量避免使用defect,因为defect这个词有更多法律意义上的暗示。我比较喜欢的bug的定义是James Bach和Michael Bolton给出的:“A bug is anything about the product that threatens its value(Bug就是任何削弱产品价值的东西)”。这个定义与对质量Quality的理解紧密相关,关于质量本书借用Gerald Weinberg的定义:“Quality Is Value To Some Person(质量就是对某个/些人的价值)”,因为这个定义揭示了质量最主要的一个方面,即质量是主观的,同样的产品对不同的人,质量可能是不同的。

[2] Cem Kaner, Rebecca L.Fiedler, Bug Advocacy: A BBST Workbook, 2015. Cem Kaner以前表达这句话时,后半句为:“The best tester is the one who gets the most bugs fixed”,但他发现很多tester会开始相互比较所发现的bug得以修复的数量,Cem并不建议这样做,因为“bug修复的数量”并不比“哪些bug得到了修复”来得更重要。

[3] 来源于Geoffrey Moore的书《Crossing the Chasm》。

[4] 本书中凡是提到“软件测试分析人员”时,均指的是当前正在从事软件测试分析工作的人员,而不是“软件测试分析员”这样一种特定的职位或角色。

[5] 有的企业会设置“软件测试分析员”“软件测试设计人员”或者“软件测试架构师”等类似的岗位,由富有经验的测试人员担任,其职责是专门负责产品或特性的测试设计工作,输出测试件(比如测试规格、测试实例、测试方案等)。各企业的叫法不一样,本书统称为“测试分析员”,对其中的差异不做区分。

[6] 更有甚者,有人认为“测试分析与测试设计”是个高技术含量的活儿,只有有经验的测试老手才能承担;而“测试执行”是个低技术含量的活儿,比较适合交给测试新手去做。关于这一点,如果您关注的不仅仅是“测试工作是否做了”,而是关注“测试工作是否做得好”,那么,“测试执行”所需要的技能并不亚于“测试分析与测试设计”所需要的技能,James Bach在这篇(blog http://www.satisfice.com/blog/archives/672)“Why Scripted Testing is Not for Novices”中的观点或许可以给您一些启发,您也可以在这里找到我翻译的中文版本(http://www.taixiaomei.com/tm06.php)。另外,我在我的blog里专门有一篇探讨了这个问题:“把你的测试用例当作一幅画”,网址为http://www.taixiaomei.com/tad03.php

[7] Steven Johnson,美国著名科普作家和媒体理论家,著有《Where Good Ideas Come From》, 中文版名称《伟大创意的诞生:创新自然史》。

[8] KYM - Know Your Mission,意为“了解您的测试任务”;TCO - Testing Coverage Outline,意为“测试覆盖大纲”。

[9] Carolyn Chandler, Anna Van Slee, Adventures in Experience Design, 2014。

[10] Sunni Brown, The Doodle Revolution: Unlock the Power to Think Differently, 2014。

[11] 为了日常沟通的方便,通常把MD/FI/QC进一步简化为MFQ了。

[12] 这份测试设计问题调查报告曾在2012年ChinaTest上分享过,您可以在我的网站http://www.sharetesting.com上找到分享的文件和视频链接。

[13] 这里没有使用test case(测试用例)这个概念,是因为不同企业出具的test case差别很大,有的很粗糙,有的很细节,所以,本书中笼统地用测试实例(对应为test ideas或者test examples)这个概念来表示测试设计的结果。

[14] 后来看了《洞察力的秘密》(Seeing What Others Don’t),作者Gary Klein,才发现,原来这种“灵光一闪”的洞察力并不是偶然获得的,我是走过了一条书中称为“规律性事件”(译者把它称为“巧合事件”,我更喜欢用“规律性事件”来表达)的发现之旅。推而广之,很多时候bug的发现也并不是纯属偶然,是一些你还不知道的因素在影响着你罢了。

[15] 关于这一点更详细的探讨,可以查看我的博文“如何评价测试用例的有效性?”http://www.taixiaomei.com/tad02.php

[16] Mike Smith, Putting the ‘Analysis’ in a Test Analyst, Testing Experience, NO.1, 2008. 原文“People tend to refer to the activity of ‘Test Analysis & Design’. I would rather view this as separate activities of ‘Test Analysis’ & ‘Test Design’ leading to separate work products that may have separate structures for their organization. This better reflects the complex logical to physical relationships that usually exist between requirements and systems as implemented.”

[17] TorbjÖrn Ryber,Essential Software Test Design,2007。

[18] Lee Copeland, A Practitioner's Guide to Software Test Design, 2004。

[19] 您可以在这里http://context-driven-testing.com/找到关于上下文测试学派更多的观点。

目录

相关技术

推荐用户