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.php?uid-318121-action-viewspace-itemid-223200
http://www.51testing.com/index.php?uid-318121-action-viewspace-itemid-219211
findBug对照表：
http://www.51testing.com/index.php?uid-318121-action-viewspace-itemid-219871
yslow+showslow进行页面性能评估:
http://www.51testing.com/index.php?uid-318121-action-viewspace-itemid-222368
Selenium:
Selenium下载及安装
http://www.51testing.com/index.php?uid-318121-action-viewspace-itemid-221462
启动Selenium server
http://www.51testing.com/index.php?uid-318121-action-viewspace-itemid-221955
Selenium处理alert弹出框
http://www.51testing.com/index.php?uid-318121-action-viewspace-itemid-222535
初学Selenium总结
http://www.51testing.com/index.php?uid-318121-action-viewspace-itemid-221977 常做总结进步更快。想想自己工作了1年多了从来没好好总结过。
顶下楼主 我们现在在用的自动化工具也有selenium，正在研究当中。楼主的个人空间里好像有好多关于selenium的资料。有空去看看。。谢谢分享:) 回复 3# 水儿儿
没有多少资料了，就是学了那么几天，之后一直忙工作，就没在学。忙工作其实是借口，实际上是不想学了，因为招聘要求上总是看到要求QTP、loadrunner这些商用的工具，开源化的工具很少有要求的，而我还不会QTP、loadrunner呢，我想还是先了解那两个吧 总结的真不错，很多地方也是值得我去学习的 回复 5# 楠族开心果
谢谢，开心果姐姐，好谦虚啊，你工作经验比我丰富多了，以后得多请教您 希望大家能对我总结的这几个问题再发表下自己的意见，看看大家都有什么高见，在工作中都是怎么处理这些问题的，先谢谢大家了 3）关于bug是否需要修改的问题
网上讲测试用例时，讲到用极限值、在输入数字的地方输入字母，但是这样测出来的问题，开发人员很反感，他们不愿意修改这样的问题，只想修改正常操作出现的问题，甚至他们的主管也是这样认为，认为客户不会那样操作，让我们测试人员很苦恼。
我们往往在这样的bug上存在争议：出现频率很高，只要运行程序就出现。但不是致命的bug，不影响功能，修改起来也很比较容易。
例如打开一个页面时，只是在左下角报脚本错误，功能照样用。像这样的Bug，开发人员心情好就改，心情不好就不改。我们测试人员对于这种bug是倾向于修改的
江潭素月 发表于 2011-1-26 10:52 http://bbs.51testing.com/images/common/back.gif
对于这个问题，我们的做法是， 只要是发现有问题的地方都作为Bug提交上去，至于要不要修改什么时候修改，项目经理会去做这个决定。当然，我们可以给项目经理或者是需求分析人员说出我们的想法和这个BUG会带来什么样的影响。
我们一般都会坚持让他们解决所有发现的问题:lol 如果开发人员更改完成bug后，如何给测试人员提交更改的代码呢，这个问题我想知道。我们现在是让开发人员提供增量文件，但是这样做的很少 回复 8# 水儿儿
你们还有需求分析人员啊，我们就一个负责项目的人员，他管着安排任务，他对测试不懂，就像我上面说的那个脚本bug，他都说不改，说只要功能能用就行。 回复 9# staring0326
我们公司的流程，在上面我已经提到了，开发人员修改完后就提交到svn上，测试人员就更新。这样的模式不可取。
有些公司是这样的，开发人员修改了程序，以打补丁的形式打到测试人员目前所测的包上 LZ所说的第二个问题，我也遇到了，我们领导说不要写测试用例，于是我就开发改了哪，我测试哪里，想到哪测试到哪，可最后发现很多测试过的模块，返过来又要测试，好像一直在兜圈圈。
有几次试着把经常用到模块的测试用例写下来，下次再测试到该模块时就去看用例，是否需要补充用例，然后按用例执行，这样在速度效率上似乎要好很多。 对于写测试用例，按照测试用例进行测试工作，我也是感触颇深啊，我们现在的测试也是不写测试用例，想到哪测到哪，导致系统会出现测试遗漏的地方，不能将系统都覆盖。且开发人员在修改了相关功能后，还得再重新测试，没有具体的测试步骤。现在越来越觉得在测试过程中，图省事不写测试用例真是不可取啊。 目前的现状和楼主的差不多。也很希望能写测试用例按测试用例来测试。不过一般都不太现实。特别是小公司，时间紧任务又多。而且公司就我一个测试的，我觉得存在的问题很多。一个人的能力毕竟是有限的，能测试到的也是有限的，所以说风险就高。而且没有测试团队感觉自己越来越退步。 回复 12# 原点
虽然公司没有要求测试前写测试用例，我一般是边测试边在testlink上写测试用例，但都是简单写写。尤其是将一些不容易想到的测试点记录下来，还有测试的思路。效果还是有的 回复 13# hbtest
虽然测试前不给时间写，最好还是写一写，可以边测试边写。不用写太仔细，那样太浪费时间，主要是理思路 回复 14# miliewei
我们是两个人，但有时候我俩把问题反映给上级，指出自己的建议，没人听我们的。公司除了我们俩个，对测试都不怎么知道，大家都以为测试就是点点界面，很简单的事 楼主只做了一年，就会这么多东西了，你会的俺都还不是很精通啊 顶起来，不错 回复 18# xyzwh
没会多少东西啊，有些只是停留在皮毛阶段，需要学习的东西还有很多很多啊
页:
[1]
2
