ACCP软件测试课件

軟體品質保證2開場白世界上不存在沒有缺陷的軟體。可以通過兩種途徑開發出沒有錯誤的軟體：在一開始就防止引入錯誤。識別潛藏在代碼中的錯誤，找到並消滅它們。3什麼是軟體品質軟體品質是軟體產品滿足使用要求的程度。對於軟體品質的衡量，就是高質量的軟體系統能夠準時地交付給用戶，所耗費的成本不超出預算，並且最重要的是，能夠正常地運行。“正常地運行”意味著該軟體必須盡可能沒有缺陷(bug)。理解：軟體需求是品質度量的基礎，與需求不符就是品質不高完成的成本和完成的時間都應該在計畫範圍內開發出的軟體產品應該是可靠的和可維護的4軟體品質保證(SQA)品質保證是一個活動，它向所有有關的人提供證據以確立品質功能正在按需求運行的信心。軟體品質保證是一系列系統性的活動，它提供開發出滿足使用要求產品的軟體過程的能力證據。5軟體開發各個階段SQA的目標6-1需求分析：確保客戶所要求的系統是可行的。確保客戶指定的需求確實能夠滿足他的真正

要求。避免开发者和客户之间的误解。向用戶提供為滿足他所提出的需求而實際構建的適當軟體系統。6軟體規格說明：通過建立需求跟蹤文檔，確保規格說明書與系統需求保持一致。確保規格說明書能適當地改進系統的靈活性、可維護性以及性能。確保已建立了測試策略。確保已建立了現實的開發進度表，包括

預定的評審。确保已为系统设计了正式的变更规程。軟體開發各個階段SQA的目標6-27軟體開發各個階段的SQA目標6-3設計：確保已建立用於描述設計的標準，並且確保遵循這些標準。確保適當地控制並用文檔記錄對設計進行的變更。確保在系統設計組件已按照商定的準則得到批准之後才開始編碼。確保對設計的評審按照進度進行。8軟體開發各個階段的SQA目標6-4編碼：確保代碼遵循已建立的風格、結構和文檔標準。確保代碼經過適當測試和集成，同時對編碼模組的修改得到適當的標識。查看代碼編寫是否遵循既定的進度。確保代碼評審按照進度進行。9軟體開發各個階段的SQA目標6-5測試：確保測試計畫的建立和遵循。確保創建的測試計畫能夠滿足所有系統規格說明書的要求。確保經過測試和返工後軟體與規格說明書保持一致。10軟體開發各個階段的SQA目標6-6維護：確保代碼和文檔的一致性。確保對已建立的變更控制過程進行監測，包括將變更集成到軟體的產品版本中的過程。確保對代碼的修改遵循編碼標準，並且要對其進行評審，不要破壞整個代碼結構。11實施品質管理品質管理的發展和趨勢品質管理體系建立品質計畫品質保證品質控制的輸入品質控制的手段和技巧品質控制的輸出12品質管理發展五個階段1900手工操作者專職檢驗員1920過程統計技術1931全面品質管理19602000以顧客為中心階段時間13品質管理發展趨勢核心：由對結果的檢驗轉向對過程精細的控制改變：－管理範圍的改變：由針對以產品生產製造服務品質管理擴大到行政部門工作品質。－關注焦點的轉移：

由面向以產品生存週期的服務品質管理轉向顧客滿意為中心品質管理。14軟體產業要經歷三個不同時代結構化生產時代(70年代中期至90年代中期)：結構化分析；結構化設計；結構化程式設計；結構化測試；結構化審查與走查。以過程為中心的時代(從80年代中期至2010年前後)：寓品質和效率於生產過程之中；關於軟體過程的主要流派(ISO9000，CMM)。軟體工業化生產時代(1995年開始)：基礎技術(軟體過程技術，面向對象技術，基於構件的開發技術)；主要問題(標準化，產業文化，政策法規)；對前途的估計(我國2005年可以進入軟體工業化生產時代)。15專案品質管理總覽圖16專案品質管理定義專案品質管理品質管理需要保證整個專案都要滿足設計時的需要專案品質管理包括了所有的活動，這些活動決定了品質策略、品質目標和責任。而這些都需要被品質計畫、品質控制、品質保證和品質改進等活動完成。17專案品質管理的核心過程三個核心過程:品質管理–確認品質標準是關於專案目的、專案管理者、專案使用者這方面決定的品質保證–評估整個專案滿足相關的品質要求品質控制–監控記過符合相應品質標準，可以進行檢查，滿足專案管理者以及整個專案組的要求18制定品質計畫品質計畫描述相關品質標準並且說明如何滿足相應標準輸入品質計畫品質策略–一個組織中有關管理層對於品質的定義和方向範圍描述產品說明標準和規則其他過程輸出–其他領域的相關知識19品質計畫的手段和技巧2-1品質計畫的工具和技巧效益成本分析–考慮市場，就意味著減少返工;成本是與品質管理活動有關的費用基本水準標準–比較實際或者計畫中其他專案實施中的情況流程圖因果圖20品質計畫的手段和技巧2-2系統或程式流程圖

試驗設計–一種分析技巧，有助於鑒定哪些變數對整個專案的成果產生最大的影響21品質計畫的輸出品質計畫的輸出品質管理計畫–說明專案管理小組如何具體執行它的品質策略;操作性定義–用非常專業化的術語描述各項操作規程的含義，以及如何通過品質控制程式對它們進行檢測。審驗單–用以證明一系列步驟是否已經得到貫徹實施對其他程式的輸入–可以在其他領域提出更長遠的要求22品質計畫中的輸出總覽圖23品質保證品質保證為了提供信用，證明專案將會達到有關品質標準，而在品質體系中開展的有計畫、有組織的工作活動品質保證的輸入品質管理計畫品質控制結果操作性定義24品質保證的手段和技巧品質保證的手段和技巧品質計畫的手段和技巧品質審查–品質審查是對其他品質管理活動的結構性復查品質保證的輸出品質改進–品質提高包括採取措施提高專案的效益和效率，為專案相關人員提供更多的利益25品質控制品質控制–包括監控特定的專案成果，以判定它們是否符合有關的品質標準，並找出方法消除造成專案成果不令人滿意的原因。預防（不讓錯誤進入專案程式）和檢驗（不讓錯誤進入客戶手中）靜態調查（其結果要麼一致，要麼不一致）和動態調查（其結果依據衡量一致性程度的一種持續性標準而評估）確定因素（非常事件）和隨機因素（正態過程分佈）誤差範圍（如果其結果落入誤差範圍所界定的範圍內，那麼這個結果就是可接受的）和控制界限（如果其成果落入控制界限內。那麼該專案也在控制之中。）26品質控制總覽圖 27品質控制的輸入品質控制的輸入專案成果–包括程式運行結果和生產結果品質管理計畫操作性定義審查單28品質控制輸入圖29品質控制的手段和技巧2-1檢驗－包括測量、檢查和測試等活動，目的是確定專案成果是否與要求相一致控制表－控制表是根據時間推移對程式運行結果的一種圖表展示。排列圖－是一種直方圖，由事件發生的頻率組織而成，用以顯示多少成果是產生於已確定的各種類型的原因的。如下圖。30品質控制的手段和技巧2-2抽樣調查統計流程圖趨勢分析31品質控制的輸出品質控制輸出品質提高可接受的決定（接受/拒絕）返工–返工是有缺陷的、不符合要求的產品變為符合要求和設計規格的產品的行為。完成後的審驗單程式的調整－程式的調整指作為品質檢測結果而隨時進行的糾錯和預防行為。32簡介軟體測試是軟體工程過程中的關鍵組件。軟體測試是軟體品質保證的要素，可以將其描述為一個運行程式以檢測錯誤（如果有）的過程。33測試的常識與道理2-1編程大師說：沒有錯誤的程式世間難求。（《編程之道》）你在學校裏學過測試嗎？（讀到博士可能也不懂測試）你所在的企業重視測試嗎？（小公司程式員的技能更加全面）臨時抱佛腳行嗎？你以為有文檔範本就會測試了嗎？

34測試的常識與道理2-2如果不懂得有效地進行測試，你不僅得不到功勞，也沒人欣賞你的苦勞，你擁有最多的將只是疲勞。職業軟體工程師應當掌握需求開發、系統設計、編程、測試、維護所有技能。35測試的目的是什麼測試的目的是為了發現盡可能多的缺陷，不是為了說明軟體中沒有缺陷。推論：成功的測試在於發現了迄今尚未發現的缺陷。所以測試人員的職責是設計這樣的測試用例，它能有效地揭示潛伏在軟體裏的缺陷。千萬不要將“測試”與“演示”混為一談。例如科研鑒定會。如果產品通過了嚴格的測試，大家不要不吭氣，應當好好地宣傳一把。36軟體測試原則2-1完全測試程式是不可能的－輸入量太大－輸出結果太多－軟體實現途徑太多－軟體說明書沒有客觀標準。從不同角度看，軟體缺陷的標準不同。37軟體測試原則2-2軟體測試是有風險的行為測試無法顯示潛伏的軟體缺陷找到的軟體缺陷越多，就說明軟體缺陷越多並非所有軟體缺陷都能修復軟體測試一項講究條理的技術專業38軟體測試方法－黑盒和白盒白盒測試中（有時候稱為開盒測試），軟體測試員可以訪問程式員的代碼，並通過檢查代碼來協助測試－可以看到盒子裏面。一般在單元測試中採用白盒測試，用於測試模組中所有可能的路徑、執行所有迴圈並測試所有邏輯運算式。黑盒測試則側重於軟體的整體功能。它不基於程式的內部結構而基於系統功能。猶如一個人站在黑盒子外面，只知道系統輸入一定數據，得到一定的輸出，而不必清楚這個黑盒子中進行了哪些操作和運算。39軟體測試方法－靜態和動態靜態檢查確保系統按照組織的標準和過程運行，主要依賴於評審和非運行的手段來檢查。通常包括需求評審、設計評審、代碼走查和代碼檢查。動態檢查在生命週期中進行測試（運行）。通常包括單元測試、集成測試、系統測試、用戶的驗收測試。40靜態測試審查(Inspection)－軟體的一種基本測試方法，它以一系列典型問題為依據進行檢測。走查(Walkthrough)

－一對一的審查，比審查更加仔細。回顧(Review)－以發現軟體中存在的錯誤和缺陷為目的的一種軟體測試方法，它是在軟體證實執行之前完成。41靜態和動態測試進行結構和功能測試測試階段執行人靜態校驗動態校驗可行性評審開發人員，用戶√需求評審開發人員，用戶√設計評審開發人員√單元測試開發人員√集成測試開發人員，用戶√系統測試開發人員在用戶的協助下完成√驗收測試用戶√42測試技術43測試產品說明書對於產品說明書的制定是個很重要的設計階段，產品說明書的品質會直接影響到整個產品開發。測試產品說明書屬於靜態黑盒子測試。44常用測試用語－測試用例測試用例：編寫用於輸入輸入的實際數制和預期結果。測試用例還明確指出使用具體測試用例產生的測試程式的任何限制。使用目的：測試用例應該設計為能夠快速容易地發現盡可能多的錯誤。應該通過使用和產生正確和錯誤的輸入和輸出來“檢驗”程式。其目標是要使用合理範圍內的條件，盡可能全面地測試所有模組乃至整個系統。45測試與調試－什麼是缺陷缺陷：最終產品同用戶的期望不一致缺陷的分類錯誤遺漏超出需求的部分缺陷（未觸發）VS.錯誤（應首先解決）46測試與調試－調試的準則調試的方法：歸納法、演繹法和回溯法。常用調試技術使用診斷輸出語句(diagnosticoutputstatement)、快照轉儲(snapshotdump)以及跟蹤指令的中斷點(instruction-dependentbreakpoint)。47測試的分類與比較開發與測試的V型關係如果軟體開發過程採用嚴格的瀑布模型，那麼開發與測試有“V”型的對應關係。需求開發

高層設計詳細設計編程單元測試集成測試系統測試驗收測試48測試階段2-1單元測試、集成測試、系統測試、驗收測試。是“從小到大”、“由內至外”、“循序漸進”的測試過程，體現了“分而治之”的思想。單元測試的粒度最小，一般由開發小組採用白盒方式來測試，主要測試單元是否符合“設計”。集成測試界於單元測試和系統測試之間，起到“橋樑作用”，一般由開發小組採用白盒加黑盒的方式來測試，既要驗證“設計”又要驗證“需求”。

49測試階段2-2系統測試的粒度最大，一般由獨立測試小組採用黑盒方式來測試，主要測試系統是否符合“需求規格說明書”。驗收測試與系統測試非常相似，主要區別是測試人員不同，驗收測試由用戶執行。50測試內容測試內容一般包含介面與路徑測試。功能測試、健壯性測試、性能測試、用戶介面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試…

51測試階段對應表測試階段

主要依據

測試人員、測試方式

主要測試內容

單元測試系統設計文檔由開發小組執行白盒測試

介面測試、路徑測試

集成測試系統設計文檔需求文檔由開發小組執行白盒測試和黑盒測試

介面測試、路徑測試功能測試、性能測試

系統測試需求文檔由獨立測試小組執行黑盒測試

功能測試、健壯性測試、性能測試、用戶介面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試

驗收測試需求文檔由用戶執行黑盒測試

52介面與路徑測試3-1介面測試：數據一般通過介面輸入和輸出，介面測試一般是白盒測試的第一步。

輸入參數有“典型值”、“邊界值”、“異常值”輸出包括函數的返回值和輸出參數。實際輸出與期望的輸出不一致，那麼說明程式有錯誤。一個函數體內的語句可能只有十幾條，但邏輯路徑可能有成千上萬條。所以應該根據經驗選擇關鍵的路徑測試。

53介面與路徑測試3-2路徑測試的檢查表－數據類型、變數值、邏輯判斷、迴圈、記憶體管理、檔I/O、錯誤處理預防一些重要的路徑沒有被測試的措施有：觀察是否有程式語句從來沒有被執行過。要特別留意函數體內的錯誤處理程式塊。54介面與路徑測試3-3介面與路徑測試用例的參考範本55功能測試3-1功能測試的基本方法是構造一些合理輸入（在需求範圍之內），檢查輸出是否與期望的相同。如果兩者不一致，即表明功能有誤。難點在於如何構造有效的輸入。56功能測試3-2功能測試的測試方法：等價劃分法和邊界值分析法。

等價劃分是指把輸入空間劃分為幾個“等價區間”，在每個“等價區間”中只需要測試一個典型值就可以了。等價劃分法來源於人們的直覺與經驗，可令測試事半功倍。“缺陷遺漏在角落裏，聚集在邊界上”。邊界值測試法是對等價劃分法的補充。如果A和B是輸入空間的邊界值，那麼除了典型值外還要用A和B作為測試用例。57功能測試3-3功能測試用例的參考範本58性能測試3-1性能測試即測試軟體處理事務的速度，一是為了檢驗性能是否符合需求，二是為了得到某些性能數據供人們參考。絕對值考慮：如數據送輸速率是每秒多少比特。“相對值”考慮：如某個軟體比另一個軟體快多少倍。性能測試中考慮運行環境的影響：例如網路環境、電腦主頻，匯流排結構和外部設備都可能影響軟體的運行速度。59性能測試3-2性能測試的一些注意事項：應當編寫一段程式用於計算時間以及相關數據。應當測試軟體在標準配置和最低配置下的性能。應當關閉那些消耗記憶體、佔用CPU的其他應用軟體（如殺毒軟體）。應當分檔記錄。例如傳輸檔的容量從100K到1M可以分成若干等級。同一種輸入情況在不同的時間可能得到不同的性能數據，可以取其平均值。

60性能測試3-3性能測試用例的參考範本61壓力測試2-1壓力測試也叫負荷測試，即獲取系統能正常運行的極限狀態。壓力測試的主要任務是：構造正確的輸入，使勁折騰系統卻讓它剛好不癱瘓。壓力測試的一個變種是敏感測試。在某種情況下，微小的輸入變動會導致系統的表現（如性能）發生急劇的變化。62壓力測試2-2壓力測試用例的參考範本63其他測試內容健壯性測試用戶介面測試資訊安全測試可靠性測試安裝和反安裝測試64問題1：有了“黑盒”測試為什麼還要“白盒”測試？問題2：由於單元測試要寫測試驅動程式，非常麻煩，能否等到整個系統全部開發完後，再集中精力進行一次性地單元測試呢？問題3：如果每個單元都通過了測試，把它們集成一起難道會有什麼不妥嗎？集成測試是否多此一舉？測試常見問題2-165測試常見問題2-2問題4：在集成測試的時候，已經對一些子系統進行了功能測試、性能測試等等，那麼在系統測試時能否跳過相同內容的測試?問題5：既然系統測試與驗收測試的內容幾乎是相同的，為什麼還要驗收測試？問題6：能否將系統測試和驗收測試“合二為一”？66總結2-1測試可以將測試描述為一個運行程式以發現錯誤的過程。軟體測試的準則:不完全測試、風險測試、無法顯示潛伏錯誤、發現錯誤成線性增長、缺陷不能完全修復、測試有條理規程測試的方法:黑盒/白盒、靜態/動態軟體測試的各個階段：單元測試、集成測試、系統測試、驗收測試67什麼是測試工具定義：輔助測試整個過程的工具軟體單元測試可以有兩種方式自己編寫代碼使用單元測試工具整個過程包括：靜態分析，測試計畫，測試設計，測試執行，測試缺陷跟蹤，測試報告和品質度量等68單元測試工具的種類單元測試工具的種類靜態分析工具代碼規範審核工具記憶體和資源檢查工具測試數據生成工具測試框架工具測試結果比較工具測試度量工具測試文檔生成和管理工具69自動測試工具自動測試工具好處速度和效率準確度和精確度耐性、不休息、可重複局限對軟體變更，尤其是代碼變更比較敏感先期的測試開發比較費時有些測試結果無法用工具比較和分析有些工具的腳本/代碼會使程式運行環境不純淨70使用自動測試工具的目的測試工具提高測試效率，節省測試成本測試設計提高測試效果，同時也可以提高測試效率，節省測試成本有些測試單靠手工很難完成壓力測試，模擬併發測試等多數的單元測試有些測試使用測試工具更合適回歸測試大量測試數據的生成、部分測試結果的比較缺陷管理和測試用例管理品質度量71如何引入自動測試工具3-1選擇自動測試工具是一個重要的步驟，所以一定要謹慎因為測試工作經常會涉及到管理流程和開發流程的改變、涉及到人員的考評標準，所以它有時會對整個企業產生影響。測試工具應該能夠管理測試過程和測試文檔，並生成各種測試報告。自動測試工具應該允許用戶把自動測試數據和流程與手工的測試數據和流程結合到一起。72如何引入自動測試工具3-2自動測試工具應該能夠將業務需求與測試計畫、測試設計和測試結果相關聯，允許最終用戶根據測試結果來評估應用程式的完成情況。自動測試工具中的各功能模組應該緊密集成到一起，共用和重用測試數據，支持回歸測試。工具應該可以很容易地利用過去的或者其他人員的測試資料。工具內部應該使用一致的腳本語言和數據格式。73如何引入自動測試工具3-3自動測試工具的體系結構和文件格式應該是開放的，可以很容易地與其他技術或工具進行交互和集成。自動測試工具廠商應該有比較完善的科室培訓和技術支持機制，能夠為自動測試工具的實施提供諮詢和支持。74Panorama產品內容產品背景及功能產品術語基礎應用原理及環境工具介紹OO-Test其他工具請按照上機安排操作75測試工具PanoramaPanorama-2C/C++是一個軟體測試工具。它也用來QA維護環境它運行在SunOS/Solaris和WindowsNT/95上，支持SunC、C++。76Panorama產品背景及功能3-1產品背景集成了8個產品/32個工具的軟體包，一般用於：1、新系統開發過程中的品質保證和單元測試；2、舊系統維護過程中品質保證與測試3、再工程中的系統分析77Panorama產品背景及功能3-278Panorama產品背景及功能3-3OO-Test：測試用例生成和管理：1、記錄和生成測試用例2、最小化測試用例集3、測試覆蓋分析OO-Browser：系統結構分析：1、生成系統中類和函數的繼承/調用關係圖2、實現代碼與關係圖的雙向對應和跳轉3、顯示系統結構測試覆蓋結果OO-Diagrammer：流程結構分析：1、生成控制流程圖、邏輯流程圖、代碼流程圖2、實現代碼與流程圖的雙向對應和跳轉3、顯示流程結構測試覆蓋結果OO-SQA：品質度量分析：1、設定品質度量標準和指標2、生成品質度量數據3、顯示品質度量結果OO-Analyzer：系統文檔生成：1、生成100多種設計文檔和品質文檔OO-Playback：GUI測試過程回放：1、捕獲並記錄測試過程2、回放測試過程3、比較回放結果OO-MemoryChecker：記憶體洩漏和非法使用檢測：1、檢測記憶體洩漏和非法使用2、記錄錯誤發生的語句位置3、生成檢測報告OO-DefectTracer：缺陷定位和追溯：1、檢測並記錄缺陷(包括死機)發生的路徑和語句位置2、生成缺陷定位報告79產品背景及功能產品功能應用：新系統開發支持舊系統維護支持系統再工程支持其他1、設計支持-系統結構/流程結構自動生成與維護-多重複雜性度量及分析-生成複雜性度量報告2、編碼及調試支持-確定編碼順序-保證編碼和設計的雙向對應-生成代碼邏輯結構-顯示測試路徑和頻率-顯示錯誤(尤其是意外中止)的語句位置和執行路徑3、測試支持-確定單元測試順序-生成並管理測試用例-執行測試用例並顯示結果-測試分析和度量-支持回歸測試-生成品質報告1、複雜性度量支持-多重複雜性度量及分析-生成複雜性度量報告2、代碼修改支持-系統結構/流程結構自動生成與維護、編碼和設計的雙向對應、錯誤定位和追溯-加強代碼理解、避免修改的副作用-幫助代碼靜態分析技術的實施3、測試支持-確定單元測試順序-生成並管理測試用例-執行測試用例並顯示結果-測試分析和度量-支持回歸測試-生成品質報告1、系統設計分析-系統結構/流程結構自動生成與維護，加強設計理解-編碼和設計的雙向對應，加強代碼理解2、系統複雜性分析-多重複雜性度量及分析-生成複雜性度量報告3、系統性能分析-分析模組執行性能和執行瓶頸4、文檔報告生成-生成多種系統分析報告和品質報告1、支持工程管理和進度估算-代碼檔和設計文檔的一致性維護-多種度量分析方法2、訓練專案組新進人員-理解系統結構和流程結構-方便閱讀和理解代碼3、支持驗收評估-自動生成設計和編碼文檔-自動生成測試分析報告-自動生成品質度量報告80產品術語基礎2-1基本概念1、塊，也叫基本段、可視段2、不可視段基本不可視段：if,switch高端迴圈邊界(執行0次循環體)低端迴圈邊界(執行1次循環體)3、段，也叫標準段包括可視段與基本不可視段4、增強段包括可視段和不可視段81產品術語基礎2-2品質保證度量規範1、代碼可讀性度量2、複雜性度量3、測試覆蓋度量IEEE度量標準1、環形複雜性2、測試覆蓋度量1、程式行數2、代碼行百分比3、注釋行百分比4、空格間隔行百分比1、環形複雜性2、塊測試複雜性JC03、段測試複雜性JC14、增強段測試複雜性JC1+5、條件段測試複雜性JC26、繼承樹深度DIT7、子類數目NOC8、類耦合數目CBO9、類中方法數目10、類中回應方法數目RFC

11、使用類中方法的函數數目12、類中重用基類代碼行數13、類中重用基類代碼百分比1、塊測試覆蓋SC02、段測試覆蓋SC13、增強段測試覆蓋SC1+4、J-覆蓋5、條件真覆蓋6、條件假覆蓋7、總條件覆蓋8、分支覆蓋1、定義：-環形複雜性C-區域數目RG-邊數目E-節點數目N-分支節點數目SN2、計算公式：-C=RG-C=E-N+2-C=SN+11、原語-程式-功能-數據-需求-測試用例2、測試覆蓋TC計算公式：-TC=((測試的需求原語數目)/(需求原語總數))*((測試的程式原語數目)/(程式原語總數))82應用原理與環境2-1使用流程.mak檔是C/C++編譯檔.hsi檔是Panorama內部使用的輸入緩衝區檔，用於記載C/C++檔結構資訊.dbs檔是Panorama內部使用的資料庫檔，用於記載C/C++檔分析和測試結果資訊，一般與his檔配合使用83應用原理與環境2-2應用原理84工具的局限性局限性1、中文顯示問題2、使用自己的腳本技術，但這種腳本技術與其他的測試工具不相容3、需要執行.mak檔，而不是編譯C程式後生成的.obj檔4、僅能處理C/C++程式5、介面不夠友好85OO-Test2-1輸出結果測試用例最小集合測試結果分析數據作用：生成並管理測試用例最小化測試用例集測試結果記錄和分析86OO-Test2-2生成並保存測試用例加載測試用例執行測試用例測試結果分析測試覆蓋結果測試用例效率最小化測試用例集87基本測試過程 基本測試過程原則：儘早測試、經常測試、充分測試。開發過程與測試過程：分析、測試、設計、測試、編碼、測試。測試計畫應該是按照開發者的要求並用具體例子來描述一個測試計畫的層次結構以及各個測試計畫相聯系的標準模版。88測試的五個問題誰執行了測試？測試什麼？什麼時候測試？怎樣測試？測試應進行到何種程度？89測試方案設計良好的測試設計由以下的若干個方面組成：測試策略測試計畫測試說明書測試規範這些方案適用於從單元測試到系統測試等各個級別的測試。測試設計需要根據軟體說明書來進行。90單元測試2-1概況定義：檢驗程式最小單位有無錯誤。一般在編碼之後，由開發人員完成。單元：軟體開發中的最小的獨立部分C語言中的單元：函數或者是子過程C++語言中的單元：類91單元測試2-2單元測試目前狀況：實施效果非常好，但是實施阻力比較大(主要是人員和管理因素)，一般只在關鍵的程式單元中實施有比較系統的理論和方法，但也依賴於系統的特殊性和開發人員的經驗有大量的輔助工具，開發人員也經常自己開發測試代碼和測試工具主要使用白盒測試和靜態分析，也使用黑盒測試92單元測試流程管理流程主要指動態測試應用流程測試計畫測試設計測試執行測試記錄分析測試總結完畢缺陷跟蹤針對測試目標，規定測試任務、資源分配、人員角色、進度安排等。根據測試計畫，設計測試用例，包括：測試步驟、測試場景、測試代碼、測試數據(包括預期結果)。根據測試計畫，配置測試環境，並手動或者自動執行測試設計。根據測試計畫，忠實地記錄測試執行的過程和結果。分析測試記錄，如果發現與預期結果不同，確定並重現缺陷。檢查測試設計是否全部執行完畢，缺陷是否全部關閉。記錄、分發、評估、關閉缺陷報告。分析測試過程和缺陷報告，評估測試品質和測試效果，給出是否通過測試的建議。93測試用例2-1測試用例是數據輸入和期望結果組成的對。軟體中有許多錯誤用戶遇到的錯誤只占很小比例應該針對用戶最容易遇到的錯誤進行測試，以便改進測試的有效性94測試用例2-2ANSI/IEEE829標準列出了測試用例應該包含在內的重要資訊：識別字測試項輸入說明輸出說明環境要求特殊要求用例依賴性95單元測試說明書的組成單元測試說明書由一系列單元測試用例組成。每個單元測試用例都應該包括四個基本要素（對照ANSI/IEEE標準）：單元的初始狀態說明單元的輸入測試用例實際要測試的內容測試用例的預期結果96單元測試說明書(例)－測試計畫編號如：stb-tp0013標題如：文字排版功能.字間距.MayCourse版本號如：V1.0執行狀態如：未執行修改記錄如：2003年7月28日；××編制/修改；原因測試目標如：語句覆蓋測試人員如：××1負責執行測試用例xxx；××2負責執行測試用例xxx測試用例編號(多個)如：stb-fg00021/stb-fg00031/stb-fg00035…被測試單元代碼位置如：$tag1/layout/MayCourse.cpp97單元測試說明書(例)－測試用例編號如：stb-tp00014標題如：測試“文字排版功能.字間距.MayCourse”版本號如：V1.3執行狀態如：已經執行修改記錄如：2003年7月29日；××編制/修改；原因測試步驟如：配置運行環境；輸入測試數據；執行X功能/測試代碼；觀察/記錄XX測試場景如：在聯網的環境下測試代碼如：stb-tp00021(位置)/stb-tp00035(位置)…測試數據如：輸入數據(輸入檔、文字描述…)；預期結果(性能、圖片、文字描述…)98單元測試說明書(例)－測試記錄編號如：stb-tp00015標題如：記錄測試“文字排版功能.字間距.MayCourse”結果填寫記錄如：2003年7月30日；××填寫；原因測試用例編號如：stb-tp0015輸出結果如：圖片、文字描述測試觀察符合/不符合期望結果99單元測試說明書(例)－缺陷跟蹤報告編號如：stb-tp00016標題如：文字排版功能.字間距.MayCourse計算錯誤版本號如：V1.3執行狀態如：空白/草稿/提交/審批/分發/正在修改/修改完畢/正在確認/關閉…修改記錄如：2003年7月31日；××編制/修改；原因測試環境和版本號碼、程式編寫人員錯誤嚴重程度和優先順序別錯誤詳細描述重現步驟和方式、對應的測試記錄編碼附件建議修改方式修改內容、結果及修改人員簽字/日期確認內容、結果及確認人員簽字/日期100單元測試說明書(例)－總結報告

編號如：stb-tp00017標題如：文字排版功能.字間距.MayCourse單元測試總結報告版本號如：V1.5執行狀態如：已經提交修改記錄如：2003年8月1日；××編制/修改；原因測試計畫編號計畫執行情況缺陷統計(缺陷總數/未解決數目)及為解決缺陷列表後續處理措施是否通過單元測試101制定單元測試說明書步驟包含一組單獨的單元測試用例的單元測試說明書的設計過程：步驟1－運行簡單測試用例步驟2－正面測試步驟3－負面測試步驟4－考慮特殊事項步驟5－覆蓋完成率測試步驟6－完善說明書，進行相對完整測試102測試用例設計技術測試用例設計技術可以大體分成兩個主要類別：黑盒技術使用的是單元的介面和對功能的描述，而無需知道單元內部是如何構建的。白盒技術使用的是有關單元內部如何工作的資訊。此外還有其他的技術，它們都不能歸入上面的類別中，例如錯誤猜測。103黑盒測試測試手段2-1根據說明書進行的測試測試用例是通過通讀相關的說明書而設計得到的。

每個測試用例都應該測試說明書的一條或多條陳述。等价划分基本做法是將要測試的軟體的輸入和輸出分成若干部分，對於特定部分中的任意值，軟體行為都是等價的。104黑盒測試測試手段2-2邊界值分析它使用與等價劃分相同的方法分析各個部分。但是，它假定錯誤最可能出現在各部分之間的邊界處。狀態變換測試當軟體被設計成狀態機或者軟體實現的是以狀態機為模型的需求的時候，狀態變換測試特別有用。測試用例通過生成導致轉變的事件來測試

狀態之間的轉換。105白盒測試測試手段2-1分支測試測試用例被設計為檢驗對單元中的流分支或判定點的控制。通常來說它的目的是要達到目標級別的判定覆蓋率。條件測試條件測試的目標是設計測試用例以表明邏輯條件的單個組件和單個組件的組合是正確的。106白盒測試測試手段2-2數據定義－使用測試它將測試用例設計為對成對的數據定義和使用進行測試。設置資料項目的值的地方就是數據定義，讀取或使用數據的地方就是數據使用。次邊界值測試很多情況下，各部分和它們的邊界可以通過單元功能說明書來識別。但是，單元可能會有內部邊界值，它只能

通過結構說明書來識別。107錯誤猜測錯誤猜測主要是憑經驗，同時還需要諸如邊界值分析等其他技術的一些輔助。憑藉經驗，測試設計者猜測特定類型的軟體中可能出現的錯誤類型，並設計測試用例來找到它們。由有經驗的工程師來進行錯誤猜測可能是最有效地設計能發現錯誤的測試的唯一方法。相反，任用不合適的人來進行錯誤猜測可能會浪費時間。簡介測試全貌：測試計畫、實際測試和寫測試報告度量是軟體工程過程的一個關鍵要素。度量標準用於理解所創建的模型的屬性。監視測試覆蓋率對於測試結果的評價，需要監視測試覆蓋率。要減少要測試的條件的數量，可以將系統分成多個獨立的部分。這樣可以為代碼測試的各個部分分別生成不同的條件組合。邏輯覆蓋測試方法4-1語句覆蓋

選擇足夠的測試用例，使得程式中每一條可執行語句至少被執行一次。判定覆蓋

選擇足夠的測試用例，使得程式中每一個分支判斷的每一種可能結果(主要指switch-case情況)都至少被執行一次。判定覆蓋也叫分支覆蓋。條件覆蓋

選擇足夠的測試用例，使得程式中每一個分支判斷中的每一個條件的可能結果都至少被執行一次。邏輯覆蓋測試方法4-2判定/條件覆蓋選擇足夠的測試用例，使得同時滿足判定覆蓋和條件覆蓋。條件組合覆蓋選擇足夠的測試用例，使得程式中每一個分支判斷中的每一個條件的每一種可能組合結果都至少被執行一次。路徑覆蓋選擇足夠的測試用例，使得程式中所有的可能路徑都至少被執行一次。邏輯覆蓋測試方法4-3語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋路徑覆蓋邏輯覆蓋測試方法4-4需要完成的各種測試包括：單元測試集成測試系統測試驗收測試回歸測試在驗收和回歸測試後，對於覆蓋率測試達到一定標準後，我們即發佈軟體。測試覆蓋率涉及的測試什麼是缺陷？缺陷可以定義成：沒有實現預定的使用需求或合理期望與規格說明書或標準存在偏差在與標準的一致性方面導致客戶不滿的任何問題為什麼需要缺陷管理？客戶期望以較少的時間/成本獲得較高的品質。規格說明書在專案開發生命週期的後期往往會被修改。測試所發現的缺陷常常會招致大量的軟體開發成本。新的開發方法、工具不斷地實現。軟體管理不能讓測試成為瓶頸並減慢開發速度。測試需要快速、靈活和可靠。我們需要有關測試充分性的證據。缺陷的生命週期缺陷管理——Defect級別致命性缺陷（Critical）數據丟失，數據計算缺陷、系統崩潰和非常死機嚴重功能性缺陷(Serious)規定的功能沒有實現或不完整、設計不合理造成性能低下，影響系統的運營警告性缺陷(Moderate)不影響業務運營的功能問題建議性缺陷(Suggestion,Cosmetic)軟體設計和功能實現等不甚合理之處提出建議

缺陷管理——修改的優先順序高優先順序中優先順序低優先順序缺陷管理——缺陷描述1分配給缺陷的ID號2提交缺陷的時間3缺陷提交人4版本號發生缺陷的子系統或模組5缺陷發生的條件6對缺陷的詳細描述7所使用的測試用例號8缺陷被發現的資料庫9使用的機器號10缺陷的重要性11缺陷的改正優先順序12發生缺陷的子系統或模組及相關的模組13缺陷是否易再現14其他缺陷管理——與缺陷跟蹤有關项1缺陷負責人6缺陷改正後需要重新做的測試2嚴重性7改正缺陷所影響的組件3優先順序8目前缺陷的狀態4估計改正缺陷的日期9缺陷類別5估計改正缺陷所要花費的時間10解決辦法缺陷管理——缺陷分發對象專案管理者測試管理者被分配修改缺陷的人組件代碼的編寫人測試小組中的其他成員缺陷管理的實現階段2-1這些階段如下所示：缺陷標識、記錄和報告缺陷的消除和跟蹤缺陷測量和根由分析缺陷預防/過程改進軟體開發生命週期所有階段的測試安裝測試工具缺陷管理的實現階段2-2缺陷管理問題包括：缺陷遺漏同類缺陷重複精力分散效率低資料庫更新不完全分類不嚴謹-每個缺陷都被劃分為缺陷的類型用來攻擊專案分類的缺陷數據很多不負責任的缺陷重置是一個瓶頸相同的缺陷捲土重來缺陷狀態資訊缺陷狀態資訊應該包含下列資訊：缺陷的當前狀態和狀態歷史記錄描述狀態歷史記錄，包括描述日期、操作、執行者、實際工作量、結果狀態和指定的下一個步驟的行。下一個步驟估計需要付出的努力完成的期望日期缺陷分析和度量缺陷生命週期分佈有助於深入瞭解缺陷結束

所花天數、修復缺陷所需付出的努力和進度分析对预计付出的努力相对于实际付出的努力的分析缺陷報告3-1進行缺陷報告前執行的過程：獲取空白的缺陷表格指定可用的資訊資訊可用時不斷更新對缺陷資訊進行分類，包括一般資訊缺陷檢測資訊缺陷消除資訊狀態資訊估計要投入的努力、預計日期、實際

日期以及缺陷在其整個生命週期中的變化。所需的缺陷資訊有：有關缺陷性質、它的修復優先順序等的基本資訊；描述-簡要的文字優先順序（緊急、普通、不急）[您的優先順序，客戶的優先順序]嚴重程度（主要、次要、不嚴重）[您的優先順序，客戶的優先順序]原因關鍵字（用於進一步分析）症狀（資料庫損壞、可視數據缺陷、

介面缺陷、等等）缺陷報告3-2起源的階段找到的階段報告的數據期望和實際的結束日期描述版本、日誌、週期、過程、用例-發現缺陷的地方報告者：（姓名、公司）硬體操作系統-發現缺陷的平臺測試位置附件/附加資訊缺陷報告3-3缺陷報告（印）總結2-1度量是軟體工程過程的一個關鍵要素。可以在源代碼中插入語句以收集程式數據，例如計算每個分支的每一側被遍曆了幾次，或者每一段代碼是否都被執行過，執行了幾次。測試覆蓋率是對最後的測試結果提供度量的信任標準。理解缺陷的定義和測試過程中對缺陷管理的必要性131簡介“能力成熟度模型”是SEI在1986年開發的過程，用於改善組織的軟體技術的應用過程。這個過程分為五個定義良好的順序提高的等級：初始級可重複級已定義級已管理級優化級132CMM的產生背景當今的軟體組織工作在一個競爭和變化日益加劇的環境中。成功的軟體組織通過為現有產品開闢新的市場或滿足新的需求來積極有效地面對變化。許多公司面對變化沒能採取主動有效的措施，而被其產品開發工作的缺乏控制所牽掣。許多公司不能夠正確地預測、控制和改進

特定產品或合同的利潤空間、產品

装运日期或产品质量。133CMMCMM是設計用來幫助組織解決這些問題的。CMM提供了一種有效的和可驗證的方法，用以不斷地加強對產品開發過程的控制，並改進產品開發過程。CMM提供了一個尺規，使組織能夠根據該尺規對其生產過程進行定期的測量，也提供了進行優化及管理改進工作的數據。CMM描述了軟體特有的產品開發實踐和

所有組織必須遵守的通用管理實踐。134SECATSECAT支持應用於行業中的大部分主要的CMM模型，特別是：集成產品開發能力成熟度模型(IPD-CMM)軟體能力成熟度模型(SW-CMM)軟體獲取能力成熟度模型(SA-CMM)系統工程能力成熟度模型(SE-CMM)EIAI/S731：系統工程能力模型(SECM)系統安全工程能力成熟度模型(SSE-CMM)135CMM等級1361級：初始級2-1開發團隊對每個專案採用不同的處理方式。可能取得巨大的成功，但以後可能不會成功。某些時間/成本估算是準確的，但大多數估算與實際相去甚遠。成功依賴於傑出的人員和他們的努力。1371級：初始級2-2傑出的人員離開後，很難再次獲得成功。經常出現危機和緊急修改工作。（許多人認為這是軟體開發過程中不可避免的。但是CMM不這樣認為。）大多數的軟體開發組織處於1級。1382級：可重複級3-1紀律化的過程用於管理軟體專案的方針和實施這些方針的規程都已制定。專案級想法，可造，類似專案成功經驗可重用。1392級：可重複級3-2軟體專案標準均已確定，並且組織能保證切實地執行這些標準。如果有分包商的話，軟體專案人員與他們一起努力，建立牢固的顧客-供應商關係