手工測試

設計用例有很多原則，但是最基礎的原則是覆蓋性，就是要覆蓋所有可能的種類（當然種類要自己區分）

例如if i〉0 then a=1 else a=0

當然還有枚舉覆蓋，路徑覆蓋等不同的覆蓋類型，還有就是要考慮到可能和不可能的類型，比如上例i=a i=“你”會怎麼樣，那測試用例又要增加

在測試過程中，手工測試的比重一般在30%左右。手工測試一般能夠發現一些自動化測試所不能發現的問題，這也是為什麼自動化測試取代不了手工測試的原因！

● 如果某項測試工作難以採用自動測試完成(甚至根本無法採用自動測試完成)，例如：在程序執行的關鍵時刻，我們需要從物理上斷開一個網絡連接，其目的在於驗證程序處理錯誤條件的能力，此時我們就可以採用手工測試。

● 對於某些測試，如果我們採用自動測試，可能導致投資回報率(return on investment，ROI)過低。例如，如果我們需要驗證一個圖形用户界面組件確實能夠應用於某個軟件產品中的某項功能的開發，而這項功能又將被其他功能替換。此時，假設使用手工測試方法只需要花費10秒時間，但是，如果使用自動測試，卻需要花費幾個小時甚至幾天的時間編寫測試，並且還要維護測試，那麼在這種情況下，我們顯然應該使用手工測試來解決問題。

● 需要使用自動測試，但是時間不允許進行自動測試的場合。

● 需要使用自動測試，但是開發團隊當前技術水平尚不足以支持自動測試的場合。

手工測試一般是基於後面這幾個原因：(1)時間資源不足；(2)技術水平不足。(3)項目週期過短。（4）機器不可代替。在這些情況下，手工測試能夠發揮重要的作用。利用手工測試，我們可以定義測試，還可以跟蹤測試，直到這些測試因為產品變更被廢棄為止。在許多開發團隊中，手工測試是以工作任務清單形式存在的，而且將來可以將這些內容進行自動化——除非這個團隊採用手工測試的原因是前面兩個因素，即：(1)自動化是不可能的；(2)測試自動化的投資回報率太低。

探討創建並運行一個手工測試的內部機制的過程中，我們必須記住創建手工測試的原因，和我們是如何創建手工測試的。

我們想定的場景非常簡單，實際上許多測試都可以歸結為一些簡單步驟的集合。在本例中，用户需要驗證Microsoft Outlook 2007可以順利過渡到Disconnected(斷開)狀態下繼續工作，同時應用程序可以將這個情況向用户報告，而且當連接斷開時，不會產生有害後果。在不會引起混淆的情況下，本章後面將這個場景稱為應用程序的收/發功能測試。

創建測試時，許多測試人員遇到的困難是他們無法定義一個完美的測試場景。我的建議是不要讓這個困難妨礙測試，也就是説一開始測試時，我們必須拋開一些次要因素，將來可以逐步完善測試。例如，在第一個場景中，我們可以在測試過程中執行其他一些工作，舉例來説，我們可以觀察當網絡連接斷開時，應用程序需要用多長時間才能夠將此情況通知用户。但是當我們進行手工測試時，一開始並不需要強調將某項功能的響應時間作為測試是否通過的標準。

編寫手工測試時，首先要描述測試目的，測試環境及其侷限，以及執行測試時常犯錯誤，然後我們需要深入到測試場景之中。此時，我們必須詳細列出測試步驟。在收/發功能這個例子中，測試場景非常簡單，只有三個步驟：

(1) 運行應用程序。

(2) 啓動應用程序的發送/接收功能。

(3) 將網絡連接物理斷開。

上述步驟執行結束後，下面要描述測試的預期執行結果。在這個例子中，我們要區分程序當時是否與郵件服務器連接，因為用户界面能夠顯示程序狀態，因此我們根據圖形用户界面來判斷程序狀態。此時用户界面應該顯示Disconnected一詞。在我們最終創建的測試中，這個顯示反饋的行為應該作為測試模板中的組成部分。

雖然我們僅僅給出了一個簡單示例，但是隻要將手工測試的其他方面考慮進來，我們就可以編寫出複雜的手工測試。編寫手工測試時，我們還可以考慮的其他方面包括：可訪問性(此時我們要確保即使用户視力不佳，也能夠及時發現其測試工具提供的用户界面所發生的變化)、可用性(在一個可控制的環境中，令用户運行測試，測試目的在於檢驗以下情況：當用户突然無法收發郵件時，用户是否能夠馬上發現網絡斷開)、安全性(其他應用程序是否能夠利用這個功能並造成不良後果？)，以及地理政治方面的因素(當把Disconnected一詞翻譯為其他語言時，是否會造成誤解或政治糾紛？)。

觀察測試如何隨時間流逝而發生演化也是一項重要工作。我們可以在測試中專門提供一個位置，在這個位置中我們可以將測試更新人員名單記錄下來。這樣當測試發生問題時，其他測試人員可以及時知道他們應該向誰諮詢。

我們已經基本瞭解了測試場景應該是個什麼樣子。下面我們使用手工測試類型創建一個測試。

手工測試類型包括純文本格式和Microsoft Word格式，Microsoft Word格式可以支持豐富格式文本，並可以嵌入圖像和表格。創建一個新的手工測試時，我們可以選擇兩種格式之一，這兩種格式分別是：

● Manual Test(text format)(*.mtx)——編輯手工測試時，我們可以在IDE中用文本格式編輯測試。如果沒有安裝Microsoft Word，那麼我們還可以使用Visual Studio編輯手工測試。

● Manual Test(Microsoft Word format)(*.mht)——我們可以使用Microsoft Word作為手工測試編輯工具。Microsoft Word為我們提供了豐富的編輯功能。例如利用這種格式，我們可以在手工測試中嵌入圖像，並且可以使文字呈現多種色彩、字體、字級和風格。

1. 文本格式通過閲讀本書，讀者可以掌握如何通過不同的途徑達到同一個目的。例如，我們既可以在Solution Explorer中用鼠標右擊一個現有的項目來創建一個手工測試，也可以在Test菜單中單擊New Test菜單項來創建一個手工測試。無論選擇哪種方法，我們在Add New Test對話框中選中Manual Test (text format)測試類型後，系統都會彈出一個測試模板。

創建一個新的測試類型後，這個新創建的測試隨即處於打開狀態，我們可以對這個測試進行編輯。手工測試類型也是如此。現在，Visual Studio編輯器已經打開了一個純文本格式的手工測試，我們現在可以編輯這個手工測試了。

利用上述測試Microsoft Outlook 2007同步行為的測試示例(也就是當Microsoft Outlook 2007執行同步操作時，網絡突然斷開，此時我們要對Outlook的行為進行測試)，給出了一個完整的測試模板。

2. Microsoft Word格式如果我們在Add New Test 對話框中選擇了Manual Test (Word format)，那麼系統將顯示一個類似的測試模板，唯一的區別就是我們可以使用不同的編輯工具——當前我們可以使用Microsoft Word(可以看到，我們當前使用了Microsoft Word 2003)完成手工測試的編輯工作。與純文本格式相比，使用Microsoft Word格式可以編輯更為豐富的內容，例如我們可以嵌入屏幕快照，還可以嵌入表格和格式化文本。

如果我們需要對默認模板進行修改，那麼我們可以在C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\ItemTemplatesCache\\1033\ManualTestWordFormat.zip\目錄下找到這些模板。在這個目錄中，表示Csharp、VisualBasic、VisualC或Test。如果我們重新進行設置，那麼新的設置將覆蓋ItemTemplatesCache目錄下的所有內容，因此一個更好的方法是修改ItemTemplatesCache目錄下的ManualTestWordFormat.zip文件。當然，如果採用了這種修改方式，那麼我們必須針對每一種語言進行設置。

我們在View菜單中選中Properties Window菜單項，就可以看到Visual Studio Properties窗口。在Test View窗口或Test Manager窗口中單擊某個手工測試後，我們就可以在Properties窗口中看到該測試的屬性。具體情況。

如果讀者當前尚未打開Test View窗口或Test Manager窗口，那麼請讀者在View菜單中選擇Properties Window菜單項，就可以打開Test View窗口或Test Manager窗口。

我們可以將當前測試的任意一個屬性添加到Test View窗口或Test Manager窗口中，這樣，我們可以基於該屬性的屬性值對手工測試進行過濾或分組。

一個手工測試包括表1-1所示的屬性。

表 1-1

如果讀者需要了解如何在連接到一個Visual Studio Team Foundation Server項目的情況下完成測試工作，請閲讀第9章的內容。

執行測試時最常用的兩個窗口分別是Test Manager窗口(該窗口僅在VSTEST中可用)和Test View窗口(該窗口在VSTEST和VSTESD中均可用)。我們可以通過選擇Test菜單中的Windows菜單項打開Test View窗口。如果讀者創建了兩個手工測試，那麼在打開Test View窗口後，在Test View窗口中，讀者可以看到兩個手工測試，這兩個手工測試都稱為ManualTest1。具體情況。

用鼠標右擊Test Name屬性列(也可以單擊Test View窗口中的任意一列屬性)，我們可以從下拉菜單(也就是上下文菜單)中選中Add/Remove Columns菜單項。此時系統彈出Add/Remove Columns對話框。這個對話框用一個列表顯示了所有的屬性，我們可以對這些屬性進行排序(我們只要單擊該列表的標題就可以完成排序操作)、過濾(需要輸入一個關鍵詞，並選擇一個屬性列，針對該屬性列，利用這個關鍵詞進行過濾)和分組(因為該窗口很小，所以可以單擊Test View窗口最右端的工具條上的overflow按鈕，然後選中對測試進行分組的屬性就可以完成分組操作)。

為了解釋如何在Test View窗口中增加一列屬性，以及如何根據某個屬性對測試進行分組，下面我們用一些測試對此進行説明。首先我們在測試項目中添加一些測試，將Owner屬性顯示為一個屬性列，然後在Group By位置處，選擇測試類型。

我們在Test View窗口中執行的所有操作都同樣可以應用於Test Manager窗口，但是，正如我們在第2章所討論的那樣，在Test View窗口中，我們還可以將測試分組為不同列表。

執行一個手工測試與執行其他測試沒有什麼不同。為了選中一個測試，我們可以在Test Manager窗口中或在Test View窗口中單擊一個測試，如果需要選中多個測試，那麼在按下Shift鍵的同時，我們可以選中鼠標兩次單擊範圍內的所有測試；此外在按下Ctrl鍵的同時，我們還可以選中一組不同的測試。

選中測試後，單擊Test Manager窗口中或Test View窗口中的工具條上的Run Selection圖標。令鼠標指針在工具條每個按鈕上方懸停片刻，我們可以觀察到每個按鈕的描述信息，從而可以瞭解該按鈕的具體功能。

我們知道，在Visual Studio中，為了完成某項工作，可以採用多種不同的方法。觀察窗口中的工具條，我們可以發現，對於某項通過單擊工具條按鈕可以完成的操作，通過用鼠標右擊屬性列或對象後，利用上下文菜單，同樣可以完成這項操作。此外，當我們在一個窗口中工作時，主窗口一般都會為我們提供一個工具條，幫助我們在當前窗口迅速完成工作。這一點對測試也同樣成立：主窗口菜單下方的Test Tools工具條可以幫助我們在測試窗口中迅速完成相關工作。為了顯示Test Tools工具條，我們可以在View菜單中選中Toolbars子菜單，然後再選擇Test Tools菜單項，就可以顯示出Test Tools工具條。

啓動執行手工測試之後，我們馬上可以看到一個信息提示，通知我們當前運行的測試包含了一個手工測試。出現這個信息提示的原因是：當我們執行一組測試時，如果當前運行的測試包含了一個手工測試，那麼運行這些測試的測試人員可以沒有意識到這種情況將會導致測試發生暫停。有的時候，測試人員啓動一個大型測試之後去吃午飯，然而，當他們吃完午飯後返回辦公室時卻發現，他們離開後大概一分鐘，測試就已經暫停下來等待手工干預，這種情況確實令人非常不快，常常使人充滿了挫折感。

測試開始執行後，Visual Studio將讀取當前測試的運行配置信息(我們在第2章討論了運行配置信息)，從而可以確定需要複製那些文件，是否需要插裝被測試程序來收集代碼覆蓋信息等內容。Visual Studio根據測試列表中的內容，一個接一個地執行測試，當遇到一個手工測試時，將顯示一條諸如“Manual Test ‘manualtest1’ is ready for execution”(手工測試manualtest1已準備好執行)之類的信息。此時，測試暫停並等待測試人員根據手工測試步驟一步步地完成手工測試過程，測試人員需要根據他們所觀察到的結果判斷該手工測試是否通過。在Visual Studio IDE中，手工測試顯示為一個標籤文檔(tabbed document)，顯示內容非常類似。

這個標籤文檔包括四個部分的內容：

● Apply工具條按鈕——只有當測試人員單擊了該文檔中Select Result分組部分中的Pass or Fail選項按鈕後，這個按鈕才會成為活動的。

● Select Result分組——在這個分組中包括兩個選項按鈕，即Pass選項按鈕和Fail選項按鈕。利用這兩個選項按鈕，測試人員可以確定手工單步執行測試腳本的測試結果。

● Comments文本框——在這個文本框中輸入的信息可以保存為測試結果，如果測試發生失效，那麼測試工程師可以在這個文本框中輸入更為詳細的失效信息。

●測試腳本視圖——這個標籤文檔窗口的底部給出了測試腳本的內容。測試人員可以利用Visual Studio內置的文本編輯器或Microsoft Word編寫測試腳本。

如果讀者使用Microsoft Word編寫手工測試，那麼當測試執行時，請讀者注意測試人員所看到的表格和嵌入圖片的顯示方式。純文本格式的測試版本可能會對相關內容進行大幅度簡化。

測試人員確定測試輸出結果後，單擊Apply按鈕，隨即可以看到Test Results窗口，這個窗口顯示了測試輸出結果。單擊Apply按鈕後，用於為測試人員顯示手工測試腳本的標籤文檔窗口也同時變為只讀的。這個文檔窗口已經成為當前運行測試歷史的組成部分了。

最後，我們説明一下手工測試類型存在的不足之處(此處所説的不足之處，係指除了需要人工交互之外的其他不足之處)。如果某個測試需要在遠程計算機上運行，那麼手工測試是不能作為這個測試的組成部分的；此外，如果某個測試被配置為驗證一個團隊完成的某個構建的穩定性，那麼這類測試無法作為這個測試的組成部分來執行；最後，這類測試無法用命令行工具(即mstest.exe)來執行。之所以存在這些問題，其根本原因都是因為手工測試需要人工干預，而我們很難遠程執行手工測試，也就是説，這個功能要求執行測試的遠程計算機停止運行，並且在繼續執行之前提示用户採取行動。因為這會導致無法事先預料的測試暫停(因為測試人員可能會忘記測試中包括了手工測試)，而團隊也常常沒有時間來解決這些方面的問題，所以我們可以採用的唯一解決方案是：將手工測試步驟打印出來，帶到實驗室，然後在某台合適的計算機上運行手工測試。完成測試後，返回辦公室，在本地計算機上運行手工測試，然後根據測試過程中發現的情況，將測試結果標記為Passed或Failed。確實，這種方法不是最優方法，但是在產品開發時間的限制下，我們常常無法及時實現手工測試，所以我們也只能採用這個辦法。