2018-2019-1 20189206 《構建之法》第二章 學習筆記

第二章 個人技術和流程

單元測試

單元測試應該準確、快速地保證程式及本模組的正確性。

• 單元測試的標準
  • 單元測試應該在最基本的功能、引數上驗證程式的正確性。
    • 單元測試應該測試的是程式中最基本的單元、系統中最基本的功能點。
  • 單元測試必須由最熟悉程式碼的人來寫
    • 最好在測試的時候就寫好單元測試，可以體現API的語義。
  • 單元測試過後，機器狀態保持不變
  • 單元測試要快（一個測試的執行時間是幾秒鐘而不是幾分鐘）
  • 單元測試應該產生可重複、一致的結果
  • 獨立性——單元測試的執行、通過、失敗不依賴於別的測試，可以人為構造資料，以保持單元測試的獨立性。
    • 單元測試中的模組可以直接引用其他的模組，並期待其他模組返回正確的結果。
  • 單元測試應該覆蓋所有的程式碼路徑
    • 所有的程式碼路徑是包括錯誤處理的路徑，為了保證程式碼的覆蓋率，單元測試必須測試公開和私有的函式、方法。
      ** 100%的程式碼覆蓋率不等於100%的正確性 **
  • 單元測試應該整合到自動測試的框架中
  • 單元測試必須和產品程式碼一起儲存和維護

迴歸測試

在單元測試基礎上，就可以建立關於這一模組的迴歸測試。顧名思義，在專案中，一個模組或功能以前是正常的，但是在一個新的構建中出了問題，那麼這個模組出現了“退步”從正常工作的狀態退化到不正常工作的狀態。

迴歸測試最好要自動化，對每一個構建快速執行所有的迴歸測試，以保證今早發現問題。

• 迴歸測試的目的在於
  • 驗證新的程式碼改正了缺陷
  • 驗證新的程式碼沒有破壞模組的現有功能

效能分析

• 兩種分析方法
  • 抽樣 當層序執行結束時，VS檢視這個程式執行在哪一個函式內，並記錄下來。程式結束後，VS得出關於程式執行時間分佈的大致印象。
  • 程式碼注入 將檢測程式碼加入到每一個函式中，程式的各個效能可以被精確地測量。缺點是程式的執行時間會大大加長，產生很大的資料檔案，增加資料分析的時間。
  • 一般的做法是先利用抽樣方法找出效能瓶頸，在針對特定的模組用程式碼注入的方法進行效能分析。

個人開發流程PSP(personal Software Process)

• 計劃
  • 明確需求和其他相關因素，指明時間成本和依賴關係
• 開發
  • 需求分析
  • 生成設計文件
  • 設計複審
  • 程式碼規範
  • 具體設計
  • 具體編碼
  • 程式碼複審
  • 測試（自測、程式碼修改和提交修改）
• 報告
  • 測試報告
  • 計算工作量
  • 事後總結，並提出過程改進計劃

PSP有如下特點

• 不限於某一種軟體技術，而是著眼於軟體開發的流程，開發出不同應用的軟體工程師可以互相比較
• 不依賴於考試，主要靠工程師自己收集資料，然後分析提高
• 在小型、初創的團隊中很難找到高質量的專案需求，意味著程式設計師的輸入質量不高，得到的軟體質量也不高
• PSP依賴於資料
• PSP的目的是記錄工程師如何實現需求的效率，而不是記錄顧客對產品的滿意度。

總結

在過去的學習和實踐中因為專業學的很多，沒有接觸到專案開發流程和類似於團隊管理這方面的知識，通過本章對於PSP個人開發流程的學習，瞭解到一個軟體專案的開發不僅僅侷限於程式碼的編寫，著眼於整個專案的開發，從需求分析到最後的事後總結，並詳細記錄每個環節所需要的時間，可以更加高效地完成專案，同時也會發現，在做專案的專案詳細地劃分使得工作方向更加明確，在以後的學習中我也會更加註重這方面知識的積累，開發專案時合理規劃每一個階段並計算所需時間。