移山 - 軟件測試討論(2)

　　比如：

　　測試名稱 測試內容

　　Stress/load test 測試軟件在負載情況下能否正常工作

　　Performance test 測試軟件的效能

　　Accessibility test 測試軟件輔助功能測試 – 測試軟件是否向殘疾用戶提供足夠的輔助功能

　　Localization/Globalization Test 本地化/全球化測試

　　Compatibility Test 兼容性測試

　　Configuration Test 配置測試 – 測試軟件在各種配置下能否正常工作

　　Usability Test 可用性測試 – 測試軟件是否好用

　　Security Test 軟件安全性測試

　　1.4Unit Test單元測試

　　二柱：我們也試過用單元測試來保證質量，要求每人都要寫，在簽入代碼前必須通過單元測試。但是搞了幾個星期就不了了之。

　　大家七嘴八舌的列舉了單元測試的問題：

　　有時單元測試報了錯，再運行一次就好了，后來大家就不想花時間改錯，多運行幾次，有一次通過就行了。

　　單元測試中好多錯都和環境有關，在別人的機器都運行不成功。

　　花在單元測試上的時間要比寫代碼的時間還多

　　單元測試中我們還要測試效能和壓力，花了很多時間

　　我們都這么費勁地測了，那還要測試人員干什么?

　　1.4.1用VSTS寫 單元測試

　　單元測試的基本構成

　　Setup//設置好環境，準備測試

　　Test// 測試

　　Teardown//打掃戰場

　　例子：我們要寫一個銀行賬戶的類，那么它的單元測試應該怎么寫?

　　誰自告奮勇上來表演一下寫代碼?小飛，好請上臺。

　　小飛寫了下面的代碼：

　　定義interface IAccount

　　實現public class Account : IAccount

　　{

　　}

　　每個函數都使用臨時代碼

　　好，現在右鍵按住Account，就可以看到“Create Unit Tests”的菜單，選中之后，會出來新建Unit Tests的對話框：

　　每個函數都可以選中是否產生 單元測試。

　　//解釋單元測試的結構

　　//一個缺省的單元測試

　　//修改過的單元測試

　　//運行單元測試

　　//單元測試的結果

　　//代碼覆蓋率

　　1.4.2好的單元測試的標準

　　單元測試應該準確，快速地保證程序基本模塊的正確性。下面是驗證單元測試好壞的一系列標準：

　　1.4.2.1單元測試應該在最低的功能/參數上驗證程序的正確性

　　單元測試應該測試程序中最基本的單元 – 如在C++/C#/Java中的類，在此基礎上，可以測試一些系統中最基本的功能點(這些功能點由幾個基本類組成)，從面向對象的設計原理出發，系統中最基本的功能點也應該由一個類及其方法來表現。單元測試要測試API中的每一個方法，及其每一個參數。

　　1.4.2.2單元測試必須由最熟悉代碼的人(程序的作者)來寫

　　代碼的作者最了解代碼的目的，特點，和實現的局限性。所以，沒有比作者適合的人選。

　　問：如果我很忙，能不能讓別人代勞單元測試?

　　答：如果忙到連單元測試都沒有時間做，那么你也沒有時間寫好這個功能。在一些極限編程的方法中，是可以考慮讓別人來做單元測試，但是，程序的作者還是要對單元測試負責。

　　最好是在設計的時候就寫好單元測試，這樣單元測試就能體現API的語義，如果沒有單元測試，語義的準確性就不能得到保障，以后會產生歧義。

　　1.4.2.3單元測試過后，機器狀態保持不變

　　這樣就可以不斷地運行單元測試，如果單元測試創建了臨時的文件或目錄，應該在Teardown階段把這些臨時的文件或目錄刪除。

　　如果單元測試在數據庫中創建或修改了記錄，那么也許要刪除這些記錄，或者每一個單元測試使用一個新的數據庫，這樣保證單元測試不受以前單元測試實例的干擾。

　　1.4.2.4單元測試要快 (一個測試運行時間是幾秒鐘, 而不是幾分鐘)

　　快，才能保證效率。因為一個軟件中有幾十個基本模塊(類)，每個模塊又有幾個方法，基本上我們要求一個類的測試要在幾秒鐘內完成。如果軟件有相互獨立的幾個層次，那么在測試組中可以分類，如數據庫層次，網絡通信層次，客戶邏輯層次，和用戶界面層次，可以分類運行測試，比如我只修改了“用戶界面”的代碼，我只需運行“用戶界面”的單元測試。

　　1.4.2.5單元測試應該產生可重復，一致的結果

　　如果單元測試的結果是錯的，那一定是程序出了問題，而且這個錯誤一定是可以重復的。

　　問：如果用隨機數以增加測試的真實性，好么?

　　答：一般情況下不好，如果某個隨機數導致程序出錯，但是下一次運行又不能重復這一錯誤，于事無補。要注意我們還是要用隨機數等辦法“增加測試的真實性”，但是不是在單元測試中。單元測試不能解決所有問題，所以也不必期望它會發現所有的缺陷。

　　1.4.2.6獨立性，單元測試的運行/通過/失敗不依賴于別的測試，可以人為構造數據，以保持單元測試的獨立性。

　　程序中的各個模塊都是互相依賴的，否則它們就不會出現在一個程序中。一般情況下，單元測試中的模塊可以直接引用其它的模塊，并期待其它的模塊能返回正確的結果。

　　如果其它的模塊很不穩定，或者其他模塊運行比較費時(如進行網絡操作)，而且對于本模塊的正確性并不起關鍵的作用。這時可以人為地構造數據以保證這個單元測試的獨立性。

　　New Object

　　New user

　　Get user permission // go thru the server to get the correct permission, you can also mock the permission object.

　　Object.Test(user)

　　1.4.2.7

　　單元測試應該覆蓋所有代碼路徑，包括錯誤處理路徑，為了保證單元測試的代碼覆蓋率，

　　單元測試必須測試公開的和私有的函數/方法。

原文轉自：http://www.kjueaiud.com