測試用例的設計思路

本文以最多見的幾種測試場景來展開討論如何設計出更爲高效且覆蓋面更爲全的測試用例。

 

在討論前，咱們先來大概瞭解下目前行業裏經常使用到的幾種測試用例的設計方法，目前主流的測試用例設計方法有以下幾種

 

1 測試用例經常使用設計方法

1.1 等價類劃分法

此設計方法算是黑盒測試中用得最多的一個了，並且此方法經常與其餘方法一塊兒來設計測試用例，經常使用的組合就是與邊界值劃分法；

 

定義：等價類劃分法是把全部可能輸入的數據劃分紅若干部分，而後從每個部分選取少數具備表明性的數據做爲測試用例。

 

劃分標準：

1. 完整性，即被劃分的各個部分測試數據共同組成了全部可能輸入的數據。
2. 排他性，即每一個部分的測試數據原則上來講，不該該有重疊部分。

 

劃分方法：

1. 在輸入條件規定了取值範圍或值的個數的狀況下，則能夠劃分爲一個有效等價類和二個無效等價類
2. 在輸入條件規定了輸入值的集合或規定了必須如何的條件下，則可劃分爲一個有效等價類和一個無效等價類
3. 在輸入條件是一個布爾量的狀況下，可劃分爲一個有效等價類和一個無效等價類
4. 在規定了輸入數據必須遵照的規則狀況下，可劃分爲一個有效等價類和若干個無效等價類（從不一樣角度違反規則）
5. 在規定了輸入數據爲一組值，每一個值分別處理不一樣狀況，則可肯定n個有效等價類和一個無效等價類
6. 假如在已經確認已劃分的等價類中各元素在程序處理中的方式不一樣狀況下，則需將該等價類進一步的劃分爲更小的等價類

 

1.2 邊界值分析法

        此方法根據也是特別經常使用的一種設計方法了，寫過代碼或者有豐富測試經驗的同窗應該知道，代碼中的判斷邏輯是很是多的，越是複雜的業務流程，判斷邏輯就越多。就算有豐富經驗的開發者，在進行判斷邏輯代碼的時候也會有所疏忽，尤爲是哪些欠缺開發經驗的同窗來講，就更容易忽略某些邊界問題了。

 

       定義：邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。一般邊界值分析法是做爲對等價類劃分法的補充，這種狀況下，其測試用例來自等價類的邊界。

 

      分析：大量的錯誤是發生在輸入或輸出範圍的邊界上，而不是發生在輸入輸出範圍的內部。所以針對各類邊界狀況設計測試用例，能夠查出更多的錯誤。使用邊界值分析方法設計測試用例，首先應肯定邊界狀況。一般輸入和輸出等價類的邊界，就是應着重測試的邊界狀況。應當選取正好等於，剛剛大於或剛剛小於邊界的值做爲測試數據，而不是選取等價類中的典型值或任意值做爲測試數據。

 

1.3 場景分析法（流程圖法）

        隨着系統功能愈來愈多，業務愈來愈複雜，這時候爲了更好的進行測試，確保全部業務流程都能被覆蓋測試到，這時候引入場景分析法就很是有必要了。

 

       定義：如今的軟件幾乎都是用事件觸發來控制流程的，事件觸發時的情景便造成了場景，而同一事件不一樣的觸發順序和處理結果就造成事件流。

 

1.4 經驗推斷法

        隨着測試人員對系統的不斷熟悉，對業務的理解不斷加深，對程序員的不斷了解，有時候就能夠有針對性的去驗證是否存在某個問題。

 

1.5 因果圖法

        等價類劃分法和邊界值分析方法都是着重考慮輸入條件，但沒有考慮輸入條件的各類組合、輸入條件之間的相互制約關係。這樣雖然各類輸入條件可能出錯的狀況已經測試到了，但多個輸入條件組合起來可能出錯的狀況卻被忽視了。

若是在測試時必須考慮輸入條件的各類組合，則可能的組合數目將是天文數字，所以必須考慮採用一種適合於描述多種條件的組合、相應產生多個動做的形式來進行測試用例的設計，這就須要利用因果圖（邏輯模型）。

 

 

定義：因果圖法是一種利用圖解法分析輸入的各類組合狀況，從而設計測試用例的方法，它適合於檢查程序輸入條件的各類組合狀況。

 

其餘幾種方法不經常使用，就不介紹了，若有須要再去學習瞭解便可。

 

2 設計思路概況

上面咱們大概瞭解了下各個測試用例設計方法，接下來就開始以實際例子來講明如何更高效的設計測試用例了。

2.1 web登陸頁面的測試

         分析：首先咱們能夠分析一下，該界面都有哪些哪些元素，每一個元素又具有哪些規則要求，是否有其餘特殊化要求，好比緩存，加密等；分析完畢後，咱們就能夠根據瞭解到的去選擇合適的測試用例設計方法，對這個頁面進行用例的編寫。

 

原型圖：

 

 

需求：

1. 支持工號密碼和APP端掃一掃登陸
2. 支持緩存帳號密碼信息，下次免輸入登陸
3. 密碼不管是前端仍是緩存仍是傳輸過程當中，須要加密處理
4. 支持驗證碼圖片點擊更換
5. 支持登陸界面不一樣語言顯示，且有記憶上次更換功能
6. 其餘的要求就如同所示

 

拿到上述需求和原型圖後，咱們就能夠開始着手分析而後去設計測試用例了。

 

2.1.0 UI界面測試

       首先對於用戶來講，對一個系統的評價，首先從界面視覺方面去判斷，就比如男女之間的第一次見面，嗯，你想的沒錯，就是相親，第一印象基本上是從我的長相，精神面貌來的，咱們都知道第一印象很重要，尤爲是在現在這個快節奏的社會；

       對於一個用戶來講，界面的風格，人機交互性，易理解性，易操做性等將直接印象用戶的第一使用體驗，假如第一使用體驗都很差了的話，假如該產品不是不可替代性的產品的話，用戶頗有可能就此流失掉，假如該系統是用戶已經付費了的，雖然很差看的頁面，難於操做的頁面，難於理解的頁面不會立刻致使客戶退貨，但起碼會使該用戶產生一種一點都不專業的感受，接下來用戶極可能帶着一種不愉快的心情去操做了，這就頗有可能致使各類各樣的刁難挑刺，最終致使完全對該產品失去興趣，要不就是打回要求從新調整，要不就是退回退款。

      大部分產品開發過程當中，在前期需求肯定及評審過程當中就會這方面進行必定討論研究，因此建議測試同窗在需求階段就要介入進去，從界面風格，人機交互性，易理解性，易操做性等幾方面去進行審視，給出比較不錯的建議。

 

      而後接下來就是對系統的業務功能進行測試了，業務分析了下，就是個登陸功能，二種登陸模式，其中工號登陸頁面上有三個輸入框，一個下拉框，一個圖片按鈕，一個文字按鈕，一個登陸按鈕；掃一掃登陸頁面就上面就一個二維碼。

       根據通常的測試套路，咱們先是進行基本的功能測試，只有基本的功能實現了，咱們纔有意義去進行其餘方面的測試。

備註：掃一掃登陸頁面因爲過於簡單就不在此進行闡釋了

2.1.1功能測試

        結合咱們所掌握到該頁面的相關需求知識以及咱們後期拓展到的隱性需求（最好在需求階段就提出來），提煉出咱們所須要的測試點，而後再結合咱們所掌握的測試用例設計方法進行測試用例的編寫。

 

如下就是提煉出的測試點：

                   1.輸入框的空值登陸

                   2.輸入框的空格測試

                           a.帳號密碼輸入框先後中間有空格是否有過濾處理處理

                   3.有效帳號密碼等信息登陸

                   4.無效帳號密碼信息登陸

                                 a.正確帳號，錯誤密碼

                                 b.不存在的帳號，A帳號的密碼

                                 c. A帳號，B帳號的密碼

                  5.密碼特殊要求測試 

                                a.在輸入框內是否密文展現

                                b.是否可從外部複製到輸入框

                                c.是否可從密碼輸入框複製密碼出去

                                d.密碼防破解機制驗證

                                e.密碼在傳輸過程當中及日誌信息中是否作了加密處理

                                f.密碼在數據庫表中是否以加密形式保存

                                g.密碼信息是否會被瀏覽器所記住並保存    

                    6.驗證碼測試

                                a.輸入正確的驗證碼登陸

                                b.驗證碼輸入框置空登陸

                                c.輸入錯誤的驗證碼登陸

                                e.輸入過期的驗證碼登陸

                                f.圖片刷新機制是否合理

 

                     7.帳號密碼記憶保存測試

                                a.正確帳號密碼登陸成功後記憶保存

                                b.正確帳號錯誤密碼登陸失敗後是否只保存帳號信息

                                c. 錯誤帳號登陸錯誤密碼登陸失敗是否會保存

                                d. 正確帳號，密碼置空登陸，是否會保存帳號信息

                                f. 記憶保存有效時間驗證

                                g. 手動清除緩存是是否仍然保留登陸信息

 

                    8.同時登陸測試

                                a.一個帳號可否在同一瀏覽器上同時登陸

                                b.一個帳號可否在同一臺機器上不一樣瀏覽器同時登陸

                                c.一個帳號可否在不一樣機器上同時登陸

                                d.一個帳號可否在web端和移動app端同時登陸

                               e.二個帳號可否在同一瀏覽器上同時登陸

                               f.二個帳號可否在同一臺機器上不一樣瀏覽器同時登陸

                   9.默認語言的記憶測試

                              a.修改界面語言選項，成功登錄後，下次登陸是否會記憶上次保存的語言

                              b.修改界面語言選項，登陸失敗後，當前頁面是否會保存修改的語言

                              c.修改界面語言選項，登陸失敗後，關閉瀏覽器，下次打開登陸是否保存上次的語言選項

                   10.輸入框長度限制測試

                   11.輸入框可輸入類型測試

 

2.1.2 友好及易操做性測試

     1.在輸入框內可否使用windows經常使用快捷鍵，好比複製粘貼，tab切換，回車等

     2.在輸入框內可否切換大小寫，輸入法，且切換後是否有相應提示

     3.網絡異常時，是否有友好加載頁面提示

     4.各類登陸失敗狀況下的提示是否友好，清晰，易懂。

 

2.1.3 健壯性測試

      1.對瀏覽器程序進程殺死，從新打開瀏覽器，已輸入的登陸信息是否還在

      2.登陸頁面與其餘頁面頁籤之間的切換以及縮小到後臺，已輸入的登陸信息是否還在

      3.假如快速屢次點擊登陸按鈕界面是否仍然正常顯示及提示

      4.假如快速進行屢次刷新操做，界面是否仍然顯

 

2.1.4 安全測試

      1.帳號密碼框是否屏蔽SQL注入攻擊

      2.帳號密碼輸入框是否禁止腳本輸入（避免XSS攻擊）

      3.登陸是否有防破解機制

      4.密碼的緩存信息是保存在cookies中仍是session中

      5.密碼在任何場所是否都是加密形式展現的

 

2.1.5 性能測試

      1.打開登陸頁面所花的時間是否知足要求

      2.點擊登陸按鈕進入到登陸成功後的頁面所花時間是否知足要求

      3.支持多少人同時正常打開，同時正常登陸操做

 

2.1.6 兼容性測試

      1.主流的瀏覽器及各版本，是否很好的兼容該頁面

      2.不一樣的操做平臺及各版本是否正常使用

      3.不一樣屏幕分配率是否合理的顯示該頁面

     4.放大縮小狀態下界面顯示是否正常

 

2.2 一個水杯的測試（以喝水的杯子爲準）

        以此例子來講明，通常咱們的測試思路能夠怎麼展開，其實和上個例子同樣的思路，再舉例說下這個例子，是用來講明做爲測試同窗來講，具有很強的邏輯概括能力，很強的發散思惟能力，及很強的產品用戶思惟能力是很重要的。

 

2.2.1 UI界面測試

      1.總體形狀外觀是否符合用戶審美觀

      2.杯身圖案是否符合用戶需求，是否涉及到民族，倫理道德，商業侵權等會引發糾紛的標識

2.2.2功能測試

      1.可否正常裝水

      2.可否正常喝水

2.2.3 易用性測試

      1.杯子是否容易裝水

      2.杯子是否容易出水

      3.杯子是否很方便的拿放（體積質量是否合理）

 

2.2.4 健壯性測試

      1.當水裝過滿的時候，是否有預防水漫出的機制

     2.當水喝的幾乎沒有的時候，剩下的一點點水是否可以順利的喝到

     3.當水杯不當心打翻時候，是否很好的避免水流出

     4.當用戶手溼滑時候，是否也可以順利拿起放下杯子

 

2.2.5 安全測試

      1. 製做杯子的材料是否會對用戶形成損害

      2. 當杯子不當心打碎的時候，碎片是否會傷害到用戶

      3. 當裝的水過熱或者過冷的時候，是否會對用戶形成傷害

      4. 當杯子因爲外部緣由被加熱過或者被冰凍過，是否會對用戶形成傷害

      5. 當杯子長時間裝水狀態下，是否會滋生細菌或產生危害到用戶的事務

      6. 當杯口以及杯身出現裂痕的時候，是否會對用戶形成割傷

      7. 當杯子放進微波爐時，杯子是否會發生爆炸或融化

 

2.2.6 性能測試

      1. 杯子在長時間震動下是否會破碎

      2. 杯子在長時間裝水狀態下是否發生漏水

      3. 當用戶使用杯子時用力過猛狀況下，杯子是否會破碎

      4. 當杯子不當心摔下的時候，是否會發生破碎變形現象

      5. 當杯子裝入過熱或過冷的水時，杯子是否會發生破裂等事故

      7. 當杯子用久了，杯身是否會掉色，杯體是否會發生變形，褪色等

2.2.7 兼容性測試

      1. 杯子除了裝水外，是否還能裝其餘液體。

      2. 杯子除了裝液體外，是否還能裝固體

      3. 杯子是否能液體和固定的混合物

      4. 杯子是否能夠在一些特殊場合使用

 

歡迎各位大佬補充進來補充, 後續再慢慢補充……