文档介绍：测试的原则
王雯佳
软件测试的原则
Good enough
Pareto原则
尽可能早的展开测试
在发现错误多的地方投入更多的测试
同化效应
彻底的测试不可能
软件测试是有风险的行为
并非所有的软件错误都能修复
反向思维逻辑
由小到大的测试范围
避免检查自己的代码
追溯至用户需求
Pareto 原则应用于软件测试
20%的模块消耗80%的资源;
20%的模块包含80%的错误;
20%的错误消耗80%的修改成本;
20%的改进包含了80%的适应性为主的成本;
20%的模块占用了80%的执行时间;
20%的工具使用占80%的整个工具使用时间。
要尽早地测试,让测试人员在软件的需求和设计阶段就介入,而不是等这些工作全部完成了才进行测试。
初涉软件测试人员希望拿到软件后就进行完全的测试,找出所有的软件错误,并使软件趋于完美。想法是非常好的,但是实现它是不可能的,哪怕是最简单的程序,主要原因有四个原因:
测试数据输入量太大
输出结果太多
软件的操作步骤太多
软件说明书并非“盲人手册”
如果时间不够,无法进行充分的测试怎么办?
使用风险分析,确定测试的重点!
由于很少有机会对一个应用软件进行所有可能的测试(包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西),对大多数软件开发项目来说,利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由,也可采用正式的方法。