個人技術和流程

• 1. 單元測試
• 1.1 寫一個單元測試
• 1.2 用以驗證的Assert類/斷言
• 1.3 如何寫好單元測試
• 1.4 迴歸測試
• 2. 效能分析工具

1. 單元測試

一般情況下一個軟體是由多人合作完成的。 儘可能的讓自己負責的模組獨立化，在保證自己穩定的同時，還不要影響其他功能模組。單元測試就是一個解決方案。

1.1 寫一個單元測試

可分成如下幾步

1. 新建一個專案，如控制檯專案console
2. 在該專案下新增一個類Email，類中包含要測試的方法
3. 選擇當前解決方案，新建專案->測試->單元測試專案
4. 給單元測試專案新增引用，將console新增進來
5. 通過測試->執行->所有測試，來檢視測試結果

單元測試簡單舉例
https://blog.csdn.net/chr23899/article/details/53035062

1.2 用以驗證的Assert類/斷言

除去異常類exception，還有斷言的Assert類

1.3 如何寫好單元測試

• 應該能準確的、快速的保證程式基本模組的正確性
• 測試的應該是一些底層的基本單元，在此基礎上再測試其他功能
• 對API的每一個方法及引數都要涉及
• 程式碼的目的特點以及侷限性，作者是最熟悉的，模組單元測試由該模組作者來寫最合適
• 單元測試測試的是單元，單元測試要快（一個測試時間應為幾秒，而不是幾分鐘）
• 有了模組化的功能，對每個功能都有對應的單元測試，這樣在更改某個功能時，只需找到對應的單元測試執行查錯即可。
• 單元測試的執行、通過、失敗不依賴於其他測試，應保證獨立性。
• 要做到對程式碼的全覆蓋，保證覆蓋率，必須測試公開的和私有的函式、方法
• 即使是通過也存在一些異常情況。另外還有程式碼效率低下等諸多問題
• 單元測試程式碼應與源程式一起妥善保管加以維護，爭取將其自動化。否則會浪費多餘的時間在尋找哪裡出錯上，額外增加負擔

1.4 迴歸測試

如果一個模組或功能以前是正常工作的，但是在一個新的構建中出了問題，那麼這個模組就出現了一個“退步”（Regression），從正常工作的穩定狀態退化到不正常工作的不穩定狀態。
迴歸測試的目的很明顯：

1. 驗證新程式碼是否改正了缺陷
2. 驗證新程式碼有沒有破壞模組現有的功能

迴歸測試就可以理解為迴歸到以前不正常的狀態。這樣把以前記錄的bug找出來，並一個個驗證，一個個修復，這樣是一個不斷修復bug的過程。

2. 效能分析工具

當編譯和執行一個工程時,可以在Debug和Release兩種配置下執行。

• Debug模式又稱除錯版本。用於除錯程式，這是個受保護的執行環境，它將告訴你程式是否有洩露，在執行時也能對特定函式的結果進行檢查。然而它生成的可執行檔案執行較慢。我們Debug過程中為什麼可以打斷點，為什麼滑鼠放在變數上就顯示值，因為編譯器背後加了很多測試程式碼。
• Release模式又稱釋出版本。當你的應用經過測試準備投入使用時，你應該在Release模式下進行編譯，這將生成供終端使用者使用的可執行檔案。雖然Release下也可以打斷點，但是有時候有些變數的值在Release下是看不見的。除錯的話應該用Debug。它往往進行了各種優化，以期達到程式碼最小和速度最優。

VS 提供了自帶的分析工具：performance tool (效能分析)
VS選單欄->除錯->效能探查器，在這裡可以診斷程式的效能問題、識別應用程式中最常見的高開銷方法。常用工具如下所示：

• 這樣可以方便的很快定位到一些效率低下反覆呼叫的無用程式碼，將程式進行改善，提升執行速度。