《软件测试的艺术》是一本由梅尔斯著作，机械工业出版社出版的平装图书，本书定价：22.0，页数：122 页，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《软件测试的艺术》精选点评：
●没学过软测有点疼... 每天看一章很快就可以看完；明概念，尚需实践
●工具书，过一遍概念
●就是太薄了
●都是废话
●图书馆有
●对测试有个基本的认识，经典书就是不一样
●这本书写的简短，很容易理解。之前的那本丢了，好想再买一本呀。
●没有软件测试基础，用这本书来做科普
●泛读
●做测试工作近6年了，重读此书 1，测试是为了发现错误，而不是为了求证 2，代码检查和白盒测试是重要的一部分，不能只做黑盒测试
《软件测试的艺术》读后感(一)：华丽的概论课什么的真的可以么
软件测试的艺术这本书只草草看了一遍，虽然本身是计算机系，却只是半吊子，所以对书中提到的理论能看懂，却并没有太多印象。
我至今仍记得Java老师在忽悠了我们半年之后说，其实我给你们上这个课只是告诉你们有Java这个东西。
这本书大抵也是这样的作用，给没有软件测试概念的人一个概念，给想了解软件测试的人一种思路，给企图应征软件测试却没有任何经验的人一点谈资。
经典之所以经典，就是因为其浅显易懂，背后却包藏着大智慧。
《软件测试的艺术》读后感(二)：完美主义者眼中的软件测试
本书的观点与传统软件测试理论形成了鲜明的对比，作者提出：软件测试的目的不是为了验证软件能够达到设计文档的要求，而是为了发现软件错误而运行软件的过程。当我刚开始学习测试技术的时候，很为该观点所动，但随着工作经验的增长，发现实际操作中无论是组织还是个人都很难达成作者的美好目标。毕竟，公司的预算、资源都很难让测试人员有机会进行所谓的完美测试。但，不管怎样，本书中提到的软件测试方法论对于任何一个从事软件测试甚至是开发人员都是大有裨益的。
推荐，5颗星！
《软件测试的艺术》读后感(三)：软件测试的原则
软件测试的10个原则：
测试用例中一个必需部分是对预期输出或结果进行定义
程序员应当避免测试自己编写的程序
编写软件的组织不应当测试自己编写的软件
应当彻底检查每个测试的执行结果
测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况
检查程序是否“未作其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
应避免测试用例用后即弃，除非软件本身就是一个一次性的软件
计划测试工作时不应默许假定不会发现错误
程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
软件测试时一项极富创造性、极具智力挑战性的工作
《软件测试的艺术》读后感(四)：刚刚看完 有收获
每天花1个小时，一周就可以看完。
该书历史悠久，1979年第一版，2004年（估计）第二版，可见其生命力。工具，环境语言都在变化，但是根本的测试思想没有变。怪不得有人称该书为测试领域的"开山鼻祖"。
该书信息密度不低，第一章以一个小测试作为引子，第二章阐述全书的核心思想，后面各章就讨论了详细的方式方法。所谓详细也是相对而言，能打下进一步学习的基础就足够了。实例很少，偏向于原则、理论、概念。
个人感觉有没有开发测试经验的都能看懂。
如果想应聘测试工程师，也可以作为恶补书籍，也是就该书小而全：）
最大的收获：
1.测试是为了发现错误而执行程序的过程。正向测试验证功能，但核心内容是反向测试，发现错误。
测试人员首先要直觉认为被测物有错误需要去发现。
2.从心理学观点论述了为什么开发人员不能做测试。以及如何逐渐一个合理的团队，最好是独立的测试部门。
3.能发现错误的测试用例才是成功的用例。 全部测试用例通过，不能作为测试结束的标志。给出了3个测试结束准则。
4.该书多次提到，任何方式方法都有局限性，需要对不同问题采取不同的方法。
5.调试（Debug）一章强调了用思考去解决问题，而非大量的print,trace和debugger的内存观察。有时人会偷懒而采取暴力调试，及不去思考，胡乱修改代码来猜测问题。
调试方式也是启发式解决问题的方法。
6.两次提到“采集-分析-汇总-提高”。及开发、测试过程要留心去总结提高，建立项目和个人的 bug、易犯错误表，调试错误分析表等。
7.增量测试和XP方法: 做事先有计划，然后由小到大，一步一个脚印，后一步踩在前一步上。
8.测试过程有很多方法都需要经验和直觉。测试是个复杂的脑力劳动。
《软件测试的艺术》读后感(五)：读书笔记
1. 测试是为了发现错误而执行程序的过程。
2. 软件测试的原则
（1）测试用例中必须包含对预期输出或结果的定义。
（2）程序员或组织应避免测试自己编写的程序。
（3）应仔细检查每个测试的执行结果。
（4）测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况。
（5）检查程序是否“未做其应该做的”仅是成功的一半，测试的另一半是检查程序是否“做了其不应该做的”。
（6）应避免测试用例用后即弃。
（7）进行测试工作时不应事先假定不会发现错误。
（8）程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
3. 测试策略
（1）如果规格说明中包含输入条件组合的情况，应首先使用因果图分析法。
（2）在任何情况下都应该使用边界值分析方法，对输入和输出边界进行分析。
（3）为输入和输出确定有效和无效等价类，补充测试用例。
（4）使用错误猜测技术补充测试用例。
（5）使用多重条件覆盖准则检查程序的逻辑结构
4. 多重条件覆盖准则：将每个判定中的所有可能的条件的组合，以及所有的分支入口点都至少执行一次（不能保证对所有可能的路径都走一次）。
5. 测试结束的准则
第一类
模块测试的结束准则：
（1）满足多重条件覆盖准则。
（2）对模块接口规格说明进行边界值分析的所有测试用例都通过。
功能测试的结束准则：
（1）因果图分析，（2）边界值分析，（3）错误猜测的所有测试用例都通过。
第二类：以确切的数量来描述结束测试的条件。
第三类：记录单位时间内发现的错误数量，通过检查统计曲线的形状来判定测试是否应结束。
6. 调试的原则
（1）动脑筋
（2）如果遇到僵局，就留到稍后解决
（3）把问题描述给别人听
（4）仅将调试工具作为头脑思考的辅助手段
（5）避免使用试验法
（6）改正错误时增加的代码比程序中原有的代码更易发生错误
（7）应修改源代码，而不是目标代码
7.极限编程的12个实践
（1）市场和业务开发人员在一起以场景的形式编写软件需求并确定优先级
（2）小规模地、递增地发布
（3）系统隐喻
（4）简要设计
（5）连续测试
（6）重构
（7）结对编程
（8）代码的集体所有权
（9）持续集成
（10）每周40小时工作
（11）客户在现场
（12）按标准编码
归纳为4个概念：
（1）聆听客户和其他程序员的谈话
（2）与客户合作，开发应用程序的规格说明和测试用例
（3）结对编程
（4）测试代码库