1，UT需要許多的人力資源，並且在項目執行過程中維護工作量很大。如果在項目啓動之前思考是否要投入UT，那麼一定要非常仔細的考慮後面投入資源的問題；
2，許多做UT的項目，在UT用例的維護上投入很多，但最後隨着項目的結束（有些可能還沒有結束），這些用例就被丟棄了，因爲後來發現需要投入越來越多的工作量；
3，如果在項目中決定做UT，那麼測試和開發的人力配比需要1：1，如果只能投入1：3，那麼對於測試人員來說，將會非常困難
4，TDD是一個很好的想法，但我覺得TDD並非說要儘早進行UT，而是儘早盡心PC測試
按：經典的觀念認爲UT應該是函數測試，但是100%的函數測試幾乎是不可能的，但僅僅挑一些函數進行UT則測試邊界可能變得比較主觀，因此，我覺得是否有必要更抽象的定義unit的概念和範圍
5，PC測試加上真實環境測試是一個比較好的測試方式
6，每個開發人員都使用一套有很多用例的PC自動化測試套，並且執行速度很快，這是一種比較好的方式
7，可考慮同一套測試用例在PC和機架上共享
按：這說的應該就是端到端的測試
8，對於測試人員來說，參與前期高層設計的討論很有必要，瞭解系統的狀態圖和高層時序圖是很重要的
9，對於PC測試來說，灰盒測試比較合適
10，對於系統級的PC測試，需要關注代碼覆蓋率
11，對於PC測試來說，儘可能多的準備一些測試用例，對於真實環境測試來說，需要的是一些常用用例，因爲比較耗時
按：PC測試就是要快，秒級最好
12，如果關心分支覆蓋，建議把關心的部分單獨拎出來，做一個更小粒度的測試，這樣比較容易觀察到覆蓋情況
13，特性的測試分析和設計是一個長期的工作，和測試執行不要分離纔好
按：這其實是測試人員能力建設的問題，每一個測試管理者都必須考慮這個問題