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