前言

作為一個測試新人，剛開始接觸測試，對于怎么寫測試用例很頭疼，無法接觸需求，只能根據(jù)站在用戶的角度去做測試，但是這樣情況會導(dǎo)致不能全方位的測試APP，這種情況就需要一份測試用例了，但是不會寫，求指教！還有就是測試出來的bug該如何追蹤？與開發(fā)的接觸基本上面對面的交流，沒有很好的一個規(guī)范

帶著問題學(xué)習(xí)是最高效的學(xué)習(xí)方法。

目錄

前言

一.什么是測試用例

二.為什么要寫測試用例

三.如何編寫測試用例

因此，在介紹如何編寫測試用例之前，先看一個軟件系統(tǒng)登錄功能的測試（如下截圖所示）：

要做這個登錄頁面的測試用例，你會從哪些方面思考進行測試呢？

看似簡單的頁面功能能夠設(shè)計多少條測試用例完成較全面的測試呢？10條以內(nèi)？20條？.......

那么在給出上述答案之前，先帶大家熟悉一下 什么是測試用例？測試用例有什么作用？ 然后在結(jié)合上述拋出的案例拋磚引玉一起討論 如何編寫測試用例？

下面就是此文目錄截圖：

一、什么是測試用例

測試用例：為了特定的目的（證明軟件存在某問題）而設(shè)計的一組由測試輸入、執(zhí)行條件、預(yù)期結(jié)果構(gòu)成的文檔

1、測試用例簡單來說就是指導(dǎo)如何做測試的文檔，該文檔主要記錄需要驗證被測軟件的是否滿足需求

2、測試用例表現(xiàn)形式常見的有兩種，可以以模板形式展示

1）一種是通過Excel直接編寫

——大多數(shù)項目中都需要按照這種方式設(shè)計編寫

2）一種是通過xmind直接整理測試點

——時間緊迫，項目沒有強制要求時，可以設(shè)計測試點的形式編寫

——對于業(yè)務(wù)流程類的測試，也可以整理為測試點進行測試

3、設(shè)計及執(zhí)行人員：測試工程師

4、用例的模板：描述編寫用例核心內(nèi)容，一般項目都有自己的設(shè)計用例的模板，常見測試用例模板可參照如下：

為了支持一下新入行的朋友們，這里也把我入行多年精心整理的上百份學(xué)習(xí)資料和講解視頻分享出來，新手入門絕對用得上，一并放在下面了，廢話不多說，文末免費獲取~

二.為什么要寫測試用例

為什么要寫測試用例，實際中產(chǎn)品出現(xiàn)問題，第一責(zé)任人首先想到的是測試為啥沒有測到？

產(chǎn)品出現(xiàn)問題了，你為啥沒有測出來呢？

當(dāng)然，除了避免“甩鍋和背鍋”，其實寫測試用例更重要的作用如下：

技術(shù)上將需求轉(zhuǎn)化為具體可驗證的指標(biāo)

以文檔的形式記錄軟件可能存在的問題

防止測試過程的活動出現(xiàn)遺漏，提高工作效率

測試工作量的展示

三.如何編寫測試用例

既然寫測試用例如此重要，那么如何更好的編寫測試用例呢？個人認為需要滿足如下幾點： - 常規(guī)思考，設(shè)身處地的從用戶角度出發(fā)（比如：實際用戶是這么使用的么，會不會遇到異常情況呢？） - 測試?yán)碚摲椒ǖ闹危ū热纾焊鶕?jù)需求設(shè)計測試用例時，能用到哪些常見的測試用例設(shè)計方法？） - 產(chǎn)品的熟悉和經(jīng)驗的積累（比如：已經(jīng)有過類型項目經(jīng)驗，曾經(jīng)在某個方面有過問題，當(dāng)時是如何處理的呢？） 上述的設(shè)計用例過程，有個前提，就是對于測試有耐心和毅力，加上日常有意識的思維訓(xùn)練，才會寫出全面的用例。

1、常規(guī)思考

回歸到開篇的問題，對于一個基本的登錄頁面，按照常規(guī)思路能否會想到如下截圖的測試點呢？實際，這些測試點都是源于從用戶角度出發(fā)，結(jié)合需求進行細化設(shè)計的過程。實際測試中是不是只有這些測試點呢？

2、學(xué)習(xí)積累

相信大多數(shù)測試工程師都能夠想到上述基本的測試點，然在實際工作中面對的項目不同，設(shè)計測試用例的顆粒度也有不同的要求，如果針對上述登錄的模塊，更深入一層考慮呢？此時需要對產(chǎn)品的熟悉程度及測試經(jīng)驗的加持，而且這些點的設(shè)計是不斷學(xué)習(xí)、熟悉項目、測試積累中得到的。

3、理論支撐

有了常規(guī)的思考，有了經(jīng)驗的積累，還需要理論的支撐。測試用例畢竟是通過人去思考設(shè)計，這個過程不可避免有疏漏。如何規(guī)避？實際就需要測試?yán)碚摰闹?，個人認為深入思考設(shè)計用例不外乎以下兩方面：

1）測試用例的設(shè)計方法

測試?yán)碚撝泻荜P(guān)鍵一塊就是將需求拆分為具體的測試點，然后根據(jù)用例設(shè)計方法進行具體的設(shè)計，其中拆分需求的關(guān)鍵是熟悉需求，將文檔中已有的描述內(nèi)容，按照用戶使用場景、個人測試經(jīng)驗的積累（如果有的話）、把大段的內(nèi)容拆分成能夠直接用用例設(shè)計方法的測試點，這樣就直接可以通過簡明扼要的文字描述轉(zhuǎn)化為Excel的測試用例，在這個過程通俗理解就是拆分細化的過程，直到可以直接寫用例驗證一個具體的功能點即可。

其中熟知的設(shè)計用例方法有：

- 觀察法

- 等價類、邊界值

- 判定表、因果圖

- 流程圖、場景法

- 錯誤推測法等

2）測試設(shè)計的思路開拓

倘若按照需求將已有的描述信息都已經(jīng)拆分完畢了，是不是就可以確保測試沒有問題了呢？

其實不然，在上述基礎(chǔ)上如果還需要再拓展全面測試，還需要借助于軟件質(zhì)量模型的特性，從這些特性出發(fā)，給予測試用例設(shè)計者更多的思考空間。這樣的設(shè)計就更加的全面可靠。

常見軟件質(zhì)量模型特性說明：

- 功能性：功能有沒有，好不好用

- 性能效率：對應(yīng)系統(tǒng)的資源耗費程度及響應(yīng)時間

- 易用性：容易理解、學(xué)習(xí)、使用

- 兼容性：能夠兼容不同的軟硬件平臺

- 可靠性：不易出問題，萬一出問題容易恢復(fù)

- 安全性：對于用戶的安全保障（外在的人生安全、內(nèi)在的信息安全等）

- 可移植性：能否在不同環(huán)境條件下無故障運行

- 可維護性：對于后期的修復(fù)維護是否方便快捷

因此，對于上述登錄功能，按照上述質(zhì)量模型的思路指導(dǎo)，就得到如下的測試點：

四、寫在最后

此時的你再回過頭來看看，還會認為登錄這個百試不爽的功能就設(shè)計十幾條甚至幾十條測試用例了嗎？顯然不是那么簡單，需要在熟悉需求基礎(chǔ)上，進行拆分細化，將常規(guī)的思考、經(jīng)驗的積累、理論的支撐結(jié)合起來使用，最終才能轉(zhuǎn)化為測試待驗證的結(jié)果。

熟悉需求上第一步，在此基礎(chǔ)上進行測試點的拆分細化，這個過程如果對于復(fù)雜一點的功能點，需要借助于測試用例的設(shè)計方法，對于頁面級的測試點應(yīng)用最多的不外乎是等價類、邊界值。

僅僅熟悉了需要，還需要結(jié)合經(jīng)驗的積累，從質(zhì)量模型的特性出發(fā)，進行全面的思考功能點的設(shè)計，是否出現(xiàn)遺漏的，是否有項目特殊要求的。

用例的設(shè)計不是一蹴而就的事情，好的用例也是需要不斷的練習(xí)，反復(fù)的修改評審，才能編寫出卓越的用例。

福利福利

如果你還有許多困惑，那么我整理的視頻資源和文檔會是你的良師益友，或許可以給你帶來一些實際性的幫助與突破【保證100%免費】

獲取方式：點贊+評論學(xué)習(xí)