住房城鄉(xiāng)建設(shè)部官方網(wǎng)站,百度廣告優(yōu)化,做外貿(mào)在什么網(wǎng)站上比較好,黃頁88標(biāo)題生成器現(xiàn)在很多文章都有介紹如何使用測試框架來測試#xff0c;但只介紹工具如何使用#xff0c;卻不介紹如何從研發(fā)角度設(shè)計(jì)測試用例#xff0c;寫出來的單測往往很難維護(hù)#xff0c;看上去就只是為了維持kpi而已。 測試用例設(shè)計(jì)的MECE原則 測試用例設(shè)計(jì)有很多經(jīng)典的方法…現(xiàn)在很多文章都有介紹如何使用測試框架來測試但只介紹工具如何使用卻不介紹如何從研發(fā)角度設(shè)計(jì)測試用例寫出來的單測往往很難維護(hù)看上去就只是為了維持kpi而已。測試用例設(shè)計(jì)的MECE原則測試用例設(shè)計(jì)有很多經(jīng)典的方法比如等價(jià)類劃分法、邊界值分析法、錯(cuò)誤推測法等。這些測試方法提供了設(shè)計(jì)的思路但是卻沒有說明如何評判測試用例是否已經(jīng)設(shè)計(jì)完全。評判測試用例有沒有設(shè)計(jì)完全是確保業(yè)務(wù)邏輯bug-free的關(guān)鍵。因此我們在設(shè)計(jì)測試用例時(shí)需要確保測試用例設(shè)計(jì)遵循MECE原則。測試用例設(shè)計(jì)遵循MECE原則指的是對測試用例進(jìn)行分類時(shí)分類應(yīng)該是互斥Mutually Exclusive且完備Collectively Exhaustive的。將測試用例根據(jù)MECE原則進(jìn)行分類可以更好地幫助我們設(shè)計(jì)出符合需求的測試用例從而更好的保證軟件質(zhì)量。下面就以排隊(duì)需求作為例子說明測試用例設(shè)計(jì)是如何滿足MECE原則的。有消費(fèi)者、隊(duì)列組、隊(duì)列、任務(wù)四種角色其關(guān)系如下有一批隊(duì)列在每個(gè)隊(duì)列中都有一批任務(wù)不同的隊(duì)列可以組成隊(duì)列組消費(fèi)者可以訂閱不同的隊(duì)列組。在消費(fèi)者消費(fèi)隊(duì)列中的任務(wù)時(shí)需要按照訂閱關(guān)系和一定的規(guī)則消費(fèi)隊(duì)列中的任務(wù)。在消費(fèi)任務(wù)時(shí)每個(gè)任務(wù)都可能對應(yīng)多個(gè)消費(fèi)者當(dāng)其中一個(gè)消費(fèi)者忙碌時(shí)需要自動(dòng)分配給下一個(gè)消費(fèi)者。另外因?yàn)橐粋€(gè)消費(fèi)者可以同時(shí)訂閱多個(gè)隊(duì)列組所以需要從多個(gè)隊(duì)列組里選取一個(gè)任務(wù)出來進(jìn)行消費(fèi)。其消費(fèi)規(guī)則如下所示消費(fèi)規(guī)則文字詳述如下如果專屬隊(duì)列有任務(wù)則從專屬隊(duì)列中選擇排隊(duì)時(shí)間最長的任務(wù)如果專屬隊(duì)列無任務(wù)VIP隊(duì)列中有任務(wù)則選擇VIP隊(duì)列中的任務(wù)對VIP隊(duì)列中的任務(wù)按隊(duì)列優(yōu)先級(jí)進(jìn)行排序選擇優(yōu)先級(jí)最高的隊(duì)列如果優(yōu)先級(jí)最高的隊(duì)列只有一個(gè)則從該隊(duì)列中選擇排隊(duì)時(shí)間最長的任務(wù)如果優(yōu)先級(jí)最高的隊(duì)列有多個(gè)則從這多個(gè)隊(duì)列中選擇排隊(duì)時(shí)間最長的任務(wù)如果專屬隊(duì)列無任務(wù)VIP隊(duì)列中無任務(wù)則選擇非VIP隊(duì)列中的任務(wù)對非VIP隊(duì)列中的任務(wù)按隊(duì)列優(yōu)先級(jí)進(jìn)行排序選擇優(yōu)先級(jí)最高的隊(duì)列如果優(yōu)先級(jí)最高的隊(duì)列只有一個(gè)則從該隊(duì)列中選擇排隊(duì)時(shí)間最長的任務(wù)如果優(yōu)先級(jí)最高的隊(duì)列有多個(gè)則從這多個(gè)隊(duì)列中選擇排隊(duì)時(shí)間最長的任務(wù)在上篇文章中引入了訂閱組的概念如圖所示一個(gè)消費(fèi)者訂閱的所有隊(duì)列組組成一個(gè)訂閱組不同消費(fèi)者的訂閱組可能是不一樣的用一張圖簡單表示這種關(guān)系要先分析清楚復(fù)雜的問題首先要做的就是按一定的標(biāo)準(zhǔn)分解問題將問題的規(guī)模變小變成一個(gè)個(gè)子問題然后逐個(gè)解決最終就解決了整個(gè)復(fù)雜的問題。分類的方法有很多但是無論使用哪種方法需要確保的是按某種標(biāo)準(zhǔn)分解問題之后子問題之間是相互獨(dú)立的不存在任何依賴的且分解后的n個(gè)子問題最終也可以組合成原始的問題不至于會(huì)漏掉某些可能的情況。這樣分解問題才滿足MECE原則。如果分解問題后不滿足MECE原則那必定會(huì)存在遺漏測試用例的情況或者有重復(fù)測試用例的情況如果在后續(xù)設(shè)計(jì)的時(shí)候發(fā)現(xiàn)有這樣的問題那可能就要重新回過頭來確定分解的標(biāo)準(zhǔn)了。在這個(gè)需求中我會(huì)將這個(gè)復(fù)雜需求按這樣的標(biāo)準(zhǔn)進(jìn)行分解訂閱了同一訂閱組的消費(fèi)者消費(fèi)任務(wù)訂閱了不同訂閱組的一類消費(fèi)者消費(fèi)任務(wù)為什么這樣分解就能滿足MECE原則因?yàn)閷τ谡麄€(gè)任務(wù)消費(fèi)情況來看只有訂閱了同一訂閱組和訂閱了不同訂閱組這兩種情況不可能存在訂閱的訂閱組既相同又不同的情況。這樣就是滿足MECE原則的問題分解。訂閱了同一訂閱組的消費(fèi)者消費(fèi)任務(wù)對于這種情況其實(shí)就是從一個(gè)訂閱組內(nèi)選擇一個(gè)任務(wù)出來分配給訂閱了這個(gè)訂閱組的消費(fèi)者。所以問題就轉(zhuǎn)化成根據(jù)消費(fèi)規(guī)則選擇訂閱組內(nèi)的任務(wù)時(shí)如何滿足MECE原則。其實(shí)這里的用例的設(shè)計(jì)已經(jīng)在上面的需求描述里給出來了此處再列出來這樣分解為什么是滿足MECE原則的呢在這個(gè)比較規(guī)則中比較的順序是按 隊(duì)列類型選擇、優(yōu)先級(jí)隊(duì)列選擇策略、任務(wù)選擇策略 這三種策略依次比較下來的。這幾種策略是根據(jù)既有的需求分類得來的相互之間沒有重疊的情況所以在策略的分類上是滿足MECE原則的。然后對于每一種選擇策略其分支的組成都是互斥且完備的比如隊(duì)列類型選擇策略中VIP隊(duì)列只存在有任務(wù)和無任務(wù)兩種互斥的情況不可能存在既有任務(wù)又無任務(wù)的可能性所以這樣的用例設(shè)計(jì)就能覆蓋到所有的情況。我們可以用這樣的標(biāo)準(zhǔn)去審視每一種策略看看是否都滿足MECE原則如果都滿足那么這樣的分類就能確保你不會(huì)遺漏任何一種情況。訂閱了不同訂閱組的一類消費(fèi)者消費(fèi)任務(wù)訂閱了同一訂閱組的消費(fèi)者消費(fèi)任務(wù)是比較流程化的用思維導(dǎo)圖就可以比較方便地梳理出來。但是像訂閱了不同的訂閱組的消費(fèi)者用思維導(dǎo)圖就不太好分析出來了。這個(gè)時(shí)候我們可以稍稍運(yùn)用一些基礎(chǔ)的數(shù)學(xué)知識(shí)集合。試想一下我們會(huì)如何表示一個(gè)消費(fèi)者訂閱了哪些隊(duì)列組比如消費(fèi)者 C1 訂閱了隊(duì)列組 QG1, QG2那我們會(huì)這樣表示: C1: {QG1, QG2}如果是消費(fèi)者 C2 訂閱了隊(duì)列組 QG2, QG3那就會(huì)這樣表示C2: {QG2, QG3}。這樣消費(fèi)者C1和C2訂閱的隊(duì)列組之間就形成了交集相交的隊(duì)列組就是QG2。從這個(gè)角度去思考對于訂閱了不同訂閱組的一類消費(fèi)者消費(fèi)任務(wù)的情況就變成了考察如何窮舉兩個(gè)集合之間的關(guān)系了。從以往學(xué)過的簡單的數(shù)學(xué)知識(shí)就可以知道兩個(gè)集合之間的關(guān)系無非就是 子集、全集、交集、無交集 這四種情況。因此我們可以用韋恩圖來表示集合之間的關(guān)系從這個(gè)圖里我們以消費(fèi)者C1作為考察對象則其他消費(fèi)者的訂閱組和C1之間的關(guān)系是C2 的訂閱組是 C1 訂閱組的子集C3的訂閱組是C1訂閱組的全集C4訂閱組和C1訂閱組的交集是 {QG2}C5訂閱組和C1訂閱組之間無交集。這樣我們在寫測試用例代碼時(shí)從消費(fèi)者的編號(hào)和隊(duì)列組的編號(hào)就知道只需要用5個(gè)消費(fèi)者和4個(gè)隊(duì)列組就可以窮舉所有的情況。而且這幾種情況都是相互獨(dú)立又完全窮盡的。再論先寫代碼還是先寫測試在前面一篇文章中討論了究竟應(yīng)該先寫代碼還是先寫測試在這里想結(jié)合這個(gè)需求再強(qiáng)調(diào)一下其實(shí)先寫哪種都沒有關(guān)系關(guān)鍵是要先設(shè)計(jì)測試用例。在這個(gè)需求例子中經(jīng)過這一輪分析即使你沒有寫一行代碼通過對測試用例的設(shè)計(jì)你也對最終要實(shí)現(xiàn)成什么效果已經(jīng)了如指掌。甚至你可以在不寫一行實(shí)現(xiàn)代碼的情況下就可以把對應(yīng)的測試用例代碼寫出來。當(dāng)然不是說要一下子把所有的用例都寫完而是用TDD的方式先寫一個(gè)測試用例的代碼然后再寫這個(gè)測試用例對應(yīng)的實(shí)現(xiàn)代碼測試通過后再實(shí)現(xiàn)下一個(gè)測試用例。其實(shí)設(shè)計(jì)測試用例的過程就像是一種直觀的方式來寫測試用例代碼的過程如果你之前認(rèn)為先寫測試再寫實(shí)現(xiàn)這樣的開發(fā)模式有點(diǎn)違反“常識(shí)”不妨試試在開發(fā)之前先對著需求按MECE原則設(shè)計(jì)出測試用例然后再去寫測試用例代碼或者去寫實(shí)現(xiàn)代碼你就會(huì)發(fā)現(xiàn)TDD方式的開發(fā)模式是非常合理且順暢的。而現(xiàn)實(shí)中有很多人都認(rèn)為TDD并不符合實(shí)際開發(fā)過程。但其實(shí)這篇文章介紹的測試用例設(shè)計(jì)方法和設(shè)計(jì)過程就是在做著TDD開發(fā)模式中的一個(gè)至關(guān)重要的環(huán)節(jié)任務(wù)拆分tasking。無法很好地實(shí)踐TDD本質(zhì)上不是因?yàn)檫@種方式違反常識(shí)而是因?yàn)殚_發(fā)者在開發(fā)之前無法很好地理清需求并做好任務(wù)拆分以致于在模仿TDD的形式時(shí)遭遇到了挫敗感而忽略了TDD最核心的部分-任務(wù)拆分。所以在之前的文章中我也說過先寫測試或先寫代碼其實(shí)都不重要重要的是要先按MECE原則設(shè)計(jì)出測試用例其實(shí)也就是要按照MECE原則做好任務(wù)拆分這樣無論你是先寫實(shí)現(xiàn)還是先寫測試或者是用其他的方式實(shí)現(xiàn)只要最終實(shí)現(xiàn)的效果是符合事先設(shè)計(jì)好的測試用例的預(yù)期的那對產(chǎn)品最終的質(zhì)量就會(huì)有了保障。總結(jié)在這個(gè)需求中運(yùn)用了MECE原則設(shè)計(jì)測試用例在實(shí)際開發(fā)中的確做到了這部分業(yè)務(wù)邏輯0bug。希望這篇文章能給大家一點(diǎn)啟示測試用例的設(shè)計(jì)過程本質(zhì)上就是在做任務(wù)拆分。對復(fù)雜需求的測試用例要實(shí)現(xiàn)對應(yīng)的測試用例代碼對于前置條件的構(gòu)造也很麻煩。這部分就留待下一篇文章解決了。最后作為一位過來人也是希望大家少走一些彎路在這里我給大家分享一些軟件測試的學(xué)習(xí)資料和我花了3個(gè)月整理的軟件測試自學(xué)全棧這些資料希望能給你前進(jìn)的路上帶來幫助。?視頻文檔獲取方式這份文檔和視頻資料對于想從事【軟件測試】的朋友來說應(yīng)該是最全面最完整的備戰(zhàn)倉庫這個(gè)倉庫也陪伴我走過了最艱難的路程希望也能幫助到你以上均可以分享點(diǎn)下方小卡片即可自行領(lǐng)取。