如何改进测试过程和提高测试效率
大家好！我是一家IT公司的测试人员，来这家公司已经一年了，感觉在测试过程和测试效率都有待改进和提高。所有想在此抛砖引玉，请各位根据各自的工作和公司谈谈，也让其他人或公司测试人员借鉴和学习。
我们测试组前段时间很是紧张，测试开发除了加班就是上班，人都快崩溃了，产品问题还出了不少。所以在做二期项目_手机终端的产品(在一期项目的基础上拓展).也是服务器与客户端架构，中间有其他组件。我根据前一个项目的测试存在的问题，就向项目组建议有关BUG的处理
在客户端测试同一版本进入回归第三次时，就可以开一次此前发现的所有BUG分析会。根据BUG记录，可以将对应的功能点分成三类：出BUG频率较高、出BUG频率一般和不出BUG。其中“BUG频率”可以根据功能点的多少和对应测试用例个数来定；“不出BUG”是指第一轮测试结束修改后，再也不出现的模块或功能点。根据这点分析，开发和测试可以分别做如下事项：
出BUG频率较高：开发可以做一次代码评审，将所使用的控件或代码理一遍；测试人员可以在开发人员做这些事时，考虑是否将对应的测试用例再细化或重新设计。待开发人员提交修改后的代码或模块，测试人员就可以加大力度来执行测试这部分的用例。
出BUG频率一般：开发可以思考一下，这些BUG出现的原因；测试人员在开发人员提交下一个版本时，照常测试；
不出BUG开发可以将该功能点对应的代码或模块冻结，日后有需要改动时，在项目例会上决定是否改及如何改。测试人员可以将对应的测试用例冻结或优先级别改为最低。
另外，可以根据项目组实际情况来在提交开发产品来进行BUG清理……
但很遗憾，这些工作至今没开展。我考虑主要有两点：
1.相关直接做事的领导认为这个太耗时，尤其在项目组忙的时候，或者直接说他们这方面的意识不是很强。另外这部分工作是要增加组员的工作量的，所以支持的组员也多少。整个事情自然被耽搁了，推行很难；
2.我们现有的测试过程不是很规范。而正是由于这些不规范，才导致了我们测试组工作效率不是很高，不是被人认可，测试组提的一些建议再好也会打折。比如在此之前，我建议开发组在进行CodeRevew时叫上我们测试组，但我们自始至终都没收到邮件，不知道开会时间和地址，只在他们结束后才从他们的表情和言谈中推断出来他们是去参加CodeReview了，很是郁闷……
我一直都苦于这些……也恳请前辈们指点迷津。
所以，想请各位能够说说各自在测试组工作中遇到的问题，及如何解决的。如何来改进我们现有的测试过程，如何提高测试效率。
[ 本帖最后由 songwj0806 于 2009-6-11 21:46 编辑 ] 我觉得你的提议很不错，现在感觉测试效率的问题真的是非常头痛的事情。而充分的利用所发现的BUG来指导测试工作的进行，提高效率应该是最可行的办法了。不过测试的工作量上会大很多，而且开发一般也不愿意再搞代码评审，他们总是认为自己的程序只是有点小问题，稍微修修补补的就好了。 所以我想通过测试人员发现的BUG，来量化，让相关人员重视。
但感觉要推行这些…… 哎，现在在做BUG分析，项目头头们认为这个很耗时，项目紧张就不该拿出2小时来做(即使是我加班做的BUG分析)，他们的想法是有这个时间说不定就多找几个BUG了。但我感觉那些BUG相似，所以我按功能点来给BUG分类，并指明BUG出现多数是属于某个控件多次点击，多个用例同时执行，才出现的。
很是无奈，
自己努力吧！ 好问题。我个人的建议是：
1.尽可能早的做测试。不要等开发把全部功能写完再测，开发完一部分就可以开始测这部分。减少后期压力。
2.把质量保证的职责传递给整个团队，而不仅仅是依靠测试把关。可以试着把开发测试放在一个团队里面，或者结对。只要有问题，就是开发和测试一起承担。
3.所有的任务都设定优先级。完成任务始终从高优先级开始。这样可以在有限的时间内，完成最有价值的任务。
4.加强沟通效率。有问题就用最快的方式获得解答。可以先不考虑流程是否规范，后期维护等问题。测试不是超人，如果没法做到长远考虑，就先做短期打算。 很是赞成楼上的建议，呵呵
页:
[1]
