軟體質量保證過程

軟體質量與缺陷

軟體質量定義

IEEE： 質量是系統、部件或過程滿足

1. 明確需求
2. 客戶或使用者需要或期望的程度

軟體質量 (GB/T 11457-2006)：

• 軟體產品滿足使用者要求的程度；
• 軟體具有所期望的各種屬性的組合程度；
• 軟體滿足使用者綜合期望的程度；
• 軟體在使用中滿足使用者要求的程度。

軟體質量評估

​ 軟體質量是人們實踐產物的屬性和行為，是可以認識以及科學描述的，並且可以通過一些方法和人類活動來改進的。
軟體質量模型：McCall模型、Boehm模型、ISO 9126模型

McCall軟體質量模型（1977）

Boehm軟體質量模型（1978）

三層模型：

1. 質量要素（7個）
2. 衡量指標（15個）
3. 度量指標

ISO 9126軟體質量模型（1993）

三層模型：

1. 外部質量特性（6個）
2. 內部質量子特性（27個）
3. 使用者自定義的度量指標

軟體缺陷

定義：任何程式、系統中的問題，和產品設計書的不一致性，不能滿足使用者的需求

現象：

• 功能、特性沒有實現或部分實現
• 設計不合理，存在缺陷
• 實際結果和預期結果不一致
• 執行出錯，包括執行中斷、系統崩潰、介面混亂
• 資料結果不正確、精度不夠
• 使用者不能接受的其他問題，如存取時間過長、介面不美觀

產生：

1. 技術問題：演算法錯誤，語法錯誤，計算和精度問題，介面引數傳遞不匹配；
2. 團隊工作：溝通不充分，誤解；
3. 軟體本身：
   • 文件錯誤、使用者使用場合(user scenario)不正確；
   • 時間上不協調、或不一致性所帶來的問題；
   • 系統的自我恢復或資料的異地備份、災難性恢復等問題；

構成：

在不同階段的分佈

在真正的程式測試之前，通過審查、評審會可以發現更多的缺陷。
規格說明書的缺陷會在需求分析審查、設計、編碼、測試等過程中會逐步發現，而不能在需求分析一個階段發現。

修復缺陷成本：

軟體測試和開發、質量保證的關係，TDD

軟體測試與開發的關係

軟體質量保證（SQA）

軟體質量保證（Software Quality Assurance，SQA）活動是通過對軟體產品有計劃的進行評審和審計來驗證軟體是否合乎標準的系統工程，通過協調、審查和跟蹤以獲取有用資訊，形成分析結果以指導軟體過程。

• 對軟體工程各個階段的進展、完成質量及出現的問題進行評審、跟蹤。

• 審查和驗證軟體產品是否遵守適用的標準、規程和要求，並最終確保符合標準、滿足要求。

• 建立軟體質量要素的度量機制，瞭解各種指標的量化資訊，向管理者提供可視資訊。

測試 vs. SQA

SQA指導、監督軟體測試的計劃和執行，督促測試工作的結果客觀、準確和有效，並協助測試流程的改進。

軟體測試是SQA重要手段之一，為SQA提供所需的資料，作為質量評價的客觀依據。

SQA是一項管理工作，側重於對流程的評審和監控

測試是一項技術性的工作，側重對產品進行評估和驗證

測試驅動開發（TDD）的思想

1. 明確當前要完成的功能。可以記錄成一個 TODO 列表。
2. 快速完成針對此功能的測試用例編寫。
3. 測試程式碼編譯不通過。
4. 編寫對應的功能程式碼。
5. 測試通過。
6. 對程式碼進行重構，並保證測試通過。
7. 迴圈完成所有功能的開發。

軟體測試分類

不同的分類：

• 按測試的物件或範圍分類，如單元測試、文件測試、系統測試等
• 按測試目的分類，如功能測試、迴歸測試、效能測試、可靠性測試、安全性測試和相容性測試等
• 根據測試過程中被測軟體是否被執行，分為靜態測試和動態測試
• 根據是否針對系統的內部結構和具體實現演算法來完成測試，可分為白盒測試和黑盒測試

靜態和動態測試

靜態測試：輪查、互審、走讀、審查會議（非正式到正式）

動態測試：執行程式

• 將需求和設計的評審納入測試的範疇，可看作是廣義測試
• 靜態測試包括對軟體產品的需求和設計規格說明書的評審、對程式程式碼的複審等
• 靜態分析的查錯和分析功能是其他方法所不能替代的，可以採用人工檢測和計算機輔助靜態分析手段進行檢測，但越來越多地採用工具進行自動化分析
• 動態測試是通過真正執行程式發現錯誤，通過觀察程式碼執行過程，來獲取系統資訊，對系統行為進行驗證。

黑盒測試與白盒測試

黑盒測試：

白盒測試

小結

軟體測試級別及任務

系統功能性測試

功能測試一般須在完成整合測試後進行，而且是針對應用系統進行測試。功能測試是基於產品功能說明書，是在已知產品所應具有的功能，從使用者角度來進行功能驗證，以確認每個功能是否都能正常使用 。

系統非功能性測試

系統非功能性測試是將軟體放在整個計算機環境下，包括軟硬體平臺、某些支援軟體、資料和人員等，在實際執行環境下進行一系列的測試，包括：

• 恢復測試
• 安全測試
• 強度測試
• 效能測試

主動測試和被動測試

主動測試方法：測試人員主動向被測試物件傳送請求、或藉助資料、事件驅動被測試物件的行為，從而驗證被測試物件的反應或輸出結果。

被動測試方法：測試人員不干預產品的執行，而是被動地監控產品在實際環境中執行，通過一定的被動機制來獲得系統執行的資料，包括輸入、輸出資料。

α、β測試

Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers‘ site；Is a form of internal acceptance testing.

Beta testing comes after Alpha testing. Versions of the software, known as beta versions, are released to a limited users outside of the programming team.

靜態測試

程式碼審查﹑走查等的概念及區別

定義：對元件/系統進行規格或實現級別的測試，而不是執行這個軟體，比如程式碼評審。

程式碼檢查主要檢查程式碼和設計的一致性，程式碼對標準的遵循、可讀性、程式碼邏輯表達的正確性及程式碼結構的合理性等方面，包括以下兩種形式：

• 程式碼審查和走查由若干程式設計師與測試員組成一個小組，集體閱讀並討論程式，或者用“腦”執行並檢查程式的過程。（頭腦風暴會）
• 桌面檢查是由程式設計師閱讀自己所編寫的程式。

程式碼審查

• 以組為單位閱讀程式碼，是一系列規程和錯誤檢查技術的集合。

• 程式碼審查小組

  • 4人組成，1人為調協人
  • 協調人應該是個稱職的程式設計師，但不是該程式的編碼人員，不需要對程式的細節瞭解得很清楚
  • 協調人的職責：
    • 為程式碼審查分發材料、安排程序
    • 在程式碼審查中起主導作用
    • 記錄發現的所有錯誤
    • 確保所有錯誤隨後得到改正
  • 第二個小組成員是程式碼的作者，其它成員通常是程式的設計人員以及一名測試專家。該測試專家應具備較高的軟體測試造詣並熟悉大部分的常見錯誤。

• 審查議程與注意事項

  • 在審查前幾天，協調人將程式清單和設計規範分發給其他成員。所有成員應在審查之前熟悉這些材料。在審查進行時，主要進行兩項活動：
    1. 由程式編碼人員逐條語句講述程式的邏輯結構，小組其它成員應提問題、判斷是否存在錯誤。
    2. 參考常見的編碼錯誤列表分析程式
  • 協調人負責確保審查會議的討論高效地進行、每個參與者都將注意力集中於查詢錯誤而不是修正錯誤（錯誤的修正由程式設計師在檢查會議後完成）
  • 程式碼審查會議的理想時間應在90-120分鐘。
    • 開會是一項繁重的腦力勞動，會議時間越長效率越低。大多數的程式碼審查都是按每小時大約閱讀150行程式碼的速度進行。因此，對大型軟體的審查應安排多個程式碼審查會議同時進行，每個程式碼審查會議處理一個或幾個模組或子程式。
  • 對事不對人，和人有關的注意事項
    • 審查是發現程式的錯誤，從而改進軟體質量。

錯誤型別

1. 資料引用錯誤

   • 變數使用前是否賦值或初始化？

     • 容易引起變數使用錯誤，特別是對於指標或引用變數。
     • 在java中要求變數在使用前必須初始化。

   • 陣列下標的範圍和型別

     • 是否存在下標越界錯誤，下標型別是否為整型。

   • 通過指標引用的記憶體單元是否存在（虛呼叫）？

     • 如在函式返回區域性變數的指標或引用時會產生虛呼叫錯誤。

   • 被引用的變數或記憶體的屬性是否與編譯器預期的一致？

     • 如A型別的指標或引用是否指向的是非A型別物件。

2. 資料宣告錯誤

   • 是否所有變數都已宣告？
     • 絕大多數程式語言要求變數先定義後使用，可保證變數使用的安全性。
   • 預設的屬性（預設值）是否正確？
   • 變數的初始化是否正確？變數的初始化是否與其儲存空間的型別一致？
   • 是否每個變數都有正確的長度、型別和儲存類別？
   • 是否存在相似名稱的變數？

3. 運算錯誤

   • 是否存在非算術變數之間的運算？
   • 是否存在混合模式的運算？（ int與float型別）
   • 是否存在不同字長變數之間的運算？（int與long型別）
   • 目標變數大小是否小於所賦值的大小？（精度損失或越界錯誤）
   • 中間結果是否上溢或下溢？
   • 是否存在除0錯誤？
   • 操作符的優先順序是否正確？
   • 整數除法是否正確？（精度問題，如2*(i/2)==i）

4. 比較錯誤

   • 是否有不同型別資料的比較運算？（如日期與數字）
   • 是否有混合模式或不同長度資料的比較運算？
   • 比較運算子是否正確？（如至多、至少，不小於）
   • 布林表示式（與、或、非）是否正確？
   • 比較運算子是否與布林表示式相混合？（如2<i<10對嗎？）
   • 是否存在浮點數的比較？
   • 優先順序是否正確？（例如if((a==2) && (b==2) || (c==3)）
   • 布林表示式的計算方式（例如 if((x==0 && (y/x)>z)）

5. 控制流程錯誤

   • 是否所有迴圈都能終止？（迴圈結束條件是否能滿足以及遞迴的終止條件是否能滿足。）
   • 是否存在由於入口條件不滿足而跳過迴圈體？（do…while迴圈）
   • 是否存在僅差一個的迴圈錯誤？（如for(int i=0;i<=10;i++){}）
   • 程式結構中括號是否匹配、if…else是否匹配、do…while是否匹配、try…catch是否匹配等。

6. 介面錯誤

   • 形參和實參的數量是否相等？
   • 形參的屬性是否與實參的屬性相匹配？
   • 形參的屬性是否與實參的順序相匹配？
   • 形參的單位是否和實參匹配？（屬邏輯錯誤）
   • 是否改變了某個僅作為輸入值的形參？（C++中的const關鍵字）
   • 全域性變數的定義是否一致？

7. 輸入輸出錯誤

   • 檔案屬性是否正確？
   • 開啟檔案的語句是否正確？
   • 緩衝區、記憶體大小是否足夠來保留程式將讀取的檔案？
   • 檔案在使用前是否開啟？
   • 檔案在使用後是否關閉了？
   • 檔案結束條件是否被正確處理？
   • 是否處理了IO錯誤？
   • 列印或輸出的文字資訊中是否存在拼寫或語法錯誤？即輸出結果正確性。

8. 其他檢查

   • 是否存在未引用過的變數？
   • 編譯通過的程式是否存在“警告”或“提示”資訊？
   • 程式或模組是否對輸入的合法性進行了檢查？是否考慮到所有的場景？（如第一章中三角形例）
   • 程式是否遺漏了某個功能？

程式碼走查

走查與程式碼審查大體相同，以小組為單位進行程式碼閱讀，但是規程稍微不同，採用的錯誤檢查技術也不一樣。

• 走查的參與者“使用了計算機”；
• 被指定為測試人員的那個人會帶來一些書面的測試用例來參加會議；
• 會議期間，每個測試用例都在人們腦中進行推演，程式的狀態（如變數的值）記錄在紙張或白板上以供監視。
• 這些測試用例必須結構簡單、數量較少，因為人腦執行程式的速度比計算機執行速度慢若干數量級。因此，這些測試用例本身並不起到關鍵的作用；相反，它們的作用是提供了啟動程式碼走查和質疑程式設計師邏輯思路及其設想的手段。
  • 在大多數的程式碼走查中，很多問題是向程式設計師提問的過程中發現的，而不是測試用例本身直接發現的。

重點---動態測試(測試用例設計)

要掌握用例設計的步驟，並會靈活應用到具體問題上。

黑盒

等價類劃分、邊界值分析、決策表、因果圖

等價類劃分法

等價類是某個輸入域的子集，在該子集中每個輸入資料的作用是等效的。將輸入資料分成若干個子集，從每個子集選取一個代表性的資料作為測試用例。

• 分為有效等價類和無效等價類。
• 在分析需求規格說明的基礎上劃分等價類，列出等價類表

設計測試用例時，要同時考慮這兩種等價類。因為軟體不僅要能接收合理的資料，也要能經受異常資料的考驗。經過正反的測試才能確保軟體具有更高的可靠性。

確定等價類的方法

在輸入條件規定了取值範圍或值的個數的情況下，則可以確立一個有效等價類和兩個無效等價類

在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下，可以確立一個有效等價類和一個無效等價類。

在輸入條件是一個布林量的情況下，可確定一個有效等價類和一個無效等價類。

在規定了輸入資料的一組值(假定n個)，並且程式要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。

• 交通工具的型別必須是公共汽車、卡車、計程車、火車或摩托車

在規定了輸入資料必須遵守的規則的情況下，可確立一個有效等價類(符合規則)和若干個無效等價類(從不同角度違反規則)。

• 頁面上使用者輸入有效E-mail地址的規則

根據等價類建立測試用例的步驟

1. 建立等價類表，列出所有劃分出的等價類

   輸入條件	有效等價類	無效等價類
   …	…	…
   …	…	…

2. 為每個等價類規定一個唯一的編號

3. 設計一個新的測試用例，使其儘可能多地覆蓋尚未覆蓋的有效等價類

4. 重複3，最後使得所有有效等價類均被測試用例所覆蓋

5. 設計一個新的測試用例，使其只覆蓋一個無效等價類

6. 重複5使所有無效等價類均被覆蓋

用單個測試用例覆蓋無效等價類，是因為某些特定的輸入錯誤檢查可能會遮蔽或取代其他輸入錯誤檢查。例如，若規定了“請輸入書籍型別（硬皮、軟皮或活頁）及數量（1-999）”，代表兩個錯誤輸入（書籍型別錯誤，數量錯誤）的測試用例“XYZ 0”，很可能不會執行對數量的檢查，因為程式會提示“XYZ是未知的書籍型別”，就不檢查輸入的其餘部分了。

示例

有一報表處理系統，要求使用者輸入處理報表的日期。假設日期限制在2000年1月至2020年12月，即系統只能對該段時期內的報表進行處理。若使用者輸入的日期不在這個範圍內，則顯示錯誤資訊。並且此係統規定日期由年月的6位數字組成，前4位代表年，後兩位代表月。則檢查日期時，有哪些等價類？

測試用例：覆蓋1、5、8三個有效等價類測試，只要用201006即可；對無效等價類的測試要分別輸入7個非法資料，如200a0b、20102、1012012、198802、203011、200000、202013

邊界值分析法

• 很多錯誤發生在輸入或輸出範圍的邊界上，因此針對各種邊界情況設定測試用例，可以更有效地發現缺陷。
• BVA – Boundary Value Analysis
• 設計方法
  • 確定邊界情況（輸入或輸出等價類的邊界）
  • 選取正好等於、剛剛大於或小於邊界值作為測試資料

確定邊界值的方法

如果輸入條件規定了值的範圍，則應取剛達到這個範圍的邊界的值，以及剛剛超越這個範圍邊界的值作為測試輸入資料。

如果輸入條件規定了值的個數，則用最大個數、最小個數、比最小個數少一、比最大個數多一的數作為測試資料。

如果程式的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最後一個元素作為測試用例（例如：圖片畫素）。

如果程式中使用了一個內部資料結構，則應當選擇這個內部資料結構的邊界上的值作為測試用例。

示例一

Test cases for ABS(x) :
class x < 0, arbitrary value: x = -10
class x >= 0, arbitrary value x = 100
classes x < 0, x >= 0, on boundary : x = 0
classes x < 0, x >= 0, below and above: x = -1, x = 1

示例二

測試限制性使用者輸入：6位正整數

示例三

Test cases :

• 任意的正常值：隨機選擇幾個選項
• 邊界值：選擇所有選項
• 邊界值：一個都不選
• 邊界值：選擇一個選項

數值邊界值檢驗

計算機基於二進位制工作，軟體任何運算都有一定的範圍限制。
0 和 1, byte 由8 bits 構成, 字由4 bytes構成, …

字元的邊界值檢驗

ASCII是常見的編碼方式

示例四：

一個二元函式f（x, y）

• 1=<x<=12

• 1=<y<=31

• (1, 15), (0, 15), (2, 15), (12, 15), (11, 15), (13, 15)

• (6, 15)

• (6, 1), (6, 0) , (6, 2) , (6, 31) , (6, 30) , (6, 32)

示例五：

假設商店貨品價格(R) 都不大於100元（且為整數），若顧客付款(P)在100元內，現有一個程式能在每位顧客付款後給出找零錢的最佳組合（找給顧客貨幣張數最少）。
假定此商店的貨幣面值只包括：50元(N50)、10元(N10)、 5元(N5)、1元(N1) 四種。

基於組合及其優化的技術

判定表方法

在實際應用中，許多輸入是由多個因素構成，而不是單一因素，這時就需要多因素組合分析。

對於多因素，有時可以直接對輸入條件進行組合設計，不需要進行因果分析，即直接採用判定表方法。

判定表由“條件和活動”兩部分組成，即列出一個測試活動執行所需的條件組合，所有可能的條件組合定義了一系列的選擇，而測試活動需要考慮每一個選擇。

判定表有時也稱“決策表”。

“閱讀指南”決策表

判定表元素

條件樁：列出問題的所有條件

動作樁：列出可能針對問題所採取的操作

條件項：針對所列條件的具體賦值

動作項：列出在條件項（各種取值）組合情況下應該採取的動作。

規則：任何一個條件組合的特定取值及其相應要執行的操作。

判定表方法步驟

• 列出條件樁
• 列出動作樁
• 填入條件項及其組合
• 填入動作項，制定初始判定表；
• 簡化、合併相似規則或者相同動作

示例

問題要求：”……對功率大於50馬力的機器，當維修記錄不全或已執行10年以上時，應給予優先的維修處理；對功率小於50馬力的機器，當執行超過10年時也優先維修……” 。這裡假定，“維修記錄不全”和“優先維修處理”均已在別處有更嚴格的定義 。請建立判定表。

解答：
① 確定規則的個數。這裡有3個條件，每個條件有兩個取值，故應有2*2*2=8種規則。

② 列出所有的條件樁和動作樁。

③ 填入條件項（二進位制的真值表）。
④ 填入動作項。

⑤ 化簡。

化簡原則：

1. 刪除不存在的規則；
2. 合併相似規則；
   1. 動作相同
   2. 該條件項包含所有取值（說明動作與該條件的取值無關）

總結

• 決策表（判定表）是分析和表達多邏輯條件下執行不同操作的情況的工具。
  • 在一些資料處理問題當中，某些操作的實施依賴於多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。決策表很適合於處理這類問題。
• 基於決策表的測試是所有黑盒測試方法中最為嚴格、且最具邏輯性的測試方法。
• 優點：能夠將複雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利用決策表能夠設計出完整的測試用例集合。
• 缺點：不能表達重複執行的動作，例如迴圈結構

練習

假設中國某航空公司規定：

1. 中國去歐美的國外航線都有食物供應，每個座位都可以播放電影。
2. 中國去非歐美的國外航線都有食物供應，只有商務倉可以播放電影。
3. 中國國內航班的商務倉有食物供應，但是不可以播放電影。
4. 中國國內航班的經濟倉只有當飛行時間大於2小時才有食物供應，但是不可以播放電影。

因果圖法

• 多種輸入條件的組合，產生多種結果設計測試用例。

• 產生背景：

  • 等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合；
  • 判定表方法考慮條件組合，但是沒有考慮輸入條件之間的相互制約關係；
  • 如果在測試時必須考慮輸入條件的各種組合，則可能的組合數目將是天文數字。

示例

基本符號

恆等-關係：果 j 取決於因 i。因出現，則果也出現。

非-關係：只有當因 i 不存在時，果 j 才出現。

或-關係：如果因 i1 或因 i2 或……或因 in 存在時，結果 j 才出現。

與-關係：只有當因 i1 與因 i2 與……與因 in 同時存在時，結果 j 才出現。

約束

• 輸入狀態之間可能存在某些依賴關係。

• 輸出狀態之間也往往存在約束。

• 在因果圖中,用特定的符號標明這些約束。

• 輸入條件的約束有以下4類： 　

  1. E約束（異）：a和b中至多有一個可能為1，即a和b不能同時為1。

  2. I約束（或）：a、b和c中至少有一個必須是1，即 a、b 和c不能同時為0。

  3. O約束（唯一）：a和b必須有一個，且僅有1個為1。

  4. R約束（要求）：a是1時，b必須是1，即不可能a是1時b是0。

• 輸出條件約束型別

  • 輸出條件的約束只有M約束（強制）：若結果a是1，則結果b強制為0。

設計方法

• 分析軟體規格說明文件描述的哪些是原因（輸入條件），哪些是結果（輸出條件），給每個原因和結果賦予一個標示符；
• 找出原因與結果，原因與原因之間的對應關係，畫出因果圖；
• 在因果圖上標上哪些不可能發生的因果關係，表明約束或限制條件；
• 根據因果圖，建立判定表，將複雜的邏輯關係和多種條件組合很具體明確的表示出來；
• 把判定表的每一列作為依據設計測試用例。

示例

某軟體規格說明書包含這樣的要求：

• 第一列字元必須是A或B，第二列字元必須是一個數字，滿足要求時進行檔案的修改；
• 如果第一列字元不正確，給出資訊L；
• 如果第二列字元不是數字，給出資訊M。

1. 根據題意，原因和結果如下：

原因：

​ 1——第一列字元是A；
​ 2——第一列字元是B；
​ 3——第二列字元是一數字。

結果：
21——修改檔案；
22——給出資訊L；
23——給出資訊M。

2. 其對應的因果圖如下：

11為中間節點；考慮到原因1和原因2不可能同時為1，因此在因果圖上施加E約束。

表中8種情況的左面兩列情況中，原因①和原因②同時為1，這是不可能出現的，故應排除這兩種情況。表的最下一欄給出了6種情況的測試用例，這是我們所需要的資料。

示例

有一個處理單價為5角錢的飲料的自動售貨機軟體測試用例的設計。其規格說明如下：

假設只能投入5角錢或1元錢：

• 當投入5角錢，並押下〖橙汁〗或〖啤酒〗的按鈕，則送出相應飲料；
• 當投入1元錢：
  • 若售貨機沒有零錢找，則一個顯示〖零錢找完〗的紅燈亮，這時在投入1元硬幣並押下按鈕後，飲料不送出來而且1元硬幣也退出來；
  • 若有零錢找，則顯示〖零錢找完〗的紅燈滅，在送出相應飲料的同時找還5角硬幣。

1. 分析這一段說明，列出原因和結果

   原因：

   1. 售貨機有零錢找 /沒零錢找（1或0）
   2. 投入1元硬幣
   3. 投入5角硬幣
   4. 押下橙汁按鈕
   5. 押下啤酒按鈕

   結果：

   21. 售貨機〖零錢找完〗燈亮 /滅（1或0）

   22. 退還1元硬幣

   23. 退還5角硬幣

   24. 送出橙汁飲料

   25. 送出啤酒飲料

2. 畫出因果圖，如圖所示。所有原因結點列在左邊，所有結果結點列在右邊。建立中間結點，表示處理的中間狀態。中間結點：

   11. 投入1元硬幣且押下飲料按鈕

   12. 押下〖橙汁〗或〖啤酒〗的按鈕

   13. 應當找5角零錢並且售貨機有零錢找

   14. 錢已付清

3. 轉換成判定表

4. 在判定表中，陰影部分表示因違反約束條件的不可能出現的情況，刪去。第16列與第32列因什麼動作也沒做，也刪去。最後可根據剩下的16列作為確定測試用例的依據

正交實驗法

在許多應用系統的測試工作中，不會象判斷三角形那樣簡單，輸入條件的因素很多，而且每個因素也不能簡單用“是”和“否”來回答。比如，微軟Powerpoint程式的列印測試，也需要考慮4個因素，每個因素也有多個選項

• 列印範圍分：全部、當前幻燈片、給定範圍
• 列印內容分：幻燈片、講義、備註頁、大綱檢視
• 列印顏色/灰度分: 彩色、灰度、黑白
• 列印效果分：幻燈片加框和幻燈片不加框。

測試組合會變得很多，如果按照傳統的測試方法，會導致很大的測試工作量

依據Galois理論，從大量的（實驗）資料（測試例）中挑選適量的、有代表性的點（條件組合），從而合理地安排實驗（測試）的一種科學實驗設計方法

產生背景

• 大部分缺陷是在兩個變數取值衝突的測試時被發現的；
• 不僅僅是在所有的組合情況下才會發現所有的測試缺陷；

測試原理

• 不要測試所有的組合，測試所有的“Pairwise ”即可；

輸入條件	完全組合數	兩兩組合數
4個變數每個可取3種值	\(3^4=81\)	9
13個變數每個可取3種值	\(3^{13}=1594323\)	15
20個變數每個可取10種值	\(10^{20}\)	180

示例

系統S有三個輸入變數X、Y、Z，其值域分別為：D(X) = {1, 2}，D(Y) = {Q, R}，D(Z) = {5, 6}.

第一步：列出所有可能的測試用例.

第二步：去掉重複的行。

方法如下：從表的最後一行開始，如果這行的兩兩組合值能夠在上面的行或此表中找到，那麼這行就可從用例集中刪除。

TestID	Input X	Input Y	Input Z
TC1	1	Q	5
TC4	1	R	6
TC6	2	Q	6
TC7	2	R	5

白盒

語句﹑判定﹑條件﹑邏輯等

邏輯覆蓋

以程式或系統的內部邏輯結構為基礎，分為語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋等。

路徑覆蓋

在程式或業務控制流程的基礎上，分析控制構造的環路複雜性，匯出基本可執行路徑集合，從而設計測試用例。

語句覆蓋

基本思想

設計若干測試用例，執行被測程式，使程式中的每個可執行語句至少被執行一次：

• 如果是順序結構，就只需讓測試從頭執行到尾；
• 如果有分支、條件和迴圈，則需要採用特定的一些方法，執行足夠的測試覆蓋全部語句。

判定覆蓋

基本思想

• 設計若干用例，執行被測程式，使得程式中每個判斷的取真分支和取假分支至少經歷一次，即判斷真假值均曾被滿足。

一個判定代表著程式的一個分支，所以判定覆蓋也被稱為分支覆蓋。

條件覆蓋

判定覆蓋是一種比語句覆蓋更強的準則，但仍然相當不足。

E.g., 若第二個判斷存在錯誤（如把a>1寫成了a!=0），那麼前面的兩個測試用例是無法發現這個錯誤的。

條件覆蓋的基本思想：

設計若干測試用例，執行被測程式以後，要使每個判斷中每個條件的可能取值至少滿足一次。

列出所有條件

覆蓋所有條件

(a, b ,c)= (2, -1, 0) T1, F2, T3, F4

(a, b ,c)= (-1, 1, 2) F1, T2, F3, T4

條件覆蓋不一定比語句覆蓋、判定覆蓋好！

兩個測試用例在兩個判斷處都是F->T，即判定覆蓋沒有滿足。進而語句覆蓋也沒有被滿足。

判定-條件覆蓋

判定-條件覆蓋是判定和條件覆蓋設計方法的交集，即設計足夠的測試用例，使得判斷條件中的所有條件可能取值至少執行一次，同時，所有判斷的可能結果至少執行一次。

特定的條件會遮蔽其他的條件，常常並不能全部都執行到。

源程式中的多重條件判斷被分解成單個的判斷和分支。

大多數機器都沒有執行多重條件判斷的單獨指令。

更為完全的測試覆蓋似乎是將每個基本判斷的全部可能的結果都執行到。

圖示例子中X>1條件對應的決斷結果可能不會被測試到。

條件組合測試

條件組合覆蓋的基本思想

設計足夠的測試用例，使得判斷中每個條件的所有可能組合值至少出現一次，並且每個判斷本身的判定結果也至少出現一次。

與條件覆蓋的區別

它不是簡單地要求每個條件都出現“真”與“假”兩種結果，而是要求讓這些結果的所有可能組合都至少出現一次。

示例：

覆蓋了所有組合，但只覆蓋了兩條路徑: 125, 134

覆蓋了所有組合，但覆蓋路徑有限，1-2-5 沒被覆蓋

基本路徑覆蓋

顧名思義，路徑覆蓋就是設計所有的測試用例，來覆蓋程式中的所有可能的執行路徑。

路徑覆蓋實際考慮了程式中各種判定結果的所有可能組合，但並未考慮判定中的條件結果的組合。因此，雖然說路徑覆蓋是一種非常強的覆蓋，但不能代替條件覆蓋和條件組合覆蓋。

實際軟體系統中，即使一個不太複雜的程式，其路徑組合都可能是一個龐大的天文數字，要想在測試中覆蓋所有的路徑往往不太現實。

• 如一個函式包含10個if語句，就有\(2^{10}=1024\)條路徑測試，若再增加一個if語句，就有\(2^{11}=2048\)條路徑要測試！！
• 必須把覆蓋的路徑數目減少到一定程度內！
• 因此有了“基路徑測試法”

基路徑覆蓋的設計過程

1. 依據程式碼繪製流程圖
2. 確定流程圖的圈複雜度（cyclomatic complexity ）
3. 確定線性獨立路徑的基本集合( basis set )
4. 設計測試用例覆蓋每條基本路徑

流程圖的圈複雜度

圈複雜度（Cyclomatic complexity）:也叫環路複雜度，程式碼邏輯複雜度的度量，提供了被測程式碼的路徑數量。複雜度越高，出錯的概率越大。

• V(G) = 區域數量(由節點、連線包圍的區域，包括圖形外部區域)
• V(G) = 連線數量 - 節點數量 + 2
• V(G) = 簡單可預測節點數量（即流程圖中判定節點的數量） + 1

示例

確定線性獨立的路徑集合

獨立路徑： 至少引入一個新的處理語句或條件的任何路徑。V(G)值正好等於該程式的獨立路徑的條數。

基本集： 由獨立路徑構成的集合，每條路徑是唯一的。由基本集匯出的測試用例，保證每行程式碼語句至少被執行一次。

基本集合不一定唯一

示例

基本路徑測試並不是測試所有路徑的組合，僅僅保證每條基本路徑被執行一次

小結

Myers給出了各種測試方法的綜合策略：

• 在任何情況下都必須使用邊界值方法。經驗表明，用邊界值分析法設計的測試用例發現錯誤的能力最強。
• 必要時使用等價類劃分法補充一些測試用例。
• 根據經驗或直覺推測程式中有可能存在的各種錯誤，用錯誤推測法追加一些測試用例。
• 分析已設計的測試用例的邏輯覆蓋程度，若沒有達到覆蓋標準，再補充足夠的測試用例。
• 如果規格說明中含有輸入條件的組合情況，則可採用因果圖法和決策表法。

整合測試

自頂向下﹑自底向上等整合策略

整合測試的模式

漸增式測試模式與非漸增式測試模式　

非漸增式測試模式：先分別測試每個模組，再把所有模組按設計要求放在一起結合成所要的程式，如大棒模式。

漸增式測試模式：把下一個要測試的模組同已經測試好的模組結合起來進行測試，測試完以後再把下一個應該測試的模組結合進來測試。

驅動模組和樁模組概念和區別

驅動模組：用於模擬被測試模組的上一級模組，相當於被測試模組的主程式，用於接收測試資料，並把這些資料傳送給被測試模組，啟動被測試模組，最後輸出實測結果。

樁模組：用於模擬被測試模組工作過程中所呼叫的模組。樁模組一般只進行很少的資料處理，不需要把子模組的所有功能都帶進來，但不允許什麼事情也不做。

示例

假設現在專案組把任務分給了7個人，每個人負責實現一個模組。你負責的是B模組，你很優秀，第一個完成了編碼工作，現在需要開展單元測試工作。那麼要怎麼做呢？

做法：

1. 寫兩個模組Sd和Se分別代替D模組和E模組(函式名、返回值、傳遞的引數相同)，這樣B模組就可以通過編譯了。Sd模組和Se模組就是樁模組。
2. 寫一個模組Da用來代替A模組，裡面包含main函式，可以在main函式中呼叫B模組，讓B模組執行起來。Da模組就是驅動模組。

大棒整合方法(Big-bang Integration)

採用大棒整合方法,先是對每一個子模組進行測試（單元測試階段），然後將所有模組一次性的全部整合起來進行整合測試 。

　　因為所有的模組一次整合的，所以很難確定出錯的真正位置、所在的模組、錯誤的原因。這種方法並不推薦在任何系統中使用，適合在規模較小的應用系統中使用。

自頂向下法(Top-down Integration)

自底向上法 Bottom-up Integration

自頂向下VS自底向上

混合策略(Modified Top-down Integration)

混合法：

• 對軟體結構中較上層，使用的是“自頂向下”法
• 對軟體結構中較下層，使用的是“自底向上”法

三明治整合方法(Sandwich Integration)

優點：它將自頂向下和自底向上的整合方法有機地結合起來，不需要寫樁程式，因為在測試初自底向上整合已經驗證了底層模組的正確性。

缺點：在真正整合之前每一個獨立的模組沒有完全測試過。E.g., B and D

持續整合(Continuous Integration)

通常系統整合都會採用持續整合的策略，軟體開發中各個模組不是同時完成，根據進度將完成的模組儘可能早的進行整合，有助於儘早發現Bug，避免整合中大量Bug湧現；而且容易定位Bug、修正Bug，最終提高軟體開發的質量與效率。

單元測試﹑驗收測試﹑迴歸測試﹑效能測試等基本概念

單元測試

定義：單元測試是對軟體基本的組成單元進行獨立的測試

時機：

• 單元測試和編碼是同步進行
• 在TDD中，強調測試在先，編碼在後
• 單元測試一般由開發人員完成,QA人員輔助

概念：模組、元件、單元

為何要進行單元測試

• 儘早發現錯誤
  • 錯誤發現越早，成本越低
  • 發現問題比較容易
  • 修正問題更容易
• 檢查程式碼是否符合設計和規範，有利於將來程式碼的維護

單元測試的目標

目標: 單元模組被正確編碼

• 資訊能否正確地流入和流出單元
• 在單元工作過程中，其內部資料能否保持其完整性，包括內部資料的形式、內容及相互關係不發生錯誤，全域性變數在單元中的處理和影響
• 為限制資料加工而設定的邊界處，能否正確工作
• 單元的執行能否做到滿足特定的邏輯覆蓋

驅動程式和樁程式

執行單元程式有時需要基於被測單元的介面，開發相應的驅動模組和樁模組。

驅動模組（drive）:對底層或子層模組進行測試所編寫的呼叫這些模組的程式。

樁模組（stub）：對頂層或上層模組進行測試時所編寫的替代下層模組的程式。

單元測試停止條件

• 單元測試用例設計已經通過評審
• 按照單元測試計劃完成了所有規定單元的測試
• 達到了測試計劃中關於單元測試所規定的覆蓋率的要求
• 被測試的單元每千行程式碼必須發現至少3個錯誤
• 軟體單元功能與設計相一致
• 在單元測試中發現的錯誤已經得到修改，各級缺陷修復率達到標準

功能測試

業務邏輯是關鍵

功能測試要點

• 每項功能符合實際要求
  • 能接受正確的資料輸入，對異常輸入的容錯處理
  • 資料的輸出結果準確，格式清晰，可以儲存和讀取
  • 選單、按鈕操作正常、靈活，能處理一些異常操作
• 系統的各種狀態按照業務流程而變化，並保持穩定
• 程式安裝、啟動正常，有相應的提示框、錯誤提示等
• 功能邏輯清楚，符合使用者習慣
• 系統的介面清晰、美觀
• ……

功能測試的整體思路

客戶需求為導向

效能測試（系統測試）

效能測試（performance test）就是為了發現系統性能問題或獲取系統性能相關指標而進行的測試。

一般在真實環境、特定負載條件下，通過工具模擬實際軟體系統的執行及其操作，同時監控效能各項指標，最後對測試結果進行分析來確定系統的效能狀況。

效能測試目標

獲取系統性能某些指標資料

驗證系統是否達到使用者提出的效能指標

發現系統中存在的效能瓶頸，優化系統的效能

效能測試型別

效能驗證測試，驗證系統是否達到事先已定義的系統性能指標、能否滿足系統的效能需求

效能基準測試，在系統標準配置下獲得有關的效能指標資料，作為將來效能改進的基準線

效能規劃測試，在多種特定的環境下，獲得不同配置的系統的效能指標，從而決定在系統部署時採用什麼樣的軟、硬體配置

壓力/負載/強度測試

壓力測試(Stress test)，也稱為強度測試、負載測試。壓力測試是模擬實際應用的軟硬體環境及使用者使用過程的系統負荷，長時間或超大負荷地執行測試軟體，來測試被測系統的效能、可靠性、穩定性等。

在一種需要反常（如長時間的峰值）數量、頻率或資源的方式下，執行可重複的負載測試，以檢查程式對異常情況的抵抗能力，找出效能瓶頸或其它不穩定性問題。

併發效能測試

併發效能測試的過程也是一個負載測試過程，即逐漸增加併發虛擬使用者數負載，直到系統出現效能瓶頸或者崩潰為止。

破壞性壓力測試，通過不斷載入的手段，快速造成系統的崩潰，讓問題儘快地暴露出來

疲勞強度測試

採用系統穩定執行情況下能夠支援的最大負載，持續長時間執行，以發現效能問題。

• 滲入測試（soak test），通過長時間執行，使問題逐漸滲透出來，從而發現記憶體洩漏、垃圾收集（GC）或系統的其他問題，以檢驗系統的健壯性
• 峰谷測試（peak-rest test），採用高低突變載入方式進行，先載入到高水平的負載，然後急劇降低負載，稍微平息一段時間，再載入到高水平的負載，重複這樣過程，容易發現問題的蛛絲馬跡，最終找到問題的根源

大資料量測試

獨立的資料量測試：針對某些系統儲存、傳輸、統計、查詢等業務進行大資料量測試

綜合資料量測試：和壓力/負載效能測試、併發效能測試、疲勞效能測試相結合的綜合測試方案

效能測試需求和指標

效能測試需求：使用者對各項指標提出的明確需求；如果使用者沒有提出效能指標，則根據使用者需求、測試設計人員的經驗來設計各項測試指標。（需求+經驗）

主要的效能指標：伺服器的各項指標（CPU、記憶體佔用率等）、後臺資料庫的各項指標、網路流量、響應時間

確定性能需求

只有具備了清楚而量化的效能指標，效能測試才能開始實施。

終端使用者的體驗，如2-5-10原則
商業需求，如“比競爭對手的產品好”
技術需求，如CPU使用率不超過70％
標準要求

響應時間是使用者的關注點，容量和資料吞吐量是（產品市場團隊）業務處理方面的關注點，而系統資源佔用率是開發團隊的技術關注點

效能的具體指標

• 資料傳輸的吞吐量（Transactions）
• 資料處理效率（Transactions per second）
• 資料請求的響應時間（Response time）
• 記憶體和CPU使用率
• 連線時間（Connect Time）、傳送時間（Sent Time）
• 處理時間（Process Time）、頁面下載時間
• 第一次緩衝時間
• 每秒（SSL）連線數
• 每秒事務總數、每秒下載頁面數
• 每秒點選次數、每秒HTTP 響應數
• 每秒重試次數

負載（Workload）

• 每秒處理請求數 (Request Per Second, RPS)
• 併發連線數 (Simultaneous Connections)
• 思考時間（thinking time），使用者發出請求之間的間隔時間
• 載入的迴圈次數或持續時間
• 載入的方式或模式，如均勻載入、峰值交替載入等

關鍵業務選擇

不可能/不需要對Web應用系統的所有功能進行效能測試，而是根據業務的實際操作情況和技術的角度來分析，選擇關鍵業務

效能測試工具

Jmeter、LoadRunner、Jprofiler

驗收測試

驗收測試 (Acceptance Test): 在軟體產品完成了系統功能和非功能測試之後、產品釋出之前所進行的軟體測試活動它是技術測試的最後一個階段，也稱為交付測試。

測試內容

前提：系統或軟體產品已通過了系統測試的軟體系統。

測試內容：

​ 驗證系統是否達到了使用者需求規格說明書（可能包括專案或產品驗收準則）中的要求，測試儘可能地發現軟體中存留的缺陷，從而為軟體進一步改善提供幫助，並保證系統或軟體產品最終被使用者接受。

主要包括易用性測試、安裝測試、文件（如使用者手冊）測試等幾個方面的內容。

測試步驟

• 制定測試計劃及驗收通過準則，通過客戶評審
• 設計測試用例並通過評審
• 準備測試環境與資料，執行測試用例，記錄測試結果
• 分析測試結果，根據驗收通過準則分析測試結果，作出驗收是否通過及測試評價。
  • 測試專案通過；
  • 測試專案沒有通過，但存在變通方法，在維護後期或下一個版本改進；
  • 測試專案沒有通過，並且不存在變通方法，需要很大的修改；
  • 測試專案無法評估或者無法給出完整的評估,此時須給出原因.
• 提交測試報告

驗收標準和注意事項

驗收測試完成標準:

• 完全執行了驗收測試計劃中的每個測試用例
• 在驗收測試中發現的錯誤已經得到修改並且通過了測試、或經過評估留待下一版本中修改
• 完成軟體驗收測試報告

注意事項：

• 必須編寫正式的、單獨的驗收測試報告
• 驗收測試必須在實際使用者執行環境中進行
• 由使用者和測試部門共同執行

α/β測試

α 測試: 開發公司組織內部人員模擬各類使用者行為對即將面市的軟體產品（稱為α版本）進行的測試，試圖發現錯誤並修正。

β 測試：組織外部的典型使用者在日常工作中實際使用β版本，並要求使用者報告異常情況、反饋使用意見。然後軟體開發公司再對β版本進行改錯和完善。

迴歸測試

迴歸測試的目的

• 所做的修改達到了預定的目的，如錯誤得到了改正，新功能得到了實現，能夠適應新的執行環境等；
• 不影響軟體原有功能的正確性。

一旦程式某些區域被修改了，就可能影響其它區域，導致受影響的區域出現新的缺陷（迴歸缺陷）。如果這時沒有迴歸測試，產品就帶著這樣的迴歸缺陷被髮布出去了，造成嚴重後果。迴歸測試就是為了發現迴歸缺陷而進行的測試。

迴歸測試策略

• 再測試修改的部分
• 再測試全部用例
• 基於風險選擇測試
• 基於操作剖面選擇測試
• 更智慧的選擇方法

軟體測試

對Junit，EasyMock jprofiler , jmeter，QTP等測試功能和工具的瞭解

作業錯題

關於軟體測試與軟體開發過程的關係，下列描述哪些是正確的？
A、沒有開發過程就沒有測試過程
B、測試過程是為保證開發過程的產出進行驗證和確認的一系列活動
C、不同的軟體開發過程模型中，測試在其中所處的位置不同
D、開發比測試更重要
答案：ABC

W模型是基於“儘早地和不斷地進行軟體測試”的原則。 答案：×

下列哪項測試是對Web網站的功能測試？
A、安全性測試
B、平臺測試
C、連線速度測試
D、連結測試
答案：D

基於JUnit設計單元測試指令碼時，用於支援同時執行多個測試用例的執行器是：
A、Categories
B、TestCase
C、Parameterized
D、Suite
答案：D

下列哪幾項可以用來檢查需求？
A、需求規格說明書
B、測試計劃書
C、產品說明書
D、測試用例
答案：AD

測試計劃的要點包括以下哪些？
A、計劃調整
B、進度安排
C、模擬測試結果
D、確定測試範圍
答案：BD

報告bug時注意的問題有哪些？
A、提供軟體測試環境
B、注意測試結果
C、附加必要的截圖和檔案
D、不要出現錯別字
答案：ACD

下列哪些工具是效能測試工具？
A、JUnit
B、JMeter
C、JProfiler
D、LoadRunner
答案：BCD

單元測試通過的標準是什麼？
A、程式通過所有的單元測試用例
B、語句覆蓋流程達到100%
C、分支覆蓋率達到85%
答案：ABC

選擇整合測試方式時，需要著重考慮以下哪些問題？
A、哪些模組是整合測試的重點
B、模組介面的重要程度
C、開發驅動模組和樁模組的複雜度
D、採用哪種測試設計技術檢測每個介面比較合適
答案:ABD

本文來自部落格園，作者：silly丶，轉載請保留本文署名silly丶，並在文章頂部註明原文連結：https://www.cnblogs.com/EIPsilly/p/15728186.html