探勘軟體測試
James 惠特克是合作夥伴開發管理堆疊， Microsoft。 這是一個前工程主任在對測試色彩、對應和 Google Web 負責應用程式之 Google。 James 是其中一個測試世界的影響最譽的名稱和撰寫在軟體測試的數個銷售量最高書籍》。 他也裝載通用。 MSDN 的部落格
2012 年 7 月
這個主題是從這本書 探勘測試軟體的秘訣和訣竅、導覽和技術套用至手動測試設計 截取的區段。
套用至
應用程式開發週期管理， Visual Studio， TFS
在執行測試時，測試人員可能會與應用程式互動以任何方式他們想要和使用應用程式提供回應的資訊，變更路由和通常探索應用程式的功能，而不會避免。 它可能特別似乎到陣列，不過，在一個熟訓練和複雜的探勘測試人員來，這種技術可以證明強大。 提倡者情形就說，探勘測試在尋找 Bug 允許完整功能個人電腦會利用和驗證功能不應該想的限制。
對探勘測試的缺點是測試人員可能會浪費漫步在應用程式有很多時間尋找作業對測試並嘗試尋找 Bug。 缺少準備、結構和指引會造成許多非產生屬性的時數和多次重新測試相同的功能。 可輕鬆地看到完全臨機操作測試不顯然是最好的方式繼續進行測試。 了解輸入、軟體環境和其他作業可以變更測試進行期間的軟體測試人員會比較隨精良的探索其與目的和目的應用程式。 這項知識有助於這些測試更好、更聰明及最大化其發現嚴重的設計和實作缺點的機會。
探勘測試目標
To gain an understanding of how an application works, what its interface looks like, and what functionality it implements: 這類目標由測試人員通常會使用新的專案或要識別測試進入點的人，識別特定測試要求和寫入測試計劃。 因為它們探索應用程式了解您的測試需求的深度和尋找新的未總測試的功能，這也是複雜的測試人員使用的目標。
To force the software to exhibit its capabilities: 這個想法是讓軟體工作工作和存取透過其速度將其困難。 這也可能不會發現 Bug，不過，它一定會提供辨識項軟體執行設計的函式，且符合其需求。
探索應用程式的邊緣和點擊潛在損害容易受到危害的地方To find bugs: 是探勘測試特製化。 目標是目的，而不是無目的，探索識別未經測試和以往多 Bug 的功能。 探勘測試人員不應該跨越 Bug 啟動時，應該考慮它們與目的和目的。
–探勘測試計劃，您測試
軟體測試由變化的多載會從輸入和程式碼路徑指出，儲存資料和作業環境的複雜性。 的，一選取任何測試之前解決此變化藉由撰寫測試計劃或由授權計劃和測試交錯一種探勘方法，它是不可能的工作。 不論最後進行測試，它完全太複雜而無法完全地執行。
不過，探勘技術有好處它們鼓勵測試人員計劃，以便測試，並在測試期間所收集到的資訊會影響實際模式執行測試。 這是一個重要優點計劃第一個方法。 嘗試的 Imagine 在季節之前預測 super 盃的優先勝者或英文、GRANT 足球 super 關聯的開頭。 這很難進行，然後參閱前小組如何使用，以及如何處理競爭，因此，主要選取手動是否能避免之害。 傳入的資訊，當季節展開保持索引鍵對預測與任意數目的精確度的結果。 同樣的軟體測試，因此，探勘測試成功嘗試計劃，測試並重新配置在所有的完全了解過去以及測試期間，它產生的軟體方式的目前資訊執行和線索前置的小持續性的加入擁有者抱此。
Agile 小組的探勘測試。
使用敏捷方法，探勘測試特別適合現今 Web 應用程式開發。 開發週期有 short，保留正式指令碼常值和維護一點時間。 功能快速不斷進展，因此，最小化相依成品 (如先前開發的測試案例) 是適當的屬性。 如果測試案例具有無關成為屬性的不錯的可能原因，先將它? 比實際執行測試您不是設定為花更多時間維護的測試案例?
(以為探勘測試的敏捷式工具的範例在 Visual Studio 和 TFS，請參閱 使用 Microsoft Test Manager 執行探勘測試、 使用探勘測試視窗，測試在裝置上執行的 Windows 市集應用程式和 在 Microsoft Test Manager 中執行測試)。
探勘測試可能同時存在與計劃的指令化測試
檢視探勘測試當做嚴格的替代架構指令碼的手動測試是不必要的。 實際上，兩者都相當恰好共存。 有正式指令碼可以提供結構給架構總管執行，因此，探勘方法可以將變化的項目可以放大到其有效率的指令碼。 我找到合併兩個技術的最佳方法是開始正式指令碼和使用探勘技術插入變化輸入。 如此一來，單一指令碼可能結束轉譯成任意數目的實際探勘測試案例。
傳統指令碼的測試通常與使用者劇本起點或文件的端對端案例我們希望我們最後的使用者執行。 這些案例可能來自使用者，從應用程式的舊版的資料，、和做為指令碼測試軟體。 探勘測試的加入項目至傳統案例測試的擴充指令碼範圍插入變化、調查和選擇性使用者路徑。
情節是以探索
以情節為基礎的 Explorer 中案例簡單案例測試和更精確地不會模擬真實的使用者，從主要案例通常迷路:畢竟產品讓許多可能的變化。 我們不應該僅預期會使用，我們應該測試才會運作。
因為虛擬的 Explorer 使用對應到原野或其他不熟悉的地形，引導自己在以情節為基礎的探勘測試後的概念是使用現有的情節。 案例，例如對應，就是要在測試期間，的一般方針輸入選取，，和程式碼路徑周遊，不過，它們不是絕對路徑。 對應可能會描述您的目的位置，但提供多種方式來加入其中。 同樣地，，當執行情節時，提供這個探勘測試人員變更執行路徑甚至鼓勵考慮各種可能的路徑。 實際上，這是探勘測試這個表單的實際用途:測試案例會描述的功能，將許多變化盡可能。 我們的「對應」不是用來識別捷徑，它要尋找 許多 路由。 對多我們可以測試，好;這會產生較多確定軟體強健地將執行案例，以便在我們的期望可以和偏離使用者的手中時。
一般而言，一個有用的案例將執行下列一或多項動作:
將使用者劇本
描述一個要求
示範功能的運作方式
示範一個整合式案例
說明安裝程式和安裝
描述可能發生錯誤的注意事項和
探勘測試人員應投入工作確保收集許多案例盡可能從這些分類。 就我們的工作遵循情節和插入變化，我們需要的大小。 是如何選取插入使這項工作探勘基本上，而且是主體我們將向下的變化。
(如需使用範例使用 Agile 工具的探勘測試在 Visual Studio 和 TFS，請參閱 如何：在 Microsoft Test Manager 中啟動探勘測試工作階段)。
探勘測試導覽
假設您瀏覽像 London，英文的大型城市，第一次的。 它是新的人的大型，忙碌， Scrum 的位元，會看見許多事和。 的，，如 London 必須提供，即使是最豐富，會有困難時間參閱一切的大部分時間不受限制的周遊人城市。 相同的可嘗試將隨精良的測試人員探索複雜軟體;全世界的所有支援不會保證完整性。
在周遊作業受益於結構和可用的混合，和，因此執行探勘測試。 有足夠的個別測試的可用樣式將協助我們將結構傳遞給我們的 Explorer 執行個體並將我們的應用程式取得我們更快速、的許多導覽的比喻。 許多這些導覽放入較大的測試策略，而且甚至結合會正確地判斷的傳統情節的測試此導覽如何組織。
如需測試計劃的任何討論需要從軟體的分解開始輸入是更多可管理的較小的部分。 但是，測試功能可能獨立阻止探索介面的 Bug，只有在功能彼此互動時。 幸運的是，在周遊比喻保存沒有這種分解。 相反地，建議根據 目的 解析而不是在應用程式的所有繼承結構應用程式中。 像接近她的假期以目的盡可能看相同簡短時間盡可能周遊的人，因此，這個測試人員也會組織她導覽。 一個實際的人將選取瀏覽的地標看和網站的混合，，且測試人員也會選擇混合搭配軟體功能以 目的執行特定的動作。 這個通常需要使用方式和函式會將任意數目的應用程式功能都不會是，如果我們會在一個嚴格功能測試模型下。
方針導覽
周遊的人員指南識別最佳在程式庫，最佳的交易和上方吸引力，，而不需要輸入許多細節或不勝負荷的人與許多選項。 探勘測試的大約成品是使用者手冊，它是否列印或實作為線上說明 (，但通常稱為此這次 F1 導覽 表示通往大部分說明系統) 的情況下。 對於此導覽，我們可以永遠不會偏離遵循用戶手冊的建議像機警告的其中，請從它的用途。
貨幣導覽
垂涎周遊人的每個位置都必須將其一些充分的理由可以來源。 對於數字會加斯，它是遊戲平台娛樂位置和區域，因此，為埃及它是度數為單位)。 對於探勘測試人員發現貨幣功能產生直接銷售人員。 銷售協同花費給應用程式的示範很多時間並不是預期的資訊來源 貨幣導覽的。 透過示範執行導覽，完全執行並找出問題。 當產品代碼為 Bug 修正、新功能加以修改，可能是示範中斷，您不僅找到高的 Bug，不過，您將相當某一嚴重的困窘儲存您的銷售人員。
在標記導覽
為長大在肯塔基的欄位、草甸和樹系的男孩，您已經學會如何檢視我的舊版同層級使用指南針。 流程很簡單。 使用指南針找出地標記 (樹狀結構、岩石，峭壁面，依此類推) 要移至的方向，嘗試移至該地標記，然後尋找下一個地標記，依此類推。 只要地標記都位在相同的方向，您可以透過密集的肯塔基樹系修補檔取得。
探勘測試人員的 地標記導覽 類似我們將選取地標記並將軟體執行類似的跳躍我們傳遞的工作。 選取一組地標記，決定它們的順序，然後探索減去地標至本機上，直到您瀏覽過所有在清單中。 記錄地標您使用了和建立地標涵蓋對應追蹤小組的進度。
alpha 導覽
我使用是本指南是一個紳士在他的五十 + 年代中要求在 out 在 London 記得所有其存留期倫敦之 Safari 導覽的。 一個周遊人剛好是平台學習的英文版記錄並經常存取這個方針的拼圖學生者。 它們並不是反映，不過，它們是好奇的，因此，該合併使用它們的了解會結束是危險組合…至少對這個方針。 當套用至探勘測試，此導覽負責 存取軟體拼圖方法。 我們如何使軟體相同工作工作盡可能? 哪些功能將會縮放至限制? 哪些項目，以及資料是否會使其執行流程? 哪些項目可能唬弄它錯誤檢查常式? 將基礎哪些輸入和內部資料其功能產生任何特定輸出?
已通過聯邦快遞公司導覽
已通過聯邦快遞公司在封裝交付世界的圖示。 它們會封裝，並在各種發佈中心周圍移動它們，並將要求傳送至其最終目的地。 對於此導覽，而不是將該行星的封裝通過聯邦快遞公司系統，移動到軟體的帳戶資料。 在此導覽時，測試人員必須將這些資料。 嘗試識別儲存的輸入，並在軟體周圍採用它們。 例如，在中，當地址輸入至購物網站時，在何處取得它顯示? 哪些功能使用它? 如果會使用做為帳單地址，請確定您功能的練習。 如果它做為傳輸位址，請確定您功能的用法。 如果可以更新，請更新它。 它是否印出或清除或處理? 嘗試尋找連續資料的每個功能，如此一來，正聯邦快遞公司管理其封裝，您可以在資料的生命週期的每個階段介入。
記憶體回收行程的導覽
收集面板框方塊記憶體的人通常知道甚至鄰域優於居民和警察，因為它們的街道地址的街道，由房子方向，且熟悉在路徑中的每個碰撞。 不過，，因為它們出現，它們不是一個非常長暫停。 如需軟體，這與條件不紊的目前地檢查。 我們可以將加入至目前地檢查我們被畫面移至螢幕，對話方塊是由對話方塊的介面 (趨勢，例如記憶體回收行程，行) 和不停止詳細測試，不過，檢查資訊清單的項目 (可能像 super 名模導覽)。 我們也可以使用此導覽由功能、模組的模組，或有我們的特定應用程式有意義的其他地標移至功能。
設計不良鄰域導覽
每個城市值得瀏覽不正確的區域和區域的人是會決定的。 軟體也有程式碼鄰域部分由 Bug 填入的錯誤。 清楚地，我們事先不知道功能可能表示錯誤的區域。 但是，找到 Bug 並報告，我們連接與 Bug 計數的某些功能，並且可以追蹤 Bug 在我們的產品的地方發生。 由於 Bug 傾向於彙總，重新審視產品的多 Bug 的部分是導覽所應該採取任何動作。 的，後，程式碼的多 Bug 的部分識別為，建議您透過周圍的功能取得記憶體回收行程的導覽驗證修正沒有引入任何新的 Bug。
博物程式庫導覽
顯示上古的博物程式庫是周遊人我的最愛。 在程式碼基底中的上古需要相同類型的從測試人員的注意力。 在這種情況下，軟體的上古是舊版程式碼。 執行修正或放入新環境的舊版程式碼檔經常會容易失敗。 通常缺乏原始開發人員長度和文件，舊版程式碼難以修改，難以檢閱，且逃避開發人員單元測試網路 (通常是誰寫入這類只測試新的程式碼)。 在此導覽時，測試人員應該識別舊的程式碼，並可執行檔成品並確定這些接收測試注意一個公平共用。
卑劣的導覽
在許多人的閃爍，一次佳導覽是您瀏覽常見的一個。 這些相反導覽是您瀏覽位沒有人可以移至另一個。 用探勘測試來說，這是最不吸引人的使用者顯示不大可能的功能會使用的和章節。 如果您的組織追蹤以使用功能，此導覽會引導您測試這個在清單的底部。 如果您的組織追蹤程式碼涵蓋範圍，此導覽祈求您發現無法測試所涵蓋的程式碼。
完整 Nighter 導覽
也稱為 蒐集成員棍棒狀態一條導覽，這一個是呆外部晚而點擊夜間一定會的那些協同。 此索引鍵 整夜。 在這個 完整 Nighter 導覽中的 探勘測試工具可繼續其應用程式執行，而不將它關閉。 它們會開啟檔案並不會關閉它們。 通常，它們也不想要儲存以便避免重設可能發生的效果的所有可能會節省時間。 連接至遠端資源而不中斷。 然後，當這些資源在常數使用時，可能會包括執行測試使用其他導覽繼續軟體工作和移動的資料。 如果它們這麼做太久，可能會發現其他測試人員將不會發現的 Bug，因為軟體拒絕該 Clean 重設時，會重新啟動時。
此名模導覽
對於此導覽，我想要在表面上視為。 使用控制項，不要超過綠色淺範圍。 此導覽不是函式或材質;它與外觀和第一次列印。 在 此名模導覽時，焦點不在功能或虛擬的互動。 它只在介面。 取得此導覽並檢視介面元素。 它們是否看起來好? 它們是否正確呈現，因此，效能是好? 當您認可變更， GUI 是否適當地重新整理? 它是否會正確地或沒有在螢幕上不悅項目的成品嗎? 如果軟體中使用色彩表示特定意義，這會持續進行? 與您預期其按鈕和控制項 GUI 面板是否為內部一致的? 介面違反任何慣例或標準?
結束日期會發出家用的人導覽
一律會在就不參與的群組導覽中的一個。 這在有其被交叉的雙 ARM 後面的代表。 他乏味，不積極，並正確地進行奇數蹟他為何首先預期支付此導覽。 指導土豆導覽 表示認可為指向實際工作越好。 這表示接受所有預設值 (應用程式預先填入的值)，將輸入欄位空白，填入做為一點表單資料盡可能，絕不會按一下廣告，呼叫將螢幕沒有按一下任何按鈕或輸入任何資料，依此類推。 如果有去的任何在應用程式的一種方式或另一個，指導土豆永遠上最省力的路徑。
強制屬性的導覽
OCD 測試人員多次將輸入相同的項目。 它們會多次執行相同的動作。 它們會重複，再做，複製，貼上，借用，然後執行部分的所有。 主要，遊戲的名稱重複。 指令在購物網站的項目然後重新排列它檢查多購買價格是否套用。 輸入在螢幕的一些資料，然後立即傳回重新輸入它。 這些是開發人員通常不是程式設計錯誤引數為的動作。 它們可以下跨重大浩劫。
開發人員通常考慮進行特定順序和使用與目的使用者軟體。 但是，使用者輸入錯誤，因此必須回溯，因此，所以通常不了解特定路徑開發人員可以在電腦頭中其，，以及採用自己。 這可能會導致開發人員小心地放置的使用方式計劃快速步入歧途。
測試是複雜的，不過，對探勘技術的有效使用方式有助於複雜而造成高品質軟體所產生的轉換馴。