Ch 4. 检查产品说明书
本章将开始介绍首个实际操作的测试——检查产品说明书，以便在编写软件之前就找出缺陷。除此之外，本章还将包括对白盒测试和黑盒测试、静动态测试、审查产品说明书的细节等内容。
开始测试
除了大爆炸模式之外，每一种模式中开发小组都会根据需求文档编写一份产品说明书，用于定义软件是什么样的。产品说明书通常是利用文字和图形描述产品的书面文档。
要求团队为小型软件编写细致的文档似乎有些过分，为什么不干脆让程序员按自己的想法编写程序呢？
开发过程中开发人员常常会产生这种疑问，这时便需要 QA 人员、测试人员和项目管理者来说明文档的重要性：程序员之间对于产品外观、功能和使用方式的理解可能会有所偏差，在测试员和程序员之间亦如此。为了确保最终产品符合客户要求以及正确计划测试投入的唯一方法，就是在产品说明书中完整描述产品。
黑盒测试与白盒测试
- 黑盒测试（或称功能性测试、行为测试）：测试人员只关注软件的功能，而不关注软件的内部代码结构。正如其名，黑盒测试中测试人员将软件看做黑盒（对于用户而言就是这样），只关注软件的输入和输出，以及软件的功能是否符合需求。
- 白盒测试（或称透明盒测试、基于覆盖的测试）：测试人员访问程序员的代码，并根据代码来制定测试用例。它依赖于对程序细节的严密检验，对软件的逻辑路经进行测试。在程序的不同点检验“程序的状态”以判定其实际情况是否和预期的状态相一致。
- 白盒测试容易产生无形的偏见，因为一旦测试员开始尝试适应代码操作，测试便可能变得不够客观。
想想 第三章 中的确认和验证的区别。
对软件的黑盒测试与白盒测试狭义上说都是确认的方法：测试员依照产品说明书的要求，检查软件是否符合预期。如果产品说明书出现问题，那么黑盒测试和白盒测试都会出现问题。
静态测试与动态测试
- 静态测试：不对软件进行运行，仅仅进行静态分析和审核。
- 动态测试：对软件进行运行，检查软件的行为。
让我们以检查二手汽车的例子来说明静态测试和动态测试的区别。
- 静态测试：检查汽车的外观、内饰、发动机、车轮等是否完好。
- 动态测试：开车试驾，检查汽车的行驶性能、刹车性能、转向性能等。
测试产品说明书
测试产品说明书属于静态黑盒测试。无论产品说明书的格式如何——图文兼具，亦或是仅仅存在于核心人员的脑海中——静态黑盒测试都能够实施。
对产品说明书进行高级审查
定义软件产品是个复杂而模糊的过程，期间难免会出现问题。为了更有效地对其进行测试，测试员必须意识到要站在一个较高的层次开展审查，而非陷入对细节的吹毛求疵中。
换言之，应该先理解产品说明书的内容及其背后的诸多为什么和怎么做，再去尝试找出那些根本性的问题、疏忽。
假设自己是客户
审查产品说明书时，测试员应该且最容易做的就是站在客户的角度看待问题。毕竟，客户是软件的最终使用者，他们的需求和期望定义了软件质量本身。
无论是与最终客户群体的代表有所交谈，还是拥有应用领域的相关知识，都能帮助测试员更好地理解产品说明书。
如果在这一步对相关知识犯了难，不要犹豫，尽早去了解它。最终设计软件测试时你还是得知道这些的。
研究现有的标准和规范
全球化与标准化的发展使得许多行业都有了自己的标准和规范，软件也不例外；无论是出于商业考量，还是为了使得软件更加易用，标准与规范是测试过程中不可绕开的一步。
具体到审查产品说明书，测试员要做的主要工作就是明确在产品中应该应用何种规范，且确认产品说明书是否遵循该要求。
这并不是在说，软件测试员要定义软件符合何种标准和规范——那是项目经理或编写产品说明书的人的工作。测试员的工作是检查采用的标准是否正确、有无遗漏。
审查和测试类似软件
研究竞品和小组开发的类似产品是快速了解软件最终结果的好方法。产品说明书在编写时团队里就应该有人进行了研究，因此很容易就能拿到相关的数据。
作为测试员，应该从以下角度展开思考：
- 规模与复杂性：类似软件的功能复杂还是单一？代码量如何？这些对他们的测试计划有何影响？
- 测试性：类似软件的测试计划如何？他们是否有足够成本用于测试？
- 质量：软件是否完全满足质量要求？用户的反馈如何？如果有问题，问题和导致问题的原因是什么？
- 安全性：软件是否有安全漏洞？如果有，漏洞是如何被发现的？他们是如何解决的？
- 这点非常重要。 软件测试员在试用类似软件时不一定能发现所有问题，但那些新闻业界的评论员可不会放过任何一个漏洞；如果从自己的体验中一无所获的话，去读读相关的媒体评论也许会有收获。
对产品说明书的低层次测试
在对产品说明书进行高级审查后，测试员应该开始对产品说明书进行低层次的测试。这一步主要是为了检查产品说明书中的细节，以确保产品说明书中的每个细节都是正确的。
属性检查清单
优秀的产品说明书总是具有这些属性：
- 完整：产品说明书是否包含了所有的功能和特性？单独使用时是否包含所有内容？
- 准确：既定解决方案正确吗？目标定义准确吗？
- 精确：每个细节是否清晰明了？是否有任何模糊之处？容易看懂和理解吗？
- 一致：产品说明书中的所有部分是否一致？是否有任何矛盾之处？
- 贴切：产品说明书是否符合用户的需求？是否有任何不必要的内容？
- 合理：在既定的预算和进度下，产品能够按预期交付吗？
- 代码无关：产品说明书是否只涵盖对产品的功能描述，而不是定义其设计、架构或实现细节？
- 可测试性：功能能否测试？给测试员提供的建立验证操作的信息是否足够？
用语检查清单
测试员需要对下列用语格外敏感，因为这些正是隐含着问题的地方：
- 总是、所有、从不等绝对词语：需要确认软件是否总是这样，要考虑明显违反这些规则的测试用例。
- 当然、显然、因此等略过推导的定论：这些词语试图说服人接受假定情况，也许根本就无法推导出这样的结论。
- 可能、有时、通常等模糊词语：这些词语暗示了软件的不确定性，太过模糊而导致无法测试。
- “有时能够工作、有时候又不能”的软件是没法测试的。
- 等等、诸如此类等省略词语：功能清单必须是完备的，这类词语过于开放。
- 良好、迅速、廉价等主观词语：这些词语无法量化，必须进一步给出定义，用数据说话。
- 处理、进行、跳过等描述过程的词语：这些词语可能隐含了某个复杂的过程，需要进一步细化。
这就像那个笑话：
把大象放进冰箱需要几步？答案是三步：打开冰箱，把大象放进去，关上冰箱。
- 如果……那么（没有否则）：问问自己，
else时会发生什么？
小测验
软件测试员可以根据产品说明书进行白盒测试吗？
可以，白盒测试就是使用如何设计影响如何测试的概念进行的。不过白盒测试也同样会诱导测试员相信产品说明书中的某些内容是完全正确的。
指出下述产品说明中的错误：当用户选择 Compact Memory 选项时，程序将使用 Huffman 解析矩阵方法尽可能压缩邮件列表数据。
这段话的问题是引入了实现细节。产品说明书应该只描述功能，而不是实现。
另外一个问题是尽可能。这是一个模糊的描述，不利于测试员进行测试。
解释软件测试员应该担心下述产品说明中的哪些内容：尽管通常连接不超过100万个，但该软件允许多达1亿个并发连接。
首先是可实现性，1亿相较于100万是一个巨大的数字。预算、进度和技术是否允许实现这一点？
其次是“通常情况”，是否能保证软件一定能够处理这么多连接？这是一个模糊的描述。
再者是测试性，测试员能否建立这么多连接进行测试？