1.測試用例的要素

測試用例是為了實施測試而向被測試的系統(tǒng)提供的一組集合, 這組集合包含 : 測試環(huán)境, 操作步驟, 測試數(shù)據(jù), 預(yù)期結(jié)果等要素.

例如 : 在 B 站輸入框輸入一個空格, 檢查結(jié)果

測試用例

標題 : 輸入框輸入空格
測試環(huán)境 : Windows 系統(tǒng), 谷歌瀏覽器-版本 111.0.5563.65（正式版本） （64 位）
操作步驟 :
1) 打開瀏覽器, 輸入網(wǎng)址 : https://www.bilibili.com/
2) 在輸入框中輸入關(guān)鍵詞, 回車展示結(jié)果
測試數(shù)據(jù) : 空格
預(yù)期結(jié)果 : 不展示任何內(nèi)容

2. 設(shè)計測試用例的萬能思路

2.1 設(shè)計測試用例的萬能公式

功能測試 + 性能測試 + 界面測試 + 兼容性測試 + 易用性測試 + 安全測試

功能測試 : 對產(chǎn)品的功能設(shè)計測試用例.
性能測試 : 極端情況: 高并發(fā)量, 響應(yīng)時間等等. (功能測試沒用問題不代表性能測試好)
界面測試 : 每個元素的大小, 顏色, 材質(zhì), 形狀, 頁面跳轉(zhuǎn)等都需要進行測試.
兼容性測試 : 軟甲的不同版本是否兼容, 不同的瀏覽器, 不同的系統(tǒng)版本, 數(shù)據(jù)兼容性等等.
易用性測試 : 產(chǎn)品是否具備簡單易上手的屬性.
安全測試 : 用戶的隱私數(shù)據(jù)是否加密 (注冊場景, 接口返回值, SQL 注入等等).

使用萬能公式針對水杯設(shè)計一個測試用例

使用萬能公式針對登錄頁面設(shè)計一個測試用例

兼容性測試里需要注意 : 不同的瀏覽器, 不同的版本可能會有非常非常的多, 難道所有的瀏覽器和版本我們都需要測試嗎 ? 我們的選型標準是什么 ?

1. 測試大部分用戶使用的瀏覽器
2. 在工作中是有數(shù)據(jù)后臺可以檢測到和管理大部分用戶使用的瀏覽器, 版本或者手機型號, 參考數(shù)據(jù)管理平臺給出的數(shù)據(jù)選型.

3. 基于需求進行測試用例的設(shè)計

基于需求設(shè)計測試用例是設(shè)計和開發(fā)測試用例的基礎(chǔ)，第一步就要分析測試需求，驗證需求是否正
確、完整、無二義性，并且邏輯自洽。在需求正確的基礎(chǔ)上再細化測試需求，從測試需求提煉出一個個測試點，然后根據(jù)每一個測試點進行測試用例的設(shè)計；

在分析測試需求時，一般分為功能測試需求和非功能測試需求

功能需求測試分析

功能測試需求主要是各個功能界面的驗證, 功能的一致性, 交互性的測試, 功能的錯誤操作, 異常操作的測試, 用戶操作的易用性, 用戶體驗, 往往結(jié)合功能測試同時驗證等等.

非功能需求測試分析

非功能需求主要涉及性能, 安全性, 可靠性, 兼容性, 易維護性和可移植性等. 從測試需求分析來看，每一類非功能特性測試都需要根據(jù)需求單獨分析。他們之間可能會存在相互影響，比如安全性越高，就越有可能給易用性，性能帶來更大的挑戰(zhàn).

4. 測試用例的具體設(shè)計方法

4.1 等價類

依據(jù)需求將輸入劃分為若干個等價類，從等價類中選出一個測試用例，如果這個測試用例測試通過，則認為所代表的等價類測試通過，這樣就可以用較少的測試用例達到盡量多的功能覆蓋，解決了不能窮舉測試的問題.

等價類的劃分

1.有效等價類 - 需求文檔的要求是有意義的集合.
2. 無效等價類 - 需求文檔的要求是沒有意義的集合.

例如針對一個 6~18 位的密碼使用等價類方法設(shè)計測試用例, 具體步驟 :

1.確認有效等價類和無效等價類.

有效等價類 : 6~18位
無效等價類: 小于 6 位, 大于 18 位

2. 編寫測試用例

1. 輸入長度為 6~18 位的密碼, 例如 : 10 位
2. 輸入長度小于 6 位的密碼, 例如 : 1 位
3. 輸入長度大于 18 位的密碼, 例如 : 20 位

4.2 邊界值

邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等
價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界.

邊界值指的是有效邊界 + 無效邊界

4.3 判定表

使用場景 : 輸入條件的組合對應(yīng)不同的結(jié)果

判定表設(shè)計測試用例的步驟 :

1. 確認輸入條件和輸出條件
2. 找出輸入條件和輸出條件之間的關(guān)系
3. 畫判定表
4. 根據(jù)判定表編寫測試用例

測試案例 : 當(dāng)某訂單使用了紅包或者訂單金額大于 300 元, 則該訂單是優(yōu)惠訂單, 否則是不優(yōu)惠的訂單

1.確認輸入條件和輸出條件

輸入條件 : 紅包(A) , 訂單金額大于300元(B) , 訂單已提交(C)
輸出條件 : 有優(yōu)惠(1) , 無優(yōu)惠(2)

2. 找出輸入條件和輸出條件之間的關(guān)系

先確定輸入條件之間可能的組合關(guān)系, 然后根據(jù)組合關(guān)系, 給出對應(yīng)的輸出結(jié)果.

AC BC ABC A B C AB 非ABC

1 1 1 2 2 2 2 2

3.畫判定表

4. 根據(jù)判定表編寫測試用例

1) 有紅包并提交訂單, 則該訂單為有優(yōu)惠的訂單.

2) 金額大于 300 元并提交訂單, 則該訂單為有優(yōu)惠的訂單.

3) 有紅包, 金額大于 300 元并提交訂單, 則該訂單為有優(yōu)惠的訂單.

4) 有紅包, 訂單金額小于 300 元, 不提交訂單則該訂單為無優(yōu)惠訂單.

5) 無紅包, 訂單金額大于 300 元, 不提交訂單則該訂單為無優(yōu)惠訂單.

6) 無紅包, 訂單金額小于 300 元, 提交訂單, 則該訂單為無優(yōu)惠訂單.

7) 有紅包, 訂單金額大于 300 元, 不提交訂單則該訂單為無優(yōu)惠訂單.

8) 無紅包, 訂單金額小于 300 元, 不提交訂單則該訂單為無優(yōu)惠訂單.

4.4 場景法設(shè)計法

可以比較生動地描繪出事件觸發(fā)時的情景, 有利于測試設(shè)計者設(shè)計測試用例, 是測試用例更容易理解和執(zhí)行. (思路引導(dǎo)作用)

例如拿 ATM 取款為例 :

編寫測試用例 :

基本事件流的用例 : 先插卡, 輸入正確的密碼, 選擇取卡功能, 輸入金額 .......
備選事件流的用例 : 插卡插不進去, 輸入錯誤的密碼, 卡被 ATM 卡出, 退出來.....

4.5 正交排列法

正交排列法是從大量的試驗中挑選出適量的, 有代表性的點, 依據(jù) "正交表" 從而合理的設(shè)計出測試用例.

正交法的目的是為了減少用例數(shù)目, 用盡量少的用例覆蓋輸入的兩兩組合. (因為用例多的時候, 使用判定表法, 兩兩組合的情況是窮舉不完的)

下圖正交表的表示形式, L9(4^3)

9 代表 9 組實驗
4 代表的是因素數(shù)
3 代表的是每個因素數(shù)對應(yīng)的水平數(shù) (輸入條件的可能選項)

正交表的特性

1. 每一列中, 不同的數(shù)字出現(xiàn)的次數(shù)相等.
2. 任意兩列中數(shù)字的排列方式齊全且均衡 (每個組合出現(xiàn)的次數(shù)相同, 例如第一列和第三列的第 2 行, 是 1,2 組合, 那么這兩列組合的其他行就不會再出現(xiàn) 1,2 組合了)

案例 : 針對注冊頁面使用正交排列法設(shè)計測試用例.

設(shè)計測試用例的步驟 :

1. 找出因素數(shù)和水平數(shù)

因素 : 姓名, 電子郵箱, 密碼, 確認密碼, 驗證碼
水平 : 填寫, 不填寫

2. 使用 allpairs 工具生成正交表

a. 在excel 中寫好對應(yīng)的因素數(shù), 和水平數(shù)
b. 在 pairs 工具的安裝路徑下找到 allpairs.exe, 然后在改路徑下新建一個 txt 文件, 把excel 中寫好的 因素數(shù)和水平數(shù)復(fù)制張貼到 txt 文件中.
c. 打開 cmd, 進入到剛剛新建的 txt 路徑的商機路徑中, 也就是 pairs. 執(zhí)行命令
allpairs.exe 322.txt>322jg.txt (322.txt是我自己新建的txt文件, 322jg.txt 是待生成的正交表文 件, 不用自己創(chuàng)建)

allpairs 生成的正交表

生成的正交表雖然有些不符合正交表的特性 2, 但是問題不大.

3. 根據(jù)正交表編寫測試用例

1. 全部填寫姓名, 電子郵箱, 密碼, 確認密碼, 驗證碼.
2. 填寫姓名, 不填寫電子郵箱, 密碼,確認密碼, 驗證碼.
3. 填寫電子, 確認密碼, 不填寫郵箱, 密碼, 驗證碼.
4. 填寫密碼,驗證碼, 不填寫姓名, 電子郵箱, 確認密碼.
5. 填寫姓名, 電子郵箱, 密碼, 不填寫確認密碼, 驗證碼.
6. 填寫確認密碼, 驗證碼, 不填寫姓名, 電子郵箱, 密碼.

4. 補充可能存在遺漏的但是非常重要的測試用例

7.全部都不填寫姓名, 電子郵箱, 密碼, 確認密碼, 驗證碼.

只有第一個用例是正常的用例.

4.6 錯誤猜測法

錯誤猜測法主要依賴測試人員的工作經(jīng)驗和積累.這個方法的缺點是難以系統(tǒng)化，并且過度依賴個人能力.

案例 : 以注冊為例

1、校驗中特殊字符空格的處理?
2、密碼校驗中的大小寫？
3、姓名中的特殊字符？
4、密碼發(fā)送是否明文

5. 白盒測試, 黑盒測試, 灰盒測試

黑盒測試 : 純功能測試, 不關(guān)心程序具體是怎么實現(xiàn)的. (系統(tǒng)測試)
白盒測試 : 關(guān)注程序的內(nèi)部實現(xiàn) (單元測試)
灰盒測試 : 介于白盒測試和黑盒測試之間 (集成測試)

5.1 常見面試題

為什么不能讓灰盒測試取代黑盒測試和白盒測試 ?

灰盒測試沒有白盒測試那么詳盡, 灰盒測試沒有黑盒測試覆蓋產(chǎn)品的廣度大, 所以灰盒測試不能取代黑白盒測試.

哪種測試方法用的多 ?

黑盒測試和白盒測試, 測試人員都會使用到, 在工作中需要結(jié)合實際情況來定, 通過場情況下對于測試人員來說, 黑盒測試相對要多一些.