qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

软件测试的“潜规则”

在多个培训中,我都会与学员探讨测试的七项基本原则,发现自己所举出的例子都是反面的,思考一下这个问题,为何我们在一些基本原则上仍然Hold不住?是不是有些“潜规则”在作祟?因而,发起这个话题,讨论测试的“潜规则”。

  先看看ISTQB的“测试七项基本原则”:

  原则1:测试指出缺陷的存在——测试没有发现缺陷并不意味着不存在缺陷

  原则2:穷尽测试是不可能的

  原则3:测试要尽早介入

  原则4:缺陷集群性——大多数缺陷总是发生在少量模块/特性上

  原则5:杀虫剂悖论

  原则6:测试活动依赖于测试Context

  原则7:“Absence-of-errors ”(无错就是好)谬误

  总结一下偏离这些基本原则的潜规则,如下:

  潜规则1:可以规划软件中缺陷的数量

    - 使用千行代码缺陷密度做为过点要求

    - 缺陷密度降低被认为是质量改善

  潜规则2:测试周期总是可以压缩的

    - 计划是倒排的,但开发周期延长,测试还是要保证按时完成

    - 实在无法压缩的话,通过外包一批完全不懂测试的人也可以搞定

  潜规则3:测试在前期的工作只能是学习

    - 测试只需要在后端介入,前端投入是浪费人力

    - 系统设计与测试无关,不能测的话自己想办法

  潜规则4:缺陷都应该用“三板斧”来发现

    - 对每个特性,构造满配置、满容量、频繁倒换,Bug马上出现

    - 基本功能的覆盖没有意义,发现不了问题

  潜规则5:姜是老的辣,用例是陈的香

    - 规格变了,用例不需要更新;架构变了,用例不需要更新;需求变了,用例也不需要更新

    - 用了10年没变化的用例被视为“金科玉律”,绝对不能变更

  潜规则6:任何一个测试项目都是可以复制的

    - 做测试策略,先把上个版本的Copy过来,再修改版本号,基本搞定!

  潜规则7:超出设计规格的缺陷都不是缺陷

    - 设计本来就是这样的,这样测就不对

    - 如果有问题是需求的问题,不是缺陷

  那么,做测试的你,被“潜”了吗?

posted on 2013-01-30 12:57 顺其自然EVO 阅读(392) 评论(0)  编辑  收藏 所属分类: 管理方向


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年1月>
303112345
6789101112
13141516171819
20212223242526
272829303112
3456789

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜