項目還沒有結束，剩下的任務，不是我現在的水平能參與的了。
想想這幾個月，從式樣理解開始，參與了詳細設計，編碼，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.kjueaiud.com/
