软件测试的轮次多少,大多数情况取决于项目大小、开发软件质量和测试效率有关。在项目确定的情况下,谈谈我们团队的做法,希望同行继续补充指正:
1.让研发团队的领导重视测试:
测试经理作为测试部门的老大,让公司领导重视测试,明白测试给项目带了的价值,那是义不容辞的责任。如何说服公司的领导,让公司的研发总监重视,这一点非常关键。只要这一点做好了,测试才会变得很轻松、愉快。如果公司的领导都不重视测试团队,只看重开发团队,即时测试部门发现了一大堆问题,公司领导也觉的很正常,不在乎,何谈降低测试轮次?如果公司研发领导很重视每轮的测试报告,自然开发部门不敢怠慢,代码的质量肯定要高得多,降低测试的轮次简直就是轻而易举的事情。
2.测试团队和开发团队的独立性:
国内很多的研发团队都不是很重视测试团队,很多情况下都是开发部门的经理说了算,什么时候测试?什么时候结束?都是如此,这就让测试团队的成员非常郁闷,很无赖,经常是抱怨居多。在这种情况下,多数时候,项目为了赶进度,项目经理和开发经理急了。为了尽快发现问题,只要开发了几个新功能和修复了几个Bug,也就安排大量测试人员立马验证,这样反反复复,版本平凡发布,测试效果极差,软件质量也得不到保证。如果测试部门和开发部门独立以后,发布版本测试都必须通过沟通来解决。你说开发部门的经理“说测试就测试”的想法,说了还能算吗?呵呵!!我们公司很多时候,在测试版本不符合要求时,要送测试部门进行测试,都是开发部门的经理和项目经理给我们测试部门的老大说好话,拍马屁,老大高兴了,我们方才开始测试,否则一切按流程行事,他们也没有办法。保持部门的独立性和平等性,同样重要。
3.细化送测标准,建立完善的测试规范:
测试经理在编写测试计划的时候,就应该考虑如下的问题:开发部门开发完成到什么时候我们可以开始接受测试?如果这点测试经理不明白,后面重复测试平凡发布版本,不是什么新鲜事。目前,我们公司的做法是:测试经理编写详细的测试规范,在规范中明确规定了软件版本的送测标准(如:某个独立模块的功能点完成了多少百分比,才能够开始测试等等,都要写成一个标准)。测试规范制定完毕后,开会评审让项目经理、开发经理和测试经理达成一个一致的建议,后面测试的时候就按测试规范中的标准执行就可以了。严格把握软件的送测标准,也能够有效的减少测试的次数。
4.测试部门建立详尽的预测试标准:
如果被测试软件符合送测标准以后,开发部门才能够请求测试部门进行测试。测试部门接受到开发部门的配置表以后,在服务器上取下测试的版本,编译、部署后,安排部分项目核心人员,对部分主要的功能进行预测试,如果预测试通过了,就可以开始测试。如果预测试不通过,就打回开发部门修改好后再预测试,直到预测试通过为止。同时,我们也要制定严格的软件测试结束标准,来把好质量关,避免一味的追求减少测试轮数,而忽视质量,结果自然可想而知。建立详尽的预测试标准,这样也能够减少测试的轮数。
5.保持测试和开发独立的测试环境:
大部分的项目硬件都非常昂贵,现在很多的公司为了节省成本,开发和测试环境都在同一台机器上。开发人员就在测试机器上开发,这样混乱的测试环境,导致很多测试出来的Bug有可能不能够重现,开发人员对不成功重现的Bug就要求列为无效的Bug,弄得测试的兄弟们递交Bug都胆战心惊的。测试人员为了重新Bug不得不另取以前的版本,重新编译后,再测试,这样做无意识又增加了测试的轮次。后来测试环境和开发环境分开了,虽然在同一台机器上,数据库都分开了,测试数据再也不会被开发人员修改了,在测试出现的问题,一般在开发那边都能够出现。后来为了保护测试组里成员的利益,我也去掉了绩效考核中“对无效的Bug”的考核项,大家终于可以放心的提缺陷了。
6.重视单元测试,提高被测软件质量:
很多时候,测试部门和开发部门单元测试比较马虎或应付客户了事,测试的时间短,留下了很多缺陷。到了后面每轮系统测试的时候,才被发现,加之项目进度的压力,给公司也带来了较大的经济负担。加大单元测试的力度,力争尽早发现并修复缺陷,同样也是减少测试轮次的一种好方法。
7.重视测试用例的评审,提高测试用例的质量:
就目前来说,很多的公司都不是很规范。一种情况:变更了软件需求,相应的测试用例,没有及时增加,测试人员测试时,完全凭个人的理解和经验,想到哪里就测到哪里,随便测试。在这种情况下,不同的人在不同的时间测试时,就会发现并提出不同的缺陷,这样混乱的测试就导致测试轮数较多,效率自然低下。另外一种情况就是测试人员设计测试用例的水平不高,测试用例质量较差,导致测试反复进行,也测试不出Bug。这就要求测试部门主管,加大测试用例评审的力度,力争以最少的测试用例,测试出较多的Bug。
8.部门员工进行模块交叉测试,避免漏测提高测试效率:
测试主管在安排测试的时候,也要注意“用人之长,避人之短”。测试启动阶段,要对这个系统集中培训,让测试部门的成员对整个系统达成一致意见,最好在第一轮测试时,尽可能发现较多缺陷,开发人员尽早修复。第二轮测试就可以进行模块交叉测试。一方面我们可以避免个人原因造成的漏测试,另外一方面也可以利用每个人不同的思维方式,很容易发现其它模块的缺陷,避免多次重复测试,提高测试人员的积极性。测试效率提高了,发现的问题多了,后面测试的轮次自然要减少。
9.加强项目成员的管理,定期报告发现缺陷的情况,增加督促力度:
加强项目成员的管理,同样能够减少版本的发布和测试的轮次。测试人员每天都编写测试日志,邮件抄送给项目部成员和公司领导报告每天测试情况,加强不同层次的领导对开发人员的督促力度。这就对应了第一条,如果公司领导不重视测试,也就无所谓。如果公司领导很重视测试结果,马上作出反应,给各个部门的经理施加压力,软件质量被重视了,自然测试版本减少。如果哪个开发人员开发的模块每天都有很多缺陷,开发人员自然很不光彩,毕竟大家都很要面子,开发人员也敢轻而易举,开发的模块功能不测试就直接扔给测试部。这也是一种有效的方法,当然也可以把缺陷的数量、严重程度作为开发人员的绩效考核标准,提高开发人员的“质量意识”,缺陷自然很少。我们公司就是这样做的,一般在2到3个版本时,就很难发现缺陷,测试人员也相互看看其它成员发现的缺陷,一旦有的测试人员发现了较多的Bug,发现缺陷很少的测试人员很急,比较有个比较吗?特别是测试半天都没发现Bug的测试人员,就经常给我讲自己测试过程中的苦衷,我也很理解他们,多给他们鼓励鼓励。
10.严格控制需求变更的流程,减少后期的需求变动:
在项目开发中,经常碰到这样的情况,客户代表中有产品部、科技部、业务部等等部门的人员,很难通过某个客户代表户讲清需求。客户代表,随着对开发系统的不断深入了解,有可能客户不断的提出新的需求,或者说是不断修改需求,所以对于需求的变更,我们一定要有一个严格的标准流程。通过开发方和客户的评审后,再编写相应需求文档,最后开始开发。很多时候,繁琐的需求变更流程和领导的多级审批签字,并且需求的变更请求,也有相关的记录,很多客户都怕承担需求变更带来风险。也让业务人员觉得变更比较麻烦,不得不放弃需求的变更。严格控制需求的变更流程,做到有效的需求变更,这也许是一种减少测试版本的方法。
1.让研发团队的领导重视测试:
测试经理作为测试部门的老大,让公司领导重视测试,明白测试给项目带了的价值,那是义不容辞的责任。如何说服公司的领导,让公司的研发总监重视,这一点非常关键。只要这一点做好了,测试才会变得很轻松、愉快。如果公司的领导都不重视测试团队,只看重开发团队,即时测试部门发现了一大堆问题,公司领导也觉的很正常,不在乎,何谈降低测试轮次?如果公司研发领导很重视每轮的测试报告,自然开发部门不敢怠慢,代码的质量肯定要高得多,降低测试的轮次简直就是轻而易举的事情。
2.测试团队和开发团队的独立性:
国内很多的研发团队都不是很重视测试团队,很多情况下都是开发部门的经理说了算,什么时候测试?什么时候结束?都是如此,这就让测试团队的成员非常郁闷,很无赖,经常是抱怨居多。在这种情况下,多数时候,项目为了赶进度,项目经理和开发经理急了。为了尽快发现问题,只要开发了几个新功能和修复了几个Bug,也就安排大量测试人员立马验证,这样反反复复,版本平凡发布,测试效果极差,软件质量也得不到保证。如果测试部门和开发部门独立以后,发布版本测试都必须通过沟通来解决。你说开发部门的经理“说测试就测试”的想法,说了还能算吗?呵呵!!我们公司很多时候,在测试版本不符合要求时,要送测试部门进行测试,都是开发部门的经理和项目经理给我们测试部门的老大说好话,拍马屁,老大高兴了,我们方才开始测试,否则一切按流程行事,他们也没有办法。保持部门的独立性和平等性,同样重要。
3.细化送测标准,建立完善的测试规范:
测试经理在编写测试计划的时候,就应该考虑如下的问题:开发部门开发完成到什么时候我们可以开始接受测试?如果这点测试经理不明白,后面重复测试平凡发布版本,不是什么新鲜事。目前,我们公司的做法是:测试经理编写详细的测试规范,在规范中明确规定了软件版本的送测标准(如:某个独立模块的功能点完成了多少百分比,才能够开始测试等等,都要写成一个标准)。测试规范制定完毕后,开会评审让项目经理、开发经理和测试经理达成一个一致的建议,后面测试的时候就按测试规范中的标准执行就可以了。严格把握软件的送测标准,也能够有效的减少测试的次数。
4.测试部门建立详尽的预测试标准:
如果被测试软件符合送测标准以后,开发部门才能够请求测试部门进行测试。测试部门接受到开发部门的配置表以后,在服务器上取下测试的版本,编译、部署后,安排部分项目核心人员,对部分主要的功能进行预测试,如果预测试通过了,就可以开始测试。如果预测试不通过,就打回开发部门修改好后再预测试,直到预测试通过为止。同时,我们也要制定严格的软件测试结束标准,来把好质量关,避免一味的追求减少测试轮数,而忽视质量,结果自然可想而知。建立详尽的预测试标准,这样也能够减少测试的轮数。
5.保持测试和开发独立的测试环境:
大部分的项目硬件都非常昂贵,现在很多的公司为了节省成本,开发和测试环境都在同一台机器上。开发人员就在测试机器上开发,这样混乱的测试环境,导致很多测试出来的Bug有可能不能够重现,开发人员对不成功重现的Bug就要求列为无效的Bug,弄得测试的兄弟们递交Bug都胆战心惊的。测试人员为了重新Bug不得不另取以前的版本,重新编译后,再测试,这样做无意识又增加了测试的轮次。后来测试环境和开发环境分开了,虽然在同一台机器上,数据库都分开了,测试数据再也不会被开发人员修改了,在测试出现的问题,一般在开发那边都能够出现。后来为了保护测试组里成员的利益,我也去掉了绩效考核中“对无效的Bug”的考核项,大家终于可以放心的提缺陷了。
6.重视单元测试,提高被测软件质量:
很多时候,测试部门和开发部门单元测试比较马虎或应付客户了事,测试的时间短,留下了很多缺陷。到了后面每轮系统测试的时候,才被发现,加之项目进度的压力,给公司也带来了较大的经济负担。加大单元测试的力度,力争尽早发现并修复缺陷,同样也是减少测试轮次的一种好方法。
7.重视测试用例的评审,提高测试用例的质量:
就目前来说,很多的公司都不是很规范。一种情况:变更了软件需求,相应的测试用例,没有及时增加,测试人员测试时,完全凭个人的理解和经验,想到哪里就测到哪里,随便测试。在这种情况下,不同的人在不同的时间测试时,就会发现并提出不同的缺陷,这样混乱的测试就导致测试轮数较多,效率自然低下。另外一种情况就是测试人员设计测试用例的水平不高,测试用例质量较差,导致测试反复进行,也测试不出Bug。这就要求测试部门主管,加大测试用例评审的力度,力争以最少的测试用例,测试出较多的Bug。
8.部门员工进行模块交叉测试,避免漏测提高测试效率:
测试主管在安排测试的时候,也要注意“用人之长,避人之短”。测试启动阶段,要对这个系统集中培训,让测试部门的成员对整个系统达成一致意见,最好在第一轮测试时,尽可能发现较多缺陷,开发人员尽早修复。第二轮测试就可以进行模块交叉测试。一方面我们可以避免个人原因造成的漏测试,另外一方面也可以利用每个人不同的思维方式,很容易发现其它模块的缺陷,避免多次重复测试,提高测试人员的积极性。测试效率提高了,发现的问题多了,后面测试的轮次自然要减少。
9.加强项目成员的管理,定期报告发现缺陷的情况,增加督促力度:
加强项目成员的管理,同样能够减少版本的发布和测试的轮次。测试人员每天都编写测试日志,邮件抄送给项目部成员和公司领导报告每天测试情况,加强不同层次的领导对开发人员的督促力度。这就对应了第一条,如果公司领导不重视测试,也就无所谓。如果公司领导很重视测试结果,马上作出反应,给各个部门的经理施加压力,软件质量被重视了,自然测试版本减少。如果哪个开发人员开发的模块每天都有很多缺陷,开发人员自然很不光彩,毕竟大家都很要面子,开发人员也敢轻而易举,开发的模块功能不测试就直接扔给测试部。这也是一种有效的方法,当然也可以把缺陷的数量、严重程度作为开发人员的绩效考核标准,提高开发人员的“质量意识”,缺陷自然很少。我们公司就是这样做的,一般在2到3个版本时,就很难发现缺陷,测试人员也相互看看其它成员发现的缺陷,一旦有的测试人员发现了较多的Bug,发现缺陷很少的测试人员很急,比较有个比较吗?特别是测试半天都没发现Bug的测试人员,就经常给我讲自己测试过程中的苦衷,我也很理解他们,多给他们鼓励鼓励。
10.严格控制需求变更的流程,减少后期的需求变动:
在项目开发中,经常碰到这样的情况,客户代表中有产品部、科技部、业务部等等部门的人员,很难通过某个客户代表户讲清需求。客户代表,随着对开发系统的不断深入了解,有可能客户不断的提出新的需求,或者说是不断修改需求,所以对于需求的变更,我们一定要有一个严格的标准流程。通过开发方和客户的评审后,再编写相应需求文档,最后开始开发。很多时候,繁琐的需求变更流程和领导的多级审批签字,并且需求的变更请求,也有相关的记录,很多客户都怕承担需求变更带来风险。也让业务人员觉得变更比较麻烦,不得不放弃需求的变更。严格控制需求的变更流程,做到有效的需求变更,这也许是一种减少测试版本的方法。
转载于:http://bbs.51testing.com/viewthread.php?tid=123987&page=2#pid1050885 讨论