)“黑箱測試管理”以外的編程經驗片斷,一些軟體工程時間分配的啟示

(轉自)http://www.cnblogs.com/fjwuyongzhi/archive/2007/04/28/730939.html

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

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%