第一篇：編寫測試用例方法心得體會(huì)

編寫測試用例方法心得體會(huì)

編寫背景：

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

編寫測試用例方法心得體會(huì)

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

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

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

３、你對黑盒測試用例的編寫的體會(huì)是什么？有什么好的版本或者標(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)的，而是在測試軟件的過程中，我在家睡覺前的思考和回家的路上思考出來的。這就是手動(dòng)測試的魅力，有些軟件的缺陷是在你使用軟件的一瞬間和思考的一剎那突然發(fā)現(xiàn)的。所以要我回答測試用例要寫到什么程度才比較好，我覺的只要你所寫的測試用例在你的公司能夠順利的執(zhí)行，不影響你的測試執(zhí)行工作就可以了。因?yàn)闇y試用例寫的太詳細(xì)，你要花費(fèi)時(shí)間和人力成本，這樣出來的測試用例是最好的也是最貴的，一旦需求變更，也需要修改，這時(shí)你會(huì)發(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è)問題了，我盡量少寫些，文字太多了大家看的也累，我寫的也累。嘿嘿。^_^

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

我的體會(huì)：

１、測試用例要根據(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è)公司的都不太一樣。

第二篇：編寫測試用例方法心得體會(huì)

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

編寫測試用例方法心得體會(huì)

編寫背景：

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

編寫測試用例方法心得體會(huì)

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

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

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

３、你對黑盒測試用例的編寫的體會(huì)是什么？有什么好的版本或者標(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)的，而是在測試軟件的過程中，我在家睡覺前的思考和回家的路上思考出來的。這就是手動(dòng)測試的魅力，有些軟件的缺陷是在你使用軟件的一瞬間和思考的一剎那突然發(fā)現(xiàn)的。所以要我回答測試用例要寫到什么程度才比較好，我覺的只要你所寫的測試用例在你的公司能夠順利的執(zhí)行，不影響你的測試執(zhí)行工作就可以了。因?yàn)闇y試用例寫的太詳細(xì)，你要花費(fèi)時(shí)間和人力成本，這樣出來的測試用例是最好的也是最貴的，一旦需求變更，也需要修改，這時(shí)你會(huì)發(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è)問題了，我盡量少寫些，文字太多了大家看的也累，我寫的也累。嘿嘿。^_^ 你對黑盒測試用例的編寫的體會(huì)是什么？有什么好的版本或者標(biāo)準(zhǔn)嗎？ 我的體會(huì)：

１、測試用例要根據(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

第三篇：編寫測試用例的一點(diǎn)體會(huì)

編寫測試用例的一點(diǎn)體會(huì)

一是測試用例對需求覆蓋的完整性；二是測試用例的有效性；三測試用例的可理解性四是測試用例的清晰性；五是測試用例的可維護(hù)性。

測試用例是基于需求的，為了測試程序是否滿足需求，個(gè)人覺得要想寫好測試用例必須對于需求做到完全理解，并能從全局上把握住需求。一個(gè)好的方法就是用mm圖把需求分解了。把基本路徑分解出來，將需求歸類。理順了需求，用例寫起來就順手的多。在編寫用例的過程中進(jìn)行等價(jià)類的劃分，最后用判定表進(jìn)行評判，補(bǔ)充缺少的用例，剔除冗余的用例。做到對需求的100%覆蓋。也就是說拿到需求文檔必須進(jìn)行必要的分析，不能上來就盲目的寫用例，新人尤其應(yīng)該注意。測試用例編寫完成后必須明確哪些是核心功能的用例！

（測試用例的有效性）測試用例應(yīng)該包含清晰的輸入數(shù)據(jù)以及預(yù)期輸出，沒有測試數(shù)據(jù)的用例更多的是具有指導(dǎo)意義，執(zhí)行過程中更多的是靠個(gè)人根據(jù)指導(dǎo)的自由發(fā)揮。但是看看我們的基線庫更多的是這樣指導(dǎo)意義的用例。（但是輸入數(shù)據(jù)又涉及到了維護(hù)的問題，以及環(huán)境或者業(yè)務(wù)發(fā)生變更后引起的有效性問題）。對于預(yù)期的結(jié)果不能僅僅是頁面上或者界面上的可見結(jié)果，如果和數(shù)據(jù)庫發(fā)生了交互，必須包含數(shù)據(jù)庫里準(zhǔn)確的驗(yàn)證結(jié)果。用例基于數(shù)據(jù)驅(qū)動(dòng)。

（測試用例的可理解性）測試用例步驟必須描述清晰，不能出現(xiàn)模棱兩可以及重復(fù)的話語，測試用例應(yīng)該按照增刪改的順序進(jìn)行安排，這樣執(zhí)行的時(shí)候效率比較高，避免不必要的重復(fù)測試，用例寫完不是就ok了，我們最好通讀2遍，進(jìn)行修改，讓單條用例流暢。

（測試用例的清晰性）測試用例的驗(yàn)證點(diǎn)必須明確清晰重點(diǎn)突出，按照最新的用例標(biāo)準(zhǔn)，一個(gè)用例進(jìn)行一個(gè)功能點(diǎn)的驗(yàn)證，一個(gè)蘿卜一個(gè)坑。對于流程性的用例也是建議按照流程順序進(jìn)行用例安排，從第一個(gè)驗(yàn)證點(diǎn)到最后一個(gè)驗(yàn)證點(diǎn)，組成流程的開始到結(jié)束，方便測試執(zhí)行。測試用例包含前置條件的必須將前置條件描述清楚，包括入口等。

（測試用例的可維護(hù)性）我們的用例主要是基于web的，用例存在一定的變數(shù)。

因此在測試用例因?yàn)闃I(yè)務(wù)需求發(fā)生變更的時(shí)候，請及時(shí)修改，維護(hù)測試用例，做到測試用例的實(shí)時(shí)性與有效性，同時(shí)也方便后來的新人同學(xué)及時(shí)學(xué)習(xí)，不會(huì)產(chǎn)生誤解與費(fèi)解。

Ross Collard在”Use Case Testing”一文中說：“測試用例的前10%到15%可以發(fā)現(xiàn)75%到90%的重要缺陷”。如果你在項(xiàng)目或者日常結(jié)束后，仔細(xì)的分析過我們的bug列表，那么你會(huì)覺的這句話非常適用。合理提高我們的測試效率就是在編寫測試用例時(shí)進(jìn)行測試用例優(yōu)先級的劃分。

1．用于冒煙測試的用例為最高優(yōu)先級

2．把基本路徑以及各模塊主功能的測試標(biāo)注為高優(yōu)先級別

3．把你所有錯(cuò)誤和邊界值或確認(rèn)測試標(biāo)注為中優(yōu)先級別

4．把可用性測試以及入口默認(rèn)值校驗(yàn)等標(biāo)注為低優(yōu)先級別。

5．將功能測試用例分為嚴(yán)重和不嚴(yán)重兩類，對于不嚴(yán)重的功能測試用例降級為低優(yōu)先級用例。

幾點(diǎn)建議：

1．你是否感覺測試的時(shí)候思維很混亂，或者總感覺有些功能沒有測到，而一些功能已經(jīng)測過好幾遍？請明確你的需求，是否做到覆蓋100%。你的用例優(yōu)先級是否設(shè)置的合理。

2．在測試時(shí)間緊迫的情況下，你不知道要測什么，或者要先測試那些功能？那么你需要調(diào)整自己用例的優(yōu)先級，順帶回去好好整理整理需求。

3．在編寫測試用例的時(shí)候優(yōu)先去學(xué)習(xí)，老人們優(yōu)秀的做法。在學(xué)習(xí)別人優(yōu)秀成果的基礎(chǔ)上，編寫自己的用例。

構(gòu)造樸實(shí)的測試用例

測試用例這種東西對于剛?cè)胄械娜藖碚f是一種誘惑，初入測試的人急于掌握這門學(xué)問，所以一開始就會(huì)問測試用例怎么寫，問的同時(shí)或許還包含了一些期望。其實(shí)測試用例就是一個(gè)測試矩陣，任何人沒有必要注重形式問題，如果你現(xiàn)在或者未來的公司有套非常完善的文檔管理體系，那么你可以參考標(biāo)準(zhǔn)模版，如果沒有你們大可跟我一樣使用下面的格式：

-----------

-ID-ACT-DATA-EXPECTED-ACTUAL-T/F-DATE

-----------

我認(rèn)為沒有什么問題，ID代表標(biāo)號（如果你愿意可以用這個(gè)ID對應(yīng)需求文檔的ID或者使用詳細(xì)設(shè)計(jì)的文檔的ID，間接連接需求），ACT代表一種動(dòng)作，因?yàn)闇y試動(dòng)作非常復(fù)雜，如果手動(dòng)執(zhí)行或者自動(dòng)執(zhí)行，或者或者是一種異常狀態(tài)都可以占用此位置，但是注意不能使用性能、數(shù)據(jù)或者安全測試替代，為什么請各位自己考慮。DATA代表數(shù)據(jù)，很多的測試類書籍中雖然沒有直接講明測試數(shù)據(jù)的劃分，但是通常我們引用三種數(shù)據(jù)“正常”、“異常”、“錯(cuò)誤”，分別對應(yīng)關(guān)鍵字“PASS”、“ERROR”、“FAIL”，對于數(shù)據(jù)的劃分我以前曾經(jīng)說過這里不再細(xì)談，為什么會(huì)在一個(gè)文檔中體現(xiàn)著點(diǎn)，主要是為了以后數(shù)據(jù)程序化作接口，一個(gè)不能將手動(dòng)測試轉(zhuǎn)為自動(dòng)測試的人員注定是平庸的。EXPECTED、ACTUAL分別代表期望和實(shí)際，我們做這一行的經(jīng)常對這兩種值的差異感到困惑，是不是“正常”、“異常”、“錯(cuò)誤”就看個(gè)人的經(jīng)驗(yàn)了。T/F的引入是因?yàn)橛羞@樣的一種情況介入，如果EXPECTED、ACTUAL是不同的，但是我們還是要給個(gè)T，因?yàn)閷τ趩雾?xiàng)的是否通過測試人員有著使用權(quán)，但決定權(quán)在于市場或者高層決策。DATE是一種好習(xí)慣，通常記為發(fā)現(xiàn)“PASS”、“ERROR”、“FAIL”的時(shí)間，很多人會(huì)忽略這個(gè)值，當(dāng)然對于我們來說沒什么損失，對于QA團(tuán)隊(duì)來說，僅僅提供給他們T/F是不夠的。

我覺得這就是一種構(gòu)造樸實(shí)的測試用例的方式，不要過于在意一份文檔的表現(xiàn)形式，如果你有很多的時(shí)間，如果你一年才寫一個(gè)這樣的文檔，那么你可以從互聯(lián)網(wǎng)上下在很多的資源把這份文檔修飾的像APPLE一樣。

入行的人員會(huì)更進(jìn)一步的發(fā)揮測試偏執(zhí)狂的能力，這時(shí)候他們急需一種數(shù)量，例如：我們一個(gè)動(dòng)態(tài)庫的測試用例就有3000多個(gè)厲害吧？厲害，我當(dāng)然說你厲害，你難道不厲害嗎？我記得有個(gè)500強(qiáng)的面試題就是你能為LOGIN動(dòng)作寫多少的測試用例？我想了半天我說就三個(gè)，或者四個(gè)，在聽到了一聲深深嘆息后，我惶恐的說大概我能寫5個(gè)吧？！當(dāng)然我自己也沒底，我就能寫出三個(gè)。LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL，所有的測試用例就是他們的衍生，一種本源的問題。我們繼續(xù)討論3000多個(gè)測試用例的事

情，有人明眼就會(huì)說：這家伙肯定是微軟的，沒錯(cuò)，除了這種大公司有了充足的資源和技術(shù)支持，哪家公司能跟他們一樣呢？當(dāng)然了，寫3000個(gè)我想入行久了誰都可以，并且跟你對系統(tǒng)的熟悉程度，工作經(jīng)驗(yàn)有莫大的關(guān)系，但是這里我又想說說關(guān)于構(gòu)造樸實(shí)的測試用例的問題了。

單元測試、集成測試這些說明的是測試范圍，功能測試、性能測試這些說明的是測試的手段，也可以這樣說某個(gè)功能測試包含了若干個(gè)功能測試也內(nèi)隱含了若干個(gè)單元測試的聯(lián)動(dòng)，當(dāng)你開始測試的時(shí)候，實(shí)際上最終是對代碼設(shè)定路徑的一種驗(yàn)算，如果我們都生活在單線程、無UI的年代你可以更清楚的看到

“PASS”、“ERROR”、“FAIL”三種狀態(tài)，可我們已經(jīng)錯(cuò)過了這個(gè)年代，我們有了包裝的UI，有了封裝的API，有了各種各樣的MESSAGE，所以你就要承受更多ERROR的打擊。這個(gè)時(shí)候有人就會(huì)通過增加測試用例的數(shù)量來回避這些陷阱，出發(fā)點(diǎn)是好的做法是累死人的，如果你愿意你可以為機(jī)器碼寫1億個(gè)測試用例，如果你還是很偏執(zhí)，你可以為門電路寫上1萬億個(gè)測試用例，你有命執(zhí)行嗎？

我通常不愿意寫太多的測試用例，很多人認(rèn)為我工作態(tài)度有問題，我認(rèn)為這更能說明我的態(tài)度：我愿意樸實(shí)的構(gòu)造我的測試用例，但是我有原則來保證我的測試用例：

1、接到任務(wù)不急于作而在于多思考，首先在紙上構(gòu)造一個(gè)大致的業(yè)務(wù)流圖

2、流圖構(gòu)造好，快速剔除公用的測試用例

3、構(gòu)造測試用例先寫符合主路徑的三種“PASS”、“ERROR”、“FAIL”

4、精化測試用例努力為ERROR多構(gòu)造1-7種假設(shè)

5、執(zhí)行測試用例強(qiáng)化FAIL的標(biāo)準(zhǔn)化失敗輸出，但是對應(yīng)減少PASS測試用例

6、進(jìn)一步精化測試用例，使“PASS”、“ERROR”、“FAIL”所占的比例分別為%20、%70、%10如果我還是測試，我將繼續(xù)我的樸實(shí)理論，多出來的安全時(shí)間我可以看看藍(lán)天享受享受生活！

測試用例編寫的“侯式標(biāo)準(zhǔn)”

作為軟件測試人員，執(zhí)行測試用例是我們進(jìn)行測試工作的主要手段，測試用例設(shè)計(jì)的好壞，直接影響著測試工作的質(zhì)量。一個(gè)“好”的測試用例能保證測試的質(zhì)量，規(guī)范測試的進(jìn)程，進(jìn)而提高我們的測試效率。那什么樣的用例才是好的測試用例？這已經(jīng)是一個(gè)老生常談的問題，大家見仁見智，眾說云云，不一而足。

而我的TL–候風(fēng)的一句話，讓我對用例的有了新的認(rèn)識。他是這樣說的：一個(gè)好的測試用例，就是在保證測試質(zhì)量的前提下，做到以下幾點(diǎn)：當(dāng)一個(gè)不熟悉業(yè)務(wù)的人，看到你的用例后，要知道用例的測試目的什么，知道你要做什么，怎么做，為什么這樣做，取得了什么什么成果。

做什么？

做任何事情，都要有的放矢。我們在編寫一個(gè)測試用例的時(shí)候，應(yīng)該知道我們要的是什么，這也是編寫一個(gè)用例最基本的前提。

怎么做？

即具體的如何設(shè)計(jì)用例。就是要明確用例的執(zhí)行過程，這樣在測試的時(shí)候才能有章可循，摸著石頭過河

為什么這樣做？

這要求用例編寫者要明確設(shè)計(jì)用例時(shí)用到的方法（如邊界值，等價(jià)類等等），以及用這種方法的好處。取得了什么成果？

這要求用例編寫者明確通過這個(gè)測試用例,我們將取得什么效果。比如一個(gè)采用邊界值設(shè)計(jì)的用例，取得的效果是在極端的數(shù)據(jù)下，軟件是否能夠正常執(zhí)行功能。

標(biāo)準(zhǔn)規(guī)范中包含的主要元素如下：

1測試名稱(Test Name)：測試用例編號和測試用例名稱。

2創(chuàng)建日期(Creation Date)：測試用例創(chuàng)建時(shí)間，系統(tǒng)自動(dòng)產(chǎn)生。

3設(shè)計(jì)人員(Designer)：測試用例設(shè)計(jì)人員

4狀態(tài)(Status)：測試用例狀態(tài)

5描述（Descrīption）：測試用例詳細(xì)描述

6步驟名稱（Step Name）：測試步驟名稱

7步驟描述（Step Descrīption）：測試步驟詳細(xì)描述。

8預(yù)期結(jié)果（Expected Result）：測試預(yù)期結(jié)果

要是按照“候風(fēng)標(biāo)準(zhǔn)”（暫且這樣命名，還沒申請侯哥批準(zhǔn)），我們要對上面的標(biāo)準(zhǔn)進(jìn)行規(guī)范的優(yōu)化以及內(nèi)容的明確

1測試名稱

A）用例根據(jù)各用例的功能來命名，盡量做到簡潔明了。

B）一級目錄使用各項(xiàng)目的頂級菜單名稱來命名，如功能、業(yè)務(wù)、查詢?nèi)箢悾?/p>

C）二級目錄使用頂級菜單下的二級菜單名稱類命名，用戶可根據(jù)名字判別該用例是測試哪個(gè)模塊的。2 描述（Descrīption）：測試用例詳細(xì)描述

要用通俗易懂而又簡潔的語言描述描述用例的設(shè)計(jì)目的，讓其他人能夠明白我們在什么步驟描述

步驟描述要詳細(xì)而不臃腫，條理而不凌亂。

同時(shí)，在規(guī)范上要增加以下幾項(xiàng)

1測試目的（Purpose）：編寫這個(gè)測試用例的目的2測試方法選擇依據(jù)（Foundation）：即用這樣方法的好處

3測試取得的成果（Achievement）：通過執(zhí)行用例取得的成果

4用例執(zhí)行的前提條件（Precondition）：執(zhí)行用例的需要滿足的前提

這樣，一個(gè)完整的用例包含的元素如下：

1測試名稱(Test Name)測試目的（Purpose）測試方法選擇依據(jù)（Foundation）用例執(zhí)行的前提條件（Precondition）

5創(chuàng)建日期(Creation Date)

6設(shè)計(jì)人員(Designer)

7狀態(tài)(Status)

8描述（Descrīption）

9步驟名稱（Step Name）

10步驟描述（Step Descrīption）

11預(yù)期結(jié)果（Expected Result）測試取得的成果（Achievement）

.綜上所述，測試用例的“侯式標(biāo)準(zhǔn)”的精髓，就是把自己的思維過程盡可能的展現(xiàn)到用例中，做到即使一個(gè)完全不懂業(yè)務(wù)的人，看到我們的用例后，也能知道業(yè)務(wù)的需求和流程，知道測試的過程，能夠無障礙的執(zhí)行我們的用例。

以上是我學(xué)習(xí)用例編寫過程中的一些體會(huì)，不足之處請大家批評指正。讓我們一起交流分享，共同進(jìn)步成長。

第四篇：編寫測試用例和測試計(jì)劃

第六章 編寫測試用例和測試計(jì)劃

主要內(nèi)容：軟件測試計(jì)劃；軟件測試方案；軟件風(fēng)險(xiǎn)分析

1.軟件測試計(jì)劃

1.1 軟件測試計(jì)劃的簡介

1測試計(jì)劃概念：測試計(jì)劃在測試中處于中心位置，它闡述了測試準(zhǔn)備工作和執(zhí)行測試的必要條件，同時(shí)也形成了測試過程質(zhì)量保證的基礎(chǔ)。

2測試計(jì)劃的作用：組織和管理測試；使測試工作和整個(gè)開發(fā)工作整合起來；資源和變更事先最為一個(gè)可控制的風(fēng)險(xiǎn)。

1.2 如何編寫軟件測試計(jì)劃

1認(rèn)識測試項(xiàng)目不僅僅只有單一測試計(jì)劃

2避免不分析直接進(jìn)行測試階段日程安排

3避免測試任務(wù)的安排超前于開發(fā)任務(wù)

4避免有些系統(tǒng)測試類型無法按期進(jìn)入測試

5不正確的變更測試計(jì)劃

6測試計(jì)劃里明確更新周期和暫停測試原則

7測試計(jì)劃不是一成不變的1.3 測試計(jì)劃包括：簡介，目的，范圍，測試策略，進(jìn)度，缺陷的嚴(yán)重程度的定義，風(fēng)

險(xiǎn)分析。

2.軟件測試方案

2.1 軟件測試方案的概念

軟件測試方案描述測試的特征，測試的方法，測試環(huán)境的規(guī)劃，測試工具的設(shè)計(jì)和選擇，測試用例的設(shè)計(jì)方法，測試代碼的設(shè)計(jì)方案。即包括以下幾點(diǎn)：

? 明確測試策略（黑盒，白盒，灰盒等）

? 細(xì)化測試特征

? 測試用例的規(guī)劃

? 測試環(huán)境的規(guī)劃

? 自動(dòng)化測試框架的設(shè)計(jì)

? 測試工具的設(shè)計(jì)和選擇

2.2 軟件測試計(jì)劃于軟件測試方案的區(qū)別

? 測試計(jì)劃是組織管理層面的文檔。測試方案是技術(shù)層面的文檔。

? 測試方案需要在測試計(jì)劃的指導(dǎo)下進(jìn)行，測試計(jì)劃提出“做什么”，測試方案明確“怎么做”

? 回報(bào)的對象不同，測試計(jì)劃向領(lǐng)導(dǎo)匯報(bào)，測試方案是組員共享該文檔

3.軟件測試的風(fēng)險(xiǎn)

? 軟件需求風(fēng)險(xiǎn)

? 人員的風(fēng)險(xiǎn)

? 測試環(huán)境的風(fēng)險(xiǎn)

? 測試工程師對產(chǎn)品的業(yè)務(wù)不熟悉

補(bǔ)充：

回歸測試：把以前檢查過的已經(jīng)修復(fù)好的缺陷，拿來另測看有無帶來新的缺陷 反側(cè)：把開發(fā)人員已經(jīng)處理的缺陷拿來測，看是否修復(fù)

第五篇：測試用例的編寫總結(jié)

在網(wǎng)上看到這篇文章很好，和大家分享一下：

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

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

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

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

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

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

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

在我測試工作中，碰上的測試類型我自己劃分成這么４種：項(xiàng)目的測試，產(chǎn)品的測試，產(chǎn)品個(gè)性化的測試，第三方驗(yàn)收測試。項(xiàng)目的測試指的是我所測試的軟件是一個(gè)項(xiàng)目，是某一個(gè)具體用戶使用的。產(chǎn)品的測試指的是我所測試的軟件是一個(gè)通用產(chǎn)品，是供很多用戶使用的。產(chǎn)品個(gè)性化測試指的是我所測試的軟件是某一用戶在使用產(chǎn)品時(shí)，提出了特殊的功能，針對這些新功能，對產(chǎn)品針對用戶進(jìn)行了個(gè)別修改。第三方驗(yàn)收測試大家都應(yīng)該很熟悉了，這里就不需要做解釋了。

對項(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à)值的bug通常不是在寫測試用例的時(shí)候發(fā)現(xiàn)的，而是在測試軟件的過程中，我在家睡覺前的思考和回家的路上思考出來的。這就是手動(dòng)測試的魅力，有些軟件的缺陷是在你使用軟件的一瞬間和思考的一剎那突然發(fā)現(xiàn)的。所以要我回答測試用例要寫到什么程度才比較好，我覺的只要你所寫的測試用例在你的公司能夠順利的執(zhí)行，不影響你的測試執(zhí)行工作就可以了。因?yàn)闇y試用例寫的太詳細(xì)，你要花費(fèi)時(shí)間和人力成本，這樣出來的測試用例是最好的也是最貴的，一旦需求變更，也需要修改，這時(shí)你會(huì)發(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è)問題了，我盡量少寫些，文字太多了大家看的也累，我寫的也累。嘿嘿。^_^

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

我的體會(huì)：

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

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

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

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

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