碼上快樂

相關內容    簡體    繁體

軟件質量保證與測試技術

本文轉載自   查看原文   2021-12-24 17:10   1169    浙江工業大學

軟件質量保證過程

軟件質量與缺陷

軟件質量定義

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

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

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

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

軟件質量評估

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

McCall軟件質量模型（1977）

image-20210506114507956

image-20210506114643587

Boehm軟件質量模型（1978）

三層模型：

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

在這里插入圖片描述

ISO 9126軟件質量模型（1993）

三層模型：

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

image-20210506120807755

軟件缺陷

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

現象：

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

產生：

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

構成：

image-20210506123254562

在不同階段的分布

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

image-20210506123313492

修復缺陷成本：

image-20210506123507060

軟件測試和開發、質量保證的關系，TDD

軟件測試與開發的關系

image-20210506123718499

image-20210506123713349

軟件質量保證（SQA）

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

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

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

  • 建立軟件質量要素的度量機制，了解各種指標的量化信息，向管理者提供可視信息。

測試 vs. SQA

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

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

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

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

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

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

image-20210506125305534

軟件測試分類

image-20210506125512773

不同的分類：

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

靜態和動態測試

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

動態測試：運行程序

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

黑盒測試與白盒測試

黑盒測試：

image-20210506130249167

白盒測試

image-20210506130301061

小結

image-20210506130311783

軟件測試級別及任務

image-20210506130417002

系統功能性測試

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

系統非功能性測試

系統非功能性測試是將軟件放在整個計算機環境下，包括軟硬件平台、某些支持軟件、數據和人員等，在實際運行環境下進行一系列的測試，包括：

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

主動測試和被動測試

主動測試方法：測試人員主動向被測試對象發送請求、或借助數據、事件驅動被測試對象的行為，從而驗證被測試對象的反應或輸出結果。

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

image-20210506141449303

α、β測試

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.

靜態測試

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

image-20210506142708690

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

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

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

代碼審查

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

  • 代碼審查小組

    • 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. 其他檢查

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

代碼走查

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

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

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

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

黑盒

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

等價類划分法

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

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

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

image-20210506211911925

確定等價類的方法

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

image-20210506215222581

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

image-20210506215245753

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

image-20210506215348236

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

  • 交通工具的類型必須是公共汽車、卡車、出租車、火車或摩托車

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

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

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

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

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

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

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

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

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

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

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

示例

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

image-20210506222208103

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

邊界值分析法

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

確定邊界值的方法

如果輸入條件規定了值的范圍，則應取剛達到這個范圍的邊界的值，以及剛剛超越這個范圍邊界的值作為測試輸入數據。
image-20210506222344848
如果輸入條件規定了值的個數，則用最大個數、最小個數、比最小個數少一、比最大個數多一的數作為測試數據。

image-20210506222350298

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

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

示例一

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位正整數

image-20210506223005087

示例三

image-20210506223047328

Test cases :

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

數值邊界值檢驗

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

image-20210506223237969

字符的邊界值檢驗

ASCII是常見的編碼方式

image-20210506223302829

示例四：

一個二元函數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) 四種。

image-20210506223429350

基於組合及其優化的技術

判定表方法

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

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

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

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

“閱讀指南”決策表

image-20210507121116759

判定表元素

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

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

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

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

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

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

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

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

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

image-20210507170421178

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

image-20210507170442636

⑤ 化簡。

化簡原則：

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

image-20210507170524817

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

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

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

image-20210507171020358

因果圖法

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

  • 產生背景：

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

image-20210507173642660

image-20210507173715805

基本符號

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

image-20210507173904360

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

image-20210507173916131

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

image-20210507173936864

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

image-20210507173941855

約束

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

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

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

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

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

      image-20210507174248075

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

      image-20210507174253669

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

      image-20210507174257098

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

      image-20210507174300623

  • 輸出條件約束類型

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

      image-20210507174304091

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

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

  • 第一列字符必須是A或B，第二列字符必須是一個數字，滿足要求時進行文件的修改；
  • 如果第一列字符不正確，給出信息L；
  • 如果第二列字符不是數字，給出信息M。
  1. 根據題意，原因和結果如下：

原因：

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

結果：
21——修改文件；
22——給出信息L；
23——給出信息M。

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

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

image-20210507175239713

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

image-20210507175333114

示例

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

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

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

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

    原因：

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

    結果：

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

    2. 退還1元硬幣

    3. 退還5角硬幣

    4. 送出橙汁飲料

    5. 送出啤酒飲料

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

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

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

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

    4. 錢已付清

      image-20210507175949450

  3. 轉換成判定表

    image-20210507180001555

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

    image-20210509100349553

正交實驗法

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

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

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

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

image-20210507180209482

產生背景

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

測試原理

  • 不要測試所有的組合，測試所有的“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}.

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

image-20210507180522041

第二步：去掉重復的行。

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

image-20210507180612802

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

白盒

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

邏輯覆蓋

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

路徑覆蓋

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

語句覆蓋

基本思想

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

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

image-20210507230731516

判定覆蓋

基本思想

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

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

image-20210507231058625

條件覆蓋

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

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

條件覆蓋的基本思想：

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

image-20210507231039767

列出所有條件

image-20210507231427963

覆蓋所有條件

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

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

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

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

判定-條件覆蓋

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

image-20210507234421259

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

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

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

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

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

image-20210507234502354

條件組合測試

條件組合覆蓋的基本思想

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

與條件覆蓋的區別

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

示例：

image-20210507234635045

image-20210507234911517

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

image-20210507235216324

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

基本路徑覆蓋

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

image-20210507235350550

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

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

  • 如一個函數包含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

示例

image-20210507235817017

確定線性獨立的路徑集合

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

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

基本集合不一定唯一

image-20210507235958382

示例

image-20210508000042538

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

小結

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

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

集成測試

自頂向下﹑自底向上等集成策略

集成測試的模式

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

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

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

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

驅動模塊：用於模擬被測試模塊的上一級模塊，相當於被測試模塊的主程序，用於接收測試數據，並把這些數據傳送給被測試模塊，啟動被測試模塊，最后輸出實測結果。

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

示例

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

做法：

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

image-20210508144551544

大棒集成方法(Big-bang Integration)

采用大棒集成方法,先是對每一個子模塊進行測試（單元測試階段），然后將所有模塊一次性的全部集成起來進行集成測試 。

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

image-20210508144637403

自頂向下法(Top-down Integration)

image-20210508144728268

自底向上法 Bottom-up Integration

image-20210508144737470

自頂向下VS自底向上

image-20210508144756177

混合策略(Modified Top-down Integration)

image-20210508144900860

混合法：

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

三明治集成方法(Sandwich Integration)

image-20210508144923144

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

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

持續集成(Continuous Integration)

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

單元測試﹑驗收測試﹑回歸測試﹑性能測試等基本概念

單元測試

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

時機：

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

概念：模塊、組件、單元

為何要進行單元測試

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

單元測試的目標

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

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

驅動程序和樁程序

運行單元程序有時需要基於被測單元的接口，開發相應的驅動模塊和樁模塊。

驅動模塊（drive）:對底層或子層模塊進行測試所編寫的調用這些模塊的程序。

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

單元測試停止條件

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

功能測試

業務邏輯是關鍵

功能測試要點

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

功能測試的整體思路

客戶需求為導向

image-20210509121411767

性能測試（系統測試）

性能測試（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): 在軟件產品完成了系統功能和非功能測試之后、產品發布之前所進行的軟件測試活動它是技術測試的最后一個階段，也稱為交付測試。

測試內容

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

測試內容：

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

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

測試步驟

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

驗收標准和注意事項

驗收測試完成標准:

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

注意事項：

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

α/β測試

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

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

回歸測試

回歸測試的目的

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

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

image-20210508151817012

回歸測試策略

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

軟件測試

對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


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 軟件質量保證與測試 基本內容 軟件質量保證體系是什么 敏捷軟件質量保證的方法與實踐 6.1.軟件質量保證 軟件質量保證與測試作業（一）---- 什么是圖靈測試 代碼審查如何保證軟件質量 軟件測試之-軟件質量、軟件質量特性 軟件質量保障與測試 軟件測試之軟件質量模型 軟件質量特性及測試類別梳理
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM