如何提高缺陷的有效率、修正率

上一篇 / 下一篇  2008-11-13 10:55:58 / 个人分类:测试技术

转载请保留:本文出自thefirstred的51Testing软件测试博客:http://www.51testing.com/?2102351Testing软件测试网(w5G@P.i

51Testing软件测试网9gI~6l@ B)k

   工作中经常有这样的问题,测试人员提了一堆bug,可是开发人员就是不改,如何改善这种问题呢?我想首先要从原因分析。有两点:51Testing软件测试网"et h*Y4\#\}-T

51Testing软件测试网-Y%v1b,vjd5PT

   1 开发人员认为这不是缺陷。由于测试人员描述不清,开发人员认为不是缺陷;或者由于对易用性方面的理解不一致、或者由于需求中对某个功能的描述本身就不清楚,因此测试人员与开发人员对功能的实现方式存在争议。51Testing软件测试网R.@c&T9Y"K

jc OTskW~I(}R0   2 虽然承认是缺陷,但是觉得影响不大或用户不会进行类似的操作而没有必要去改,或者是觉得改起来性价比不高,或是开发任务太紧没有时间去改。51Testing软件测试网3[4d7b1\0OZEtY

0rZqB o6?0   对于第一种情况,测试人员要做到下面几点:51Testing软件测试网]7a k/khW7Qy3`#b

51Testing软件测试网F/H&bw|

   a 描述清楚。对于可以复现的缺陷,需要写明测试环境、操作过程、实际结果与预期结果,最好把缺陷画面抓取下来,附到缺陷描述中;对于不能复现的缺陷,把缺陷画面抓取下来,请开发人员去分析原因

Ti5d&rs-|0

MVX;Eq"~:O0Q(W)?0   b 制定统一的checklist,并且经过项目负责人的评审,如果遇到测试人员认为是缺陷而开发人员认为不是缺陷的问题,以checklist为准51Testing软件测试网fxv g0t)| ]

51Testing软件测试网/Fk4b+z&RV:Hk

   c 对于需求不明确的问题,向需求分析人员进行确认,来判断是否缺陷。注意测试人员千万不要说我觉得应该怎样怎样的,不要真的把自己当作用户51Testing软件测试网!?3Dm}z(T

51Testing软件测试网!TT0F\!nBY9q

   对于第二种情况,参考下面几点:

.T6a B2s O!d0

*@)~L pv2GL8H,a,|0   a 对于开发人员认为缺陷影响不大而不去改的情况,仍然以checklist为准

6J8TCxJzZ6K n051Testing软件测试网0D P6t-D`1v$?

   b 测试人员以边界值法或错误猜测法设计的测试用例而发现的问题,开发人员可能会觉得这种情况不大可能出现,这时测试人员应该引导开发人员分析系统的潜在风险,提高开发人员的质量意识,当然这需要测试人员具备一定的沟通技巧了51Testing软件测试网!D;Hq!D0O!t

| c'f_6NB%WTo0   c 测试人员需要提高自己的综合能力。当开发人员以不好改或者改起来风险太大为借口拒绝修改时,如果测试人员能站在开发的角度,利用自己的技术实力提出比较中肯的建议,开发人员一般还是会接受的

a2op5n+k"M051Testing软件测试网2sB-`~$EU1X

 

k|S\5lw)@A.GM0

TAG: 测试技术 缺陷 有效率 修复率

 

评分:0

我来说两句

Open Toolbar