软件测试技术教学课件作者林连进第三章.ppt

３.５　软件测试原则 (２) 程序员往往犯同样的错误. 每个人都有自己的偏好. 一个程序员总是反复犯自己容易犯的错误. (３) 某些软件故障可能是冰山之巅. 某些看似无关紧要的软件故障可能是由一个极其严重的原因造成的. ５. 杀虫剂现象 １９９０ 年Ｂｏｒｉｓ Ｂｅｉｚｅｒ 在其?软件测试技术(第２ 版)? 一书中引用了“杀虫剂现象” 一词. 用于描述软件测试进行得越多. 其程序免疫力越强的现象. 这与农药杀虫类似. 常用一种农药. 害虫最后就有抵抗力. 农药发挥不了多大的效力. 上一页 下一页 返回 ３.５　软件测试原则 为了避免杀虫剂现象的发生. 应该根据不同的测试方法开发测试用例. 对程序的不同部分进行测试. 以找出更多的软件故障. ６. 并非所有软件故障都能修复 在软件测试中. 令人沮丧的现实是. 即使拼尽全力. 也不能使所有的软件故障都得以修复. 但这并不意味着软件测试没有达到目的. 关键是要进行正确的判断、合理的取舍. 根据风险分析决定哪些软件故障必须修复. 哪些可以不修复. 上一页 下一页 返回 ３.５　软件测试原则 不修复软件故障的原因可能有: (１) 没有足够的时间. 软件产品开发中. 常常在项目进度中没有为测试留出足够的时间. 而软件又必须按时交付. (２) 修复风险太大. 这种情况很常见. 软件本身很脆弱. 修复一个软件故障可能导致其他软件故障的出现. 在紧迫的产品发布进度的压力之下. 修改软件将冒很大的风险. 在某些情况下. 暂时不去理睬软件故障. 以避免出现新的软件故障或许是一个可选的安全之道. (３) 不值得修复. 不常出现的软件故障和在不常用功能中出现的软件故障可以暂不修复. 可以躲过和用户有办法预防或避免的软件故障通常也可以不修复. 上一页 下一页 返回 ３.５　软件测试原则 (４) 可不算数的软件故障. 在某些特殊场合. 错误理解、测试错误或者软件规格说明变更可以把软件故障当作附加的功能而不当作故障对待. ７. 一般不要扔掉测试用例 在使用交互系统进行软件测试时. 常常出现这样的情况: 一个人坐在计算机前. 编写出一些测试用例并用它们对被测程序进行测试. 当再次测试程序时(例如. 改错后或改进了程序后). 就得重新编写测试用例. 由于重新编写测试用例需要大量的工作. 人们多半要回避它. 因此. 对程序的重新测试很少能像原来那样严格. 这意味着. 如果对程序的修改使原先能正确运行的部分出现了故障. 那么这个故障常常不会被发现. 因此. 除非真正没有用处. 一般不要扔掉测试用例. 上一页 下一页 返回 ３.５　软件测试原则 ８. 应避免测试自己编写的程序 开发和测试是两个不同的活动. 开发是创造或者建立一个模块或者整个系统的过程. 而测试是为了确定一个模块或者系统是否因存在故障而不能正常工作的过程. 这两个活动有本质的区别. 一个人不可能把两个截然对立的角色都扮演好. 当一个程序员完成了设计、编写代码的建设性工作后. 要一夜之间改变他的观点. 设法对程序形成一个完全否定的态度. 那是非常困难的. 大部分程序员都不能使自己进入测试状态. 揭露自己程序中隐藏的故障. 因而大部分程序员不能有效地测试自己的程序. 上一页 下一页 返回 ３.５　软件测试原则 除了这个心理学因素之外. 还有一个重要的问题: 程序中可能包含程序员对问题的叙述或说明的误解所产生的故障. 如果是这种情况. 当程序员测试自己的程序时. 往往还会带着 同样的误解进行测试. 这样问题很难被发现. 可以把测试看作对一篇论文或一本著作的评审. 正如许多作者所知. 批评自己的著作是非常困难的. 也就是说. 找出自己的故障往往是人们所不容易接受的. 这并不是说程序员不可以测试自己的程序. 只是相比之下. 由他人进行测试可能会更有效、更成功. 上一页 下一页 返回 ３.５　软件测试原则 ９. 测试工作应该由独立的专业软件测试机构来完成 独立测试是指软件测试工作由在经济和管理上独立于开发机构的组织进行. 独立测试与非独立测势相比具有以下优势: (１) 避免软件开发者测试自己开发的软件. 由于心理学上的原因. 软件开发者难以客观、有效地测试自己的软件. 而找出那些因为对问题的误解而产生的软件故障就更加困难. (２) 避免软件开发机构测试自己的软件. 软件产品开发过程受时间、成本和质量三方面的制约. 时间和成本指标便于衡量. 而质量却很难度量. 因此在软件开发过程中. 上一页 下一页 返回 ３.５　软件测试原则 当时间、成本和质量三者发生矛盾时. 质量最容易被忽视. 如果测试组织与开发组织来自相同的机构. 测试过程就会面临来自与开发组织同一来源的管理方面的压力. 使测试过程受到干扰. 采用独立测试方式. 无论在技术上还是管