針對此條，對于LEADER而言，最大的難處在于時間風險的估算。最好的解決方式是和開發(fā)人員開會，共同探討模塊的復(fù)雜性和測試時間。一般，開發(fā)，測試，修復(fù)，再測試的周期中，開發(fā)和測試的時間是1：2左右。甚至更多。

　　對于測試用例的設(shè)計人員而言，最大的難處并不在于新功能本身，而是如何設(shè)計覆蓋路徑，新舊版本之間的問題將非常嚴重。怎樣設(shè)計組合用例，將是測試的重中之重。

　 　活生生的例子： 我們的測試用例中沒有設(shè)計到橫向子模塊的兼容性測試，因為舊版本沒有該問題，而新版本也僅僅是調(diào)用這個模塊。結(jié)果，在冒煙測試中，就發(fā)現(xiàn)，這個被調(diào)用的公 用模塊，在某一個相對特殊的子模塊中，會發(fā)生菜單項無效的問題。隨后再想到要設(shè)計橫向模塊的兼容性測試，并和舊版本做比較，浪費了很多時間。

　　2、一定要和舊版本一起，做至少一輪的隨機測試

　 　尤其是涉及到自定義的數(shù)據(jù)保存功能的情況下，用新版本的程序讀取舊版本保存的數(shù)據(jù)看看。接口之間的古怪問題，一定會讓你頗有成就感。另外，去有規(guī)律的做 一些古怪的隨機測試，比如，程序中產(chǎn)生報表或者示例圖之后，最小化窗口，再還原看看。很有可能，圖片和數(shù)據(jù)就變了，或者消失，或者殘缺了。這種怪事就在我 的測試中實際發(fā)生了。因此，這一輪的隨機測試一定要做，思路越古怪越好。

　　3、不要嫌重復(fù)勞動麻煩

　　親身經(jīng)歷了令人沮喪的事情。在某3天，我不停地測試一個功能，單元測試證 明代碼和算法沒有錯誤，我也看過，的確不可能出錯。前臺依賴這個算法而顯示的數(shù)據(jù)上萬。不過還是出于負責而一條一條的檢查，一直沒有出現(xiàn)問題。最終，想放 棄的時候，發(fā)現(xiàn)，這將近2萬條數(shù)據(jù)，最后的10條果然出現(xiàn)了問題。你說妖怪不？早知道就應(yīng)該從尾巴開始測試。哎。所以，不能放棄，知道不，測試就是要負責 的。

　　4、關(guān)于不可重現(xiàn)的BUG

　　唯一能夠告訴新手的就是，你每做一個動作，都必須保持腦子清晰。當你發(fā)現(xiàn)某些一定是不可重現(xiàn)BUG時（比如內(nèi)存溢出，花屏等），別著急關(guān)閉你的屏幕，直接叫開發(fā)過來看，或者打開任務(wù)管理器，并截取圖片保存。因為這是你的業(yè)績。

　　第一步：畫出因果圖：

　　第二步：從因果圖導(dǎo)出判定表：

　　第三步：從判定表導(dǎo)出測試用例：

　　1、測試用例的代表性：能夠代表并覆蓋各種合理的和不合理、合法的和非法的、邊界的和越界的、以及極限的輸入數(shù)據(jù)、操作和環(huán)境設(shè)置等。

　　2、測試結(jié)果的可判定性：即測試執(zhí)行結(jié)果的正確性是可判定的，每一個測試用例都應(yīng)有相應(yīng)的期望結(jié)果。

　　3、測試結(jié)果的可再現(xiàn)性：即對同樣的測試用例，系統(tǒng)的執(zhí)行結(jié)果應(yīng)當是  `相同的。

　　二、測試用例設(shè)計方法原則（只對常用的兩種舉例）

　　比如：對邊界值設(shè)計測試用例，應(yīng)遵循以下幾條原則：

　　1、如果輸入條件規(guī)定了值的范圍，則應(yīng)取剛達到這個范圍的邊界的值，以及剛剛超越這個范圍邊界的值作為測試輸入數(shù)據(jù)。

　　2、如果輸入條件規(guī)定了值的個數(shù)，則用最大個數(shù)、最小個數(shù)、比最小個數(shù)少一、比最大個數(shù)多一的數(shù)作為測試數(shù)據(jù)。

　　3、根據(jù)規(guī)格說明的每個輸出條件，使用前面的原則1。

　　4、根據(jù)規(guī)格說明的每個輸出條件，應(yīng)用前面的原則2。

　　5、如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合，則應(yīng)選取集合的第一個元素和最后一個元素作為測試用例。

　　6、如果程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu)，則應(yīng)當選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界上的值作為測試用例。

　　比如：等價類設(shè)計測試用例的原則

　　1、在輸入條件規(guī)定了取值范圍或值的個數(shù)的情況下，則可以確立一個有效等價類和兩個無效等價類。

　　2、在輸入條件規(guī)定了輸入值的集合或者規(guī)定了“必須如何”的條件的情況下，可以確立一個有效等價類和一個無效等價類。

　　3、在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等價類。

　　4、在規(guī)定了輸入數(shù)據(jù)的一組值（假定n個），并且程序要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。

　　5、在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下，可確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。

　　6、在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下，則應(yīng)再將該等價類進一步地劃分為更小的等價類。

　　三、測試用例必要元素描述

　　測試用例編號：用來唯一標識測試用例的編號，由測試組根據(jù)具體情況統(tǒng)一管理。

　　測試用例級別：用來衡量測試用例的重要性，測試組根據(jù)具體情況制定統(tǒng)一標準。

　　測試需求或者測試需求編號（其實就是測試名稱 盡量簡單易懂）：描述測試的目的是什么。

　　前置條件：運行測試用例必須的條件

　　測試用列的輸入：簡單的講就是用來測試的數(shù)據(jù)

　　操作：就是在輸入數(shù)據(jù)之后用戶的操作，將會影響到測試的輸出

　　輸出：相應(yīng)的期望結(jié)果。

　　用于黑盒的測試用例

　　說明：根據(jù)情況可以將輸入正確的用戶名字和密碼；輸入錯誤的用戶名字和密碼進行具體的拆分；輸入字母數(shù)字為組合的用戶名，字母符號為組合的密碼或者直接給出具體的值。一般寫到上面的程度就可以了，能夠給測試起到很好的指導(dǎo)作用。

　　用于白盒的測試用例

　　說明：一般要求函數(shù)有返回數(shù)值，如果沒有就要根據(jù)設(shè)計說明書來判斷是否實現(xiàn)設(shè)計說明書上提出的功能。

　　總結(jié)：目前我們用到的測試用例只有這兩種，如果其中某一項沒有就不必寫出，原則上都要寫出測試用例再做測試，而且要評審測試用例是否完整，否則所測試的需求很有可能是得不到充分測試的。用戶可以根據(jù)實際情況選擇測試用例模板。

　　一、用正交表設(shè)計測試用例的步驟

　　（1） 有哪些因素（變量）

　　（2） 每個因素有哪幾個水平（變量的取值）

　　（3） 選擇一個合適的正交表

　　（4） 把變量的值映射到表中

　　（5） 把每一行的各因素水平的組合做為一個測試用例

　　（6） 加上你認為可疑且沒有在表中出現(xiàn)的組合

　　二、如何選擇正交表

　　● 考慮因素（變量）的個數(shù)

　　● 考慮因素水平（變量的取值）的個數(shù)

　　● 考慮正交表的行數(shù)

　　● 取行數(shù)最少的一個

　　三、設(shè)計測試用例時的三種情況

　　（1）因素數(shù)（變量）、水平數(shù)（變量值）相符

　　（2）因素數(shù)不相同

　　（3）水平數(shù)不相同

　　四、我們來看看第一種情況：

　　（1）因素數(shù)與水平數(shù)剛好符合正交表

　　我們舉個例子：

　　這是個人信息查詢系統(tǒng)中的一個窗口。我們可以看到要測試的控件有3個：姓名、身份證號碼、手機號碼，也就是要考慮的因素有三個；而每個因素里的狀態(tài)有兩個：填與不填。

　　選擇正交表時分析一下：

　　1、表中的因素數(shù)>=3；

　　2、表中至少有3個因素數(shù)的水平數(shù)>=2；

　　3、行數(shù)取最少的一個。

　　從正交表公式中開始查找，結(jié)果為：

　　L4(23)

　　變量映射：

這個可以直接查正交表，會發(fā)現(xiàn)L25(5^6)這個正交表，它表示有25次試驗數(shù)即測試用例個數(shù)，5表示水平數(shù)，6表示因數(shù)。如下，有3個因數(shù)，它們都有5個水平數(shù)。 A:a1,a2,a3,a4,a5 B:b1,b2,b3,b4,b5 C:c1,c2,c3,c4,c5 它們對應(yīng)的正交表為： 000000 012341 024132 031423 043214 104324 111110 123401 130242 142033 203143 210434 映射成測試用例為： A   B   C    a1 b1 c1  a1 b2 c3  a1 b3 c5  a1 b4 c2  a1 b5 c4  a2 b1 c5  a2 b2 c2  a2 b3 c4  a2 b4 c1  a2 b5 c3  a3 b1 c4  a3 b2 c1  a3 b3 c3  a3 b4 c5  a3 b5 c2  a4 b1 c3  a4 b2 c5  a4 b3 c2  a4 b4 c4  a4 b5 c1  a5 b1 c2  a5 b2 c4  a5 b3 c1  a5 b4 c3  a5 b5 c5  你可以再往上下一些工具，有助你生產(chǎn)測試用例。 

　　新入職公司，感覺測試部各位同事抒寫的用例都不太標準。也許是出來久的緣故，很少去總結(jié)用例之間的關(guān)系。比如邊界值分析法、等價類分析法、因果圖分析法等等，這些本該對我們測試用例做指導(dǎo)工作的 方法。在實際測試中往往沒有那么多時間進行歸納與分析。由此，本人借51這個黃金時間對之前在公司實習一個星期后，對表單測試用例、上傳組建測試用例等在 Web系統(tǒng)測試中比較集中的用例進行了深入的分析和總結(jié)，由此拿出分析結(jié)果與各位分享一下。如有什么錯誤或不足之處希望各位能回復(fù)指出，非常感謝您的參 與！

　　使用FreeMind8.0總結(jié)了以下的內(nèi)容，希望能結(jié)合實際項目使用各種覆蓋方法對項目中的測試用例進行一次完全的歸納分析。

　　表單測試用例篇

　　（1）輸入系統(tǒng)支持的數(shù)據(jù)格式測試用例分析

　　（2）輸入非系統(tǒng)支持的數(shù)據(jù)格式測試用例分析

　　（3）路徑覆蓋測試分析

　　以下一個TextArea域為例子，使用Excell計算路徑覆蓋測試點，最終產(chǎn)生完全覆蓋表單用例。

　　這里需要首先區(qū)分一下，是手動測試用例還是自動測試用例？

　　一、對于自動測試用例，首先就是要改變腳本的開發(fā)方法，如：

　　1.數(shù)據(jù)驅(qū)動腳本：將測試數(shù)據(jù)從腳本中分立，保存在外部文件中，當數(shù)據(jù)發(fā)生變化時，就不再需要更改代碼，腳本的維護成本也比較低

　　2.關(guān)鍵字驅(qū)動腳本：把腳本中的檢查點和執(zhí)行操作的控制都維護在外部文件中，同樣的，數(shù)據(jù)也會與代碼分離開，可以說是結(jié)合了數(shù)據(jù)驅(qū)動的腳本開發(fā)方法，提高了測試腳本的共享和復(fù)用，缺點就是腳本開發(fā)需要更多的編程經(jīng)驗和設(shè)計能力

　　二、對于手動測試用例，那么我們就需要解決如下問題：

　　1.測試用例管理工具：之前看到很多討論，都沒有提到這個，但我想說的是，工欲善其事，必先利其器，良好的測試用例管理工具，絕對會為測試用例的復(fù)用帶來簡單、方便和快捷，也比office文檔更適用于測試用例庫的建設(shè)和維護

　 　2.測試用例的設(shè)計策略：測試策略無非有兩種，基于功能和基于風險，之前也在論壇里提到過，還有筒子回貼說，測試策略就是基于功能的，這點我不敢茍同， 基于風險的測試用例，往往才是最能被復(fù)用的，對于任何同類型產(chǎn)品來說，無論如何進行功能升級，其失效模式也一定大同小異，比如：汽車的失效模式之一——剎 車失靈，這個不論是小汽車、三輪車、還是大卡車，都會存在同樣的問題，但是功能和性能上，三者之間的差異就比較大了，所以我才會提到我們需要在測試開始前 考慮這樣一種基于風險的測試策略

　　3.業(yè)務(wù)抽象：對于測試來說，同樣需要跟研發(fā)的系統(tǒng)分析師有相當水平的測試設(shè)計師存在，他們的工作職責 是分析系統(tǒng)需求、抽象業(yè)務(wù)用例、設(shè)計測試方案來指導(dǎo)測試用例的進行，測試用例的復(fù)用也應(yīng)該在這一環(huán)節(jié)被考慮，因為一條一條的去查找和審閱相同和相似的測試 用例，對于龐大的系統(tǒng)來說，由于海量測試用例的存在，無疑為大海撈針，但是從更高層次的業(yè)務(wù)用例中去尋找相似性，一定是更快捷的方法，但這也同時需要清晰 合理的、能夠與分解后業(yè)務(wù)用例對應(yīng)的、可跟蹤可追溯的測試用例庫結(jié)構(gòu)，基于此，我才把管理工具放在了第一位

　　以上是我對于“如何提高測試用例復(fù)用性”的問題答案，其中不考慮“如何正確編寫測試用例？”“如何進行測試用例設(shè)計”等問題。

　 　組織和編寫良好的測試用例具有很強的可復(fù)用性。因此，在重復(fù)使用的過程中，需要對測試用例進行維護或者更新，測試用例不是一成不變的。在一個階段的測試 過程結(jié)束后，或多或少會發(fā)現(xiàn)一些測試用例編寫得不夠合理或缺少測試用例覆蓋一些應(yīng)用場景。而且，當下一個版本在測試中使用前一個版本的測試用例時，其中部 分功能可能發(fā)生了改變，這時候也需要去修改那些受功能變化影響的測試用例，使之具有良好的延續(xù)性。通常情況下，測試用例需要更新，可能有以下幾種原因：

　　1、先前的測試用例設(shè)計不全面或者不夠準確。隨著測試的深入和對產(chǎn)品規(guī)格說明書的深入研究，對某些功能、特性、邏輯等的理解越來越清楚、深刻。

　　2、所發(fā)現(xiàn)的嚴重的軟件缺陷沒有被目前的測試用例所覆蓋。

　　3、新的版本中有新功能的需求或者原有功能的增強而需要發(fā)生改動。

　　4、編寫的測試用例不規(guī)范或者語句錯誤。

　　5、舊的測試用例已經(jīng)不再適用，需要刪除。

　 　開發(fā)一個軟件產(chǎn)品，會發(fā)布多個版本，伴隨著測試用例的不斷維護，測試用例也需要不斷完善并與產(chǎn)品功能、特性的變化保持一致，從而使測試用例和產(chǎn)品版本相 關(guān)聯(lián)。在線軟件服務(wù)中，用于不同的客戶有不同的需求及定制，而且有些客戶激進，有些客戶保守，所以軟件產(chǎn)品的多個版本常常共存，為不同的客戶提供服務(wù)，這 時測試用例多個版本并存。所以在新建、修改、刪除測試用例時要十分小心，確定對正確的版本進行修改，不要錯該其他版本的測試用例。無論是對軟件產(chǎn)品還是軟件服務(wù)，多個版本并存的可能性很大，而且可能為不同的主要版本發(fā)布不同的補丁包或小版本，這樣早期的一些版本所擁有的測試用例還是有效的。

　　根據(jù)產(chǎn)品特性和一致性準則，測試用例的維護可以按下面幾種情況分別處理：

　　1、產(chǎn)品特性沒變，只是根據(jù)漏掉的缺陷來完善測試用例。這時候，增加和修改測試用例均可，因為當前被修改的測試用例對相應(yīng)的版本都有效，不會影響某個特定版本所擁有的測試用例。

　　2、原有產(chǎn)品特性發(fā)生了變化，不是新功能特性的問題，而是功能增強，這時候原有的測試用例只對先前版本（如 1.0、2.0）有效，而對當前新的版本（如 3.0）無效。這時，決不能修改測試用例，只能增加新的測試用例，不能影響原有的測試用例。

　　3、原有功能取消了，這時只要將與該功能對應(yīng)的測試用例在新版本上置為空標志或“無效”狀態(tài)，但不能刪除這些測試用例，因為它們對先前某個版本還是有效的。

　　4、完全新增加的特性則很清楚，增加新的測試用例。

　　每個測試用例記錄，針對一個有效版本都有對應(yīng)的標志位，通過這個標志位，很容易實現(xiàn)上述維護需求。這樣，新舊版本的相同測試用例得到一致的維護，測試用例數(shù)也不會成幾倍、幾十倍的增加，可以真正保證測試用例的完整性和有效性。

相關(guān)鏈接：

　　測試用例的設(shè)計在很大程度上是由簡單到詳細且逐步完善的一個過程。其依據(jù)需求文檔、概要設(shè)計、詳細設(shè)計等參考資料。假如在測試過程中沒有測試用例或僅有簡單的功能描述，那么測試過程難以控制或測試結(jié)果將毫無可靠性而言。網(wǎng)上對測試用例的具體設(shè)計的文章也數(shù)不勝數(shù)了，筆者在這也不重復(fù)闡述。

　　因此，筆者對測試用例的總結(jié)為：

　　簡單的測試用例可靠性低、重用性差，且可能導(dǎo)致不同人員理解不同。

　　詳細的測試用例可靠性高，而且便于估計執(zhí)行所需時間，易于控制。

　　我們在設(shè)計測試用例時應(yīng)當考慮以下幾點：

　　第一、時間要求。［是否在測試過程中，測試用例的執(zhí)行易于控制］

　　第二、執(zhí)行者。［應(yīng)當考慮不同的測試用例執(zhí)行者對系統(tǒng)的了解程度］

　　第三、理解程度。［當把測試用例交付給他人執(zhí)行時應(yīng)不需要過多的解釋］

　　所以，測試用例的設(shè)計重要性顯而易見。

　　登錄功能，是一個大家熟悉得不能再熟悉的功能了。但是往往這類看似簡單但卻不簡單的功能，在設(shè)計測試用例時卻漏洞百出。下面，我們通過Google郵箱的登錄窗口實例進一步了解測試用例的設(shè)計。

　　☆ 簡單的測試用例

　　☆ 一般的測試用例

　　☆ 詳細的測試用例

　　通過以上三個測試用例，我們可以很直觀的了解到測試用例具體實現(xiàn)價值。但是，我們達到第三種測試用例設(shè)計技巧時還是不能體現(xiàn)其“詳細”的概念化。

　 　到這，可能很多讀者會問為什么？其實，答案很簡單。雖然我們在設(shè)計用例時把過程體現(xiàn)了，但并沒有把測試數(shù)據(jù)容入當中。那為什么又要寫入相應(yīng)的測試數(shù)據(jù) 呢？我們可以分三點看待這個問題。第一、沒有將測試數(shù)據(jù)和測試邏輯分開的測試用例可能顯得非常龐大，不利于測試員理解，導(dǎo)致難以控制和執(zhí)行；第二、通過將 用例參數(shù)化，可以簡化用例，使測試用例邏輯清晰，數(shù)據(jù)與邏輯的關(guān)系明了，易于理解；第三、有利于提高測試用例的復(fù)用性。所以，在加入輸入（數(shù)據(jù)或操作 等）、輸出（結(jié)果數(shù)據(jù)或預(yù)期結(jié)果等）的測試用例可以很好的重復(fù)使用。

　　☆ 詳細的測試用例（含測試數(shù)據(jù)）

　　結(jié)束語：測試用例的設(shè)計是否詳細，直接關(guān)系著測試生命周期的正常表現(xiàn)。

　　這個例子的設(shè)計并不是我首先想出的，我參考了原文，然后經(jīng)過整理，融匯了我的Excel技巧，把它整理了出來，分析了表的生成過程，比原來的設(shè)計有一定的易學(xué)易用性。現(xiàn)在讓大家來進行分析與學(xué)習。

　　需求規(guī)格：

　　1、如果落點在棋盤外，則不移動棋子；

　　2、如果落點與起點不構(gòu)成日字型，則不移動棋子；

　　3、如果落點處有自己方棋子，則不移動棋子；

　　4、如果在落點方向的鄰近交叉點有棋子（絆馬腿），則不移動棋子；

　　5、如果不屬于1-4條，且落點處無棋子，則移動棋子；

　　6、如果不屬于1-4條，且落點處為對方棋子（非老將），則移動棋子并除去對方棋子；

　　7、如果不屬于1-4條，且落點處為對方老將，則移動棋子，并提示戰(zhàn)勝對方，游戲結(jié)束。

　　一、原因條件：

　　1、落點在棋盤上；

　　2、落點與起點構(gòu)成日字；

　　3、落點處不為自己方棋子；

　　4、落點方向的鄰近交叉點有棋子（絆馬腿）；

　　5、落點處無棋子；

　　6、落點處為對方棋子（非老將）；

　　7、落點處為對方老將。

　　二、結(jié)果動作：

　　21、不移動棋子

　　22、移動棋子（不吃子）

　　23、移動棋子并除去對方棋子

　　24、移動棋子除去對方老將，勝利。

　　添加一個中間節(jié)點11，這樣能夠簡化設(shè)計。然后畫出因果圖：

　 　通常的設(shè)計方法就是一個表的方法，我稱為一表法。但是七個因子，表格就會非常的長，讓人望而卻步！2^7=128，那么長的表是一般人不能做到的，在 Excel里面都感覺版面不夠，要是拿來考試怎么辦？所以這里提供兩表法。1、2、3、4只與11及21有關(guān)，可以使用一個表先處理。然后11、5、6、 7有可以作為一個表。