第一篇：白盒測試用例設(shè)計(jì)方法

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

白盒測試又稱結(jié)構(gòu)測試，透明盒測試、邏輯驅(qū)動測試或基于代碼的測試。白盒測試是一種測試用例設(shè)計(jì)方法，盒子指的是被測試的軟件，白盒指的是盒子是可視的，你清楚盒子內(nèi)部的東西以及里面是如何運(yùn)作的。

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

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

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

? 檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性。

2.白盒測試的目的 通過檢查軟件內(nèi)部的邏輯結(jié)構(gòu)，對軟件中的邏輯路徑進(jìn)行覆蓋測試；

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

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

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

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

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

4）測試總結(jié)階段：對比測試的結(jié)果和代碼的預(yù)期結(jié)果，分析錯(cuò)誤原因，找到并解決錯(cuò)誤。

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

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

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

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

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

揭示隱藏在代碼中的錯(cuò)誤；

對代碼的測試比較徹底；

最優(yōu)化 ? 缺點(diǎn)：費(fèi)用昂貴；

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

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

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

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

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

1.2.1.2.控制流圖的基本控制結(jié)構(gòu)的圖形符號 在控制流圖中，其基本的控制結(jié)構(gòu)所對應(yīng)的圖形符號如下圖。

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

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

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

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

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

2）用例設(shè)計(jì)：

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

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

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

2）用例設(shè)計(jì)：

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

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

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

2）用例設(shè)計(jì)：

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

4）缺點(diǎn)：判定/條件覆蓋準(zhǔn)則的缺點(diǎn)是未考慮條件的組合情況。

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

2）用例設(shè)計(jì)：

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)點(diǎn)：多重條件覆蓋準(zhǔn)則滿足判定覆蓋、條件覆蓋和判定/條件覆蓋準(zhǔn)則。更改的判定/條件覆蓋要求設(shè)計(jì)足夠多的測試用例，使得判定中每個(gè)條件的所有可能結(jié)果至少出現(xiàn)一次，每個(gè)判定本身的所有可能結(jié)果也至少出現(xiàn)一次。并且每個(gè)條件都顯示能單獨(dú)影響判定結(jié)果。

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

6.路徑覆蓋 1）主要特點(diǎn)：設(shè)計(jì)足夠的測試用例，覆蓋程序中所有可能的路徑。

2）用例設(shè)計(jì)：

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

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

If（!A）B++；

If（!A）D--；

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

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

編輯測試用例方法感言

編輯測試用例方法感言、一個(gè)測試用例要寫到什么程度才比較好?、剛開始做測試的時(shí)候，你是怎么學(xué)習(xí)寫測試用例的？、你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標(biāo)準(zhǔn)嗎？

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

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

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

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

由于測試用例是本人執(zhí)行，所以測試用例可以寫的簡單些，但是一定要開發(fā)人員能夠看明白。可惜我所在的公司，都沒有人來看我的測試用例。測試用例對我來說是用來提示我不要忘記了要測試哪些項(xiàng)。一些很有價(jià)值的bug通常不是在寫測試用例的時(shí)候發(fā)現(xiàn)的，而是在

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

第二個(gè)問題，剛開始做測試的時(shí)候，你是怎么學(xué)習(xí)寫測試用例的？

我之所以選擇測試這個(gè)工作是因?yàn)椋何耶厴I(yè)后，在第一家公司做技術(shù)支持，產(chǎn)品的問題很多，導(dǎo)致技術(shù)支持工作很辛苦、很累。為了讓用戶買到的產(chǎn)

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

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

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

你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標(biāo)準(zhǔn)嗎？

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

今天就想到那么些了，以后想到了在補(bǔ)充上了。我把我用的模板給你們粘貼一份上來，只能給你們做些參考，具體還是要看對你所在的公司適用不適用。測試項(xiàng)的歸類我就不列舉了，因?yàn)槊總€(gè)公司的都不太一樣。

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

由安博測試空間技術(shù)中心http://www.tmdps.cn/提供

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

編寫背景：

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

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

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

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

２、剛開始做測試的時(shí)候，你是怎么學(xué)習(xí)寫測試用例的？

３、你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標(biāo)準(zhǔn)嗎？

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

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

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

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

第二個(gè)問題，剛開始做測試的時(shí)候，你是怎么學(xué)習(xí)寫測試用例的？

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

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

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

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

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

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

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

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

今天就想到那么些了，以后想到了在補(bǔ)充上了。我把我用的模板給你們粘貼一份上來，只能給你們做些參考，具體還是要看對你所在的公司適用不適用。測試項(xiàng)的歸類我就不列舉了，因?yàn)槊總€(gè)公司的都不太一樣。

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

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

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

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

編寫背景：

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

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

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

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

２、剛開始做測試的時(shí)候，你是怎么學(xué)習(xí)寫測試用例的？

３、你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標(biāo)準(zhǔn)嗎？

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

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

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

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

第二個(gè)問題，剛開始做測試的時(shí)候，你是怎么學(xué)習(xí)寫測試用例的？

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

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

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

你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標(biāo)準(zhǔn)嗎？

我的體會：

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

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

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

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

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

今天就想到那么些了，以后想到了在補(bǔ)充上了。我把我用的模板給你們粘貼一份上來，只能給你們做些參考，具體還是要看對你所在的公司適用不適用。測試項(xiàng)的歸類我就不列舉了，因?yàn)槊總€(gè)公司的都不太一樣。

第五篇：測試用例設(shè)計(jì)步驟

測試用例設(shè)計(jì)步驟

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

1、測試需求分析

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

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

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

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

A、主流程是什么

B、條件備選流程是什么

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

D、關(guān)鍵的判斷條件是什么

3、測試用例設(shè)計(jì)

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

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

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

適合的技術(shù)：由業(yè)務(wù)需求和設(shè)計(jì)說明導(dǎo)出的功能測試、等價(jià)類劃分

邊界測試：對某個(gè)功能的邊界情況進(jìn)行測試。

適合的技術(shù)：邊界值劃分

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

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

適合的技術(shù)：由業(yè)務(wù)需求和設(shè)計(jì)說明導(dǎo)出的特殊業(yè)務(wù)流程、錯(cuò)誤猜測法、邊界值

分析、內(nèi)部邊界值測試。

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

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

括響應(yīng)時(shí)間，吞吐量等。

適合的技術(shù)：業(yè)務(wù)需求和設(shè)計(jì)說明導(dǎo)出的測試

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

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

4、測試用例評審

測試用例設(shè)計(jì)完成后，為了確認(rèn)測試過程和方法是否正確，是否有遺漏的測試點(diǎn)，需要進(jìn)行測試用例的評審。

測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設(shè)計(jì)者、測試leader、項(xiàng)目經(jīng)理、開發(fā)工程師、其它相關(guān)開發(fā)測試工程師。測試用例評審?fù)戤叄瑴y試工程師根據(jù)評審結(jié)果，對測試用例進(jìn)行修改，并記錄修改日志。

5、測試用例更新完善

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