除了很好地進行“黑盒測試管理”，個人覺得下述更值得用功；畢竟“前除后略”！

1、架構和算法的可行性測試分析：主要包括性能、并發等方面

2、codereview：很簡單，但很多人沒有這樣做；其實這比“黑盒測試”更容易發現邊界問題、流程正確性問題等。值得推廣！

3、測試驅動和單元測試，很多人為了達到那些并不太懂編程管理層的要求，往往是少了這些看似不容易出成績的步驟。（很大程度上改變設計思維）

知道可能出錯的地方，當然容易避免出錯。

4、uml和用例：特別是ui建模，個人覺得最不可少；uml和用例至少要能覆蓋核心內容。

具體如何做，要根據每個人、每個單位甚至每個項目做具體優化，這里提供思路。

5、用心架構（各功能模塊的關系<用例等>、分布式計算的節點關系<即分層>、類的層次結構<uml圖>、升級的備案、數據庫架構、數據庫表的范式<er圖>、并發訪問和多線程等）：不好的架構，code起來吃力、問題又多又不好解決！以個人的經驗認為，一般可分為六個階段

a 用戶需求收集、訪談和確認-->
b 架構和可行性分析并文檔化-->
c 開發測試部署和維護詳細計劃-->
d1 單元編碼、測試<-->d2 部署測試-->
e1 開發環境集成和測試-->
e2 真實環境模擬測試-->
e3 部署預演-->（原系統備份）-->
f 部署

1) 各階段主要的“產出”（不考慮投入）
a：需求說明書、ui建模、用例和uml圖和系統使用幫助文件初稿、系統可能存在的風險報告
b：系統架構圖（邏輯圖和物理圖）、核心算法代碼和測試報告、第二方和第三方組件的風險分析報告
c：系統各模塊的詳細說明書，數據庫架構和測試，各功能的開發、coderivew和測試計劃、部署計劃（相當于每日構建）、集成測試計劃、系統的升級考慮和方案。注意，盡可能在code前將數據庫可能的問題解決掉！
d：代碼、bug管理、可執行文件、開發環境、測試環境
e：可發布的安裝包、最終用戶文檔、修改之前相關的文檔到和現在的系統一致
f：可能的問題預案、安裝和不斷依實際情況優化，進入維護階段

2)時間分配：a:b:c:d:e:f=10:10:20:50:5:5，a階段的時間這里指項目啟動時算起，啟動前的時間不計在內。

真正的code時間一般可能占50%