具体描述
路遥知马力，日久见人心。本书从第1版付梓到现在已经30余年，尽管这30年来计算机软硬件都发生了显著的变化，但是这本书经受住了时间的考验，显示出强大的生命力。市面上多半的软件书籍都偏重于讲流行的开发技术、编程语言以及测试方法，往往是风光一阵不再，而这本书却像醇香的好酒历久弥新。这一次修订的第3版仍然延续之前的写作风格，结构和语言简明扼要，全面而细致地展示了那些久经考验的软件测试方法和智慧。如果你参与重要的软件项目开发，对本书仔细研读绝对值得，将给你带来长期收益。
第3版阐述了如何将经典软件测试法则应用到解决当今计算机行业所面临的最紧迫的问题之中，这些问题包括：
移动设备的应用测试
各种设备上的软件代码走查、代码审查（从技术以及如何发现错误的角度讨论）
可用性测试（随着直接面向广大终端用户的应用在数量上呈爆发性增长，可用性变得越来越重要）
互联网应用、电子商务和敏捷编程环境的测试
作者简介
Glenford J. Myers，IBM系统研究所前高级研究员，同时还是RadiSys公司的创始人和前CEO。
Tom Badgett，曾经主管大型企业软件开发团队，已出版超过60本关于计算机软件和硬件的技术书籍，同时他还是PcJr,Digital News等主流计算机杂志的技术编辑。
Corey Sandler，计算机新闻的先锋，他曾经负责Gannett Newspapers 和the Associated Press的技术部分以及之后成为Pc Magazine的第一任主编。他同时还是Digital News（针对DEC小型机的一份报纸）的编辑创始团队成员，他著作等身，目前已经出版了超过150本书籍，覆盖了从计算机到商业以及很多其他领域。
目录信息
序言
前言
第1章 一次自评价测试
第2章 软件测试的心理学和经济学
2.1 软件测试的心理学
2.2 软件测试的经济学
2.2.1 黑盒测试
2.2.2 白盒测试
2.3 软件测试的原则
2.4 小结
第3章 代码检查、走查与评审
3.1 代码检查与走查
3.2 代码检查
3.2.1 代码检查小组
3.2.2 检查议程与注意事项
3.2.3 对事不对人，和人有关的注意事项
3.2.4 代码检查的衍生功效
3.3 用于代码检查的错误列表
3.3.1 数据引用错误
3.3.2 数据声明错误
3.3.3 运算错误
3.3.4 比较错误
3.3.5 控制流程错误
3.3.6 接口错误
3.3.7 输入/输出错误
3.3.8 其他检查
3.4 代码走查
3.5 桌面检查
3.6 同行评审
3.7 小结
第4章 测试用例的设计
4.1 白盒测试
4.2 黑盒测试
4.2.1 等价划分
4.2.2 一个范例
4.2.3 边界值分析
4.2.4 因果图
4.3 错误猜测
4.4 测试策略
4.5 小结
第5章 模块（单元）测试
5.1 测试用例设计
5.2 增量测试
5.3 自顶向下测试与自底向上测试
5.3.1 自顶向下的测试
5.3.2 自底向上的测试
5.3.3 比较
5.4 执行测试
5.5 小结
第6章 更高级别的测试
6.1 功能测试
6.2 系统测试
6.2.1 能力测试
6.2.2 容量测试
6.2.3 强度测试
6.2.4 可用性测试
6.2.5 安全性测试
6.2.6 性能测试
6.2.7 存储测试
6.2.8 配置测试
6.2.9 兼容性/转换测试
6.2.1 0安装测试
6.2.1 1可靠性测试
6.2.1 2可恢复性测试
6.2.1 3服务/可维护性测试
6.2.1 4文档测试
6.2.1 5过程测试
6.2.1 6系统测试的执行
6.3 验收测试
6.4 安装测试
6.5 测试的计划与控制
6.6 测试结束准则
6.7 独立的测试机构
6.8 小结
第7章 可用性（或用户体验）测试
7.1 可用性测试基本要素
7.2 可用性测试流程
7.2.1 测试用户的选择
7.2.2 需要多少用户进行测试
7.2.3 数据采集方法
7.2.4 可用性调查问卷
7.2.5 何时收工，还是多多益善
7.3 小结
第8章 调试
8.1 暴力法调试
8.2 归纳法调试
8.3 演绎法调试
8.4 回溯法调试
8.5 测试法调试
8.6 调试的原则
8.6.1 定位错误的原则
8.6.2 修改错误的技术
8.7 错误分析
8.8 小结
第9章 敏捷开发模式下的测试
9.1 敏捷开发的特征
9.2 敏捷测试
9.3 极限编程与测试
9.3.1 极限编程基础
9.3.2 极限测试：概念
9.3.3 极限测试的应用
9.4 小结
第10章 互联网应用测试
10.1 电子商务的基本结构
10.2 测试的挑战
10.3 测试的策略
10.3.1 表示层的测试
10.3.2 业务层的测试
10.3.3 数据层的测试
10.4 小结
第11章 移动应用测试
11.1 移动环境
11.2 测试面临的挑战
11.2.1 移动设备多样性
11.2.2 运营商网络基础设施
11.2.3 脚本编程
11.2.4 可用性测试
11.3 测试方法
11.3.1 真机测试
11.3.2 基于模拟器的测试
11.4 小结
附录A极限编程示例程序
附录B小于1000的素数
· · · · · · (收起)
读后感
本书的观点与传统软件测试理论形成了鲜明的对比，作者提出：软件测试的目的不是为了验证软件能够达到设计文档的要求，而是为了发现软件错误而运行软件的过程。当我刚开始学习测试技术的时候，很为该观点所动，但随着工作经验的增长，发现实际操作中无论是组织还是个人都很难达...
评分软件测试的10个原则： 测试用例中一个必需部分是对预期输出或结果进行定义 程序员应当避免测试自己编写的程序 编写软件的组织不应当测试自己编写的软件 应当彻底检查每个测试的执行结果 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入...
评分软件测试的艺术这本书只草草看了一遍，虽然本身是计算机系，却只是半吊子，所以对书中提到的理论能看懂，却并没有太多印象。 我至今仍记得Java老师在忽悠了我们半年之后说，其实我给你们上这个课只是告诉你们有Java这个东西。 这本书大抵也是这样的作用，给没有软件测试概念的...
评分软件测试的10个原则： 测试用例中一个必需部分是对预期输出或结果进行定义 程序员应当避免测试自己编写的程序 编写软件的组织不应当测试自己编写的软件 应当彻底检查每个测试的执行结果 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入...
评分软件测试的艺术这本书只草草看了一遍，虽然本身是计算机系，却只是半吊子，所以对书中提到的理论能看懂，却并没有太多印象。 我至今仍记得Java老师在忽悠了我们半年之后说，其实我给你们上这个课只是告诉你们有Java这个东西。 这本书大抵也是这样的作用，给没有软件测试概念的...
用户评价
在我翻开《软件测试的艺术》之前，我一直认为软件测试不过是找 bug 的例行公事，一种 Mechanical 的过程，充其量算是个“技术工种”。这本书的开篇就如同一记醍醐灌顶，它用一种近乎哲学的高度，将测试从单纯的“发现错误”提升到了“理解软件本质”、“保障用户体验”乃至“促进软件质量文化”的全新维度。我尤其被作者对于“测试思维”的阐述所吸引，那是一种超越具体方法论的、对潜在风险的敏锐洞察力，一种对用户行为的深刻同理心，以及一种对代码背后逻辑的严谨拷问。书中并未仅仅罗列各种测试类型或工具，而是着重探讨了如何在复杂的项目环境中，如何根据不同的需求、不同的团队、不同的产品生命周期阶段，灵活地选择和组合测试策略。它强调的不仅仅是“怎么测”，更是“为什么测”、“测什么”以及“如何让测试的价值最大化”。我开始重新审视自己过去的工作，那些我曾认为理所当然的测试步骤，在作者的笔下，都有了更深层的含义和更具智慧的解读。例如，关于回归测试，书中并非简单地介绍自动化脚本的编写，而是深入分析了回归测试的“目的性”和“有效性”，如何构建一个既能保证稳定又不过度消耗资源的回归测试集，以及在敏捷开发中，如何让回归测试真正成为“加速器”而非“绊脚石”。这种对细节的关注和对宏观的把握，让我对软件测试有了前所未有的敬畏感。
评分《软件测试的艺术》在关于“测试与开发协作”的部分，着实让我耳目一新。我以往的经验中，测试团队常常被视为“质量的把关者”，与开发团队之间存在着一种天然的“对立”关系，测试发现问题，开发修复问题，这种模式常常导致沟通不畅和效率低下。但这本书将测试视为“整个软件开发生命周期中不可或缺的一部分”，强调了测试人员与开发人员之间的“伙伴关系”。作者详细阐述了如何在敏捷开发流程中，实现测试与开发的深度融合，例如，通过“测试驱动开发（TDD）”和“行为驱动开发（BDD）”等实践，让测试在开发早期就介入，甚至成为开发的一部分。书中还深入探讨了如何建立一个开放、高效的沟通机制，如何通过共享信息、共同目标来消除隔阂。我尤其赞赏书中关于“移向左侧（Shift-Left）”的理念，即尽早地将测试活动融入到开发过程中，从而在更早的阶段发现和解决问题，降低修复成本。这让我重新思考了测试团队的角色和价值，我们不应该仅仅是“发现问题的人”，更应该是“预防问题、提升质量的驱动者”。
评分当我合上《软件测试的艺术》这本书时，我感到一种前所未有的充实和启迪。它不仅仅是一本关于软件测试方法的教科书，更是一本关于“软件质量哲学”的宣言。我从书中收获的不仅仅是各种测试技术的应用，更是对测试本身价值的深刻理解，以及对如何成为一名更优秀的测试工程师的清晰认知。作者的语言风格幽默且富有洞察力，将那些复杂的技术概念解释得深入浅出，引人入胜。我开始重新审视自己过往的测试工作，并将书中提到的许多理念融入到日常实践中。我更加理解了“测试不是为了找Bug，而是为了创造价值”的真谛。这本书让我明白，优秀的软件测试，需要技术、经验、沟通、协作以及最重要的——持续学习和不断精进的精神。它激励我不断探索新的技术，不断提升自己的思维方式，努力成为一名能够真正为软件质量贡献力量的“艺术家”。
评分我必须承认，在读《软件测试的艺术》之前，我对“探索性测试”的理解非常模糊。我总是觉得这是一种“随意”的测试方式，缺乏系统性和可重复性，似乎是技术不够成熟的测试人员的无奈之举。然而，这本书彻底颠覆了我的认知。作者将探索性测试描述为一种“基于经验、知识和创造力的即时测试设计和执行”，它强调的是测试人员的智慧、直觉以及对被测系统深入的理解。书中通过生动的案例，展示了经验丰富的测试工程师如何通过对系统进行“探索”，快速发现隐藏的、难以通过脚本化测试暴露的问题。这不仅仅是“点点鼠标”，而是对软件行为模式的深刻理解，对用户使用场景的模拟，以及对异常情况的预判。作者还详细阐述了如何有效地记录探索性测试的过程和发现，如何将这些非结构化的测试活动转化为有价值的反馈，并为未来的测试设计提供灵感。我尤其欣赏书中对于“测试日志”的讨论，它不仅仅是简单的操作记录，更是一种思维过程的体现，一种对发现和学习的沉淀。这让我意识到，探索性测试并非“无头苍脑”，而是需要高度的技巧和经验的积累。这本书让我开始重新评估“经验”在测试中的价值，并且鼓励我走出舒适区，拥抱那些更具挑战性、更需要智慧的测试方法。
评分《软件测试的艺术》中关于“安全测试”的部分，虽然篇幅不长，却给我留下了极其深刻的印象。我一直认为安全测试是安全专家的事情，与我们普通测试人员关系不大。但书中却强调了“安全是质量的重要组成部分”，并呼吁每一位测试人员都应该具备基本的安全意识。作者简要介绍了各种常见的安全漏洞，如SQL注入、跨站脚本攻击等，并阐述了在日常测试中，如何通过一些简单的技巧，来发现这些潜在的安全隐患。我尤其被书中关于“安全思维”的培养所吸引，要时刻警惕软件中可能存在的安全风险，并在测试过程中主动去探索和验证。虽然我目前的技术能力还不足以进行专业的安全渗透测试，但这本书让我意识到，安全意识的培养是每个人都需要拥有的，并且在软件开发的全过程中都应该得到重视。这为我打开了另一扇认识软件质量的窗户，让我看到了隐藏在代码深处的另一种重要价值。
评分我一直对“测试设计”这个概念感到有些抽象，在阅读《软件测试的艺术》之前，我以为测试设计就是列出测试用例。然而，这本书让我对测试设计的理解上升到了一个全新的高度。作者将测试设计看作是一种“创造性的过程”，它需要对被测系统的需求、架构、潜在风险有深刻的理解，并在此基础上，设计出能够有效地验证软件质量的测试方案。书中不仅介绍了各种经典的测试设计技术，如等价类划分、边界值分析、因果图等，更重要的是，它强调了这些技术应该如何结合使用，以及在不同的情境下，如何选择最适合的设计方法。我尤其欣赏书中对于“测试用例的可维护性”和“可追溯性”的讨论。一个好的测试用例，不仅仅要能发现问题，更要能够清晰地反映出它所要验证的需求，并且易于修改和更新。作者还探讨了如何利用“风险分析”来指导测试设计，将有限的测试资源投入到风险最高的区域，从而最大化测试的价值。这让我意识到，测试设计并非简单的“填空题”，而是一门需要深思熟虑、逻辑严谨的学问。
评分《软件测试的艺术》中对于“性能测试”的论述，让我对这一领域有了颠覆性的认识。我一直认为性能测试就是模拟大量用户并发访问，然后看看系统会不会崩溃。但这本书却将性能测试描绘成一门“科学与艺术的结合”，它不仅仅是测试工具的使用，更是对系统架构、资源瓶颈、用户行为模式的深刻理解。作者详细介绍了各种性能测试的类型，如负载测试、压力测试、稳定性测试等，并阐述了它们各自的目的和应用场景。我尤其被书中关于“性能测试场景设计”的讨论所吸引，如何根据实际的用户行为和业务流程，构建出逼真且有代表性的测试场景，是至关重要的。书中还提供了很多关于性能瓶颈分析和调优的实用建议，如何通过监控工具、日志分析等手段，定位性能问题，并与开发团队协作，找到最优的解决方案。这让我意识到，性能测试并非简单的“跑数据”，而是需要深入的分析能力和跨团队的协作能力，才能真正保障软件在面对高并发时的稳定性和响应速度。
评分我在阅读《软件测试的艺术》的过程中，对于“测试度量与报告”的章节印象尤为深刻。我之前总觉得测试报告只是一个简单的总结，列出测试执行了多少用例，发现了多少bug，通过率是多少。但作者却将测试度量与报告提升到了“沟通价值、驱动改进”的层面。书中详细介绍了各种常用的测试度量指标，例如测试覆盖率、缺陷密度、缺陷逃逸率等，并分析了这些指标的意义和局限性。更重要的是，作者强调了如何根据不同的受众（管理层、开发团队、产品经理），来定制化地呈现测试报告，确保信息的清晰传达和有效利用。我尤其赞赏书中关于“数据可视化”的讨论，通过图表和图形，能够更直观地展示测试的进展和质量状况，更容易引起关注和共鸣。此外，作者还探讨了如何利用测试度量来识别过程中的瓶颈，并为持续改进提供依据。这让我意识到，一份有价值的测试报告，不仅仅是数据的堆砌，更是对软件质量现状的深刻洞察，以及对未来改进方向的有力指引。
评分在阅读《软件测试的艺术》时，关于“用户体验测试”的部分，让我深刻地感受到了作者对用户需求的深刻洞察。我一直以来，都将用户体验测试视为一种“辅助性”的测试，主要关注界面的美观和操作的流畅。但作者却将其提升到了“评估软件是否真正满足用户需求、是否能带来良好使用感受”的战略高度。书中详细阐述了如何从用户的角度出发，设计测试用例，关注易用性、可访问性、用户满意度等多个维度。我尤其欣赏书中关于“可用性测试”的实践方法，通过观察真实用户与软件的交互过程，发现潜在的问题和不便之处。作者还强调了测试人员需要具备的“同理心”，要能够站在用户的立场思考，理解用户的期望和痛点。这让我意识到，优秀的用户体验是软件成功的关键，而测试人员在其中扮演着至关重要的角色，我们不仅要测试软件的功能是否正确，更要关注它是否能为用户带来愉悦、高效的使用体验。
评分《软件测试的艺术》中对于“测试自动化”的阐述，堪称我目前为止读到的最深刻、最全面的论述。我原以为自动化不过是写脚本、跑脚本，用工具代替人工，以此提高效率。但作者却将自动化提升到了“战略层面”，它不是为了自动化而自动化，而是为了“提升整体软件开发效率和质量”而服务。书中详细分析了自动化测试的“投资回报率”，以及如何根据项目的实际情况，选择合适的自动化测试层级（单元、集成、端到端），并对不同层级的自动化测试的优缺点进行了深入的剖析。更令我印象深刻的是，作者强调了“自动化测试的维护性”和“可读性”。一个自动化测试脚本如果难以理解、难以维护，那么它本身就会成为一个负担，而非助力。书中提供了一些非常实用的建议，比如如何设计可复用的测试模块，如何进行清晰的测试数据管理，以及如何构建一个健壮、稳定的自动化测试框架。我开始思考，我们团队目前的自动化测试实践，是否真的达到了“艺术”的境界，还是仅仅停留在“工匠”的层面。这本书给了我很多启发，让我明白，真正的自动化测试，不仅仅是技术的堆砌，更是对软件开发流程的深刻理解和优化。
评分奉旨读书...全是全，但都是蜻蜓点水。另外翻译有些地方看着就不对头，下了个英文版对照才懂。
评分翻了翻，一般而已，不太对自己的胃口
评分第一本（半）主动读完的专业书籍ORZ
评分奉旨读书...全是全，但都是蜻蜓点水。另外翻译有些地方看着就不对头，下了个英文版对照才懂。
评分不太配得上书名啊……改叫软件测试的基本要素更好，这样我就不买了。
