質量保證與測試策略工作Zhu.軟件質量就是客戶的滿意度軟件缺陷(Bug)是什么軟件測試的基本方法

-/黑盒，靜態/動態，自動化/手工，…軟件測試的分類和階段

-單元、集成、系統（性能、適用性、兼容性…）、驗收測試軟件測試的工作范疇

-策略、計劃、設計、執行、報告、評估…第三章質量保證與測試策略Zhu.3.1軟件質量保證3.2測試策略3.3測試計劃3.4軟件質量的可靠性評估3.1軟件質量保證（SQA）SQA概述SQA活動SQS與軟件測試的關系Zhu.什么是SQA?軟件質量保證是通過對軟件產品和活動有計劃的進行評審和審計來驗證軟件是否合乎標準的系統工程活動.

Zhu.確保SQA活動要自始至有計劃的進行審查軟件產品和活動是否遵守適用的標準、規程和要求并得到客觀驗證。SQA的活動和結果要保證全員參與，溝通順暢。逐級解決不符合問題SQA活動技術方法的應用正式技術評審的實施軟件測試標準的執行修改的控制度量質量記錄和記錄保存Zhu.SQA活動的影響因素知識結構：專業的技術，例如質量管理與控制知識、統計學知識等。經驗依據：如果沒有這些標準，就無法準確地判斷開發活動中的問題，容易引發不必要的爭論，因此組織應當建立文檔化的開發標準和規程。全員參與：全員參與至關重要，高層管理者必須重視軟件質量保證活動。把握重點：一定要抓住問題的重點與本質，盡可能避免陷入對細節的爭論之中。Zhu.SQA策略SQA策略主要分三個階段：以檢測為重：產品制成之后進行檢測，只能判斷產品質量，不能提高產品質量。以過程管理為重：把質量的保證工作重點放在過程管理上，對制造過程中的每一道工序都要進行質量控制。以新產品開發為重：在新產品的開發設計階段，采取強有力的措施來消滅由于設計原因而產生的質量隱患。Zhu.SQA與軟件測試有什么關系和區別？

Zhu.SQA與軟件測試的關系

SQA

是管理工作、審查對象是流程、強調以預防為主測試是技術工作、測試對象是產品、主要是以事后檢查SQA指導測試、監控測試測試為SQA提供依據Zhu.測試策略的概念測試策略通常是描述測試工程的總體方法和目標。描述目前在進行哪一階段的測試（如單元測試、集成測試、系統測試）以及每個階段內進行的測試種類（如功能測試、性能測試、壓力測試等），以確定合理的測試方案使得測試更有效。

Zhu.影響測試策略的因素1、測試完成的標準標準的高低對策略確定有著重要的影響。比如該軟件的應該用場合為軍用，這將對軟件的可靠性、安全性要求非常高，但如果是用于小型商場的收費系統由于是內部使用，主要考慮其計算的準確與精度及復雜統計與報表生成等方面準確性與易用性。(降落傘99.9%)2、資源狀況

參與測試的人、測試中所需要的軟件平臺（如操作系統甚至會涉及到第三方的一些應用軟件）及測試可能用到的相關硬件設備（如計算機，網絡硬件其它外設等）

Zhu.制定測試策略

全面細致地了解產品的項目信息:應用領域,測試范圍,市場需求,產品的特點和主要功能,技術架構基于模塊、功能、整體、系統、版本、壓力、性能、配置和安裝等各個因素對產品的影響,公正客觀地開展測試計劃根據程序的重要性和一旦發生故障將造成的損失,來確定它的測試等級和測試重點認真研究測試策略,以便能使用盡可能少的有效測試用例,發現盡可能多的程序錯誤,因為一次完整的軟件測試過后,如果程序中遺漏的錯誤過多并且很嚴重,則表明本次測試是失敗的,是不足的;而測試不足意味著讓用戶承擔隱藏錯誤帶來的危險.同時反過來說,如果過度測試,則又會浪費許多寶貴的資源.找到一個最佳平衡點。Zhu.測試范圍的確立優先級最高的需求功能新功能和編碼改動較大(提高性能表現)的舊功能運用有效的測試技術去提高測試效果經常容易出現問題部分的功能一些經常被用戶使用的功能和配置Zhu.測試持續階段的確定當測試任務明確后,測試計劃將依賴于測試小組的人力資源而最終確定.

Task1/11/81/151/201/292/52/122/202/28需求分析-----設計審查

-------------

測試計劃準備工作

-----------------

設計測試用例

--------------------

功能測試

------------

集成&系統測試

--------------------

第一輪測試

------------

第二輪測試

----------

確認測試

------

測試結束

-

Zhu.通過/失敗的標準單個的測試通過/失敗

測試用例全部產品測試通過/失敗

每個階段的通過/失敗Zhu.測試周期MRD/PRD/UISign-offEng.PlanSign-offEng.SpecSign-offTestPlanSign-offProductReviewCodeFreezeTestCaseSign-offCodeComplete驗收測試QA創建

TestPlanQAQA創建

TestCases功能測試寫/審查Spec系統測試單元測試PRD/UI審查QAZhu.簽字signoffPRD（ProductRequirementDocument），

產品需求文檔.PRD文檔是產品項目由“概念化”階段進入到“圖紙化”階段的最主要的一個文檔，其作用就是“對MRD中的內容進行指標化和技術化”，這個文檔的質量好壞直接影響到研發部門是否能夠明確產品的功能和性能。MRD，英文全稱MarketRequirementDocument，市場需求文檔。該文檔在產品項目中是一個“承上啟下”的作用，“向上”是對不斷積累的市場數據的一種整合和記錄，“向下”是對后續工作的方向說明和工作指導。作用是：產品項目由“準備”階段進入到“實施”階段的第一文檔，其作用就是“對年度產品中規劃的某個產品進行市場層面的說明”，這個文檔的質量好壞直接影響到產品項目的開展，并直接影響到公司產品戰略意圖的實現。BRD，英文全稱為：BusinessRequirementDocument；商業需求描述。基于商業目標或價值所描述的產品需求內容文檔（報告），其核心的用途就是用于產品在投入研發之前，由企業高層作為決策評估的重要依據。BRD是產品生命周期中最早的文檔，再早就應該是腦中的構思了，其內容涉及市場分析，銷售策略，盈利預測等，通常是供決策層們討論的演示文檔，一般比較短小精煉，沒有產品細節。UserInterface(用戶界面)階段通過/失敗的標準

項目經理和測試組長已經全部按計劃到位?所有相關的信息已經傳達到QA?QA.開始了測試設計?需求階段設計審查所有設計中及文檔中的問題都已經被解決?技術設計和測試設計已經結束?最高優先級的功能要求已經實現?新功能已經實現?所有的功能是按照設計來實現的?代碼完成?功能驗證確認測試回歸測試完成與否?是不是完全按測試計劃完成了所有的測試?沒有嚴重的缺陷?達到產品發布的標準?測試環境的檢查?所有嚴重問題是不是都已測出?功能測試,壓力測試,安全測試,兼容性測試,易用性測試是否都已完成?有沒有阻礙產品發布的缺陷？系統測試Zhu.風險評估

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

里程碑的定義和跟蹤可以幫助項目管理者掌握項目的進行狀態里程碑

日期

測試計劃完成

---1/15

測試用例完成---1/29

功能驗證完成器

---2/5

代碼凍結前完成系統測試

--2/20

版本發布前完成確認測試

---2/28Zhu.測試計劃的創建和評審MRD/PRDreview測試策略知識傳遞日程測試范圍反饋討論分析FormalReviewmeeting問題QAdraftofTestPlanUpdatedTestPlanFinalTestPlan測試方法任務UpdatedTestPlan資源Pear-to-PearorInternalReviewChecklistZhu.測試計劃內容構成測試計劃制定的第一步就是將軟件分解較小而且相對獨立的功能模塊，寫成測試需求。測試需求有很多分類方法，最普通的一種就是按照功能分類：測試需求是測試設計和開發測試用例的基礎，分解功能模塊可以更好地進行設計；詳細的測試需求是用來衡量測試覆蓋率的重要指標；測試需求包括各種測試實際和開發以及所需資源。一個測試計劃應包括：產品基本情況、測試需求說明、測試策略和記錄、測試資源配置、計劃表、問題跟蹤報告、測試計劃的評審、結果等。Zhu.測試計劃標準格式-116componentsofTestPlan(IEEE,1983)Testplanidentifier（測試計劃標識)Instruction(引言）TestItems（定義或主題詞)Featurestobetested（需要被測試的功能)Featuresnottobetested(無需被測試的功能)Approach(方法和途徑）Itemspass/failcriteria（測試通過、失敗的標準)Suspensioncriteriaandresumptionrequirements（延遲的標準和再恢復的要求)Testdeliverables(測試交付的內容)TestingTasks(測試任務Zhu.測試計劃標準格式–216componentsofTestPlan(IEEE,1983)Environmentalneeds（必備的環境)Responsibilities(職責)Staffingandtrainingneeds(人員和必需的培訓)Schedule(時間進度表)Riskandcontingencies(風險和相關費用）Approvals（批準)模板：中文

測試計劃

和英文Zhu.3.4軟件質量的可靠性評估軟件可靠性評估的概述軟件可靠性模型可靠性評估過程Zhu.軟件可靠性評估的概述軟件可靠性評估（SoftwareReliabilityAssessment）指根據軟件系統可靠性結構（單元與系統間可靠性關系）、壽命類型和各單元的可靠性試驗信息，利用概率統計方法，評估出系統的可靠性特征量。軟件可靠性評估的要素

1）規定的時間2）規定的環境條件3）規定的功能Zhu.軟件可靠性模型

軟件可靠性模型（Softwarereliabilitymodel）是指為預計或估算軟件的可靠性所建立的可靠性結構和數學模型。建立可靠性模型是為了將復雜系統的可靠性逐級分解為簡單系統的可靠性，以便于定量預計、分配、估算和評價復雜系統的可靠性。1）可靠性結構模型，是依據系統結構邏輯關系，對系統的可靠性特征及其發展變化規律做出可靠性評價。2）可靠性預計模型，是用來描述軟件失效與軟件缺陷的關系，借助這類模型，可以對軟件的可靠性特征做出定量的預計或評估。依據軟件缺陷與運行剖面數據，利用統計學原理建立二者之間的數學關系，獲取開發過程中可靠性變化、軟件在預定工作時間的可靠度、軟件在任意時刻發生的失效數的平均值以及軟件在規定時間間隔內發生失效次數的平均值。Zhu.可靠性評估過程可靠性數據收集

用時間定義的軟件可靠性數據可以分為四類：失效時間數據，記錄發生一次失效所累積經歷的時間；失效間隔時間數據，記錄本次失效與上一次失效間的間隔時間；分組數據，記錄某個時間區內發生了多少次失效；分組時間內的累積失效數，記錄某個區間內的累積失效數。這四類數據可以互相轉化。測試時間；含有測試用例的測試計劃或測試說明；所有與測試有關的測試結果，包括所有測試時發生的故障；參與測試的個人身份。可靠性評估報告Zhu.白盒測試白盒測試也稱結構測試或邏輯驅動測試，它是按照程序內部的結構測試程序，通過測試來檢測產品內部動作是否按照設計規格說明書的規定正常進行，檢驗程序中的每條通路是否都能按預定要求正確工作。

白盒測試方法的分類語句覆蓋，語句覆蓋法的基本思想是設計若干測試用例，運行被測程序，使程序中的每個可執行語句至少被執行一次判定覆蓋，判定覆蓋法的基本思想是設計若干用例，運行被測程序，使得程序中每個判斷的取真分支和取假分支至少經