2.1單元測試

1.軟件的很多錯誤來源於程序員對模塊功能的誤解，疏忽或不了解模塊的變化。單元的測試可以讓自己負責的模塊功能定義盡量明確，模塊功能的改變不會影響其他模塊，而且模塊的質量能得到穩定的、量化的保證。

2.創建單元測試的主要步驟：

• 設置數據
• 使用被測試類型的功能
• 比較實際結果和預期的結果

3.一個好的單元測試應當準確快速的保證程序基本模塊的正確性。一個好的單元測試應該滿足以下標準：

• 單元測試應該在最基本的功能/參數上驗證程序的正確性
• 單元測試應該由最熟悉代碼的人（程序的作者）來寫
• 單元測試過後機器的狀態應保持不變
• 單元測試要快
• 單元測試應該產生可重復、一致的結果
• 獨立性-單元測試的運行/通過/失敗不依賴別的測試，可以認為構造數據，以保持單元測試的獨立性
• 單元測試應該覆蓋所有代碼路徑(100%的代碼覆蓋率不等於100%的正確性)
• 單元測試應該集成到自動測試的框架中
• 單元測試必須和產品代碼一起保存維護

4.回歸測試：從正常工作的穩定狀態退化到不正常工作的不穩定狀態。 回歸測試最好要自動化，這樣可以對每一個構造快速運行所有的回歸測試，以保證盡量早的發現問題。單元測試是回歸測試的基礎。

2.2效能分析工具

1.效能分析工具可以測試代碼運行的效率，讓程序員有針對性的對程序代碼進行優化升級。

2.常用的方法有：

• 抽樣：當程序運行時 效能分析工具時不時的看看程序運行在哪一個函數裏，程序運行結束就會得出一個程序運行時間的大致印象。不需要改動程序，可以很快找到瓶頸，但是不能準確表示代碼中的調用關系樹
• 代碼註入：將檢驗代碼加入到每個函數中，這樣程序得一舉一動都會被記錄下來。程序的各個效能數據都會被精準的測量，但是程序的運行時間會大大將長，還會產生很大的數據文件，增加了數據分析的時間，同時註入的程序代碼也影響了程序真實得運行情況

3.先抽樣找到效能的瓶頸，然後對特定的模塊用代碼註入的方式進行詳細分析。

2.3個人開發流程

1.個人開發流程：軟件工程師開發軟件的工作流程

2.PSP特點：

• 不局限於某一種軟件技術，而是著眼於軟件的開發流程
• 不依賴考試，而是要靠工程師自己收集數據，然後分析提高
• 依賴於數據
• PSP的目的是記錄工程師如何完成實現需求的效率，而不是記錄顧客對產品的滿意度。

在此之前，寫完代碼就結束了，從未做過單元測試，也未考慮過代碼效能優化問題。書上調用次數的例子讓我明白了代碼上的一個微小的改變可以大幅度提高效率。不寫單元測試的壞處目前沒有體會到，但我知道了亡羊補牢，在每一個模塊中把本部分問題解決，否則最後的大窟窿是沒辦法補上的。編程只是軟件開發中的一個部分，從個人開發流程可以看到，需求分析、對方法的使用、總結等都非常重要。

《構建之法（第三版）》第二章