課件01-軟件測試-成果

軟件測評技術

第一部分測試成果及管理測試成果及管理—提要認識軟件測試失效及其管理缺陷及其管理認識—測試的定義由人工或自動方法來執(zhí)行或評價系統(tǒng)或系統(tǒng)部件的過程，以驗證它是否滿足規(guī)定的需求；或識別出期望的結(jié)果和實際結(jié)果之間有無差別。認識—測試的對象軟件被廣泛應用，承擔許多關鍵與核心任務軟件是被開發(fā)或設計的，包括維護階段軟件是邏輯產(chǎn)品，可視性低軟件是復雜的，輸入空間無限大，可執(zhí)行路徑特別多大多數(shù)軟件是定制的，可選標準構(gòu)件少既可能運行在芯片上，也可能運行于大型系統(tǒng)中認識—測試的發(fā)展歷程時間區(qū)間標志性活動~1956面向調(diào)試的階段1957~1978面向證實的階段1979~1982面向缺陷的階段1983~1987面向評價的階段1988~面向預防的階段認識—測試的目的發(fā)現(xiàn)軟件中隱藏的缺陷或其征兆；驗證軟件是否滿足其規(guī)格說明的規(guī)定和要求；為軟件產(chǎn)品質(zhì)量的評價提供依據(jù)，為軟件開發(fā)過程的改進提供支持。認識—測試的焦點開發(fā)過程中的工作產(chǎn)品軟件需求規(guī)格說明軟件設計文檔軟件源代碼軟件產(chǎn)品軟件目標代碼用戶文檔認識—測試的獨立性開發(fā)人員的測試專職測試人員的測試專職測試團隊的測試獨立機構(gòu)的測試用戶的測試認識—測試與調(diào)試測試不是調(diào)試，調(diào)試也不是測試，實際工作中人們卻常將測試與調(diào)試混為一談主要區(qū)別：測試是一種檢驗，調(diào)試是推理過程測試從已知條件開始，使用預先定義的規(guī)程并且有可預知的結(jié)果；調(diào)試的開始條件可能不可知，結(jié)果不可預見測試經(jīng)常由非程序設計人員完成，調(diào)試必須由程序設計者完成認識—驗證與確認驗證(Verification)與確認(Validation)是廣泛認可的質(zhì)量保證方法和手段驗證是指對開發(fā)過程中某項規(guī)定活動進行檢查的過程，以確保該活動實現(xiàn)了規(guī)定能力確認是指審查已建立的軟件產(chǎn)品是否符合客戶需要的過程V&VVerification:

Arewebuildingtheproductright?Validation:

Arewebuildingtherightproduct?認識—驗證與確認認識—測試的公理公理1不可能對程序進行完全的測試局限無法確信規(guī)格說明100%正確無法確信可以達到100%的軟件測試無法保證測試環(huán)境100%滿足測試要求期望證實給定的軟件滿足其規(guī)格說明認識—測試的公理公理2測試無法說明軟件沒有缺陷局限軟件質(zhì)量體現(xiàn)在多個方面，但首先要面對并必須解決的是軟件缺陷，在資源制約和技術限制的條件下，無法保證找到軟件中所有的缺陷期望在給定的時限內(nèi)盡可能多的發(fā)現(xiàn)缺陷和隱患認識—測試的公理公理3發(fā)現(xiàn)問題越多地方,潛在的問題也更多局限不可能通過測試獲得100%的質(zhì)量信心無法確信測試系統(tǒng)(或環(huán)境)的正確性無法確信測試人員完全理解了軟件沒有足夠的資源徹底完成軟件測試期望為軟件產(chǎn)品質(zhì)量的評價提供依據(jù)認識—測試的地位軟件測試是軟件驗證與確認的重要組成部分有效的測試對于開發(fā)可靠、安全和成功的軟件是必須的測試不是“銀彈(silverbullet)”，它具有有效范圍，它不能替代其它軟件工程方法的作用認識—與其他活動的關系軟件質(zhì)量軟件工程方法標準與過程正式技術評審測試SCM與SQA度量與控制認識—測試的主要成果軟件缺陷軟件缺陷的征兆故障失效異常注：相關定義來自IEEEStd1633?-2008IEEERecommendedPracticeonSoftwareReliability認識—缺陷缺陷(Defect)存在于軟件中的、不期望的或不可接受的偏差。在特定的狀態(tài)下，導致軟件不能完成所需的任務典型的軟件缺陷數(shù)組越界使用計算表達式錯誤算法實現(xiàn)錯誤認識—故障故障(Fault)軟件中缺陷的體現(xiàn)。如：軟件的計算或判斷與規(guī)定的不符合等一個故障如果發(fā)生，可能引起失效典型的軟件故障資源泄露執(zhí)行了多余的循環(huán)無限遞歸調(diào)用認識—失效失效(Failure)系統(tǒng)或系統(tǒng)部件不能在規(guī)定的限制內(nèi)完成所需功能功能單元完成所需功能的能力被終止程序的運行偏離了其需求認識—異常觀察到異常(征兆)軟件失效測試失效軟件缺陷(原因)測試缺陷(原因)開發(fā)人員錯誤測試人員錯誤可能造成可能表現(xiàn)為可能是認識—征兆與原因征兆和原因有可能在“地理上”是分離的征兆有可能會因為其他問題的解決而消失征兆有可能是間歇性的原因有可能會歸結(jié)于非錯誤之間的組合原因有可能會歸結(jié)于系統(tǒng)或編譯器錯誤原因有可能會歸結(jié)于每個人都相信的假設認識—失效與缺陷的關系錯誤(Error)在軟件開發(fā)過程中軟件開發(fā)人員產(chǎn)生隱錯／缺陷(bug/defect)在軟件產(chǎn)品中軟件中存在設計者的失誤(錯誤)→導致軟件中留有錯誤的設計(缺陷)→導致軟件錯誤地執(zhí)行(故障)→導致軟件的錯誤行為(失效)。故障(fault)在軟件運行中缺陷被激活失效(failure)在運行階段用戶的經(jīng)歷認識—錯誤錯誤(Error)在軟件開發(fā)過程中出現(xiàn)的不符合期望或不可接受的人為差錯典型的錯誤誤解或遺漏了用戶需求設計沒有完整的實現(xiàn)軟件需求程序設計錯誤認識—軟件測試發(fā)展動態(tài)國外的情況測試是開發(fā)過程的常規(guī)活動測試技術的利用趨于科學國內(nèi)的情況專業(yè)機構(gòu)的情況開發(fā)機構(gòu)的情況評價技術的使用還較局限認識—軟件測試標準進展ISO/IEC25051:2006Softwareengineering--SoftwareproductQualityRequirementsandEvaluation(SQuaRE)--RequirementsforqualityofCommercialOff-The-Shelf(COTS)softwareproductandinstructionsfortesting認識—軟件測試標準進展GB/T25000.51-2010軟件工程軟件產(chǎn)品質(zhì)量要求和評價(SQuaRE)商業(yè)現(xiàn)貨(COTS)軟件產(chǎn)品的質(zhì)量要求和測試細則認識—軟件測試標準進展ISO/IEC/IEEE29119:2013Softwareandsystemsengineering--Softwaretesting認識—軟件測試標準進展ISO/IEC25010:2011Systemsandsoftwareengineering--SystemsandsoftwareQualityRequirementsandEvaluation(SQuaRE)--Systemandsoftwarequalitymodels認識—軟件測試標準進展質(zhì)量特性1特性2特性3特性n子特性1子特性2子特性n屬性1屬性2屬性n屬性1屬性2屬性3屬性n認識—軟件測試標準進展ISO/IEC25010:2011SoftwareproductqualitymodelFunctionalstabilityReliabilityPerformanceefficiencyUsabilitySecurityCompatibilityMaintainabilityPortability認識—軟件測試標準進展ISO/IEC25010:2011FunctionalstabilityFunctionalcompletenessFunctionalcorrectnessFunctionalappropriateness認識—軟件測試標準進展ISO/IEC25010:2011ReliabilityMaturityAvailabilityFaulttoleranceRecoverability認識—軟件測試標準進展ISO/IEC25010:2011PerformanceefficiencyTimebehaviorResourceutilizationCapacity認識—軟件測試標準進展ISO/IEC25010:2011UsabilityAppropriatenessrecognizabilityLearnabilityOperabilityUsererrorprotectionUserinterfaceaestheticsAccessibility認識—軟件測試標準進展ISO/IEC25010:2011SecurityConfidentialityIntegrityNon-repudiationAccountabilityAuthenticity認識—軟件測試標準進展ISO/IEC25010:2011CompatibilityCo-existenceInteroperability認識—軟件測試標準進展ISO/IEC25010:2011MaintainabilityModularityReusabilityAnalyzabilityModifiabilityTestability認識—軟件測試標準進展ISO/IEC25010:2011PortabilityAdaptabilityInstallabilityReplaceability認識—軟件測試標準進展ISO/IEC25040:2011Systemsandsoftwareengineering--SystemsandsoftwareQualityRequirementsandEvaluation(SQuaRE)--Evaluation失效—失效狀態(tài)考慮到相關的操作及環(huán)境條件，由一個或多個失效引起或作用的對系統(tǒng)的直接和后繼的影響不同的失效狀態(tài)對可靠性的影響具有差異失效—Therac-25事件AtomicenergyofCanadaLtd開發(fā)的Therac-25放射治療儀1985.6~1987.1,6人治療過量,其中3人死亡失效—Therac-25原因主循環(huán)中存在競爭條件寄存器溢出失效—Therac-25教訓系統(tǒng)安全性分析、風險分析未包含軟件Therac-25重用了T-20的軟件，假設和前提發(fā)生了改變，但未受到關注失效—Ariane5事件1996年6月4日，Ariane5發(fā)射40秒后爆炸失效—Ariane5直接原因?qū)⒁粋€64位浮點值轉(zhuǎn)換為16位有符號整數(shù)值時，超出了16位整數(shù)的表示范圍，而這個異常未得到正確處理失效—Ariane5經(jīng)驗教訓作了Ariane5和Ariane4具有相同環(huán)境的假設，重用軟件在新的環(huán)境下完全沒有進行測試錯誤處理模塊的處理機制不正確失效—火星探測器事件1999年，火星氣象衛(wèi)星(MarsClimateOrbiter)到達火星之后不久就消失1999年，火星極地登陸者(MarsPolarLander)在火星上著陸時墜毀。失效—火星探測器原因地面系統(tǒng)軟件和飛行器上軟件分別使用公制和英制兩種單位。失效—火星探測器教訓沒有進行充分的測試；發(fā)現(xiàn)異常時，沒有被恰當?shù)慕忉尅ＪА渌咐?·23事件銀聯(lián)出租車計價器GE醫(yī)療軟件因失效主動召回……失效—?列舉你所見、所聞的失效失效—分級失效狀態(tài)可劃分為不同的等級軟件失效的分級可以依據(jù)不同的前提所帶來的安全風險所造成的經(jīng)濟損失對系統(tǒng)任務的影響失效—分級的作用根據(jù)軟件失效的級別，通過可靠性分析，找出關鍵的軟件部件(子系統(tǒng)/配置項/部件/單元/功能)，進行重點管理，降低開發(fā)風險對軟件進行分級管理關鍵/重要/一般A/B/C/D/E根據(jù)軟件失效的級別，識別關鍵功能，進行標識和追蹤管理失效—分級舉例1失效類別對服務質(zhì)量的影響A基本服務中斷B基本服務質(zhì)量降低C使用不方便，需要立即修改D影響較小，可延期修改失效—分級舉例2失效類別可能造成的經(jīng)濟損失(元)1>100000210000~10000031000~100004<1000失效—分級舉例3失效類別對操作的影響1用戶不能進行一項或多項關鍵操作2用戶不能進行一項或多項重要操作3用戶不能進行一項或多項操作，但是有補救辦法4一項或多項操作中的小缺陷失效—FRACASFRACAS是“FailureReportAnalysisandCorrectiveActionSystem”的縮寫，是“失效報告、分析及糾正措施系統(tǒng)”FRACAS通常也稱為“失效信息閉環(huán)管理系統(tǒng)”是跟蹤系統(tǒng)可靠性的方法是一組過程、規(guī)則和軟件工具在產(chǎn)品生存期后端開始使用失效—FRACAS的角色工作系統(tǒng)視角組織機構(gòu)(各方代表)人員職責分工工作的流程資源保障失效—FRACAS的角色信息系統(tǒng)視角與可靠性信息系統(tǒng)的關系信息準確與完整性及時性、正確性可追蹤性失效—FRACAS的作用及時有效地處理當前故障過去發(fā)生的故障不再重現(xiàn)建立企業(yè)的可靠性經(jīng)驗失效—FRACAS的目標利用“信息反饋，閉環(huán)控制”的原理，通過一套規(guī)范化的程序，使發(fā)生的產(chǎn)品故障能得到及時的報告和糾正，從而實現(xiàn)產(chǎn)品可靠性的增長，達到對產(chǎn)品可靠性和維修性的預期要求，防止故障再現(xiàn)通過FRACAS建立企業(yè)問題/故障信息數(shù)據(jù)庫，為軟件可靠性設計和分析以及關于維修策略、保障策略和備件策略的制定提供數(shù)據(jù)支持失效—FRACAS流程記錄事件分析失效模式開展糾正活動檢驗糾正活動識別失效趨勢確定單個部件對失效產(chǎn)生的作用失效—FRACAS實施故障記錄故障報告故障分析糾正措施閉環(huán)管理售后服務數(shù)據(jù)庫FRACAS數(shù)據(jù)庫外場故障廠內(nèi)故障失效—FRACAS進化知識庫故障故障報告根源分析糾正措施閉環(huán)驗證可靠性分析產(chǎn)品改進①②③④⑤⑥⑦失效—FRACAS文檔故障記錄表故障報告表故障分析表糾正措施表閉環(huán)管理表失效—利用FRACASFRACAS數(shù)據(jù)庫FMEA設計準則可靠性評估可靠性增長計劃故障模式手冊關鍵件判定和故障歷史使用、故障、維修信息故障統(tǒng)計分析缺陷—軟件的缺陷屬性無法提供無缺陷的軟件，缺陷已成為軟件的固有屬性和特征各種研究報告表明，每寫1000行代碼會產(chǎn)生30到85個缺陷大多數(shù)缺陷可通過測試捕獲在大量的已完成測試的軟件中，每1000行代碼仍存在0.5~3缺陷軟件缺陷有可能會給系統(tǒng)質(zhì)量尤其是可靠性帶來重大影響缺陷—求和的例子#include<stdio.h>intsum(i1,i2,i3){inti1;inti2;inti3;return(i1+i2+i3);}intmain(){printf(“Sumis%d\n”,sum(1,2,3));return(0)}缺陷—排序的例子#include<iostream>intmain(){inta,b,c;a=7;b=5;c=3;if(a>b>c)std::cout<<“a,b,careinorder\n”;elsestd::cout<<“a,b,caremixedup\n”;return(0);}缺陷—?列舉你所見、所聞的缺陷缺陷—缺陷的影響缺陷可能導致失效同樣的缺陷在不同的場景下導致的失效狀態(tài)會有很大的差別，可能只是使用不便，也有可能帶來災難缺陷的復雜度與失效的嚴重性之間的關系是未知的最大限度的減少缺陷,可以提高軟件的可靠性缺陷—基本特性變異的預期常常產(chǎn)生缺陷在實際項目中完全消除缺陷是不可能的，基于軟件開發(fā)經(jīng)濟學的考慮，減少缺陷是現(xiàn)實的缺陷有可能非常簡單，也有可能極其復雜程序設計語言與缺陷的復雜性和數(shù)量的關系是未知的不論人的能力和背景，都可能產(chǎn)生缺陷認識—缺陷的解決策略避錯(Defectavoidance)第一次就做正確排錯(defectremoval)早發(fā)現(xiàn),早實施容錯(Defecttolerance)有缺陷,也能正確的完成任務恢復選用最佳恢復策略,失效后繼續(xù)工作缺陷—缺陷管理的目的強制按照統(tǒng)一的流程處理缺陷對缺陷實現(xiàn)全生命周期的閉環(huán)管理依據(jù)缺陷的相對和絕對重要性來修復問題有利于缺陷信息的清楚傳達透明的缺陷修復進展獲得更多有價值的信息為技術支持和市場部門提供支持缺陷—缺陷管理的目標確保應該修正的問題和缺陷都得到修正其它均是次要問題缺陷—避免濫用個人業(yè)績監(jiān)控開發(fā)與測試人員的彈藥庫缺陷—缺陷管理的任務需要了解缺陷的人員一看到報告就應該明白不會因為被相關人員遺忘而得不到修正避免個別程序員的“即興發(fā)揮”增加交流缺陷—缺陷生命周期審閱打開分配測試關閉拒絕重新打開暫緩缺陷—分類法基于來源分類基于嚴重性或危害度分類基于修復優(yōu)先級分類缺陷—基于來源分類功能系統(tǒng)過程數(shù)據(jù)雜類BorisBeizer缺陷—功能類規(guī)格功能測試缺陷—系統(tǒng)類內(nèi)部接口硬件設備操作系統(tǒng)軟件結(jié)構(gòu)資源管理缺陷—過程類計算初始化控制或序列靜態(tài)邏輯其它缺陷—數(shù)據(jù)類類型結(jié)構(gòu)初始化其它缺陷—雜類代碼文檔標準其它重復NAP(不是一個問題)缺陷—嚴重性等級(1)1不能完全滿足系統(tǒng)要求，基本功能未完全實現(xiàn)或危及人員安全的缺陷。2不利于完全滿足系統(tǒng)要求或基本功能實現(xiàn)，并且不存在變通的解決辦法的缺陷。3不利于完全滿足系統(tǒng)要求或基本功能的實現(xiàn)，但卻存在合理的變通解決辦法的缺陷。4不影響完全滿足系統(tǒng)要求或基本功能的實現(xiàn)，但有不便于操作的缺陷。5其它缺陷缺陷—嚴重性等級(2)輕微輸出拼寫錯誤，遺漏一些空格普通輸出可能被誤解或者多余反感用戶需要一些竅門使用戶工作煩擾拒絕處理合法事務嚴重事務及其處理無固定軌跡非常嚴重缺陷導致系統(tǒng)進行錯誤的處理極端嚴重缺陷頻繁且隨意的導致一些用戶或一些事務受限不可容忍長期不可恢復的數(shù)據(jù)庫訛誤，必需重啟系統(tǒng)災難系統(tǒng)失敗傳染使其他系統(tǒng)變壞，導致文件丟失缺陷—危害度危害度輕微普通反感嚴重非常嚴重災難傳染缺陷類型缺陷—修復優(yōu)先級立即解決高優(yōu)先級正常排隊低優(yōu)先級缺陷—分工測試人員報告軟件缺陷分析人員分析缺陷報告開發(fā)人員修復缺陷，并將修復集成到新的版本中測試人員檢查新的版本缺陷—測試人員的工作負責報告缺陷監(jiān)控所報告的缺陷的解決缺陷—建立管理系統(tǒng)使用商業(yè)缺陷跟蹤與管理系統(tǒng)自行開發(fā)專用缺陷跟蹤與管理系統(tǒng)創(chuàng)建缺陷數(shù)據(jù)庫缺陷—周報每周新發(fā)現(xiàn)問題總結(jié)按功能區(qū)域和嚴重性分類每周狀態(tài)報告包括對缺陷數(shù)量意外上升的解釋缺陷—測試周期完成報告當所有重要問題已經(jīng)解決，結(jié)束這個測試周期;報告給出總共報告了多少缺陷，修正了多少，多少被延期。缺陷—報告的作用報告新的缺陷描述缺陷相關的現(xiàn)有信息發(fā)現(xiàn)缺陷是測試的目的,缺陷報告是測試者主要的工作成果程序員工作在時間和競爭的壓力下,缺陷報告是測試者向程序員推銷應該花時間和精力去修復一個缺陷的手段缺陷—隔離運行測試并發(fā)現(xiàn)了失敗,所看到的是征兆,不是潛在的缺陷繼續(xù)做工作，希望證實這個缺陷:更嚴格更一般缺陷—報告編寫指南闡述如何重現(xiàn)問題分析錯誤使得能用最少的步數(shù)描述它包括所有的步驟讓報告易于理解用中立語言保持簡單:每個報告一個缺陷如果測試文件是重現(xiàn)問題的基礎,參照并附上缺陷—報告的要素1問題報告單號9能否重現(xiàn)17分配2報告人10嚴重性18狀態(tài)3報告日期11優(yōu)先級19解決4被測對象名稱12客戶影響20解決版本5發(fā)布號13問題摘要21解決人6版本標識14關鍵字22更改記錄7配置15問題描述23注釋8報告類別16修復建議缺陷—寫好缺陷報告好的報告從好的測試開始立即寫報告準確、完整而簡練發(fā)現(xiàn)了什么，不是做了什么缺陷—分類管理舉例正交缺陷分類(ODC，OrthogonalDefectClassification)由IBM在1990s開發(fā)定量管理缺陷的方法DefectTypeTrigger缺陷—ODCv5.11OpenerCloserDefect類型(Type)來源(Source)影響(Impact)觸發(fā)(Trigger)活動(Activity)目標(Target)界定(Qualifier)年齡(Age)缺陷—活動(Activity)設計評審(DesignReview)代碼審查(CodeInspection)單元測試(UnitTest)功能測試(FunctionTest)系統(tǒng)測試(SystemTest)缺陷—觸發(fā)(Triggers)設計評審/代碼審查類觸發(fā)單元測試類觸發(fā)功能測試類觸發(fā)系統(tǒng)測試類觸發(fā)缺陷—觸發(fā)(Triggers)設計評審/代碼審查類觸發(fā)設計一致性(DesignConformance)邏輯/流程(Logic/Flow)向后兼容(BackwardCompatibility)內(nèi)在文檔(InternalDocument)橫向兼容(LateralCompatibility)并發(fā)(Concurrency)語言依賴(LanguageDependency)副作用(SideEffects)特