首次测试项目经验总结

刚刚结束最后一个页面的性能测试，也暗示着我参加的第一个项目的告终。三个月了，总结一下！：）
　　项目还没有结束，剩下的任务，不是我现在的水平能参与的了。
　　想想这几个月，从式样理解开始，参与了详细设计，编码，PT1,PT2，结合测试，直到最后的性能测试。项目虽然不大，技术含量也不高，却着实让自己学到了不少东西。
初进项目组
　　leader第一天开了一个小会，主要把项目的背景和一些相关情况给我们讲解了一下。然后发给我们工程表，我被分到了两个最简单的页面（照顾新员工嘛^.^）。
　　前两天的任务就是式样理解（日方提供的式样书，相当于系统设计文档）。我当时很费解，为什么一个试样书的理解需要两天的时间。文档是日文的，幸好有翻译帮忙，当我一一了解了那一句句难懂的日文之后，去分析它的要求和目的，初步设想解决办法。还的确用了整整两天的时间。（leader对时间掐的还是蛮准的嘛）
详细设计
　　刚做的时候，感想很多，记得当时写过一篇blog。
http://www.blogjava.net/realsmy/archive/2007/08/29/140736.html
　　这是这几个月始终没有脱离的内容，也是最让我痛苦的部分。随着式样一次又一次的变更，BUG一个又一个的发现，就得一遍又一遍的修改啊。
编码
　　PG的日子过的还是挺快乐的。我喜欢编码，喜欢遇到各种无法解决的问题，喜欢感受那解决完每一个“实现难点”后的快感。
PT1
　　第一轮测试是针对详细设计书的，先是通过Excel的一个带宏的模板，把DD设计书转成PT1测试书。然后就是根据自己当时写的每一个设计点进行测试。
　　从方法上讲属于白盒测试，利用的就是eclipse提供的单步调试。测试代码的运行是否正常走到了每一个测试点，以及针对详细设计，测试代码的逻辑设计是否完善。
PS：测试的BUG数有很多说道，特别是，0个BUG和1个BUG的区别，要远高于1个BUG和两个BUG的区别。
PT2
　　就是黒\盒测试。测试书需要自己来写，每一个测试点都要写得很详细。然后针对测试数一一测试。每一个测试点还都需要保存相应的截图。
　　起初我还真小看了PT2，总感觉自己写的代码，在编码的时候就调试过很多次了，而且又经过了PT1，哪里还会有错误。结果恰恰相反。PT2的BUG数还真不少。
　　让我想起leader曾说过的，“一个页面的完成，不是说点击一个功能按钮，出了结果且没有报错就算完成了。”。的确，那最多算完成了一半儿。
结合测试
　　测试数是leader自己写的，从整个系统的使用角度去想，把我们每个人做的部分都结合到服务器上，调试各种结合的测试。如果说我们每个人做的部分是一个模块的话，主要是考察模块与模块之间的磨合性，以及自己的模块在众多模块中的生存性。
　　看了leader的测试书，再看自己的PT2测试数，其实有些部分是差不多的，但是能明显的看出，leader考虑的内容要比我考虑的完善得多。还有待学习啊。
性能测试
　　我感觉最有意思的部分，因为对我来说是最新鲜的。从来没有实际的操作过那么多条数据。我本是个对数字十分敏感的人，这对我来说，更是一种吸引。
　　可惜的是，我涉及到的几个表，要求施加的压力都太小了。很容易的就测完了。看这我的导师和另几位同事，一插就是几百万条，还在讨论着各自的时间和方法，自己真的有些羡慕。下次有机会一定要要爽一回，一口气也插它个几百万条。
　　总结下自己的成长：
1. 对一个外包的项目有了初步的了解。当然我知道，每一个项目都是不一样的，涉及到的步骤，相关工具，相关模板都是不一样的。我在期待着下一个项目。
2. 对struts有了更深一层的了解。这个项目的框架是同事写的，其实就是在struts的基础上又封装了一层，曾经几次想要修改这个框架，也让我长了不少见识。特别是在编码中应用到的log4j,filter等，以前都没用过，也不知道是谁发明的，的确好用。
3. 深刻体会到一个良好的管理体系对做外包项目是多么的重要。本身外包（我做的这个）的技术含量并不高。一个团队需要做好的就是在最短的时间的内对每一个阶段内容做到最优。
4. 日语的重要性。无论是读还是写还是听。都太重要了。如果日语好的话，不用每次都找翻译帮你解释一个个文档，不用每次都查字典去看某个单词怎么写，不用等翻译在的时候才可以和日本客户交流。我，还差的太远。
　　期待着下一个项目。（据说下周就可以确定了，应用东芝框架的那个，哈哈，我喜欢）
给自己加油！～:) 

原文转自：http://www.ltesting.net