【正文】 清楚，包括入口等。因此在測試用例因為業(yè)務(wù)需求發(fā)生變更的時候，請及時修改，維護(hù)測試用例，做到測試用例的實時性與有效性，同時也方便后來的新人同學(xué)及時學(xué)習(xí)，不會產(chǎn)生誤解與費(fèi)解。如果你在項目或者日常結(jié)束后，仔細(xì)的分析過我們的bug列表，那么你會覺的這句話非常適用。1．用于冒煙測試的用例為最高優(yōu)先級2．把基本路徑以及各模塊主功能的測試標(biāo)注為高優(yōu)先級別3．把你所有錯誤和邊界值或確認(rèn)測試標(biāo)注為中優(yōu)先級別4．把可用性測試以及入口默認(rèn)值校驗等標(biāo)注為低優(yōu)先級別。幾點(diǎn)建議：1．你是否感覺測試的時候思維很混亂，或者總感覺有些功能沒有測到，而一些功能已經(jīng)測過好幾遍？請明確你的需求，是否做到覆蓋100%。2．在測試時間緊迫的情況下，你不知道要測什么，或者要先測試那些功能？那么你需要調(diào)整自己用例的優(yōu)先級，順帶回去好好整理整理需求。在學(xué)習(xí)別人優(yōu)秀成果的基礎(chǔ)上，編寫自己的用例。其實測試用例就是一個測試矩陣，任何人沒有必要注重形式問題，如果你現(xiàn)在或者未來的公司有套非常完善的文檔管理體系，那么你可以參考標(biāo)準(zhǔn)模版，如果沒有你們大可跟我一樣使用下面的格式：IDACTDATAEXPECTEDACTUALT/FDATE我認(rèn)為沒有什么問題，ID代表標(biāo)號（如果你愿意可以用這個ID對應(yīng)需求文檔的ID或者使用詳細(xì)設(shè)計的文檔的ID，間接連接需求），ACT代表一種動作，因為測試動作非常復(fù)雜，如果手動執(zhí)行或者自動執(zhí)行，或者或者是一種異常狀態(tài)都可以占用此位置，但是注意不能使用性能、數(shù)據(jù)或者安全測試替代，為什么請各位自己考慮。EXPECTED、ACTUAL分別代表期望和實際，我們做這一行的經(jīng)常對這兩種值的差異感到困惑，是不是“正常”、“異常”、“錯誤”就看個人的經(jīng)驗了。DATE是一種好習(xí)慣，通常記為發(fā)現(xiàn)“PASS”、“ERROR”、“FAIL”的時間，很多人會忽略這個值，當(dāng)然對于我們來說沒什么損失，對于QA團(tuán)隊來說，僅僅提供給他們T/F是不夠的。入行的人員會更進(jìn)一步的發(fā)揮測試偏執(zhí)狂的能力，這時候他們急需一種數(shù)量，例如：我們一個動態(tài)庫的測試用例就有3000多個厲害吧？厲害，我當(dāng)然說你厲害，你難道不厲害嗎？我記得有個500強(qiáng)的面試題就是你能為LOGIN動作寫多少的測試用例？我想了半天我說就三個，或者四個，在聽到了一聲深深嘆息后，我惶恐的說大概我能寫5個吧？！當(dāng)然我自己也沒底，我就能寫出三個。我們繼續(xù)討論3000多個測試用例的事情，有人明眼就會說：這家伙肯定是微軟的，沒錯，除了這種大公司有了充足的資源和技術(shù)支持，哪家公司能跟他們一樣呢？當(dāng)然了，寫3000個我想入行久了誰都可以，并且跟你對系統(tǒng)的熟悉程度，工作經(jīng)驗有莫大的關(guān)系，但是這里我又想說說關(guān)于構(gòu)造樸實的測試用例的問題了。這個時候有人就會通過增加測試用例的數(shù)量來回避這些陷阱，出發(fā)點(diǎn)是好的做法是累死人的，如果你愿意你可以為機(jī)器碼寫1億個測試用例，如果你還是很偏執(zhí)，你可以為門電路寫上1萬億個測試用例，你有命執(zhí)行嗎？我通常不愿意寫太多的測試用例，很多人認(rèn)為我工作態(tài)度有問題，我認(rèn)為這更能說明我的態(tài)度：我愿意樸實的構(gòu)造我的測試用例，但是我有原則來保證我的測試用例：接到任務(wù)不急于作而在于多思考，首先在紙上構(gòu)造一個大致的業(yè)務(wù)流圖流圖構(gòu)造好，快速剔除公用的測試用例構(gòu)造測試用例先寫符合主路徑的三種“PASS”、“ERROR”、“FAIL”精化測試用例努力為ERROR多構(gòu)造17種假設(shè)執(zhí)行測試用例強(qiáng)化FAIL的標(biāo)準(zhǔn)化失敗輸出，但是對應(yīng)減少PASS測試用例進(jìn)一步精化測試用例，使“PASS”、“ERROR”、“FAIL”所占的比例分別為%%70、%10如果我還是測試，我將繼續(xù)我的樸實理論，多出來的安全時間我可以看看藍(lán)天享受享受生活！測試用例編寫的“侯式標(biāo)準(zhǔn)”作為軟件測試人員，執(zhí)行測試用例是我們進(jìn)行測試工作的主要手段，測試用例設(shè)計的好壞，直接影響著測試工作的質(zhì)量。那什么樣的用例才是好的測試用例？這已經(jīng)是一個老生常談的問題，大家見仁見智，眾說云云，不一而足。他是這樣說的：一個好的測試用例，就是在保證測試質(zhì)量的前提下，做到以下幾點(diǎn)：當(dāng)一個不熟悉業(yè)務(wù)的人，看到你的用例后，要知道用例的測試目的什么，知道你要做什么，怎么做，為什么這樣做，取得了什么什么成果。我們在編寫一個測試用例的時候，應(yīng)該知道我們要的是什么，這也是編寫一個用例最基本的前提。就是要明確用例的執(zhí)行過程，這樣在測試的時候才能有章可循，摸著石頭過河為什么這樣做？這要求用例編寫者要明確設(shè)計用例時用到的方法（如邊界值，等價類等等），以及用這種方法的好處。比如一個采用邊界值設(shè)計的用例，取得的效果是在極端的數(shù)據(jù)下，軟件是否能夠正常執(zhí)行功能。2創(chuàng)建日期(Creation Date)：測試用例創(chuàng)建時間，系統(tǒng)自動產(chǎn)生。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ù)各用例的功能來命名，盡量做到簡潔明了。2 描述（Descrīption）：測試用例詳細(xì)描述要用通俗易懂而又簡潔的語言描述描述用例的設(shè)計目的，讓其他人能夠明白我們在什么步驟描述步驟描述要詳細(xì)而不臃腫，條理而不凌亂。以上是我學(xué)習(xí)用例編寫過程中的一些體會，不足之處請大家批評指正。第三篇：編寫測試用例和測試計劃第六章 編寫測試用例和測試計劃主要內(nèi)容：軟件測試計劃；軟件測試方案；軟件風(fēng)險分析 軟件測試計劃的簡介1測試計劃概念：測試計劃在測試中處于中心位置，它闡述了測試準(zhǔn)備工作和執(zhí)行測試的必要條件，同時也形成了測試過程質(zhì)量保證的基礎(chǔ)。 如何編寫軟件測試計劃1認(rèn)識測試項目不僅僅只有單一測試計劃2避免不分析直接進(jìn)行測試階段日程安排3避免測試任務(wù)的安排超前于開發(fā)任務(wù)4避免有些系統(tǒng)測試類型無法按期進(jìn)入測試5不正確的變更測試計劃6測試計劃里明確更新周期和暫停測試原則 測試計劃包括：簡介