很巧合的，按照一开始的序言建议，历经三个月才把这本书啃完。一方面是每天的时间在分散着用，匀给它的时间屈指可数；另一方面是自身的喜好，我更喜欢阅读纸质书，对于电子书，仅存的耐心是有限的。
不得不说，这本书里有很多值得我学习的地方，并且有不少是我踩过的坑，比如发现bug的时候，应该是尽可能详细地描述问题，帮助开发去更准确地定位和解决问题，而不是将自己的猜想强加给开发，等等。当我踩过的坑重新出现在眼前时，莫名的是一种喜悦，没有什么比遇到一本可读性强的书更值得开心的事情了。
这本书给我最大的启发在于思考角度的转变，思考维度的扩大，不只是停留在自己的一亩三分地。每个人都会认为自己的职业是神圣不可侵犯的，当出现彼此间的利益或者权益冲突时，第一反应是维护自己，而不是反思自己。作为一个不吝啬自我反省的我，在读这本书的过程中，发现我的自我反省在工作上并非是有效和可取的，思维的狭窄，角度的单一和思考方式的老化，使自我反省的效果不佳，导致所谓的经验没有运用在实际工作中，而所谓的教训时常变成打脸的巴掌。
这本书总共有11章，主要针对的是有一定测试经验的人员，而不是新手。分别从测试员本身、测试手段、程序错误分析、自动化、测试文档、管理项目等方面进行阐述。每个章节的重点都有所不同，但又不是完全独立的，彼此之间有一定的联系。比如在与程序员的交互中间，就会涉及到如何正确地去分析程序错误的相关知识；在管理测试项目时，也会涉及管理测试小组的问题。比较有同感的是在前面几章，也就是作为一个测试员的基本素养方面的东西，大多数的教训是在我的工作中已经出现过，而我并没有进行深入思考的。
在阅读的同时，我会跟着去思考自己曾经的做法以及现在的做法，去思考自己存在的一些问题，以及这些问题应该如何正确而有效地去解决或者尝试着去解决。在与程序员交互的那一章里，我看到了自己致命性的问题。以前总是觉得测试工作是重中之重，所以在与程序员的接触中，更多地是会去把问题描述+自我猜测=提bug，而导致bug迟迟定位不到，也得不到有效的解决。这样的付出是无效的，而我自己却从没有反思过是不是我所描述地不够严谨，是不是我误导了他们。脑海里还能回忆出当时跟开发争执的情景。而当我读到这本书中的一些内容的时候，发现是自己的问题更大。对于一个bug的研究停留在表象，并且所做的猜测也是停留在自我认知里，并没有通过更多地依据来证明它的可靠性。思维的转变是在无形中产生的，一个人，一句话，一本书，一个场景都有可能让你发生改变。
除了在测试角色与日常工作内容、与周边相关人员的沟通与协调有较为详细的经验和教训描述外，还在管理和职业发展方面给出了一些很有帮助的经验和教训。对于刚进入管理层或者有意向要往这方面发展的人来说，这是值得借鉴的。作为管理，分成两个部分，一是对事，二是对人。在我看来，这样的顺序是可行的。先把事情规划好，再把人安排到位，才不会做起事情来毫无章法。毕竟人是为了事而存在的。对于项目的管理，应该是从流程上进行，测试项目有一个特点就是受编程项目驱动，而测试员的工作是对程序员工作的反映，这就使得测试工作被赋予服务的特点，而不是控制。但是太多个人存在这样的问题，认为项目的推动在测试，所以测试经理却误把自己当成项目经理，而事实上应该是以合适的角色管理项目，应该发挥耳目作用。先评估自己公司的文化，了解在公司权力等级中的位置，在不被解雇或排斥的限度内发挥作用，给别人带来价值，以此来施展和扩大自己的影响力。必须明确的一点是管理的是提供测试服务的子项目而不是开发项目。这一点是我以前忽略的，在第一家公司的时候，负责三个项目的主导，大家各司其职，我也只关注测试部分，完成得很好。而进入第二家以后，一个人单打独斗，在团队里承受开发的不屑，渐渐地就开始越权了，其实这也是一个我需要吸取的教训：管理的是提供测试服务的子项目，而不是开发项目。还有很多其他非常有效的经验值得学习。而在带人方面，总结来说就是因人而异，主动发现每个人的特点，使其扬长避短。与人相处显然是更复杂的，要做到因人而异不那么容易，但是起码要提供一些可供新人学习和提高的机会，比如参与他们的测试，与他们共同探讨，信息同步；比如积累自己员工的专业领域知识和技术方面的专门知识，交叉学习；比如积极提高他们的技能，为他们提供学习机会；比如不随意让员工加班，注重员工的幸福感等等方面，一个团队的建设，不仅在于专业层面，在精神层面，人文层面都需要注意。这些都是值得去学习和思考的。
最后两个章节就是关于职业规划和计划测试策略。在职业规划上主要是确定自己的方向并不懈地努力，无论是换岗还是继续坚持测试，都需要保证“学习”这个前提。学习更多的相关技能，才能处于不被淘汰的境地，其实这是非常浅显易懂的道理，只是太多人急功近利，总想走捷径，学什么都是去搜攻略：21天快速学会xxxx或者X天从入门到精通。如果通向成功的道路这么容易，那么为什么还有这么多的loser？不得不佩服这些人。我目前对于自己的职业规划也只是限定在两年内，主要是提升专业技能，在转岗方面还没有想法。最后说计划测试策略，老实说，所做的项目以前的是项目来制定，测试计划由客户提供，所以没有什么根据可言，客户说用这个夹具用那个程序，我自己也没有去深入思考过。而在这一章节中提到测试灰盒，是给我挺大启发的，在了解一些内部结构后再来指导外部测试，也就是所谓的知其所以然。测试策略中最基本的三个问题：为什么担心？谁关心？测试多少。我以前只关注测试多少，慢慢地过渡到测试多少+谁关心，看了这个我才明白，还需要：为什么担心。所以原来冗杂的测试策略，现在看来有很多部分是完全不需要的，那些花时间又不重要的测试问题，是完全可以不必放在测试策略里的。测试策略给的是一个整体的指导方向，一种测试设计。感觉自己的专业性还是低段位的，没有系统起来。测试策略在有条件的情况下，还是很有必要做起来的。
写了这么多乱七八糟的话，读后感总结下来就是对自己的一种认识和改进，也是读这本书所受的益处：
- 多方面考虑问题，转变思考模式和角度；
- 关注产品本身，尽可能准确全面地描述问题；
- 学会与程序员和平相处，不卑不亢；
- 测试是否分量低，取决于公司的企业文化。了解测试在公司权力等级中的位置，在不被解雇或排斥的限度内发挥作用，给别人带来价值，以此来施展和扩大自己的影响力。
- 服务于需要测试工作的子项目，而不是控制开发项目的进度；
- 扬长避短，积累专业知识；
- 进行有效地职业规划，在没有明确的方向前，以提高自身专业技能为导向进行学习；
- 培养制定测试策略的意识，找实例进行训练。