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