» 您尚未 登录   注册 | 社区服务 | FTP中心 | 帮助 | 社区 | 无图版 | 测试百科  | 测试Blog 
软件测试基地论坛 -> 新手园地 -> [讨论]绩效评估中是找到的bug多好还是多写用例好?
 XML   RSS 2.0   WAP 

<<  1   2   3  >>  Pages: ( 2/3 total )
--> 本页主题: [讨论]绩效评估中是找到的bug多好还是多写用例好? 加为IE收藏 | 收藏主题 | 上一主题 | 下一主题
土土松


该用户目前不在线
级别: 论坛版主
精华: 7
发帖: 1689
基地声望: 246 点
基地币: 2765 Bug
基地贡献: 6 点
好评度: 48 点
在线时间:1031(小时)
注册时间:2005-10-30
最后登录:2007-10-29
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



呵呵,这个世界就是因为像你们这种没有创想的思维太多,不懂得如何去针对性,才会浪费了人才,丧失了机会!!

去拥抱你们所谓的管理理论吧,请问你们谁敢说在项目的管理中能运用你们的理论,给你们的组员减少工作压力,最终高效完成目标??能在你们的管理中发现组员的特点和优势吗?能真正公平的考核绩效吗?

我敢说我没有给组员任何压力,但是产出都比你们强!~~~因为我有个性!!!!

看来你们没有资格做我的对手~~~~

让你们的管理理论在肚子中腐烂吧!!!


MSN:ss2maomao@hotmail.com
我的博客已经升级:
http://hi.baidu.com/lidanny
欢迎莅临~~!!~~

[20 楼] | Posted: 2006-03-08 15:54 顶端
nicolas


该用户目前不在线
级别: Cntesting老学员
精华: 0
发帖: 188
基地声望: 58 点
基地币: 788 Bug
基地贡献: 0 点
好评度: 0 点
在线时间:75(小时)
注册时间:2005-12-03
最后登录:2006-10-20
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



能够想象的是老板会对那个在同样时间里设计用例量少但发现BUG多的员工说:“你负责设计的那部分模块问题挺多的,你干得不错,但不幸的是你得加班把剩下的做完,快到deadline了”

很多人都会变成聪明的人,只要他不以为自己聪明。
[21 楼] | Posted: 2006-03-08 16:00 顶端
kokahkhk


该用户目前不在线
级别: Cntesting老学员
精华: 0
发帖: 61
基地声望: 26 点
基地币: 599 Bug
基地贡献: 0 点
好评度: 0 点
在线时间:39(小时)
注册时间:2005-12-24
最后登录:2006-10-18
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



完全测试是不可能的,也就是说测试只是为了尽可能的去发现更多BUG,发现全部的BUG是不现时的
所以得出结论:绩效评估 当然看BUG,你用列写的再多,发现不了问题又有什么用呢,
既然发现不了问题你的测试价值又体现在哪呢?,既然价值体现不了,又怎么来做绩效评估呢?
再说效率,什么叫效率,发现BUG多叫效率,不是用例多就是效率,因为你是做测试的,测试最重要的本质不是去找BUG,你说找什么呢?


[ 此贴被kokahkhk在2006-03-08 17:42重新编辑 ]


●█〓██▄▄▄▄▄▄ ●●●●●●
▄▅██████▅▄▃▂
██████████████
◥⊙▲⊙▲⊙▲⊙▲⊙▲⊙▲◤

[22 楼] | Posted: 2006-03-08 16:05 顶端
土土松


该用户目前不在线
级别: 论坛版主
精华: 7
发帖: 1689
基地声望: 246 点
基地币: 2765 Bug
基地贡献: 6 点
好评度: 48 点
在线时间:1031(小时)
注册时间:2005-10-30
最后登录:2007-10-29
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



呵呵,那么你就是那个喜欢多写用例,事实却是装样子给老板看的滑头员工!!!

老板也只会让能者多劳,因为能者值得信任。。。。而混日子的人永远是卑微如蚁。

每个人心里都明白!~~


MSN:ss2maomao@hotmail.com
我的博客已经升级:
http://hi.baidu.com/lidanny
欢迎莅临~~!!~~

[23 楼] | Posted: 2006-03-08 16:07 顶端
nicolas


该用户目前不在线
级别: Cntesting老学员
精华: 0
发帖: 188
基地声望: 58 点
基地币: 788 Bug
基地贡献: 0 点
好评度: 0 点
在线时间:75(小时)
注册时间:2005-12-03
最后登录:2006-10-20
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



18楼的有一定误解,任何比较都应当存在条件,在条件一定的情况下是没有实际和理论的差别的,实际有时与理论有差别是因为前提条件不同,与常说的“理论指导实际,实际反作用于理论”是两个关注点不同的说法。

很多人都会变成聪明的人,只要他不以为自己聪明。
[24 楼] | Posted: 2006-03-08 16:24 顶端
Fastpoint


该用户目前不在线
级别: 总版主
精华: 44
发帖: 5033
基地声望: 390 点
基地币: 1689 Bug
基地贡献: 0 点
好评度: 15 点
在线时间:818(小时)
注册时间:2005-10-08
最后登录:2008-07-22
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



倒,一天不来出现争论了,哈哈。来看看老师的理论:

对软件进行测试全面是不可能的,所以说我们会使用部分测试用例,这样的话我们就要进行一个风险评估,那么风险评估的依据是什么呢?

由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西),对大多数软件开发项目来说,利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由,也可采用正式的方法。

对于该项目的用途而言,哪种功能最重要?
哪种功能对用户最明显?
哪种功能对安全影响最大?
哪种功能对用户最有用?
对客户来说,该应用软件的哪个部分最重要?
在开发过程中,该应用软件的哪个部分可以最先测试?
哪一部分代码最复杂,容易导致出现错误?
哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?


哪一部分程序与过去项目中引起问题的部分相类似/有关?
哪一部分程序与过去项目中需要大量维护的部分相类似/有关?
需求和设计的那些部分不清楚或不容易读?
开发人员认为在应用软件中哪些部分是高风险的?
哪些问题能造成最差的发行?
哪些问题最能引起用户抱怨?
哪些测试可以容易地覆盖多种功能?
哪些测试在覆盖高风险部分的测试时使用时间最少?


如果决定不去测试所有的情况,那么我们就面临了很大的风险,比如在计算器例子中假设1024+1024会出现致命的错误,那么你会怎么办?所以说这也变相说明了为什么有些错误我们怎样测试都发现不了,一但到了客户那里马上为客户所发现。
软件测试人员需要学会的一个主要本领就是如何把无边无际的可能性控制到一个可以接受的范围内,这就需要根据风险制定出相应的计划了。


如果很多测试用例发现了较少的BUG,那么可以说明两点:

1.软件质量已经非常好了
2.你设计的测试用例太“老”了

哈哈!


可不可不要这么样徘徊在目光内
你会察觉到我根本寂寞难耐
即使千多百个深夜曾在梦境内
我有吻过你这毕竟并没存在

人声车声开始消和逝
无声挣扎有个情感奴隶
是我多么的想她
但我偏偏只得无尽叹谓

其实每次见你我也着迷
无奈你我各有角色范围
就算在寂寞梦内超出好友关系
唯在暗里爱你暗里着迷
无谓要你惹上各种问题
共我道别吧别让空虚使我越轨
[25 楼] | Posted: 2006-03-08 17:46 顶端
樊冰


该用户目前不在线
级别: Cntesting老学员
精华: 0
发帖: 69
基地声望: 21 点
基地币: 146 Bug
基地贡献: 0 点
好评度: 0 点
在线时间:55(小时)
注册时间:2005-12-24
最后登录:2007-07-15
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



我同意楼主的话,软件中BUG的分布是随机的,如果被分配到的部分本身就是高质量的,那即使写了几倍于别人的优秀用例,发现的BUG也十分有限,但是却不能说他的工作是底效率的,反之亦然!
[26 楼] | Posted: 2006-03-08 17:49 顶端
樊冰


该用户目前不在线
级别: Cntesting老学员
精华: 0
发帖: 69
基地声望: 21 点
基地币: 146 Bug
基地贡献: 0 点
好评度: 0 点
在线时间:55(小时)
注册时间:2005-12-24
最后登录:2007-07-15
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



所以,如果有家公司是以发现BUG 的多少来评价一个测试人员是十分有失公允的,这就是为什么现在还没有公司有这样的制度
[27 楼] | Posted: 2006-03-08 17:51 顶端
joyce


该用户目前不在线
级别: 助理测试工程师
精华: 2
发帖: 666
基地声望: 155 点
基地币: 7552 Bug
基地贡献: 0 点
好评度: 0 点
在线时间:540(小时)
注册时间:2005-10-06
最后登录:2008-07-16
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



有,所以职员都比较郁闷~

他们都希望开发越傻越好,全是BUG才好呢~!呵呵呵


sunny_w_b@hotmail.com
[28 楼] | Posted: 2006-03-08 18:37 顶端
土土松


该用户目前不在线
级别: 论坛版主
精华: 7
发帖: 1689
基地声望: 246 点
基地币: 2765 Bug
基地贡献: 6 点
好评度: 48 点
在线时间:1031(小时)
注册时间:2005-10-30
最后登录:2007-10-29
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



QUOTE:
下面是引用樊冰于2006-03-08 17:49发表的:
软件中BUG的分布是随机的,如果被分配到的部分本身就是高质量的,那即使写了几倍于别人的优秀用例,发现的BUG也十分有限,但是却不能说他的工作是底效率的,反之亦然!


请问这是什么理论?

风险列表确定后,优秀的测试人员已经可以把这一部分剔除不测,为何还会分配出去?

比如你在APP项目中,会去特意很仔细的写个用例去测试“实用工具”菜单栏吗?
我不会,这里冒烟一下足够了。

所以,如果你分配了这种测试给组员,就是低工作效率,就是浪费时间。。


MSN:ss2maomao@hotmail.com
我的博客已经升级:
http://hi.baidu.com/lidanny
欢迎莅临~~!!~~

[29 楼] | Posted: 2006-03-08 18:45 顶端
nicolas


该用户目前不在线
级别: Cntesting老学员
精华: 0
发帖: 188
基地声望: 58 点
基地币: 788 Bug
基地贡献: 0 点
好评度: 0 点
在线时间:75(小时)
注册时间:2005-12-03
最后登录:2006-10-20
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



测试用例的设计实际中是风险驱动的,一点都没错,但是看清楚这个帖子不是讨论风险分析法的对错,而是测试用例设计人员的绩效评价问题。
有这种BUG奖励体制的公司,如果公司里的每一个员工没有清楚中间目标和最终目标的关系,必将导致这家公司的人员流失,而且就算每个人都很清楚的明确最终目标,也绝对有人会做出违背初衷的事情,都是因为那个糟糕的奖励体制。


很多人都会变成聪明的人,只要他不以为自己聪明。
[30 楼] | Posted: 2006-03-08 19:06 顶端
土土松


该用户目前不在线
级别: 论坛版主
精华: 7
发帖: 1689
基地声望: 246 点
基地币: 2765 Bug
基地贡献: 6 点
好评度: 48 点
在线时间:1031(小时)
注册时间:2005-10-30
最后登录:2007-10-29
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



呵呵,真是顽固不化啊。。

提高效率的手段本身就不存在任何理论驱动,我会奖励那个写4个用例却发现6个BUG的人,因为LZ说的很清楚,他们的BUG等级是一样的。

难道现实的数据不能证明绩效?? 我是不能明白班长的理论基点何在,也不明白单纯的理论而不靠经验和感觉,如何去提高效率,增加狙击错误的精确程度。


MSN:ss2maomao@hotmail.com
我的博客已经升级:
http://hi.baidu.com/lidanny
欢迎莅临~~!!~~

[31 楼] | Posted: 2006-03-08 19:14 顶端
xuewinds


该用户目前不在线
级别: Cntesting老学员
精华: 0
发帖: 568
基地声望: 73 点
基地币: 0 Bug
基地贡献: 6 点
好评度: 2 点
在线时间:151(小时)
注册时间:2005-12-24
最后登录:2008-11-28
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



原来风险列表还有这些用处啊。。。。那风险列表的某些作用和测试需求不是有冲突了么?
[32 楼] | Posted: 2006-03-08 20:08 顶端
Fastpoint


该用户目前不在线
级别: 总版主
精华: 44
发帖: 5033
基地声望: 390 点
基地币: 1689 Bug
基地贡献: 0 点
好评度: 15 点
在线时间:818(小时)
注册时间:2005-10-08
最后登录:2008-07-22
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



呵呵!

可不可不要这么样徘徊在目光内
你会察觉到我根本寂寞难耐
即使千多百个深夜曾在梦境内
我有吻过你这毕竟并没存在

人声车声开始消和逝
无声挣扎有个情感奴隶
是我多么的想她
但我偏偏只得无尽叹谓

其实每次见你我也着迷
无奈你我各有角色范围
就算在寂寞梦内超出好友关系
唯在暗里爱你暗里着迷
无谓要你惹上各种问题
共我道别吧别让空虚使我越轨
[33 楼] | Posted: 2006-03-08 21:00 顶端
xuewinds


该用户目前不在线
级别: Cntesting老学员
精华: 0
发帖: 568
基地声望: 73 点
基地币: 0 Bug
基地贡献: 6 点
好评度: 2 点
在线时间:151(小时)
注册时间:2005-12-24
最后登录:2008-11-28
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



。。。。。。。。老师 答案不会就是呵呵吧?
[34 楼] | Posted: 2006-03-08 21:46 顶端
xuewinds


该用户目前不在线
级别: Cntesting老学员
精华: 0
发帖: 568
基地声望: 73 点
基地币: 0 Bug
基地贡献: 6 点
好评度: 2 点
在线时间:151(小时)
注册时间:2005-12-24
最后登录:2008-11-28
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



老师的意思是不是 通过在测试计划里对风险列表进行仔细分析 来帮助之后创建测试需求时测试范围的控制?
[35 楼] | Posted: 2006-03-08 22:01 顶端
海松宝


该用户目前不在线
级别: 总版主
精华: 4
发帖: 1741
基地声望: 414 点
基地币: 413 Bug
基地贡献: 291 点
好评度: 15 点
在线时间:1093(小时)
注册时间:2005-10-13
最后登录:2008-10-30
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



呵呵,昨天没来得及看,今天一看还真有意思,仿佛又回到前几年在51cmm的感觉了。

我们的学员都不错啊,能够有这么好的想法,双方在不同的理解上都有一定的深度。

辩论是个好事情啊!很多的创新思维就是在碰撞的火化中产生的。继续继续,看看最终谁的理论更有说服力!

我不给你们下结论,只是提醒三点:

  1. 想要证明自己是正确的,让别人信服,就需要有力的理论事实依据
  2. 把自己的视野放开一点,超出自己目前的位置,从更高、更广的角度去看问题(从测试技术、项目管理、团队管理、战略管理等不同角度、不同高度,你看待事务的想法会大不相同)
  3. 通过激辩和争论,结果可以是势不两立;也可以是增进友谊、惺惺相惜,各自得到提高。



[ 此贴被海松宝在2006-03-09 11:56重新编辑 ]


软件测试的发展,需要你我他共同参与
[36 楼] | Posted: 2006-03-09 11:46 顶端
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 顶端
海松宝


该用户目前不在线
级别: 总版主
精华: 4
发帖: 1741
基地声望: 414 点
基地币: 413 Bug
基地贡献: 291 点
好评度: 15 点
在线时间:1093(小时)
注册时间:2005-10-13
最后登录:2008-10-30
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



ray的比喻很形象。

事实上,有的公司就这么做过,用发现的Bug数来作为测试人员的考核依据,其结果就是测试人员为了口袋不空而把心思花在了找一些浅显的问题上面,没人愿意去找那些隐藏很深的、影响巨大的问题。


软件测试的发展,需要你我他共同参与
[38 楼] | Posted: 2006-03-11 09:11 顶端
zhanyizhu


该用户目前不在线
级别: Cntesting老学员
精华: 0
发帖: 53
基地声望: 14 点
基地币: 408 Bug
基地贡献: 0 点
好评度: 0 点
在线时间:45(小时)
注册时间:2006-03-24
最后登录:2006-10-19
查看作者资料 发送短消息 推荐此帖 引用回复这个帖子



豪猪有刺,软件有bug, 这就是人生
[39 楼] | Posted: 2006-04-17 10:52 顶端
<<  1   2   3  >>  Pages: ( 2/3 total )

软件测试基地论坛 -> 新手园地




软件测试基地上海测仕信息技术有限公司旗下网站
Copyright © 2005-2007 Cntesting.com, All Rights Reserved
沪ICP备06057721号

Powered by PHPWind Code © 2003-06 PHPWind
Total 0.198674(s) query 5, Time now is:12-05 12:22, Gzip disabled
You can contact us


每日一句:Loading...