51Testing软件测试论坛

标题: 2010年测试工作总结 [打印本页]

作者: 江潭素月    时间: 2011-1-26 10:52
标题: 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多多!



附:

代码走查:http://www.51testing.com/index.p ... space-itemid-223200
http://www.51testing.com/index.p ... space-itemid-219211

findBug对照表:
http://www.51testing.com/index.p ... space-itemid-219871

yslow+showslow进行页面性能评估:
http://www.51testing.com/index.p ... space-itemid-222368

Selenium:
Selenium下载及安装
http://www.51testing.com/index.p ... space-itemid-221462
启动Selenium server
http://www.51testing.com/index.p ... space-itemid-221955
Selenium处理alert弹出框
http://www.51testing.com/index.p ... space-itemid-222535
初学Selenium总结
http://www.51testing.com/index.p ... space-itemid-221977
作者: 水儿儿    时间: 2011-1-26 12:01
常做总结进步更快。想想自己工作了1年多了从来没好好总结过。
顶下楼主
作者: 水儿儿    时间: 2011-1-26 12:02
我们现在在用的自动化工具也有selenium,正在研究当中。楼主的个人空间里好像有好多关于selenium的资料。有空去看看。。谢谢分享
作者: 江潭素月    时间: 2011-1-26 14:22
回复 3# 水儿儿

没有多少资料了,就是学了那么几天,之后一直忙工作,就没在学。忙工作其实是借口,实际上是不想学了,因为招聘要求上总是看到要求QTP、loadrunner这些商用的工具,开源化的工具很少有要求的,而我还不会QTP、loadrunner呢,我想还是先了解那两个吧
作者: 楠族开心果    时间: 2011-1-26 19:00
总结的真不错,很多地方也是值得我去学习的
作者: 江潭素月    时间: 2011-1-27 09:22
回复 5# 楠族开心果


    谢谢,开心果姐姐,好谦虚啊,你工作经验比我丰富多了,以后得多请教您
作者: 江潭素月    时间: 2011-1-27 09:24
希望大家能对我总结的这几个问题再发表下自己的意见,看看大家都有什么高见,在工作中都是怎么处理这些问题的,先谢谢大家了
作者: 水儿儿    时间: 2011-1-27 11:14
3)关于bug是否需要修改的问题
网上讲测试用例时,讲到用极限值、在输入数字的地方输入字母,但是这样测出来的问题,开发人员很反感,他们不愿意修改这样的问题,只想修改正常操作出现的问题,甚至他们的主管也是这样认为,认为客户不会那样操作,让我们测试人员很苦恼。
我们往往在这样的bug上存在争议:出现频率很高,只要运行程序就出现。但不是致命的bug,不影响功能,修改起来也很比较容易。
例如打开一个页面时,只是在左下角报脚本错误,功能照样用。像这样的Bug,开发人员心情好就改,心情不好就不改。我们测试人员对于这种bug是倾向于修改的
江潭素月 发表于 2011-1-26 10:52

对于这个问题,我们的做法是, 只要是发现有问题的地方都作为Bug提交上去,至于要不要修改什么时候修改,项目经理会去做这个决定。当然,我们可以给项目经理或者是需求分析人员说出我们的想法和这个BUG会带来什么样的影响。
我们一般都会坚持让他们解决所有发现的问题
作者: staring0326    时间: 2011-1-27 11:34
如果开发人员更改完成bug后,如何给测试人员提交更改的代码呢,这个问题我想知道。我们现在是让开发人员提供增量文件,但是这样做的很少
作者: 江潭素月    时间: 2011-1-27 14:11
回复 8# 水儿儿


    你们还有需求分析人员啊,我们就一个负责项目的人员,他管着安排任务,他对测试不懂,就像我上面说的那个脚本bug,他都说不改,说只要功能能用就行。
作者: 江潭素月    时间: 2011-1-27 14:13
回复 9# staring0326


    我们公司的流程,在上面我已经提到了,开发人员修改完后就提交到svn上,测试人员就更新。这样的模式不可取。

  有些公司是这样的,开发人员修改了程序,以打补丁的形式打到测试人员目前所测的包上
作者: 原点    时间: 2011-1-28 10:04
LZ所说的第二个问题,我也遇到了,我们领导说不要写测试用例,于是我就开发改了哪,我测试哪里,想到哪测试到哪,可最后发现很多测试过的模块,返过来又要测试,好像一直在兜圈圈。
有几次试着把经常用到模块的测试用例写下来,下次再测试到该模块时就去看用例,是否需要补充用例,然后按用例执行,这样在速度效率上似乎要好很多。
作者: hbtest    时间: 2011-1-28 10:23
对于写测试用例,按照测试用例进行测试工作,我也是感触颇深啊,我们现在的测试也是不写测试用例,想到哪测到哪,导致系统会出现测试遗漏的地方,不能将系统都覆盖。且开发人员在修改了相关功能后,还得再重新测试,没有具体的测试步骤。现在越来越觉得在测试过程中,图省事不写测试用例真是不可取啊。
作者: miliewei    时间: 2011-1-28 11:17
目前的现状和楼主的差不多。也很希望能写测试用例按测试用例来测试。不过一般都不太现实。特别是小公司,时间紧任务又多。而且公司就我一个测试的,我觉得存在的问题很多。一个人的能力毕竟是有限的,能测试到的也是有限的,所以说风险就高。而且没有测试团队感觉自己越来越退步。
作者: 江潭素月    时间: 2011-1-28 13:45
回复 12# 原点


    虽然公司没有要求测试前写测试用例,我一般是边测试边在testlink上写测试用例,但都是简单写写。尤其是将一些不容易想到的测试点记录下来,还有测试的思路。效果还是有的
作者: 江潭素月    时间: 2011-1-28 13:59
回复 13# hbtest

虽然测试前不给时间写,最好还是写一写,可以边测试边写。不用写太仔细,那样太浪费时间,主要是理思路
作者: 江潭素月    时间: 2011-1-28 14:02
回复 14# miliewei


    我们是两个人,但有时候我俩把问题反映给上级,指出自己的建议,没人听我们的。公司除了我们俩个,对测试都不怎么知道,大家都以为测试就是点点界面,很简单的事
作者: xyzwh    时间: 2011-2-10 14:02
楼主只做了一年,就会这么多东西了,你会的俺都还不是很精通啊
作者: happyrichman    时间: 2011-2-11 17:12
顶起来,不错
作者: 江潭素月    时间: 2011-2-14 13:46
回复 18# xyzwh


    没会多少东西啊,有些只是停留在皮毛阶段,需要学习的东西还有很多很多啊
作者: 江潭素月    时间: 2011-2-14 13:47
回复 19# happyrichman


谢谢
作者: 阿七    时间: 2011-2-14 14:02
的确挺乱的...
作者: amyliu2009    时间: 2012-2-18 22:50
都没权限看,楼主干吗要设置这个权限啊?
作者: amyliu2009    时间: 2012-2-18 22:51
太气愤了,让大家分享吗




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2