测试的原则.ppt

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