“.Net軟體測試自動化之道”

久聞此書大名，終於在上個星期把它從圖書館裡借了出來。看後感覺前半部分對測試人員來說還是不錯的，但是後面部分過於傾向代碼開發，比較適合做白盒測試，單元測試。整體上要求讀者有一定的開發能力，但是測試人員也可以把它作為一本瞭解開發人員如何做測試的參考書。

術語

test harness 測試套件

test suite 測試組

SUT(System Under Test)、AUT(Application under Test)、IUT(Implementation Under Test)待測程式

Console application 控制台程式

精華

自動化測試技術是為了補充其他測試的不足，比如手工測試，測試驅動開發，基於模型的測試，開源測試架構，商業測試架構等等，而不是替代這些測試。軟體測試自動化相比於手工測試的5個優點（SAPES）

1.更快的速度（Speed）

2.更高的準確性（Accuracy）

3.精度（Precision）

4.效率（Efficiency）

5.更有利於測試者提升自身技能（Skill-Building）

文中作者提出了“輕量級的自動化測試”的概念，認為輕量級的自動化與開源測試架構和商業架構相比，沒有那麼陡峭的學習曲線，與商業自動化測試架構相比，輕量級的自動化測試花費相對便宜並且很容易定製。與開源測試架構相比，輕量級的自動化測不會有太多版本更新和bug修複，從而更為穩定。最大的優點是可以調動測試者的主觀能動性－輕量級的自動化測試積極鼓勵編寫有創造性的測試程式，而商業架構和開源架構常常限制你只需編寫架構支援良好的那些測試類型。它唯一的缺點是不太容易維護。

第一部分  Windows應用程式測試

第一章  API測試

API(Application Programming Interface)測試的自動化是軟體測試自動化最基本的一種類型。從本質上說，API測試是用來驗證組成軟體的那些單個方法的正確性，而不是測試整個系統本身。API測試也被稱位單元測試(Unit Testing)，模組測試(Module Testing)，組件測試(Component Testing)以及元件測試(Element Testing)。從技術上說，這些術語是有很大區別，但是在日常應用中，你可以認為他們大致具有相同的意思。它們背後的思想就是，必須確定系統中每個單獨的模組工作正常，否則，這個系統作為一個整體不可能是正確的。

手工測試一個API的步驟：

建立一個小的程式，

把待測的類copy到測試程式中，

針對待測方法寫入程式碼（hard-coding）一些輸入值，

運行這個存根程式（stub program）以得到實際的輸出結果，

然後通過肉眼來比較實際的結果是否與預期的結果一致，

從而決定測試是否通過。

自動化測試API的步驟：

1）儲存用於測試案例的資料存放區測試案例資料的檔案

a－獨立於測試套件

b－檔案中的每一行代表一個單獨的測試案例，每個測試案例基本欄位為：測試案例ID，待測方法，測試案例輸入以及期望結果。每個欄位用統一的字元分開，如“：”

c－檔案格式可以採用文字檔或XML格式甚至SQL表。對於輕量級的自動化測試程式來說，出於簡單性的考慮，文字檔是最好的資料存放區方法。

2）讀入測試案例資料一般通過while迴圈語句遍曆測試案例檔案檔案的每一行，將資料讀入。路徑最好用相對路徑。

3）解析測試案例採用類似spit的方法，把分隔字元作為輸入傳給它，然後把傳回值存入一個字元數組。

4）把資料轉換為合適的類型

5）判定測試案例通過與否

6）記錄測試案例結果把測試案例ID和測試結果寫到一個獨立於測試程式的簡單文字檔中

7）給測試案例結果加上時間戳記可以把時間戳記加到測試結果的檔案名稱中

8）通過計算對測試結果進行總結通過簡單的整數計數器，計算測試案例的通過與否

9）獲得測試回合的總時間

10）注意驗證輸入為空白或期望值為空白的情況

11）處理“方法拋出異常”的情況

12）處理輸入參數為空白字串的情況

13）編寫程式使得測試案例失敗時發送警告郵件

第2章 基於反射的UI測試（Reflection-Based UI Testing）

第3章 基於Windows的UI測試

第4章 測試套件設計模式

測試案例資料的儲存方式

a－平面型的儲存結構（flat storage）：純文字檔案

b－階層（hierarchical）：XML檔案

c－關係型（relational）：SQL資料

測試處理資料的兩種基本方式是流方式（streaming）和緩衝方式（buffered）,用虛擬碼表示如下：

streaming

迴圈開始

     從外部儲存讀入單個測試案例

     把測試案例資料解析成輸入值和期望值

     調用待測組件

     判斷測試案例結果

     把測試案例結果儲存到外部儲存

迴圈結束

buffered

迴圈開始    //1.讀入所用測試案例    

        從外部儲存把單個測試案例讀入記憶體

迴圈結束

迴圈開始    //2.運行所有測試案例

     從記憶體中讀入單個測試案例

     把測試案例資料解析成輸入值和期望值

     調用待測組件

     判斷測試案例結果

     把測試案例結果寫入記憶體中的資料結果

迴圈結束

迴圈開始    //3.儲存所有測試結果

     把測試案例結果從記憶體寫入到外部儲存

迴圈結束

streaming處理模型比buffered模型更為簡單，因此它通常是最好的選擇。但是，在下面情況下，應該考慮使用buffered處理模型。

1.如果待測系統涉及檔案輸入輸出，通常我們希望盡量減少測試套件的檔案操作。如果需要對效能進行監測，那就尤為如此。

2.如果需要對測試案例輸入進行預先處理（例如，從不同的資料存放區讀出測試案例資料並進行過濾）或者延遲對測試案例結果的處理（例如，為了彙總不同類型的測試案例結果），這種情況下，讓資料儲存在記憶體中以便於處理通常是更為方便的方法。

接下的幾節分別介紹了如下組合的具體的實現方法，個人傾向於使用文字檔儲存資料並採用streaming模型因為其的簡單，不過有時也會視需要選擇其他的。

1）檔案檔案儲存體並採用streaming模型

2）檔案檔案儲存體並採用buffered模型

3）XML檔案儲存體資料並採用streaming模型

4）XML檔案儲存體資料並採用buffered模型

5）SQL儲存資料並採用streaming模型

6）SQL儲存資料並採用buffered模型

第2部分 Web應用程式測試

第5章 請求－響應測試

第6章 基於教本的Web UI測試

第7章 底層的Web UI測試

第8章 Web Service測試

第3部分 資料測試

第9章 SQL預存程序測試

第10章 排列與組合

第11章 ADO.NET測試

第12章 XML測試

由於第2部分和第3部分本人接觸的不多，就不介紹了。不過第10章的排列與組合介紹了如何通過排列組合產生測試資料的思路值得參考。