本书的突出特点是具有很强的工程实用性。作者在软件测试理论基础上，系统地提出了一种通过测试线索、需求和规格说明，相当严谨地设计测试的过程。重点讨论了子系统测试方法，即不编写过多的桩函数和驱动程序，充分利用设计文档和源程序的一种测试，特别适合工期很紧张的软件项目测试。
　　本书系统地给出了子系统测试目标和分类，有针对性地给出具体的测试方法和思路。书中给出的测试大纲和检查单会对读者有不少启发，这些内容不仅可以直接用于各类软件的测试设计，还有助于帮助读者开发自己的测试大纲和检查单。
　　软件子系统测试 你有过以下问题吗?通过阅读本书，你将找到答案：
◆如何设计测试
◆测试人员会犯什么典型错误，如何避免这些错误
◆如何实现测试
◆如何判断自己的测试是否有效
◆如何判断测试已经完成
◆第一部分通过实际例子，介绍子系统测试的基本问题。
◆第二部分解决的问题是，要对哪些内容进行成本不高的整体测试，然后再增加哪些部件做进一步测试。
◆第三部分进一步完善了第一部分，并讨论更正测试错误和其他变更方面的重要问题。
◆第四部分详细讨论基本子系统测试技术，包括基于对象和面向对象的子系统。
◆第五部分讨论如何确定在什么情况下简化假设不成立，在什么情况下成立。
本书附录中包括日常工作中非常实用的测试大纲和检查单。

作者简介
BrianMarick是非常知名的软件测试专家。1992年创立了测试基金会和http://www.testing.com网站。为各种杂志撰写过许多测试方面的专业文章。他目前致力于“敏捷测试”的研究。

本书的主题是“中间测试”，重点讨论的是如何彻底测试大型系统中的中等规模组件。我把这些组件叫做子系统。好的子系统测试，是有效和高效地测试集成后的系统的前提条件之一。
　　本书的目标是提出一种巧妙、灵活、经济和一致的测试过程，使得子系统测试人员不必在考虑下一步应该做什么上浪费时间。本书还要详细讨论各个步骤要采用的手段和技巧，使得测试人员能够知道如何才能完成好下一步工作。总之，本书要解答以下这些常见问题：
　　◆如何设计测试
　　◆测试人员会犯什么典型错误，如何避免出现这些错误
　　◆如何实现测试
　　◆如何判断自己的测试是否有效 　　
　　◆如何判断测试是否已经完成
本书读者对象
　　本书是为三类读者编写的。第一类读者是负责诸如设备驱动程序、词汇分析器、类库或客户-服务器系统通信基础模块这类子系统开发的个体程序员。在很多机构中，这些程序员要测试自己编写的代码。这样安排效率很高，但是会带来问题。大多数程序员对测试了解不够，不能把自己的知识集成到有效、高效的策略中。即使是对测试了解比较多的程序员，在查找自己的错误时也会遇到麻烦；　因为如果某人没有在设计中考虑到某些特殊情况，他很难在测试中注意到这类问题。只要程序员能够注意到这个问题，并细心地做工作，那这种问题不一定会成为决定性的。本书能够对这类读者提供帮助，　因为本书的基本目标适合会犯这类错误的所有人
　(既包括程序员，也包括独立测试人员)。子系统测试的目标是减少错误数量，　同时要降低残留错误的危害。
　　并不是说所有程序员都要成为测试专家——尽管大部分程序员在得到合适的支持后都可以很好地完成测试。这类专家就是本书的第二类读者。这类专家与测试人员及开发人员协商，帮助他们解决测试设计方面的问题、评审解决方案、指出疏漏、使实现更容易、评审对质量的评估(以保证这些手段被有效地使用)。一个测试顾问可以极大地帮助很多开发人员，　当然，这些专家自己也要进行测试，包括子系统测试或系统测试。
　　这意味着子系统测试要随着子系统开发一起进行。测试设计的最终产品是一组测试，但是测试的中间结果可以在设计过程期间或在设计评审中使用。这有助于在设计和规格说明　(成本很高地)转换为代码之前，尽早找出其中非常重要的设计和规格说明错误，避免出现成本很高的、不得不返工的情况。
　　最后一类读者是负责测试变更，特别是修改程序错误的程序员或测试人员。变更会带来特殊问题，它们会分解子系统的“不相关”部件，　因此必须仔细测试。但是必须严格限制能够完成的测试量。
　　所有这些读者在测试设计中都要使用代码。代码并不是测试信息的惟一来源，但是是基本来源。本书大部分章节的例子采用C语言编写，　有关基于对象和面向对象测试的章节中的例子采用C++语言编写。读者要能够读懂这些例子才能使用本书，但是本书介绍的方法也适用于其他语言。我的知识背景是UNIX，　因此部分例子来自UNIX方面的问题。本书尽量避开与系统有关的细节问题，并对不能避开的问题做了解释，　以便有其他背景知识的读者不会有理解上的困难。
　　其他读者对象　　
　　系统测试人员在使用本书时会有两个问题。大多数系统测试人员只使用系统的外部接口。本书有些部分对这些读者很有用：简化因果测试、分类测试、测试设计框架、对测试变量的强调、常见测试错误检查单以及对覆盖率的讨论。系统测试人员的第一个问题，是在不引用代码的情况下明了这些主题，而子系统测试人员则在代码背景下需要了解这些主题。要想在一本书中满足这两种要求是不可能的，　因此系统测试人员只得跳过一些内容，并对其他部分进行一定的推断和转换。
　　第二个问题是本书不够充分。系统测试是最困难的一种测试，系统测试要建立在风险分析基础上：最明显或最严重的问题可能出现在哪里 采用什么具体测试手段能够有效地找出这些问题 怎样评估这些具体测试的质量 好的系统测试可能要求某种本书没有讨论到的一些创新。
　　与此形成对比的是，风险分析在子系统测试中的地位不是那样高。我们可以通过风险分析确定要在具体的子系统上投入多少工作量。一旦这种决策完成，测试过程是统一的，　即每个子系统的测试过程都很类似；而这在系统测试中这可能是一种严重错误。
　　我曾经在美国伊利诺伊大学的一门课程中使用过本书。大多数听课学生都是准备进入公司的硕士研究生。因此，他们主要关心的是如何测试，　以及如何协调测试工作及软件开发中的其他工作，但是他们也需要了解理论和尚末实用化的技术。在教学过程中，我补充了一些期刊论文和有关系统测试方面的介绍。对于自学读者，建议系统测试部分阅读　[Beizer86]、[Morell89]的文献综述，这很有用。软件工程IEEE会刊、软件工程与方法论ACM会刊、IEEE软件期刊、ACM“测试、分析与验证研讨会”　(现在叫做“软件测试与分析国际研讨会”论文集)都是很好的现成材料，值得浏览。
　　本书的结构
　　第一部分将通过一个实际例子介绍子系统测试基本问题。这个例子在多个方面进行了简化：假设拥有该程序所做工作的完整规格说明，子系统在测试实现中没有引入问题，　以及有充分时间完整地进行测试。
　　第一部分包含的内容比较多，试图全盘照搬是有风险的，尤其是当被测试的产品很快要推出时；循序渐进地采用有关技巧要更好一些。第二部分将讨论：　当进行测试时应该首先对哪些内容进行成本不高的整体测试，然后再增加哪些部件进一步测试。此外还要讨论如何逐渐改进子系统测试。
　　第三部分对第一部分中经过简化的部分进行了完善。其中有一章要讨论如何选择和测试大的子系统。其他各章要讨论如何应对不够完整、不够严格或遗漏规格说明等情况，　以及在测试时间不足的情况下，如何进行测试。这一部分还要讨论有关测试错误修复和其他变更方面的重要问题。
　　第四部分进一步给出一个例子，建议读者仔细通读，并将自己做的工作和作者做的工作进行比较。只靠阅读不会学到多少技巧，应该像学徒工那样：首先观察专家是如何处理某个问题的，然后在专家在场的情况下自己来处理问题。这个例子在本书范围内尽可能地模拟这种情况。
　　第四部分的其他章节对子系统测试基本技术进行了扩展，　以适应新情况。包括输入句法的测试，测试一致性关系，　以及测试基于对象和面向对象的子系统。不仅是这些问题本身很重要，而且还说明了如何将子系统测试引导到读者自己的环境中。
　　子系统测试要做出一些不会永远成立的简化假设。第五部分讨论如何确定在什么情况下简化假设不成立，且该如何应对。但是，有时这些假设成立的条件过多，在这种情况下，为了有效测试不需要利用本书的这些素材。
　　本书附录包括子系统测试要使用的大纲。附录F提供在日常工作中要使用的检查单。有经验的测试人员可以参考本书附录，寻找更多材料。
　　本书的最后是术语表，在术语表中给出的术语在正文中第一次出现时采用楷体印刷。
欢迎读者联系
　　 如果读者有问题和异议，请将你的意见告诉我，最好通过电子邮件与我联系，我的邮箱地址是：marick@testing．eom。我的通信地址是：
　　Brian Marick
　　Testing Foundations
　　913 West White Street
　　Champaign，IL 61821
　　USA
　　我不能承诺对所有邮件都回信，不过我会解答最好或最常见的问题，我计划在因特网上提供问题答案，并有可能印刷出版。

（美）Brian Marick：暂无简介

韩柯：暂无简介

第一部分　基本手段
第1章　规格说明
1．1　规格说明的要系
1．1．1　前提
1．1．2　后果
1．1．3　定义
1．2　检查规格说明
1．2．1　不完备
1．2．2　模糊

第2章　SREADHEX例子介绍
2．1　引入
2．2　规格说明
2．3　代码

第3章　构建测试需求检查单
3．1　查找规格说明中的线索
3．1．1　前提与后果
3．1．2　变量
3．1．3　操作
3．1．4　定义
3．2　查找代码中的线索
3．2．1　变量
3．2．2　模式操作
3．2．3　函数调用
3．3　找出SREADHEX的线索
3．3．1　代码
3．3．2　我们现在所处的位置
3．4　通过前提、后果和定义获取测试需求
3．4．1　简单验证前提
3．4．2　使用OR的验证前提
3．4．3　使用AND的验证前提
3．4．4　AND和OR组合验证前提
3．4．5　假设前提
3．4．6　后果
3．4．7　定义
3．5　找出SREADHEX的测试需求
3．6　通过大纲确定测试需求
3．7　通过SREADHEX说明大纲的使用
3．8　我们现在所处的位置
3．9　使用测试需求大纲规则小结
3．10　集成测试需求
3．10．1　集成测试需求的一个例子
3．10．2　另一个例子
3．10．3　最后一个例子
3．11　SREADHEX的集成测试需求
3．12　错误猜测
3．13　根据规格说明扫描代码

第4章　测试规格说明
4．1　标记将要使用的规格说明
4．2　一般测试规格说明
4．3　错误测试规格说明
4．4　构建测试规格说明要注意的问题
4．5　有关测试形式的规则
4．6　有关测试内容的规则
4．7　分别测试规格说明和代码
4．7．1　通过规格说明处理需求
4．7．2　根据代码进行需求的while处理
4．8　SREADHEX测试规格说明
4．8．1　设计注释
4．8．2　测试1
4．8．3　测试2
4．8．4　测试3
4．8．5　测试3(续)
4．8．6　测试4
4．8．7　测试5、6和7
4．8．8　测试8
4．9　我们现在所处的位置

第5章　测试驱动器与套件驱动器
5．1　测试驱动器
5．1．1　向子系统提供输入
5．1．2　比较实际结果和预期结果
5．2　套件驱动器
5．3　测试自己的驱动器
5．4　SREADHEX驱动器
5．4．1　大纲与文件结构
5．4．2　驱动器与桩
5．4．3　运行测试
5．5　我们现在所处的位置

第6章　采用问题大纲审查代码
6．1　责任
6. 2　审查SREADHEX

第7章　利用覆盖率检验测试套件
7．1　覆盖率的类型
7．2　不可行的覆盖率
7．3　运用覆盖率信息
7．3．1　覆盖率成本的一个例子
7．3．2　需要小心运用覆盖率的一个例子
7．4　一个较大例子
7．4．1　程序
7．4．2　使用通用覆盖率工具(GCT)
7．4．3　覆盖率
7．4．4　新测试
7．5　SREADHEX的覆盖率
7．6　我们现在所处的位置

第8章　清理

第9章　其他提示
9．1　使用优先级较低的需求
9．2　不确定的限制

第二部分　实施子系统测试

第10章　实施
10．1　运用覆盖率
10．2　改进测试规格说明
10．3　改进测试需求
10．4　并行改进规格说明分析

第11章　完善

第三部分　实践中的子系统测试

第12章　使用更典型的规格说明
12．1　例子：GREPORT
12．2　过程
12．3　练习
12．4　通过代码导出规格说明

第13章　处理大型子系统
13．1　复杂性的应对方案
13．1．1　制订测试进度表
13．1．2　例程需求
13．1．3　较大子系统中的ERROR需求
13．2　大型子系统的危险
13．2．1　内部测试驱动器
13．2．2　外部调试器
13．2．3　没有调试器时的方法
13．3　选择子系统

第14章　测试错误修改与其他维护变更
14．1　一个例子
14．2　测试变更的基本过程
14．3　传播缺陷
14．4　相似性缺陷
14．5　测试较大变更
14．6　测试套件退化

第15章　时间进度压力下的测试
15．1　没有足够时间的测试
15．2　几乎没有足够时间的测试

第四部分　举例与扩展

第16章　句法测试
16．1　符号
16．2　测试需求
16．2．1　邻近项
16．2．2　序列
16．2．3　替换项
16．2．4　简单重复
16．2．5　重复与替换项
16．3　交互

第17章　第二个完整例子：MAX
17．1　规格说明
17．2　通过规格说明导出测试
17．2．1　线索
17．2．2　来自前提和后果的需求
17．2．3　扫描大纲
17．2．4　测试设计
17．3　通过代码导出测试
17．4　使用问题大纲
17．5　测试驱动器与测试运行
17．6　使用覆盖率

第18章　测试一致性关系
18．1　构建测试需求检查单
18．1．1　基本检查单
18．1．2　增加缺陷可视性的注释
18．1．3　测试这个例子
18．2　多样性问题
18．2．1　多于两个变量
18．2．2　检验子系统的其他部分
18．2．3　如果检查由库例程完成
18．2．4　未检查或不可能的ERROR需求
18．2．5　如果多个变量可以同时变更

第19章　状态机与状态图
19．1　状态机
19．1．1　实现
19．1．2　稀疏状态机
19．1．3　冗余迁移
19．2　状态图
19．2．1　状态行动
19．2．2　条件状态迁移
19．2．3　嵌套状态
19．2．4　历史信息
19．2．5　状态图实现框架
19．3　什么时候和怎样构建模型
19．3．1　模型什么时候有用
19．3．2　构建模型
19．4　审查状态机和状态图
19．4．1　检查模型
19．4．2　审查行动
19．4．3　检查实现映射
19．5　测试状态机和状态图
19．5．1　测试需求
19．5．2　来自状态图的需求
19．5．3　测试规格说明
19．5．4　测试实现
19．5．5　覆盖率
19．6　多个状态机
19．6．1　独立状态机
19．6．2　通信状态机

第20章　测试使用可重用软件的子系统
20．1　测试需求
20．2　覆盖率

第21章　测试基于对象的软件
21．1　背景
21．1．1　术语
21．1．2　其他方法
21．2　子系统规模与测试实现
21．2．1　两种特例
21．2．2　另一种方法
21．3　类测试需求大纲
21．3．1　组织
21．3．2　第一步：对象使用需求
21．3．3　第二步：状态机需求
21．3．4　第三步：成员函数集成需求
21．3．5　第四步：对象的聚合
21．4　使用类需求大纲
21．5　时间进度压力

第22章　面向对象的软件1：继承
22．1　测试规格说明与实现
22．2　导出类的类型
22．3　导出类需求大纲
22．3．1　复制基类需求大纲
22．3．2　处理新成员
22．3．3　处理顶替成员函数
22．3．4　处理继承成员函数
22．3．5　更新剩余的对象使用需求
22．3．6　更新状态机需求
22．3．7　多继承
22．4　成员函数的测试需求检查单
22．4．1　新的成员函数
22．4．2　顶替成员函数
22．4．3　继承成员函数
22．5　针对已变更外部例程的测试需求检查单
22．6　通用性(模板)

第23章　测试导出类的一个例子
23．1　abstract hash table：一个抽象类
23．2　hash table：一个导出类
23．2．1　hash table大纲
23．2．2　hash table成员函数的测试需求检查单
23．2．3　hash table测试规格说明与实现
23．3　checking hash table：另一个导出类
23．3．1　checking hash table大纲
23．3．2　checking hash table成员函数的测试需求检查单
23．3．3　实现checking hash table测试
23．4　abstract_hash_table<Item，sx>：模板类

第24章　面向对象的软件2：动态捆绑
24．1　虚拟调用需求大纲
24．1．1　捆绑虚拟调用大纲
24．1．2　怎样处理数据成员
24．1．3　在变更中构建虚拟调用大纲
24．2　使用虚拟调用需求大纲
24．2．1　编写了新的外部代码
24．2．2　增加了导出类
24．2．3　维护

第五部分　测试需求的乘积

第25章　简单测试需求乘积
25．1　变量需求可达性
25．1．1　过程--通过规格说明和代码来处理
25．1．2　过程--只通过规格说明来处理
25．1．3　测试大型子系统的含意
25．1．4　举例：一致性检查
25．1．5　举例：根据sreadhex规格说明来处理
25．1．6　举例：构建sreadhex规格说明
25．2　复杂布尔表达式
25．2．1　导出需求的大纲
25．2．2　举例
25．3　创建布尔便利定义
25．3．1　过程
25．3．2　greport例子
25．3．3　greport的其他问题
25．4　数据流测试
25．5　一些理论

第26章　操作测试需求的乘积
26．1　过程
26．1．1　找出交互线索
26．1．2　乘积
26．1．3　覆盖率
26．1．4　举例
26．2　发散操作
第六部分　附　　录
附录A　测试需求大纲(学生版)
附录B　测试需求大纲(标准版)
附录C　与POSIX有关的测试需求大纲(部分样本)
附录D　代码审查问题大纲
附录E　复杂布尔表达式需求大纲
附录F　用于测试编写内容的检查单
参考文献
术语表