这本书看了一半，内容还是比较充实的，从软件测试概念、找bug的核心思维、测试设计、测试架构到测试需求分析和测试策略制定、测试方案的设计，其中有些比较浅显易懂，有些却比较抽象生涩，就像测试架构的设计，只能感性的了解一些，可能自己目前的心智还不够吧。想想把所有看到的都记下来也不免有些枯燥和乏味。所以就挑一点感触比较深的记录一下。
1.测试的三重境界：
第一重：围着bug转，主要包含3个阶段，发现bug、定位bug和回归bug。首先就是使用各种办法找bug。在发现了bug之后，可以以最短的路径复现bug，方便开发人员定位分析，自己也要努力搞清楚bug产生的原因，如果涉及到比较技术的，试着去了解原因，书中说到微软公司的测试会自己调试程序找到问题并给出开发人员解决方案，这种感觉很牛逼啊，这个感觉我是不可能实现了，如果这样应该要先转开发几年，还要是个牛逼的开发，再转回来做测试吧。对于已经发现的问题，要及时的追踪，只有bug被解决了，软件质量才会得到提升。所以要经常查看buglist，和开发沟通bug解决的进展。
第二重：站在bug之上。在一定的成本与时间的前提下，测试需要站在用户的角度，进行常用模块的重点测试，避免非常用功能的过度测试。采用合理全面的测试方法，验证软件是否符合用户需求。通过2-8原则，实现测试成本和时间的效益最大化。80%的错误是由20%的模块引起，80%的测试成本花在20%的软件模块中，80%的测试时间花在20%的软件模块中。
第三重：挑战零缺陷。测试需要变被动为主动，在设计之前，就做好设计的防患措施。相对于堵缺陷，防止于未然更加重要。第一是尽量在需求阶段、设计阶段，发现问题，第二是从已有的bug中追本溯源，找出问题的根源，提示防范措施。我认为软件这个零缺陷的思想有点和身体类似，身体健康重要的是预防疾病，或者从已有的疾病例如感冒中吸取一些教训，多做一些预防的操作。这样整个软件质量更有保障，测试不用一直堵bug精疲力尽，开发也不用修bug到身心疲惫。而且成本和时间的开销也会减小。
2.测试需求
什么是测试需求？测试需求的来源不仅包含了产品需求，除了产品需求，还有可靠性需求，设计需求，可测试性需求，这些都可以转化为测试需求。测试需要从多种途径收集需求，越全面越好，善于发现需求中的问题及隐含需求。并要求将零散的需求及问题归档。
可测试性需求：需要有可测试到的数据输出、状态，需要可以控制数据的方式，即有办法输入不同的测试数据或预置数据，需要可操作性，软件易使用，接近用户，需要软件有一定的稳定性，这些和需求的变更、开发的周期、测试发现严重bug的早晚都有关系。遇到可测试性需求的问题，需要及时提出来。
