如何阅读软件测试书籍（一）, the little black book on test design

　　三番四次看见有人在俱乐部里提及，所以找来看看。翻开introduction，不由大笑。因为我也不止一次提过，现存的测试方法，不适合于系统测试（system testing)。在我每年两次的system testing时，每次我都复习之前用过的方法，并加以改进。自己也试着把经历写成博客。点我。所以看到RE也跳出来写，觉得颇为亲切，于是看了下去。顺便写些阅读手记，给不常看书的tester们一点提示，看软件测试书籍，要带着询问，思考，回答，联想的方式阅读，而万不能一目十行。

注：Q为问题代号，即在阅读时，由于作者描述不清，产生的问题，我会在Q后，试图在文中寻找答案。

1 标题

　　作为一个优秀的tester，首先我们要发问：这是一本关于什么的书。标题是：the little black book on test design。

• Q1.1 为什么叫little？因为本书只有32页。
• Q1.2 black book，为啥叫魔法书？
• Q1.3 test design，哪一部分的test，unit test，component test，还是integration或system test，抑或全部包括？

　　仅从标题，我们还无法得到答案。

2 纵览目录，结构及方向

　　RE将本书分为：介绍，灵感，分析，点子，执行，终曲，及参考书目这几个部分。

3 简介

　　简介里，通常会告诉我们，作者为什么会写这本书，写了给谁看。RE说：本书是讲述system testing的。这就回答了问题1.3。如果我们只做unit test，却忽略了这句话，读完了才开始骂街，那就要冤枉RE了。但是注意，RE在此处提到了一个新词：ambitious，野心。

• Q3.1 什么叫有野心的进行system testing呢？

　　RE说：十年来常觉得现存测试方法之不足，现将坊间实用方法记录如下，以供诸位品鉴。实用方法包括：测试策略，分析，设计，和执行。此处，RE提供了一条新的线索，即：本书所谓的测试设计，不止包括设计，更包括其他一切。因为在现实中，这些任务彼此互相联系，很难彻底分开。由于测试的抽样区间过分巨大（即连一个计算器都有无穷多种组合的输入），因此，从中选出重要区域才是关键。手动进行system testing的人，如何抽样重要区域更为重要。此处，勉强算是Q1.2的解答，因为在真实环境中，现存方法并不实用，因此，才将实用方法总结分享，称之为black book。

　　我们更可以替作者做出总结：本书是针对系统测试（system testing）的实用方法的总结归纳（用于找到测试的重要区域），尤其适用于手动测试。

3.1 要素

　　RE说：tester应该收集尽可能多的信息（需求，说明，雏形，代码，缺陷，技术支持，用户故事，用户预期，技术，工具，模型，系统，质量标准，质量特点，测试技术，测试点子，交谈，风险，可能性），将所有这些整理起来，而后发挥创造力，找到重要区域。但是，这个方法只适合于ambitious projects，即有野心的项目。若是你的项目，资源紧缺（说白了就是没啥经费，没啥牛人），就别扯这个。即：ambitious project needs ambitious testers and ambitious testing。（有野心的项目，才需要有野心的tester和有野心的testing）。此处，对Q3.1，ambitious有了解答。

　　RE又说：若是有野心之人，那么可以采用下面四步：1，搜寻灵感，2，分析重点区域，3，合成测试点子，4执行。我们留意到，这四步，正是接下来四章的标题。

3.2 基础理论

　　RE以社会学研究为例：科学家总是收集被研究对象的所有信息，加以分类，试图从中发现一些理论。直到收集来的信息稳定下来，再不更改，此时，理论才成型。整个过程中，没有前提，没有假设，若是我们开始就自许已经将重要问题都一网打尽，那是非常危险的事情。RE将基础理论的形成与testing进行类比。基础理论是要从社会中收集信息，包括面谈，背景资料等，相比对于testing如何收集信息，3.1中的要素中已经列举过了。

3.3 测试设计理论

　　RE说：测试的策略、分析、设计与执行不应分离，而应结合在一起。因为它们之间互相影响，更不要一开始就定下strategy，让它慢慢随着情形演变。此处RE的理念，开始与敏捷共鸣。越是晚下决定，对客户越有利。那么是不是就不应该有strategy呢？RE说，高层的策略可以有，但不要具体。底层的测试策略，则应该在学习的同时，逐渐成型。

　　RE说：为什么测试分析不常被提及？因为“要测什么”早已在需求中说清楚了。市面上大部分的书，都在讲述单元测试或模块测试的方法，而比之更重要的system testing，以及如何选择重要区域(important things)这个问题，却被忽略了。好在，探索性测试比较关注于此。RE更感兴趣的，不是设计测试用例，而是设计测试点子。此处，与基础理论相对应，RE认为，他的工作是搜集相关信息，分析，针对性的进行选择策略与工具。

• Q3.3.1：我们已经听RE提到过数次，重要区域了，到底什么是重要的？

3.4 重要区域（important things)

　　终于来解答Q4.3.1这个问题了。RE列举了如下若干可以为重点区域提供参考的信息来源：1需求，2业界知识，3用户情况，4想象力，5批判性，6技术，7测试人的思维。从上述来源中选去重点，需要对价值观的判断，而计算机，在这一点上，远远不如人类。此处，提到需要用到价值判断（value judgement），来选择重点区域。相信这个词，在之后会频繁出现。

4 灵感

　　在阅读本章前，我们先看看灵感一词。inspiration - stimulation or arousal of the mind, feelings, etc, to special or unusual activity or creativity. 中文：加速或唤醒思维与情感，以达到非凡的活力或创造力。此处：非凡的活力或创造力，自然是指system testing。那么本章讲述的，应该是：如何加速或唤醒system testing相关的思维与情感，以此来完成ambitous system testing这件事。

　　RE用了三段来论述，为什么照着需求安排testing strategy是不足够的。而后，开始讨论，除了需求，我们还可以依赖哪些信息来源。RE在思考软件测试到底要解决什么问题，他的答案是：我们知道所构建的产品必然会存有问题，但我们希望可以通过努力，在真实环境中可以让客户顺利（无失败、无错误）的使用，并通过使用该产品解决问题。我们突然读到这个话，可能有点觉得突兀。

4.1 模型

　　RE列举了以下若干模型：需求，代码，帮助文档，软件成品，思维模型。我们为了理解的更加深入，先试着理解模型Model这个词。Model - a representation, usually a smaller scale of  a device or structure。试着用中文解释：模型-实体结构或设备的一种缩小的展示。

• Q4.1.1：那么软件测试的实体是什么？或者换个问法，软件测试到底为了什么？此处的答案，4的开篇已经讲述了。即在知道不能发现全部问题的情况下，以保证客户的顺利使用，并达到目的为前提。而若干的模型，均为这一目的在不同层面，不同角度的展示。

4.2 项目与工程

　　本段主要结合真实背景，讲述实际项目中，如何搜集信息。RE先列出了前提：当一个项目，经过多版本发布后，已经存在了相当多的历史数据。我们要如何利用这些数据呢？如：

• 是否有为缺陷建立分类，并找到其中的共性？
• 是否有为缺陷做标签，可以为以后的测试提供灵感？
• 尝试寻找patch中修复的bug的由来，如何避免？

　　>> 题外话：我近年进行system testing，都采用risk analysisi的方法，而被我评为高风险的两大区域：1，customer case（用户技术支持）集中的部分；2，近来bug（缺陷）集中的部分。

　　当前测试进行的背景，也可以作为模型之一。如：

• 从哪里开始，有多少时间？
• 测试人员被背景？
• 别人会覆盖哪些测试？

　　RE说：如果有质量标准可以作为参考，那么便可以容易的从上述提问中，找到何为重要区域。此处，提到新词quality objective，即质量标准，这个词出现在这里略显生僻。RE的意思是，用以判断何为重要的准绳。但上文提到过类似的词，叫value judgements，我以为，二者意思相近，应该去掉一个。

4.3 人与技能

　　此处又有些含糊不清，看到人，我们先想到的是tester，但RE却在第一段中说：要了解用户（user）的知识范围，感受，所受的伤害。那么此处的people，到底是指tester还是user，颇有些含糊。

　　好在文章马上转入skills：

• 知识，经验，直觉，客官
• 探索与学习
• 分析思维
• 批判性思维
• 创新

　　>> 题外话：为了提高我组里众位精兵强将的tester的技能，我曾一度推行testing dojo活动。主要分了learning/practise两种。learning dojo中，我们会一起观看一段测试大牛的视频，并讨论其中涉及到的技术与理念，practise dojo，则选一名tester进行现场测试，其他人稍后会对本次测试给出意见。有人偷偷反馈说，testing dojo这个活动，是在公司几年中颇有收获的一个亮点。可惜，没能坚持下去。

4.4 更多灵感

　　RE列举了一些方法，如：

• 与客户面对面，了解需求。注意，此处所用的词，客户（customer）不同于前文的用户（user），我想简单理解下，customer，付钱的，user，真正使用的。
• 自己使用 - eat your own dog food
• 看看竞争对手的产品
• 理解业务需求

4.5 两倍工作量

　　在需求文档之上，真实的需求包括上述种种，比需求文档的内容更加详尽。tester应该要试着理解，搜集，建立这份真实的需求，才能完成ambitous system testing。但也只有如此，tester才能从更多维度，理解产品。

　　结尾：在结尾处，RE列出了34个测试点子的来源。此处，用了sources for test ideas，又一次的混淆词意。此章讲述的是test inspiration，应该用sources for testing inspiration才对。试着列出一两条：

• 1 capabilities - 这东西干嘛地？
• 2 failure mode - 现实的/假象的，内部的/外部的失败