51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3851|回复: 5
打印 上一主题 下一主题

[原创] 如何改进测试过程和提高测试效率

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-6-11 21:44:51 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
大家好!
我是一家IT公司的测试人员,来这家公司已经一年了,感觉在测试过程和测试效率都有待改进和提高。所有想在此抛砖引玉,请各位根据各自的工作和公司谈谈,也让其他人或公司测试人员借鉴和学习。
我们测试组前段时间很是紧张,测试开发除了加班就是上班,人都快崩溃了,产品问题还出了不少。所以在做二期项目_手机终端的产品(在一期项目的基础上拓展).也是服务器与客户端架构,中间有其他组件。我根据前一个项目的测试存在的问题,就向项目组建议有关BUG的处理
        在客户端测试同一版本进入回归第三次时,就可以开一次此前发现的所有BUG分析会。根据BUG记录,可以将对应的功能点分成三类:出BUG频率较高、出BUG频率一般和不出BUG。其中“BUG频率”可以根据功能点的多少和对应测试用例个数来定;“不出BUG”是指第一轮测试结束修改后,再也不出现的模块或功能点。根据这点分析,开发和测试可以分别做如下事项:
        出BUG频率较高:开发可以做一次代码评审,将所使用的控件或代码理一遍;测试人员可以在开发人员做这些事时,考虑是否将对应的测试用例再细化或重新设计。待开发人员提交修改后的代码或模块,测试人员就可以加大力度来执行测试这部分的用例。
        出BUG频率一般:开发可以思考一下,这些BUG出现的原因;测试人员在开发人员提交下一个版本时,照常测试;
        不出BUG开发可以将该功能点对应的代码或模块冻结,日后有需要改动时,在项目例会上决定是否改及如何改。测试人员可以将对应的测试用例冻结或优先级别改为最低。
           另外,可以根据项目组实际情况来在提交开发产品来进行BUG清理……
     但很遗憾,这些工作至今没开展。我考虑主要有两点:
       1.相关直接做事的领导认为这个太耗时,尤其在项目组忙的时候,或者直接说他们这方面的意识不是很强。另外这部分工作是要增加组员的工作量的,所以支持的组员也多少。整个事情自然被耽搁了,推行很难;
       2.我们现有的测试过程不是很规范。而正是由于这些不规范,才导致了我们测试组工作效率不是很高,不是被人认可,测试组提的一些建议再好也会打折。比如在此之前,我建议开发组在进行CodeRevew时叫上我们测试组,但我们自始至终都没收到邮件,不知道开会时间和地址,只在他们结束后才从他们的表情和言谈中推断出来他们是去参加CodeReview了,很是郁闷……
      我一直都苦于这些……也恳请前辈们指点迷津。

     所以,想请各位能够说说各自在测试组工作中遇到的问题,及如何解决的。如何来改进我们现有的测试过程,如何提高测试效率。

[ 本帖最后由 songwj0806 于 2009-6-11 21:46 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-6-12 10:24:21 | 只看该作者
我觉得你的提议很不错,现在感觉测试效率的问题真的是非常头痛的事情。而充分的利用所发现的BUG来指导测试工作的进行,提高效率应该是最可行的办法了。不过测试的工作量上会大很多,而且开发一般也不愿意再搞代码评审,他们总是认为自己的程序只是有点小问题,稍微修修补补的就好了。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2009-6-12 19:01:15 | 只看该作者
所以我想通过测试人员发现的BUG,来量化,让相关人员重视。
但感觉要推行这些……
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2009-7-1 13:52:41 | 只看该作者
哎,现在在做BUG分析,项目头头们认为这个很耗时,项目紧张就不该拿出2小时来做(即使是我加班做的BUG分析),他们的想法是有这个时间说不定就多找几个BUG了。但我感觉那些BUG相似,所以我按功能点来给BUG分类,并指明BUG出现多数是属于某个控件多次点击,多个用例同时执行,才出现的。
很是无奈,
自己努力吧!
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2009-7-3 17:01:50 | 只看该作者
好问题。我个人的建议是:
1.尽可能早的做测试。不要等开发把全部功能写完再测,开发完一部分就可以开始测这部分。减少后期压力。
2.把质量保证的职责传递给整个团队,而不仅仅是依靠测试把关。可以试着把开发测试放在一个团队里面,或者结对。只要有问题,就是开发和测试一起承担。
3.所有的任务都设定优先级。完成任务始终从高优先级开始。这样可以在有限的时间内,完成最有价值的任务。
4.加强沟通效率。有问题就用最快的方式获得解答。可以先不考虑流程是否规范,后期维护等问题。测试不是超人,如果没法做到长远考虑,就先做短期打算。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
 楼主| 发表于 2009-11-26 16:51:24 | 只看该作者
很是赞成楼上的建议,呵呵
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-10 13:18 , Processed in 0.067991 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表