手工測試就是由人去一個一個的輸入用例，然後觀察結果，和機器測試相對應，屬於比較原始但是必須的一個步驟。
基本介紹
- 中文名：手工測試
- 外文名：Manual testing
- 含義：人去一個一個的輸入用例
- 比重：比重一般在30%
介紹,包括項目,創建,屬性,執行,
介紹
設計用例有很多原則，但是最基礎的原則是覆蓋性，就是要覆蓋所有可能的種類（當然種類要自己區分）
例如if i〉0 then a=1 else a=0
當然還有枚舉覆蓋，路徑覆蓋等不同的覆蓋類型，還有就是要考慮到可能和不可能的類型，比如上例i=a i=“你”會怎么樣，那測試用例又要增加
包括項目
● 如果某項測試工作難以採用自動測試完成(甚至根本無法採用自動測試完成)，例如：在程式執行的關鍵時刻，我們需要從物理上斷開一個網路連線，其目的在於驗證程式處理錯誤條件的能力，此時我們就可以採用手工測試。
● 對於某些測試，如果我們採用自動測試，可能導致投資回報率(return on investment，ROI)過低。例如，如果我們需要驗證一個圖形用戶界面組件確實能夠套用於某個軟體產品中的某項功能的開發，而這項功能又將被其他功能替換。此時，假設使用手工測試方法只需要花費10秒時間，但是，如果使用自動測試，卻需要花費幾個小時甚至幾天的時間編寫測試，並且還要維護測試，那么在這種情況下，我們顯然應該使用手工測試來解決問題。
● 需要使用自動測試，但是時間不允許進行自動測試的場合。
● 需要使用自動測試，但是開發團隊當前技術水平尚不足以支持自動測試的場合。
手工測試一般是基於後面兩個原因：(1)時間資源不足；(2)技術水平不足。在這些情況下，手工測試能夠發揮重要的作用。利用手工測試，我們可以定義測試，還可以跟蹤測試，直到這些測試因為產品變更被廢棄為止。在許多開發團隊中，手工測試是以工作任務清單形式存在的，而且將來可以將這些內容進行自動化——除非這個團隊採用手工測試的原因是前面兩個因素，即：(1)自動化是不可能的；(2)測試自動化的投資回報率太低。
探討創建並運行一個手工測試的內部機制的過程中，我們必須記住創建手工測試的原因，和我們是如何創建手工測試的。
我們想定的場景非常簡單，實際上許多測試都可以歸結為一些簡單步驟的集合。在本例中，用戶需要驗證Microsoft Outlook 2007可以順利過渡到Disconnected(斷開)狀態下繼續工作，同時應用程式可以將這個情況向用戶報告，而且當連線斷開時，不會產生有害後果。在不會引起混淆的情況下，本章後面將這個場景稱為應用程式的收/發功能測試。
創建測試時，許多測試人員遇到的困難是他們無法定義一個完美的測試場景。我的建議是不要讓這個困難妨礙測試，也就是說一開始測試時，我們必須拋開一些次要因素，將來可以逐步完善測試。例如，在第一個場景中，我們可以在測試過程中執行其他一些工作，舉例來說，我們可以觀察當網路連線斷開時，應用程式需要用多長時間才能夠將此情況通知用戶。但是當我們進行手工測試時，一開始並不需要強調將某項功能的回響時間作為測試是否通過的標準。
編寫手工測試時，首先要描述測試目的，測試環境及其局限，以及執行測試時常犯錯誤，然後我們需要深入到測試場景之中。此時，我們必須詳細列出測試步驟。在收/發功能這個例子中，測試場景非常簡單，只有三個步驟：
(1) 運行應用程式。
(2) 啟動應用程式的傳送/接收功能。
(3) 將網路連線物理斷開。
上述步驟執行結束後，下面要描述測試的預期執行結果。在這個例子中，我們要區分程式當時是否與郵件伺服器連線，因為用戶界面能夠顯示程式狀態，因此我們根據圖形用戶界面來判斷程式狀態。此時用戶界面應該顯示Disconnected一詞。在我們最終創建的測試中，這個顯示反饋的行為應該作為測試模板中的組成部分。
雖然我們僅僅給出了一個簡單示例，但是只要將手工測試的其他方面考慮進來，我們就可以編寫出複雜的手工測試。編寫手工測試時，我們還可以考慮的其他方面包括：可訪問性(此時我們要確保即使用戶視力不佳，也能夠及時發現其測試工具提供的用戶界面所發生的變化)、可用性(在一個可控制的環境中，令用戶運行測試，測試目的在於檢驗以下情況：當用戶突然無法收發郵件時，用戶是否能夠馬上發現網路斷開)、安全性(其他應用程式是否能夠利用這個功能並造成不良後果？)，以及地理政治方面的因素(當把Disconnected一詞翻譯為其他語言時，是否會造成誤解或政治糾紛？)。
觀察測試如何隨時間流逝而發生演化也是一項重要工作。我們可以在測試中專門提供一個位置，在這個位置中我們可以將測試更新人員名單記錄下來。這樣當測試發生問題時，其他測試人員可以及時知道他們應該向誰諮詢。
我們已經基本了解了測試場景應該是個什麼樣子。下面我們使用手工測試類型創建一個測試。
創建
手工測試類型包括純文本格式和Microsoft Word格式，Microsoft Word格式可以支持豐富格式文本，並可以嵌入圖像和表格。創建一個新的手工測試時，我們可以選擇兩種格式之一，如圖1-1所示，這兩種格式分別是：
圖 1-1
● 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對話框(參見圖1-1)中選中Manual Test (text format)測試類型後，系統都會彈出一個測試模板(參見圖1-2)。
創建一個新的測試類型後，這個新創建的測試隨即處於打開狀態，我們可以對這個測試進行編輯。正如圖1-2所示，手工測試類型也是如此。現在，Visual Studio編輯器已經打開了一個純文本格式的手工測試，我們現在可以編輯這個手工測試了。
利用上述測試Microsoft Outlook 2007同步行為的測試示例(也就是當Microsoft Outlook 2007執行同步操作時，網路突然斷開，此時我們要對Outlook的行為進行測試)，圖1-3給出了一個完整的測試模板。
圖 1-2
圖 1-3
2. Microsoft Word格式如果我們在圖1-1所示的Add New Test 對話框中選擇了Manual Test (Word format)，那么系統將顯示一個與圖1-2類似的測試模板，唯一的區別就是我們可以使用不同的編輯工具——當前我們可以使用Microsoft Word(從圖1-4可以看到，我們當前使用了Microsoft Word 2003)完成手工測試的編輯工作。圖1-4說明，與純文本格式相比，使用Microsoft Word格式可以編輯更為豐富的內容，例如我們可以嵌入螢幕快照，還可以嵌入表格和格式化文本。
圖 1-4
如果我們需要對默認模板進行修改，那么我們可以在C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\ItemTemplatesCache\<language>\1033\ManualTestWordFormat.zip\目錄下找到這些模板。在這個目錄中，<language>表示Csharp、VisualBasic、VisualC或Test。如果我們重新進行設定，那么新的設定將覆蓋ItemTemplatesCache目錄下的所有內容，因此一個更好的方法是修改ItemTemplatesCache目錄下的ManualTestWordFormat.zip檔案。當然，如果採用了這種修改方式，那么我們必須針對每一種語言進行設定。
屬性
我們在View選單中選中Properties Window選單項，就可以看到Visual Studio Properties視窗。在Test View視窗或Test Manager視窗中單擊某個手工測試後，我們就可以在Properties視窗中看到該測試的屬性。具體情況如圖1-5所示。
圖 1-5
如果讀者當前尚未打開Test View視窗或Test Manager視窗，那么請讀者在View選單中選擇Properties Window選單項，就可以打開Test View視窗或Test Manager視窗。
我們可以將當前測試的任意一個屬性添加到Test View視窗或Test Manager視窗中，這樣，我們可以基於該屬性的屬性值對手工測試進行過濾或分組。
一個手工測試包括表1-1所示的屬性。
表 1-1
屬 性 | 可 編 輯 性 | 描 述 |
Project Area | 如果該屬性為VSTFS的組成部分，那么該屬性為可編輯的 | 如果某個團隊開發的項目連線到了Visual Studio Team Foundation Server，那么測試可以直接映射到TFS中為這個項目開闢的一個區域。這個屬性用於指定這個區域 |
Project Relative Path | 唯讀的 | 這個屬性包含了測試所屬項目的檔案名稱。此處的路徑是一條相對於本地磁碟上的解決方案位置的相對路徑 |
Solution | 唯讀的 | 這個屬性是包含了當前測試所屬測試項目的解決方案的名稱 |
Test Enabled | 可編輯的 | 當一次測試運行包括了某個測試時，我們可以利用這個屬性，在不修改這次測試運行的前提下將這個測試排除在這次測試運行之外。例如，我們可以關閉一個可能導致當前構建的應用程式崩潰的測試，直到該應用程式的新版本修正了導致程式崩潰的bug之後，我們再重新啟用這個測試，從而將這個測試重新納入這次測試運行中 |
Test Name | 唯讀的 | 這個屬性為測試名稱，一般是基於檔案名稱定義的 |
Test Storage | 唯讀的 | 在手工測試中，測試存儲與測試ID是相同的，也就是說，測試存儲就是這個測試駐留的實際路徑 |
Test Type | 唯讀的 | 這個屬性為測試的類型，在此，測試類型為手工測試。我們可以將當前測試的任意一個屬性列添加到Test View視窗或Test Manager視窗中，這樣我們可以根據屬性值對測試進行分組或過濾。所以利用這個屬性我們可以觀察所有的手工測試 |
Timeout | 唯讀的 | 這個屬性確定了測試的逾時值。手工測試類型不包括逾時的時限值，也就是說：對手工測試類型而言，逾時值為無窮大。對於其他測試類型，我們可以用逾時的時限值來規範測試執行時間。如果測試在規定的逾時時限內沒有正常運行結束，那么我們認為這個測試執行失效 |
如果讀者需要了解如何在連線到一個Visual Studio Team Foundation Server項目的情況下完成測試工作，請閱讀第9章的內容。
執行
執行測試時最常用的兩個視窗分別是Test Manager視窗(該視窗僅在VSTEST中可用)和Test View視窗(該視窗在VSTEST和VSTESD中均可用)。我們可以通過選擇Test選單中的Windows選單項打開Test View視窗。如果讀者創建了兩個手工測試，那么在打開Test View視窗後，在Test View視窗中，讀者可以看到兩個手工測試，這兩個手工測試都稱為ManualTest1。具體情況請參見圖1-6。
圖 1-6
用滑鼠右擊Test Name屬性列(也可以單擊Test View視窗中的任意一列屬性)，我們可以從下拉選單(也就是上下文選單)中選中Add/Remove Columns選單項。此時系統彈出Add/Remove Columns對話框(參見圖1-7)。這個對話框用一個列表顯示了所有的屬性，我們可以對這些屬性進行排序(我們只要單擊該列表的標題就可以完成排序操作)、過濾(需要輸入一個關鍵字，並選擇一個屬性列，針對該屬性列，利用這個關鍵字進行過濾)和分組(因為該視窗很小，所以可以單擊Test View視窗最右端的工具條上的overflow按鈕，然後選中對測試進行分組的屬性就可以完成分組操作)。
圖 1-7
為了解釋如何在Test View視窗中增加一列屬性，以及如何根據某個屬性對測試進行分組，下面我們用一些測試對此進行說明。首先我們在測試項目中添加一些測試，將Owner屬性顯示為一個屬性列，然後在Group By位置處，選擇測試類型(參見圖1-8)。
圖 1-8
我們在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工具條。
啟動執行手工測試之後，我們馬上可以看到一個信息提示，通知我們當前運行的測試包含了一個手工測試(參見圖1-9)。出現這個信息提示的原因是：當我們執行一組測試時，如果當前運行的測試包含了一個手工測試，那么運行這些測試的測試人員可以沒有意識到這種情況將會導致測試發生暫停。有的時候，測試人員啟動一個大型測試之後去吃午飯，然而，當他們吃完午飯後返回辦公室時卻發現，他們離開後大概一分鐘，測試就已經暫停下來等待手工干預，這種情況確實令人非常不快，常常使人充滿了挫折感。
圖 1-9
測試開始執行後，Visual Studio將讀取當前測試的運行配置信息(我們在第2章討論了運行配置信息)，從而可以確定需要複製那些檔案，是否需要插裝被測試程式來收集代碼覆蓋信息等內容。Visual Studio根據測試列表中的內容，一個接一個地執行測試，當遇到一個手工測試時，將顯示一條諸如“Manual Test ‘manualtest1’ is ready for execution”(手工測試manualtest1已準備好執行)之類的信息。此時，測試暫停並等待測試人員根據手工測試步驟一步步地完成手工測試過程，測試人員需要根據他們所觀察到的結果判斷該手工測試是否通過。在Visual Studio IDE中，手工測試顯示為一個標籤文檔(tabbed document)，與圖1-10中所顯示內容非常類似。
圖 1-10
這個標籤文檔包括四個部分的內容：
● Apply工具條按鈕——只有當測試人員單擊了該文檔中Select Result分組部分中的Pass or Fail選項按鈕後，這個按鈕才會成為活動的。
● Select Result分組——在這個分組中包括兩個選項按鈕，即Pass選項按鈕和Fail選項按鈕。利用這兩個選項按鈕，測試人員可以確定手工單步執行測試腳本的測試結果。
● Comments文本框——在這個文本框中輸入的信息可以保存為測試結果，如果測試發生失效，那么測試工程師可以在這個文本框中輸入更為詳細的失效信息。
如果讀者使用Microsoft Word編寫手工測試，那么當測試執行時，請讀者注意測試人員所看到的表格和嵌入圖片的顯示方式。純文本格式的測試版本可能會對相關內容進行大幅度簡化。
測試人員確定測試輸出結果後，單擊Apply按鈕，隨即可以看到如圖1-11所示的Test Results視窗，這個視窗顯示了測試輸出結果。單擊Apply按鈕後，用於為測試人員顯示手工測試腳本的標籤文檔視窗也同時變為唯讀的。這個文檔視窗已經成為當前運行測試歷史的組成部分了。
圖 1-11
最後，我們說明一下手工測試類型存在的不足之處(此處所說的不足之處，系指除了需要人工互動之外的其他不足之處)。如果某個測試需要在遠程計算機上運行，那么手工測試是不能作為這個測試的組成部分的；此外，如果某個測試被配置為驗證一個團隊完成的某個構建的穩定性，那么這類測試無法作為這個測試的組成部分來執行；最後，這類測試無法用命令行工具(即mstest.exe)來執行。之所以存在這些問題，其根本原因都是因為手工測試需要人工干預，而我們很難遠程執行手工測試，也就是說，這個功能要求執行測試的遠程計算機停止運行，並且在繼續執行之前提示用戶採取行動。因為這會導致無法事先預料的測試暫停(因為測試人員可能會忘記測試中包括了手工測試)，而團隊也常常沒有時間來解決這些方面的問題，所以我們可以採用的唯一解決方案是：將手工測試步驟列印出來，帶到實驗室，然後在某台合適的計算機上運行手工測試。完成測試後，返回辦公室，在本地計算機上運行手工測試，然後根據測試過程中發現的情況，將測試結果標記為Passed或Failed。確實，這種方法不是最優方法，但是在產品開發時間的限制下，我們常常無法及時實現手工測試，所以我們也只能採用這個辦法。
