RexBlack是RexBlack咨询服务公司的董事长和顾问。这是一家国际化的软件和硬件测试和质量保证咨询机构，主要从事测试、测试自动化和质量保证项目的实现、咨询和培训等业务，其客户包括思科、康柏、戴尔、通用电器、　日立、摩托罗拉、Sun等国际知名公司。他曾在Software Testing and Quality Engineering和The Journal for Software Testing Professionals发表多篇论文，他还经常在专业性会议上发表演讲，并开办了许多培训班。

你在负责管理一个计算机硬件或软件测试项目吗 恭喜你!也许你刚从测试工程提升或从开发小组的另一个部门调过来，或者也许你已经做了一段时间的测试项目了。不管你是测试经理、开发经理、技术或项目负责人，还是对公司测试和质量保证项目负有一定责任的人，你都可能在寻找一些关于怎样管理测试项目的方法。
　　本书对你可能会有所帮助。本书在1999年出版的第1版，在头两年销售量就超过10 000册。我收到很多读者的电子邮件，　一些人想问我一两个问题，　一些人对我撰写此书表示了感谢，还有一些人指出了其中的错误。读者们在不同的出版物和网站上写了评论意见，大部分是肯定的意见，但也有一些有助于改进的建议。我非常高兴本书得到大家的认可，也感谢所有阅读本书第1版的读者，特别是那些建议我如何改进第2版的读者。
　　本书包含了我从编程和系统管理转向测试管理时希望学习到的知识。本书会告诉你怎样开发一些必要的工具以应用于你的测试项目，还提供一些帮助你获得和使用必需资源的技术。如果你掌握了这些基本工具，将这些技术运用到你的资源管理过程中，合理分配精力，你就能成功地管理测试项目。你甚至还会做得更加出色，这可能让你同我一样成为测试项目经理。
本书重点
　　出于很多种原因，　我编写了本书。首先，在所谓的“软件危机”　中，很多项目在交付日期、预算和质量上的实际结果和预期相差甚远，特别是编写和测试软件的个人、高级项目负责人和用户之间的评价相差甚远。同样，计算机硬件开发项目经常忽略了关键进度安排和质量里程碑。作为项目风险管理策略的一个完整部分，有效的测试和明确的结果交流都大有裨益。
　　其次，我发觉关于软件测试和硬件测试方面的文献之间存在差别。我读过一些如何设计和实施测试用例的基础知识方面的书籍，　同样也读过描述经验丰富的高级项目经理如何运用诸如能力成熟度模型(CMM)、IS09000、全面质量管理、软件质量度量等概念和工具来提高产品质量的书籍。然而，我相信像我们这样的测试经理需要这样一本书，　它将向我们阐述测试项目管理中像砖和水泥一样的基本工具和技术。
　　在本书中提供的技巧和工具会帮助你计划、构建和执行一个结构化的测试操作。不同于所有普通、特定且无用的测试项目，结构化的测试操作是有计划的、可重复的且编制成文档的，但仍在适当的地方保持了创造性和灵活性。在本书中学到的东西让你能够开发用于理解测试产生的大量数据含义的模型，从而让你能够有效地管理软件或硬件开发项目中经常是混乱的、无序的且由变化驱动的那些领域。本书还讲述了如何组建一个有效且高效的测试组织。
　　最后，我要重点谈谈开发和维护环境中的测试管理问题。　因为以下两个相关主题在其他书里介绍得很多，在此我就不讨论了。
　　基本项目管理工具，比如工作分解结构、甘特图、状态报告和人员管理技巧。在从事管理工作时，这些工具对你很有帮助，　因此我建议你应参考一些项目管理方面的书籍，　比如在附录B中参考文献里面列出来的书目。你也可以参考现在项目管理方面大量优秀的培训课程。
　　计算机硬件产品测试。如果你的业务范围包括这种测试类型，我推荐你参考W．Edwards Deming、Kaoru lshikawa和J．M．Juran编写的关于统计质量控制方面的优秀书籍，　还有Patrick O’Connor编写的关于可靠性工程方面的书籍；详细内容请参看附录B中的参考文献。
　　从把“黄金代码”原封不动地拷贝到发布介质上的意义来说，软件产品不需要测试。但是，硬件和软件产品经常包含一些小的修订和维护发布版本。你可以利用本书中描述的技术来管理那些包含这种发布版本的较小的测试项目。
　　本书对于软件和硬件测试的不同之处有详细的描述，　因此，　乍一看以为本书分为两个方面阐述。然而，我发现从测试项目管理的角度看，这两个方面测试的区别没有从测试技术角度看重要。意思很清楚：硬件测试软件，软件测试硬件。这样你就可以用相似的技术管理硬件开发和软件开发项目的测试了。
规范还是食谱
　　在我刚开始担任测试工程师及测试项目经理的时候，我对测试一无所知。无知会让你意识不到在隧道洞中看到的亮光实际上是正在飞速驶来的火车。　“那会有多么艰难呢 ”我这么想，“测试仅仅就是算出可能出现什么差错，并进行试验验证罢了。”
　　但是我很快发现自己错了，　出现以上看法错误在于以下三个关键方面：
　　．“算出可能出现什么差错，并进行试验验证”的任务的确很困难，也就是设计出好的测试用例很困难。在近十年里，　涌现出了许多关于测试用例工程的好书。但是，　虽然在我学生时代或以前，BorisBeizer、BillHetzel、CemKaner和GlenfordMyers都出版了相关主题的书，我的教授却没有教我测试方面的知识。随着软件工程的下半世纪的开始，这种状况最终开始改变。但是，大多数成长中的软件工程师仍然很少学习有关测试方面的知识。
　　．测试不是在真空中进行的。相反，　它是整个项目的一部分，　因此测试必须和实际项目需求相符，而不是黑客的异想天开。简而言之，测试项目需要对测试项目进行管理。
　　．“测试太难了。”这种想法的盛行只会增加测试专家面临的困难。一旦我们从痛苦的经历中明白了测试到底有多难，我们有时候就觉得好像是命中注定要一个项目接一个项目地反复解释为什么这个测试任务需要花费这么多时间和金钱。
　　以上几个方面暗含了很多复杂的因素。其中最重要的因素之一就是组织测试过程的成熟度等级可能发生较大变化：测试可能是一个可重复的、可度量的过程的一部分，或者对一个混乱项目的亡羊补牢。另外，动机因素(也就是管理为什么会干扰测试的原因)在重点和强度上都可能发生改变。　因为害怕重复近期的失败项目而萌发测试动机的测试经理与尽可能生产出好的产品的经理对待测试的态度是不同的，而两种动机都不同于那些被迫进行测试但并不重视测试的人的动机。最后，测试还和项目的其他部分紧密相关，　因此测试经理经常遭到外界的各种影响。　当测试范围和进度的改变在项目中引起较大变动时，这些影响并不总是良性的。
　　上述因素使得开发一个关于“如何”计划和执行测试项目的指南非常困难。正如学者们可能说的那样，测试项目管理不是简单开发一个规范。“理解以下观点你就能理解这个领域。”这句话不适合测试这个领域，并且，测试规范的开发不是本书要完成的任务。
　　你需要一份规范来正确管理测试项目吗 我认为不需要。相反，打个比方：我是个技艺精湛的厨子，　一个业余主厨。我永远不可能成为世界级的名厨，但是我照样能为我的家人做出不错的正餐。我成功地准备了丰盛的感恩节大餐，有些是在汽车旅馆的小厨房里准备的。在学校里为了生活需要，我掌握了烹制家常饭菜的方法。在这个过程中，我学会了如何从食谱里面找出烹制方法，如何应急，　怎样快速地准备各种配料，　以及怎样掌握好正餐和一系列小吃的时间，然后凭着记忆烹制食物。
　　对你的测试组织所需要的管理，　一顿价格合理的家常饭菜就是很好的类比。因此，本书就可以作为测试项目经理的“食谱”，　它描述了需要的基本工具，并帮助你组合和调配适当的元素。
需要的工具
　　我的测试管理方法中包含五种基本工具：
　　详尽的测试计划。一份详细的测试计划就像一个水晶球，让你可以预见和预防潜在的危机。这样的计划阐述了测试范围、质量风险管理、测试策略、人员配备、资源、硬件补给、配置管理、安排进度、阶段、主要里程碑、阶段过渡，　以及做预算。
　　良好的测试系统。好的测试系统能有效地确定可能损害上市产品或降低内部用户认可度的错误。它的内部和外部保持一致，　易学易用，且建立在一套设计良好和兼容的工具之上。我用术语“良好测试系统体系结构”来描述这种系统的特性。体系结构一词让测试小组内的成员培养对测试开发的全局和结构化的观点。对于管理来说，创造良好测试系统包含开发结构优良、持久耐用的产品。
　　基本状态的错误跟踪数据库。在测试过程中，你和勇敢的测试小组成员将发现很哆bug(又称为问题)、缺陷、错误、问题、过失，　以及其他不容易用纸记录的内容。试图在你的大脑里或一个文档中记住所有错误会立即造成灾难，　因为你不能在测试小组内和程序员、其他开发小组同行或项目管理小组进行有效的交流，而这样并不有助于提高产品质量。你需要一个方法来跟踪每个错误从开始到结束过程中的一系列状态。我将告诉你怎样安装和使用一个有效和简单的数据库来实现这个目的。这个数据库还可以以信息图表的方式总结错误，告诉管理部门关于项目测试完成情况、产品稳定性、系统转变时间、麻烦的子系统和根本原因。
　　全面的测试跟踪电子表格。除了跟踪错误之外，你还需要跟踪每个测试用例的状态。当使用某特定硬件时，操作系统会失效吗 按照特定格式保存文件的时间是否太长 哪个版本的软件或者硬件不能完成重要的测试 使用单个电子表格的多个简单工作表就可以跟踪每个测试用例的结果，使你获得回答各种问题的细节内容。详细的工作表组成一个汇总的工作表，使你可以了解整体情况。测试用例进度如何 多少测试用例被阻塞 所有测试用例到底花费多长时间才能完成
　　简单的变更管理数据库。多少次你曾经纳闷：“进度为什么与计划出现如此大的偏差 ”诸如硬件或者软件交付日期推迟、丢失阻塞测试用例的特性、无效的测试资源，　以及其他看起来微不足道的变更都可能会对项目测试实施产生负面影响。如果测试实施得晚，整个项目完成时间就会推迟。你不能防止测试延迟情况的发生，但是可以跟踪测试延迟情况，　以便提前了解可能发生的延迟，并有效地解决问题。本书提供一个简单、高效的数据库，使你可以及时跟踪风险，防止出现问题。
　　本书向你展示了如何开发这五种基本工具，把这五种基本工具应用到测试项目中，　以及如何获取和使用必需的资源。我已经在PC中普遍安装的Microsoft Office套件(Excel、Word、Access和Project)　中实现了它们。你也可以很容易地使用其他办公自动化应用程序，　因为我并没有使用Office套件的高级功能。
需要的资源
　　让我们继续使用烹饪的比喻，为了做出一盘菜，你需要其他调料或者资源。在测试烹饪书中，我将演示如何组装资源以便实现测试项目。这些资源包括以下内容：
　　实用的测试试验室。工作舒适和安全的地方，配有优秀人才和计算机设备。该实验室需要通过多种方式与开发小组、管理部门，　以及外界进行交互和沟通。你必须保证实验室装备足够的软件和硬件以保证测试人员高效率地工作，　同时还应该及时更新软件和硬件。请记住，这是个测试试验室，需要让工程师很轻松地跟踪有关系统配置的关键信息。
　　测试工程师和技术人员。你需要能够努力工作的优秀的团队。寻找优秀的测试工程师比寻找优秀的开发工程师更难。你怎样识别初露头角的测试天才和那些会使测试变得一团糟的庸才呢 有时，识别两种人的难度超出你的想像。一旦团队组建完成，就可以真正地开始工作了。
　　你怎样激励团队努力工作呢 怎样消除影响士气的因素呢
　　承包人和顾问。作为测试经理，你有可能借用外部资源，按小时雇佣技术高手，在项目结束时终止合作。我将帮助你区分普通的高技术临时工人，　了解他们从事这种工作的原因，　并消除他们的顾虑。你何时需要承包人 承包人关心什么事情 你应该尝试固定与一些合作愉快的承包人合作吗 你怎样判断何时需要顾问
　　外部测试试验室和供应商。在有些案例中，有必要不在自己的测试试验室中做某种测试，如当自己的测试试验室的测试任务很重时。合理使用外部资源提供的技能、基础设施和设备有助于节省时间和成本。这些实验室和供应商到底能够为你做什么 你怎样使用他们来缩小测试项目的规模，而不会影响测试覆盖率等方面 你怎样把这些过程和结果映射到自己的测试项目
　　当然，在使用这些资源之前，你需要对此进行合理的调配。在前面你也许已经了解到，管理部门对测试需要的资金和设备的要求也许很精确。我提供一些有助于你尽快获得所需资源的建议。　　
　相关环境
　　我已经在许多大型和小型项目中使用过这些工具和技术。这些概念可以很容易扩展和缩小，尽管大型项目也许需要购买自动化方式的某些工具。在这种情况下，我所描述的工具可以充当你准备购买或者构建自动化工具的原型和需求。
　　在分布式项目中，这些概念也可以扩展。在旅馆房间和机场大厅里，我曾经在膝上电脑中使用这些工具来同时管理多个项目。我曾经使用这些工具来测试市场驱动的终端用户系统和内部信息技术项目。尽管背景不同，但是我认为可以改编这些概念，使之应用于多种环境下。
　　这些工具符合工业标准，　与领先的软件和硬件供应商的最佳测试管理实践和工具保持一致。我使用这些工具来整理我对项目的认识，开发有效的测试计划和测试包，在动态高技术开发环境中执行计划，并跟踪、分析和向项目经理展示结果。同样，我对测试资源管理的建议也来自各种成功和失败的经验。
　　由于环境原因，我在本版的最后新增加一章，讨论测试过程与整体开发或者维护过程保持一致的重要性。这涉及诸如组织环境、测试的原因和经济因素、　系统开发的生命周期和方法论，以及过程成熟度模型等问题。
使用本书
　　本书中所有内容都不是基于科学真理、闭门造车、学术研究，或甚至是灵感。它只是一些关于我曾经在管理大量测试项目时从事的和将继续从事的工作的内容。你可以照搬这些方法或者做一些修改。也许你会发现所有的方法或其中的一部分非常有用。
　　同样，这不是一本描述测试方法、测试理论或开发过程艺术的书。本书是有关硬件测试和软件测试的实践书。对于开发过程(最佳实践或贵公司的实践)，我只是假设你作为测试经理而介入到一个开发项目，并花大量的时间进行必要的测试开发。最后一章讲述了我所见过的和参与过的不同的开发过程。我还讨论了开发周期的选择是如何影响测试的。
　　当然，在一定程度上，我不能只谈论测试管理，而不谈论测试技术。因为硬件测试技术和软件测试技术有区别，所以你可能会发现我使用的一些术语可能对你的运用造成困惑、矛盾或不清楚。本书提供了术语表，如果你是一个软件测试者，　它能帮助你解开硬件测试示例的疑团，反之亦然。最后，测试经理通常既是技术带头人也是经理，因此你务必在特殊测试项目中理解和使用最佳实践，尤其是在采用测试技术的过程中。附录B中有一个书目，　如果需要，那些书可以帮助你重新学习这些主题。
　　本书基于我的实际经验，其中好坏经验兼有。失败的教训是为了帮助你避免一些我曾犯过的错误。我试图让这种讨论保持轻松风趣。在附录B的参考文献中列出的书目中你可以找到本书内容的理论支持。
　　我发现对照例子学习的效果最好，　因此我还在书中包含了很多例子。　由于我描述的工具应用于软件测试和硬件测试，　因此很多例子我都以以下两个假设项目之一为基础：
　　·大多数软件例子包含基于Java的字处理包SpeedyWfiter的开发，它由SoftwareCafeteria有限公司编写。SpeedyWriter拥有宇处理器的所有功能，还有网络文件加锁、Web集成和
　　公钥加密等功能。SpeedyWnter包含了其他供应商提供的各种JavaBeans。
　　·大多数硬件例子参照服务器DataRocket的开发，它由Winged Bytes公司开发。DataRocket提供强大的、高容量的文件和应用服务，也是局域网用户的Web主机。它运行多个操作系统。借助于第三方软件，Winged Bytes计划集成一个U．S．制的局域网网卡和台湾的SCSI控制器。
　　至于书中讨论的工具，你可以在网址www．rexblackconsulting．com找到相关例子。我为第2版花了大量时间改进这些模板。我还增加了一些实际项目的案例研究。在描述这些工具用途的章节中，我用了简短的篇幅指导你如何使用和学习这些模板和案例研究。这样，你就可以凭借自己的力量利用这些资源成功地实现那些工具了。我在书中用了一些图来描述部分工具，并在本版中改善了图的可读性。但是，工作表和图表的屏幕快照内容还是很有限。因此，在阅读不同的章节时，你也许想从网站打开并验证相应的案例研究和模板以加深对工具工作机制的
理解。
　　请注意本书中提供的工具是可用的，但是也包含了很少量的“虚构数据”。不应该用这种数据来推导对错误汇总、缺陷密集度、主要质量风险的任何粗略估计，或者任何其他项目采用的衡量尺度的经验。我开发这些工具主要是为了证实一些想法，所以它们不具有你所期望的如同商业产品一样复杂的自动功能。如果你打算在自己的项目中使用这些工具，那么就要花足够时间和精力来使它们适合于你的项目环境。
　　考虑到你们在实际项目中使用这些工具前需要做练习，我在每章的最后都安排了练习。这些都是本版中新添加的内容，也使得本书更加适合作为关于测试、软件工程或软件项目管理方面课程的测试管理教材(练习解答请参见网站www．rexblackconsulting．com)。假定测试越来越多地被明智的项目经理看作是项目风险管理策略的一个关键部分，那么相关内容的资料作为学校或认证课程的部分教材是非常有意义的。
　　最后，你应当知道测试不是时间和资源充足的领域。我发现至关重要的是把重点放在对项目经理来说真正有价值的测试上。过去，我经常都是因故终止错误步骤，　因为我总是在一些不重要的细节上花费时间而忽略了重要的环节。这些经历教会我辨别并关注那些少数重点，　而忽略多数琐碎的细节。书中介绍的工具和技术同样可以帮助你做到这一点。许许多多计算机测试组织维持不了几年就垮台了。本书可以帮你避免重蹈覆辙。
　　虽然测试管理的成功不仅仅简单地取决于一份工作，这一点是很清楚的，但是对不同的人就有不同的含义。在日常工作中，我保持平和的心态，减缓压力，从实际管理测试中不断提升专家形象，在我的知识范围内衡量成功的价值，而不是通过对在混乱环境中引起的无休止的危机做出反应来衡量。我希望我的这些工具和想法将帮助你成为一个成功的测试专家。
第2版的改动和新增内容
　　对于本书第1版的读者和正犹豫着是否要购买第2版的读者，我下面将简要说明第2版中的一些改动和新增内容：
　　·最后一章是新加的，其中讨论了测试过程与整体开发或维护过程相适应的重要性。我阐述了组织环境、测试的原因和经济因素、系统开发的生命周期和方法论，以及过程成熟度模型。
　　·　为书中讨论的工具和技术添加了一些案例研究。这些案例研究源自真实项目，令人高兴的是它们不受非公开协议的限制。本书第2版还包含了一些背景信息帮助你理解这些案例研究文档。
　　·增加了模板和例子的数量，并改善了一些工具的格式。还添加了一些新的度量。模板里包含了生成这些度量的工具。第1版中的一些模板有些小错误。(第1版的读者和一些测试专家发现并给我指出了那些错误。)我已经改正了那些错误。
　　·　第1版中的一些图片很小且字体太小。第2版中我修改并扩大了图片，这样就提高了可读性。在最后的编辑中我还改正了一些放错地方的图片。
　　·　除了案例研究，我还增加了一些练习，其中有些是我以前在三日制　“测试过程管理”课程中采用的练习，有些是特别为第2版创作的。这些练习可以用于自学、　图书俱乐部或课堂教育。(CalifomiaPolytechnic State University的Patricia McQuaid教授把第1版选作软件测试课程的教材。)为了确保这些练习的实用性，我和软件工程学术界的著名人士共同做出了努力。
　　·包含模板、案例研究和练习的支持文件和其他工具没有用易损并难以更新的CD-ROM提供，而是发布在网站WWW．rexblackconsulting．com上。我将继续更新和改正这些模板，这样从某种意义上来讲，本书也将不断地得到完善。
　　·　最后，从我编写第1版以来，根据管理测试项目人员面对的挑战，我对第2版做了一些小的变动。每次当我将此书作为两日制和三日制　“管理测试过程”课程的教材时，至少有一个学生告诉我说：“令人惊讶的是我们这里讲到的每个问题在我的项目中都发生了。”然而，我已经学习了一些新技巧并开阔了思想。例如，我在第1版中批判探索性测试，但是通过和一些成功实践者的认真交流和自己尝试，我了解到探索性测试是一项有用的技术。
　　如果你阅读了第1版，欣赏它，　并觉得它有用，那么我想这些改动和新增加的内容会使第2版对你更加有用。

（美）Rex Black：暂无简介

龚波 但静培 林生 周林全：林生: 林生，华南师范大学计算机学院教授。大学毕业并任教于军事电信工程学院（即西安电子科技大学）信息工程系，多年从事数字系统、数据通信和计算机通信与网络方向的科研和教学工作。1981至1983年期间，作为访问学者在加拿大不列颠哥伦比亚大学研修计算机通信和计算机网络。回国后，先后在西安电子科技大学和华南师范大学从事计算机通信和计算机网络方向的教学与科研工作。曾经出版的著作有《计算机通信网原理》（西安电子科技大学出版社）、《计算机通信与网络教程》（第1版）和（第2版）（清华大学出版社）；译著有《数字系统设计基础》（西安电子科技大学出版社）、《数字设计原理与实践》（机械工业出版社）。

前言
第1章　确定测试的重点内容：测试
项目的基础
1．1　可能测试什么：扩大的测试工作量
1．1．1　从显微镜到望远镜：测试粒度
1．1．2　后退还是前进 测试阶段
1．1．3　第一次挫折
1．2　测试时要考虑质量
1．2．1　为质量进行全面定义
1．2．2　不注重质量是铤而走险
1．2．3　评价质量风险的非正式方法
1．2．4　故障模式和效果分析：理解质量
风险的正式方法
1．3　测试的内容：进度、资源和预算
1．3．1　削足适履：使测试计划适应项目
1．3．2　估计资源和创建预算
1．3．3　协商合适的测试项目
1．4　案例研究
1．5　练习
第2章　策划和描述测试过程：
测试计划
2．1　编写测试计划的目的
2．2　测试计划的数量
2．3　利用草案激发讨论
2．4　测试计划模板
2．5　概述
2．6　边界
2．6．1　范围
2．6．2　定义
2．6．3　设置
2．7　质量风险
2．8　里程碑的推荐进度
2．9　过渡
2．10　进入标准
2．11　退出标准
2．12　测试配置和环境
2．13　测试开发
2．14　测试执行
2．14．1　关键参与者
2．14．2　测试用例和错误跟踪
2．14．3　错误隔离和分类
2．14．4　测试版本管理
2．14．5　测试循环
2．14．6　测试时间
2．15　风险和不测事件
2．16　变更历史
2．17　参考文档
2．18　常见问题
2．19　IEEE 829模板：比较和对照
2．20　推销计划
2．21　清晰、针对性和行动
2．22　免费测试计划模板
2．23　案例研究
2．24　练习
第3章　测试系统体系结构、用例
和覆盖
2．1　测试系统体系结构和工程设计
3．2　测试系统体系结构原理
3．2．1　测试系统质量
3．2．2　任何测试系统都不是孤岛：测试
人员和测试系统
3．2．3　测试系统质量的好实践和原理
3．3　系统的基本构件：测试用例
3．3．1　创建测试条件
3．3．2　基本测试模板
3．3．3　DataRocket的压力测试用例
3．3．4　其他测试用例模板
3．3．5　如何细化 准确性的作用
3．4　避免可怕的"测试遗漏"：覆盖和
回归测试间距
3．4．1　最好的意图，低劣的覆盖决策
3．4．2　正在测试的是开发建立的系统吗
3．4．3　把质量风险和测试用例联系起来
3．4．4　配置覆盖
3．4．5　错误覆盖
3．4．6　回归测试间距
3．4．7　如果不能重复所有测试怎么办
回归风险缓和策略
3．5　"学习经验教训"：测试用例递增改进
3．5．1　故障响应
3．5．2　采用最佳实践
3．5．3　使用探索性测试
3．6　不能面面俱到：有所取舍
3．7　案例研究
3．8　免费案例研究
3．9　练习
第4章　令人兴奋的捕虫工作：错误
跟踪数据库
4．1　为什么捣乱 正式的错误跟踪系统
示例
4．2　问题是什么 故障描述
4．2．1　报告描述风格
4．2．2　编写好的错误报告的十个步骤
4．3　灵活的报告：开始创建数据库
4．4　重要的少，次要的多：按重要性排序
4．5　设置错误跟踪：添加动态信息
4．5．1　使用状态来管理错误生命周期
4．5．2　强调所有权和责任
4．5．3　关键转移：隔离到调试
4．5．4　引导错误生命周期：错误分类
过程
4．5．5　设置动态字段
4．6　最后一步：为分析获取错误数据
4．6．1　与错误相关的：子系统、配置
和质量风险
4．6．2　错误来源：解决方案和根本
原因
4．6．3　错误何时结束 关闭日期和注入、
检测和删除阶段
4．6．4　完成错误跟踪数据库
4．7　从错误跟踪数据库中抽取度量
4．7．1　如何去除缺陷：公开／关闭图表
4．7．2　为什么发生错误：根本原因图表
4．7．3　开发小组如何响应：关闭周期
图表
4．7．4　什么被破坏了：子系统图表
4．7．5　事后度量：缺陷发现比例
4．7．6　关于度量和图表
4．8　管理错误跟踪
4．8．1　错误数据的误用和策略
4．8．2　陷入困境
4．9　案例研究
4．10　练习
第5章　管理测试用例：测试跟踪
电子表格
5．1　建立最基本的测试跟踪电子表格
5．1．1　基本的电子表格
5．1．2　在测试项目中使用测试跟踪
电子表格
5．2　进一步提高
5．2．1　为测试包和测试用例指定标识符
和测试人
5．2．2　加人日期和时间信息：计划与
实际情况的对比
5．2．3　理解测试运行的时间长短
5．2．4　增加测试用例状态的精确度
5．2．5　划分测试包和测试用例的优
先级
5．2．6　审阅累计列
5．2．7　其他总结和分组数据的方法
5．2．8　通过加入测试用例细节来扩展
测试跟踪电子表格
5．2．9　跟踪覆盖
5．3　启动测试跟踪系统
5．3．1　小问题
5．3．2　大问题
5．3．3　没有问题
5．4　从测试跟踪电子表格中抽取度量值
5．4．1　我们能完成什么工作吗 画出
测试进度图
5．4．2　我们在按照计划完成工作吗
画出计划测试完成表
5．4．3　我们在按计划进行测试吗 画出
测试和错误覆盖图
5．4．4　简而言之，测试状态就是建立
一个平衡的计分卡或监控板
5．5　质问监控板：异议和争论
5．6　案例研究
5．7　练习
第6章　危急时刻的技巧和工具：管理
动态内容
6．1　做好每个细节：凡事做到最好
6．1．1　在遇到问题时要坚持继续前进
6．1．2　关联性、进度表和提示：进度
管理的重要性
6．1．3　它不会交付自己：修订和发布
过程
6．1．4　它不会安装自己：配置测试
环境
6．1．5　审核和更新测试结果时要细心
6．1．6　定义测试执行过程
6．1．7　当测试失败时：使测试结果的
误判最小化
6．1．8　"祝端午节快乐……"当危急
时刻、假日和发生文化冲突时
6．2　蜘蛛网：管理测试硬件和软件配置
后勤
6．2．1　各部分及其连接方式：实体-关
系图
6．2．2　从图表到模式：实现后勤数据库
6．2．3　预算和计划：提早使用后勤数
据库
6．2．4　什么东西在什么地方运行
跟踪软件配置
6．3　意料之中和意料之外：变更管理
数据库
6．3．1　使用(和误用)变更管理数据
6．3．2　简单就好：变更管理数据库
6．4　案例研究
6．5　练习
第7章　配置和管理测试实验室
7．1　设置测试实验室的必要性
7．2　选择和规划实验室场所
7．3　测试实验室配置清单
7．3．1　清单模板的样本
7．3．2　使用风险分析来选择正确的
配置清单
7．3．3　关于实验室配置的深远考虑
7．4　安全和跟踪问题
7．5　管理设备和配置
7．6　保持测试环境的整洁
7．7　人的因素
7．7．1　安全的实验室是工作效率高的
实验室
7．7．2　对实验室设备的损坏
7．7．3　实验室中的生产率
7．8　案例研究
7．9　练习
第8章　组织和管理测试小组
8．1　测试工作的合适人选：什么样类型的
人能成为优秀的测试工程师
8．1．1　专业悲观主义
8．1．2　适度的好奇心
8．1．3　集中注意力：杜绝水平差的人
8．1．4　避免胸怀大志的英雄
8．1．5　防止懒惰
8．1．6　拒绝懦弱的人
8．2　确定测试小组：需要多少人、谁
可以参加、应该做什么
8．2．1　规模
8．2．2　技能
8．2．3　教育和培训
8．2．4　岗位、经验和目标
8．3　专家或者项目资源 组织模型
8．4　雇佣测试人员
8．4．1　确定工作
8．4．2　收集和筛选简历
8．4．3　现场面试
8．4．4　做出雇佣决定
8．4．5　避免和销除雇佣错误
8．4．6　接纳新的测试人员
8．5　非常关注：激励你的测试小组
8．5．1　站在测试小组一边
8．5．2　支持合理的工作方式
8．5．3　促进每个测试人员的职业发展
8．5．4　不要根据是否符合时间进度来
分发奖金
8．5．5　不要像买大米那样购买错误
8．5．6　希望感谢星期六晚上的比萨饼
8．5．7　提高我们与他们的思想水平
8．5．8　人们到底该做什么
8．6　扩展你的能力：使用临时专家和
实施人员
8．6．1　临时性工作人员充当的角色
8．6．2　长期临时工
8．6．3　雇佣承包人
8，6．4　引入专家
8．7　案例研究
8．8　练习
第9章　政治斗争的胜利：测试经理
面临的组织性挑战
9．1　唐吉诃德，质量冠军：你的工作职责
到底是什么
9．2　适合你的位置：组织内部的测试
小组
9．3　还有其他什么适合的吗 增加其他
测试功能
9．4　同其他经理协作：测试管理的方向
9．4．1　向上管理
9．4．2　向外管理
9．5　在黑暗中前行的测试：没有文档，
你是否应该继续下去
9．6　停牌检查：解雇和清算
9．7　表现测试工作业绩：以合理的方式
呈现正确的信息
9．7．1　传递坏消息的好方法
9．7．2　测试监控制度化
9．7．3　精确性和听众的重要性
9．8　可以告诉先驱们：早期采纳对测试
的影响
9．9　练习
第10章　联合其他参与者的力量：
测试项目的分布化
10．1　选择合作伙伴
10．1．1　供应商
10．1．2　第三方测试组织
10．1．3　销售办事处
10．1．4　用户和用户代理人
10．2　制定分布式测试工作的计划
10．2．1　评估能力
10．2．2　了解成本
10．2．3　比较、协调和分配测试方案
10．2．4　组织后勤
10．2．5　处理映射问题
10．3　管理分布式测试工作
10．3．1　监控测试工作的进展情况
10．3．2　交流进展状况和改变工作方向
10．3．3　处理策略上的注意事项
10．3．4　关注文化差异
10．3．5　建立和维护信任关系
10．4　案例研究
10．5　练习
第11章　测试环境：经济学、生命周
期和过程成熟度
11．1　质量的获得是免费的吗 对测试
进行经济调整
11．1．1　测试实际上花费多少
11．1．2　SpeedyWnter案例研究
11．1．3　管理测试筹款的阻碍
11．1．4　克服障碍……，做我们力所
能及的事情
11．2　测试要符合生命周期的要求
11．2．1　常见生命周期主题
11．2．2　V模型
11．2．3　螺旋模型
11．2．4　演化或递增模型
11．2．5　代码编写与错误修正
11．2．6　测试维护版本
11．2．7　系统、子系统、商业软件和
组件集成
11．2．8　硬件／软件系统
11．3　过程成熟度
11．3．1　"但是我们是不相同的……"：
解决方案的共性
11．3．2　测试团队不是--座孤岛：外部
因素对工作生产率的影响
11．3．3　过程成熟度模型
11．4　管理测试过程：回顾性总结
11．5　案例研究
11．6　练习
附录A　硬件测试基础：软件测试
人员入门
附录B　参考文献、相关读物和其他
资源
术语表