本文內容整理自西安交通大學軟件學院杜小智老師的mooc附件ppt

mooc鏈接：軟件質量保證_中國大學MOOC(慕課)

寫在前面

本文是我在復習軟件質量保證課程時整理的復習資料，內容不是很全，只涉及到了Mooc的前兩章內容，考試內容我也不太記得了，需要特別強調的是他考到了實驗！！！就是讓做的那個JUnit5的實驗，考的也比較簡單，我們只考到了讓編寫對于一個東西的測試代碼，如果實驗自己寫的完成這個也不是很困難，然后再就是給了一個網易郵箱的注冊界面，讓等價類分析，然后還有路徑測試，和邊界值測試，其實上課雖然講了10種，但是應該就只考了這三種，可以看看mooc的視頻或者ppt，我也整理出來了，如果需要的話可以看這（里面整理到的題目都必須要搞懂，不然考試就備受折磨）。選擇和簡答也中規中矩，但我記不得有啥，不過不是很難，應該有RUP？或許吧，反正應該就是mooc前兩章的東西，如果不會的話編起來也挺容易的（我自己覺得是這樣的）

一、軟件質量保證基礎知識

Six software engineering practices

• 開發迭代
• 管理需求
• 使用組件架構
• 模型可視化(UML)
• 持續驗證質量
• 管理變更

相關術語

錯誤

• 人們在開發軟件過程中發生的過錯(mistake) ;
  • 客戶可能未完全描述清楚他的意圖;
  • 分析人員未完全理解客戶的需求、編寫出不完善的需求文檔;
  • 設計人員未完全弄清楚需求文檔描述的問題; .
  • 實現人員受限于自身能力及工作狀態編寫出不完善的程序;
• 軟件錯誤是一種人為的過程， 對于軟件本身來講是一種外部行為。

缺陷

• 錯誤在程序中的表現;
• 存在于軟件(文檔、數據及程序)之中的那些不希望或不可接受的偏差;
• 當缺陷被激活時，會發生軟件故障;
• 缺陷是造成軟件故障甚至失效的內在原因;
• 常用Bug指代缺陷。

故障

• 軟件運行過程中出現的不希望/不可接受的內部狀態; .
• 軟件喪失了在規定的限度內執行所需功能的能力;
• 故障是動態的，可能會導致失效;
• 故障是軟件缺陷的內在表現。

失效

• 軟件運行時產生的不希望/不可接受的外部行為結果;
• 系統行為對用戶預期的偏離;
• 失效是軟件缺陷的外在表現，只有運行中的軟件才可能發生失效
• 失效可能會帶來事故

總結

軟件缺陷產生的原因

軟件缺陷的類型

• 軟件未實現需求規格說明書要求的功能;
• 軟件出現了需求規格說明書指明不應該出現的錯誤;
• 軟件實現了需求規格說明書中未提到的功能;
• 軟件未實現需求規格說明書雖未明確提及但應該實現的功能; .
• 軟件難以理解、不易使用、運行緩慢等，即:用戶體驗不佳。

軟件缺陷產生的原因

需求規格說明書的問題

導致軟件缺陷最大的原因是產品需求規格說明說明書

團隊協作問題

• 不同階段的團隊成員相互理解不一致;
• 相互職責劃分不夠清晰，存在扯皮推諉情況;
• 溝通不夠充分，對接口的理解不一致,造成單元無法集成;
• 公司或團隊文化，對軟件質量不夠重視;
• 團隊成員技術水平有限。

未考慮復雜的應用場景

• 未考慮大量用戶同時使用軟件系統的情況;
• 未考慮海量數據使用場合;
• 對于邊界條件缺乏考慮;
• 只考慮正常情況，對于異常情況未充分考慮;
• 對于一些實時性系統，未進行整體考慮和精心設計，未注意時間同步要求;
• 只考慮系統自身，未考慮系統與第三方軟件及硬件之間的依賴關系。

技術方面問題

• 開發人員的技術具有局限性;
• 新技術不成熟或對新技術不夠熟練，使得軟件存在缺陷;
• 用戶的要求在現有技術水平下不可能實現;
• 軟件邏輯過于復雜，在問題分解時劃分的不夠合理。

總結

• 引起軟件故障的原因涉及:人員、技術、管理及成本等多方面;
• 缺陷的存在是軟件不能按期完成或失敗的重要原因。

軟件缺陷分類

按開發階段分類

按嚴重程度分類

典型的軟件缺陷

輸入、輸出缺陷

數據缺陷

計算缺陷

邏輯缺陷

缺口缺陷

軟件質量

質量定義

質量不等于需求規格說明書

不同人對于質量的關注點不同

質量維度

質量維度：FURPS

• 功能測試：Function test
• 易用性測試：Usability test
• 可靠性測試：Reliability test
• 性能測試：Performance test
• 可支持性測試：Supportability test

功能測試

易用性測試

可靠性測試

性能測試

可支持性測試

質量的維度

Qos/非功能性需求

軟件質量定義

• GB/T12504-90：軟件蠶品種能滿足給定需求的各種特性的綜合。這些特性稱為質量特性，包括：功能性、可靠性、易用性、可維護性、可移植性、經濟性等
• ANSI/IEEE 729標準：軟件產品中能慢組規定的和隱含的與需求有關的全部特征和特性

軟件質量模型

軟件質量模型

• McCall質量模型
• ISO/IEC 9126質量模型
• Boechm質量模型
• ISO 9000:2000質量標準
• Perry模型

McCall質量模型

產品操作質量因子

產品修復和產品轉變質量因子

質量標準

總結

ISO 9126質量模型

質量特性與子特性

兩種模型異同

相同

不同

總結

沒有一種標注的質量模型可以應用于各類軟件項目

軟件質量保證

軟件質量保證的定義

軟件質量保證（Software Quality Assurance，SQA），是確保軟件產品自誕生起到消亡止的全生命周期的質量活動，即確定、達到和維護需要的軟件質量高而進行的所有有計劃的系統性管理活動。

目標

• 保證軟件開發及其維護符合功能與技術需求;
• 保證軟件開發及其維護符合管理需求;
• 為實現前兩個目標，組織一些活動來改進軟件開發效率和維護效率。

軟件質量保證活動

• 項目前質量活動
• 軟件生命周期中的質量活動
• 基礎設施方面
• 管理方面的質量活動
• 軟件質量標準
• SQA自身的考慮

項目前質量活動

• 合同評審活動
  • 確保用戶需求清晰、確保項目規劃和資源需求估計合理、對參與項目的專業員工的能力進行評審、評估客戶能否正常履行合同、并對開發風險進行評估。
• 制定開發計劃
  • 開發進度及人員安排進行規劃,明確所需要的硬件資源、開發工具、過程管理方式，確定與合作伙伴的分工與協作。
• 制定質量計劃
  • 明確質量目標、并將質量目標分解為多個可量化的子目標，明確每個階段開始和結束的質量標準，給出較為詳細的評審、測試、驗證及確認活動的安排。

軟件生命周期中的質量活動

基礎設施方面

管理方面的質量活動

軟件質量標準

SQA自身的考慮

SQA與軟件測試的對比

• 軟件質量保證（SQA）
  • 面向過程
  • 注重減少開發過程中的錯誤做法
  • 過程：怎樣做事情
• 軟件測試
  • 面向產品
  • 注重發現產品中的缺陷
  • 產品：過程的最終結果
• 交匯點
  • SQA一般通過努力改進過程來改進產品

軟件測試定義與目標

軟件測試

• 保證和提高軟件質量的手段
• 更關注軟件產品
• 重點在于發現軟件產品中的缺陷

軟件測試定義

• 狹義定義：
  • 為了發現錯誤而執行程序的過程
• 廣義定義：
  • 在軟件開發過程中的所有評審、確認、檢驗等活動

定義說明

• 由特定測試團隊執行的一個正式過程
• 按照預先計劃的測試過程來執行計劃的測試用例
• 軟件行為是可以預測的且穩定的
• 軟件測試不等于軟件使用

軟件測試目標

• 直接目標
  • 發現盡可能多的缺陷
  • 評估軟件質量
  • 在規定的時間和預算內，執行測試工作
• 簡介目標
  • 編制軟件錯誤記錄，用于錯誤預防

討論

是否可以通過測試發現所有缺陷？

• 比如窮舉行測試，一般而言是不行的，采用窮舉行測試不顯示也不可能
• 即使可以窮舉所有路徑，程序可能依然存在錯誤
  • 路徑測試并不能保證程序滿足系統功能需求
  • 程序可能遺漏了某些路徑
  • 路徑測試難以返現數據敏感的錯誤

目標：以有限的輸入，返現盡可能多的bug

軟件測試模型

軟件測試模型

• V模型
• W模型
• X模型
• H模型

V模型

• 單元測試與詳細設計對應;
  • 主要針對程序源碼進行測試;
  • 通常發生在項目的早期，在每個最小可測單元完成之后，立即進行測試工作;
  • 通常由開發人員執行單元測試，以保證自己編寫的程序不包含明顯的缺陷;
  • 也可以由測試人員進行單元測試來檢驗該程序單元是否滿足了預期要求。
• 集成測試對應于概要設計
  • 涉及多個單元綜合在一起進行測試
  • 單元之間數據傳遞是否正確
  • 單元之間的接口是否一致
• 系統測試對應于需求分析;
  • 將所有程序單元綜合在一起;
  • 并同計算機硬件、輸入輸出接口設備、第三方系統、數據以及人等一起進行測試;
  • 涉及功能性、非功能性方面。
• 驗收測試由用戶主導
  • 目的是為了檢驗軟件開發團隊所交付的軟件是否滿足其最終需求;
  • 采用真實的業務數據;
  • 不僅關注功能是否實現，還關注程序的非功能性要求;
  • 可能會請一-些專家及組織中相關人員來使用軟件，或者請第三方測試機構來檢驗軟件。

缺點

• 將測試活動作為編碼之后的一個環節，理論上還是一個瀑布模型，只是將測試活動進行了細化;
• 通過測試發現的缺陷，修復成本往往很高。

W模型

• 基于盡早地和不斷地進行測試的原則;
• 驗證(Verification)
  • 是指開發人員是否在正確地做事情，強調過程的正確性,不僅檢驗當前階段是否正確，還檢驗當前階段是否與上一個階段相一致;
• 確認(Validation)
  • 是指開發人員是否在做正確的事情,強調結果的正確性,不僅檢驗當前階段是否正確，還檢驗當前階段的工作是否與用戶的需求相一致。
• 優點
  • 強調測試應伴隨整個軟件開發周期;
  • 測試的對象也不僅僅是程序，還包括需求、設計及相關文檔。
• 缺點
  • 仍然將開發活動分解為需求分析、設計、編碼等串行活動; .
  • 測試和開發之間也是一種線性的先后關系;
  • 不支持迭代式開發。

軟件測試分類

6個維度分類

• 按階段分類
• 按是否運行軟件分類
• 按設計方法分類
• 按測試執行者分類
• 按需求分類
• 按測試對象分類

按單元分類

• 單元測試(Unit testing) 針對的是一-個小的程序單元，用于檢驗該單元是否滿足預定功能;
• **集成測試(Integration testing) **是將多個被測后的程序單元綜合在一起進行的一種測試活動，其目標主要是發現與接口有關的問題;
• **系統測試(System testing) **是將所有程序單元綜合在一-起， 并同計算機硬件、輸入輸出接口設備、第三方系統以及人等一起進行測試;
• **驗收測試(Acceptance testing) **是由用戶主導的測試，目的是為了檢驗軟件開發團隊所交付的軟件是否滿足其最終需求。

按是否運行軟件分類

• **靜態測試(Static testing)是指不需要執行被測軟件而進行的測試活動。
  • 桌面檢查、代碼走查、同行評審、靜態分析等;
  • 往往能發現大量錯誤(淺顯)
• **動態測試(Dynamic testing) **是指實際執行軟件的測試活動，在測試過程中，將預先設計好的測試用例或臨時設計的測試用例輸入給被測軟件，然后判斷程序的輸出是否符合預期，往往能夠發現些深層次錯誤。

按設計方法分類

• 黑盒測試(Black box testing)、行為測試、功能性測試或基于需求的測試。
  • 只關心軟件的輸入和輸出、不關心軟件采用哪種編程語言實現;
  • 設計依據是軟件需求規格說明書。
• 白盒測試(White box testing)、玻璃盒測試(Glass box testing)、透明盒測試或結構性測試(Structural testing)。
  • 基于程序源碼的測試。
• 灰盒測試(Gray box testing)
  • 介于白盒測試與黑盒測試之間，是二者相結合的方法。

按測試執行者分類

• 人工測試(Manual testing) 也稱為手工測試，是指測試工作由人來逐個完成。測試人員通過手工方式給被測軟件輸入-個測試用例，等被測軟件執行完成以后，手工記錄該測試用例是否通過。
• 自動化測試(Automatic testing) 是由計算機自動完成的測試，在測試過程中，不需要或很少需要人工干預。錄制/回放、腳本技術、數據驅動、關鍵字驅動和業務驅動等;
• 人工測試與自動化測試相結合。

按需求分類

• 功能性測試(Functional testing) 主要基于軟件需求規格說明書進行測試，驗證軟件是否實現了所期望的每個功能，也包括檢驗軟件是否存在多余功能或遺漏了某些功能。
• 非功能性測試(Non-functional testing) 是指出功能性測試之外的其它系統級別的測試。
  • 性能測試、安全性測試、可靠性測試、易用性測試、兼容性測試、壓力測試、文檔測試、用戶界面測試…

按測試對象分類

• 桌面程序測試是經典的軟件測試，在互聯網出現之前，軟件測試多數屬于桌面程序測試。它針對的是運行于計算機上的本地化程序。
• 嵌入式系統測試不僅關注其功能是否滿足需求，更加關注其性能、可靠性等方面的需求Web程序的測試不僅局限于功能方面的測試,還需要考慮性能測試、界面測試、安全性測試及兼容性測試。
• Web程序的測試不僅局限于功能方面的測試，還需要考慮性能測試、UI測試、安全性測試及兼容性測試。
• 移動APP測試包括功能性測試、兼容性測試、隱私測試等。

軟件測試原則

10個原則

測試思想與測試用例

測試思想

概念

• 測試思想（Test idea）是辨別某個測試可能有用的簡要說明
• 測試思想與測試用例不同，它是測試用例的思想來源

來源

案例

某程序接受范圍為[10,100]的整型輸入,有哪些輸入值的思考

測試用例

組成

• 輸入：前提（在測試用例執行之前已經出在的環境）、由某種測試方法所表示的實際輸入
• 預期輸出：后果和實際輸出

測試活動

典型測試用例信息

二、軟件測試流程

RUP測試流程

RUP（Rational Unified Process）

軟件過程

• 軟件工程過程提供規范但靈活的方法來指派軟件項目團隊中每個成員的任務和職責
• 目標是在規定的時間和預算內，保證軟件產品的質量滿足用戶的需求
• 過程定義了為達到某個目標，誰(who) 應該做什么(what)、在什么時候(when) 做、如何(how) 做

軟件工程生命周期

RUP基本術語

RUP軟件側測試角色

• 測試經理(Test Manager)
  • 對整個測試工作負責
  • 明確測試任務與目標
  • 制定測試計劃
  • 安排測試人員
  • 協調資源
• 測試分析師(Test Analyst)
  • 分析被測軟件的特征
  • 細化測試目標
  • 構思測試思想
  • 設計測試用例
  • 準備測試數據
  • 分析測試結果
  • 編寫軟件缺陷報告
• 測試設計師(Test Designer)
  • 測試開發工程師、測試架構師、測試自動化專家
  • 定義測試方法
  • 確定測試環境和配置
  • 開發自動化測試工具
  • 提供測試指導手冊
  • 本質上是開發人員
• 測試員(Tester)
  • 執行測試用例
  • 記錄測試結果
  • 測試_工作的執行者，可以利用測試設計師提供的自動化測試工具執行測試工作
  • 對自動化測試能否成功起到很重要作用
  • 可能會編寫測試腳本

RUP測試流程

定義評估任務

主要任務

定義評估任務（Define Evaluation Mission）的目標：確定測試工作的重點

常見目標

目標變化

• 測試團隊可能會同時有多個目標;
• 測試團隊的工作目標也會隨著軟件生命周期而發生變化;
• 每次迭代的目標明確非常關鍵，并基于目標來進一步制定計劃

指定測試計劃

• 考慮被測軟件的特征、測試團隊的人員組成、測試周期、測試目標等因素;
• 明確規定測試工作的范圍、方法、資源和進度
• 明確每個任務的責任人，評估可能存在的風險。
• 指定工作范圍不完全等同于開發工作范圍
  • 測試考慮更多
  • 每次迭代的測試目標不同

測試方法

• 測試方法（Test Approach）有時也稱為測試策略（Test Strategy）
• 確定將要具體使用的測試技術，從而完成預期測試使命
• 一個好的測試方法通常包括五個方面
  • 多樣性
  • 以風險為中心
  • 與產品相關
  • 實際可行
  • 可防御

多樣化

• 不應只采用一-種測試技術，而是同時采用多種技術;
• 每一種測試技術都有優缺點，只適合發現某類問題，而對于其它類型的缺陷則無法發現;
• 同時綜合應用多種測試技術，有助于增加發現軟件缺陷的概率。

以風險為中心

與產品相關

實際可行

可防御

測試與評估

測試與評估的目標

• 工作重心：如何達到所需的測試深度和廣度
• 測試執行工作并對測試結果進行分析
• 設計測試分析師和測試員

需要解決的問題

• 如何進行測試工作
• 如何評估測試結果
• 如何編寫缺陷報告

測試技術

測試技術

測試技術的維度

缺陷報告

• 缺陷報告體現了測試員的能力
• 一個優秀的測試員，不一定是發現缺陷數量最多的那個人，而是使缺陷被修復數量最多的那個人。

拒絕修復缺陷的原因

如何讓程序員接受缺陷

編寫缺陷報告原則

• 清晰
• 簡單

缺陷報告

缺陷報告示例

跟隨測試

• 當發生失效時，要進行跟隨測試: .
  • 分析失效產生的條件
  • 發現失效發生的規律
  • 分析邊界條件
  • 分析不可復現的缺陷

為什么要跟隨測試

例子

不懂缺陷，臨界條件，失效

跟隨測試定義

• 跟隨測試是一種探索性測試
• 有助于幫助開發人員理解缺陷并加快缺陷的修復
• 在開始看到失效后繼續進行測試，以期望發現缺陷的所有影響

跟隨測試技術

• 改變測試行為
• 改變選項和配置
• 改變運行環境
• 改變測試數據

改變測試行為

改變選項和配置

改變運行環境

• 軟件環境
  • 操作系統、數據庫、瀏覽器
• 硬件環境
  • 處理器類型、內存大小、網絡帶寬
• 在測試過程中，應該同時在兩臺配置完全不同的計算機上執行測試工作，從而檢查缺陷是否和運行環境有密切關系

改變測試數據

• 測試數據的變化也會給程序帶來較大的影響
  • 小文件->大文件
  • 小的并發量->大的并發量
• 在實際測試工作中，要認真設計測試數據，從而更有效地發現程序中存在的缺陷

完成驗收任務

主要任務

• 涉及兩類角色:測試經理和測試分析師
• 主要任務:撰寫測試總結報告
• 不斷反饋測試I作的進展情況
  • 目前已進行了多少測試工作?
  • 還有多少測試工作需要完成?
• 這兩個問題是復雜的多維度問題，不能簡單回復

測試工作進展

測試總結報告

• 風險和職責
• 測試情況匯報
• 缺陷度量
• 延期或不修復bug的確認

風險和職責

測試情況匯報

缺陷度量

• 自開始到現在項目出現的Bug情況以及修復情況用圖的方式展示
• 直觀明了地了解項目的質量狀態
• 在項目的后期，如果Bug修復率低于Bug發現率，項目規劃存在風險

理想Bug曲線

實際的Bug曲線

延期或不修復Bug的確認

驗證測試方法

• 目的：確定測試方法是否可行

• 工作重點

  • 較早地驗證測試方法是否可行
  • 建立支撐架構
  • 獲得需要的可測試性
  • 了解每種測試技術的優缺點和適用情況

• 可測試性（Testability）

  • 可見性（Visibility）
    • 測試人員能夠看到和理解軟件正在做什么
  • 可控性（Control）
    • 測試人員能夠強迫某些事情發生

• 改進軟件的可測試性

  • 增加軟件的可見性

    • 軟件使用標準的UI控件
    • 對于每 個類型的錯誤，設定唯一的錯誤消息， 增加關于程序內部的可能錯誤的消息
    • 充分利用日志系統

  • 采用基于組件的架構

    • 通過API來進行自動化測試
    • 暴露接口規范，提供除U接口之外的更多API

  • 使用一些設備和工具.

    • 內存查看器、仿真器

確認構建穩定性

• 冒煙測試、構建回歸測試、構建驗證測試
• 目的：確認構建足夠穩定從而值得測試
• 工作重點:
  • 評估構建的穩定性
  • 評估構建的可測試性
  • 確認這個版本的開發工作符合預期
  • 決定是否值得測試這個構建
  • 如果新的構建被拒絕，繼續測試當前版本的軟件

為什么構建穩定性重要

確認構建穩定性

改進測試資產

• 目的：維護和改進測試資產，增加復用性
• 工作重點：
  • 構建測試套
  • 為測試套編制測試腳本
  • 去除過時的測試資產或投資收益比不高的資產
  • 維護測試環境配置

總結

以上是生活随笔為你收集整理的软件质量保证基本知识加复习建议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。