測(cè)試用例的編寫總結(jié)-文庫吧資料
2024-11-14 21:23本頁面
【正文】 資料已經(jīng)實(shí)在是多。 人員的風(fēng)險(xiǎn)178。 回報(bào)的對(duì)象不同，測(cè)試計(jì)劃向領(lǐng)導(dǎo)匯報(bào)，測(cè)試方案是組員共享該文檔178。178。 測(cè)試計(jì)劃是組織管理層面的文檔。 自動(dòng)化測(cè)試框架的設(shè)計(jì)178。 測(cè)試用例的規(guī)劃178。 明確測(cè)試策略（黑盒，白盒，灰盒等）178。 軟件測(cè)試方案的概念軟件測(cè)試方案描述測(cè)試的特征，測(cè)試的方法，測(cè)試環(huán)境的規(guī)劃，測(cè)試工具的設(shè)計(jì)和選擇，測(cè)試用例的設(shè)計(jì)方法，測(cè)試代碼的設(shè)計(jì)方案。2測(cè)試計(jì)劃的作用：組織和管理測(cè)試；使測(cè)試工作和整個(gè)開發(fā)工作整合起來；資源和變更事先最為一個(gè)可控制的風(fēng)險(xiǎn)。讓我們一起交流分享，共同進(jìn)步成長。同時(shí)，在規(guī)范上要增加以下幾項(xiàng)1測(cè)試目的（Purpose）：編寫這個(gè)測(cè)試用例的目的2測(cè)試方法選擇依據(jù)（Foundation）：即用這樣方法的好處3測(cè)試取得的成果（Achievement）：通過執(zhí)行用例取得的成果4用例執(zhí)行的前提條件（Precondition）：執(zhí)行用例的需要滿足的前提這樣，一個(gè)完整的用例包含的元素如下：1測(cè)試名稱(Test Name)測(cè)試目的（Purpose）測(cè)試方法選擇依據(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）測(cè)試取得的成果（Achievement）.綜上所述，測(cè)試用例的“侯式標(biāo)準(zhǔn)”的精髓，就是把自己的思維過程盡可能的展現(xiàn)到用例中，做到即使一個(gè)完全不懂業(yè)務(wù)的人，看到我們的用例后，也能知道業(yè)務(wù)的需求和流程，知道測(cè)試的過程，能夠無障礙的執(zhí)行我們的用例。B）一級(jí)目錄使用各項(xiàng)目的頂級(jí)菜單名稱來命名，如功能、業(yè)務(wù)、查詢?nèi)箢?；C）二級(jí)目錄使用頂級(jí)菜單下的二級(jí)菜單名稱類命名，用戶可根據(jù)名字判別該用例是測(cè)試哪個(gè)模塊的。3設(shè)計(jì)人員(Designer)：測(cè)試用例設(shè)計(jì)人員4狀態(tài)(Status)：測(cè)試用例狀態(tài)5描述（Descrīption）：測(cè)試用例詳細(xì)描述6步驟名稱（Step Name）：測(cè)試步驟名稱7步驟描述（Step Descrīption）：測(cè)試步驟詳細(xì)描述。標(biāo)準(zhǔn)規(guī)范中包含的主要元素如下：1測(cè)試名稱(Test Name)：測(cè)試用例編號(hào)和測(cè)試用例名稱。取得了什么成果？這要求用例編寫者明確通過這個(gè)測(cè)試用例,我們將取得什么效果。怎么做？即具體的如何設(shè)計(jì)用例。做什么？做任何事情，都要有的放矢。而我的TL–候風(fēng)的一句話，讓我對(duì)用例的有了新的認(rèn)識(shí)。一個(gè)“好”的測(cè)試用例能保證測(cè)試的質(zhì)量，規(guī)范測(cè)試的進(jìn)程，進(jìn)而提高我們的測(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的打擊。LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL，所有的測(cè)試用例就是他們的衍生，一種本源的問題。我覺得這就是一種構(gòu)造樸實(shí)的測(cè)試用例的方式，不要過于在意一份文檔的表現(xiàn)形式，如果你有很多的時(shí)間，如果你一年才寫一個(gè)這樣的文檔，那么你可以從互聯(lián)網(wǎng)上下在很多的資源把這份文檔修飾的像APPLE一樣。T/F的引入是因?yàn)橛羞@樣的一種情況介入，如果EXPECTED、ACTUAL是不同的，但是我們還是要給個(gè)T，因?yàn)閷?duì)于單項(xiàng)的是否通過測(cè)試人員有著使用權(quán)，但決定權(quán)在于市場(chǎ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è)試的人員注定是平庸的。構(gòu)造樸實(shí)的測(cè)試用例測(cè)試用例這種東西對(duì)于剛?cè)胄械娜藖碚f是一種誘惑，初入測(cè)試的人急于掌握這門學(xué)問，所以一開始就會(huì)問測(cè)試用例怎么寫，問的同時(shí)或許還包含了一些期望。3．在編寫測(cè)試用例的時(shí)候優(yōu)先去學(xué)習(xí)，老人們優(yōu)秀的做法。你的用例優(yōu)先級(jí)是否設(shè)置的合理。5．將功能測(cè)試用例分為嚴(yán)重和不嚴(yán)重兩類，對(duì)于不嚴(yán)重的功能測(cè)試用例降級(jí)為低優(yōu)先級(jí)用例。合理提高我們的測(cè)試效率就是在編寫測(cè)試用例時(shí)進(jìn)行測(cè)試用例優(yōu)先級(jí)的劃分。Ross Collard在”Use Case Testing”一文中說：“測(cè)試用例的前10%到15%可以發(fā)現(xiàn)75%到90%的重要缺陷”。（測(cè)試用例的可維護(hù)性）我們的用例主要是基于web的，用例存在一定的變數(shù)。對(duì)于流程性的用例也是建議按照流程順序進(jìn)行用例安排，從第一個(gè)驗(yàn)證點(diǎn)到最后一個(gè)驗(yàn)證點(diǎn)，組成流程的開始到結(jié)束，方便測(cè)試執(zhí)行。（測(cè)試用例的可理解性）測(cè)試用例步驟必須描述清晰，不能出現(xiàn)模棱兩可以及重復(fù)的話語，測(cè)試用例應(yīng)該按照增刪改的順序進(jìn)行安排，這樣執(zhí)行的時(shí)候效率比較高，避免不必要的重復(fù)測(cè)試，用例寫完不是就ok了，我們最好通讀2遍，進(jìn)行修改，讓單條用例流暢。對(duì)于預(yù)期的結(jié)果不能僅僅是頁面上或者界面上的可見結(jié)果，如果和數(shù)據(jù)庫發(fā)生了交互，必須包含數(shù)據(jù)庫里準(zhǔn)確的驗(yàn)證結(jié)果。但是看看我們的基線庫更多的是這樣指導(dǎo)意義的用例。也就是說拿到需求文檔必須進(jìn)行必要的分析，不能上來就盲目的寫用例，新人尤其應(yīng)該注意。在編寫用例的過程中進(jìn)行等價(jià)類的劃分，最后用判定表進(jìn)行評(píng)判，補(bǔ)充缺少的用例，剔除冗余的用例。把基本路徑分解出來，將需求歸類。測(cè)試用例是基于需求的，為了測(cè)試程序是否滿足需求，個(gè)人覺得要想
化學(xué)相關(guān)推薦
鄂ICP備17016276號(hào)-1