ray
级别: Cntesting老学员
精华:
1
发帖: 52
基地声望: 13 点
基地币: 524 Bug
基地贡献: 0 点
好评度: 0 点
在线时间:32(小时)
注册时间:2005-12-27
最后登录:2006-10-17
|
前几天都没上来,一直听说这里有战争,看了看突然想起小时候看过一部卡通片:
给大家讲讲吧~
有一头熊,家里鼠患成灾,于是它便养了一只猫,并对那只猫说:"你抓到大老鼠就有大鱼吃,抓到小老鼠就只有小鱼吃,抓不到老鼠就没鱼吃!"... 一开始熊的家里有很多老鼠,老鼠有大有小,猫努力地工作着,每天可以换到很多鱼,大鱼小鱼都有... 由于猫的努力工作熊家里的老鼠浅浅少了,猫的待遇也大不如前,虽然它仍然努力地工作,但是每天得到的却只有小鱼,有时甚至还会换来熊的抱怨"怎么老鼠一天比一天少,一天比一天小!~@#$%&......." 于是聪明的猫想出了一个法子,它把抓来的一部分老鼠关在一个熊看不见的地方,用熊家里的粮食每天一日三餐去喂那些老鼠,大老鼠生小老鼠,小老鼠长大又生小小老鼠,每只老鼠都又肥又大,然后猫再用这些养肥了的老鼠去换大鱼 而猫的工作从抓老鼠变成了养老鼠,这对猫来说那是多么写意的事情啊... 从此之后,猫得到了熊的赞赏,并且每天都有很多大鱼吃,而熊家里的的老鼠却一天比一天多,粮食的消耗量也一天比一天多.......
很明显在这个故事里熊是一位脑筋非常不开窍的顾主 起初猫努力地工作,使它家里的老鼠越来越少,它不但不感激,反而还要抱怨猫 而最后,猫开始"捣糨糊"甚至做出一些有违职业道德的事,它倒反而赞赏猫
我们可以把熊的家比做一个软件工程,熊与猫当然就是老板和测试人员,老鼠不用说肯定充当BUG 我们知道在一个项目当中,BUG的数量会随着项目的进展呈负增长趋势,这就意味这测试人员发现的BUG数量也是呈负增长趋势... 我们还知道在一个项目中,越复杂的模块,代码行数越多的模块,或者是疲劳的开发人员写出来的模块,都要比简单的,行数少的,头脑清醒的开发写出来的模块出现BUG的几率要大的多... 因此通过这两个概念去考虑一位测试人员在整个项目中的效率的话,我的理解是: 并不用一味追求一种考核手段,在各个不同的阶段或面对不的同模块可以使用不同的考核手段,每个阶段或模块评定总和的平均值就是这位测试人员在整个项目当中的工作效率了... 根据经验,譬如项目刚开始的阶段或编码较多,开发人员整体状态不佳等此类BUG暴发时期,可以以发现BUG数量为效率考核准则,而在项目后期,或BUG都已被基本解决等此类需要多而细致的测试用例,来发现少数隐藏在"深"处的BUG的时期,则可以用测试用例的数量来作为效率考核准则
最后我的观点是: 不要做没脑子的"熊" 也不能把"猫"都累死
|
#!/bin/bash
X="Work" Y="Play" Z="Keeping your mouth shut" read -p "Which do you wanna get, Fail or Success?" A if [ $A == "Success" ] then A=$X"+"$Y"+"$Z fi echo -e "$A\n"
|
|
[37 楼]
|
Posted: 2006-03-11 01:15 |
| |