2010年测试工作总结

      2010-3从开发转为测试,开始了我的软件测试工作,近一年的时间了。刚做这个工作时,只知道测试是要检查程序有没有错误,其他的就都不知道了,后来通过搜索,在51testing上浏览帖子,才慢慢知道测试到底是怎么回事。
       2010-3入职到现在的公司时,测试组刚成立,之前没有专职测试人员,所以公司也没有关于测试的规范,没有人真正了解过测试。我和另一个同事边学习边摸索,进行着测试的工作。
       这一年来,主要做的工作就是黑盒中的功能测试,也就是别人所认为的点点界面,但是自己真正做了才知道,测试并非是个人就能做,并非仅点点界面的事情。从刚做测试只会输入正确的数据,到现在测试边界值、极限值、非系统要求数据类型的值等等。慢慢体会到了书本上所说的等价类划分方法 、边界值分析方法、错误推测方法、因果图方法的含义。其次,做了代码走查的工作,使用jupiter作为走查中bug记录的工具,使用findBugs插件辅助走查逻辑错误。再就是各种文档的编写,编写过ISO9000的文档、竞标文档、各项目的需求分析、概要设计、数据库设计、操作手册等。再就是初步学习了开源自动化工具selenium、学习了使用slow+showslow进行页面性能评估,初涉了单元测试插件junit,了解了QTP、loadrunner,但都没有深入学习。
       由于公司没有了解测试的相关人员,我们俩只是在摸索中做着测试的工作,所以测试过程中发现存在很多问题。
       先说下我们的测试流程: 公司有测试人员2个。如果开发人员有需要测试的程序,给测试人员打个招呼,然后我们测试人员将源代码从服务器上迁到本机MyEclipse,然后部署运行,进行测试。如果发现有bug,提交到bug管理工具mantis中,开发人员访问mantis,修改Bug,提交代码,测试人员更新代码,复测。
      再说我们所测的系统:所有系统没有需求分析。都是在公司一个原有系统的基础上进行修改。客户首先拿到我们原有的系统,然后指出哪里不合适,开发人员进行修改,改完让客户试用,客户再指出哪里不合适,再修改。这样,需求变更很多次,开发人员做完一部分,想给客户更新了,然后就让我们测测,我们无法预知他们什么时候要测试,要测试什么样的功能。
      这样的工作模式我认为存在很多问题,在 51testing[你问我来答第8期]:软件缺陷管理交流 中我对工作中的问题进行了提问,在此谢谢千里和liuygneusoft的回答,真的很感谢他们,耐心分析了我工作中的问题,并分析了如何改善这些问题。现将问题和相应的改善方法总结如下:
1)测试流程存在问题,没有版本控制
没有版本管理,导致工作混乱,测试人员的工作变成没计划,没管理。比如新发现的BUG,无法去分析,是修改带来的,还是原来就有的,只是没测试到;另外,测试、修改Bug、复测的时间混在一块,分不清是谁的效率低;还有,会增加测试人员工作量。开发人员只要改代码,就会提交到SVN中,频繁的更改,测试轮次就会乱,且容易助长发人员,自己修改后不测试,就扔到测试人员手中,在liuygneusoft的公司这就private build ,测试人员不能没完没了的给开发人员帮private build测试,只有特殊情况下才用。

千里的建议:建立一个群。凡是开发有任何更新必须发群消息出来,测试员对更新情况做出记录。这样在一定程度上做到了版本控制。

liuygneusoft的建议:这是配置管理员的专职工作,但当前公司没配备,那我们只能从己有人员中想办法,谁最合适呢,当然是研发经理,也不要求正经八百的做配置管理,只是控制一下,什么时候发布下一个版本到测试人员那,或是定在每周五(多长时间,可以视情况定)发布一个新版本测试,这样也促使开发人员尽量在下一版本前修改优先级高的BUG。这样的改进方法并不复杂,只是控制一下发布时间,把时间点当成版本。

2)不写测试用例,想到哪测到哪,测试很难将功能点覆盖全面。由于测试都是临时通知,没有时间写测试用例。
liuygneusoft的建议:在没需求分析的情况下,可以按功能菜单划化测试需求,理清功能点,有了测试需求分解,可以边测试边写测试用例。这么做的好处是,可以慢慢积累用例,如中间有测试人员离职,也还有用例在。


3)关于bug是否需要修改的问题
网上讲测试用例时,讲到用极限值、在输入数字的地方输入字母,但是这样测出来的问题,开发人员很反感,他们不愿意修改这样的问题,只想修改正常操作出现的问题,甚至他们的主管也是这样认为,认为客户不会那样操作,让我们测试人员很苦恼。
我们往往在这样的bug上存在争议:出现频率很高,只要运行程序就出现。但不是致命的bug,不影响功能,修改起来也很比较容易。
例如打开一个页面时,只是在左下角报脚本错误,功能照样用。像这样的Bug,开发人员心情好就改,心情不好就不改。我们测试人员对于这种bug是倾向于修改的

千里的建议:把问题以邮件的形式反馈给开发并抄送一份给领导。同时把要不要修改的权力交给领导并暗示他,如果是谁说的不改以后出了问题谁来承担责任。

       再次谢谢千里和liuygneusoft对我的帮助,但愿在新的一年的里,我能逐步改善这些问题,提高自己的测试技术,尤其是设计测试用例的能力和性能测试的能力。祝愿大家在新的一年里快乐多多,money多多!

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值