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