软件质量测试
軟件測試
第一章：軟件測試核心概念
1.2：軟件測試的概念
軟件
定義
軟件 = 程序 + 數據(庫) + 文檔 + 服務
特點
軟件測試
定義
軟件測試是使用人工或者自動手段來運行或測試某個系統(tǒng)的過程，其目的在于檢驗被測軟件系統(tǒng)是否滿足規(guī)定的需要，或是弄清被測系統(tǒng)的預期結果與實際結果之間的差別。
主要解決問題
認識誤區(qū)
軟件缺陷
定義
- 軟件測試員認為軟件難以理解，不宜使用，運行速度緩慢，或者最終用戶覺得不好
- 軟件未達到需求規(guī)格說明書中指明的功能
- 軟件出現了需求規(guī)格說明書中指明不會出現的錯誤
- 軟件功能超出需求規(guī)格說明書中指明的范圍
- 軟件未達到需求規(guī)格說明書中雖未指明但應達到的目標
軟件測試員的主要任務
- 根據用戶的意見和反饋執(zhí)行測試
- 根據SRS描述，針對系統(tǒng)的有效輸入及有效操作下的正常功能進行測試
- 依據SRS的描述或者個人經驗，針對系統(tǒng)在無效輸入或者無效操作下的軟件容錯能力進行測試
- 開發(fā)人員應遵循良好的開發(fā)習慣，與用戶和項目成員及時溝通，避免植入無依據的軟件缺陷
- 需求分析階段強調測試專家的介入，從測試的視角完善SRS，提高系統(tǒng)的外部環(huán)境容錯能力
測試分析
-
測試為完整性和有效性
-
代碼的測試
-
測試的管理
軟件去缺陷的來源及代價
- 系統(tǒng)本身的復雜性不斷增長，使得測試范圍和難度也隨之增大
- 與用戶溝通不當導致無法獲取最真實的用戶需求
- 需求不斷變化
- 開發(fā)人員的勞累，自大和追求個性化，導致不斷植入各種缺陷
- 進度壓力導致測試被壓縮，無法進行充分的測試
- 對文檔的輕視致使測試缺乏依，帶來測試的漏洞
測試用例的概念
測試用例 = 輸入 + 輸出 + 測試環(huán)境
- 輸入數據
- 正常數據
- 錯誤數據
- 邊界數據
自動化測試
手動測試
自動測試技術
- 優(yōu)點：
自動化測試實施要點
實質：為了追求快速，高效地發(fā)現和預防回歸缺陷
自動化測試的局限性
測試人員需要編寫，不斷調試測試腳本。
第三章：黑盒測試技術
概述
黑盒測試僅需要知道被測對象的輸入和預期輸出，不需要了解其實現細節(jié)
對測試人員透明，且程序透明，不需要測試人員了解其內部實現
適用
測試為函數，對象功能時----測試不需要了解被測程序的內部實現邏輯時
評價
邊界值測試
測試核心和難點
測試用例設計
- 測試數據選擇
- 窮舉法
- 典型值法
- 邊界組合方式
- 強邊界法 — 覆蓋所有輸入條件的所有邊界組合 — 多個輸入條件同時取邊界值
- 弱邊界法 — 單缺陷假設
- 全邊界法 — 強邊界 + 弱邊界
等價類測試
軟件測試目標
- 測試的完備性：在理論上完全覆蓋被測對象的輸入輸出域
- 測試的無冗余性：每個測試用例都是為了揭示某一類型的軟件缺陷而設計，射出任何用例都將影響對該類缺陷的挖掘能力
將輸入域劃分為若干子集
- 子集中所有數據等價—在系統(tǒng)中被處理的方式相同
- 子集之間互不相交
- 所有子集的并集為整個輸入域
測試用例設計
相關概念
有效等價類：其對于SRS而言，合理，有意義的輸入數據構成的集合，即被測對象可以接受的數據
無效等價類：其對于SRS而言，不合理，無意義的輸入數據構成的集合，即被測對象不能接受的數據
等價類劃分時，必須遵循 – 獨立性假設，即輸入條件之間相互獨立，互不影響
用例設計
強組合方式：構成測試用例的每個輸入條件對應某個有效等價類 — 全覆蓋
弱組合方式：測試用例僅需完全覆蓋所有輸入條件的有效等價類
針對無效等價類的測試用例設計
單缺陷假設 — 每個用例僅覆蓋一個輸入條件的某一個無效等價類
基于決策表的測試
為了彌補等價類劃分時強加的獨立性假設，其設計在等價類劃分的基礎上
決策表劃分
- 輸入區(qū)，輸出區(qū)，輸入取值區(qū)，輸出取值區(qū)
| 輸出區(qū) | 輸出取值區(qū) |
決策表的簡化
兩個前提
- 輸出相同
- 輸入相似
補充
- 當輸入條件本身不存在相關性，則不需要使用決策表，因為等價類劃分本身不存在冗余
- 其不處理無效等價類
- 僅針對輸入域進行分析
基于正交表的測試
在數據毫無規(guī)律或測試人員不了解數據規(guī)律的情況下使用
特點
- 均勻分布：實驗點均勻分布
- 整齊可比：實驗結果便于分析
用例設計
- 等水平正交表 — Ln(q ^ s)
- 混合水平正交表 — Ln(q1 ^ s1 * q2 ^ s2)
n：實際測試用例的個數 — 正交表的列數
q：每個輸入條件所取測試數據的個數
q ^ s：理論上的全組合方式個數
一般應采用邊界值測試和等價類測試方法，通過結合邊界值來建立正交表和設計測試用例，對邊界進行補充測試，從而得到多個邊界缺陷共存的情況
基于場景的測試
以事件流為核心，是高層測試設計的基礎
用例設計
基本流：從初始狀態(tài)到最終狀態(tài)過程的最主要的一個業(yè)務流程
備選流：！！！
場景構建
場景可以僅包含一個基本流，可以包含一個基本流和若干的備選流
最少的場景數等于事件流總數 —基本流 + 備選流
補充
- 一個測試用例對應一個場景，但一個場景可對應多個測試用例
- 僅對輸入域分析
- 部分場景邏輯上可行，但現實不可行
第五章：白盒測試技術
白盒測試基于軟件的源代碼，已知產品的內部工作過程
關注對象
- 源代碼 — 查看源代碼，檢查代碼規(guī)范等問題，并查找代碼缺陷
- 程序結構 — 通過函數調用圖，算法流程圖等反應程序設計的相關圖表，找到代碼缺陷，或評價程序執(zhí)行效率，數據定義和使用缺陷
優(yōu)勢
- 針對性強，測試效率高
- 在函數級別工作，缺陷修復成本低
局限性
- 對測試人員技術要求高
適用階段
- 被測對象為函數或者功能
靜態(tài)白盒測試
-
代碼檢查
- 主要通過同行評審方法來發(fā)現缺陷，即基于缺陷預防的思想
- 同行審批
- 審查
- 團隊評審
- 走查
- 結對編程
- 同行桌查
- 輪查
- 特別檢查
-
靜態(tài)結構分析
- 通過引入多種形式的圖表，幫助快速了解程序設計和結構，更好地理解源代碼，并找到缺陷和代碼優(yōu)化方向
- 函數調用函數圖
- 函數控制流圖
- [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-lcgN8kow-1661077722011)(D:\Typora\picture\bffd7f6544da486b8508668970dea965.png)]
- ：函數出入口
- ：串行語句
- ：邏輯判斷(開始)
- ：邏輯判斷(結束)
- ：break
- ：包含函數調用
- 設計特點
- 多出口
- 環(huán)復雜度高
- 存在非結構化設計
-
代碼質量度量
- 軟件質量模型
- 外部質量模型
- 高層：質量特性 — 軟件質量需求評價標準
- 中層：質量子特征 — 軟件質量設計評價準則
- 底層：質量度量 — 軟件質量度量評價準則
- 內部質量模型
- 高層：質量特性 — 軟件質量需求評價標準
- 中層：質量子特征 — 軟件質量設計評價準則
- 底層：質量度量 — 軟件質量度量評價準則
- 使用中質量模型
- 外部質量模型
- 代碼質量度量模型
- 質量因素
- 質量標準
- 質量度量元：規(guī)范代碼行為屬性
- 代碼質量的自動度量
- 代碼之來給你可以通過測試工具來完成自動度量，以直觀的圖表形式呈現，即利于后續(xù)分析，又節(jié)省人力，加快工作進度
- 軟件質量模型
-
靜態(tài)結構分析的局限
- 函數調用圖中無法看出接口的復雜度，流程控制如無法看出每個判定節(jié)點的復雜度和循環(huán)結構的復雜度
對判定的測試
對代碼中所有的邏輯值均需要測試真值和假值的情況
- 每條語句至少執(zhí)行一次
- 關注語句而非判定，即隱式的分支無效(分支上不存在可執(zhí)行語句)
- 保證程序中每個判定結點的真假路徑各執(zhí)行一次
- 處理復合判定表達式時會存在遺漏
- 保證每個符合表達式中每個表達式的真假情況個執(zhí)行一次
- 其并不能保證判定覆蓋
- 判定覆蓋 + 條件覆蓋
- 測試用例復雜，有時難以設計
- 每個判定結點中的簡單判定可能取值結果組合情況應該至少執(zhí)行一次
- 測試用例會存在冗余，規(guī)模巨大
- 在滿足判定/條件覆蓋的基礎上，每個簡單判定都應該獨立的影響到整個判定表達式取值
- 無法處理耦合的表達式
對路徑的測試
相關概念：
程序圖：經過壓縮后的控制流圖，也是一種特殊形式的有向圖。
- 壓縮：
- 剔除注釋語句
- 剔除數據變量的聲明語句
- 所有的串行結點壓縮為一個節(jié)點
- 所有循環(huán)壓縮為一個循環(huán)
環(huán)復雜度：基于判定節(jié)點對程序圖封閉環(huán)數據造成影響來衡量程序的復雜程度
- 環(huán)復雜度計算
- 直接觀察法
- 程序將二維平面分割為封閉區(qū)域和開放區(qū)域的個數
- 公式計算法
- V(G) = e - n + 1
- e：圖中邊的數量
- n：圖中節(jié)點的總數
- 使用條件：無孤立節(jié)點，且為強連通圖
- V(G) = e - n + 1
- 判定節(jié)點法
- V(G) = P + 1
- P：圖中獨立判定結點的個數
- V(G) = P + 1
- 多出口程序
- 將兩個出口連接到要給虛擬結點(不存在)上，形成單出口程序
- 將兩個出口連接到入口節(jié)點，形成強連通圖
基本復雜度：通過結構化設計節(jié)點不斷進行壓縮，最終得到一個無法壓縮的程序圖
基本原理：將全路徑集合看作一個向量空間，并從全路徑集合中抽取一組線性無關的獨立路徑看作一組向量基。
目標
- 測試的完備性：對獨立路徑的測試達到對所有路徑的測試覆蓋
- 測試的無冗余性：每條路徑都是獨立的，針對每條路徑設計的測試用例之間不存在冗余
獨立路徑的抽取
測試難點
對循環(huán)的測試
重點關注循環(huán)的過程正確性，即在循環(huán)的邊界和運行界限內對循環(huán)體的執(zhí)行過程進行測試
循環(huán)分類
單個循環(huán)
循環(huán)的串聯
- 判定為每個循環(huán)獨立，即可獨立測試
循環(huán)的嵌套
- 先進性內循環(huán)測試，在進行外循環(huán)測試
非結構化的循環(huán)
- 若為編寫人員，改寫為結構化循環(huán)，若為測試人員，則按照相關邏輯設計并執(zhí)行測試用例
對變量的測試
定義/引用異常缺陷
用例設計
相關概念
- 定義節(jié)點 — 變量值發(fā)生改變
- 使用節(jié)點 — 使用
- 定義/使用節(jié)點對
- 定義/使用路徑 — 從節(jié)點值被改變到該變量停止使用的一條路徑
- 定義清除路徑 — 從節(jié)點值被改變到該變量停止使用的一條路徑(中間節(jié)點不修改變量值)
所有的定義/使用路徑(不包括定義清除路徑)為高風險路徑
第七章：單元測試
單元測試是指對軟件中的最小可測試單元或基本組成單元進行檢查和驗證
單元
- C(面向過程)：常指一個函數或者一個過程
- Java(面向對象)：一般指一個類
- 圖形化軟件：常指要給窗口或一個菜單
單元測試內容
- 靜態(tài)檢查
- 適用于所有可能出現的運行情況
- 動態(tài)測試
- 能夠真實反映程序在特定運行期的運轉情況
被測功能單元的測試為黑盒測試，對代碼所作測試為白盒測試
靜態(tài)檢查
- 主要對模塊局部數據結構的測試
動態(tài)測試
-
模塊接口測試
-
模塊邊界條件測試
-
模塊獨立路徑測試
-
錯誤處理路徑測試
驅動和樁模塊的設計
驅動模塊：模擬被測單元的上級模塊，用于接收測試數據，啟動被測模塊和輸出結果
- 利用已有測試用例，接受測試的輸入數據
- 將測試數據傳遞被測單元
- 打印和輸出測試用例的相關結果，判斷測試是通過還是失敗
- 通過測試日志文件記錄測試過程，便于后繼數據保存和分析
樁模塊：被被測模塊所調用的模塊
- 在特定情況下完成原單元的基本功能
- 能夠正確被調用
- 有返回值
- 不包含有單元的所有細節(jié)
認識誤區(qū)
測試需求針對實現的功能或性能，可測試需求是指需求分析是應該注意需求的可測試性要求
單元測試過程
日構建
日構建是自動，完整地構建整個代碼庫的代碼，在構建的同時完成單元測試執(zhí)行的軟件研發(fā)工作模式(一天可構建多次)
優(yōu)勢
- 進度可見，可控
- 適于多環(huán)境下的團隊開發(fā)
- 便于盡早發(fā)現，修復和驗證缺陷
- 增量測試
不足
- 給開發(fā)人員帶來壓力
- 加重開發(fā)經理的工作負擔
- 開發(fā)小組需要投入精力保證每日構建的順暢
- 需要額外忍受負責冒煙測試
回歸測試
主要對修改后的軟件重新進行測試，以保證其正確性
第八章：集成測試
單元測試無法取代集成測試
將經過單元測試的模塊組成子系統(tǒng)或系統(tǒng)，并進行測試的過程，
內容
- 檢查模塊接口間的數據是否會丟失
- 檢查模塊功能是否對其他模塊產生不利影響
- 檢查全局數據結構是否正確
- 單元測試的誤差會不會累加成無法接受的程度
評價
- 測試用例越小越好
- 驅動模塊，樁模塊數量越少越好
- 單個集成測試設計的接口越少越好
集成方式
成對集成
- 容易定位缺陷 — 每個集成測試只存在一對調用單元
鄰居集成
- 鄰居構成
- 中間層模塊 + 上層模塊 + 下層模塊
- 根模塊 + 葉子模塊
- 測試用例減少，驅動模塊和樁模塊相對較少
基于獨立路徑的集成
- 從根節(jié)點到葉子節(jié)點形成的獨立路徑
集成測試遍歷順序的設計
大爆炸集成
一次性組裝所有通過單元測試的模塊
自頂而下的集成
自底而上的集成
三明治集成
上下結合，一同執(zhí)行集成
第九章：系統(tǒng)測試
功能測試
性能測試
安全性測試
兼容性測試
用戶界面測試
進行測試的過程，
內容
- 檢查模塊接口間的數據是否會丟失
- 檢查模塊功能是否對其他模塊產生不利影響
- 檢查全局數據結構是否正確
- 單元測試的誤差會不會累加成無法接受的程度
評價
- 測試用例越小越好
- 驅動模塊，樁模塊數量越少越好
- 單個集成測試設計的接口越少越好
集成方式
成對集成
- 容易定位缺陷 — 每個集成測試只存在一對調用單元
鄰居集成
- 鄰居構成
- 中間層模塊 + 上層模塊 + 下層模塊
- 根模塊 + 葉子模塊
- 測試用例減少，驅動模塊和樁模塊相對較少
基于獨立路徑的集成
- 從根節(jié)點到葉子節(jié)點形成的獨立路徑
集成測試遍歷順序的設計
大爆炸集成
一次性組裝所有通過單元測試的模塊
自頂而下的集成
自底而上的集成
三明治集成
上下結合，一同執(zhí)行集成
第九章：系統(tǒng)測試
功能測試
性能測試
安全性測試
兼容性測試
用戶界面測試
可安裝性測試
總結
- 上一篇： EL表达式和JSTL标准标签库
- 下一篇： yum安装Docker失败No pack