高手過招，手中無需用劍，只要輕描淡寫地以口代手，三兩句話便高下立判，勝者勝得痛快，輸者也輸得瀟灑。然而，除了在武俠**之內，恐怕很難有地方讓你感受到這種「會當凌絕頂」的痛快。本文根據作者在測試
工作中的體會，提出了一種被稱為「測試用例預演」的方法，用模擬的測試用例執行發現程式中潛在的問題，這種方法究竟有何神奇呢?請見內文。 武俠**中的高手大抵有三個層次，第乙個級別是「靜若處子，動如脫兔，身負成名絕技」的高手，印象中這乙個級別的基本是殺手或是性情豪爽的江湖俠客，這種人一旦遇到，打殺的場面最為巨集偉，刀槍之聲不絕，各出奇招，直到一方倒地或是被制;第二個級別是「落葉飛花，片葉支花均可傷人」的高手，這個級別的高手相遇，少了巨集偉的場面，卻在看似不經意的凝重中展開殘酷的廝殺，勝負只在一念之間;第三個級別的高手寥寥無幾，多是成名已久、文武雙修的名宿，已至「手中無刀，心中無刀」的最高境界，這種高手若是過招，全不聞金戈之聲，全無殺伐之意，輕描淡寫的以口代手，三兩句話便高下立判，贏的贏得痛快，輸的輸得瀟灑，在武俠中看到此，常不免心潮澎湃，艷羨不已，巴不得自己也能有這個機會一嘗絕頂高手之間的這種至高默契。可惜身為開發或是測試工程師，又出生在這個真實的世界，恐怕實在是不太會有機會領會這種至高的境界。
所幸，我們雖不能飛進武俠**嘗試這種生活，卻能在我們的測試工作中體會到這種樂趣。真耶?假耶?且與我一起，**個究竟。
回到我們的題目「高手過招的樂趣 —— 測試用例預演」，這裡我要提出的是一種可以讓你體會到高手過招樂趣的方法：「測試用例預演」。且慢試圖在頭腦中搜尋你對這種方法的印象，因為這是我自創的名詞(申明：如果很不幸你通過其他途徑確實聽到或是見過這種描述，請一定告知本人，本人會慎重考慮，至少到目前為止，我還能有把握地說這是我首先命名和以正式文件描述的一種方法)。之所以把這種算不上十分複雜的方法寫下來，是因為本人在實際的工作中發現該方法確實能起到比較大的作用，而且更重要的是，那種高手過招的感覺，很希望能和更多有高手夢的朋友能夠感受得到。
測試用例預演是一種非正式的測試用例執行方法，概括說來，這種方法是無需通過測試用例的真正執行(靜態或是動態執行)，而只需要開發人員和測試人員之間的口頭交流，就能發現被測系統中存在的問題。設想一下，無需動手(測試執行)，通過以口代手(開發和測試人員之間的口頭交流)，就能實現我們的目標(發現缺陷)，這不是高手過招是什麼?
測試用例預演的一般步驟是：
測試工程師與開發工程師以某種方式坐在一起，進入交流狀態，這個過程中需要盡可能避免干擾，比較好的時機是坐在一起進餐的時候;
測試工程師根據測試用例進行提問，甚至可以臨時擴充套件測試用例，但要注意三點：
1). 不要偏離測試用例太遠，以免偏離實際的業務;
2).可以考慮一些在測試用例中沒有明確寫明的異常情況處理;
3).提問的方式是「如果我這麼操作，你的系統會如何反應?」;
開發工程師根據測試工程師的問題，做出應答，對每個問題都只需要回答系統的響應即可，不需要描述具體的實現方法;
測試工程師仔細聆聽開發工程師的回答，需要對開發工程師的答覆敏銳反應，不放過任何乙個開發人員的遲疑，對拿不準的問題應該記錄並需要馬上驗證;
雙方繼續預演直到預期的預演時間結束或是有一方感到疲倦;
記錄預演過程中發現的問題到缺陷跟蹤庫。
當然，要說明的是，參與交流的開發和測試工程師不是比武雙方，真正的敵人只有乙個：系統的缺陷，這點務必要牢記，以免弄錯了對手，傷了和氣。
測試用例預演不是一種複雜的方法，但根據我的經驗，要想在實際工作中應用這種方法並取得較好的效果，必須了解這種方法的適用範圍，遵循一定的使用方法，並需要注意一定的技巧。這裡我以faq的方式提供秘笈一部，各位請留意：
q：測試用例預演可以取代測試執行嗎?
a：這個問題是我捏造出來的，我想大概不會有人真的這麼認為：)，不過在這個問題的回答中，我希望能盡可能準確地描述測試用例預演方法的適用範圍：如前面所提到的，測試用例預演是一種「虛擬」的測試用例執行方法，因為主要是通過口頭互動的形式，也就限制了該方法適用的深度，一般來說，針對業務邏輯的較為直觀的用例可以採用這樣的方法，尤其是那些涉及大量使用者複雜互動的用例，採用這種方法非常有效，測試工程師模擬使用者或是裝置提出各種可能的正常異常情況，很容易發現程式處理中的漏洞。但是，對於那些需要涉及大量地層處理的用例，測試工程師一般不太可能對其機制了解得十分清晰，因此採用這種方式也很難發現問題。
q：測試用例預演可以在哪些場合下使用?
a：測試用例預演的應用場合沒有特殊要求，但至少要保證是乙個適合雙人溝通的場合，沒有過多的被打擾，雙方都處在能積極思考的狀態，這樣就可以了。根據我的經驗，一起就餐、雙方暫時沒有明確的工作內容，或是在對設計進行非正式評審的時候是乙個比較好的時機，但還要充分考慮雙方的喜好，譬如，有人不喜歡在吃飯的時候展開討論。總之，乙個適合雙人溝通的場合是最低要求。
q：測試用例預演方法可以用在其他地方嗎?
a：中子炮剛發明的時候，科學家們狂熱地將中子炮對準任何可以找到的東西;按照這種趨勢，測試用例預演方法也必須要考慮是否可以應用在其他地方：)實際上，預演這種方法在評審或是思維遊戲的過程中一直都是被廣泛應用的，測試用例預演只不過將預演這種方法用到了以往需要真正執行的領域中，除了在測試執行環節，設計評審過程中我們也可以採用這種方法針對設計進行審查，關鍵在於提問的技巧：「如果我們這麼做，你的設計將會怎樣反應?」。
q：好像我用測試用例預演方法很難達到預期的目標?
a：測試用例預演方法並非不需要前提條件，至少要保證以下條件才能使測試用例預演發揮較大的作用：
開發工程師具有良好的配合意識;
測試工程師對產品具有良好的熟悉程度;
提問者的提問必須從「如果我這樣做，程式會怎樣反應」開始;
參與預演的開發工程師對用於預演的用例涉及的模組要非常熟悉;
其中，測試工程師對產品具有良好的熟悉程度是非常必要的，測試用例預演的主要物件是針對業務邏輯的用例，這就要求測試工程師熟悉產品，熟悉業務。所謂「棋逢對手」，至少要能和開發工程師是乙個級別上的。另外，參與預演的開發工程師必須對用於預演的用例涉及的模組很熟悉，如果參與預演的開發工程師是模組的開發者自然沒有問題，如果不是，就要求開發工程師必須能夠準確了解模組的行為和實現。
q：測試用例預演發現的問題需要記入缺陷庫嗎?
a：答案是肯定的，測試用例預演是一種「虛擬」的測試執行，預演過程中發現的問題同樣要被記錄、跟蹤。當然，為了標識測試用例的發現階段，可以專門在缺陷管理系統中增設乙個「預演」階段，統計預演在缺陷發現方面提供的效果。
q：如果開發人員不配合，怎麼辦?
a：這個問題……我只能說具體問題具體分析了。關鍵是弄清楚開發人員為什麼不配合，可能是開發人員個性羞澀，不喜歡這樣面對面的交流方式;也可能是開發人員覺得這種方式浪費時間;又或者是開發人員對測試人員抱有不信任的態度。不管怎樣，發揮你的個人所長，讓開發人員放下顧慮和成見，認識到這種做法能給他和專案帶來的好處，自然可以解決這個問題。
q：還有哪些在測試用例預演過程中應該主要的問題?
a：當然還有一些需要注意的問題，溝通的技巧、對對方反饋的及時分析等等，這些都可以在實際運用測試用例預演方法的過程中逐漸體會。我總結的幾點需要注意的問題包括：
對每乙個開發人員的猶豫都不能放過，乙個猶豫很可能就是乙個缺陷隱藏的地方;
如果可能，最好能和開發人員一起，確定那些不確定的問題，以防開發人員一時馬虎放過了本來存在的問題;
預演的方式不適合在正式評審會議上應用，因為預演主要是兩個人之間的協同思考，在正式評審會議上容易浪費其他人的時間;
預演時要注意記錄，頭腦風暴產生的火花如果不及時記錄的話，很可能會在短時間後被遺忘。
什麼是介面測試？用例設計
介面測試是測試系統元件間介面的一種測試，主要用於測試系統與外部其他系統之間的介面，以及系統內部各個子模組之間的介面。測試的重點是要檢查介面引數傳遞的正確性，介面功能實現的正確性，輸出結果的正確性，以及對各種異常情況的容錯處理的完整性和合理性。針對軟體介面的分類一般有如下幾種情況 2 同一系統內部上層...
什麼樣的測試用例是好的測試用例
1 用例覆蓋程度毫無疑問，這一點應該是最重要的，無需多說，覆蓋率最大化是一套測試用例的最重要評價標準，如果漏測就杯具了。2 用例是否已經達到工作量最小化 在滿足用例覆蓋程度最大化的前提下，應該盡量減小執行用例所需要的工作量。這些方面的方法有不少，如條件覆蓋，分支覆蓋，正交覆蓋等方法。面對不同的測試物...
測試眉形的有哪個軟體 到底什麼是軟體測試？
廣義的軟體測試定義是 貫穿在整個開發各階段的複查 評估與檢驗活動，這遠遠超出了程式測試的範圍，可以統稱為確認 驗證與測試活動 v，v t validation,verification and testing 而狹義的測試定義為 軟體測試是為了發現錯誤而執行程式的過程。軟體測試是根據軟體開發各階段的...