空间管理您的位置: 51Testing软件测试网 » 江潭素月的个人空间 » 日志

2010年测试工作总结

上一篇 / 下一篇 2011-01-26 10:14:51 / 个人分类：测试总结

查看( 1983 ) / 评论( 15 ) / 评分( 0 / 0 )

       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

收藏举报

TAG:

引用删除 kentbai / 2011-02-23 08:50:35: 很不正规啊

引用删除江潭素月 / 2011-01-29 10:17:24: 原帖由islandbriar于2011-01-28 12:03:42发表
还有一种方法，可以让
1、开发主管提交测试申请后，依此为依据开始执行测试；
2、对于开发人员修复时间.

这确实是一个办法。我们现在是这么做的，让开发主管每周或者隔几天整体提交一次需求更改内容，我们只测试这些内容，等整体都修改完毕后，我们再进行整理的回归。这样确实能省很大一部分工作。
不过这样做确实有一定的问题。很多时候开发人员修改A模块可能会引起B模块的bug，但B模块不在需求更改范围内，我们测试人员没有进行测试，就给客户更新上了，导致客户那边出现问题

引用删除江潭素月 / 2011-01-29 10:11:24: 原帖由xiaogang606于2011-01-28 11:20:34发表
说点个人意见：其实用例有没有时间写，关键还是看自己的安排，原来我也老说没时间写用例等等，现在想想其.

关于用例，其实我在写，只是公司没有要求写，而且公司里除了我俩刚做测试外，其他人不懂测试，我不知道自己写的测试用例对于功能点的覆盖率能有多少。
还有我们老大是外行，技术测试都不懂，就是每个项目找个负责人管着。
年后一定想办法，提高接收测试的标准，减少测试次数，腾出更多的时间提高自己的技术。

引用删除江潭素月 / 2011-01-29 09:52:33: 原帖由xiaogang606于2011-01-28 11:16:36发表
哈哈，感觉有点向我第一家公司，不过比我第一家公司弱点，当时我们还有10个人。bug的修改判断是交给研发.

问题是负责这个项目的领导都倾向于不改，像那种脚本错误。再往上反映就是对项目、对测试、对开发都不懂的大领导了

引用删除江潭素月 / 2011-01-29 09:50:14: 原帖由蚂蚁吞大象于2011-01-28 11:06:18发表
你们才2个测试，真够辛苦的，同情下！
另外，我们这有些项目需求也是经常的变，开发都懒得整理了，我测.

现在最最郁闷的是我们辛辛苦苦整理的问题和建议，没人搭理。项目经理回复我们说过段时间开会讨论，一直没有音

引用删除江潭素月 / 2011-01-29 09:44:25: 原帖由seeon1于2011-01-28 10:24:12发表
在我看来，没有一个正规的测试管理流程，测试跟点点页面没什么区别。
我觉得你现在的测试工作太混乱了

流程不正规，但是不能左右测试人员的思想。测试的时候自己可以思考测试用例的设计，测试后总结思考如何改善测试。工作乱不能代表着测试就是点点界面吧，我觉得这两者没有必然的联系。

引用删除 islandbriar / 2011-01-28 12:03:42: 还有一种方法，可以让
1、开发主管提交测试申请后，依此为依据开始执行测试；
2、对于开发人员修复时间，需要开发主管根据进度安排，此时很可能你还在第一阶段，你可以整体去更新代码，但不用去关注已经测试过的模块，按申请单执行。
3、所有测试申请单任务执行完后，你开始对mantis上已修复的问题进行复测，其中，必须具备经验如果有测试用例更好；

引用删除 xiaogang606 / 2011-01-28 11:20:34: 说点个人意见：其实用例有没有时间写，关键还是看自己的安排，原来我也老说没时间写用例等等，现在想想其实是惰性催眠了自己。1次测试大概有个周期，几天可以完成，这个都是可以规划的。合理的安排时间，规划进度，限制开发提交的次数等等都是可以由你完成的。觉得你可以和你们老大商量下公司对测试的判断，已经测试的成分含量，确定测试的地位，要不然你会处于很尴尬的局面。很羡慕你懂开发

引用删除 xiaogang606 / 2011-01-28 11:16:36: 哈哈，感觉有点向我第一家公司，不过比我第一家公司弱点，当时我们还有10个人。bug的修改判断是交给研发经理去判断的。
建议你：将缺陷提交给经理或者项目经理，在例会时将bug提出，和他们一起讨论，不要单独和开发人员去讨论bug的有效性，要不然扯不清。