測試思想-測試設計實踐總結part1

轉載：http://blog.sina.com.cn/s/blog_13cc013b50102v4ad.html

步驟一：用例劃分：

1.按系統模塊劃分

2.按性質分類劃分

3.按關聯緊密程度劃分

 

1.按系統模塊劃分

通常設計比較好的系統軟件，都會把功能進行分類，並以模塊的方式佈局在用戶界面上，如圖：【目標管理】，【課程管理】，【學員管理】，大模塊下再分小模塊，好比【課程管理】模塊又分【課程列表】，【項目資源管理】。

 

用例劃分：針對每一個模塊、子模塊或子模塊的模塊設計用例

優勢：容易展開，簡單明瞭

缺點：

1.業務邏輯容易被忽視。模塊與模塊之間每每是關聯的。

2.容易忽略非UI功能的測試，好比安裝測試

 

舉例：數據庫審計系統，【規則模塊】，【對象模塊】

【規則模塊】：存放規則，好比操做表名xx的規則

【對象模塊】：存放對象，好比表名對象，操做方式對象

 

關聯：規則引用對象

業務流程：客戶操做->產生瀏覽數據->系統捕獲數據->檢測操做對象與規則引用的對象->若是對象匹配則觸發規則並執行規則中指定的動做

 

單獨測兩個模塊可能都沒問題，可是結合起來，在【對象模塊】中把【規則模塊】中規則正在引用的對象刪除，那結果會咋樣？難說吧

 

2.按性質分類劃分

用例劃分：兼容性測試，壓力測試，安裝測試，容量測試，可靠性…

好處：對按模塊劃分的有效補充。

 

3.按關聯緊密程度劃分

用例劃分：也是按模塊劃分，區別是把關聯比較緊密的模塊歸到某個模塊

好處：有利於任務分配，減小人力資源的重複投入

 

舉例：手機在線教育APP應用，打開應用有 個人課程，個人筆記，個人問題等模塊，其中，個人筆記，筆記記錄來自課程模塊，觀看課件學習時進行提交的。

若是按模塊來，測試個人筆記的人須要去觀看課件並提交筆記，而測試課件觀看的人又要測提交筆記，很明顯的，「提交筆記」重複投入了勞力。若是把提交筆記歸到個人筆記模塊，這樣按模塊分配用例，分配給同一我的去測，這就減小了交叉，減小重複的勞動

 

步驟二：用例設計

一、設計思想

二、用例編寫

 

1、設計思想

a) 測試點來源與定位

來源

測試點來源：1、顯式需求 2、隱式需求。一個需求點能夠對應多個測試點

 

定位測試點

測試點其實也就是測試目的。用例定義了「怎麼測」，而測試點則定義了「爲什麼測」，因此，設計前必須明白測試點是什麼，且一個用例僅對應一個測試點。

 

理由：便於統計，測試用例對整個測試過程的質量控制和評估有很重要的意義：

1、測試需求覆蓋率分析。若是一個用例包含幾個測試點，那麼不利於需求覆蓋分析

2、用例成功率分析。一個用例中有多個測試點，確定會形成用例數量減小，用例失敗率大大增多，那麼你作的用例成功率還有什麼意義？

3、缺陷分析。若是用例失敗了，就生成一個缺陷。若是一個用例中寫了多個測試點，迴歸的時候若是有指定迴歸用例，那用例中那些些與缺陷不相關的測試點也可能也被迴歸，增長工做量。

 

如下3點想法幫助你更好的定位測試點

1.站在用戶使用角度來考慮，看你定位的「測試點」是否有實際意義

2.考慮你定位的「測試點」的完成可否標誌着用戶實際業務流程的一個階段性結束？

3.考慮你定位的「測試點」的完成，是否能夠爲其餘用戶或業務提供輸入數據，以供完成下面的工做？

綜合2-3點：劃清界線，點到即止

 

例子：QQ郵箱註冊

 

如上圖，單獨把任意一個選框拿出來併爲其設計一個用例，站在用戶角度來看，都無實際意義。用戶關注的是我填寫完資料並點擊註冊，能生成一個可用賬號，爲登陸功能提供輸入數據。因此設計用例時，這裏的測試目的應該定位爲賬號註冊，而不是某個選框的特性測試。那輸入框的特性，好比上述咋辦？這個就是方法問題了， 相似這樣的，能夠考慮用場景法來設計。

 

舉例：音樂臺音樂短片 撲克牌花式技巧演示"五個竅門」視頻播放

 

 

操做流程：點擊 撲克牌花式技巧演示"五個竅門」視頻鏈接，自動打開視頻播放界面，邊緩衝，以邊播放，播放完成，出現上述界面，給出「重播」按鈕提示。

不考慮試測試點粒度和分割(1條用例)：

1.點擊視頻鏈接--打開視頻播放界面

2.查看打開的播放器界面--一邊進行視頻緩衝，一邊自動播放緩衝好的視頻部分

3.等待播放結束，查看播放器界面--出現重播按鈕和推薦短片

4.點擊重播按鈕--從新播放已緩衝完成的視頻

 

考慮試測試點粒度和分割(2條用例)：

用例1：在線視頻播放功能

1.點擊視頻鏈接--打開視頻播放界面

2.查看打開的播放器界面--視頻以邊緩衝，一邊自動播放

3.等待播放結束，查看播放器界面--出現重播按鈕和推薦短片

 

用例2：視頻重播功能

1.打開視頻進行播放直到播放結束，查看播放器界面--出現重播按鈕和推薦短片

2.點擊重播按鈕--從新播放打開的視頻

這裏用例操做過程彷佛有點冗餘，可是從測試目的考慮是容許的：對用例2來講，步驟1可當作是爲測試重播而必須通過的一條路線，不是測試重點，而對用例1而言，用例2中的步驟1則是測試重點。進一步，結束播放時的畫面還有推薦視頻。對這個設計用例，模仿用例2也顯得很容易，思路清晰。

 

舉例：在線教育系統，手機端離線視頻學習

操做流程：網絡鏈接下，下載課件視頻，網絡斷開下，查看打開視頻學習，提交離線筆記，新增待同步學識記錄。網絡鏈接，點擊同步學識記錄按鈕進行服務端與手機端的同步。

從以上3點想法來考慮，可定位如下兩個測試點：

1.保存離線筆記

2.同步離線筆記

 

可能有人會以爲，以上2個測試點也能夠合併在一塊兒。對的，可是你再結合一個用例對應一個測試點就好理解爲什麼不合並了。

備註：用例是死的，人是活的，例中所舉的例子都存在必定的冗餘，執行的時候能夠考慮執適當的用例執行順序來減小操做冗餘。

 

舉例：教師端學員信息修改

 

點擊修改，彈出修改界面，繼續點擊單位，出現如圖界面

 

點擊修改界面中的【單位】設置框，彈出的是一個單位搜索和選擇對話框，若是不獨立出來，對搜索框的準確性驗證也加到修改功能的用例裏，用例會顯得龐大，並且測試點不單一，咋辦？

單獨出來，目的就是對其搜索或展現數據(單位)準確性，找不到單位聯繫客服等功能驗證，好比，是否錯亂，是否少了等進行驗證，是有意義的，由於這個測試點的輸出數據爲這個資料修改模塊提供了輸入數據，使其可往下執行。而修改中則僅關注單位選擇做用。

 

b） 分離測試數據與測試邏輯（步驟）

方法：將用例中的一些輸入、輸出等做爲參數，數據則單獨列出，在執行時選擇相應的數據執行。

理由：爲何要參數化？

a 、沒有將測試數據和測試邏輯分開的測試用例可能顯得很是龐大，不利於測試員理解，致使難以控制和執行；

b 、經過將用例參數化，能夠簡化用例，使測試用例邏輯清晰，數據不邏輯的關係明瞭，易於理解；

c 、有利於提升測試用例的重用；

選擇參數化內容

測試用例中須要經過使用不一樣數據來重複執行測試的部分；

包括：

a 、輸入（數據或操做等）

b 、輸出（結果數據或預期結果等）

舉例

例一：系統登錄

 

測試數據

 

 

 

固然，這裏的案例也存在不妥的地方，也就說包含了多個測試點，另外，要是再加個驗證碼，那就更不妥了。。。

 

c) 依據業務邏輯進行設計

（關於業務邏輯的詳細說明可參考另外一文檔）

舉例說明什麼是業務邏輯：

網上購物

業務流程：用戶登陸-選擇商品-結算-下訂單-付款-確認收貨，這是一個流程

業務規則：當用戶下單付款後必須通知賣家，有顧客光臨

業務實體：訂單信息，包含購買物品，買家，金額等

業務實體完整性：如：訂單信息中，買家不可少，物品id不能爲空

根據上述，能夠得出優先級：業務流程>業務規則>實體完整性

固然這順序不是絕對的。

 

思想：

根據80/20原則，百分之80的用戶只使用了產品20%的核心功能，測試要多站在用戶角度進行模擬測試，有些測試站在測試的角度看是有意義的，站在用戶的角度看卻沒多大意義，由於有些相似邊界值的數據用戶極少或根本不會用。（注意我這裏的用詞），因此要保證基本的核心功能可用。這樣寫出來的用例優先級也比較好分，一目瞭然