信息工程導論-第七章

第七講信息產(chǎn)品質(zhì)量控制軟件質(zhì)量定義明確表示是否符合功能和性能要求，明確地記載開發(fā)標準和所有專業(yè)開發(fā)軟件的期望的隱性特點質(zhì)量控制是審查產(chǎn)品相關的各個方面質(zhì)量的過程軟件質(zhì)量標準經(jīng)過數(shù)十年的發(fā)展，軟件行業(yè)形成的標準分工細，體系繁多。本節(jié)主要從標準的層次來說明軟件質(zhì)量標準的情況。根據(jù)軟件工程標準制定機構和標準適用的范圍，將軟件質(zhì)量標準分為5個級別，即國際標準、國家標準、行業(yè)標準、企業(yè)標準和項目規(guī)范。很多標準的原始狀態(tài)可能是項目標準或企業(yè)標準，但隨著行業(yè)發(fā)展與推進，它的權威性可能促使它發(fā)展成為行業(yè)、國家或國際標準，因此這里所說的層次具有一定的相對性。軟件質(zhì)量標準—國際標準由國際機構指定和公布供各國參考的標準稱為國際標準。國際標準化組織（InternationalStandardsOrganization，ISO）具有廣泛的代表性和權威性，它所公布的標準也具有國際影響力。20世紀60年代初，國際標準化組織建立了“計算機與信息處理技術委員會”，專門負責與計算機有關的標準工作。它所公布的標準帶有ISO字樣，如ISO10012:1995質(zhì)量手冊編寫指南。軟件質(zhì)量標準—國家標準由政府或國家級的機構制定或批準，適用于本國范圍的標準，稱為國家標準。如：GB（GuoBiao）中華人民共和國國家技術監(jiān)督局是中國的最高標準化機構，它所公布實施的標準簡稱為“國標”。ANSI（AmericanNationalStandardsInstitute）美國國家標準協(xié)會。是美國一些民間標準化組織的領導機構，具有一定的權威性。FIPS（FederalInformationProcessingStandards）美國商務部國家標準局聯(lián)邦信息處理標準。它所公布的標準均冠有FIPS字樣。如，1987年發(fā)表的FIPSPUB132—87Guidelineforvalidationandverificationplanofcomputersoftware（軟件確認與驗證計劃指南）。BS（BritishStandard）英國國家標準。DIN（DeutschesInstitutforNormung）德國標準協(xié)會。JIS（JapaneseIndustrialStandard）日本工業(yè)標準行業(yè)標準。軟件質(zhì)量標準—行業(yè)標準行業(yè)標準是由一些行業(yè)機構、學術團體或國防機構制定，并適用于某個業(yè)務領域的標準。IEEE軟件工程標準為滿足軟件工程化的迫切需求，1976年，美國電氣和電子工程師會（IEEE）標準化部成立了一個軟件工程組，負責起草軟件工程標準另外，我國的一些部門（如信息產(chǎn)業(yè)部）也開展了軟件標準化工作，制定和公布了一些適合本部門工作需要的規(guī)范。這些規(guī)范的制定參考了國際標準和國家標準。這些標準的制定對各自行業(yè)的軟件工程起到了強有力的推動作用。軟件質(zhì)量標準—軍工標準中華人民共和國國家軍用標準（GJB）。是由我國國防科學技術工業(yè)委員會批準，適合國防部門和軍隊使用的標準。例如，1988年發(fā)布實施的GJB473-88軍用軟件開發(fā)規(guī)范。美電氣和電子工程師學會（InstituteOfElectricalandElectronicsEngineers，IEEE），該學會成立了軟件標準技術委員會（SESS），開展軟件標準化活動。美國國防部標準（DepartmentofDefense-Standards，DOD-STD）。美國軍用標準（Military-Standards，MIL-S）。IEEE軟件工程標準：顧客標準流程標準產(chǎn)品標準資源與技術標準軟件質(zhì)量標準—IEEE標準IEEE730:2001結構與內(nèi)容：目的參考文檔管理文檔標準、實踐、約定和度量軟件評審IEEE/EIAStd12207——軟件生命周期過程主要過程（PrimaryProcess）包括5個過程，這些過程供各主要當事方（如需方、供方、開發(fā)者、運行者和維護者）在參與或完成軟件產(chǎn)品開發(fā)、運行或維護時使用，它們是：獲取過程：需方獲取系統(tǒng)，軟件產(chǎn)品或軟件服務的活動。供應過程：供方向需方提供系統(tǒng)、軟件產(chǎn)品或軟件服務的活動。開發(fā)過程：開發(fā)者定義并開發(fā)軟件產(chǎn)品的活動。運行過程：運行者在規(guī)定的環(huán)境中為其用戶提供計算機系統(tǒng)服務的活動。維護過程：軟件產(chǎn)品后期維護更新。軟件質(zhì)量標準—IEEE標準IEEE/EIAStd12207——軟件生命周期過程支持過程（SupportingProcess）包括8個過程，其每個過程均有明確的目的支持其它過程，幫助軟件項目獲得成功及良好的產(chǎn)品質(zhì)量。它們是：文檔編制過程：記錄生存期過程中產(chǎn)生信息所需的活動。配置管理過程：實施配置管理活動。質(zhì)量保證過程：為確保軟件產(chǎn)品和軟件過程符合規(guī)定的需求并能堅持既定計劃所需的活動。聯(lián)合評審、審核、驗證與確認可作為質(zhì)量保證技術使用。驗證過程：為驗證最終產(chǎn)品滿足預期使用要求的活動。確認過程：為確保最終產(chǎn)品滿足預期使用要求的活動。聯(lián)合評審過程：評審方與被評審方共同對某一活動的狀態(tài)和產(chǎn)品進行評審的活動。審核過程：審核項目是否按要求、計劃、合同完成的活動。問題解決過程：分析和解決在開發(fā)、運行、維護或其他過程中出現(xiàn)的問題（不論其性質(zhì)和來源如何）的活動。軟件質(zhì)量標準—IEEE標準軟件質(zhì)量標準—IEEE標準軟件生存期過程主要過程支持過程組織過程獲取過程供應過程開發(fā)過程運行過程配置管理過程質(zhì)量保證過程文檔編制過程維護過程驗證過程聯(lián)合評審過程確認過程審核過程問題解決過程管理過程基礎設施過程改進過程培訓過程軟件生命周期過程示意圖IEEEStd1012——驗證與確認驗證驗證是用來評價某一系統(tǒng)或某一組件的過程，來判斷給定階段的產(chǎn)品是否滿足該階段開始時施加的條件。即說明驗證活動在一定的程度上是一種普通的測試活動，要求驗證每個開發(fā)階段是否符合先前階段定義的需求。經(jīng)過合理組織的項目應該包含驗證和確認計劃（VerificationandValidationPlan，VVP）。在IEEE1012-1987，《IEEE軟件驗證和確認標準》（IEEEStandardforSoftwareVerificationandValidation）和IEEE1059-1993，，《IEEE軟件驗證和確認指南》（IEEESoftwareGuideforVerificationandValidationPlan）中，IEEE為建立一個VVP提供了優(yōu)秀的指導。確認確認是開發(fā)過程中間或結束時對某一系統(tǒng)或某一組件進行評價的過程，以確認它是否滿足規(guī)定的需求。需要確認已經(jīng)實現(xiàn)的組件實際上按照規(guī)格說明書進行的工作。通常，用測試來完成這項任務，確認計劃是必須的。軟件質(zhì)量標準—IEEE標準軟件質(zhì)量標準—IEEE標準類別目的參與人備注管理評審監(jiān)控進展是否與需求相符，判定計劃和進度表的狀態(tài)及需求；在系統(tǒng)中分配或評價為達到目的相符所采用的管理途徑的有效性；它們有對本系統(tǒng)負有直接責任的管理人員實行決策制定者、評審領導人、記錄員、管理人員、其他小組成員（可選）、技術人員、客戶或用戶代表（可選）技術評審評價軟件產(chǎn)品，由認定的小組人員決定對預期使用的適宜性，并標識規(guī)格說明和標準的偏差。決策制定者、評審領導人、記錄員、管理人員、其他小組成員（可選）、技術人員、客戶或用戶代表（可選）審查查出并標識軟件產(chǎn)品的反常，驗證軟件產(chǎn)品是否滿足規(guī)格說明，是否滿足指定的指令屬性，是否與用到的規(guī)章、標準、指南、計劃和規(guī)程相符，標識與標準和規(guī)格說明的偏差，收集軟件工程數(shù)據(jù)。用收集到的軟件工程數(shù)據(jù)改善審查過程本身，以及相應的支持文檔審查領導人、記錄員、讀者、作者、審查員評審的所有參與者都是審查員，管理地位比審查小組所有成員都高的人不應參與走查找出反常、改善產(chǎn)品、考慮替換物的實現(xiàn)、評價與標準和規(guī)格說明的相符性走查領導人、記錄員、作者、小組成員審計就用到的規(guī)章、標準、指南、計劃和規(guī)程對軟件產(chǎn)品和過程獨立地提供評價審查領導人、記錄員、作者、項目發(fā)起人、審計組織審計員應將觀察到的不相符處和相符處記入檔案IEEEStd1028——評審目錄軟件測試是在軟件投入運行前對軟件需求分析、軟件設計規(guī)格說明和軟件編碼進行查錯和糾錯。查錯的活動稱為測試，糾錯的活動稱為調(diào)試。測試又分為靜態(tài)測試和動態(tài)測試。靜態(tài)測試，又稱評審，是對軟件進行的一種分析和檢查活動。靜態(tài)測試不需要執(zhí)行程序，因而在代碼產(chǎn)生之前便可對各種文檔進行測試。動態(tài)測試是通過運行軟件來檢驗其動態(tài)行為和運行結果的正確性。動態(tài)測試是在編碼之后進行。

軟件測試的概念軟件測試的目標測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程一個好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤一次成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試E.W.Dijkstra則認為：“測試能證明錯誤的存在，但不能證明錯誤不存在”。軟件測試目的基于不同的立場，存在著兩種完全不同的測試目的。從用戶的角度出發(fā)，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可接受該產(chǎn)品。從軟件開發(fā)者的角度出發(fā)，則希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗證該軟件已正確地實現(xiàn)了用戶的要求，確立人們對軟件質(zhì)量的信心。測試的特點軟件件測試的開銷大

按照Boehm的統(tǒng)計，軟件測試的開銷大約占總成本的30%-50%。例：APPOLLO登月計劃，80%的經(jīng)費用于軟件測試。Exchange2000和Windows2000開發(fā)人員結構Exchange2000Windows2000項目經(jīng)理25人約250人開發(fā)人員140人約1700人測試人員350人約3200人不能進行“窮舉”測試只有將所有可能的情況都測試到，才有可能檢查出所有的錯誤。但這是不可能的。比如：例：程序P有兩個整型輸入量X、Y，輸出量為Z，在32位機上運行。所有的測試數(shù)據(jù)組（Xi，Yi）的數(shù)目為：1毫秒執(zhí)行1次，共需5億年。=323226422軟件測試難度大

既然不能進行“窮舉”測試，又要查出盡可能多的錯誤，軟件測試工作的難度大。只有選擇— “高效的測試用例”測試的特點軟件測試的基本原則1）測試應“盡早地和不斷地進行”。測試計劃可以在需求分析完成后就開始進行。詳細的測試用例定義可以在各種設計結果確定后開始進行。測試計劃應包括：測試的目的、所測軟件的功能、輸入和輸出、測試方法、測試用例、測試進度、資源要求、測試資料、測試工具等。2）盡量不由程序設計者測試自己的程序。軟件測試的基本原則3）應保證測試用例的完整性和有效性。完整的測試用例應由輸入數(shù)據(jù)和相應的預期結果組成。既有合理輸入數(shù)據(jù)，也有不合理的輸入數(shù)據(jù)。4）注意錯誤的群集現(xiàn)象和應用Pareto原則：經(jīng)驗表明，測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目或檢錯率成正比。因而應當對錯誤群集的程序段進行更多的測試Pareto原則表明80%的錯誤來源于20%的程序模塊5）長期保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告，能為后期的維護提供方便。測試流程軟件測試基本步驟模塊測試子系統(tǒng)測試系統(tǒng)測試平行運行目的：保證每個模塊作為一個單元能夠正確運行，又稱為單元測試集成測試、組裝測試、聯(lián)合測試；重點在于測試模塊之間的接口；將經(jīng)過測試的子系統(tǒng)裝配成一個完整的系統(tǒng)來測試；發(fā)現(xiàn)設計和編碼的錯誤，驗證系統(tǒng)是否滿足需求說明所定義的功能及其動態(tài)特性；也稱為集成測試。同時運行新舊兩個系統(tǒng)，并且對處理的結果進行比較，以確定新系統(tǒng)是否滿足相關性能指標。驗收測試有用戶參加的系統(tǒng)測試；驗證是否滿足用戶的需要。單元測試（unittesting），是指對軟件中的最小可測試單元進行檢查和驗證。對于單元測試中單元的含義，一般來說，要根據(jù)實際情況去判定其具體含義C語言中單元指一個函數(shù)Java里單元指一個類圖形化的軟件中可以指一個窗口或一個菜單等軟件測試—單元測試單元測試優(yōu)點它是一種驗證行為它是一種設計行為它是一種編寫文檔的行為它具有回歸性為什么要使用單元測試我們編寫代碼時，代碼通過編譯，只是說明了它的語法正確；我們卻無法保證它的語義也一定正確，但單元測試會為代碼語義正確做保證。單元測試工具C/C++CppUnitC++TestVisualUnitgtest

JavaJunitJUnit-addonsSpring測試框架DJUnitEasyMock集成測試集成測試，也叫組裝測試或聯(lián)合測試。在單元測試的基礎上，將所有模塊按照設計要求（如根據(jù)結構圖〕組裝成為子系統(tǒng)或系統(tǒng)，進行集成測試。集成測試的目標是確保各單元組合在一起后能夠按既定意圖協(xié)作運行，并確保增量的行為正確集成測試的必要性還在于一些模塊雖然能夠單獨地工作，但并不能保證連接起來也能正常工作集成測試的意義還在于它能間接地驗證概要設計是否具有可行性軟件測試—集成測試完成標準怎樣判定集成測試過程完成了，可按以下幾個方面檢查：1、成功地執(zhí)行了測試計劃中規(guī)定的所有集成測試2、修正了所發(fā)現(xiàn)的錯誤3、測試結果通過了專門小組的評審集成測試方法集成測試應該考慮以下問題：1、在把各個模塊連接起來的時候，穿越模塊接口的數(shù)據(jù)是否會丟失2、各個子功能組合起來，能否達到預期要求的父功能3、一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響4、全局數(shù)據(jù)結構是否有問題5、單個模塊的誤差積累起來，是否會放大，從而達到集成測試可接受的程度軟件測試—集成測試驗收測試系統(tǒng)開發(fā)生命周期方法論的一個階段，這時相關的用戶和／或獨立測試人員根據(jù)測試計劃和結果對系統(tǒng)進行測試和接收。它讓系統(tǒng)用戶決定是否接收系統(tǒng)它是一項確定產(chǎn)品是否能夠滿足合同或用戶所規(guī)定需求的測試軟件測試—驗收測試驗收測試過程1.軟件需求分析2.編制《驗收測試計劃》和《項目驗收準則》3.測試設計和測試用例設計4.測試環(huán)境搭建5.測試實施：測試并記錄測試結果。6.測試結果分析7.測試報告驗收測試的常用策略實施驗收測試的常用策略有三種，它們分別是：正式驗收非正式驗收或Alpha測試Beta測試驗收測試相關標準驗收測試標準配置復審αβ測試α測試在軟件交付使用之后，用戶將如何實際使用程序，對于開發(fā)者來說是無法預測的。α測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進行的測試。α測試的目的是評價軟件產(chǎn)品的功能、局域化、可使用性、可靠性、性能和支持，尤其注重產(chǎn)品的界面和特色。α測試可以從軟件產(chǎn)品編碼結束之時開始，或在模塊（子系統(tǒng)）測試完成之后開始，也可以在確認測試過程中產(chǎn)品達到一定的穩(wěn)定和可靠程度之后再開始。β測試β測試是由軟件的多個用戶在實際使用環(huán)境下進行的測試。這些用戶返回有關錯誤信息給開發(fā)者。測試時，開發(fā)者通常不在測試現(xiàn)場。因而，β測試是在開發(fā)者無法控制的環(huán)境下進行的軟件現(xiàn)場應用。在β測試中，由用戶記下遇到的所有問題，包括真實的以及主觀認定的，定期向開發(fā)者報告。β測試主要衡量產(chǎn)品的功能、局域化、可使用性、可靠性、性能和支持。著重于產(chǎn)品的支持性，包括文檔、客戶培訓和支持產(chǎn)品生產(chǎn)能力。只有當α測試達到一定的可靠程度時，才能開始β測試。它處在整個測試的最后階段。同時，產(chǎn)品的所有手冊文本也應該在此階段完全定稿。目錄軟件質(zhì)量控制方法--CMMCMM軟件質(zhì)量控制方法--RUPRUP（Rati