工作总结

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/?uid-318121-action-viewspace-itemid-228418

附：

代码走查：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
启动Seleniumserver
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