近一個月左右的時間裡，我參加了某專案的測試工作。具體有：編寫測試用例，實施單體測試（其實是功能性測試），實施強化測試。

測試結束後，出現了若干個Bug，分類一下，有如下幾個原因：

對原始碼沒有很好的進行管理：2個。由於資訊溝通不暢，該提交的css檔案沒有提交，導致畫面表現和測試時不一致，被客戶指責。

對本專案特有的作法不熟悉：1個。客戶方提供畫面Demo為主頁檔案，約定俗成的規矩是：我們在他們的Demo檔案基礎上改動。而不遵守此點，被客戶發現，被指責。

對式樣理解不正確： 2個。

1個是因為沒有理解客戶需要在輸出的Excel檔案中，NUll為空白顯示，如果為其他則用=''來表達。對此說明理解有誤。導致沒有用'xxx'來輸出，而無論開發人員還是測試人員，都沒有認識到這一點。

1個是對某模組的三種狀態理解不正確。以為只有兩種狀態。事後仔細閱讀詳細設計文件也發現了這一點。

但是由於專案的歷史積累很龐大，在很短的時間裡閱讀完畢詳細設計文件存在困難。如果有一個可以參考的地方，提供出完整的畫面遷移圖，也可以瞭解到該模組有幾種狀態。

測試人員不細心導致：N個。

比如：用例寫明要求某專案的值大於零的時候，需要用紅字顯示。但測試者沒有驗證等於零的情況，結果等於零也是紅色。當然被指責。不過，話說回來，也可以把Case寫的細緻一些，列出值等於零的情況。使得測試者無法躲避。

還有，測試用例中明明寫著畫面的Layout要和使用者提供的Demo一致，但是測試人員根本沒有進行比對。直接把畫面複製貼上了事。這是很不好的習慣。

測試用例不夠細緻清晰：N個

比如：客戶的設計文件中提到的時間日期格式：yyyymmddhhmmss,其實他們想要的是24小時格式。而這一點在寫Case之前，我們必須和客戶確認好。而且要分別對0x點（比如5點）和1x點（比如15點）的型別分別測試。又因為編碼人員錯誤的採用的simpledateformat ,導致把12點若干分表示成了00點若干分。導致事後，我們把從0點到24點的各個時段全都測試了一遍。

從這一點上，也看出，等待最後測試把門的方式，實際上很容易造成遺漏，而且測試的代價也很大。從0點到24點的各個時段全都測試，這種方式如果在編碼的時候，由編碼人員自己實施的話，要輕鬆很多。當然jsp頁面自動化測試很困難。

不過，做一個測試用的頁面，把24小時的時間段在畫面上都表示一下，恐怕早就會發現自己的問題。

使用者的設計文件不完整：N個

客戶的要求裡面，有全稱改略稱的要求。雖然在頁面初始化的時候，按下檢索按鈕的時候都正確。

但是在畫面上進行各種編輯活動的時候，卻會再次變成全稱，結果也導致客戶指責。而實際上，這一點在客戶的設計文件上完全沒有。

此外，還有客戶中途變更設計書，導致已經進行的測試用例沒有了用處，還得重新進行測試之類。

而且，在強化階段，還無意中發現了，

為了滑鼠移動的時候，顯示提示資訊。在本該採取左連線的地方，錯誤地採取的等值連結。這是個非常嚴重的問題，

會導致客戶的資料很多都無法抽取出來。而這本該在程式碼Review的時候就發現出來。

我想，是否對從資料庫抽取資料這樣的操作，在輸出到頁面之前，就要在DAO層次上進行嚴格測試。

綜合來看：

從客戶方角度，維護一個最新狀態的，與原始碼一致的設計文件十分重要。若非如此，很容易造成開發，測試實施的遺漏。

而另外，很多的問題，都可以早期發現，早期防止。比如：對維護專案而言，當客戶對系統提出維護性開發需求的時候，

應當進行風險分析，詳細記錄分析過程：那些地方需要修改，會影響到那些地方等等。如果可能，具體到程式碼的原檔案級別更為理想。

這樣，當修改程式碼完畢後，方便專案經理或者Leader進行檢查，探討。事情推到測試級別後，代價就比較高昂。

當然，客戶給定的工期較緊張，也導致我們無法很好的進行程式碼Review，對設計文件的QA等。

[@more@]

近階段測試工作小結：

相關文章