软件测试的“潜规则”
在多个培训中,我都会与学员探讨测试的七项基本原则,发现自己所举出的例子都是反面的,思考一下这个问题,为何我们在一些基本原则上仍然Hold不住?是不是有些“潜规则”在作祟?因而,发起这个话题,讨论测试的“潜规则”。 先看看ISTQB的“测试七项基本原则”: 原则1:测试指出缺陷的存在——测试没有发现缺陷并不意味着不存在缺陷 原则2:穷尽测试是不可能的 原则3:测试要尽早介入 原则4:缺陷集群性——大多数缺陷总是发生在少量模块/特性上 原则5:杀虫剂悖论 原则6:测试活动依赖于测试Context 原则7:“Absence-of-errors ”(无错就是好)谬误 总结一下偏离这些基本原则的潜规则,如下: 潜规则1:可以规划软件中缺陷的数量 - 使用千行代码缺陷密度做为过点要求 - 缺陷密度降低被认为是质量改善 潜规则2:测试周期总是可以压缩的 - 计划是倒排的,但开发周期延长,测试还是要保证按时完成 - 实在无法压缩的话,通过外包一批完全不懂测试的人也可以搞定 潜规则3:测试在前期的工作只能是学习 - 测试只需要在后端介入,前端投入是浪费人力 - 系统设计与测试无关,不能测的话自己想办法 ...
