UML软件工程组织

 

 

从企业问题来了解软件测试人员的作用
 

2008-01-25 来源:快速测试

 

先讲一个案例:

企业网站已经运行多年了,访问速度越来越慢,最近用户反映,打开个网站首页快的时候也要2、3秒,慢的时候就需要喝杯茶了,还不如上外网新浪搜狐快,厂领导重视这个问题,信息部的领导当然不敢怠慢。

首先组织人员参观附近的运行比较好的相关网站,比如总公司的,地方上的信息港等,现场咨询了相关设计人员若干问题。

然后就组织会议,召集相关人员讨论、分析网站首页慢的原因。网站的开发人员、维护人员、测试人员以及各方领导都参加了分析。结论很快就出来了,接着领导们开始提改进建议。但会议却好象陷入了僵局。

网站首页慢的原因如下:

1、在首页打开的数据库(表)太多。因为首页要各车间、单位的最新数据列表,提取最新数据占用了太多时间。

2、数据库有问题。测试人员在逐个测试数据库时发现,虽然网站涉及多个数据库服务器,如办公邮箱服务器、邮件服务器、文件服务器、各生产数据服务器等,但有一台服务器明显慢了许多,断掉这台服务器,网站首页的打开速度就进入毫秒级,将这台数据库的数据导出至另一台备用服务器上,并将WEB服务器上的链接指定到备用服务器,访问速度依然是毫秒级。

3、首页中的SQL语句有问题。特别是Oracle中数据表指针的移动很费时间,需要优化。

解决方案也接着就出来了,如下:

将首页改为静态的。首页中不再访问所有的数据库服务器,而是若干文本列表,这些文本由其它数据库(表)在新增记录时,同步在WEB服务器上生成。首页是静态的,速度就会快多了。

测试人员表示反对这种方案,认为问题出在数据库上,而不是网页的动态或静态上,但在讨论的过程中,领导强调指出问题必须给出解决方案,否则不予考虑。于是,表态的人少了,会议沉默了,然后就是方案的实现,解决问题的时限,散会……

这是个真实的案例。在本案例中,测试人员先期很积极的寻找网站速度慢的原因,但后来归于沉默,是因为测试人员没有能力解决这个问题,只能从多个方面寻找问题的原因,但谁找出问题谁负责解决的做法,打消了测试人员的积极性,测试人员是找问题的,不是解决问题的。多一事不如少一事。可以预见,这个方案最终会不了了之。

这就是在大多企业中软件测试人员的一种窘境,测试人员即要发现问题,还要解决问题,并且测试人员和开发人员一般在同一个部门,发现的问题越多,自己不解决,就给开发人员造成的返工量越大,开发人员和测试人员的矛盾很多,又得不到有效的解决。

总结企业中测试人员面临的问题:

1、测试人员的工作量很大,同时要为多个项目做测试,但收入却很低。

2、测试人员不具备独立性,企业的信息部门很少设有测试组一类的,测试人员往往和开发人员在同一个科室,开发人员有时兼做另一个项目的测试人员,表面上是方便了与开发人员的交流,实际上却阻碍了测试工作的进展,碍于情面,谁都要在组织内生存,谁都不愿以工作影响了同事关系。

3、领导对测试工作的轻视问题。有些领导不懂测试流程,甚至分不清集成测试和系统测试,不给测试人员说话的空间,喜欢自己说了算,当然这是题外话。

4、测试人员要解决自己发现的问题。虽然开发和测试角色可能出现重复,但两者的侧重点是不一样的,测试是发现问题,而开发则是解决问题。在实际工作中往往不是这样,特别是在一些技术问题分析会议中,谁提的问题多,谁就最终负责解决问题。迫于生存,测试人员一般不多表态。

5、测试人员的素质。程序员在干不动编程时,才会转行做测试,做职业转行的缓冲,一些优秀的编程人员一般都安排做开发了,优秀人员不做测试最重要的原因是收入低,领导也不会安排这样的人做测试,认为是人力资源浪费。所以,从开发岗位上转行来的测试人员,即使有丰富的开发经验,他也不能对所发现的问题全部解决。优秀人员的缺席也导致了测试工作效率降低。

总之,一个软件企业中,测试人员无法发挥他应有的作用,只能说明该企业的软件过程能力有问题,这属于管理人员的问题,而非测试人员所能做的。

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号