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