軟件測評技術

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

Arewebuildingtheproductright?Validation:

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