软件测试过程管理（原书第2版）
[绝版]
点击看大图基本信息
- 作者： （美）Rex Black [作译者介绍]
- 译者： 龚波 但静培 林生 周林全
- 丛书名： 软件工程技术丛书/测试系列
- 出版社：机械工业出版社
- ISBN：7111127471
- 上架时间：2003-9-30
- 出版日期：2003 年10月
- 开本：16开
- 页码：399
- 版次：2-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 软件质量、软件测试及维护
编辑推荐
本书由RexBlack是RexBlack咨询服务公司的董事长和顾问亲自编写，详细论述了管理大型和小型项目中硬件和软件所需要的工具和资源，从而使读者可以根据自己的具体情况进行定制。还提供作者亲自做的很多测试试验，其中包括失败的试验，使读者不仅可以从中吸取经验教训，而且可以有效地将测试理论与实践完美结合。
内容简介回到顶部↑
本书详细论述了管理大型和小型项目中硬件和软件所需要的工具和资源，从而使读者可以根据自己的具体情况进行定制。这些工具虽然简单，但非常有效，并遵循行业标准，使读者能够了解和掌握最好的测试管理实践和工具。本书还提供了作者亲自做的很多测试试验，其中包括失败的试验，使读者不仅可以从中吸取经验教训，而且可以有效地将测试理论与实践完美结合。
主要特点：
◆比较期望的和实际的进度、预算和质量
◆在开发和维护过程中调整测试过程
◆如何选择和何时使用测试工程师和技术人员。分包商和顾问，以及外部测试试验室和供应商
◆设置和使用有效且简单的错误跟踪数据库
◆跟踪每个测试用例的状态
主要特点：
◆比较期望的和实际的进度、预算和质量
◆在开发和维护过程中调整测试过程
◆如何选择和何时使用测试工程师和技术人员。分包商和顾问，以及外部测试试验室和供应商
◆设置和使用有效且简单的错误跟踪数据库
◆跟踪每个测试用例的状态
作译者回到顶部↑
本书提供作译者介绍
RexBlack是RexBlack咨询服务公司的董事长和顾问。这是一家国际化的软件和硬件测试和质量保证咨询机构，主要从事测试、测试自动化和质量保证项目的实现、咨询和培训等业务，其客户包括思科、康柏、戴尔、通用电器、 日立、摩托罗拉、Sun等国际知名公司。他曾在Software Testing and Quality Engineering和The Journal for Software Testing Professionals发表多篇论文，他还经常在专业性会议上发表演讲，并开办了许多培训班。
.. << 查看详细
.. << 查看详细
目录回到顶部↑
前言
第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章 策划和描述测试过程：
第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章 策划和描述测试过程：
前言回到顶部↑
你在负责管理一个计算机硬件或软件测试项目吗?恭喜你!也许你刚从测试工程提升或从开发小组的另一个部门调过来，或者也许你已经做了一段时间的测试项目了。不管你是测试经理、开发经理、技术或项目负责人，还是对公司测试和质量保证项目负有一定责任的人，你都可能在寻找一些关于怎样管理测试项目的方法。
本书对你可能会有所帮助。本书在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都出版了相关主题的书，我的教授却没有教我测试方面的知识。随着软件工程的下半世纪的开始，这种状况最终开始改变。但是，大多数成长中的软件工程师仍然很少学习有关测试方面的知识。
．测试不是在真空中进行的。相反， 它是整个项目的一部分， 因此测试必须和实际项目需求相符，而不是黑客的异想天开。简而言之，测试项目需要对测试项目进行管理。
．“测试太难了。”这种想法的盛行只会增加测试专家面临的困难。一旦我们从痛苦的经历中明白了测试到底有多难，我们有时候就觉得好像是命中注定要一个项目接一个项目地反复解释为什么这个测试任务需要花费这么多时间和金钱。
以上几个方面暗含了很多复杂的因素。其中最重要的因素之一就是组织测试过程的成熟度等级可能发生较大变化：测试可能是一个可重复的、可度量的过程的一部分，或者对一个混乱项目的亡羊补牢。另外，动机因素(也就是管理为什么会干扰测试的原因)在重点和强度上都可能发生改变。 因为害怕重复近期的失败项目而萌发测试动机的测试经理与尽可能生产出好的产品的经理对待测试的态度是不同的，而两种动机都不同于那些被迫进行测试但并不重视测试的人的动机。最后，测试还和项目的其他部分紧密相关， 因此测试经理经常遭到外界的各种影响。 当测试范围和进度的改变在项目中引起较大变动时，这些影响并不总是良性的。
上述因素使得开发一个关于“如何”计划和执行测试项目的指南非常困难。正如学者们可能说的那样，测试项目管理不是简单开发一个规范。“理解以下观点你就能理解这个领域。”这句话不适合测试这个领域，并且，测试规范的开发不是本书要完成的任务。
本书对你可能会有所帮助。本书在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都出版了相关主题的书，我的教授却没有教我测试方面的知识。随着软件工程的下半世纪的开始，这种状况最终开始改变。但是，大多数成长中的软件工程师仍然很少学习有关测试方面的知识。
．测试不是在真空中进行的。相反， 它是整个项目的一部分， 因此测试必须和实际项目需求相符，而不是黑客的异想天开。简而言之，测试项目需要对测试项目进行管理。
．“测试太难了。”这种想法的盛行只会增加测试专家面临的困难。一旦我们从痛苦的经历中明白了测试到底有多难，我们有时候就觉得好像是命中注定要一个项目接一个项目地反复解释为什么这个测试任务需要花费这么多时间和金钱。
以上几个方面暗含了很多复杂的因素。其中最重要的因素之一就是组织测试过程的成熟度等级可能发生较大变化：测试可能是一个可重复的、可度量的过程的一部分，或者对一个混乱项目的亡羊补牢。另外，动机因素(也就是管理为什么会干扰测试的原因)在重点和强度上都可能发生改变。 因为害怕重复近期的失败项目而萌发测试动机的测试经理与尽可能生产出好的产品的经理对待测试的态度是不同的，而两种动机都不同于那些被迫进行测试但并不重视测试的人的动机。最后，测试还和项目的其他部分紧密相关， 因此测试经理经常遭到外界的各种影响。 当测试范围和进度的改变在项目中引起较大变动时，这些影响并不总是良性的。
上述因素使得开发一个关于“如何”计划和执行测试项目的指南非常困难。正如学者们可能说的那样，测试项目管理不是简单开发一个规范。“理解以下观点你就能理解这个领域。”这句话不适合测试这个领域，并且，测试规范的开发不是本书要完成的任务。
评论交流
共有9人开贴评论 11人参与评论 5人参与打分 查看
评价等级：
发表于：2004-10-14 16:16:00
这本书其他出版社出过：北京大学出版社《测试流程管理》
是我所知的，国内出版的最早的、实用的讲测试管理的书。那是3年前的事情了。
这本书不错，事实是，我根据书上讲的，成功的实践了其中的部分过程和原则，持续2年时间，最大团队规模14人。我被认为是长于测试管理，咳咳，我不过是按照书上说的，并坚持实践了而已。侥幸，我带领的测试组测试的产品，在整个研发团队的集体努力下，成了公司最成功的产品，去年销售额达4.5个亿。之所以说侥幸，是因为测试工作真是胆战心惊，如履薄冰的。
现在我已经不再带测试团队了，怀念实践rex的方法的日子。
5颗星给rex black 。
这个版本的书，我没看过，所以无法评价这个版本的翻译、编辑质量。
北大出版社的那个版本，质量优良，还配了一张光盘【内含各种书中涉及到的表格模板，比较有用，我直接翻译了其中测试执行跟踪表，拿到公司用，现在成了我所在公司测试文档的标准模板－－不过我没有告诉我的同事们来源 :P】
书的价格是贵，但确实值。
是我所知的，国内出版的最早的、实用的讲测试管理的书。那是3年前的事情了。
这本书不错，事实是，我根据书上讲的，成功的实践了其中的部分过程和原则，持续2年时间，最大团队规模14人。我被认为是长于测试管理，咳咳，我不过是按照书上说的，并坚持实践了而已。侥幸，我带领的测试组测试的产品，在整个研发团队的集体努力下，成了公司最成功的产品，去年销售额达4.5个亿。之所以说侥幸，是因为测试工作真是胆战心惊，如履薄冰的。
现在我已经不再带测试团队了，怀念实践rex的方法的日子。
5颗星给rex black 。
这个版本的书，我没看过，所以无法评价这个版本的翻译、编辑质量。
北大出版社的那个版本，质量优良，还配了一张光盘【内含各种书中涉及到的表格模板，比较有用，我直接翻译了其中测试执行跟踪表，拿到公司用，现在成了我所在公司测试文档的标准模板－－不过我没有告诉我的同事们来源 :P】
书的价格是贵，但确实值。
)
加载中...| 我要写评论 |
| 查看所有评论交流(共9条) |
