【正文】 例的規(guī)劃178。 軟件測試方案的概念軟件測試方案描述測試的特征，測試的方法，測試環(huán)境的規(guī)劃，測試工具的設(shè)計和選擇，測試用例的設(shè)計方法，測試代碼的設(shè)計方案。讓我們一起交流分享，共同進步成長。B）一級目錄使用各項目的頂級菜單名稱來命名，如功能、業(yè)務(wù)、查詢?nèi)箢?；C）二級目錄使用頂級菜單下的二級菜單名稱類命名，用戶可根據(jù)名字判別該用例是測試哪個模塊的。標準規(guī)范中包含的主要元素如下：1測試名稱(Test Name)：測試用例編號和測試用例名稱。怎么做？即具體的如何設(shè)計用例。而我的TL–候風的一句話，讓我對用例的有了新的認識。單元測試、集成測試這些說明的是測試范圍，功能測試、性能測試這些說明的是測試的手段，也可以這樣說某個功能測試包含了若干個功能測試也內(nèi)隱含了若干個單元測試的聯(lián)動，當你開始測試的時候，實際上最終是對代碼設(shè)定路徑的一種驗算，如果我們都生活在單線程、無UI的年代你可以更清楚的看到“PASS”、“ERROR”、“FAIL”三種狀態(tài)，可我們已經(jīng)錯過了這個年代，我們有了包裝的UI，有了封裝的API，有了各種各樣的MESSAGE，所以你就要承受更多ERROR的打擊。我覺得這就是一種構(gòu)造樸實的測試用例的方式，不要過于在意一份文檔的表現(xiàn)形式，如果你有很多的時間，如果你一年才寫一個這樣的文檔，那么你可以從互聯(lián)網(wǎng)上下在很多的資源把這份文檔修飾的像APPLE一樣。DATA代表數(shù)據(jù)，很多的測試類書籍中雖然沒有直接講明測試數(shù)據(jù)的劃分，但是通常我們引用三種數(shù)據(jù)“正?！薄ⅰ爱惓！?、“錯誤”，分別對應(yīng)關(guān)鍵字“PASS”、“ERROR”、“FAIL”，對于數(shù)據(jù)的劃分我以前曾經(jīng)說過這里不再細談，為什么會在一個文檔中體現(xiàn)著點，主要是為了以后數(shù)據(jù)程序化作接口，一個不能將手動測試轉(zhuǎn)為自動測試的人員注定是平庸的。3．在編寫測試用例的時候優(yōu)先去學(xué)習(xí)，老人們優(yōu)秀的做法。5．將功能測試用例分為嚴重和不嚴重兩類，對于不嚴重的功能測試用例降級為低優(yōu)先級用例。Ross Collard在”Use Case Testing”一文中說：“測試用例的前10%到15%可以發(fā)現(xiàn)75%到90%的重要缺陷”。對于流程性的用例也是建議按照流程順序進行用例安排，從第一個驗證點到最后一個驗證點，組成流程的開始到結(jié)束，方便測試執(zhí)行。對于預(yù)期的結(jié)果不能僅僅是頁面上或者界面上的可見結(jié)果，如果和數(shù)據(jù)庫發(fā)生了交互，必須包含數(shù)據(jù)庫里準確的驗證結(jié)果。也就是說拿到需求文檔必須進行必要的分析，不能上來就盲目的寫用例，新人尤其應(yīng)該注意。把基本路徑分解出來，將需求歸類。５、即使對測試很熟悉了，在時間非常緊的時候，編寫測試用例還是很有必要和好處的。如：業(yè)務(wù)流程測試、安裝測試、功能測試、用戶友好性測試、兼容性測試、性能測試、安全性測試等等。說了這么多，不知道這樣的回答是否是回答了這個問題。測試大綱更多的是把握住測試項的方向，而測試用例是指導(dǎo)怎么去執(zhí)行測試。模板找好了，可是寫就費勁了。就像小孩子學(xué)習(xí)寫字一樣。為此，我經(jīng)常上網(wǎng)查測試的資料，看看自己到底適合不適合做測試，測試到底是什么樣的一個職業(yè)，怎么去規(guī)劃自己的個人發(fā)展。第二個問題，剛開始做測試的時候，你是怎么學(xué)習(xí)寫測試用例的？我之所以選擇測試這個工作是因為：我畢業(yè)后，在第一家公司做技術(shù)支持，產(chǎn)品的問題很多，導(dǎo)致技術(shù)支持工作很辛苦、很累。所以要我回答測試用例要寫到什么程度才比較好，我覺的只要你所寫的測試用例在你的公司能夠順利的執(zhí)行，不影響你的測試執(zhí)行工作就可以了?？上宜诘墓荆紱]有人來看我的測試用例。由于時間關(guān)系，測試用例都是先寫重點的業(yè)務(wù)，也就是集成測試的測試用例。我所在的公司，通常項目開發(fā)時間都很短４到５個月，然而測試通常都是在開發(fā)即將結(jié)束的時候才真正介入。產(chǎn)品的測試指的是我所測試的軟件是一個通用產(chǎn)品，是供很多用戶使用的。第一篇：測試用例的編寫總結(jié)在網(wǎng)上看到這篇文章很好，和大家分享一下：在我的個人郵箱和MSN上，通常同行都問我類似下面這樣的問題：１、一個測試用例要寫到什么程度才比較好?２、剛開始做測試的時候，你是怎么學(xué)習(xí)寫測試用例的？３、你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？對于測試用例，而我目前正在思考的問題是：怎么寫出對公司有價值的測試用例，對公司來說，怎么測試才是最有價值的測試？下面先來分析第一個問題吧：一個測試用例要寫到什么程度才比較好？這個問題，沒有定語，沒有說是在什么樣的一個情況下，因此我這里只能就我工作中碰到的情況說說了。項目的測試指的是我所測試的軟件是一個項目，是某一個具體用戶使用的。對項目、產(chǎn)品的測試，測試的時候通常要考慮這個項目的周期和測試資源。為此在這種情況下，我都是先熟悉系統(tǒng)的業(yè)務(wù)，把握重點業(yè)務(wù)和功能后，參考需求，把測試需求、測試計劃和測試大綱給制定好。由于測試用例是本人執(zhí)行，所以測試用例可以寫的簡單些，但是一定要開發(fā)人員能夠看明白。這就是手動測試的魅力，有些軟件的缺陷是在你使用軟件的一瞬間和思考的一剎那突然發(fā)現(xiàn)的。這也不是好的方法。對測試，大家都認為不就是拿個鼠標點來點去，誰都可以來做。現(xiàn)在想想自己剛開始寫測試用例的時候，真是好笑。還好，公司沒有嚴格要求必須要那個模板，只要適用就行。沒有辦法，那時候沒有人指導(dǎo)我，全靠自己自學(xué)和領(lǐng)悟，所以那段日子很苦阿！多寫幾次后，就知道和領(lǐng)悟了，測試用例要根據(jù)測試大綱來寫，測試大綱要根據(jù)測試計劃來寫。這也是我一點一點的領(lǐng)悟出來的。^_^你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？我的體會：１、測試用例要根據(jù)測試大綱來編寫２、測試用例也要分測試項進行歸類，這樣比較好分析和閱讀。４、熟悉系統(tǒng)，對編寫測試用例很有幫助。一個好的方法就是用mm圖把需求分解了。做到對需求的100%覆蓋。（但是輸入數(shù)據(jù)又涉及到了維護的問題，以及環(huán)境或者業(yè)務(wù)發(fā)生變更后引起的有效性問題）。（測試用例的清晰性）測試用例的驗證點必須明確清晰重點突出，按照最新的用例標準，一個用例進行一個功能點的驗證，一個蘿卜一個坑。因此