【軟體測試】質量保證與測試策略

飄走的我發表於2017-01-09

1.軟體質量保證（SQA）



1.1   什麼是SQA ？


軟體質量保證是通過對軟體產品和活動有計劃的進行評審和審計來驗證軟體是否合乎標準的系統工程活動. 


  • 確保SQA活動要自始至有計劃的進行
  • 審查軟體產品和活動是否遵守適用的標準、規程和要求並得到客觀驗證。
  • SQA的活動和結果要保證全員參與，溝通順暢。
  • 逐級解決不符合問題

1.2  SQA活動

  • 技術方法的應用
  • 正式技術評審的實施
  • 軟體測試
  • 標準的執行
  • 修改的控制
  • 度量
  • 質量記錄和記錄儲存
 1.3  SQA活動的影響因素

  • 知識結構：專業的技術，例如質量管理與控制知識、統計學知識等。
  • 經驗
  • 依據：如果沒有這些標準，就無法準確地判斷開發活動中的問題，容易引發不必要的爭論，因此組織應當建立文件化的開發標準和規程。
  • 全員參與：全員參與至關重要，高層管理者必須重視軟體質量保證活動。
  • 把握重點：一定要抓住問題的重點與本質，儘可能避免陷入對細節的爭論之中。
1.4  SQA 策略

SQA策略主要分三個階段：
  1. 以檢測為重：產品製成之後進行檢測，只能判斷產品質量，不能提高產品質量。
  2. 以過程管理為重：把質量的保證工作重點放在過程管理上，對製造過程中的每一道工序都要進行質量控制。
  3. 以新產品開發為重：在新產品的開發設計階段，採取強有力的措施來消滅由於設計原因而產生的質量隱患。

1.5  SQA與軟體測試的關係
  • SQA 是管理工作、審查物件是流程、強調以預防為主
  • 測試是技術工作、測試物件是產品、主要是以事後檢查
  • SQA指導測試、監控測試
  • 測試為SQA提供依據


2. 測試策略


2.1  測試策略的概念


測試策略通常是描述測試工程的總體方法和目標。描述目前在進行哪一階段的測試（如單元測試、整合測試、系統測試）以及每個階段內進行的測試種類（如功能測試、效能測試、壓力測試等），以確定合理的測試方案使得測試更有效。 


2.2  影響測試策略的因素

1、測試完成的標準
標準的高低對策略確定有著重要的影響。比如該軟體的應該用場合為軍用，這將對軟體的可靠性、安全性要求非常高，但如果是用於小型商場的收費系統由於是內部使用，主要考慮其計算的準確與精度及複雜統計與報表生成等方面準確性與易用性。


2、資源狀況
參與測試的人、測試中所需要的軟體平臺（如作業系統甚至會涉及到第三方的一些應用軟體）及測試可能用到的相關硬體裝置（如計算機，網路硬體其它外設等） 


2.3  制定測試策略

  1.  全面細緻地瞭解產品的專案資訊:應用領域,測試範圍,市場需求,產品的特點和主要功能,技術架構
  2.  基於模組、功能、整體、系統、版本、壓力、效能、配置和安裝等各個因素對產品的影響,公正客觀地開展測試計劃
  3.  根據程式的重要性和一旦發生故障將造成的損失,來確定它的測試等級和測試重點
  4.  認真研究測試策略,以便能使用盡可能少的有效測試用例,發現儘可能多的程式錯誤,因為一次完整的軟體測試過後,如果程式中遺漏的錯誤過多並且很嚴重,則表明本次測試是失敗的,是不足的;而測試不足意味著讓使用者承擔隱藏錯誤帶來的危險.同時反過來說,如果過度測試,則又會浪費許多寶貴的資源. 找到一個最佳平衡點。

2.4  測試範圍的確立

  • 優先順序最高的需求功能
  • 新功能和編碼改動較大(提高效能表現)的舊功能
  • 運用有效的測試技術去提高測試效果
  • 經常容易出現問題部分的功能 
  • 一些經常被使用者使用的功能和配置

2.5  測試持續階段的確定


當測試任務明確後,測試計劃將依賴於測試小組的人力資源而最終確定.


2.6 通過/失敗的標準

  • 單個的測試通過/失敗  ---> 測試用例
  • 全部產品測試通過/失敗  --->     每個階段的通過/失敗
2.7  測試周期


2.8   階段通過/失敗的標準 




2.9  評估

2.9.1  風險評估

  • 測試小組開始專案測試時,硬體資源沒有按時配備或仍然不足
  • 開始專案測試時, 軟體產品編碼沒有按計劃完成
  • 開始專案測試時, 測試用例沒有準備好
  • 缺少按計劃參加專案測試的測試人員
  • 在專案測試過程中, 需求總是不停地改動
  • 當專案測試進行時, 在設計說明書中被定義的功能總是不停地被修改

2.9.2  測試評估


里程碑的定義和跟蹤可以幫助專案管理者掌握專案的進行狀態
  •   里程碑                    日期
  •   測試計劃完成            --- 1/15
  •   測試用例完成            --- 1/29
  •   功能驗證完成器           --- 2/5
  •   程式碼凍結前完成系統測試    -- 2/20
  •   版本釋出前完成確認測試    ---2/28


3.  測試計劃


3.1  測試計劃的建立和評審



 3.2  測試計劃內容構成

測試計劃制定的第一步就是將軟體分解較小而且相對獨立的功能模組，寫成測試需求。
測試需求有很多分類方法，最普通的一種就是按照功能分類：
  •  測試需求是測試設計和開發測試用例的基礎，分解功能模組可以更好地進行設計；
  •  詳細的測試需求是用來衡量測試覆蓋率的重要指標；
  •  測試需求包括各種測試實際和開發以及所需資源。


一個測試計劃應包括：產品基本情況、測試需求說明、測試策略和記錄、測試資源配置、計劃表、問題跟蹤報告、測試計劃的評審、結果等。


3.3  測試計劃標準格式 

  1. Test plan identifier （測試計劃標識)
  2. Instruction (引言）
  3. Test Items  （定義或主題詞)
  4. Features to be tested  （需要被測試的功能)
  5. Features not to be tested (無需被測試的功能)
  6. Approach (方法和途徑）
  7. Items pass/ fail criteria （測試通過、失敗的標準)
  8. Suspension criteria and resumption requirements （延遲的標準和再恢復的要求)
  9. Test deliverables (測試交付的內容)
  10. Testing Tasks (測試任務
  11. Environmental needs （必備的環境)
  12. Responsibilities (職責)
  13. Staffing and training needs (人員和必需的培訓)
  14. Schedule (時間進度表)
  15. Risk and contingencies (風險和相關費用）
  16. Approvals （批准)


4.軟體質量的可靠性評估


4.1  軟體可靠性評估的概述


軟體可靠性評估（Software Reliability Assessment）指根據軟體系統可靠性結構（單元與系統間可靠性關係）、壽命型別和各單元的可靠性試驗資訊，利用概率統計方法，評估出系統的可靠性特徵量。


軟體可靠性評估的要素 
1）規定的時間
2）規定的環境條件
3）規定的功能

4.2  軟體可靠性模型 

軟體可靠性模型（Software reliability model）是指為預計或估算軟體的可靠性所建立的可靠性結構和數學模型。建立可靠性模型是為了將複雜系統的可靠性逐級分解為簡單系統的可靠性，以便於定量預計、分配、估算和評價複雜系統的可靠性。


1）可靠性結構模型，是依據系統結構邏輯關係，對系統的可靠性特徵及其發展變化規律做出可靠性評價。

2）可靠性預計模型，是用來描述軟體失效與軟體缺陷的關係，藉助這類模型，可以對軟體的可靠性特徵做出定量的預計或評估。依據軟體缺陷與執行剖面資料，利用統計學原理建立二者之間的數學關係，獲取開發過程中可靠性變化、軟體在預定工作時間的可靠度、軟體在任意時刻發生的失效數的平均值以及軟體在規定時間間隔內發生失效次數的平均值。 

4.3  可靠性評估過程

可靠性資料收集 
用時間定義的軟體可靠性資料可以分為四類：
  • 失效時間資料，記錄發生一次失效所累積經歷的時間；
  • 失效間隔時間資料，記錄本次失效與上一次失效間的間隔時間；
  • 分組資料，記錄某個時間區內發生了多少次失效；
  • 分組時間內的累積失效數，記錄某個區間內的累積失效數。這四類資料可以互相轉化。
  1. 測試時間；
  2. 含有測試用例的測試計劃或測試說明； 
  3. 所有與測試有關的測試結果，包括所有測試時發生的故障；
  4. 參與測試的個人身份。 

可靠性評估報告

相關文章