【正文】 看我們的基線庫(kù)更多的是這樣指導(dǎo)意義的用例。（但是輸入數(shù)據(jù)又涉及到了維護(hù)的問題，以及環(huán)境或者業(yè)務(wù)發(fā)生變更后引起的有效性問題）。對(duì)于預(yù)期的結(jié)果不能僅僅是頁(yè)面上或者界面上的可見結(jié)果，如果和數(shù)據(jù)庫(kù)發(fā)生了交互，必須包含數(shù)據(jù)庫(kù)里準(zhǔn)確的驗(yàn)證結(jié)果。用例基于數(shù)據(jù)驅(qū)動(dòng)。（測(cè)試用例的可理解性）測(cè)試用例步驟必須描述清晰，不能出現(xiàn)模棱兩可以及重復(fù)的話語，測(cè)試用例應(yīng)該按照增刪改的順序進(jìn)行安排，這樣執(zhí)行的時(shí)候效率比較高，避免不必要的重復(fù)測(cè)試，用例寫完不是就ok了，我們最好通讀2遍，進(jìn)行修改，讓單條用例流暢。（測(cè)試用例的清晰性）測(cè)試用例的驗(yàn)證點(diǎn)必須明確清晰重點(diǎn)突出，按照最新的用例標(biāo)準(zhǔn)，一個(gè)用例進(jìn)行一個(gè)功能點(diǎn)的驗(yàn)證，一個(gè)蘿卜一個(gè)坑。對(duì)于流程性的用例也是建議按照流程順序進(jìn)行用例安排，從第一個(gè)驗(yàn)證點(diǎn)到最后一個(gè)驗(yàn)證點(diǎn)，組成流程的開始到結(jié)束，方便測(cè)試執(zhí)行。測(cè)試用例包含前置條件的必須將前置條件描述清楚，包括入口等。（測(cè)試用例的可維護(hù)性）我們的用例主要是基于web的，用例存在一定的變數(shù)。因此在測(cè)試用例因?yàn)闃I(yè)務(wù)需求發(fā)生變更的時(shí)候，請(qǐng)及時(shí)修改，維護(hù)測(cè)試用例，做到測(cè)試用例的實(shí)時(shí)性與有效性，同時(shí)也方便后來的新人同學(xué)及時(shí)學(xué)習(xí)，不會(huì)產(chǎn)生誤解與費(fèi)解。Ross Collard在”Use Case Testing”一文中說：“測(cè)試用例的前10%到15%可以發(fā)現(xiàn)75%到90%的重要缺陷”。如果你在項(xiàng)目或者日常結(jié)束后，仔細(xì)的分析過我們的bug列表，那么你會(huì)覺的這句話非常適用。合理提高我們的測(cè)試效率就是在編寫測(cè)試用例時(shí)進(jìn)行測(cè)試用例優(yōu)先級(jí)的劃分。1．用于冒煙測(cè)試的用例為最高優(yōu)先級(jí)2．把基本路徑以及各模塊主功能的測(cè)試標(biāo)注為高優(yōu)先級(jí)別3．把你所有錯(cuò)誤和邊界值或確認(rèn)測(cè)試標(biāo)注為中優(yōu)先級(jí)別4．把可用性測(cè)試以及入口默認(rèn)值校驗(yàn)等標(biāo)注為低優(yōu)先級(jí)別。5．將功能測(cè)試用例分為嚴(yán)重和不嚴(yán)重兩類，對(duì)于不嚴(yán)重的功能測(cè)試用例降級(jí)為低優(yōu)先級(jí)用例。幾點(diǎn)建議：1．你是否感覺測(cè)試的時(shí)候思維很混亂，或者總感覺有些功能沒有測(cè)到，而一些功能已經(jīng)測(cè)過好幾遍？請(qǐng)明確你的需求，是否做到覆蓋100%。你的用例優(yōu)先級(jí)是否設(shè)置的合理。2．在測(cè)試時(shí)間緊迫的情況下，你不知道要測(cè)什么，或者要先測(cè)試那些功能？那么你需要調(diào)整自己用例的優(yōu)先級(jí)，順帶回去好好整理整理需求。3．在編寫測(cè)試用例的時(shí)候優(yōu)先去學(xué)習(xí)，老人們優(yōu)秀的做法。在學(xué)習(xí)別人優(yōu)秀成果的基礎(chǔ)上，編寫自己的用例。構(gòu)造樸實(shí)的測(cè)試用例測(cè)試用例這種東西對(duì)于剛?cè)胄械娜藖碚f是一種誘惑，初入測(cè)試的人急于掌握這門學(xué)問，所以一開始就會(huì)問測(cè)試用例怎么寫，問的同時(shí)或許還包含了一些期望。其實(shí)測(cè)試用例就是一個(gè)測(cè)試矩陣，任何人沒有必要注重形式問題，如果你現(xiàn)在或者未來的公司有套非常完善的文檔管理體系，那么你可以參考標(biāo)準(zhǔn)模版，如果沒有你們大可跟我一樣使用下面的格式：IDACTDATAEXPECTEDACTUALT/FDATE我認(rèn)為沒有什么問題，ID代表標(biāo)號(hào)（如果你愿意可以用這個(gè)ID對(duì)應(yīng)需求文檔的ID或者使用詳細(xì)設(shè)計(jì)的文檔的ID，間接連接需求），ACT代表一種動(dòng)作，因?yàn)闇y(cè)試動(dòng)作非常復(fù)雜，如果手動(dòng)執(zhí)行或者自動(dòng)執(zhí)行，或者或者是一種異常狀態(tài)都可以占用此位置，但是注意不能使用性能、數(shù)據(jù)或者安全測(cè)試替代，為什么請(qǐng)各位自己考慮。DATA代表數(shù)據(jù)，很多的測(cè)試類書籍中雖然沒有直接講明測(cè)試數(shù)據(jù)的劃分，但是通常我們引用三種數(shù)據(jù)“正?！?、“異?！?、“錯(cuò)誤”，分別對(duì)應(yīng)關(guān)鍵字“PASS”、“ERROR”、“FAIL”，對(duì)于數(shù)據(jù)的劃分我以前曾經(jīng)說過這里不再細(xì)談，為什么會(huì)在一個(gè)文檔中體現(xiàn)著點(diǎn)，主要是為了以后數(shù)據(jù)程序化作接口，一個(gè)不能將手動(dòng)測(cè)試轉(zhuǎn)為自動(dòng)測(cè)試的人員注定是平庸的。EXPECTED、ACTUAL分別代表期望和實(shí)際，我們做這一行的經(jīng)常對(duì)這兩種值的差異感到困惑，是不是“正?！薄ⅰ爱惓！?、“錯(cuò)誤”就看個(gè)人的經(jīng)驗(yàn)了。T/F的引入是因?yàn)橛羞@樣的一種情況介入，如果EXPECTED、ACTUAL是不同的，但是我們還是要給個(gè)T，因?yàn)閷?duì)于單項(xiàng)的是否通過測(cè)試人員有著使用權(quán)，但決定權(quán)在于市場(chǎng)或者高層決策。DATE是一種好習(xí)慣，通常記為發(fā)現(xiàn)“PASS”、“ERROR”、“FAIL”的時(shí)間，很多人會(huì)忽略這個(gè)值，當(dāng)然對(duì)于我們來說沒什么損失，對(duì)于QA團(tuán)隊(duì)來說，僅僅提供給他們T/F是不夠的。我覺得這就是一種構(gòu)造樸實(shí)的測(cè)試用例的方式，不要過于在意一份文檔的表現(xiàn)形式，如果你有很多的時(shí)間，如果你一年才寫一個(gè)這樣的文檔，那么你可以從互聯(lián)網(wǎng)上下在很多的資源把這份文檔修飾的像APPLE一樣。入行的人員會(huì)更進(jìn)一步的發(fā)揮測(cè)試偏執(zhí)狂的能力，這時(shí)候他們急需一種數(shù)量，例如：我們一個(gè)動(dòng)態(tài)庫(kù)的測(cè)試用例就有3000多個(gè)厲害吧？厲害，我當(dāng)然說你厲害，你難道不厲害嗎？我記得有個(gè)500強(qiáng)的面試題就是你能為L(zhǎng)OGIN動(dòng)作寫多少的測(cè)試用例？我想了半天我說就三個(gè)，或者四個(gè)，在聽到了一聲深深嘆息后，我惶恐的說大概我能寫5個(gè)吧？！當(dāng)然我自己也沒底，我就能寫出三個(gè)。LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL，所有的測(cè)試用例就是他們的衍生，一種本源的問題。我們繼續(xù)討論3000多個(gè)測(cè)試用例的事情，有人明眼就會(huì)說：這家伙肯定是微軟的，沒錯(cuò)，除了這種大公司有了充足的資源和技術(shù)支持，哪家公司能跟他們一樣呢？當(dāng)然了，寫3000個(gè)我想入行久了誰都可以，并且跟你對(duì)系統(tǒng)的熟悉程度，工作經(jīng)驗(yàn)有莫大的關(guān)系，但是這里我又想說說關(guān)于構(gòu)造樸實(shí)的測(cè)試用例的問題了。單元測(cè)試、集成測(cè)試這些說明的是測(cè)試范圍，功能測(cè)試、性能測(cè)試這些說明的是測(cè)試的手段，也可以這樣說某個(gè)功能測(cè)試包含了若干個(gè)功能測(cè)試也內(nèi)隱含了若干個(gè)單元測(cè)試的聯(lián)動(dòng)，當(dāng)你開始測(cè)試的時(shí)候，實(shí)際上最終是對(duì)代碼設(shè)定路徑的一種驗(yàn)算，如果我們都生活在單線程、無UI的年代你可以更清楚的看到“PASS”、“ERROR”、“FAIL”三種狀態(tài)，可我們已經(jīng)錯(cuò)過了這個(gè)年代，我們有了包裝的UI，有了封裝的API，有了各種各樣的MESSAGE，所以你就要承受更多ERROR的打擊。這個(gè)時(shí)候有人就會(huì)通過增加測(cè)試用例的數(shù)量來回避這些陷阱，出