心中的測試用例結(jié)構(gòu) 為新模型做準備
記得去年年初的時候，就做過關(guān)于如何寫的分享，說了為什么要寫測試用例，什么是測試用例，如何寫測試用例，什么樣的才叫好的用例，什么樣的叫不好的用例，也說了寫用例的糾結(jié)：前提條件和執(zhí)行步驟的糾結(jié)；測試用例標題的糾結(jié)；預(yù)期結(jié)果的驗證的糾結(jié)等等。
個人覺得講得很詳細了，覺得效果不錯的，為啥后來那些培訓的同學對于寫測試用例沒有一個系統(tǒng)的概念呢，不知道怎么去寫一個好的用例呢？這個blog的作用不是講這些，而是說下工作一兩年內(nèi)都很容易出現(xiàn)的用例結(jié)構(gòu)問題。你去問一線測試工程師，資深測試工程師，TL，Manager，甚至是Director，都不能對怎么寫好用例達成一個共同的意識，以及共同的作業(yè)方式，當然我們不期望流程化，死板化，但我希望我們不要忘了我們的測試信念，我們的質(zhì)量意識。
背景介紹：今年部門大量采用新模型進行項目測試，將去年做好基礎(chǔ)的自動化測試，接口測試用到項目過程中去，真正的做到測試提前，為開發(fā)質(zhì)量提高更早，更前面的保證和跟蹤。模型注意改進點在開發(fā)Coding階段，我們先看下以前SPR模型下，測試做了哪幾個工作：
1. 接口說明文檔評審
2. 數(shù)據(jù)庫設(shè)計文檔評審
3. 測試設(shè)計
4. 測試用例編寫
5. 測試用例評審和修改
相比較舊模型而言，下面再看下新模型下，測試又會去做什么呢：
1. 制定測試開發(fā)計劃
2. 接口說明文檔評審
3. 數(shù)據(jù)庫設(shè)計文檔評審
4. 自動化測試設(shè)計
5. 自動化測試腳本開發(fā)準備（Page Model 和 DB model的建立；自動化腳本偽代碼編寫）
6. 接口測試設(shè)計
7. 接口測試腳本開發(fā)（搭建接口測試環(huán)境，接口測試代碼編寫，調(diào)試，后期Hudson上回歸）
8. 自動化測試腳本和接口測試設(shè)計評審和修改
9. Code Review
大家是不是感覺到了明顯的變化，那就是我們測試需要做更多的前期事情，那這樣我們就需要對我們的測試用例模型（MM圖）進行改進，以適應(yīng)新的變化。對于做MM圖，我自己對MM圖的理解也許和大家不一樣，我每次做項目，做出來的MM圖都比較細，不僅僅是列出我要測試的每個功能點，而且每個功能點的測試設(shè)計和測試場景都寫出來了，而且我覺得一個非常好的MM圖（測試設(shè)計）需要經(jīng)過如下三個步驟：
MM 1 ——— PRD階段，使用RBT方法做出來的MM圖（功能點劃分，P1 和 P2的用例場景）
MM 2 ——— UC階段，使用RBT方法強烈Review UC做出來的MM圖（補充P1 和 P2的用例場景，P3和P4的用例場景）
MM 3 ——— 系統(tǒng)設(shè)計階段，通過Review接口說明文檔，詳細設(shè)計文檔，數(shù)據(jù)庫設(shè)計文檔（補充每個功能點容易遺漏的異常場景和詳細校驗點）
當然這里面的MM 圖不是一成不變的，在測試執(zhí)行階段，這個MM圖也會新增或修改測試思路（特別是發(fā)現(xiàn)了一些用例沒有寫的bug），下面就看一下例子吧：
那么如果我們使用了新模型后，我們的MM圖就必須加一些標記了，新模型的coding階段，我們測試人員沒有太多時間去編寫詳細的測試用例，我們有很多的自動化測試用例和接口測試用例，這時我們的MM圖就可以變成這樣了：
注意上圖的Automan就是自動化測試腳本的標記，iTest就是接口測試腳本的標記，另外一個就是Manual了。
當然也不能簡單了，我們最好能把自動化測試腳本和接口測試腳本編寫的環(huán)境連接起來，比如我打開了一個標記為自動化測試用例的環(huán)境，如下：
Page Model，DB Model 和 Ruby編程環(huán)境，能夠把用例標題寫入腳本模板中
再比如我打開了一個標記為接口測試用例的環(huán)境，如下：
Java代碼編寫環(huán)境，能夠把用例標題寫入腳本模板中，優(yōu)化腳本模板
其實這里面區(qū)別開我們的手工測試用例，自動化測試用例，接口測試用例可以有2種方式：
1. 一種是在功能點來進行劃分：細分到一個很小的功能點，寫測試思路的時候，不用Care是什么類型的測試用例，最好評審完后，加上一個簡單的標記即可，上圖的方式就是這種方式，就是統(tǒng)計數(shù)據(jù)比較麻煩一點。
2. 另一種是根據(jù)用例類型來劃分：首先劃分3個維度，然后再維度后面加上自己的功能點的測試思路
這樣做的優(yōu)點就是很清晰的知道不同的測試類型的用例個數(shù)或復雜度等，但注意這里面有個缺點：就是有可能一個功能點會存在多個不同的測試類型，所以本人建議使用第一種方式來做。
最后需要強調(diào)的是我們的測試思路的標題一定要是可見性的，正確性的，目的性的。另外如何在一個功能需求模塊中把這些用例結(jié)構(gòu)清晰的抽象出來，需要多思考，需要對于即將測試的需求有整體性的把握，然后在完善MM圖的過程中不斷的調(diào)整用例MM結(jié)構(gòu)圖，使其能讓開發(fā)清楚的知道我們即將要測試哪些點。我們也可以很快捷方便的完善我們的所以測試思路。
最后說明下，這里的測試思路的載體MM圖，如何去進行組織用例結(jié)構(gòu)和思路編寫規(guī)范，是需要一些探索式測試ET 的一些技巧的，特別是測試設(shè)計和測試執(zhí)行的相關(guān)注意點。
【編輯推薦】
