第一篇：白盒測試用例設計方法

1.白盒測試用例設計方法 1.1.白盒測試概述 由于邏輯錯誤和不正確假設與一條程序路徑被運行的可能性成反比。由于我們經常相信某邏輯路徑不可能被執(zhí)行，而事實上，它可能在正常的情況下被執(zhí)行。由于代碼中的筆誤是隨機且無法杜絕的，因此我們要進行白盒測試。

白盒測試又稱結構測試，透明盒測試、邏輯驅動測試或基于代碼的測試。白盒測試是一種測試用例設計方法，盒子指的是被測試的軟件，白盒指的是盒子是可視的，你清楚盒子內部的東西以及里面是如何運作的。

1.白盒的測試用例需要做到 ? 保證一個模塊中的所有獨立路徑至少被使用一次；

? 對所有邏輯值均需測試 true 和 false；

? 在上下邊界及可操作范圍內運行所有循環(huán)；

? 檢查內部數(shù)據(jù)結構以確保其有效性。

2.白盒測試的目的 通過檢查軟件內部的邏輯結構，對軟件中的邏輯路徑進行覆蓋測試；

在程序不同地方設立檢查點，檢查程序的狀態(tài)，以確定實際運行狀態(tài)與預期狀態(tài)是否一致。

3.白盒測試的特點 依據(jù)軟件設計說明書進行測試、對程序內部細節(jié)的嚴密檢驗、針對特定條件設計測試用例、對軟件的邏輯路徑進行覆蓋測試。

4.白盒測試的實施步驟 1）測試計劃階段：根據(jù)需求說明書，制定測試進度。

2）測試設計階段：依據(jù)程序設計說明書，按照一定規(guī)范化的方法進行軟件結構劃分和設計測試用例。

3）測試執(zhí)行階段：輸入測試用例，得到測試結果。

4）測試總結階段：對比測試的結果和代碼的預期結果，分析錯誤原因，找到并解決錯誤。

5.白盒測試的方法 總體上分為靜態(tài)方法和動態(tài)方法兩大類。

? 靜態(tài)分析：是一種不通過執(zhí)行程序而進行測試的技術。靜態(tài)分析的關鍵功能是檢查軟件的表示和描述是否一致,沒有沖突或者沒有歧義。

? 動態(tài)分析：主要特點是當軟件系統(tǒng)在模擬的或真實的環(huán)境中執(zhí)行之前、之中和之后 , 對軟件系統(tǒng)行為的分析。動態(tài)分析包含了程序在受控的環(huán)境下使用特定的期望結果進行正式的運行。它顯示了一個系統(tǒng)在檢查狀態(tài)下是正確還是不正確。在動態(tài)分析技術中,最重要的技術是路徑和分支測試。下面要介紹的六種覆蓋測試方法屬于動態(tài)分析方法。

6.白盒測試的優(yōu)缺點 ? 優(yōu)點：迫使測試人員去仔細思考軟件的實現(xiàn)；

可以檢測代碼中的每條分支和路徑；

揭示隱藏在代碼中的錯誤；

對代碼的測試比較徹底；

最優(yōu)化 ? 缺點：費用昂貴；

無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤；

不驗證規(guī)格的正確性。

1.2.白盒測試基本技術 1.2.1.控制流圖 1.2.1.1.定義 程序流程圖是軟件開發(fā)過程中進行詳細設計時，表示模塊內部邏輯的一個常用的、也非常有效的圖示法。程序流程圖詳細地反映了程序內部控制流的處理和轉移過程，它一般是進行模塊編碼的參考依據(jù)。在程序流程圖中，通常擁有很多種圖示元素，例如，“矩形框”表示一個計算處理過程，而“菱形框”表示一個判斷條件等。通常測試人員為某個程序模塊做白盒測試過程中，在做與路徑相關的各種分析的時候，這些非常細節(jié)的信息往往是不太重要。因此，為了更清晰突出地顯示出程序的控制結構，反映控制流的轉移過程，一種簡化了的程序流程圖便出現(xiàn)了，就是程序的控制流圖。在控制流圖中一般只有兩種簡單的圖示符號：節(jié)點和控制流。

1）節(jié)點。以標有編號的圓圈表示。它一般代表了程序流程圖中矩形框所表示的處理、以及領形框所表示的判定條件，以及兩條活多條節(jié)點的匯合點等。一個節(jié)點就是一個基本的程序塊，它可以是一個單獨的語句（如if條件判斷語句，或循環(huán)語句），也可以是多個順序執(zhí)行的語句塊。

2）控制流。以帶箭頭的弧線表示，用來連接相關的兩個節(jié)點。它與程序流程圖中的控制流所表示的意義是一致的，都是知識了程序控制的轉移過程。為了便于處理，每個控制流也可以標有名字，這是繼就相當于向圖中的邊。每條邊必須要終止某一節(jié)點。

1.2.1.2.控制流圖的基本控制結構的圖形符號 在控制流圖中，其基本的控制結構所對應的圖形符號如下圖。

（a）順序結構（b）IF ELSE結構（c）多分支結構（d）循環(huán)結構 1.2.2.六種覆蓋方法 首先為了下文的舉例描述方便，這里先給出一張程序流程圖。

1.語句覆蓋 1）主要特點：語句覆蓋是最起碼的結構覆蓋要求，語句覆蓋要求設計足夠多的測試用例，使得程序中每條語句至少被執(zhí)行一次。

2）用例設計：（如果此時將A路徑上的語句1—〉T去掉，那么用例如下）X ?Y ?路徑 ?1 ?50 ?50 ?OBDE ?2 ?90 ?70 ?OBCE 3）優(yōu)點：可以很直觀地從源代碼得到測試用例，無須細分每條判定表達式。

4）缺點：由于這種測試方法僅僅針對程序邏輯中顯式存在的語句，但對于隱藏的條件和可能到達的隱式邏輯分支，是無法測試的。在本例中去掉了語句1—〉T去掉，那么就少了一條測試路徑。在if結構中若源代碼沒有給出else后面的執(zhí)行分支，那么語句覆蓋測試就不會考慮這種情況。但是我們不能排除這種以外的分支不會被執(zhí)行，而往往這種錯誤會經常出現(xiàn)。再如，在Do-While結構中，語句覆蓋執(zhí)行其中某一個條件分支。那么顯然，語句覆蓋對于多分支的邏輯運算是無法全面反映的，它只在乎運行一次，而不考慮其他情況。

2.判定覆蓋 1）主要特點：判定覆蓋又稱為分支覆蓋，它要求設計足夠多的測試用例，使得程序中每個判定至少有一次為真值，有一次為假值，即：程序中的每個分支至少執(zhí)行一次。每個判斷的取真、取假至少執(zhí)行一次。

2）用例設計：

X ?Y ?路徑 ?1 ?90 ?90 ?OAE ?2 ?50 ?50 ?OBDE ?3 ?90 ?70 ?OBCE 3）優(yōu)點：判定覆蓋比語句覆蓋要多幾乎一倍的測試路徑，當然也就具有比語句覆蓋更強的測試能力。同樣判定覆蓋也具有和語句覆蓋一樣的簡單性，無須細分每個判定就可以得到測試用例。

4）缺點：往往大部分的判定語句是由多個邏輯條件組合而成（如，判定語句中包含AND、OR、CASE），若僅僅判斷其整個最終結果，而忽略每個條件的取值情況，必然會遺漏部分測試路徑。

3.條件覆蓋 1）主要特點：條件覆蓋要求設計足夠多的測試用例，使得判定中的每個條件獲得各種可能的結果，即每個條件至少有一次為真值，有一次為假值。

2）用例設計：

X ?Y ?路徑 ?1 ?90 ?70 OBC ?2 40 ? OBD 3）優(yōu)點：顯然條件覆蓋比判定覆蓋，增加了對符合判定情況的測試，增加了測試路徑。

4）缺點：要達到條件覆蓋，需要足夠多的測試用例，但條件覆蓋并不能保證判定覆蓋。條件覆蓋只能保證每個條件至少有一次為真，而不考慮所有的判定結果。

4.判定/條件覆蓋 1）主要特點：設計足夠多的測試用例，使得判定中每個條件的所有可能結果至少出現(xiàn)一次，每個判定本身所有可能結果也至少出現(xiàn)一次。

2）用例設計：

X ?Y ?路徑 ?1 ?90 ?90 ?OAE ?2 ?50 ?50 ?OBDE ?3 ?90 ?70 ?OBCE ?4 ?70 ?90 ?OBCE 3）優(yōu)點：判定/條件覆蓋滿足判定覆蓋準則和條件覆蓋準則，彌補了二者的不足。

4）缺點：判定/條件覆蓋準則的缺點是未考慮條件的組合情況。

5.組合覆蓋 1）主要特點：要求設計足夠多的測試用例，使得每個判定中條件結果的所有可能組合至少出現(xiàn)一次。

2）用例設計：

X ?Y ?路徑 ?1 ?90 ?90 ?OAE ?2 ?90 ?70 ?OBCE ?3 ?90 ?30 ?OBDE ?4 ?70 ?90 ?OBCE ?5 ?30 ?90 ?OBDE ?6 ?70 ?70 ?OBDE ?7 ?50 ?50 ?OBDE 3）優(yōu)點：多重條件覆蓋準則滿足判定覆蓋、條件覆蓋和判定/條件覆蓋準則。更改的判定/條件覆蓋要求設計足夠多的測試用例，使得判定中每個條件的所有可能結果至少出現(xiàn)一次，每個判定本身的所有可能結果也至少出現(xiàn)一次。并且每個條件都顯示能單獨影響判定結果。

4）缺點：線性地增加了測試用例的數(shù)量。

6.路徑覆蓋 1）主要特點：設計足夠的測試用例，覆蓋程序中所有可能的路徑。

2）用例設計：

X ?Y ?路徑 ?1 ?90 ?90 ?OAE ?2 ?50 ?50 ?OBDE ?3 ?90 ?70 ?OBCE ?4 ?70 ?90 ?OBCE 3）優(yōu)點：這種測試方法可以對程序進行徹底的測試，比前面五種的覆蓋面都廣。

4）缺點：由于路徑覆蓋需要對所有可能的路徑進行測試（包括循環(huán)、條件組合、分支選擇等），那么需要設計大量、復雜的測試用例，使得工作量呈指數(shù)級增長。而在有些情況下，一些執(zhí)行路徑是不可能被執(zhí)行的，如：

If（!A）B++；

If（!A）D--；

這兩個語句實際只包括了2條執(zhí)行路徑，即A為真或假時候對B和D的處理，真或假不可能都存在，而路徑覆蓋測試則認為是包含了真與假的4條執(zhí)行路徑。這樣不僅降低了測試效率，而且大量的測試結果的累積，也為排錯帶來麻煩 僅供參考

第二篇：編輯測試用例方法感言

編輯測試用例方法感言

編輯測試用例方法感言、一個測試用例要寫到什么程度才比較好?、剛開始做測試的時候，你是怎么學習寫測試用例的？、你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？

對于測試用例，而我目前正在思考的問題是：怎么寫出對公司有價值的測試用例，對公司來說，怎么測試才是最有價值的測試？

一個測試用例要寫到什么程度才比較好？

這個問題，沒有定語，沒有說是在什么樣的一個情況下，因此我這里只能就我工作中碰到的情況說說了。說起來

比較長阿，大家要有常要考慮這個項目的周期和測試資源。我所在的公司，通常項目開發(fā)時間都很短到個月，然而測試通常都是在開發(fā)即將結束的時候才真正介入。測試就是個人負責。因此時間和人力資源對測試來說是完成測試工作的一個風險。為此在這種情況下，我都是先熟悉系統(tǒng)的業(yè)務，把握重點業(yè)務和功能后，參考需求，把測試需求、測試計劃和測試大綱給制定好。由于時間關系，測試用例都是先寫重點的業(yè)務，也就是集成測試的測試用例。另外測試用例是根據(jù)測試大綱來的。通常都是先挑最重要的測試項和風險大的業(yè)務功能編寫測試用例。

由于測試用例是本人執(zhí)行，所以測試用例可以寫的簡單些，但是一定要開發(fā)人員能夠看明白?？上宜诘墓荆紱]有人來看我的測試用例。測試用例對我來說是用來提示我不要忘記了要測試哪些項。一些很有價值的bug通常不是在寫測試用例的時候發(fā)現(xiàn)的，而是在

測試軟件的過程中，我在家睡覺前的思考和回家的路上思考出來的。這就是手動測試的魅力，有些軟件的缺陷是在你使用軟件的一瞬間和思考的一剎那突然發(fā)現(xiàn)的。所以要我回答測試用例要寫到什么程度才比較好，我覺的只要你所寫的測試用例在你的公司能夠順利的執(zhí)行，不影響你的測試執(zhí)行工作就可以了。因為測試用例寫的太詳細，你要花費時間和人力成本，這樣出來的測試用例是最好的也是最貴的，一旦需求變更，也需要修改，這時你會發(fā)現(xiàn)這種詳細的測試用例是最不掙錢的。測試用例寫的太粗，別人看不懂，不能執(zhí)行，那你要花費你的時間去解釋，這就加大了測試的工作量。這也不是好的方法。

第二個問題，剛開始做測試的時候，你是怎么學習寫測試用例的？

我之所以選擇測試這個工作是因為：我畢業(yè)后，在第一家公司做技術支持，產品的問題很多，導致技術支持工作很辛苦、很累。為了讓用戶買到的產

品的質量是好的，我選擇了做測試，到了現(xiàn)在的公司。我剛做測試的時候，對測試一無所知，什么測試流程阿、文檔阿都不知道，公司的測試和管理也不規(guī)范。對測試，大家都認為不就是拿個鼠標點來點去，誰都可以來做。為此，我經常上網(wǎng)查測試的資料，看看自己到底適合不適合做測試，測試到底是什么樣的一個職業(yè)，怎么去規(guī)劃自己的個人發(fā)展。其實要做好測試，真是不容易。不喜歡，真是不能做這個職業(yè)。http://

現(xiàn)在想想自己剛開始寫測試用例的時候，真是好笑。就像小孩子學習寫字一樣。先是在網(wǎng)上狂搜索了一把測試用例的模板，綜合了幾個，就形成了。我之所以不用公司原有的測試用例模板，是因為太不適用了。還好，公司沒有嚴格要求必須要那個模板，只要適用就行。模板找好了，可是寫就費勁了。對于剛做測試的新人，看似簡單的一個填表工作，要寫好真是不簡單。一開始寫的比較不自然，有些生搬硬套，而且

還很慢。沒有辦法，那時候沒有人指導我，全靠自己自學和領悟，所以那段日子很苦阿！多寫幾次后，就知道和領悟了，測試用例要根據(jù)測試大綱來寫，測試大綱要根據(jù)測試計劃來寫。測試大綱更多的是把握住測試項的方向，而測試用例是指導怎么去執(zhí)行測試。還好，我有編程的經驗，所以對我熟悉軟件幫了一個很大的忙。熟悉了軟件的業(yè)務才能去寫測試用例，才能更好的去測試。這也是我一點一點的領悟出來的。說了這么多，不知道這樣的回答是否是回答了這個問題。

你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？

我的體會：、測試用例要根據(jù)測試大綱來編寫、測試用例也要分測試項進行歸類，這樣比較好分析和閱讀。如：業(yè)務流程測試、安裝測試、功能測試、用戶友好性測試、兼容性測試、性能測試、安全性測試等等。、編寫測試用例要考慮各種情況，精力主要集中在軟件的主要業(yè)務流程和風險高的地方。能分出測試優(yōu)先級別就最好了。、熟悉系統(tǒng)，對編寫測試用例很有幫助。、即使對測試很熟悉了，在時間非常緊的時候，編寫測試用例還是很有必要和好處的。

今天就想到那么些了，以后想到了在補充上了。我把我用的模板給你們粘貼一份上來，只能給你們做些參考，具體還是要看對你所在的公司適用不適用。測試項的歸類我就不列舉了，因為每個公司的都不太一樣。

第三篇：編寫測試用例方法心得體會

由安博測試空間技術中心http://004km.cn/提供

編寫測試用例方法心得體會

編寫背景：

一直以來都不太想把技術方面的文章寫出來給大家看，一個是怕寫作功底不好誤導哪些剛入門的測試同行，自己的表達能力有限，另一方面怕有的同行拿出去炒作，再者測試網(wǎng)站論壇上關于測試用例的資料已經實在是多。但是看到同行紛紛都在問我測試用例的問題，都很想知道我寫測試用例的心得體會。我就抱著試試看的心態(tài)寫寫吧，希望測試的老前輩看見了，可以給我多提提建議。

編寫測試用例方法心得體會

在我的個人郵箱和MSN上，通常同行都問我類似下面這樣的問題：

１、一個測試用例要寫到什么程度才比較好?

２、剛開始做測試的時候，你是怎么學習寫測試用例的？

３、你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？

對于測試用例，而我目前正在思考的問題是：怎么寫出對公司有價值的測試用例，對公司來說，怎么測試才是最有價值的測試？

下面先來分析第一個問題吧：一個測試用例要寫到什么程度才比較好？

這個問題，沒有定語，沒有說是在什么樣的一個情況下，因此我這里只能就我工作中碰到的情況說說了。說起來比較長阿，大家要有耐心看才行哈。^_^ 在我測試工作中，碰上的測試類型我自己劃分成這么４種： ^

對項目、產品的測試，測試的時候通常要考慮這個項目的周期和測試資源。我所在的公司，通常項目開發(fā)時間都很短４到５個月，然而測試通常都是在開發(fā)即將結束的時候才真正介入。測試就是１個人負責。因此時間和人力資源對測試來說是完成測試工作的一個風險。為此在這種情況下，我都是先熟悉系統(tǒng)的業(yè)務，把握重點業(yè)務和功能后，參考需求，把測試需求、測試計劃和測試大綱給制定好。由于時間關系，測試用例都是先寫重點的業(yè)務，也就是集成測試的測試用例。另外測試用例是根據(jù)測試大綱來的。通常都是先挑最重要的測試項和風險大的業(yè)務功能編寫測試用例。由于測試用例是本人執(zhí)行，所以測試用例可以寫的簡單些，但是一定要開發(fā)人員能夠看明白。可惜我所在的公司，都沒有人來看我的測試用例。測試用例對我來說是用來提示我不要忘記了要測試哪些項。一些很有價值的ｂｕｇ通常不是在寫測試用例的時候發(fā)現(xiàn)的，而是在測試軟件的過程中，我在家睡覺前的思考和回家的路上思考出來的。這就是手動測試的魅力，有些軟件的缺陷是在你使用軟件的一瞬間和思考的一剎那突然發(fā)現(xiàn)的。所以要我回答測試用例要寫到什么程度才比較好，我覺的只要你所寫的測試用例在你的公司能夠順利的執(zhí)行，不影響你的測試執(zhí)行工作就可以了。因為測試用例寫的太詳細，你要花費時間和人力成本，這樣出來的測試用例是最好的也是最貴的，一旦需求變更，也需要修改，這時你會發(fā)現(xiàn)這種詳細的測試用例是最不掙錢的。測試用例寫的太粗，別人看不懂，不能執(zhí)行，那你要花費你的時間去解釋，這就加大了測試的工作量。這也不是好的方法。

第二個問題，剛開始做測試的時候，你是怎么學習寫測試用例的？

我之所以選擇測試這個工作是因為：我畢業(yè)后，在第一家公司做技術支持，產品的問題很多，導致技術支持工作很辛苦、很累。為了讓用戶買到的產品的質量是好的，我選擇了做測試，到了現(xiàn)在的公司。我剛做測試的時候，對測試一無所知，什么測試流程阿、文檔阿都不知道，公司的測試和管理也不規(guī)范。對測試，大家都認為不就是拿個鼠標點來點去，誰都可以來做。為此，我經常上網(wǎng)查測試的資料，看看自己到底適合不適合做測試，測試到底是什么樣的一個職業(yè)，怎么去規(guī)劃自己的個人發(fā)展。其實要做好測試，真是不容易。不喜歡，真是不能做這個職業(yè)。

現(xiàn)在想想自己剛開始寫測試用例的時候，真是好笑。就像小孩子學習寫字一樣。先是在網(wǎng)上狂搜索了一把測試用例的模板，綜合了幾個，就形成了。我之所以不用公司原有的測試用例模板，是因為太不適用了。還好，公司沒有嚴格要求必須要那個模板，只要適用就行。模板找好了，可是寫就費勁了。對于剛做測試的新人，看似簡單的一個填表工作，要寫好真是不簡單。一開始寫的比較不自然，有些生搬硬套，而且還很慢。沒有辦法，那時候沒有人指導我，全靠自己自學和領悟，所以那段日子很苦阿！多寫幾次后，就知道和領悟了，測試用例要根據(jù)測試大綱來寫，測試大綱要根據(jù)測試計劃來寫。測試大綱更多的是把握住測試項的方向，而測試用例是指導怎么去執(zhí)行測試。還好，我有編程的經驗，所以對我熟悉軟件幫了一個很大的忙。熟悉了軟件的業(yè)務才能去寫測試用例，才能更好的去測試。這也是我一點一點的領悟出來的。說了這么多，不知道這樣的回答是否是回答了這個問題。

最后一個問題了，我盡量少寫些，文字太多了大家看的也累，我寫的也累。嘿嘿。^_^ 你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？ 我的體會：

１、測試用例要根據(jù)測試大綱來編寫

２、測試用例也要分測試項進行歸類，這樣比較好分析和閱讀。如：業(yè)務流程測試、安裝測試、功能測試、用戶友好性測試、兼容性測試、性能測試、安全性測試等等。

３、編寫測試用例要考慮各種情況，精力主要集中在軟件的主要業(yè)務流程和風險高的地方。能分出測試優(yōu)先級別就最好了。

４、熟悉系統(tǒng)，對編寫測試用例很有幫助。

５、即使對測試很熟悉了，在時間非常緊的時候，編寫測試用例還是很有必要和好處的。

今天就想到那么些了，以后想到了在補充上了。我把我用的模板給你們粘貼一份上來，只能給你們做些參考，具體還是要看對你所在的公司適用不適用。測試項的歸類我就不列舉了，因為每個公司的都不太一樣。

北京測試空間科技發(fā)展有限公司是注冊于北京市海淀區(qū)高新技術園的軟件企業(yè)，目前主要業(yè)務范圍包括軟件測試管理 工具研發(fā)、軟件測試項目外包和軟件測試專業(yè)技術人才培養(yǎng)及派遣。在軟件測試管理工具研發(fā)領域已成功開發(fā)具有

自主知識產權的STMP管理軟件。在軟件測試項目外包領域已建立廣泛的業(yè)務渠道，服務客戶包括北大軟件工程中心、東軟股份、海輝高科、用友軟件、萊博智科技、電子部5所、11所，航天704所、中國金融認證管理中心、國安創(chuàng)想、清華同方、中軟融鑫、長峰科技等100余家企業(yè)，項目覆蓋行業(yè)包括軍工、航天、金融、通信等領域。由安博測試空間技術中心http://004km.cn/提供 地址：北京市海淀區(qū)學院路40號大唐電信測試空間樓 聯(lián)系電話：010-62303223 62303260 62303230

第四篇：編寫測試用例方法心得體會

編寫測試用例方法心得體會

編寫背景：

一直以來都不太想把技術方面的文章寫出來給大家看，一個是怕寫作功底不好誤導哪些剛入門的測試同行，自己的表達能力有限，另一方面怕有的同行拿出去炒作，再者測試網(wǎng)站論壇上關于測試用例的資料已經實在是多。但是看到同行紛紛都在問我測試用例的問題，都很想知道我寫測試用例的心得體會。我就抱著試試看的心態(tài)寫寫吧，希望測試的老前輩看見了，可以給我多提提建議。

編寫測試用例方法心得體會

在我的個人郵箱和MSN上，通常同行都問我類似下面這樣的問題：

１、一個測試用例要寫到什么程度才比較好?

２、剛開始做測試的時候，你是怎么學習寫測試用例的？

３、你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？

對于測試用例，而我目前正在思考的問題是：怎么寫出對公司有價值的測試用例，對公司來說，怎么測試才是最有價值的測試？

下面先來分析第一個問題吧：一個測試用例要寫到什么程度才比較好？

這個問題，沒有定語，沒有說是在什么樣的一個情況下，因此我這里只能就我工作中碰到的情況說說了。說起來比較長阿，大家要有耐心看才行哈。^_^ 在我測試工作中，碰上的測試類型我自己劃分成這么４種： ^

對項目、產品的測試，測試的時候通常要考慮這個項目的周期和測試資源。我所在的公司，通常項目開發(fā)時間都很短４到５個月，然而測試通常都是在開發(fā)即將結束的時候才真正介入。測試就是１個人負責。因此時間和人力資源對測試來說是完成測試工作的一個風險。為此在這種情況下，我都是先熟悉系統(tǒng)的業(yè)務，把握重點業(yè)務和功能后，參考需求，把測試需求、測試計劃和測試大綱給制定好。由于時間關系，測試用例都是先寫重點的業(yè)務，也就是集成測試的測試用例。另外測試用例是根據(jù)測試大綱來的。通常都是先挑最重要的測試項和風險大的業(yè)務功能編寫測試用例。由于測試用例是本人執(zhí)行，所以測試用例可以寫的簡單些，但是一定要開發(fā)人員能夠看明白?？上宜诘墓?，都沒有人來看我的測試用例。測試用例對我來說是用來提示我不要忘記了要測試哪些項。一些很有價值的ｂｕｇ通常不是在寫測試用例的時候發(fā)現(xiàn)的，而是在測試軟件的過程中，我在家睡覺前的思考和回家的路上思考出來的。這就是手動測試的魅力，有些軟件的缺陷是在你使用軟件的一瞬間和思考的一剎那突然發(fā)現(xiàn)的。所以要我回答測試用例要寫到什么程度才比較好，我覺的只要你所寫的測試用例在你的公司能夠順利的執(zhí)行，不影響你的測試執(zhí)行工作就可以了。因為測試用例寫的太詳細，你要花費時間和人力成本，這樣出來的測試用例是最好的也是最貴的，一旦需求變更，也需要修改，這時你會發(fā)現(xiàn)這種詳細的測試用例是最不掙錢的。測試用例寫的太粗，別人看不懂，不能執(zhí)行，那你要花費你的時間去解釋，這就加大了測試的工作量。這也不是好的方法。

第二個問題，剛開始做測試的時候，你是怎么學習寫測試用例的？

我之所以選擇測試這個工作是因為：我畢業(yè)后，在第一家公司做技術支持，產品的問題很多，導致技術支持工作很辛苦、很累。為了讓用戶買到的產品的質量是好的，我選擇了做測試，到了現(xiàn)在的公司。我剛做測試的時候，對測試一無所知，什么測試流程阿、文檔阿都不知道，公司的測試和管理也不規(guī)范。對測試，大家都認為不就是拿個鼠標點來點去，誰都可以來做。為此，我經常上網(wǎng)查測試的資料，看看自己到底適合不適合做測試，測試到底是什么樣的一個職業(yè)，怎么去規(guī)劃自己的個人發(fā)展。其實要做好測試，真是不容易。不喜歡，真是不能做這個職業(yè)。

現(xiàn)在想想自己剛開始寫測試用例的時候，真是好笑。就像小孩子學習寫字一樣。先是在網(wǎng)上狂搜索了一把測試用例的模板，綜合了幾個，就形成了。我之所以不用公司原有的測試用例模板，是因為太不適用了。還好，公司沒有嚴格要求必須要那個模板，只要適用就行。模板找好了，可是寫就費勁了。對于剛做測試的新人，看似簡單的一個填表工作，要寫好真是不簡單。一開始寫的比較不自然，有些生搬硬套，而且還很慢。沒有辦法，那時候沒有人指導我，全靠自己自學和領悟，所以那段日子很苦阿！多寫幾次后，就知道和領悟了，測試用例要根據(jù)測試大綱來寫，測試大綱要根據(jù)測試計劃來寫。測試大綱更多的是把握住測試項的方向，而測試用例是指導怎么去執(zhí)行測試。還好，我有編程的經驗，所以對我熟悉軟件幫了一個很大的忙。熟悉了軟件的業(yè)務才能去寫測試用例，才能更好的去測試。這也是我一點一點的領悟出來的。說了這么多，不知道這樣的回答是否是回答了這個問題。

最后一個問題了，我盡量少寫些，文字太多了大家看的也累，我寫的也累。嘿嘿。^_^

你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？

我的體會：

１、測試用例要根據(jù)測試大綱來編寫

２、測試用例也要分測試項進行歸類，這樣比較好分析和閱讀。如：業(yè)務流程測試、安裝測試、功能測試、用戶友好性測試、兼容性測試、性能測試、安全性測試等等。

３、編寫測試用例要考慮各種情況，精力主要集中在軟件的主要業(yè)務流程和風險高的地方。能分出測試優(yōu)先級別就最好了。

４、熟悉系統(tǒng)，對編寫測試用例很有幫助。

５、即使對測試很熟悉了，在時間非常緊的時候，編寫測試用例還是很有必要和好處的。

今天就想到那么些了，以后想到了在補充上了。我把我用的模板給你們粘貼一份上來，只能給你們做些參考，具體還是要看對你所在的公司適用不適用。測試項的歸類我就不列舉了，因為每個公司的都不太一樣。

第五篇：測試用例設計步驟

測試用例設計步驟

設計測試案例的時候，需要有清晰的測試思路，對要測試什么，按照什么順序測試，覆蓋哪些需求做到心中有數(shù)。測試用例編寫者不僅要掌握軟件測試的技術和流程，而且要對被測軟件的設計、功能規(guī)格說明、用戶試用場景以及程序/模塊的結構都有比較透徹的理解。測試用例設計一般包括以下幾個步驟：

1、測試需求分析

從軟件需求文檔中，找出待測試軟件/模塊的需求，通過自己的分析、理解，整理成為測試需求，清楚被測試對象具有哪些功能。測試需求的特點是：包含軟件需求，具有可測試性。測試需求應該在軟件需求基礎上進行歸納、分類或細分，方便測試用例設計。測試用例中的測試集與測試需求的關系是多對一的關系，即一個或多個測試用例集對應一個測試需求。

2、業(yè)務流程分析

軟件測試，不單純是基于功能的黑盒測試，還需要對軟件的內部處理邏輯進行測試。為了不遺漏測試點，需要清楚的了解軟件產品的業(yè)務流程。建議在做復雜的測試用例設計前，先畫出軟件的業(yè)務流程。如果設計文檔中已經有業(yè)務流程設計，可以從測試角度對現(xiàn)有流程進行補充。如果無法從設計中得到業(yè)務流程，測試工程師應通過閱讀設計文檔，與開發(fā)人員交流，最終畫出業(yè)務流程圖。業(yè)務流程圖可以幫助理解軟件的處理邏輯和數(shù)據(jù)流向，從而指導測試用例的設計。

從業(yè)務流程上，應得到以下信息：

A、主流程是什么

B、條件備選流程是什么

C、數(shù)據(jù)流向是什么

D、關鍵的判斷條件是什么

3、測試用例設計

完成了測試需求分析和軟件流程分析后，開始著手設計測試用例。測試用例設計的類型包括功能測試，邊界測試，異常測試，性能測試，壓力測試等。在用例設計中，除了功能測試用例外，應盡量考慮邊界、異常、性能的情況，以便發(fā)現(xiàn)更多的隱藏問題。

黑盒測試的測試用例設計方法有：等價類劃分、邊界值劃分、因果圖分析和錯誤猜測，白盒測試的測試用例設計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這里主要討論黑盒測試。在設計測試用例的時候可以使用軟件測試用例設計方法，結合前面的需求分析和軟件流程分析進行設計：

功能測試：測試某個功能是否滿足需求的定義，功能是否正確，完備。

適合的技術：由業(yè)務需求和設計說明導出的功能測試、等價類劃分

邊界測試：對某個功能的邊界情況進行測試。

適合的技術：邊界值劃分

異常測試：對某些功能來說，其邊界情況無法簡單的了解或某些操作不完全是正確的但又是

可能發(fā)生的，類似這樣的情況需要書寫相關的異常測試。

適合的技術：由業(yè)務需求和設計說明導出的特殊業(yè)務流程、錯誤猜測法、邊界值

分析、內部邊界值測試。

性能測試：檢查系統(tǒng)是否滿足在需求中所規(guī)定達到的性能，性能主要包括了解程序的內外部

性能因素。內部性能因素包括測試環(huán)境的配置，系統(tǒng)資源使用狀況；外部因素包

括響應時間，吞吐量等。

適合的技術：業(yè)務需求和設計說明導出的測試

壓力測試：壓力測試又稱強度測試，主要是檢查系統(tǒng)運行環(huán)境在極限情況下軟件運行的能力，比如說給一個相當大的負荷或網(wǎng)絡流量給應用軟件兼容測試：測試軟件產品在不

同的平臺，不同的工具，相同工具的不同版本下功能的兼容性。

4、測試用例評審

測試用例設計完成后，為了確認測試過程和方法是否正確，是否有遺漏的測試點，需要進行測試用例的評審。

測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設計者、測試leader、項目經理、開發(fā)工程師、其它相關開發(fā)測試工程師。測試用例評審完畢，測試工程師根據(jù)評審結果，對測試用例進行修改，并記錄修改日志。

5、測試用例更新完善

測試用例編寫完成之后需要不斷完善，軟件產品新增功能或更新需求后，測試用例必須配套修改更新；在測試過程中發(fā)現(xiàn)設計測試用例時考慮不周，需要對測試用例進行修改完善；在軟件交付使用后客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例一般也應隨之編制升級更新版本。測試用例是“活”的，在軟件的生命周期中不斷更新與完善。