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

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

方法：這裏針對業務流程的測試推薦使用「場景法」。（固然，我的理解業務流程是從系統總體來把握的，局部角度來看，有些只算是「操做流程」,可是這個區別並不影響方法的使用）

舉例：

 

分析：先考慮用戶使用場景

場景1：列表有數據，用戶把數據按默認方式導出

點擊導出->開始導出->查看導出文件

場景2：用戶忽然不想導出

點擊導出->點擊取消

場景3：列表有數據，用戶把數據按自定義方式導出

點擊導出->開始導出->查看導出文件

點擊導出->設置導出列->開始導出->查看導出文件

點擊導出->設置導出列->設置導出記錄數->查看導出文件

場景4：找不到導出的文件，重複導出

點擊導出->導出列和記錄數設置和上次同樣->開始導出->查看導出文件

 

這些主要的考慮了，接下來考慮容錯啥的

1.列表沒數據，進行導出

2.導出列的邊界值測試

 

好了，接下來就是細分和組合等了

細分：好比上面的導出列設置時，能夠是所有選中，能夠添加部分選中

組合：好比那個取消導出操做能夠和其它場景的寫在一塊兒

更多詳情，搜索 場景法

 

再舉個例子說明按邏輯設計的好處：

教師端學員信息修改

 

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

 

要點分析：

此處的修改是服務端管理員對學生端學員信息的修改，若是按業務邏輯來，這裏的修改會同步學生端學員信息的修改，這個點不容易遺漏的

 

說明：按業務邏輯來設計用例，容易讓本身陷入矛盾的地方

背景：某個在線教育產品，功能模塊包含了 個人筆記，課程-視頻課件播放，其中，個人筆記中，筆記內容記錄，來源視頻播放界面提交的筆記

舉例：按業務邏輯來，可能會以下方式編寫

一、打開視頻播放界面，輸入筆記內容，提交---(預期結果)

二、打開個人筆記--可見提交的筆記

這樣看好像沒問題，可是細想下，測試 個人筆記 模塊時，會漏掉步驟2的驗證麼？不會吧，因此這裏的步驟2是多餘的，可去掉，這裏應該對步驟1進行重點測試，不輸入、輸入字符過長，輸入字符含特殊字符，輸入字符含換行等

 

那步驟2怎麼辦？在個人筆記模塊新增用例，把步驟1當作一條線，以下

一、打開視頻播放界面提交一條筆記 （預期結果可免了，視頻播放模塊已驗證過了）

二、打開個人筆記--預期結果（提交時間，內容顯示，字符類型支持等）

這裏也告訴咱們，僅當某個點不會被單獨做爲一個用例檢測點時，才須要進行一個「關聯」，比如上面的學員信息修改，數據同步

 

這樣看好像是沒錯的，可是很大的不足是啥呢？仍是上面提到的，人力的重複投入：測試提交筆記時至少測輸入字符串的長度，類型支持；測試筆記模塊的查閱時也要測試筆記內容是否被截斷，要測試特殊字符的顯示是否正常等，也要進行提交筆記時執行的測試操做

 

解決方案：沒錯，仍是按邏輯設計用例>>輸入筆記->提交筆記->顯示筆記，

一、打開視頻播放界面，輸入筆記內容，提交---(預期結果)

二、打開個人筆記--可見提交的筆記

 

這裏能夠根據本文中提到的，檢測點的思想，進行細化，分紅多條用例

好比用例1.記筆記(字符長度測試)；用例2.記筆記(字符類型驗證)，固然對應的用例內容也跟着改，以下

一、打開視頻播放界面，輸入超長字符的筆記內容，提交---(預期結果)

二、打開個人筆記--筆記顯示不截斷，過長以…結尾

 

接着能夠根據本文中提到的，歸到同一個模塊，好比筆記模塊，分配給同一我的

 

d) 獨立出公共用例

思想：把某些公用的模塊或功能獨立出來設計，減小冗餘

舉例：常見的智能手機，不少模塊中選擇文字，文字變底色，一般伴隨彈出操做面板，相似全選，複製等，那能夠考慮在某個模塊中把這個功能單獨出來設計用例，其它模塊則再也不重複寫

 

e) 提升用例複用性

設計用例應該多考慮用例的複用性，能夠從如下幾個方面來考慮：

1)通用性。通用性是指可複用測試用例並不侷限於具體的應用，不過度依賴於被測軟件的需求、設計和環境，可以在某一類型、某一領域的類似軟件的測試中普遍使用。(能夠嘗試去構建本身的用例庫)

2)有效性。測試用例的目標是儘早發現軟件問題

3)獨立性。

1.用例之間不存在相互依賴關係

對於測試需求 R1和 R2，測試用例集分別爲 cl和 c2，c1 和 c2 的交集爲空，而且每一個可複用測試用例可以獨立運行。測試用例是否具備獨立性，決定了測試用例可複用能力的強弱。

若是測試用例之間存在着相互關聯，或測試用例的運行環境取決於其餘測試用例的執行狀態，那麼，其中的測試用例不能複用時，與之相關的測試用例的可複用性也不復存在。

2.測試邏輯和測試數據分離

詳情見下文

4)標準化

見」用例組成」

 

1、用例編寫

1.1 用例組成

用例應遵循統一或規範的格式、結構，規範的命名規則，使用術語，用簡明、易懂、無歧義的語言來描述，而且具備詳細的文檔。主要元素以下：

標識符ID：每一個測試用例應該有一個惟一的標識符，它將成爲全部和測試用例相關的文檔、表格引用和參考的基本元素

測試項(用例名)：測試用例的標題，所給名稱最好能清晰且簡潔地表達測試用例的功能，見名知意，即測試目的、驗證點。

建議格式：【模塊-子模塊】用例名

好比：【登陸】密碼大小寫敏感測試

測試需求：對要驗證的測試需求的描述和測試要求，如登陸驗證需求：

 a 、用戶名長度爲 6 至 10 位（含 6 位和 10 位），

 b 、用戶名由字符（ a-z 、 A-Z ）和數字（ 0-9 ）組成，。

測試環境：where-在哪裏測？測試用例運行時所處的環境，包括系統的配置和設定等要求，也包括操做操做系統，瀏覽器，通信協議等環境。即軟硬件環境。通常來講，在整個的測試模塊裏面應該包含整個的測試環境的特殊要求，而單個測試用例的測試環境須要表徵該測試用例所單獨須要的特殊環境需求。

測試前提：測試用例執行前必須知足的條件，如已登陸、某個選項已經被勾選

輸入數據： which-輸入哪些數據?用來執行測試用例的數據。可能包括數據、文件，必要的時候，相關的數據庫、文件也必須被羅列。

操做步驟：how-怎麼作? 操做步驟，如 1 打開軟件，2 點擊 xx 按鈕

預期輸出：標識按照指定的環境和輸入標準獲得的指望輸出結果(包含中間結果和最後結果)。

用例關聯：用來標識該測試用例與其它用例之間的依賴關係，例如，用例 A 須要基於 B 的測試結果正確的基礎上才能進行，此時須要在 A 的測試用例中代表對 B 的依賴性，從而保證測試用例的嚴謹性。並不是全部的測試用例之間都須要關聯

優先級：優先級越高的用例，應越早被執行

優先級一般是這樣分的：

首先：核心功能>次要功能

其次：正向用例>逆向用例

也就是說，先確保核心功能正常，再次要功能測試；先確保常規路徑運轉正常-而後再逆向測試；

注意：

1.優先級之分主要是從「關注對用戶最有價值的東西」這個點出發來考慮的。

2.上述的優先級的順序，銀行爲例，銀行帳戶登陸，登陸模塊也包含逆向測試，可是涉及資金安全，登陸模塊的逆向測試的優先級也大於常規的正向用例的優先級，因此本質上優先級應該是：核心功能（正向用例>逆向用例）> 次要功能（正向用例>逆向用例），而針對核心功能

所在模塊：按模塊書寫，一般狀況下，建議 【模塊-子模塊】用例名稱

版本號：用於測試用例的版本管理，每一個測試用例應按照定義的規則設定一個版本號。

測試階段：被測軟件所處的測試階段，包括單元測試、集成測試、確認測試、系統測試、驗收測試等

測試類型：有功能測試、性能測試、安全測試、用戶界面測試、接口測試、安裝測試等，可選擇多項。

附件：對測試用例附加的一些描述信息，例如文本、圖像、模型、與測試用例有關的一些文檔，方便測試人員迚一步理解測試用例。

 

1.2用例編寫

1.層次性

2.明確性

3.可測性

4.可讀性

 

1.層次性

黑盒理論：輸入->處理->輸出

設計應用：測試步驟與預期結果對應

舉例：

測試步驟1--預期結果1

測試步驟2--預期結果2

 

2.完整性

黑盒理論：輸入->處理->輸出

設計應用：對輸出物進行完整的檢驗

舉例：

數據導出，如圖

 

點擊導出--彈出導出確認框

確認導出--可在導出目錄下看到導出文件

---------------如下對步驟每每被忽略-----------------

打開導出文件--導出記錄數正確，內容完整，準確

 

3.可測性

黑盒理論：預期結果 vs 實際結果 ->驗證是否缺陷

設計應用：預期結果必須可測

舉例：

數據查詢

 

選擇目標狀態所有，輸入註冊時間，點擊查詢--列出註冊時間範圍內的的全部學員記錄，數據正確，完整

分析：

情形一：列表的數據不是你本身造的，且測試不接觸後臺數據庫，即數據源不知

這種狀況下，預期結果的「列出全部的」，」數據正確「，」完整「，從何驗證，這樣的預期結果沒實際意義

 

情形二：列表的數據是本身造的或者可經過後臺查詢，即數據源可知

這種狀況下，預期結果的「列出全部的」，」數據正確「，」完整「是可驗證的，有實際意義。

因此這裏要根據實際狀況來寫預期結果，以情形一爲例：

選擇目標狀態所有，輸入註冊時間，點擊查詢--列出學員記錄的註冊時間在給定註冊時間查詢範圍內

 

4.可讀性

1.數據和邏輯獨立性，詳見上面

2.語言描述：儘可能精煉，用詞恰當等

3.規範（我我的不是很贊同）

對用例中用到的元素，輸入數據和非輸入數據如按鈕，控件等，添加標識規範，如輸入數據用｛｝，相似按鈕控件，連接等非輸入數據用【】

 

例子：

在密碼框中輸入｛密碼｝，點擊【登陸】按鈕

關於這點我不是很同意的，有待討論，由於需求什麼都在變，可能這個版本寫「登陸」，下個版本寫「確認」，可是同一個意思，登陸系統，因此我我的比較建議用天然語言描述，好比輸入密碼和用戶名，登陸系統，這樣大大提升用例可複用性。再說了，稍微有點電腦基礎的人，一看界面也應該大體知道相似刪除，登陸，修改之類的元素吧。。。