根据 需求 ——>设计 测试——> 执行程序

保证测试和需求重叠——关注测试结果:没有缺陷既没有问题;

》现实问题:
Myers(迈瑞斯):“测试只能证伪,但不能证真”
-
换言之:“测试没有发现缺陷,不等于没有缺陷;测试发现了缺陷当不能保证该缺陷是否是软件中的最后一个缺陷,我们无法保证程序中永远没有缺陷!”
测试现实压力: 时间、成本、质量
测试目标
- 在最短的时间内、找到最严重、最多的缺陷,最大程度保证产品符合已知用户需求。
- 基于风险最低,效率最高,分而治之的测试设计原则
- 测试用例就是
1.能代表需求的小的测试单元
2.描述用户预期输出
3.反应系统实际执行结果

测试用例的基本属性
-
典型性:能揭示最有可能存在缺陷的地方,能代表和覆盖合理与不合理,合法与不合法的情况。(有利于发现最高风风险的缺陷)
-
可测试性:一个测试用例的预期输出必须是可以检测的,可以根据相关开发文档得到明确的,可判定的结论。
-
可重现性:对于相同的测试用例,系统的预期执行结果应该完全相同,否则,如果系统预期输出存在不确定性。一旦实际运行该测试用例,也无法进行校验。
-
独立性:测试用例应尽量独立。
(相互关联的测试用例给执行结果带来了不确定性,增大了执行结果检验和缺陷定位的难度——不是必须具备的)
网友评论