软件测试之旅,路漫漫,其修远兮,吾将上下而求索。 <<软测之魂>> 作者 擅长测试设计,嵌入式软件测试,测试自动化,测试体系建设,测试管理, 软件配置管理建设,医疗器械软件测试,教育。 新浪微博@Aullyxiao,邮箱aul516@126.com

如何控制Bug的蔓延--防不胜防的糖衣炮弹

上一篇 / 下一篇  2010-06-23 00:35:12 / 天气: 热 / 心情: 平静 / 精华(1) / 置顶(1) / 个人分类:测试方法

如何控制Bug的蔓延--防不胜防的糖衣炮弹

有这么一种现象,总是很难控制,就是已上线的软件版本更改,每一个更改都必须有来源,这是公司规定的流程。但是在执行的过程中,常会有偏离。

1、              有些开发工程师在更改代码过程中,看到一些代码有问题,控制不住手氧,改之,结果改出问题(没想到对别的地方有影响)(改完之后,有些技术高手们有时还会窃喜,“我多好,又悄悄地做了一次雷锋);

2、              测试发现了之前版本遗留的bug,特别是严重的,没经过评审,直接改之,风险不受控(更改非计划内)。

3、              测试提交了一个bug,开发解决时,把系列的问题解决了,影响到多个模块,但测试回归bug没有分析到所有的路径,漏测。开发解决问题的影响分析并没有传递给测试。

3点,测试吃的亏多着呢,即使有要求开发更改代码要作影响分析,但人为的东西,不可控制。写与不写,写了是否全面了,是不一样的。想起“落后就要挨打”的古训,如果测试人员对每一个提交的软件版本,都能做好代码分析,即使开发不说,或说全,漏测的机会也会少很多。

TAG:

老A 引用 删除 archonwang   /   2010-06-24 11:20:35
很不错的命题,感谢。
软测路上 引用 删除 aux0   /   2010-06-23 21:18:37
已上线的软件,更改应是很严格的,更改版本也应有限制,有时一些严重的问题,如数组越界,分母除零,逻辑判断中多或少了一个等号,等等,测试从现象上看是很严重的,有时问题还是偶发等。这种时候引入代码检视是个好时机。曾遭遇的教训吧。
蝈蝈笼子 引用 删除 蝈蝈5   /   2010-06-23 17:05:19
如果测试人员对每一个提交的软件版本,都能做好代码分析
根本不可能
蝈蝈笼子 引用 删除 蝈蝈5   /   2010-06-23 17:05:04
-5
 

评分:0

我来说两句

Open Toolbar