軟件測試理論知識總結(jié)

PAGE36軟件測試的定義和目的什么是軟件測試IEEE定義為：使用人工和自動手段來運行或測試某個系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或是弄清預期結(jié)果與實際結(jié)果之間的差別。G.J.Myers認為：1）程序測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程；2）好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；3）成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤測試。（注：1）軟件測試是一個過程，包含若干活動，運行軟件進行測試只是活動之一；2）運行軟件測試可以人工方式也可以借助于工具，3）進行軟件測試可以運行軟件也可以不運行軟件；4）軟件測試的目的不僅僅是為了發(fā)現(xiàn)錯誤。）軟件測試的目的人們對軟件測試的目的的認識也經(jīng)歷了一個過程：20世紀60年代20世紀70年代中期20世紀90年代證明 檢測預防表明軟件能夠工作發(fā)現(xiàn)錯誤管理質(zhì)量軟件生命周期計劃需求分析設計編碼測試運行和維護軟件研發(fā)組織和流程SQA配置管理組軟件測試組軟件開發(fā)組配置經(jīng)理開發(fā)經(jīng)理測試經(jīng)理項目經(jīng)理常見項目組架構(gòu)SQA配置管理組軟件測試組軟件開發(fā)組配置經(jīng)理開發(fā)經(jīng)理測試經(jīng)理項目經(jīng)理 基本軟件研發(fā)流程瀑布模型螺旋模型RUP（RationalUnitedPress）模型所有工作流在各個階段都有體現(xiàn)。（IBM收購）IPD（IntegredProductDesign）模型從整個產(chǎn)品角度出發(fā)，不僅僅針對研發(fā)。（IBM）軟件中引入缺陷的原因軟件缺陷：既指靜態(tài)存在于軟件工作產(chǎn)品（文檔，代碼）中的錯誤，也指軟件運行時由于這些錯誤被激發(fā)引起的和軟件產(chǎn)品預期屬性的偏離現(xiàn)象。Bug：代碼中的缺陷。有時也被廣泛指因軟件產(chǎn)品內(nèi)部的缺陷引起的軟件產(chǎn)品最終運行時和預期屬性的偏離。（注：軟件錯誤、軟件缺陷、Bug在實際工作中可以認為是一樣。）常見的引入缺陷的原因開發(fā)過程缺乏有效的溝通，或者沒有進行溝通軟件復雜度越來越高編程中產(chǎn)生的錯誤需求不斷變更項目進度的壓力不重視開發(fā)文檔軟件開發(fā)工具本身隱藏的問題。。。。。。。。。。。。。。。。。。。。。。缺陷類型遺漏：規(guī)定的或者預期的需求未體現(xiàn)在產(chǎn)品中（可能未將規(guī)格說明全面實現(xiàn)，也可能需求分析階段就遺漏了需求）錯誤：未將規(guī)格說明正確實現(xiàn)（可能設計錯誤、也可能編碼錯誤）額外的實現(xiàn)：規(guī)格說明并未規(guī)定的需求被納入了產(chǎn)品，得到實現(xiàn)。（也可以用下面五種類型表示：產(chǎn)品未達到產(chǎn)品說明書中要求實現(xiàn)的功能產(chǎn)品出現(xiàn)了產(chǎn)品說明書中沒有的功能產(chǎn)品沒有實現(xiàn)產(chǎn)品說明書中雖未指明但要求實現(xiàn)的功能產(chǎn)品出現(xiàn)了說明書中明確規(guī)定不出現(xiàn)的功能測試人員或用戶認為產(chǎn)品不應使用）測試過程測試階段劃分單元測試（UnitTesting）針對軟件基本組成單元（軟件設計的最小單位）來進行正確性檢驗的測試工作。（檢測軟件模塊對《詳細設計說明書（LLD）的符合度》）。集成測試（IntegrationTesting）在單元測試的基礎上，將所有模塊按照概要設計組裝成為子系統(tǒng)或系統(tǒng)，驗證組裝后功能以及模塊間接口是否正確的測試工作。（檢測軟件模塊對《概要設計說明書（HLD）的符合度》）系統(tǒng)測試（SystemTesting）將已經(jīng)集成好的軟件系統(tǒng)，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設、某些支持軟件、數(shù)據(jù)和人員等其他元素結(jié)合在一起，在實際運行（使用）環(huán)境下，對計算機系統(tǒng)進行一系列的測試工作。（通過與《需求規(guī)格說明書（SRS）》作比較，發(fā)現(xiàn)軟件與系統(tǒng)需求定義不符合或之矛盾的地方）單元、集成、系統(tǒng)測試的比較測試方法不同單元測試屬于白盒測試范疇集成測試屬于灰盒測試范疇系統(tǒng)測試屬于黑盒測試范疇考察范圍不同單元測試主要測試單元內(nèi)部的數(shù)據(jù)結(jié)構(gòu)、邏輯結(jié)構(gòu)、異常處理等集成測試主要測試模塊之間的接口和接口數(shù)據(jù)傳遞關系，以及模塊組合后的整體功能系統(tǒng)測試主要測試整個系統(tǒng)相對于需求的符合度評估基準不同單元測試主要是邏輯覆蓋率集成測試主要是接口覆蓋率系統(tǒng)測試主要是測試用例對需求規(guī)格的覆蓋率回歸測試（RegressionTesting）目的：驗證缺陷得到了正確的修復，同時對系統(tǒng)的變更沒有影響以前的功能。（注：回歸測試可以發(fā)生在任何一個階段）回歸測試策略完全重復測試重新執(zhí)行所有在前期測試階段建立的測試用例，來確認問題修改的正確性和修改的擴散局部影響性。選擇性重復測試即有選擇地重新執(zhí)行部分在前期測試階段建立的測試用例，來測試被修改的程序覆蓋修改法即針對被修改的部分，選取或重新構(gòu)造測試用例驗證沒有錯誤再次發(fā)生的用例選擇方法周邊影響法該方法不但包含覆蓋修改法確定的測試用例，還需要分析修改的擴散影響，對那些受到修改間接影響的部分選擇測試用例驗證它沒有受到不良影響，該方法比覆蓋修改法更充分一點。指標達成法這是一種類似于單元測試的方法，在重新執(zhí)行測試前，先確定一個要達成的指標，如修改的部分代碼100%的覆蓋、與修改有關的接口60%的覆蓋等，基于這種要求選擇一個最小的測試用例集合?；貧w測試流程（適用于單元測試，集成測試，系統(tǒng)測試）在測試策略制定階段，制定回歸測試策略確定需要回歸測試的版本回歸測試版本發(fā)布，按回歸測試策略執(zhí)行回歸測試回歸測試通過，關閉缺陷跟蹤單（問題單）回歸測試不通過，缺陷跟蹤單返回開發(fā)人員，開發(fā)人員重新修改問題，再次提交測試人員回歸測試（注：回歸測試比較適合使用自動化工具）其他測試階段驗收測試驗收測試是以用戶為主的測試，驗收組應該由項目組成員，用戶代表等組成在通過內(nèi)部系統(tǒng)測試及軟件配置審查后，就可以開始驗收測試驗收測試原則上在用戶所在地進行，但經(jīng)用戶同意也可以在公司內(nèi)模擬用戶環(huán)境驗收測試根據(jù)合同、《需求規(guī)格說明書》或《驗收測試計劃》對產(chǎn)品進行驗證結(jié)果兩種（接受與不接受）Alpha測試（屬于驗收測試）由用戶在開發(fā)環(huán)境下進行的測試，也可以是開發(fā)機構(gòu)內(nèi)部的用戶在模擬實際操作環(huán)境下進行的測試。目的主要是評價軟件產(chǎn)品的FLURPS（即功能、局域化、可用性、可靠性、性能和技術支持等）Beta測試（屬于驗收測試）由軟件的多個用戶在一個或多個用戶的實際環(huán)境下進行測試Alpha測試和Beta測試的區(qū)別Alpha測試過程可控，但是參與人數(shù)有限；Beta測試參與人數(shù)巨大，但是過程不可控。測試過程模型測試過程階段劃分測試計劃階段：測試計劃測試設計階段：測試方案測試實現(xiàn)階段：測試用例、測試規(guī)程測試執(zhí)行階段：測試報告主要測試文檔測試計劃：指明測試范圍、方法、資源、以及相應測試活動的時間進度安排表的文檔。測試方案：指明為完成軟件或軟件集成特性的測試而進行的設計測試方法的細節(jié)文檔。測試用例：指明為完成一個測試項的測試輸入、預期結(jié)果、測試執(zhí)行條件等因素的文檔。測試規(guī)程：指明執(zhí)行測試時測試活動序列的文檔。（后執(zhí)行用例的輸入是先執(zhí)行用例的輸出）測試報告：指明執(zhí)行測試結(jié)果的文檔。（注：1）將工作過程表現(xiàn)出來2）表明個人對測試對象的態(tài)度）測試日報：每天測試執(zhí)行情況的記錄和總結(jié)。常見的測試過程模型瀑布模型缺陷：測試介入太晚工作效率低成本巨大H模型測試就緒點測試就緒點測試流程測試流程測試準備測試執(zhí)行其他流程（如設計流程）測試準備活動，包括測試需求分析、測試計劃、測試設計、測試編碼、測試驗證另一類是測試執(zhí)行活動，包括測試運行、測試報告、測試結(jié)果分析等。優(yōu)點：測試與其他流程并發(fā)的進行測試準備和測試執(zhí)行分開V&V模型需求分析概要設計需求分析概要設計詳細設計集成測試計劃、設計、實現(xiàn)系統(tǒng)測試計劃、設計、實現(xiàn)編碼代碼走查單元測試計劃、設計、實現(xiàn)執(zhí)行系統(tǒng)測試執(zhí)行集成測試執(zhí)行單元測試優(yōu)點：測試與其他流程并發(fā)的進行測試準備和測試執(zhí)行分開測試過程子階段與開發(fā)過程子階段一一對應。V&V的含義驗證（Verification）和確認（Validation）驗證：（“Arewebuildingtheproductright?”）驗證是保證軟件正確地實現(xiàn)特定功能的一系列活動驗證是檢測每一階段形成的工作產(chǎn)品是否與前一階段定義的規(guī)格相一致確認：（“Arewebuildingtherightproduct?”）確認是指保證所生產(chǎn)的軟件可追溯到用戶需求的一系列活動確認是檢測每一階段的工作產(chǎn)品是否與最初定義的軟件需求規(guī)格相一致測試過程規(guī)范CMM關于過程的要素角色（Roles）：人入口準則（EntryCriteria）：執(zhí)行活動所必須滿足的條件輸入（Inputs）：完成某活動所需要加工或參考的資料、原材料活動（Activities）：流程由一系列有相互關系的活動組成輸出（Outputs）：完成某活動后所提交的工作產(chǎn)品出口準則（ExitCriteria）：完成或退出某活動所必須滿足的條件評審和審計（ReviewsandAudits）可管理和受控的工作產(chǎn)品（WorkProductsManagedandControlled）測量(Measurements)：客觀指標（一組數(shù)據(jù)）書面規(guī)程（DocumentedProcedures）培訓（Training）：技術支持工具（Tools）：輔助說明職責：權責定義模板：標準格式檢查表（Checklist）：要點列表軟件質(zhì)量軟件質(zhì)量的定義質(zhì)量：實體基于這些特性滿足需求的程度。（一個實體的所以特性，基于這些特性可以滿足明顯的和隱含的需求）軟件質(zhì)量的三個層次：（需求的分層導致質(zhì)量也分層）符合需求規(guī)格：符合開發(fā)者明確定義的目標，即產(chǎn)品是不是在做讓它做的事情。目標是開發(fā)者定義的，并且是可以驗證的。符合用戶顯示需求（基于SRS）：符合用戶所明確說明的目標。目標是客戶所定義的，符合目標即判斷我們是不是在做我們需要做的事。符合用戶的實際需求：實際需求包括用戶明確說明的和隱含的需求。影響軟件質(zhì)量的因素：（鐵三角）流程好處：將不可見的工作過程變得可見可控；使得整個工作過程有序并減少內(nèi)耗，提高工作效率。技術（設計、開發(fā)、測試）企業(yè)技術負載于人（現(xiàn)有職工的技術；企業(yè)是否重視技術積累）技術與流程的關系：有技術，無流程不可能進行現(xiàn)代化的軟件開發(fā)；有流程，無技術不可能生產(chǎn)高質(zhì)量的產(chǎn)品組織（非直接的）通過對流程和技術產(chǎn)生作用而間接對產(chǎn)品質(zhì)量產(chǎn)生影響。組織對流程的影響（組織應該將流程制度化，規(guī)范化以保證其執(zhí)行效率；當流程執(zhí)行中遇到阻礙時，組織應給予處理，保證流程順暢執(zhí)行）組織對技術的影響（保證有能力的人去做合適的事情（資源調(diào)配）；組織重視并組織技術的積累，建立知識庫（財富庫））軟件質(zhì)量管理體系ISO9000ISO9000族2000版標準主要由ISO9000、ISO9001、ISO9004三個核心標準組成。2000版的八項質(zhì)量管理原則：以客戶為中心（在同一組織內(nèi)部，顧客的定義是下游環(huán)節(jié)的人員是上游環(huán)節(jié)人員的顧客）領導作用（1個制定，4個確保，1個創(chuàng)造，2個決定，1個評審）全員參與過程方法管理的系統(tǒng)方法持續(xù)改進基于事實的決策方法互利的供方關系八項質(zhì)量管理原則的意義：是質(zhì)量管理的理論基礎用高度概括，易于理解的語言所表述的質(zhì)量管理的最基本、最通用的一般性規(guī)律為組織建立質(zhì)量管理體系提供了理論依據(jù)是組織的領導者有效的實施質(zhì)量管理工作必須遵循的原則。CMM（CapabilityMaturityModel）/CMMI（CapabilityMaturityModelIntegration）評估軟件承辦商能力；協(xié)助軟件組織改進過程，提高過程能力基本術語：KPA（KeyProcessArea）關鍵過程域（過程域簡單的說就是做好一個事情的某個方面，對于軟件開發(fā)而言就是做好軟件開發(fā)的某個方面）如果該級別的全部PA達到要求了，就認為該級別達到了如果判斷PA達到要求呢？（每個PA包含幾個目標（Goal）；如果這幾個目標都達到要求了，就認為該PA達到要求了）如何判斷Goal達到要求呢？（每個Goal包含幾個實踐（Practice）；每個實踐達到要求了，就認為該Goal達到要求了）CMM/CMMI用途可以識別組織的長處和弱處評估組織用以來評價軟件承包商的能力和風險領導可以借此來進行過程改進，提高企業(yè)軟件生產(chǎn)能力開發(fā)和技術人員參照CMM/CMMI進行執(zhí)行過程改進CMM/CMMI的選擇企業(yè)本身項目特點（軟件開發(fā)用CMM；有軟件開發(fā)且包括硬件和采購用CMMI）考慮企業(yè)自身的能力成熟度企業(yè)對經(jīng)費的預算若企業(yè)只想在某個方面（如過程）提高進行改進（使用CMMI）CMM向CMMI的轉(zhuǎn)型CMM/CMMI區(qū)別降低了復雜度和規(guī)模；擴大了模型覆蓋率；表達方式（CMM：階段式表示；CMMI：階段式（初始級、可重復級、已定義級、已管理級、優(yōu)化級）、連續(xù)式（管理類、支持類、項目類、過程類））CMMI強調(diào)對需求的管理；加強對工程過程的重視，強調(diào)度量；加強了對風險的管理；CMM中的“組間協(xié)調(diào)”在CMMI中作為“集成化項目管理”CMM中的一個目標；中的KPA“同行評審”在CMMI中抽象為KPA“驗證”；CMM是作為評估標準出現(xiàn)的，是“必要”是才能保證評估的標準；CMMI是作為改進模型出現(xiàn)的，羅列了較多的最佳實踐，易于過程改進。CMM主要是針對軟件的CMM/CMMI的各級特點初始級（Initial）過程能力是不可預測的，過程是無序的?？芍貜图墸≧epeatable）過程能力是有紀律的。已定義級（Defined）過程能力為標準的和一致的。（SEPG軟件工程過程組）已管理級（Managed）過程能力為可預測的。優(yōu)化級（Optimizing）過程能力的基本特征是不斷改進，不斷改善其項目的過程性能。ISO9001和CMM的關系最大的相似點（強調(diào)管理、過程、規(guī)范化和文檔化）不同點（CMM把焦點嚴格對準軟件；ISO9001的范圍包括硬件、軟件、流程性材料和服務）兩者之間的聯(lián)系（CMM2和ISO9001強相關；CMM的每個關鍵過程域至少按某種解釋與ISO9001弱相關）六西格瑪（本質(zhì)是一個全面管理概念，而不僅僅是質(zhì)量提高手段）六西格瑪管理法是以質(zhì)量作為主線，以客戶為中心，利用對事實和數(shù)據(jù)的分析，改進提升一個組織的業(yè)務流程能力，從而增強企業(yè)競爭力，是一套靈活的，綜合性的管理方法體系。六西格瑪管理法原則：（與ISO9000族2000版的八大原則進行比較）注重客戶注重流程全員參與預防為主事實依據(jù)的決定持續(xù)和突破性改進六西格瑪改進區(qū)域：周期時間（流程速度、回應能力）輸出物的變差（產(chǎn)品或服務的直通率，缺陷成本降低，客戶滿意升高）營運效率（更低成本）六西格瑪?shù)膶嵤┠Ｊ剑―MAIC）定義（Define）提出問題，確定目標測量（Measure）收集資料，尋找原因分析（Analysis）研究資料，確定原因改進（Improve）優(yōu)化解決方案控制（Control）推行控制系統(tǒng)三大質(zhì)量管理體系的區(qū)別：ISO9000是不分行業(yè)的質(zhì)量管理體系；CMM/CMMI只適用于軟件行業(yè)的質(zhì)量管理體系；六西格瑪是考慮質(zhì)量、成本、進程三方面的不分行業(yè)的質(zhì)量管理體系。軟件質(zhì)量模型項目和產(chǎn)品的區(qū)別（依據(jù)需求來源不同）：項目：由特定用戶提出，以合同、契約為方式表現(xiàn)，企業(yè)需求人員獲得；產(chǎn)品：由企業(yè)內(nèi)部的市場人員進行對潛在客戶群進行分析后得出。質(zhì)量模型：一組特性及特性之間的關系，它提供規(guī)定質(zhì)量需求和評價質(zhì)量的基礎。內(nèi)部質(zhì)量：從接收到用戶的原始需求開始到產(chǎn)品交付用戶之間的所有中間過程產(chǎn)品的質(zhì)量（由開發(fā)與測試人員決定）（影響因素“鐵三角”流程最主要）外部質(zhì)量：軟件系統(tǒng)作為一個整體運行時所體系出來的特性（系統(tǒng)測試-測試人員決定）使用質(zhì)量：用戶評價軟件質(zhì)量模型軟件功能性（核心）當軟件在指定條件下使用時，軟件產(chǎn)品提供滿足明確和隱含需求的功能的能力。適合性（Suitability）：軟件產(chǎn)品為指定的任務和用戶目標提供一組合適的功能的能力。準確性（Accuracy）：軟件產(chǎn)品提供具有所需精確的正確或相符的結(jié)果或效果的能力?；ゲ僮餍裕↖nteroperabiblity）：軟件產(chǎn)品與一個或更多的規(guī)定系統(tǒng)進行交互的能力。保密安全性（Security）：軟件產(chǎn)品保護信息和數(shù)據(jù)的能力，以使未授權的人員或系統(tǒng)不能閱讀或修改這些信息和數(shù)據(jù)，而不拒絕授權人員或系統(tǒng)對它們的訪問。功能性的依從性軟件可靠性在指定條件下使用時，軟件產(chǎn)品維持規(guī)定的性能級別的能力。成熟性（Maturity）：軟件產(chǎn)品為避免由軟件中錯誤而導致失效的能力。容錯性（FaultTolerance）：在軟件出現(xiàn)故障或者違反指定接口的情況下，軟件產(chǎn)品維持規(guī)定的性能級別的能力。易恢復性（Recoverability）：在失效發(fā)生的情況下，軟件產(chǎn)品重建規(guī)定的性能級別并恢復受直接影響的數(shù)據(jù)的能力。（MTTR平均恢復時間和恢復業(yè)務的程序）可靠性的依從性軟件易用性在指定條件下使用時，軟件產(chǎn)品被理解、學習、使用和吸引用戶的能力易理解性（Understandability）：軟件產(chǎn)品使用用戶能理解軟件是否合適以及如何能將軟件用于特定的任務和使用環(huán)境的能力。易學性（Learnability）：軟件產(chǎn)品使用戶能學習其應用的能力。易操作性（Operability）：軟件產(chǎn)品使用戶能操作和控制它的能力。吸引性（Attractiveness）：軟件產(chǎn)品吸引用戶的能力。易用性的依從性軟件效率（性能測試重點）在規(guī)定條件下，相對于所用資源的數(shù)量，軟件產(chǎn)品可提供適當性能的能力。時間特性（TimeBehavior）：在規(guī)定條件下，軟件產(chǎn)品執(zhí)行其功能時，提供適當?shù)捻憫吞幚頃r間以及吞吐率的能力。（即完成用戶的某個功能需要的響應時間（響應時間是從發(fā)起請求到收到成功提示信息））資源利用性（ResourceUtilization）：在規(guī)定條件下，軟件產(chǎn)品執(zhí)行其功能時，使用合適的資源數(shù)量和類別的能力。效率依從性軟件維護性軟件產(chǎn)品可被修改（修正、改進或軟件對環(huán)境、需求和功能規(guī)格說明變化的適應）的能力。易分析性（Analyzability）：軟件產(chǎn)品診斷軟件中的缺陷或失效的原因或識別待修改部分的能力。易改變性（Changeability）：軟件產(chǎn)品使指定的修改可以被實現(xiàn)的能力。穩(wěn)定性（Stability）：軟件產(chǎn)品避免由于修改而造成意外結(jié)果的能力。易測試性（Testability）：軟件產(chǎn)品使已修復軟件能被確認的能力。維護性的依從性軟件可移植性軟件產(chǎn)品從一種環(huán)境遷移到另一種環(huán)境的能力。適應性（Adaptability）：軟件產(chǎn)品無需采用有別于為考慮該軟件的目的而準備的活動或手段就可能適應不同的指定環(huán)境的能力。易安裝性（Installability）：軟件產(chǎn)品在指定環(huán)境中被安裝的能力（安裝測試）。共存性（Co-existence）：軟件產(chǎn)品在公共環(huán)境中同與其分享公共資源的其他獨立軟件共存的能力。易替換性（Replaceablity）：軟件產(chǎn)品在同樣環(huán)境下，替代另一個相同用途的指定軟件產(chǎn)品的能力?？梢浦残缘囊缽男攒浖|(zhì)量活動（軟件質(zhì)量保證（SQA）和測試）SQA和測試的關系：SQA從流程方面保證了軟件的質(zhì)量測試從技術方面保證了軟件的質(zhì)量只進行SQA活動或者只進行測試活動不一定能產(chǎn)生很好的軟件質(zhì)量。SQA的主要工作范圍：（被稱為老師，醫(yī)生，警察）指導（指導項目成員執(zhí)行過程，培訓）并監(jiān)督（過程的執(zhí)行是否符合規(guī)范）項目安裝過程實施對項目進行度量（度量數(shù)據(jù)的采集，度量使得不可見的智力過程變得可見）、分析，增加項目的可視性審核（審計過程產(chǎn)品是否符合相關模塊，審計問題產(chǎn)生原因）工作產(chǎn)品，評價工作產(chǎn)品和過程質(zhì)量目標的符合度進行缺陷分析（提出過程改進意見給SEPG），缺陷活動預防，發(fā)現(xiàn)過程的缺陷，提供決策的參考，促進過程的改進SQA需要職能：軟技能（個人素質(zhì)、溝通能力）自我修煉掌握項目管理熟知軟件工程了解業(yè)務知識熟練掌握過程改進體系質(zhì)量管理PDCA循環(huán)（螺旋式上升逐步實現(xiàn)質(zhì)量目標）：Plan計劃：制定計劃，明確目標；基于目標的方法步驟Do執(zhí)行：執(zhí)行PlanCheck檢查：檢查實際執(zhí)行結(jié)果與計劃中預期目標的差距（目標的實現(xiàn)程度，若存在差距，分析原因）Act改進：根據(jù)分析原因給出明確方案并制定下一輪過程改進目標糾正措施糾正措施計劃設計檢查檢測實施執(zhí)行Plan計劃Do執(zhí)行Act改進Check檢查軟件度量的概念和目的：度量：對事物屬性的量化表示軟件度量：是指計算機軟件中范圍廣泛的測度，包括對軟件系統(tǒng)、構(gòu)件或生命周期過程具有的某個給定屬性的度的一個定量測量目的：提高軟件生產(chǎn)率，縮短產(chǎn)品研發(fā)周期，降低研發(fā)成本、維護成本（對于開發(fā)商）提高軟件產(chǎn)品質(zhì)量，提高用戶滿意度（對用戶）為組織持續(xù)改進提供量化的指標和反饋（對開發(fā)商長遠）軟件度量的作用：理解預測評估改進軟件度量分類：四個基本度量項：規(guī)模（Size）：軟件產(chǎn)品的大小工作量（Effort）：完成各軟件工作產(chǎn)品和活動所用人時（或人天等）進度（Schedule）：各軟件工作產(chǎn)品和活動開始和結(jié)束的時間質(zhì)量（quality）-缺陷(defect)：在各軟件工作產(chǎn)品和活動中產(chǎn)生的缺陷數(shù)其他度量指標：缺陷密度：研發(fā)活動發(fā)現(xiàn)缺陷密度；研發(fā)活動引入缺陷密度；工作產(chǎn)品缺陷密度生產(chǎn)率：SRS、HLD、LLD階段文檔生產(chǎn)率：頁/人天；編碼階段生產(chǎn)率：KLOC/人天；UT、IT、ST用例設計階段生產(chǎn)率：用例/人天測試執(zhí)行效率：執(zhí)行用例數(shù)/人天用例密度：用例數(shù)/KLOC。。。。。。。。。。。。。。。。。。。。測試方法是否需要了解軟件內(nèi)部結(jié)構(gòu)（黑盒測試和白盒測試）注灰盒測試是否需要執(zhí)行被測對象（靜態(tài)測試和動態(tài)測試）是否需要借助自動化腳本或工具進行測試（人工測試和自動化測試）黑盒測試和白盒測試什么是白盒測試（基于程序結(jié)構(gòu)的邏輯驅(qū)動測試）？白盒測試是依據(jù)被測軟件分析程序內(nèi)部構(gòu)造，并依據(jù)內(nèi)部構(gòu)造設計用例，來對內(nèi)部控制流程進行測試，可完全不顧程序的整體功能實現(xiàn)情況。（玻璃盒測試，透明盒測試，開放盒測試，結(jié)構(gòu)化測試，邏輯驅(qū)動測試）】為什么進行白盒測試？白盒測試一般在測試前期進行，通過達到一定的邏輯覆蓋率指標，使得軟件內(nèi)部邏輯控制結(jié)構(gòu)上的問題能基本得到消除白盒測試能保證內(nèi)部邏輯結(jié)構(gòu)達到一定的覆蓋程度，能夠給予軟件代碼質(zhì)量的更大保證白盒測試發(fā)現(xiàn)問題后解決問題的成本較低白盒測試的常用技術：（靜態(tài)分析和動態(tài)分析）靜態(tài)分析：控制流分析、數(shù)據(jù)流分析、信息流分析等；控制流分析相關概念程序元素：一個程序元素通常是一個條件，一個簡單的語句或者一塊語句（多個連續(xù)語句）控制流關系：一個程序的控制流關系敘述了程序元素和它們執(zhí)行的次序之間的聯(lián)系控制流圖：對應于控制流關系的圖控制流矩陣：由控制流圖得到，反映相鄰程序元素之間的先后順序關系控制流分析步驟確定所有程序元素；根據(jù)程序元素之間的相互關系得到控制流圖；將控制流圖轉(zhuǎn)換成控制流矩陣；通過數(shù)據(jù)結(jié)構(gòu)的形式把控制流矩陣表示出來；借助算法對控制流進行分析，找出存在的問題；控制流分析可以發(fā)現(xiàn)的問題確保寫出的程序不應包含：轉(zhuǎn)向并不存在的標號；沒有用的語句的標號；從程序入口進入后無法達到的語句；不能達到停機語句的語句。數(shù)據(jù)流分析相關概念數(shù)據(jù)流分析法關鍵是數(shù)據(jù)的定義和引用。數(shù)據(jù)的定義：如果程序中某一語句執(zhí)行時能改變某程序變量V的值，則稱V是被該語句定義的。數(shù)據(jù)的引用：如果一語句的執(zhí)行引用了內(nèi)存中變量V的值，則說該語句引用變量V。數(shù)據(jù)流分析步驟根據(jù)代碼得到數(shù)據(jù)流表；分析數(shù)據(jù)流表找到以下兩種錯誤：（變量未定義但被引用；變量定義但未被引用）；根據(jù)分析結(jié)果對代碼進行修正和優(yōu)化。信息流分析動態(tài)分析：邏輯覆蓋測試（分支測試、路徑測試等）、程序插裝等；邏輯覆蓋測試（分支測試、路徑測試等） 程序插裝 借助往被測程序中插入操作來實現(xiàn)測試目的的方法。（比如：打印語句，打印我們最關系的信息）。白盒測試的特點：測試人員需要了解軟件的實現(xiàn)；可以檢測代碼中的每條分支和路徑；揭示隱藏在代碼中的錯誤；對代碼的測試比較徹底；實現(xiàn)代碼結(jié)構(gòu)上的優(yōu)化；白盒測試投入大，成本高；白盒測試不驗證規(guī)格的正確性。什么是黑盒測試（基于規(guī)格的測試）？黑盒測試把被測對象看成一個黑盒，只考慮其整體特征，不考慮其內(nèi)部具體實現(xiàn)。黑盒測試針對的被測對象可以是一個系統(tǒng)，一個子系統(tǒng)，一個模塊，一個子模塊，一個函數(shù)等。常見的黑盒測試類型：功能性測試：一種是順序測試每個程序特性或功能，另一種途徑是一個模塊一個模塊的測試，即每個功能在其最先調(diào)用的地方被測試；容量測試：檢測軟件在處理海量數(shù)據(jù)時的局限性，能發(fā)現(xiàn)系統(tǒng)效率方面的問題；負載測試：檢測系統(tǒng)在一個很短時間內(nèi)處理一個巨大的數(shù)據(jù)量或執(zhí)行許多功能調(diào)用上的能力；恢復性測試：主要保證系統(tǒng)在崩潰后能夠恢復外部數(shù)據(jù)的能力。常用的黑盒測試的方法：等價類劃分法；邊界值分析法；因果圖分析法；判定表法；狀態(tài)遷移法；。。。。。。。。。黑盒測試的特點：對于更大的代碼單元來說（子系統(tǒng)甚至系統(tǒng)）比白盒測試效率更高；測試人員不需要了解實現(xiàn)的細節(jié)，包括特定的編程語言；從用戶的視角進行測試，很容易被大家理解和接受；有助于暴露任何規(guī)格不一致或有歧義的問題；沒有清晰的和簡明的規(guī)格，測試用例很難設計的；不能控制內(nèi)部執(zhí)行路徑，會有很多內(nèi)部程序路徑?jīng)]有被測試到；不能直接針對特定的程序段，這些程序可能非常復雜（因此可能隱藏更多的問題）?；液袦y試利用被測對象的整體特性信息，采用黑盒測試方法；利用被測對象的內(nèi)部具體實現(xiàn)信息，采用白盒測試方法；如果既使用被測對象的整體特性信息，又利用被測對象的內(nèi)部具體實現(xiàn)信息，采用灰盒測試方法。兩種信息占的比例不同，相應的灰度就不同。靜態(tài)測試和動態(tài)測試靜態(tài)測試：不運行被測試的軟件系統(tǒng)，而是采用其他手段和技術對被測試軟件進行檢測的一種測試技術。（代碼走讀、文檔評審、程序分析等）。靜態(tài)測試常用技術——靜態(tài)分析技術：定義：一種不通過執(zhí)行程序而分析程序執(zhí)行的技術。功能：檢查軟件的表示和描述是否一致，沒有沖突或者沒有歧義，它描述的是糾正軟件系統(tǒng)的描述、表示和規(guī)格上的錯誤，因此是任何進一步測試執(zhí)行的前提。主要有三種不同的程序測試可能性：考慮程序是否滿足編碼規(guī)則，語法上是否具有一致性和完整性；考慮文檔描述是否規(guī)范、準確、便于查閱；考慮程序和文檔之間的一致性。靜態(tài)分析技術結(jié)構(gòu) 手工 自動正規(guī)檢視技術評審走查靜態(tài)驗證語法分析器符號執(zhí)行器手工靜態(tài)分析（最重要的手工技術是同行評審（對象：計劃、需求文檔、設計圖、代碼等））：根據(jù)同行評審形式正規(guī)的程度分為：正規(guī)檢視：以某個方案的裁決為目的，形式比較嚴格，有固定的流程，多用于文檔的評審；技術評審：以某個方案的裁決為目的，一般由企業(yè)高層技術人員和管理人員參與；走查：以發(fā)現(xiàn)軟件產(chǎn)品中的缺陷為目的，沒有嚴格規(guī)定，比較隨意。自動化靜態(tài)分析動態(tài)測試：按照預先設計的數(shù)據(jù)和步驟去運行被測軟件系統(tǒng)，從而對被測軟件系統(tǒng)進行檢測的一種技術。動態(tài)測試常用技術——動態(tài)分析技術：定義：對軟件系統(tǒng)運行行為進行分析，包含程序在受控的環(huán)境下使用特定的輸入進行正式的運行，和期望的結(jié)果比較以檢查系統(tǒng)運行是正確還是不正確。常用的動態(tài)分析技術：路徑測試分支測試性能測試。。。。。。。。常用動態(tài)分析工具功能動態(tài)分析類型工具的功能測試覆蓋率分析（白盒）測試對代碼的檢測范圍跟蹤（白盒）跟蹤程序執(zhí)行期間的所以路徑，例如所有變量的值等調(diào)整（黑盒）度量程序執(zhí)行過程中使用的資源模擬（黑盒）模擬系統(tǒng)的一部分，例如無法獲得的代碼或硬件斷言檢查（白盒）測試在復雜邏輯結(jié)構(gòu)中是否某個條件已經(jīng)被給出Logiscope中的Rulechecker(白盒靜態(tài)技術)，Logiscope中的Testchecher（白盒動態(tài)技術）、TCL（白盒動態(tài)技術）。人工測試和自動化測試人工測試：測試活動（如評審、測試設計、測試執(zhí)行等）由人工來完成，狹義上是指測試執(zhí)行由人工完成，這是最基本的測試形式。自動化測試：一般是指通過計算機模擬人的測試行為，替代人的測試活動，狹義上是指測試的執(zhí)行由計算機完成。自動化測試的意義：對程序新版本運行前一版本執(zhí)行的測試，提高回歸測試效率可以運行更多更頻繁的測試，比如冒煙測試可以執(zhí)行手工測試困難或不可能做的測試，比如大量的重復操作或者集成的測試更好地利用資源，比如測試儀器或者被測對象測試具有一致性和可重復性，即自動化測試的步驟和結(jié)果是完全一樣的測試的復用性，即自動化測試腳本可以拆分開給其他測試腳本使用可以更快地將軟件推向市場，軟件發(fā)布前進行高效的回歸測試，減少軟件發(fā)布的時間增加軟件的信任度，通過自動化測試提高了測試效率，把節(jié)約的時間拿出來做更多的測試。自動化測試的限制：不能取代手工測試，自動化測試只能提供測試效率，不能提高測試的有效性，即不可能發(fā)現(xiàn)更多的缺陷手工測試比自動化測試發(fā)現(xiàn)的缺陷更多對測試設計依賴性極大，測試設計的不好會遺漏問題自動化測試對軟件開發(fā)具有很大的依賴性，開發(fā)上出現(xiàn)變更可能導致前面的自動化測試完全失效工具本身并不具備想象力，工具不具有職能。自動化測試的誤區(qū)：不現(xiàn)實的期望，希望自動化能取代手工測試缺乏測試實踐經(jīng)驗，手工測試都做不好，或者經(jīng)驗積累不夠，就嘗試自動化，很難成功期望自動化測試發(fā)現(xiàn)大量新的缺陷，自動化只能保證測試執(zhí)行的效率，確保已有的問題不再發(fā)生，發(fā)現(xiàn)新缺陷不是其目的安全性錯覺，認為進行自動化測試的軟件就安全的，質(zhì)量有保證的（只有手工測試做好了，明確了測試觀察點，才能把自動化測試做好，所以手工測試是自動化測試的一個基礎）需求管理軟件需求管理簡介需求（強調(diào)做什么（What）而不是如何做（How））的定義：SRS就是（1）解決用戶問題或達到用戶目標所需的條件或能力；2）為遵循合同、標準、規(guī)格或其他要求的正式文檔，系統(tǒng)必須滿足或擁有的條件或能力。）需求管理的定義：使用戶和項目團隊之間，就不斷變更的需求，達到并保持一致的過程。（基線：評審后方可建立受控，需修改時必須經(jīng)過CCB（ChangeControlBoard變更控制委員會）批準是下一步開始工作的基礎）需求管理的要求：軟件需求要基線化軟件需求的實現(xiàn)要跟蹤，要記錄，要標示要測量軟件需求要驗證軟件需求軟件需求工程介紹需求開發(fā)需求開發(fā)需求管理需求工程需求獲取需求分析需求定義需求驗證需求分配需求評審需求基線需求跟蹤變更控制需求開發(fā)：需求獲?。焊鶕?jù)需求來源的不同分為：項目和產(chǎn)品需求分析：1）根據(jù)用戶提出的顯示需求，充分的挖掘其背后隱藏的隱式需求；2）嚴格定義所以需求（顯示和隱式）的規(guī)格（功能、性能、約束、質(zhì)量、其他）需求定義：將所獲取的所有需求以規(guī)范化的語言表示需求驗證：驗證需求是否得到實現(xiàn)（需求陷阱：缺少用戶參與；用戶扁平需求；項目范圍不斷擴大；切忌需求沒完沒了；切忌模糊不清的需求等）需求管理（CMM二級的第一個KPA）：需求分配：需求本身是分層次的（業(yè)務需求；用戶需求；軟件需求），并非所有項目都有需求分配；需求評審：評審已分配的需求（原始需求）；對已形成的SRS進行評審需求基線：建立需求基線使得SRS可控需求跟蹤：貫穿于整個軟件開發(fā)過程變更控制：需求變更的控制（失效的變更控制；沒有進行變更控制（幾乎不存在））軟件需求變更：需求變更可能發(fā)生在任意階段要求變更的需求進行變更控制變更的基礎是需求基線軟件需求跟蹤流程介紹軟件需求跟蹤流程Input Task Output對于已經(jīng)基線化的SRS、設計文檔、代碼、測試文檔等的CRs初始化RTM對于已經(jīng)基線化的SRS、設計文檔、代碼、測試文檔等的CRs初始化RTM更新RTMSOWorARRTMForm準備基線化的文檔，代碼初始的RTM更新后的RTMSOW為工作說明書；AR為原始需求；CRs為需求變更RTM（RequirementTruceablityMatrix）需求跟蹤矩陣（注意Excel最下排的不同需求列表）RTM初始化：將原始需求列入原始需求列表將SRS列入SRS列表在開發(fā)需求跟蹤矩陣中建立AR與SRS的關系（在開發(fā)中確保需求被實現(xiàn)）在系統(tǒng)測試需求跟蹤矩陣中建立SRS與ST的關系（在測試中確保需求被驗證）軟件需求跟蹤方法需求項，概要設計項等的定義。通用測試用例寫作方法軟件測試用例格式測試用例編號N3310_IT_FILEITF_READFILE_004測試項目測試模塊A提供的文件接口測試標題文件B正在被其他進行執(zhí)行讀/寫操作，通過A模塊的文件接口讀取文件B中的數(shù)據(jù)重要級別高預置條件進程XProcess被創(chuàng)建并啟動輸入。。。。操作步驟。。。預期輸出。。。測試用例的寫作要點測試用例編號規(guī)則：由字符和數(shù)字組合成的字符串，用例編號應具有唯一性、易識別性約定：系統(tǒng)測試用例：產(chǎn)品編號-ST-系統(tǒng)測試項名-系統(tǒng)測試子項名-XXX 。。。。。。。。。。。。。。。。。。。。。。。測試用例項目規(guī)則：當前測試用例所屬測試大類、被測需求、被測模塊、被測單元等約定：系統(tǒng)：軟件需求項；集成：集成后的模塊名或接口名；單元：被測試的函數(shù)名測試用例標題規(guī)則：測試用例的簡單描述，需要用概括的語言描述該用例的出發(fā)點和關注點，原則上每個用例的標題不能重復測試用例重要級別規(guī)則：高：保證系統(tǒng)基本功能、核心業(yè)務、重要特性、實際使用頻率比較高的用例中：重要程度介于高和低之間的測試用例低：實際使用頻率不高、對業(yè)務功能影響不大的模塊或功能的測試用例（對于流程：基本流的級別為高；備選流的級別為低）測試用例預置條件規(guī)則：執(zhí)行當前測試用例需要的前提條件，如果這些前提條件不滿足，則后面的測試步驟無法進行或者無法得到預期的結(jié)果測試用例輸入規(guī)則：用例執(zhí)行過程中需要加工的外部信息。根據(jù)軟件測試用例的具體情況，有手工輸入、文件、數(shù)據(jù)庫記錄等等測試用例操作步驟規(guī)則：執(zhí)行當前測試用例需要經(jīng)過的操作步驟，需要明確的給出每個步驟的描述，測試用例執(zhí)行人員可以根據(jù)該操作步驟完成測試用例執(zhí)行測試用例預期結(jié)果規(guī)則：當前測試用例的預期輸出結(jié)果，包括返回值的內(nèi)容、界面的響應結(jié)果、輸出結(jié)果的規(guī)則符合度等等測試用例的寫作檢查規(guī)則測試用例標識是否按照測試方案的規(guī)則來編寫是否每個測試用例的預置條件都被描述清楚？每個測試用例的“輸入“中是否列出了所以測試的輸入數(shù)據(jù)？測試用例的“預期結(jié)果“是否完整而且清晰？是否明確說明了每個測試用例或測試用例集的重要級別？是否明確說明了測試用例的執(zhí)行順序？軟件缺陷管理軟件缺陷管理基本概念注意五個關于缺陷管理的名詞：BUG，缺陷（Defect），錯誤（Error），故障（Fault），失效（Failure）缺陷報告單（前面在缺陷類型中提到的五種缺陷都應寫如其中）缺陷管理的目的：保證信息的一致性保證缺陷得到有效的跟蹤，解決獲取正確的Bug信息，用作缺陷分析和產(chǎn)品度量軟件缺陷管理基本流程Bug的生命周期：一個缺陷從最初的提交，經(jīng)過若干處理，最后關閉的過程。缺陷的相關屬性：缺陷發(fā)現(xiàn)人缺陷發(fā)現(xiàn)時間缺陷狀態(tài)缺陷嚴重程度嚴重性：軟件缺陷對軟件質(zhì)量的破壞程度，即此軟件缺陷的存在將對軟件的功能和性能產(chǎn)生怎樣的影響。致命：例如，軟件的意外退出甚至操作系統(tǒng)崩潰，造成數(shù)據(jù)丟失。嚴重：例如，由于單功能失效導致多個相關功能均失效。一般：例如，軟件的單功能失效。提示：軟件界面的細微缺陷。例如，某個控件沒有對齊，某個標點符合丟失等依據(jù)（工作量、質(zhì)量、進度、成本）修改缺陷的優(yōu)先級分為：緊急的，恰當?shù)?，范圍?nèi)的缺陷所屬版本缺陷修改日期TD（QC）中常用軟件缺陷狀態(tài)列表：New：缺陷的初始狀態(tài)Open：開發(fā)人員開始修改缺陷Fixed：開發(fā)人員修改缺陷完畢Closed：回歸測試通過Reopen：回歸測試失敗Postpone：推遲修改Rejected：開發(fā)人員認為不是程序問題，拒絕缺陷Duplicate：與已經(jīng)提交的Defect重復Abandon：被Rejected和Duplicate的Defect，測試人員確認后的確不是問題，將Defect置為此狀態(tài)軟件測試缺陷管理流程：提交一個Bug審查Bug并分配相關負責人員修改Bug回歸測試BUG管理流程圖BUG管理流程圖測試人員測試經(jīng)理開發(fā)經(jīng)理開發(fā)人員NewDuplicateOpenNAbandonYPostposePostposeAssignNYFixedReopenClosedValidate缺陷跟蹤單填寫方法缺陷跟蹤單寫作準則（5C）：Correct（準確）：每個組成部分的描述準確，不會引起誤解Clear（清晰）：每個組成部分的描述清晰，易于理解Concise（簡潔）：只包含必不可少的信息，不包括任何多余的內(nèi)容Complete（完整）：包含復現(xiàn)該缺陷的完整步驟和其他本質(zhì)信息Consistent（一致）：按照一致的格式書寫全部缺陷報告缺陷跟蹤單基本內(nèi)容缺陷項目注意事項簡單描述1、用一句話簡單的描述清楚問題（Headline“看到什么“）詳細描述1、描述問題的基本環(huán)境，包括操作系統(tǒng)、硬件環(huán)境、網(wǎng)絡環(huán)境、被測試軟件的運行環(huán)境2、用簡明扼要的語言描述清楚軟件出現(xiàn)異常的時候的測試人員的操作步驟和使用數(shù)據(jù)3、如果從GUI界面上可以反映出軟件的異常，采用拷屏的方式截屏，粘貼在問題單中4、被測試軟件運行時候的相關日志文件5、測試人員根據(jù)上述信息可以給出對問題的簡單的分析6、被測試軟件的版本7、狀態(tài)、嚴重級別、優(yōu)先級8、提交日期、提交人相關附件1、GUI的拷屏圖片2、被測試軟件運行的相關日志文件缺陷報告的寫作要點：再現(xiàn)：一般是盡量三次再現(xiàn)故障，如果問題是間斷的，那要報告問題發(fā)生頻率初步定位：可能影響再現(xiàn)的變量，例如配置變化、工作流、數(shù)據(jù)庫，這些都可能改變錯誤的特征推廣：確定系統(tǒng)的其他部分是否可能出現(xiàn)這種錯誤，以及使用不同的數(shù)據(jù)時是否存在著這種問題等等，特別是這些可能存在更加嚴重特征的部分壓縮：精簡任何不必要的信息，特別是冗余的測試步驟去除歧義：使用清晰的語言，尤其是避免使用那些有多個不同或相反含義的詞匯中立：公正的表達自己的意思，對錯誤及其特征的事實進行陳述，避免夸張、幽默和諷刺評審：至少有一個同行，最好是一個有經(jīng)驗的測試工程師或測試經(jīng)理，在遞交錯誤報告之前自己先閱讀一遍。測試覆蓋率覆蓋率概念覆蓋率是用來度量測試完整性的一個手段。覆蓋率是測試技術有效性的一個度量。覆蓋率=（至少被執(zhí)行一次的Item數(shù)）/item的總數(shù)覆蓋率大體可劃分為兩大類：邏輯覆蓋率和功能覆蓋率測試用例設計不能一味追求覆蓋率，因為測試成本隨覆蓋率的增加而增加。邏輯覆蓋率主要類型：語句覆蓋（StatementCoverage）在測試時運行被測程序后，程序中被執(zhí)行到的可執(zhí)行語句的比率：語句覆蓋率=（至少被執(zhí)行一次的語句數(shù)量）/（可執(zhí)行的語句總數(shù)）判斷覆蓋（DecisionCoverage）或分支覆蓋（BranchCoverage）在測試時運行被測程序后，程序中所有判斷語句的取真分支和取假分支被執(zhí)行到的比率判斷覆蓋率=（判斷結(jié)果被評價的次數(shù)）/（判斷結(jié)果的總數(shù)）分支條件覆蓋率（BranchConditionCoverage）或判斷條件覆蓋率（DecisionConditionCoverage）在測試時運行被測程序后，所有判斷語句中的每個條件的所有可能值（為真或為假）和每個判斷本身的判定結(jié)果（為真或為假）出現(xiàn)的比率分支條件覆蓋率=（條件操作數(shù)值或判定結(jié)果至少被評價一次的數(shù)量）/（條件操作數(shù)值總數(shù)+判定結(jié)果總數(shù)）路徑覆蓋率（PathCoverage）在測試時運行被測程序后，程序中所有可能的路徑被執(zhí)行過的比率路徑覆蓋率=（至少被執(zhí)行到一次的路徑數(shù)）/（總的路徑數(shù)）路徑能否全面覆蓋在軟件測試中是個重要的問題，如果程序中的每一條路徑都得到考驗，才能說程序受到了全面檢驗即使對于路徑數(shù)有限的程序已經(jīng)做到了路徑覆蓋，仍然不能保證被測程序的正確性其他覆蓋率功能覆蓋率（FunctionCoverage）：屬于黑盒測試范疇面向?qū)ο蟮母采w率繼承上下文覆蓋基于狀態(tài)的上下文覆蓋已定義用戶上下文覆蓋函數(shù)覆蓋指令塊覆蓋判定路徑覆蓋單元測試單元測試的定義和目的什么是單元測試？單元測試是對軟件基本組成單元進行測試，如函數(shù)(function或procedure)或一個類的方法（method）單元具有一些基本屬性，如：明確的功能、規(guī)格定義，明確的與其他部分的接口定義等，可清晰地同一程序的其他單元劃分基本單元不一定是指一個具體的函數(shù)或一個類的方法在具體實現(xiàn)時，也可能對應的是多個程序文件中的一組函數(shù)單元測試的目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種錯誤，主要是基于白盒測試驗證代碼是與設計相符合的；發(fā)現(xiàn)設計和需求中存在的錯誤發(fā)現(xiàn)在編碼過程中引入的錯誤單元測試關注的重點單元接口對如下進行測試：被測單元的輸入輸出參數(shù)在個數(shù)、屬性、順序上是否和詳細設計中的描述保持一致是否修改了只做輸入用的形式參數(shù)約束條件是否通過形式參數(shù)來傳送局部數(shù)據(jù)結(jié)構(gòu)檢查一些各種錯誤：檢查不正確或不一致的數(shù)據(jù)類型說明使用尚未賦值或尚未初始化的變量錯誤的初始值或錯誤的缺省值變量名拼寫錯誤或書寫錯誤不一致的數(shù)據(jù)類型獨立路徑對基本執(zhí)行路徑和循環(huán)進行測試會發(fā)現(xiàn)大量的錯誤。設計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。運算的優(yōu)先次序不正確或誤解了運算的優(yōu)先次序運算的方式錯誤不同數(shù)據(jù)類型的比較“差1錯”。即不正確的多循環(huán)或少循環(huán)一次錯誤的或不可能的循環(huán)終止條件關系表達式中不正確的變量和比較符當遇到發(fā)散的迭代時不能終止的循環(huán)不適當?shù)匦薷牧搜h(huán)變量等出錯處理比較完善的單元設計要求能預見出錯的條件，并設置適當?shù)某鲥e處理，已使在程序出錯時，能對出錯程序重新做安排，保證其邏輯上的正確性出錯的描述難以理解出錯的描述不足以對錯誤定位和確定出錯的原因顯示的錯誤與實際的錯誤不符對錯誤條件的處理不正確在對錯誤進行處理前，錯誤條件已經(jīng)引起系統(tǒng)的干預等邊界條件常見錯誤：在N次循環(huán)的第N次，取最大最小值時容易發(fā)生錯誤特別要注意數(shù)據(jù)流，控制流中剛好等于、大于、小于確定的比較值時出現(xiàn)錯誤的可能性單元測試環(huán)境必須為每個單元測試開發(fā)驅(qū)動單元和樁單元驅(qū)動單元（Driver）：所測函數(shù)的主程序，它接收測試數(shù)據(jù)，并把數(shù)據(jù)傳送給所測試單元，最后再輸出實測結(jié)果。當被測試單元能完成相關功能時，也可以不要驅(qū)動單元。接收測試數(shù)據(jù)，包含測試用例輸入和預期輸出把測試用例輸入傳送給要測試的單元將被測單元的實際輸出和預期輸出進行比較，得到測試結(jié)果將測試結(jié)果輸出到指定位置樁單元（Stub）：用例代替所測單元調(diào)用的子單元樁單元的功能是從測試角度模擬被調(diào)用的單元樁單元需要針對不同的輸入，返回不同的期望值，模擬所代替單元的不同功能樁單元返回的期望值根據(jù)輸入和被測模擬單元的詳細設計來確定單元測試策略孤立的測試策略方法：不考慮每個模塊與其他模塊之間的關系，為每個模塊設計樁模塊和驅(qū)動模塊。每個模塊進行獨立的單元測試。優(yōu)點：該方法是最簡單，最容易操作的，可以到達高的結(jié)構(gòu)覆蓋率，它是純粹的單元測試缺點：樁函數(shù)和驅(qū)動函數(shù)工作很大，效率低自頂向下的單元測試策略方法：先對最頂層的單元進行測試，把頂層所調(diào)用的單元做成樁模塊。其次對第二層進行測試，使用上面已測試的單元做驅(qū)動模塊。如此類推直到測試完所有模塊。優(yōu)點：可以節(jié)省驅(qū)動函數(shù)的開發(fā)工作量，測試效率較高缺點：隨著被測單元一個一個被加入，測試過程將變得越來越復雜，并且開發(fā)和維護的成本將增加。自底向上的單元測試策略方法：先對模塊調(diào)用層次圖上最低層的模塊進行單元測試，模擬調(diào)用該模塊的模塊做驅(qū)動模塊。然后再對上一層做單元測試，用下面已經(jīng)被測試過的模塊做樁模塊。以此類推，直到測試完所有模塊。優(yōu)點：可以節(jié)省樁函數(shù)的開發(fā)工作量，測試效率較高缺點：不是純粹的單元測試，底層函數(shù)的測試質(zhì)量對上層函數(shù)的測試將產(chǎn)生很大的影響。單元測試過程單元測試的四個階段單元測試計劃階段：完成單元測試計劃單元測試設計階段：完成單元測試方案單元測試實現(xiàn)階段：完成單元測試用例、單元測試規(guī)程、單元測試腳本及數(shù)據(jù)文件單元測試執(zhí)行階段：執(zhí)行單元測試用例，修改發(fā)現(xiàn)的問題并進行回歸測試，提交單元測試報告單元測試原則對全新的代碼或修改過的代碼進行單元測試單元測試根據(jù)單元測試計劃和方案進行，排除測試的隨意性必須保證單元測試計劃、單元測試方案、單元測試用例等經(jīng)過評審當測試用例的測試結(jié)果與預期結(jié)果不一致時，單元測試的執(zhí)行人員需如實記錄實際的測試結(jié)果只有當測試計劃中的結(jié)束標準達到時，單元測試才能結(jié)束對被測試單元需達到的一定的代碼覆蓋率要求單元測試執(zhí)行過程單元測試執(zhí)行時間安排編碼完成之后，并且符合單元測試入口條件單元測試執(zhí)行的活動構(gòu)造單元的測試環(huán)境運行單元測試腳本，記錄測試結(jié)果修改錯誤，進行回歸測試單元測試分析和總結(jié)提交單元測試報告單元測試執(zhí)行的輸入輸入：單元測試計劃、單元測試方案、單元測試用例和規(guī)程、驅(qū)動程序和樁模塊、需求規(guī)格說明書、概要設計說明書、詳細設計說明書輸出：單元測試報告CppUnit自動化單元測試框架CppUnit是用于面向?qū)ο骳++程序的單元測試的框架，它提供了一系列的頭文件和靜態(tài)庫。采用CppUnit所提供的單元測試框架，可以很方便的開發(fā)測試用例，并實現(xiàn)單元測試的“自測試”。使用CppUnit開發(fā)出來的測試用例是固化的，對同一功能多次執(zhí)行的測試用例是完全相同的，并實現(xiàn)了測試的自動化。CppUnit采用斷言來判斷測試用例的執(zhí)行結(jié)果，并可將執(zhí)行結(jié)果寫入一個文本文件中。CppUnit基本概念：被測試類（CUT）：被測試的類，該類的一個實例對象或者類本身作為測試的對象被測試方法；被測試的類中的成員方法測試用例(testcase)：是用來測試一個功能是否正確的一系列測試執(zhí)行，是測試執(zhí)行和統(tǒng)計的最基本單位測試工廠：一般給一個被測試類定義一個測試工廠，對該被測試類的被測試方法的測試用例和數(shù)據(jù)進行組裝測試裝置（testfixture）：容納多個測試方法以及相關測試數(shù)據(jù)的類，它可以為多個測試方法準備相關數(shù)據(jù)、測試上下文，進行公共的初始化和后處理測試套（testsuite）：相關測試用例的集合，測試套之間可以相互嵌套，也就是說一個測試套可以包含一些測試用例，也可以包含其他測試套，一般來說測試套和被測試的方法對應，并且需要把測試套定義為測試裝置類測試方法（testmethod）：以一個函數(shù)形式表現(xiàn)出來的獨立的測試執(zhí)行，每個測試用例對應一個測試方法，但又不完全等同于測試方法。比如進行繼承類的測試，雖然父類和子類有完全相同的測試方法，但是在父類和子類中對應于同樣測試方法的測試用例是不相干的測試驅(qū)動（testdriver）：就是給所有的測試用例提供執(zhí)行環(huán)境的代碼測試執(zhí)行器（testrunner）：負責實際執(zhí)行測試驅(qū)動。在CppUnit中，一般在main函數(shù)或其他的入口點定義一個測試執(zhí)行器，然后把要執(zhí)行的測試套全部加入該執(zhí)行器，調(diào)用該執(zhí)行器的run函數(shù)，執(zhí)行實際的測試CppUnit基本框架：測試執(zhí)行器 測試工廠1（對應類1） 測試套11（對應類1的方法1） 測試方法111（對應用例1） 測試方法112（對應用例2） 。。。。。。。。。。。。。。。。。。。。。。。。 測試套12（對應類1的方法2） 測試工廠2（對應類2） 測試套21（對應類2的方法1） 。。。。。。。。。。。。。。。。。。。。。。。 測試套22（對應類2的方法2） 。。。。。。。。。。。。。。。。。。。。。。。。。。CppUnit框架結(jié)果判斷主要依靠斷言進行檢查，判斷測試用例執(zhí)行是否成功；如：CPPUNIT_ASSERT_EQUAL(para1,para2)集成測試集成測試的定義和目的什么是集成測試（組裝測試、聯(lián)合測試等）？集成測試是在單元測試的基礎上，將所有函數(shù)按照概要設計要求組裝成為子系統(tǒng)或系統(tǒng)所進行的測試。集成測試和單元測試所關注的范圍是不同的，因此，它們在發(fā)現(xiàn)問題的集合上包含有不相交的區(qū)域，不能使用集成測試來代替單元測試，反之也是一樣。集成測試的目的：集成測試的目的是確保各組件組合在一起后能夠按既定意圖協(xié)作運行，并確保增量的行為正確。屬于灰盒測試。驗證接口是否與設計相符合；發(fā)現(xiàn)設計和需求中存在的錯誤。集成測試關注的重點單元間的接口（類型：函數(shù)接口、文件接口、消息接口、數(shù)據(jù)庫接口和全局變量）在把各個模塊連接起來的時候，穿越模塊接口的數(shù)據(jù)是否會丟失；全局數(shù)據(jù)結(jié)構(gòu)是否有問題，會不會被異常修改?；A后的功能各個子功能組合起來，能否達到預期要求的父功能一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；單個模塊的誤差積累起來，是否會放大，從而達到不可接受的程度。集成測試的層次三個級別：模塊內(nèi)集成測試；子系統(tǒng)內(nèi)集成測試；子系統(tǒng)間集成測試。集成測試的策略大爆炸集成方式（BigBang）首先對每個模塊分別進行單元測試，然后再把所有單元組裝在一起進行測試，最終得到要求的軟件系統(tǒng)。優(yōu)點大爆炸集成可以迅速完成集成測試，并且只要極少數(shù)的驅(qū)動和樁模塊設計。它需要的測試用例也是最少的；該方法比較簡單；多個測試人員可以并行工作，對人力，物力資源利用率較高缺點這種一次性組裝方式試圖在輔助模塊的協(xié)助下，在模塊單元測試的基礎上，將所測模塊連接起來進行測試。但是由于程序中不可避免地存在模塊間接口、全局數(shù)據(jù)結(jié)構(gòu)等方面的問題，所以一次試運行成功的可能性并不很大；在發(fā)現(xiàn)錯誤的時候，其問題定位和修改都比較困難；即使被測系統(tǒng)能夠被一次性集成，但還是會有許多接口錯誤很容易的躲過測試而進入到系統(tǒng)測試范圍內(nèi)。適用范圍一個維護型項目（或者能增強型項目），其以前的產(chǎn)品已經(jīng)很穩(wěn)定，并且新增的項目只有少數(shù)幾個組件被增加或修改；被測系統(tǒng)比較小，并且它的每個函數(shù)都經(jīng)過了充分的單元測試。自頂向下集成方式（Top-Down）首先集中于頂層的組件，然后逐步測試處于底層的組件；廣度優(yōu)先策略和深度優(yōu)先策略優(yōu)點自頂向下的集成方式在測試過程中較早地驗證了主要的控制和判斷點如果選用按深度方向組裝的方式，可以首先實現(xiàn)和驗證一個完整的軟件功能功能可行性較早得到證實，還能夠給開發(fā)者和用戶帶來成功的信心最多只需一個驅(qū)動，減少了驅(qū)動器的開發(fā)的費用支持故障隔離，定位比較容易控制結(jié)構(gòu)得到較早驗證。缺點樁的開發(fā)和維護是本策略的最大成本；底層組件行為的驗證被推遲了；隨著底層組件的不斷增加，整個系統(tǒng)越來越復雜，導致底層組件的測試不充分，尤其是那些被重用的組件。適用范圍產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定；產(chǎn)品的高層接口變化比較?。划a(chǎn)品的底層接口未定義或經(jīng)?？赡鼙恍薷?；產(chǎn)品的控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能夠看到產(chǎn)品的系統(tǒng)功能行為。自底向上集成測試策略（Bottom-up）從程序結(jié)構(gòu)的最底層的組件開始組裝和測試。對于一個給定層次的組件，它的子組件（包括子組件的所有下屬組件）已經(jīng)