軟體測驗

一、軟體測驗初階

軟體測驗：驗證一個軟體是否滿足用戶所提出的需求，不以軟體測驗人員的主管意愿去判斷軟體的質量，軟體測驗遵循一定的行業標準，

軟體測驗按是否運行程式分為：動態測驗與靜態測驗

軟體測驗左移：需求之前的調研階段和需求階段，測驗人員參加
軟體測驗右移：產品上線后，系統監控、日志記錄分析

軟體測驗與開發的區別是什么?

區別主要有以下3幾個方面：

1）從軟體測驗與研發中除錯對比來看：

目的存在區別：軟體測驗是驗證軟體測質量，發現程式的缺陷，判斷軟體是否滿足了用戶的需求，也就是說以用戶需求為導向；軟體開發中的除錯是開發人員檢查某程式是否實作了他想讓程式實作的預期功能，

人員存在區別：測驗主要是由測驗人員和開發人員來執行，黑盒測驗主要由測驗人員完成、單元/集成測驗（白盒測驗）主要是由開發人員執行，除錯由開發人員完成，

開發階段存在區別：軟體測驗貫穿在軟體的整個軟體開發生命周期當中；軟體除錯只存在于開發階段，（軟體發開的生命周期：需求分析 計劃 設計 開發 測驗 運行 ）

2）從難易程度來看：

軟體開發廣度小，專業度高；軟體測驗廣度大，專業度低，

3）從技能要求程度來看：

軟體測驗要求更廣泛：業務能力，測驗手段和工具使用，用戶模型分析和理解，一定編程能力；軟體研發：思維邏輯能力，業務處理能力，較好的編程能力，

測驗人員需要具備哪些優秀品質？

1）對測驗行業感興趣，興趣使然；

2）有良好的溝通交流能力；

3）有不斷學習的狀態和快速的學習能力；

4）有較強的抗壓能力和責任心：測驗往往是產品的最后一個檢驗者，測驗的作業成效很難衡量，測驗用例執行、bug數目的多少都無法說明產品是否能夠交給用戶使用，所以，責任感是最重要的測驗必備素質之一，就壓力而言，來自開發人員、用戶、上級、自己的壓力；

5）思維模式：逆向思維模式：比如手機中的短信資訊，一致洗掉，數量為0時依舊洗掉；有發散性思維：測驗一臺自動售歡訓，對外觀、壓力、耗電量、易用性、斷電情況、輸入金額等要測驗，需要考慮多方面，因此發散思維一定要培養出來，

做測驗的驅動力是是什么？

（結合自身）興趣使然 性格合適 在班級中擔任班長 有良好的組織溝通交流能力 有一定的編碼能力 這些因素讓我覺得我做測驗比較合適，

二、軟體測驗基礎

需求

我們根據一個具體的例子，分析需求：

舉例：在社交APP上發朋友圈，類似微信朋友圈、qq空間這種
需求（發送朋友圈）–> 分析/設計（產品經理列出出功能、權限）–> 開發（開發人員根據具體的功能實作細節，文字/圖片形式進行開發）–> 測驗 --> 上線

用戶需求：讓APP擁有發布朋友圈這項功能，總體看起來比較簡單，

軟體需求：對用戶需求具體細化，是用戶需求的具體實作細節，開發人員根據軟體需求開發，

需要注意的是：軟體需求是用戶需求轉化而來的

軟體開發中的需求一般指的是：滿足用戶的期望或者合同規定的的標準、規范、檔案所需要的條件和權限，

測驗用例定義

軟體測驗：向被測驗系統發起的一組集合，這組集合包含測驗資料、測驗步驟、測驗平臺、預期結果，

舉例：網易郵箱注冊測驗用例設計

軟體開發模型

瀑布模型

適用的專案：需求比較穩定的專案 ；
優點：各個階段比較獨立，看重需求分析和軟體測驗；
缺點：無法適應需求的變化，，測驗在編碼后才去執行，導致前期的問題無法及時發現，無法及時修正缺陷，

螺旋模型

適用的專案：前期需求不是很明確，有風險，專案比較龐大的系統；
優點：強調軟體質量，每一次迭代進行嚴格的風險分析，討論專案是否有必要進行下去；
缺點：引入風險管理，會投入大量的人力和物力，

迭代、增量模型

比如一個系統4個功能模塊A B C D，要在兩周時間完成；
對于迭代模型來說：第一周開發人員先完成A B C D四個模塊的基本功能，第二周在基礎功能上進行細化完善； 優點：抗風險能力強
對于增量模型來說：第一周完成A B模塊開發，第二周完成 C D模塊開發，

敏捷模型

敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟體開發

目標：交付一個高質量可用軟體；
特點：輕檔案，輕流程，重目標，重質量；
優點：可以適應需求的變化；
缺點：由于專案周期長，很難保證開發人員不更換，沒有檔案就會造成在交接程序中出現很大的苦難，

Scrum敏捷開發

軟體測驗模型

軟體測驗模型有兩種，分別是V模型和W模型

V模型

優點：開發的每一個階段和測驗的每一個階段相對應，開發每個階段是測驗依據；

缺點：測驗流程介入比較晚，前期錯誤和風險后期才發現，失去及時糾正的機會，

W模型

優點：開發階段和測驗階段獨立分布在兩個V模型中，測驗在專案前期就接入，前期的問題可以被發現；

缺點：W模型的每一個階段仍然是串行的程序，不能適應需求變化的專案，因此無法應用到敏捷開發，

軟體測驗生命周期

每一個階段的具體內容：

需求分析：分析需求，細化需求，驗證需求的正確性和合理性；

測驗計劃：計劃測驗人員數量、測驗時間、測驗范圍、測驗目的等；

測驗設計/開發：分析需求，從細化的需求中提煉功能點，設計測驗用例；

測驗執行：執行測驗用例，記錄BUG；

測驗報告：測驗范圍，測驗用例數量，執行了多少，發現多少BUG，修改多少BUG，還有多少BUG未解決及解決方案，

軟體測驗中BUG

BUG分類

第一種：當軟體需求存在且合理時，如果開發的軟體功能和軟體需求規格不相符合，我們稱這種情況為軟體錯誤BUG，

第二種：當軟體需求不存在的時候，用戶需求存在且合理，但是軟體功能和用戶需求不相符合，我們稱這種情況為軟體錯誤BUG，

怎么描述一個BUG？

通過六部分內容去描述一個BUG：

1.代碼的版本號
2.測驗環境（測驗平臺）
3.測驗步驟
4.實際結果
5.預期結果
6.附件（包含錯誤日志、截圖等）

通過網易郵箱注冊描述一個bug：

BUG級別

BUG級別分為4種：

1）崩潰
系統運行阻斷，嚴重影響開發人員和測驗人員的的作業，需要馬上修復；

2）嚴重
系統可以運行，但是已經不穩定了，如果繼續運行下去，將產生嚴重后果；（如直播畫面失真、密碼明文顯示）

3）一般
系統可以穩定運行，但是一些功能還沒有實作，影響了用戶的體驗；（比如查詢功能，同一條資料在不同頁都有顯示，這是由于沒有對資料排序，導致翻頁查詢出現這個問題）

4）次要（建議）
影響用戶的視覺體驗，比如界面提示內容，圖片排版等，

BUG的生命周期

BUG的宣告周期：BUG被發現到BUG被解決的程序，

BUG的處理流程圖（生命周期圖）

問題1：

問題2：

三、測驗用例設計

測驗用例元素

測驗用例元素：向被測驗系統發起的一組集合，這組集合包含測驗資料、測驗步驟、測驗平臺、預期結果，

測驗用例設計方法

Ⅰ.基于需求的測驗用例設計

根據需求設計測驗用例：
驗證需求的正確性；細化需求，從需求中提煉出功能模塊，劃分子功能，根據每個子功能設計測驗用例，

用戶需求測驗：

用戶購買3000元以內的華為智能手機
價格：小于等于3000 3000 2999 3001
手機：智能手機
品牌：華為
基本功能測驗：打電話 發短信 安裝APP 連網

軟體需求測驗：

若用戶沒有收到激活郵件，可以在登錄界面錄入電子郵件賬號和密碼后，再次發送激活郵件

每次發送激活郵件后，激活郵件只在24小時內有效，超過24小時需要重新發送激活郵件

Ⅱ.具體設計測驗用例的方法

1.等價類

等價類：把輸入（特殊情況下考慮輸出）劃分成若干個等價類，從每一個等價類中選一個測驗用例進行測驗，如果測驗用例通過，則表明測驗用例所代表的等價類測驗通過，

等價類分為兩種情況

有效等價類：符合需求規格說明，這樣有意義的輸入資料集合，稱為有效等價類；
無效等價類：不符合需求說明的輸入資料集合，稱為無效等價類，

舉例：注冊功能中輸入用戶名，要求長度6-15位，輸入為字符型別，不區分大小寫

根據長度劃分：
有效等價類：郵箱地址長度在6-15位
無效等價類：長度小于6位或者長度大于15位

根據字符型別劃分：
有效等價類：A ~ Z，a ~ z，大小寫混合
無效等價類：漢字 特殊符號 標點符號 空格 大小寫字母與其他字符混合

2.邊界值

針對輸入和輸出的邊界進行測驗用例的設計，

比如上面的用戶名輸入，我們已經知道有效等價類和無效等價類

有效等價類：郵箱地址長度在6-15位
無效等價類：長度小于6位或者長度大于15位
邊界值是 5 6 7 以及 14 15 16，可以看出邊界值是某個值以及它的左值和右值，

通過一個代碼再認識一下邊界值：

if(x <= 100){
	System.out.print("x小于等于100");
}else if(a > 100 && a < 1000){
	System.out.print("x在100和1000之間");
}else{
	System.out.print("x大于等于1000");
}

在這個代碼中，邊界值有99 100 101，999 1000 1001

3.因果圖法

因果圖是一種邏輯圖，包含恒等、、與、或、非這些關系，當輸入有很多時，不同的輸入之間組合對應著不同的輸出，此時這種情況需要用因果圖分析不同輸入組合和不同輸出之間的關系，

因果圖法設計測驗用例的步驟：

1.分析所有的輸入和輸出
2.找出輸入和輸出之間的邏輯關系
3.根據輸入和輸出之間的邏輯關系畫因果圖
4.根據因果圖畫判定表
5.根據判定表設計測驗用例

因果圖法習題練習：現在有淘寶618活動，訂單已經提交情況下，如果訂單合計總金額大于300元或者訂單有紅包，則最終有優惠，
1）首先分析輸入輸出
輸入：訂單提交，訂單未提交，金額大于300，金額小于300，有紅包，沒有紅包
輸出：有優惠，沒有優惠
2）輸入組合與輸出之間的邏輯關系
訂單提交，金額大于300，有紅包，有優惠
訂單提交，金額大于300，沒有紅包，有優惠
訂單提交，金額小于等于300，有紅包，有優惠
訂單提交，金額小于等于300，沒有紅包，沒有優惠
3）畫因果圖

4）畫判定表

5）寫測驗用例
訂單已提交，金額大于300，有紅包，有優惠
訂單已提交，金額大于300，沒有紅包，有優惠
訂單已提交，金額小于等于300，有紅包，有優惠
訂單已提交，金額大于300，沒有紅包，沒有優惠
訂單未提交，金額大于300，有紅包，沒有有優惠
訂單未提交，金額大于300，沒有紅包，沒有優惠
訂單未提交，金額小于等于300，有紅包，沒有優惠
訂單未提交，金額小于等于300，沒有紅包，沒有優惠

4.正交法

正交法是研究多因素多水平的一種實驗方法，根據正交性，從輸入組中選擇最優的組合進行試驗，通過這些最優組合得出的試驗結果去分析整個實驗的結果，
因素：輸入的變數 水平：變數的取值

正交法依賴于正交表實作，正交表是由行和列構成的，其中列代表因素數也即是變數的個數，行表示為：L = （水平數）*因素數+1，水平數指的是每個變數最大值的個數，

正交表的性質：
1.每一列不同資料出現的次數一致
2.任意兩列不同資料的組合出現的次數相同

正交表設計測驗用例的步驟：
1.確定所有的輸入（輸入指的是不同的變數）
2.確定每一個變數的取值個數
3.確定因素數（列），水平數，正交表的行
4.根據正交表的性質，把變數的值映射到表中
5.寫測驗用例，正交表的每一行就是一個測驗用例
6.補充正交表中沒有的但是你認為可能出現的測驗用例

正交法練習：注冊功能，輸入姓名，郵箱，郵箱密碼，確認密碼和驗證碼
分析：只需呀考慮每一個變數輸入與不輸入的情況
1）確定輸入：姓名、郵箱、密碼、確認密碼、驗證碼
2）確定變數取值個數：五個變數取值個數都是2個：輸入與不輸入
3）確定因素數（列），水平數，行：因素數為5，水平數為2，因此行為（2-1）*5+1=6
4）根據正交表性質把變數值映射到正交表中：

5）寫測驗用例：
姓名填寫，郵箱不填寫，密碼填寫，確認密碼不填寫，驗證碼填寫
姓名不填寫，郵箱填寫，密碼不填寫，確認密碼填寫，驗證碼不填寫
姓名不填寫，郵箱不填寫，密碼填寫，確認密碼不填寫，驗證碼不填寫
姓名填寫，郵箱填寫，密碼填寫，確認密碼填寫，驗證碼不填寫
姓名填寫，郵箱不填寫，密碼不填寫，確認密碼填寫，驗證碼填寫
全填寫
全不填寫

5.場景法

把場景中的每一個功能點提出來，考慮功能點的可能出現的不同情況，根據這些情況設計測驗用例，（把一個個獨立的功能點按照一定的策略串聯起來，形成一定的場景或業務

設定ATM取款場景

ATM取款流程：插卡 -> 輸入密碼 -> 輸入金額 -> 取錢 -> 退卡
1）插卡：卡插反了，卡消磁了，插入了其他型別地卡（公交卡、飯卡等）
?????卡注銷，卡消磁
?????卡停留時間長，卡被機吞
2）輸入密碼：密碼連續輸錯了三次，賬戶就會被鎖定
?????密碼前兩次或者第一次出錯，接下來一次輸入正確
?????點擊忘記密碼，就在手機上重置密碼
3）輸入金額：金額大于銀行卡余額，ATM機本身余額不足
?????輸入的金額低于ATM要求的最低金額
?????輸入了零錢（ATM機不允許）
?????超過每日最大取款金額
4）取錢：錢在ATM機長時間未取
?????遺忘了部分錢沒有取
5）其他：ATM機網路例外，斷電，機器故障

根據例外點寫測驗用例：

卡插反了，會提示“插卡錯誤”，取款失敗
卡消磁，會提示“無效卡”，取款失敗
插入其他卡，會提示“無效卡”，取款失敗
卡掛失，會提示“無效卡”，取款失敗
…

6.錯誤猜測法

根據測驗人員的經驗、知識、直覺去判斷哪一個模塊可能會出現問題，專門針對這個模塊撰寫測驗用例，可算補充的設計測驗用例的方法，

舉例：搜索框內進行資料查詢
輸入名字“張三” ，當輸入“ ?張三”時搜不出來，原因就是沒有使用trim()去洗掉名字前后的空格，

習題練習

1.根據等價類和邊界值設計測驗用例

從姓名看：

從年齡看：

2.根據因果圖法設計測驗用例
有一個處理1元5角的盒裝飲料的自動售歡訓器，若投入1元＋5角硬幣，按下可樂、雪碧、紅茶按鈕，相應的飲料就會送出來；若投入的是2元硬幣，出飲料的同時退還5角硬幣，

1）分析輸入和輸出
輸入：輸入1元5角硬幣，輸入2元硬幣，按下可樂、雪碧、紅茶按鈕
輸出：可樂、雪碧、紅茶，5角硬幣
2）分析不同輸入組合與輸出之間的關系
輸入1元5角硬幣，按“可樂”按鈕，送出可樂
輸入1元5角硬幣，按“雪碧”按鈕，送出雪碧
輸入1元5角硬幣，按“紅茶”按鈕，送出紅茶
輸入2元硬幣，按“可樂”按鈕，送出可樂，輸出5角硬幣
輸入2元硬幣，按“雪碧”按鈕，送出雪碧，輸出5角硬幣
輸入2元硬幣，按“紅茶”按鈕，送出紅茶，輸出5角硬幣
3）畫因果

4）根據因果圖畫判定表

5）根據判定表寫測驗用例

四、軟體測驗分類

測驗金字塔模型

金字塔測驗策略要求在3個不同級別進行自動化測驗，具體如圖所示：

(1)單元測驗

單元測驗要求在開發中對每個功能模塊(函式、類方法)進行測驗，如檢測其中某一項功能是否按預期要求正常運行，單元測驗中通常采用白盒測驗，主要對代碼內部邏輯結構進行測驗，

(2)介面測驗

介面測驗要求對資料傳輸、資料庫性能等進行測驗，從而保證資料傳輸以及處理的完整性，介面功能的完整運作對整個專案功能擴展、升級與維護有著重要的作用，介面測驗通常使用黑盒測驗和白盒測驗相結合的方式進行，

(3)UI測驗

UI測驗以用戶體驗為主，軟體的所有功能都是通過這一層展示給用戶的，因此UI測驗的作業也很重要，由于UI界面以最終的用戶體驗為主，因此在UI測驗中并不是100%地使用自動化測驗，其中需要人工操作來確定UI界面的易用程度，

金字塔模型特點：
A.從下到上三層測驗，投入相同的時間和人力物力，回報產出率越來越低；
B.從下到上，測驗的效率越來越低；
C.從下到上，定位問題越來越難

1.按照開發階段劃分測驗

單元測驗

單元測驗根據編碼前后介入分為編碼前測驗（TDD，Test-Driven-Develop，測驗驅動開發）和編碼后測驗，

單元主要測驗內容：對單元介面進行測驗（按照介面設計檔案），屬于白盒測驗，對區域資料結構測驗、邊界測驗、路徑測驗和錯誤處理測驗，

單元測驗工具：Junit
步驟：1.在pom.xml中匯入Junit依賴 2.在file-setting-Plugins中搜索Juint并安裝 3.進行單元測驗，選中要測驗類的類名，ctrl+shift+T，生成單元測驗類，

集成測驗

按照一定的策略把單元模塊組裝起來

測驗內容：模塊之間的資料傳輸（輸入輸出、引數），模塊之間的功能沖突，全域資料結構，單個模塊對整個功能的影響；

系統測驗

對被測驗軟體應用系統進行全面的系統的測驗
測驗內容：功能、界面、性能、安全、兼容性、可靠性、可移植性等
回歸測驗：當系統引入新的功能或者修改了BUG時，需要進行回歸測驗；大型系統一般需要不停迭代，每次都要進行回歸測驗，采用自動化回歸測驗方法，
冒煙測驗：在正式測驗之前對系統的主要流程和核心功能進行測驗，

驗收測驗

驗收測驗不僅僅對系統進行全面測驗，還要驗收檔案（開發檔案、軟體設計檔案、需求分析檔案、功能使用檔案、用戶使用手冊等），

2.按照實施組織劃分

α（alpha）測驗

將用戶或者公司內非測驗與開發人員請到現場進行測驗
優點：時間集中，現場好溝通產品問題，α測驗優于β測驗
缺點：容易受到開發環境的影響

β（ Beta）測驗

用戶在實際使用環境下進行測驗
特點：用戶測驗的結果更接近實際使用情況的反饋

3.按照是否運行程式劃分

靜態測驗

不運行程式，根據需求規格和說明檔案結合代碼，查看代碼的風格，語法，邏輯是否符合要求，

動態測驗

寫測驗用例，運行系統程式，執行測驗用例

4.按照是否手工劃分

手工測驗

優點：比較靈活，屬于發散性的測驗
缺點：測驗用例數量比較大時，很容易出錯，
手工測驗無法被替代

自動化測驗

自動化測驗：按照預設的條件去執行測驗，收集測驗的結果，設定正常驗證和例外驗證，
應用自動化測驗前提：專案的功能相對穩定
自動化測驗什么時候最有價值：當腳本的重復使用率較高，自動化就越有價值，

自動化測驗有：
UI界面自動化：selenium，unittest，ddt，HTMLResultRepport
介面自動化：jmeter postman
性能自動化：loaderrunner

5.按照是否查看代碼劃分

黑盒測驗

黑盒測驗不去關注程式內部具體怎么實作，只關注功能的輸入和輸出是否滿足要求，

黑盒測驗設計測驗用例的方法有：等價類、邊界值、因果圖、正交法、錯誤猜測法、場景法，

系統測驗與驗收測驗屬于黑盒測驗范疇

白盒測驗

白盒測驗關注程式內部的實作邏輯，結構，語法，

白盒測驗有哪些方法：
陳述句覆寫法
回圈覆寫法：while(x == true)
路徑覆寫法：if/else switch
邏輯覆寫法：判定覆寫、條件覆寫、判定組合覆寫、條件組合覆寫

單元測驗屬于白盒測驗范疇

灰盒測驗

灰盒測驗介于白盒與黑盒測驗之間，
集成測驗屬于灰盒測驗范疇

6.按照地域劃分

軟體國際化：開發軟體時使用的一種工程技術，使軟體可以適用不同國家的語言，文化，不用修改源代碼，這種技術就叫軟體國際化，