Ch3質(zhì)量保證與測試策略

軟件測試方法和技術(shù)

-Ch.3質(zhì)量保證與測試戰(zhàn)略Zhu.Kerry@gmail朱少民KerryZhu第二章回想Zhu.Kerry@gmail軟件質(zhì)量就是客戶的稱心度軟件缺陷(Bug)是什么軟件測試的根本方法 -白盒/黑盒，靜態(tài)/動態(tài)，自動化/手工，…軟件測試的分類和階段 -單元、集成、系統(tǒng)〔性能、適用性、兼容性…〕、驗收測試軟件測試的任務(wù)范疇 -戰(zhàn)略、方案、設(shè)計、執(zhí)行、報告、評價…第三章質(zhì)量保證與測試戰(zhàn)略Zhu.Kerry@gmail3.1軟件質(zhì)量保證3.2測試戰(zhàn)略3.3測試方案3.4軟件質(zhì)量的可靠性評價3.1軟件質(zhì)量保證〔SQA〕SQA概述SQA活動SQS與軟件測試的關(guān)系Zhu.Kerry@gmail什么是SQA?軟件質(zhì)量保證是經(jīng)過對軟件產(chǎn)品和活動有方案的進(jìn)展評審和審計來驗證軟件能否符合規(guī)范的系統(tǒng)工程活動.Zhu.Kerry@gmail確保SQA活動要自始至有方案的進(jìn)展審查軟件產(chǎn)品和活動能否遵守適用的規(guī)范、規(guī)程和要求并得到客觀驗證。SQA的活動和結(jié)果要保證全員參與，溝照射暢。逐級處理不符合問題SQA活動技術(shù)方法的運(yùn)用正式技術(shù)評審的實施軟件測試規(guī)范的執(zhí)行修正的控制度量質(zhì)量記錄和記錄保管Zhu.Kerry@gmailSQA活動的影響要素知識構(gòu)造：專業(yè)的技術(shù)，例如質(zhì)量管理與控制知識、統(tǒng)計學(xué)知識等。閱歷根據(jù)：假設(shè)沒有這些規(guī)范，就無法準(zhǔn)確地判別開發(fā)活動中的問題，容易引發(fā)不用要的爭論，因此組織該當(dāng)建立文檔化的開發(fā)規(guī)范和規(guī)程。全員參與：全員參與至關(guān)重要，高層管理者必需注重軟件質(zhì)量保證活動。把握重點：一定要抓住問題的重點與本質(zhì)，盡能夠防止墮入對細(xì)節(jié)的爭論之中。Zhu.Kerry@gmailSQA戰(zhàn)略SQA戰(zhàn)略主要分三個階段：以檢測為重：產(chǎn)品制成之后進(jìn)展檢測，只能判別產(chǎn)質(zhì)量量，不能提高產(chǎn)質(zhì)量量。以過程管理為重：把質(zhì)量的保證任務(wù)重點放在過程管理上，對制造過程中的每一道工序都要進(jìn)展質(zhì)量控制。以新產(chǎn)品開發(fā)為重：在新產(chǎn)品的開發(fā)設(shè)計階段，采取強(qiáng)有力的措施來消滅由于設(shè)計緣由而產(chǎn)生的質(zhì)量隱患。Zhu.Kerry@gmailSQA與軟件測試有什么關(guān)系和區(qū)別？Zhu.Kerry@gmailSQA與軟件測試的關(guān)系SQA是管理任務(wù)、審查對象是流程、強(qiáng)調(diào)以預(yù)防為主測試是技術(shù)任務(wù)、測試對象是產(chǎn)品、主要是以事后檢查SQA指點測試、監(jiān)控測試測試為SQA提供根據(jù)Zhu.Kerry@gmail測試戰(zhàn)略的概念測試戰(zhàn)略通常是描畫測試工程的總體方法和目的。描畫目前在進(jìn)展哪一階段的測試〔如單元測試、集成測試、系統(tǒng)測試〕以及每個階段內(nèi)進(jìn)展的測試種類〔如功能測試、性能測試、壓力測試等〕，以確定合理的測試方案使得測試更有效。Zhu.Kerry@gmail影響測試戰(zhàn)略的要素1、測試完成的規(guī)范規(guī)范的高低對戰(zhàn)略確定有著重要的影響。比如該軟件的應(yīng)該用場所為軍用，這將對軟件的可靠性、平安性要求非常高，但假設(shè)是用于小型商場的收費(fèi)系統(tǒng)由于是內(nèi)部運(yùn)用，主要思索其計算的準(zhǔn)確與精度及復(fù)雜統(tǒng)計與報表生成等方面準(zhǔn)確性與易用性。2、資源情況 參與測試的人、測試中所需求的軟件平臺〔如操作系統(tǒng)甚至?xí)婕暗降谌降囊恍┻\(yùn)用軟件〕及測試能夠用到的相關(guān)硬件設(shè)備〔如計算機(jī)，網(wǎng)絡(luò)硬件其它外設(shè)等〕Zhu.Kerry@gmail制定測試戰(zhàn)略全面細(xì)致地了解產(chǎn)品的工程信息:運(yùn)用領(lǐng)域,測試范圍,市場需求,產(chǎn)品的特點和主要功能,技術(shù)架構(gòu)基于模塊、功能、整體、系統(tǒng)、版本、壓力、性能、配置和安裝等各個要素對產(chǎn)品的影響,公正客觀地開展測試方案根據(jù)程序的重要性和一旦發(fā)生缺點將呵斥的損失,來確定它的測試等級和測試重點仔細(xì)研討測試戰(zhàn)略,以便能運(yùn)用盡能夠少的有效測試用例,發(fā)現(xiàn)盡能夠多的程序錯誤,由于一次完好的軟件測試過后,假設(shè)程序中脫漏的錯誤過多并且很嚴(yán)重,那么闡明本次測試是失敗的,是缺乏的;而測試缺乏意味著讓用戶承當(dāng)隱藏錯誤帶來的危險.同時反過來說,假設(shè)過度測試,那么又會浪費(fèi)許多珍貴的資源.找到一個最正確平衡點。Zhu.Kerry@gmail測試范圍確實立優(yōu)先級最高的需求功能新功能和編碼改動較大(提高性能表現(xiàn))的舊功能運(yùn)用有效的測試技術(shù)去提高測試效果經(jīng)常容易出現(xiàn)問題部分的功能一些經(jīng)常被用戶運(yùn)用的功能和配置Zhu.Kerry@gmail測試?yán)^續(xù)階段確實定當(dāng)測試義務(wù)明確后,測試方案將依賴于測試小組的人力資源而最終確定.Task1/11/81/151/201/292/52/122/202/28需求分析-----設(shè)計審查-------------測試方案預(yù)備任務(wù)-----------------設(shè)計測試用例--------------------功能測試------------集成&系統(tǒng)測試--------------------第一輪測試------------第二輪測試----------確認(rèn)測試------測試結(jié)束-Zhu.Kerry@gmail經(jīng)過/失敗的規(guī)范單個的測試經(jīng)過/失敗測試用例全部產(chǎn)品測試經(jīng)過/失敗每個階段的經(jīng)過/失敗Zhu.Kerry@gmail測試周期MRD/PRD/UISign-offEng.PlanSign-offEng.SpecSign-offTestPlanSign-offProductReviewCodeFreezeTestCaseSign-offCodeCompleteER驗收測試QA創(chuàng)建TestPlanQAQA創(chuàng)建TestCases功能測試寫/審查Spec系統(tǒng)測試單元測試PRD/UI審查QAZhu.Kerry@gmail階段經(jīng)過/失敗的規(guī)范工程經(jīng)理和測試組長曾經(jīng)全部按方案到位?一切相關(guān)的信息曾經(jīng)傳到達(dá)QA?QA.開場了測試設(shè)計?需求階段設(shè)計審查一切設(shè)計中及文檔中的問題都曾經(jīng)被處理?技術(shù)設(shè)計和測試設(shè)計曾經(jīng)終了?最高優(yōu)先級的功能要求曾經(jīng)實現(xiàn)?新功能曾經(jīng)實現(xiàn)?一切的功能是按照設(shè)計來實現(xiàn)的?代碼完成?功能驗證確認(rèn)測試回歸測試完成與否?是不是完全按測試方案完成了一切的測試?沒有嚴(yán)重的缺陷?到達(dá)產(chǎn)品發(fā)布的規(guī)范?測試環(huán)境的檢查?一切嚴(yán)重問題是不是都已測出?功能測試,壓力測試,平安測試,兼容性測試,易用性測試能否都已完成?有沒有妨礙產(chǎn)品發(fā)布的缺陷？系統(tǒng)測試Zhu.Kerry@gmail風(fēng)險評價測試小組開場工程測試時,硬件資源沒有按時配備或依然缺乏開場工程測試時,軟件產(chǎn)品編碼沒有按方案完成開場工程測試時,測試用例沒有預(yù)備好短少按方案參與工程測試的測試人員在工程測試過程中,需求總是不停地改動當(dāng)工程測試進(jìn)展時,在設(shè)計闡明書中被定義的功能總是不停地被修正Zhu.Kerry@gmail測試評價里程碑的定義和跟蹤可以協(xié)助工程管理者掌握工程的進(jìn)展形狀里程碑日期測試方案完成---1/15測試用例完成---1/29功能驗證完成器---2/5代碼凍結(jié)前完成系統(tǒng)測試--2/20版本發(fā)布前完成確認(rèn)測試---2/28Zhu.Kerry@gmail測試方案的創(chuàng)建和評審MRD/PRDreview測試戰(zhàn)略知識傳送日程測試范圍反響討論分析FormalReviewmeeting問題QAdraftofTestPlanUpdatedTestPlanFinalTestPlan測試方法義務(wù)UpdatedTestPlan資源Pear-to-PearorInternalReviewChecklistZhu.Kerry@gmail測試方案內(nèi)容構(gòu)成測試方案制定的第一步就是將軟件分解較小而且相對獨立的功能模塊，寫成測試需求。測試需求有很多分類方法，最普通的一種就是按照功能分類：測試需求是測試設(shè)計和開發(fā)測試用例的根底，分解功能模塊可以更好地進(jìn)展設(shè)計；詳細(xì)的測試需求是用來衡量測試覆蓋率的重要目的；測試需求包括各種測試實踐和開發(fā)以及所需資源。一個測試方案應(yīng)包括：產(chǎn)品根本情況、測試需求闡明、測試戰(zhàn)略和記錄、測試資源配置、方案表、問題跟蹤報告、測試方案的評審、結(jié)果等。Zhu.Kerry@gmail測試方案規(guī)范格式-116componentsofTestPlan(IEEE,1983)Testplanidentifier〔測試方案標(biāo)識)Instruction(引言〕TestItems〔定義或主題詞)Featurestobetested〔需求被測試的功能)Featuresnottobetested(無需被測試的功能)Approach(方法和途徑〕Itemspass/failcriteria〔測試經(jīng)過、失敗的規(guī)范)Suspensioncriteriaandresumptionrequirements〔延遲的規(guī)范和再恢復(fù)的要求)Testdeliverables(測試交付的內(nèi)容)TestingTasks(測試義務(wù)Zhu.Kerry@gmail測試方案規(guī)范格式–216componentsofTestPlan(IEEE,1983)Environmentalneeds〔必備的環(huán)境)Responsibilities(職責(zé))Staffingandtrainingneeds(人員和必需的培訓(xùn))Schedule(時間進(jìn)度表)Riskandcontingencies(風(fēng)險和相關(guān)費(fèi)用〕Approvals〔同意)模板：中文測試方案和英文Zhu.Kerry@gmail3.4軟件質(zhì)量的可靠性評價3.4.1軟件可靠性評價的概述3.4.2軟件可靠性模型3.4.2可靠性評價過程Zhu.Kerry@gmail軟件可靠性評價的概述軟件可靠性評價〔SoftwareReliabilityAssessment〕指根據(jù)軟件系統(tǒng)可靠性構(gòu)造〔單元與系統(tǒng)間可靠性關(guān)系〕、壽命類型和各單元的可靠性實驗信息，利用概率統(tǒng)計方法，評價出系統(tǒng)的可靠性特征量。軟件可靠性評價的要素1〕規(guī)定的時間2〕規(guī)定的環(huán)境條件3〕規(guī)定的功能Zhu.Kerry@gmail軟件可靠性模型軟件可靠性模型〔Softwarereliabilitymodel〕是指為估計或估算軟件的可靠性所建立的可靠性構(gòu)造和數(shù)學(xué)模型。建立可靠性模型是為了將復(fù)雜系統(tǒng)的可靠性逐級分解為簡單系統(tǒng)的可靠性，以便于定量估計、分配、估算和評價復(fù)雜系統(tǒng)的可靠性。1〕可靠性構(gòu)造模型，是根據(jù)系統(tǒng)構(gòu)造邏輯關(guān)系，對系統(tǒng)的可靠性特征及其開展變化規(guī)律做出可靠性評價。2〕可靠性估計模型，是用來描畫軟件失效與軟件缺陷的關(guān)系，借助這類模型，可以對軟件的可靠性特征做出定量的估計或評價。根據(jù)軟件缺陷與運(yùn)轉(zhuǎn)剖面數(shù)據(jù)，利用統(tǒng)計學(xué)原理建立二者之間的數(shù)學(xué)關(guān)系，獲取開發(fā)過程中可靠性變化、軟件在預(yù)定任務(wù)時間的可靠度、軟件在恣意時辰發(fā)生的失效數(shù)的平均值以及軟件在規(guī)定時間間隔內(nèi)發(fā)生失效次數(shù)的平均值。Zhu.Kerry@gmail可