今天重读《软件测试》这本书，感受颇深，以前学习过，当干了一年测试以后，重读这本书，感觉理解得更好了，于是想重新细读，然后把笔记写下来，以后方便查看。
今天从床上爬起来，首先细细品味这第一章，主要是测试的概述。基本讲了这么几个问题：
1、几个术语：
a、错误：等同于过错，例如，我们在编码的时候会出现错误。有个很重要的一点是，错误可能扩散。
例如：需求时的错误在设计阶段可能被放大，在编写代码阶段还会进一步放大。（也许这就是为什么要越早发现bug越好，在后期对bug的维护或者修改花费的代价是前期发现付出的代价的几倍）。
b、缺陷：缺陷是错误的结果。缺陷是错误的表现。可以这样理解，如果在编码上出现了一个错误，那么可以导致在功能实现上出现缺陷。缺陷还可以分为：过错缺陷和遗漏缺陷。遗漏缺陷更难检测和解决。
c、失效：当缺陷执行时会发生失效。
d、事故：当失效发生时，可能会也可能不会呈现给用户（或客户或测试人员）。
综合以上：他们之间是有因果关系的。举个简单的例子，如果编码人员（其实不一定是编码人员出了错）在编写程序是出了个错误，那么就可能导致某个功能没有实现，没有实现的功能就是软件中的一个缺陷，那么在这个缺陷（没有被实现或者很好实现的功能）被执行的时候，软件表现出来的就是不起作用，就是失效，严重的情况下，就会给客户造成事故。
另外，通过评审可以发现缺陷，避免很多失效的发生，有效的评审，可以发现遗漏缺陷。
e、测试：测试就是一个处理错误、缺陷、失效、事故的过程。是一个采用测试用例执行软件的过程。测试的两个显著的目标：找出失效（为了提高软件本身的质量），或演示正确的执行（针对客户，让客户放心地去接受你的软件，比如客户的验证性测试）。（其实就是一个找出软件中的错误去更正并向客户证明我的软件是正确的能满足客户要求的）。
注：括号里是我的理解，请批评指正。
d、测试用例：测试用例最基本的应该包括，一个测试用例标识，输入和预期输出。其中输入又包括前提条件（就是执行这个测试用例之前已经存在的环境）和由某种测试方法标识的实际输入。预期结果也有两类：后果和实际输出。
测试活动要建立必要的前提条件，提供测试用例的输入，观察输出，然后将这些输出和预期输出进行比较，以确定测试是否通过。
一个良好的测试用例还应该包括执行历史：执行日期、结果、版本、执行人。
2、测试的生命期模型：
大概分三个阶段：引入程序错误、找出程序错误、清除程序错误
引入程序错误：需求规格说明、设计阶段、编码阶段 都是引入程序错误的阶段。
找出程序错误：测试阶段
清除程序错误：缺陷分类、缺陷隔离、缺陷解决。
其中缺陷解决这个步骤又是一个引入新缺陷的机会（比如在修改原来的bug的时候，导致了原来正确的地方又出现了新的缺陷，这就是为什么测试总是要进行回归测试）。
3、测试过程：测试计划、测试用例开发、运行测试用例、评估测试结果。
4、利用韦恩图理解测试最后得到结论：
功能性测试只利用规格说明标识测试用例，而结构性测试（白盒）使用程序源代码（实现）作为测试用例标识的基础。两种方法单独使用都是不充分的。
考虑程序行为：如果所有已描述行为都没有被实现，则结构性测试永远也不会认识到这一点。反过来，如果程序实现了没有被描述的行为，功能性测试永远也不会认识到这一点（病毒就是这种为描述行为的很好的例子）。所以这两种方法都需要。
明智的组合会带来功能性测试的置信，以及结构测试的度量。
