仅仅尽大的努力是不够的。你必须知道要做什么，然后再尽大的努力。  ——爱德华 戴明
　　没有记录不能断定什么时间确实发生过。 ——弗吉尼亚 伍尔夫
　　这部分，我们将把软件测试的知识联系起来，说明和软件测试有关的所有工作是如何计划、如何组织以及如何和项目小组之间进行交流的。
　　软件测试计划是软件测试员与产品开发小组交流意图的主要方式。IEEE关于软件测试文档的标准以如下方式表达软件测试计划的目的：
　　规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险。
　　这里我们在回顾一下对于软件缺陷（bug）的定义：
　　1）软件为实现产品说明书要求得功能
　　2）软件出现了产品说明书不应该出现的错误
　　3）软件实现了产品说明书未提到的功能
　　4）软件为实现产品说明书虽未明确提及但应该实现的目标
　　测试用例计划目标：
　　1）组织。正确的计划会组织好用例，以便全体测试员和其他项目小组成员有效的审查和使用。
　　2）重复性。我们已经知道，在项目期间有必要多次执行同样的测试，以寻找新的软件缺陷，保证老的软件缺陷得以修复。
　　3）跟踪。
　　4）测试证实。在少数搞风险行业中，软件测试小组必须证明确实执行了计划执行的测试。发布忽略某些测试用例的软件实际上是不合法的和危险的。正确的测试用例计划和跟踪提供了一种证明测试内容的手段。
　　测试用例应该包含的主要内容：标示符、测试项、输入说明、输出说明、环境要求、特殊过程要求和用力之间的依赖性。
　　* 为什么所有软件缺陷不一定都能修复
　　a. 测试小组没有足够的时间，测试人员太少没法满足所有的功能都进行测试的要求
　　b. 不算真正的软件缺陷，很多情况下，理解错误、测试错误或者说明书变更会把可能的软件缺陷当做功能对待。。
　　c. 修复的风险太大，很多情况下，软件本身是非常脆弱的、难以理清头绪，有可能修复了这个缺陷却又出来了更多的问题。在紧迫的产品发布进度压力下，修改软件将冒很大的风险。
　　d. 不值得修复，在实际的软件测试中，有些不常用的，不常出现的软件缺陷是可以放过的。
　　e. 无效的软件缺陷修复报告，测试人员没有建立足够强大的测试用例，以为已经把软件缺陷修复了，然而并没有
　　* 如何使找出的软件缺陷尽量得以恢复
　　a. 尽快报告软件缺陷
　　b. 有效的描述软件缺陷：短小、单一
　　c. 在报告软件缺陷是不要做评价
　　d. 对软件缺陷报告跟踪到底
　　* 可以用哪些技术分离和再现软件缺陷
　　不要想当然的接受任何假设。记下所做的每一件事——每一个步骤、每一次停顿、每一件工作。
　　查找时间依赖和竞争条件问题。软件缺陷仅在特定时刻出现嘛？也许它取决于输入数据的速度
　　边界条件软件缺陷、内存泄露和数据溢出等白盒问题可能会慢慢自己显露出来
　　状态缺陷仅在特定软件状态中显露出来。
　　考虑资源依赖性和内存、网络、硬件共享的相互作用、
　　不要忽视硬件。
　　* 软件缺陷的生命从出现到消失像什么
　　很想昆虫的生命周期，软件缺陷的生命周期像是这样： 发现缺陷-->打开-->解决-->关闭