東南大學《軟件測試》課程復習筆記

本文轉載自查看原文 2020-05-27 22:38 559 學習筆記

2020-05-27
驚聞這兩天就要安排線上考試，抓緊把之前剩了個尾巴的復習筆記完成了，希望可以取得還OK的成績。

整理了一下2019-2020學年計算機學院大三下《軟件測試》課程的內容，僅供參考。

by z0gSh1u

導論 / Chapter 1

大型軟件開發中經常遇到巴別塔和焦油坑（極度混亂、復雜的情況）

什么是錯誤（error）：1+2=5；死機、崩潰…

為什么有錯誤：Everything & Everyone。軟件測試就是為了發現錯誤以便解決錯誤。

軟件測試過程圖

正確的測試策略：盡可能經常測試，並且盡早測試。缺陷發現的越晚，消除的代價就越大。

經典測試理論 / Chapter 2

測試的V模型

提出的四大測試過程：單元測試、集成測試、系統測試、驗收測試

問題：錯誤引入的越早，發現的卻越晚。

單元測試

對最小可測試元素（函數、類）進行測試。

模塊接口測試：檢查進出模塊的數據是否正確
模塊局部數據結構測試：未使用的變量、數組越界…
模塊邊界條件測試：合法數據、非法數據…
模塊獨立執行通路測試：計算錯誤、判定錯誤、控制流錯誤
模塊內部錯誤處理測試：錯誤處理設施是否有效

集成測試

對單元進行集成后測試。測試對象可以是一個包或一組包。

進行集成的方法

增式

A → AB → ABC

特點：工作量小；發現錯誤早；錯誤定位容易；測試徹底；需要機器多；並行性差
- 自頂向下
  
  高級模塊作為驅動，每次替換掉一個低級的stub（樁，臨時占位的模塊），逐步求精。
  
  缺點：需要提供stub；stub模塊可能難以模擬數據
- 自底向上
  
  要編制驅動程序，協調測試用例輸入輸出。生成測試數據沒有困難，適合關鍵模塊在底部的情況。
  
  缺點：不能盡快看到整個程序的框架；時序和資源競爭問題只能到后期發現
非增式

特點：工作量大；發現錯誤晚；錯誤定位難；測試不徹底；需要機器少；並行性好

A → B → C → ABC

系統測試

對系統“整體”進行測試，模擬真實運行環境。

驗收測試

最后一道工序，用戶在場測試，非開發人員和測試人員完成。

α測試（內測）

開發即將完成時進行，可以對程序作小的變動。測試環境受開發方控制，用戶的數量少，時間集中。
β測試（公測）

開發基本完成時進行，正式發布前尋找錯誤。測試環境不受開發方控制，用戶的數量多，時間不集中。

測試任務的過程

測試計划

測試目標

單元測試的目標是檢查最小單元有無錯誤；集成測試的目標是檢查模塊有無錯誤…
測試范圍（回答“哪些“的問題）

哪些接口需要測試？哪些要做性能測試？
測試項目

功能測試；數據庫集成測試…
測試策略

基於代碼覆蓋；基於規格說明…
測試工具
測試資源
產出物件

測試設計

設計測試用例
設計測試腳本
評估測試覆蓋

開發

搭建測試環境
編寫測試腳本

執行

執行測試腳本
分析執行情況
Bug報告 / Bug跟蹤

評估

分析覆蓋率（測試用例覆蓋、代碼覆蓋）
分析缺陷
是否達到退出標准
撰寫報告

測試方法

靜態方法和動態方法
- 靜態分析：檢查和閱讀
- 動態方法：運行測試用例
黑盒測試與白盒測試
- 黑盒測試：不考慮程序內部
- 白盒測試：分析程序的內部結構
回歸測試

檢查修改或增加的部分是正確的，並且沒有造成其他錯誤
模擬用戶操作

測試類型

可靠性測試
功能測試
性能測試
……

測試工具

測試管理工具：Quality Center
性能測試工具：Load Runner
單元測試工具：JUnit

黑盒測試 / Chapter 3

將程序當作黑盒，進行總體功能驗證。

特點：基於規格說明（需求），與代碼實現無關，以用戶視角進行，適用於測試的各個階段。

實施工具：需求規格說明；需求跟蹤矩陣RTM；測試執行數據

實施策略：正面（預期輸入輸出）和負面（非預期輸入）測試用例

等價類划分

將程序的輸入域划分為有效等價類（有效輸入數據）和無效等價類（無效輸入數據），來導出測試用例。

划分准則

下表描述了一些輸入數據類型的等價類划分思想：

例子：

合法的用戶名要求：
（1）由字母開頭；（2）后跟字母或數字的任意組合構成；（3）有效字符數不超過6個

2個有效等價類：
（1）{0<全字母<=6}：John, Kenedy
（2）{0<字母開頭+數字<=6}：u001, user01

4個無效等價類：
（1）字母串，且長度超過6：userabcd
（2）字母開頭的字符、數字組合串，且長度超過6：user01587
（3）長度不超過6的數字開頭串：010ah
（4）其他：數字開頭的字符串集合、空字符串、非法字符串

因果圖（判定表）

多個輸入條件互相關聯、存在邏輯關系時，組合測試可能生成大量無效的測試用例。

因果的四種關系

四種輸入約束，一種輸出約束

輸入：

互斥：最多只有一個成立
包含：至少一個成立
唯一：有且只有一個成立
要求：有向，C1成立則C2成立

輸出：

屏蔽：有向，E1成立則E2不成立

根據因果圖，可以快速排除一些不可能的輸入，和一些不可能的輸入輸出組合。

邊界值分析

利用並擴展了缺陷更容易出現在邊界處的概念。

等價類划分時，往往先要確定邊界值。邊界值分析是等價類划分方法的補充，測試中需要將兩者結合起來使用。

Paul Jorgensen公式

n為存在邊界值的參數個數。

4n+1：基本邊界測試

每個參數取min、min+1、max、max-1各一次，其他參數取典型值；最后全部參數取典型值
6n+1：健壯性邊界測試

每個參數取min、min±1、max、max±1各一次，其他參數取典型值；最后全部參數取典型值
3m：條件邊界測試

每個條件取自身、±1各一次

白盒測試 / Chapter 4

白盒測試就是結構化測試。兩個特點：

基於代碼
盡可能覆蓋實現的行為

概論

靜態白盒測試

不執行軟件，審查軟件設計、體系結構和代碼。

特點：

可發現某些機器發現不了的錯誤
利用不同人對代碼的不同觀點
節約計算機資源，但以增加人工成本為代價

動態白盒測試

提供源代碼和可執行程序，測試過程需要在計算機上執行程序。

優點：

能檢測代碼中的判斷和路徑
對代碼的測試比較徹底

缺點：

無法檢測不可達路徑
不能驗證需求規格

覆蓋准則

我們不可能進行窮舉測試，覆蓋准則回答了“測試執行到何時才是足夠”的問題。

基於控制流的動態白盒測試方法

語句覆蓋

測試用例能使得每個可執行語句都至少執行一次。

例子：

問題：

100%的語句覆蓋很困難，可能存在不可達代碼
可能無法發現一些嚴重問題

判定覆蓋

測試用例使得被測程序的每個判定分支至少經過一次（即真假至少取一次）。

特點：

判定覆蓋包含了語句覆蓋，並避免了遺漏邊的問題
不能發現條件表達式中的錯誤

條件覆蓋

保證每個判斷中的每個原子條件的可能取值（不是每種組合）至少滿足一次。

例：if A and B then Action1

則（1）A=true，B=true（2）A=false，B=false 兩個用例即滿足要求

條件覆蓋不能保證程序所有分支都被執行。

條件組合覆蓋

保證每個條件的取值組合至少出現一次。問題是代價昂貴（2^n）。

某些條件組合是不可能的（如F OR F = F）。

判定條件覆蓋

每個條件的所有可能取值至少一次（條件覆蓋），每個判斷本身所有可能結果也至少一次（判定覆蓋）。

路徑覆蓋

保證每條可能執行到的路徑都至少經過一次。

優點：相對徹底；缺點：路徑數可能指數級增加（2^n，n是分支次數）；可能存在不可達路徑

基本路徑測試

尋找基本路徑，保證每條路徑至少執行一次。

從流程圖到流圖

流圖：描述程序中的邏輯控制流（順序結點可以合並）
尋找基本路徑

基本路徑：貫穿程序的、至少引入一組新的處理語句或一個新判斷的程序通道

例：

圈復雜度：度量基本路徑數，也是所有語句被執行一次所需測試用例數的下限。高圈復雜度的模塊蘊含錯誤的可能性最大，是測試中關注的焦點。

基本路徑集合可能有多種，但基本路徑數是確定的，等於圈復雜度。

尋找基本路徑：
- 找到從入口到出口的最短路徑
- 遞歸地改變該最短路徑上所有判定結點的真假情況，生成新的路徑
- 直到找到所有基本路徑
產生測試用例

根據基本路徑設計測試用例進行測試。

基本路徑的本質

每一條路徑可以表示成邊的向量，Px=(e1, ..., en)（n為邊數，元素為該邊在路徑中的出現次數）。其他任何路徑對應的向量，都可以用這些基本路徑的向量線性組合得到。這說明只要基本路徑測試正確，則其他邏輯也測試正確。

循環的處理

簡單循環

跳過；執行一次；執行兩次；執行m次；執行n-1、n、n+1次（n為循環次數，m<n）
嵌套循環
- 先測試最內層循環，此時外層的循環變量取最小值，內層按簡單循環測試
- 從內往外測試上層循環，更外層的取最小值，更內層的取典型值，該層按簡單循環測試
- 最后全體按同時取最小或最大循環次數測試
串接循環
- 串接互相獨立：分別用簡單循環方法測試
- 串接不獨立（第一個循環變量與第二個循環控制相關）：把第一個看作外循環，第二個看作內循環，按嵌套循環測試
非結構循環

需要先進行結構化。可以使用重復編碼法、狀態變量法、判定轉移法。

基於數據流的動態白盒測試方法

根據程序中變量定義和其后變量使用的位置來選擇程序的測試路徑。

一些定義：

P：程序
G(P)：程序流圖
V：變量集合
PATH(P)：P的所有路徑集合
DEF(v, n)：變量v的定義節點是n
USE(v, n)：變量v的使用節點是n
- P-USE：謂詞使用，即在條件判斷語句中使用
- C-USE：運算使用，即在計算表達式中使用
- O-USE：輸出使用
- L-USE：數組定位使用
- I-USE：循環迭代次數控制使用
DU-PATH：定義-使用路徑，是PATH中的某條路徑，以DEF起始，中間可有其他DEF，到USE終止
DC-PATH：定義-清除路徑，DEF起始，中間沒有其他DEF

測試過程

分析出DEF和USE節點，記DEF節點數為NDEF，USE節點數為NUSE
列出可能的DU-PATH（NDEF*NUSE條）
約簡DU-PATH，對於相同前綴的，只保留最長的
針對每個剩下的DU-PATH設計測試用例

Q問題

面向路徑的測試數據生成問題——是否存在一組輸入，使得P中任意一條語句可被執行，在理論上是不可判定的。

解決方法：

隨機法
靜態法
- 符號執行：用符號值表示程序變量，然后模擬程序執行
- 區間算術：數值和變量都用區間表示，然后進行區間消減
迭代松弛法
遺傳算法
模擬退火

面向對象軟件測試 / Chapter 5

面向對象核心概念

對象（實例）：可操作性的實體
消息：對象之間通過消息傳遞來協作
接口：對象行為聲明的集合
類：具有共性的對象的集合
封裝
繼承：類的依賴關系
多態：重載，動態綁定

OO軟件測試概論

與傳統測試的異同

單元測試時基於兩個基本元素：METHOD和CLASS
系統測試與傳統測試類似，仍然基於需求規約
集成測試是OO測試最復雜的部分

面向對象技術對軟件測試的影響

類的使用

使得基本可測單元是類或對象，而不是子程序。在對每個類進行單元測試后還要對類簇進行測試。
封裝的使用

信息隱藏使得對象的一部分不可訪問，減輕了波動影響。但測試時經常需要訪問對象的內部狀態，信息隱藏給這帶來了難度。

修改時需要大量的回歸測試。
繼承的使用

要確定衍類中從基類繼承的已測試的功能是否需要再測試。
多態和動態綁定的使用

引入了不可判定問題：難以確定該用例使得哪個多態方法被激活；多態組件的每個可能的綁定都需要獨立測試，而實際上又難以找到所有的綁定。

狀態的控制分布在整個系統中，使得難以對每個狀態進行單一的測試。
抽象的使用

要執行內部的結構測試時，降低了軟件的可測試性。

OO軟件測試

OO軟件的開發過程

采用迭代式增量開發過程模型，每次迭代包含OOA（分析）、OOD（設計）、OOP（編程）三個階段。

面向對象測試模型（OOTM）

在整個軟件開發生命周期全過程中不斷測試。

OOA Test、OOD Test

測試分析和設計的結果，由建模專家、領域專家、軟件專家參與
OOP Test

針對編程風格和程序代碼進行測試，采取單元測試、集成測試等手段
OO Unit Test

對具體單一的功能模塊的測試（類）
OO Integrate Test

對系統內部的相互服務進行測試（函數間、類間合作）
OO System Test

最后階段的測試，主要以用戶需求為測試標准

面向對象單元測試（OO Unit Test）

面向對象的單元測試，實際就是對類的測試。

基於服務的類測試策略

考察類中的方法對數據的操作。

為了避免軟件測試的盲目性，Kung提出了塊分支圖法（BBD）

一個方法f的BBD是一個五元組(修改前的類Du, 修改后的類Dd, 參數表P, 調用的服務Fe, 控制結構圖G)：

構造BBD圖后可對程序的流程進行抽象進行測試：
- 繪制服務的控制流圖
- 確定基本路徑集（每個可執行語句至少一次）
- 生成測試用例
基於狀態的類測試策略

從外界向對象發送特定消息序列，來測試對象的響應狀態。利用對象狀態圖（OSD）模型來測試：

OSD描述了對象在其生命周期中的所有狀態及其狀態之間的相互轉移。構造過程如下：
- 掃描源程序，得出執行分析表
- 確定對象狀態
- 構造狀態轉移
- 構造測試消息序列
- 生成測試用例（根據每條測試消息序列，選擇相應的數據進行測試）

面向對象的集成測試（OO Integrate Test）

由於程序的控制流無法確定，只能對編譯完成的程序做基於黑盒的集成測試。要參考OOD的結果。

靜態測試

得出源程序的類系統圖和函數功能調用關系圖，檢測程序結構是否符合設計要求（OOP是否符合OOD要求）
動態測試

根據靜態測試得出的圖表，設計測試用例，達到一定的覆蓋標准

設計測試用例的方法：
- 確定類的狀態和行為
- 確定待測類的所有關聯
- 根據類的對象構造測試用例，使用一定的輸入激發某種狀態，也要設計類禁止的負例

面向對象的系統測試（OO System Test）

測試軟件與系統其他部分配套運行的表現。要參考的OOA的結果。

主要測試內容：

功能測試；強度測試；性能測試；安全測試；恢復測試；可用性測試；安裝/卸載測試

性能測試 / Chapter 6

引言

性能需求是一種非功能性需求。

性能測試是模擬正常、峰值、異常負載條件下，測量系統的性能指標能否達到需求，以找出瓶頸，優化系統。

性能測試的步驟

熟悉應用：以知道需要模擬什么
測試需求：可能需要進行指標的轉換（UV如何轉換成吞吐量、響應時間指標）
測試准備
- 機器數量
- 網絡環境：帶寬應高於服務器吞吐量，避免出現瓶頸
- 測試數據准備：用戶注冊、數據量
- 測試用例設計
- 測試腳本准備
測試執行：監控客戶端和服務器性能，后續歸檔處理
測試結果分析：內存問題、共享資源競爭問題

性能測試的指標

響應時間

網絡傳輸時間+應用服務器處理時間+數據庫處理時間
並發用戶數
吞吐量
- 業務視角：請求數/秒、頁面數/秒…
- 網絡視角：字節/秒
資源利用率（內存、磁盤、處理器、網絡）

實際使用/總量

性能測試的方法

基准測試

制定一個性能基准測試標准。系統變化之后，進行一次相同標准的測試，即可看出變化對性能的影響
負載測試

找出負載逐漸增加時系統性能指標的變化情況，找出系統的負載極限
壓力測試

找出高負載系統下的問題，如資源競爭、同步問題、內存泄漏
容量測試

找出能正常運行的最大負載或工作量
失效恢復測試

局部發生故障，能多大程度上繼續使用系統
並發測試
……

例子 - 壓力測試

相關工具：LoadRunner、QALoad…

安全測試 / Chapter 7

引論

基本概念

safety安全可靠：軟件在運行過程中不到達某個不安全的狀態
security安全保密：軟件不會被黑客攻擊
vulnerability漏洞：系統設計、實現或操作和管理中存在的缺陷或弱點

為什么要關注軟件安全

黑客攻擊機會越來越多，越來越容易
漏洞利用速度越來越快
病毒的種類和感染的機會越來越多

軟件安全問題

安全問題	例子
內存安全	緩沖區溢出問題可能導致攻擊者控制內存空間，執行惡意代碼
進程/線程安全	線程同步問題、線程協作問題、線程死鎖問題、線程控制問題…
異常/錯誤處理	異常捕獲安全、異常處理安全…
輸入安全	不要信任用戶的任何輸入…
國際化安全	字符集轉換安全
面向對象安全	對象的內存分配與釋放、序列化安全…
Web安全	XSS攻擊、SQL注入…
訪問控制不當	特權提升問題…
遠程調用安全	惡意調用RPC服務器中的過程…
拒絕服務攻擊	DoS、DDoS…
數據加密保護	加密算法不良、密碼保存不安全…
代碼注入	DLL注入…