軟件測試培訓資料課件

軟件測試培訓資料軟件測試培訓資料1內(nèi)容軟件測試理論基礎軟件測試流程軟件項目運作流程軟件測試工作流程軟件測試用例設計方法軟件缺陷測試的技巧測試工具的選擇軟件的測試整個過程內(nèi)容軟件測試理論基礎2軟件測試理論基礎軟件測試理論基礎3測試行業(yè)簡介軟件測試在軟件生命周期中占據(jù)重要作用。軟件生命周期的每個階段都應該包含測試從而檢驗本階段的成果是否接近預期的目標，盡可能早的發(fā)現(xiàn)錯誤并加以修正。由于測試的重要性和復雜度，它慢慢的獨立發(fā)展成為一個行業(yè)，并且在迅猛發(fā)展。在典型的軟件開發(fā)項目中，軟件測試工作量往往占軟件開發(fā)總工作量的40％以上。而在軟件開發(fā)的總成本中，用在測試上的開銷要占30％到50％測試行業(yè)簡介軟件測試在軟件生命周期中占據(jù)重要作用。4軟件測試概論（概述）1975年，“測試數(shù)據(jù)選擇的原理”（TowardatheoryofTestData）的文章，軟件測試才被確定為一種研究方向。1979年，“軟件測試時為發(fā)現(xiàn)錯誤而執(zhí)行一個程序或者系統(tǒng)的過程”1983年，“測試是以評價一個程序或者系統(tǒng)屬性為目標的任何一種活動，測試是對軟件質(zhì)量的一種度量”。2002年，“測試是為了度量和提高被測試軟件的質(zhì)量，對測試軟件進行工程設計、實施、維護的的整個生命周期過程”。軟件測試概論（概述）1975年，“測試數(shù)據(jù)選擇的原理”（To5軟件測試概論（行情）國外：A、軟件測試在軟件公司中占有重要的地位B、軟件測試理論研究蓬勃發(fā)展，引領軟件測試理論研究的國際潮流C、軟件測試市場繁榮國內(nèi)：1、我國著名的軟件公司都已經(jīng)或者正在建立獨立的專職軟件測試隊伍2、國家開始對軟件測試職業(yè)高度重視和認可（軟考中級資格中增加軟件評測師）軟件測試概論（行情）國外：6軟件測試概論（行情）3、用戶對軟件質(zhì)量要求越來越高，通過第三方測試機構的嚴格測試來判定4、市場需求量不斷增大，軟件測試工程師的待遇也在不斷提高。北京地區(qū)的薪資趨勢大致如圖1-1所示。圖1-1薪資趨勢圖軟件測試概論（行情）3、用戶對軟件質(zhì)量要求越來越高，通過第三7測試工程師的職業(yè)發(fā)展軟件測試工程師一般有幾個方向可走，如圖1-2所示。一個理想的測試工程師應該有開發(fā)經(jīng)驗，至少要有開發(fā)的概念。僅僅發(fā)現(xiàn)Bug是測試的初步，而分析出根本原因，卻要有很深的功底。初級測試工程師中級測試工程師開發(fā)工程師測試管理者高級測試工程師圖1-2職業(yè)發(fā)展規(guī)劃圖測試工程師的職業(yè)發(fā)展軟件測試工程師一般有幾個方向可走，如圖18企業(yè)需要怎樣的測試人才？一年以上軟件測試經(jīng)驗計算機相關專業(yè)大專以上學歷了解軟件工程，熟悉軟件測試過程和標準，熟悉配置管理技術和工具能夠編制測試計劃、設計測試用例、編寫B(tài)ug報告和測試總結報告、使用測試工具、開發(fā)測試腳本熟練使用Windows或Unix或Linux操作系統(tǒng)企業(yè)需要怎樣的測試人才？一年以上軟件測試經(jīng)驗9企業(yè)需要怎樣的測試人才？熟練C、C++、Java、VB、Delphi、C#中的一種以上熟練使用SQLServer或Oracle數(shù)據(jù)庫了解業(yè)務領域（ERP、OA、電子商務、稅務系統(tǒng)、電信計費系統(tǒng)……）熟練掌握至少一種以上的測試工具，如TestDirector、QTP、LoadRunner、Robot進取、合作、表達、溝通、責任心、耐心、認真程度企業(yè)需要怎樣的測試人才？熟練C、C++、Java、VB、De10測試學習路線對于軟件測試初學者，我們要切合實際、循序漸進的學習，在學習中可參考圖1-3所示的軟件測試學習路線圖，從軟件測試的理論基礎，到項目實戰(zhàn)，逐步學習，掌握技術技能，最終勝任軟件測試工作。初學者軟件測試理論基礎學習缺陷管理知識學習Web測試環(huán)境搭建學習Linux操作系統(tǒng)知識學習配置管理知識學習數(shù)據(jù)庫知識學習QTP功能測試工具學習LoadRunner性能測試工具學習項目實戰(zhàn)崗前培訓面試技巧工作圖1-3軟件測試學習路線圖測試學習路線對于軟件測試初學者，我們要切合實際、循序漸進的學11軟件測試由來調(diào)試在已知錯誤的情況下，對軟件程序代碼做出的一系列檢查，校正的過程。測試

在未知錯誤的情況下，檢查程序代碼是否有問題的過程。區(qū)分：軟件測試從軟件質(zhì)量保證的角度來檢查程序代碼是否有誤，而調(diào)試是為了解決當前已知的錯誤，調(diào)試活動無法替代軟件測試活動。軟件測試由來調(diào)試12軟件測試定義定義：軟件測試就是為了發(fā)現(xiàn)錯誤而審查軟件文檔、檢查軟件數(shù)據(jù)和執(zhí)行程序代碼的過程。軟件測試應該是對軟件形成過程的文檔,數(shù)據(jù)以及程序進行的測試,而不僅是對程序進行的測試。60%以上的軟件錯誤并不是程序錯誤,而是分析和設計的錯誤,提倡軟件全生命周期測試的理念。軟件測試定義定義：軟件測試就是為了發(fā)現(xiàn)錯誤而審查軟件文檔、檢13什么是軟件質(zhì)量1991年國際標準ISO9126中定義為:軟件滿足規(guī)定或潛在用戶需求的總和。1999年國際標準ISO14598中定義為:軟件特性的總和，軟件滿足規(guī)定或潛在用戶需求的能力。2001年國際標準ISO9126中定義為：軟件滿足規(guī)定用戶或潛在用戶需求的能力，要從軟件在內(nèi)部，外部和使用過程中的表現(xiàn)來衡量，包含內(nèi)部質(zhì)量、外部質(zhì)量、和使用質(zhì)量。什么是軟件質(zhì)量1991年國際標準ISO9126中定義為:軟14軟件測試與質(zhì)量保證的區(qū)別軟件質(zhì)量保證和軟件測試是軟件質(zhì)量工程中兩個不同層面的工作。質(zhì)量保證(QA):質(zhì)量保證的重要工作通過預防，檢查與改進來保證軟件質(zhì)量(所關注的是軟件質(zhì)量的檢查與測量,著眼于軟件開發(fā)的過程,步驟和產(chǎn)物)。軟件測試：測試過程雖然與開發(fā)過程緊密相關但，關心的不是過程的活動，而是對過程的產(chǎn)物以及開發(fā)出的軟件進行剖析。軟件測試與質(zhì)量保證的區(qū)別軟件質(zhì)量保證和軟件測試是軟件質(zhì)量工程15軟件測試的目的和原則

基于不同的立場，存在著兩種完全不同的測試目的：用戶角度：希望軟件測試暴露軟件中隱藏的錯誤和缺陷，已考慮是否接受產(chǎn)品。軟件開發(fā)者角度：希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗證被測軟件已正確的實現(xiàn)了用戶的需求，確立人們對軟件質(zhì)量的信心。軟件測試的目的和原則基于不同的立場，存在著兩種完全不同16軟件測試的目的和原則換言之，測試的目的是：想以最少的時間和人力，系統(tǒng)地找出軟件中潛在的各種錯誤和缺陷。如果我們成功地實施了測試，我們就能夠發(fā)現(xiàn)軟件中的錯誤。測試的附帶收獲是，它能夠證明軟件的功能和性能與需求說明相符合。實施測試收集到的測試結果數(shù)據(jù)為可靠性分析提供了依據(jù)測試不能表明軟件中不存在錯誤，它只能說明軟件中存在錯誤軟件測試的目的和原則換言之，測試的目的是：17軟件測試的目的和原則

軟件測試的原則：所有的軟件測試都應追溯到用戶需求。應當把“盡早地和不斷地進行軟件測試”作為軟件測試者的座右銘。完全測試是不可能的，測試需要終止。測試無法顯示軟件潛在的缺陷。也就是說測試只能證明軟件存在錯誤而不能證明軟件沒有錯誤。軟件測試的目的和原則軟件測試的原則：18軟件測試的對象根據(jù)軟件定義，軟件包括程序，數(shù)據(jù)和文檔，所以軟件測試并不僅僅是程序測試，軟件測試應該貫穿整個軟件生命周期中。

需求分析，概要設計，詳細設計以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明，概要設計規(guī)格說明，詳細設計規(guī)格說明以及源程序。軟件測試的對象根據(jù)軟件定義，軟件包括程序，數(shù)據(jù)和文檔，所以軟19軟件測試的對象為了把握各個環(huán)節(jié)的正確性，人們需要進行各種驗證和確認工作：驗證(verification)：是保證軟件正確實現(xiàn)特定功能的一系統(tǒng)活動和過程,目的是保證軟件生命周期中的每一個階段的成果滿足上一個階段所設定的目標。確認(validation)：是保證軟件滿足用戶需求的一系列的活動和過程，目的是在軟件開發(fā)完成后保證軟件，用戶需求相符合。軟件測試的對象為了把握各個環(huán)節(jié)的正確性，人們需要進行各種驗證20軟件測試的對象軟件測試的對象21軟件測試分類

一般的，我們將軟件測試活動分為以下幾類：黑盒測試、白盒測試、灰盒測試、靜態(tài)測試、動態(tài)測試、手動測試、自動測試軟件測試分類一般的，我們將軟件測試活動分為以下幾類：22軟件測試分類—黑盒測試黑盒測試又叫功能測試、數(shù)據(jù)驅(qū)動測試或基于需求規(guī)格說明書的功能測試。該測試類別注重于測試軟件的功能性需求。測試工程師無需了解程序代碼的內(nèi)部構造，完全模擬軟件產(chǎn)品的最終端用戶使用該軟件，檢查軟件產(chǎn)品是否達到了用戶的需求。如圖1-4所示為黑盒測試實例圖。黑盒測試能更好的從用戶角度來考察被測系統(tǒng)的功能性需求實現(xiàn)情況。測試用例測試結果圖1-4黑盒測試示例圖軟件測試分類—黑盒測試黑盒測試又叫功能測試、數(shù)據(jù)驅(qū)動測試或基23軟件測試分類—白盒測試白盒測試又稱結構測試、邏輯驅(qū)動測試或基于程序代碼內(nèi)部構成的測試。白盒測試需要測試工程師深入考查程序代碼的內(nèi)部結構、邏輯設計等。就像前面的例子，我們拆開手機，觀察手機電路板的設計，液晶屏的構成等。對于白盒測試工程師來說，軟件產(chǎn)品的內(nèi)部結構是敞開的。如圖1-5所示是白盒測試示例圖。程序內(nèi)部結構測試用例測試結果圖1-5白盒測試示例圖軟件測試分類—白盒測試白盒測試又稱結構測試、邏輯驅(qū)動測試或基24軟件測試分類—灰盒測試灰盒測試介于白盒和黑盒測試之間。灰盒測試一方面考慮程序代碼的功能性表現(xiàn)，另一方面，又需要考慮程序代碼的內(nèi)部結構。通俗地講，灰盒測試就是白加黑。像我們的性能測試，自動化功能測試就是采用了灰盒測試的方法。圖1-6是灰盒測試的示例圖。測試用例測試結果圖1-6灰盒測試示例圖軟件測試分類—灰盒測試灰盒測試介于白盒和黑盒測試之間。測試用25軟件測試分類—靜態(tài)測試定義：靜態(tài)的、不執(zhí)行被測對象程序代碼而尋找缺陷的過程。在進行靜態(tài)測試時可采用一些代碼走查工具，如QAC++、C++Test等。軟件測試分類—靜態(tài)測試定義：靜態(tài)的、不執(zhí)行被測對象程序代碼而26軟件測試分類—動態(tài)測試實際的執(zhí)行被測對象的程序代碼，輸入實現(xiàn)設計好的測試用例，檢查程序代碼運行得到的結果與測試用力中設計的預期結果之間是否有差異，判定實際結果與預測結果是否一致。動態(tài)測試有四部分組成：設計測試用例、執(zhí)行測試用例、分析比較輸出結果、輸出測試報告。動態(tài)測試有三種主要方法：黑盒測試、白盒測試和灰盒測試軟件測試分類—動態(tài)測試實際的執(zhí)行被測對象的程序代碼，輸入實現(xiàn)27軟件測試分類—手動測試它是測試人員設計測試用例并執(zhí)行測試用例，然后根據(jù)實際的結果去和預期的結果相比較并記錄測試結果，最終輸出測試報告的測試活動。可充分發(fā)揮測試工程師的主觀能動性，將其智力體現(xiàn)在測試工作中，能發(fā)現(xiàn)許多的缺陷，但同時又有一定的局限性和單調(diào)枯燥性。軟件測試分類—手動測試它是測試人員設計測試用例并執(zhí)行測試用例28軟件測試分類—自動化測試定義利用測試工具，模擬用戶業(yè)務使用流程，讓他們自動運行來查找缺陷。優(yōu)點快、廣泛、可重復性工作缺點只可檢查比較主要的問題，如崩潰、死機，無法發(fā)現(xiàn)一般的日常錯誤。編寫腳本工作量也很大，有時會超過手動測試時間。我們要根據(jù)實際情況選擇或者不選擇測試工具，選擇使用何種測試工具，不能為了實用工具而可以的去使用工具。軟件測試分類—自動化測試定義29軟件測試人員職業(yè)要求

從個人素質(zhì)角度要求測試工程師需要具備以下6種素質(zhì)：責任心溝通能力團隊合作精神耐心、細心和信心時時保持懷疑態(tài)度、并且有缺陷預防的意識不斷學習的能力軟件測試人員職業(yè)要求從個人素質(zhì)角度要求測試工程師需要30軟件測試流程軟件測試流程31軟件測試流程圖軟件測試雖然是軟件生存周期的一個獨立階段，但測試工作卻滲透到從分析、設計直到編程的各個階段中（1-7是軟件測試所經(jīng)階段的一般流程）。需求測試、單元測試、集成測試、系統(tǒng)測試、性能測試、用戶測試、回歸測試需求測試單元測試集成測試系統(tǒng)測試性能測試用戶測試回歸測試圖1-7軟件測試流程圖軟件測試流程圖軟件測試雖然是軟件生存周期的一個獨立階段，但測32需求測試要從以下幾個方面考慮需求測試：完整性正確性一致性可行性無二義性健壯性必要性可測試性可修改性需求測試要從以下幾個方面考慮需求測試：33單元測試又稱模塊測試，就是對程序代碼中最小的涉及模塊單元進行測試。

在單元測試中我們主要采用靜態(tài)測試與動態(tài)測試相結合的辦法。單元測試要求需要幾年的代碼編寫經(jīng)驗，并且要十分熟悉當前的被測系統(tǒng)，以及該系統(tǒng)是否與其他系統(tǒng)的接口關聯(lián)情況。單元測試在編碼階段占據(jù)非常重要的地位?？梢越档途幋a的錯誤率，提高編碼質(zhì)量單元測試又稱模塊測試，就是對程序代碼中最小的涉及模塊單元進行34集成測試又稱組裝測試，是將軟件產(chǎn)品各個模塊組裝起來，檢查接口是否存在問題，以及組裝后的整體功能、性能表現(xiàn)。一般可采用非增式集成方法、增式集成方法（自底向上集成、自頂向下集成、組合方式集成）等策略進行測試，利用一黑盒測試為主，白盒測試為輔的測試方法進行測試。主要解決各個組成但源代碼是否符合開發(fā)規(guī)范、接口是否存在問題，整體功能有無錯誤、界面是否符合設計規(guī)范、性能是否滿足用戶需求等。集成測試又稱組裝測試，是將軟件產(chǎn)品各個模塊組裝起來，檢查接口35系統(tǒng)測試將通過集成測試的軟件部署到某種較為復雜的計算機永華環(huán)境進行測試。目的：通過與系統(tǒng)的需求定義作比較，發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。這個階段主要進行的是安裝卸載測試、兼容性測試、功能確認測試、安全測試等。采用黑盒測試法，主要考察被測軟件的功能與性能表現(xiàn)。系統(tǒng)測試將通過集成測試的軟件部署到某種較為復雜的計算機永華環(huán)36性能測試性能測試要求被測軟件在業(yè)務處理速度、處理能力和所耗用的硬件系統(tǒng)資源比率滿足用戶的需求。不要嘗試用手動方式進行性能測試，應當編寫一段相應的程序或者使用專門的工具進行，如利用LoadRunner自動化性能測試工具。性能測試相對難度較大，要求測試人員掌握編程語言，精通業(yè)務流程，擁有深厚的項目經(jīng)驗。性能測試性能測試要求被測軟件在業(yè)務處理速度、處理能力和所耗用37用戶測試可稱為用戶確認測試。正式驗收前，需要用戶對本系統(tǒng)做出一個評價，用戶可對交付的系統(tǒng)做測試，并將測試結果反饋回來，進行修改、分析。用戶測試環(huán)節(jié)是被測試軟件首次作為正式的系統(tǒng)交友用戶使用，用戶會根據(jù)他們的實際使用情況進行測試、使用，并提出實際使用過程中的問題。用戶測試是軟件生產(chǎn)流程中的最后質(zhì)檢關。用戶測試可稱為用戶確認測試。38回歸測試回歸測試是經(jīng)過一段時間以后再回過頭來對以前修復過的Bug重新進行測試，看該Bug是否會重新出現(xiàn)。有些時候可采用自動化測試工具來進行回歸測試，如利用QTP一般情況下，都由測試工程師手動的執(zhí)行一千的測試用例。來檢查用例通過情況?；貧w測試回歸測試是經(jīng)過一段時間以后再回過頭來對以前修復過的B39軟件項目運作流程軟件項目運作流程40軟件項目運作圖市場調(diào)研可行性研究產(chǎn)品立項需求調(diào)研設計開發(fā)系統(tǒng)測試產(chǎn)品發(fā)布產(chǎn)品維護產(chǎn)品升級圖1-8軟件項目運作圖軟件項目運作圖市場調(diào)研可行性研究產(chǎn)品立項需求調(diào)研設計開發(fā)系統(tǒng)41市場調(diào)研1、主動模式將公司或者企業(yè)作為需求接收的被動方，而需求的提出作為主動方。2、被動模式在沒有明確的需求提出者時，有公司或企業(yè)主動提出給特定使用用戶群提供某種產(chǎn)品的模式。市場調(diào)研主體：市場人員、銷售人員調(diào)研方式：客戶走訪，市場觀察，報刊媒體等輸出文件：《XXX項目市場調(diào)研分析報告》市場調(diào)研1、主動模式42可行性研究以預測為前提，以投資效果為目的，從技術上、管理上進行全面綜合分析研究的方法。基本任務：對新開發(fā)產(chǎn)品或升級產(chǎn)品從技術經(jīng)濟角度進行全面的分析研究，并對其投產(chǎn)后的經(jīng)濟效益進行預測，在既定的范圍內(nèi)進行方案論證的選擇，以便最合理的利用資源，達到預定的社會效益和經(jīng)濟效益。主體：市場人員、銷售人員對象：在市場調(diào)研階段產(chǎn)生的《XXX項目市場調(diào)研分析報告》輸出文件：《XXX項目可行性分析報告》可行性研究以預測為前提，以投資效果為目的，從技術上、管理上進43產(chǎn)品立項在前期的市場調(diào)研、可行性研究經(jīng)過評審可行后，則由需求調(diào)研人員牽頭，進行產(chǎn)品立項，并進行產(chǎn)品小組的建立，同時制定產(chǎn)品的運作計劃，如需求調(diào)研、產(chǎn)品設計、產(chǎn)品測試、產(chǎn)品發(fā)布等一系列的工作步驟及時間點。立項負責人：市場調(diào)研人員工作內(nèi)容：提交產(chǎn)品立項申請，審批通過后，指定產(chǎn)品計劃書，確定產(chǎn)品各個階段的工作流程及時間進度表。產(chǎn)品立項在前期的市場調(diào)研、可行性研究經(jīng)過評審可行后，則由需求44需求調(diào)研1、主動模式2、被動模式需求調(diào)研參與人員：市場人員、開發(fā)人員、測試人員等調(diào)研對象：客戶或假象客戶（廣泛應用群）輸出：需求規(guī)格說明書需求調(diào)研1、主動模式45設計開發(fā)由系統(tǒng)架構師進行系統(tǒng)的概要設計，主要從穩(wěn)定性、安全性、擴展性、可維持性等方面進行設計。設計人員：系統(tǒng)架構師、項目開發(fā)小組輸出：項目開發(fā)計劃、概要設計文檔、詳細設計文檔、數(shù)據(jù)庫文檔等設計開發(fā)由系統(tǒng)架構師進行系統(tǒng)的概要設計，主要從穩(wěn)定性、安全性46系統(tǒng)測試按照前期的測試計劃，利用測試用例進行系統(tǒng)的功能、性能測試。在經(jīng)過多次版本的迭代后，完成系統(tǒng)測試，輸出測試報告。測試人員：項目測試小組輸出：測試計劃、測試方案、測試用例、功能測試報告、性能測試報告等系統(tǒng)測試按照前期的測試計劃，利用測試用例進行系統(tǒng)的功能、性能47產(chǎn)品發(fā)布經(jīng)過開發(fā)部門、測試部門和其他部門的努力，產(chǎn)品在預定的日期完成，有項目組擇日發(fā)布。發(fā)布人員：項目實施人員、市場部等輸出：客戶現(xiàn)場項目實施報告等產(chǎn)品發(fā)布經(jīng)過開發(fā)部門、測試部門和其他部門的努力，產(chǎn)品在預定的48產(chǎn)品維護交付使用后，需根據(jù)需求調(diào)研階段協(xié)議，制定產(chǎn)品維護流程，出現(xiàn)問題需及時解決，直到產(chǎn)品使用廢棄或升級，進入新的生命周期。產(chǎn)品維護交付使用后，需根據(jù)需求調(diào)研階段協(xié)議，制定產(chǎn)品維護流程49產(chǎn)品升級在軟件產(chǎn)品使用到一定期限后，可以根據(jù)先前的約定進行升級，或根據(jù)客戶新的需求，再次進行新需求的調(diào)研開發(fā)等。產(chǎn)品升級在軟件產(chǎn)品使用到一定期限后，可以根據(jù)先前的約定進行升50軟件測試工作流程軟件測試工作流程51測試部門組織結構1、人員構成

測試主管、測試組長、環(huán)境保障人員、配置管理員、測試設計人員、測試工程師測試主管測試組長環(huán)境保障人員軟件測試部配置管理員測試設計人員測試工程師圖1-9測試部人員結構圖測試部門組織結構1、人員構成測試主管測試組長環(huán)境保障人員軟件52測試部門組織結構2、測試主管負責測試部門日常管理工作。3、測試組長測試主管根據(jù)項目情況，指派合適的測試人員但當測試組長。4、環(huán)境保障人員維護整個項目過程中的系統(tǒng)環(huán)境，如硬件、軟件方便的。由測試人員兼任。5、配置管理員是軟件開發(fā)過程中的一個重要工作流程面對需求變更、版本迭代、文檔審核起到相當大的作用。測試部門組織結構2、測試主管53測試部門組織結構6、測試設計人員一般由高級測試工程師擔當，負責測試方法設計、測試用例設計及功能測試、性能測試的步驟、流程設計。7、測試工程師執(zhí)行測試用例，進行系統(tǒng)的功能測試，經(jīng)過多次版本迭代，完成系統(tǒng)測試。8、技術構成白盒測試技術、黑盒測試技術、自動化測試技術人員、項目管理技術人員白盒測試技術人員黑盒測試技術人員軟件測試部自動化測試技術人員項目測試技術人員圖1-10測試部技術構成圖測試部門組織結構6、測試設計人員白盒測試黑盒測試軟件測試部自54測試部門組織結構9、白盒測試技術人員該職位測試人員需要精通軟件開發(fā)語言，要有幾年的開發(fā)經(jīng)驗，能進行底層的代碼review，測試樁設計等，同時能夠食用百合測試工具對系統(tǒng)的最小功能單元進行測試，找出代碼、系統(tǒng)架構方面的缺陷。10、黑盒測試技術人員要求測試人員有一定的軟件工程理論、軟件質(zhì)量保證知識。11、自動化測試人員需測試人員掌握軟件開發(fā)的知識，系統(tǒng)的調(diào)優(yōu)，自動化測試工具，如QuickTestProfessionalLaodRunner。測試部門組織結構9、白盒測試技術人員55測試部門組織結構12、項目管理技術人員要求掌握一般的項目管理知識，如配置管理、版本控制、評審管理、項目實施與進度控制等。13、資源構成14、硬件資源需要齊備的測試環(huán)境，如測試PC機、測試服務器、測試芯片、測試手機等。硬件資源軟件測試部軟件資源技術支持圖1-11測試部資源構成圖測試部門組織結構12、項目管理技術人員硬件資源軟件測試部軟件56測試部門組織結構15、軟件資源測試需要的操作系統(tǒng)、應用軟件、管理軟件等。如Windows、Linux等操作系統(tǒng)，SQLServer、Oracle等數(shù)據(jù)庫軟件，QuickTestProfessionalLaodRunner等自動化測試工具。16、技術支持當測試人元遇到問題不能解決時，可由兄弟部門給予支持。確保在一個團隊合作的環(huán)境下，更高效的完成測試工作。測試部門組織結構15、軟件資源57測試工作流程測試準備階段測試工作流程測試開展階段測試輸出階段圖1-12測試工作流程圖測試工作流程測試準備階段測試工作流程測試開展階段測試輸出階段58測試工作流程1、測試準備階段測試計劃制定測試小組建立項目經(jīng)理測試主管測試組長部署測試任務指派測試組長獲取測試需求及相關文檔圖1-13測試工作介入流程圖測試組長測試主管測試工程師小組工作會議申請小組成員指定小組成員圖1-14測試小組建立圖測試工作流程1、測試準備階段項目經(jīng)理測試主管測試組長部署測試59測試工作流程需求測試啟動測試需求提取分配任務測試組裝需求調(diào)研部門校正需要提供需求測試小組反饋結果圖1-15需求測試流程圖測試組長測試小組測試工具分配任務編寫用例圖1-16部署測試需求提取任務流程圖測試工作流程需求測試啟動分配任務測試組裝需求調(diào)研部門校正需要60測試工作流程測試用例編寫測試組長測試小組測試工具分配任務編寫用例圖1-17部署測試用例編寫任務流程圖測試工作流程測試用例編寫測試組長測試小組測試工具分配任務編寫61測試工作流程2、測試開展階段搭建測試環(huán)境—測試組長，可根據(jù)說明說中的軟件產(chǎn)品運行環(huán)境配置要求搭建。測試環(huán)境最好與開發(fā)環(huán)境分開文檔引入—工作日報、功能測試報告、性能測試報告等模板執(zhí)行測試—根據(jù)項目的Bug管理流程，經(jīng)過多次的版本迭代，完成測試工作。測試工作流程2、測試開展階段62測試工作流程3、測試輸出階段測試計劃測試方案測試用例測試工程師的工作日報功能測試報告性能測試報告測試工作流程3、測試輸出階段63思考與練習1、軟件測試共有幾種模型？具體的內(nèi)容是什么？相互之間有什么區(qū)別與聯(lián)系？2、簡要描述同行評審與階段評審的區(qū)別。3、軟件測試與軟件開發(fā)的關系是什么？4、什么叫軟件測試？軟件測試的目的是什么？思考與練習1、軟件測試共有幾種模型？具體的內(nèi)容是什么？相互之64思考與練習5、軟件測試的一般工作流程是什么？6、軟件測試的測試流程是什么？各階段的工作內(nèi)容重點是什么？7、當你接到一個測試任務后，你如何開展測試工作？思考與練習5、軟件測試的一般工作流程是什么？65軟件測試用例設計方法軟件測試用例設計方法66什么是測試用例測試用例（

TestCase）是指對一項特定的軟件產(chǎn)品進行測試任務的描述，體現(xiàn)測試方案、方法、技術和策略。內(nèi)容包括測試目標、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預期結果、測試腳本等，并形成文檔。什么是測試用例67測試用例包含要素每個具體測試用例都將包括下列詳細信息：編制人、審定人、編制日期、版本、用例類型、設計說明書編號、用例編號、用例名稱、輸入說明、期望結果（含判斷標準）、環(huán)境要求、備注等。具體可以參考建行測試用例模板測試用例包含要素每個具體測試用例都將包括下列詳細信息：編制人68黑盒測試案例設計技術測試用例設計：將軟件測試的行為活動，作為一個科學化的組織歸納。測試用例：設計一個情況，軟件程序在這種情況下，必須能夠正常運行并且達到程序所設計的執(zhí)行結果。因為我們不可能進行窮舉測試，為了節(jié)省時間和資源、提供測試效率，必須從數(shù)量極大的可用測試數(shù)據(jù)精心挑選出具有代表性或者特殊性的測試數(shù)據(jù)來進行測試。

黑盒測試案例設計技術測試用例設計：將軟件測試的行為活動，作為69測試測試用例的好處在開始實施測試之前設計好測試用例，可以避免盲目測試并提高測試效率。測試用例的使用令軟件測試的實施重點突出、目的明確。在軟件版本更新后只修正少部分的測試用例便可展開測試工作，降低工作強度，縮短項目周期。功能測試模塊的通用化和復用化使軟件易于開發(fā)，而測試用例的通用化和復用化則會使軟件測試易于開展，并隨著測試用例的不斷精化其效率也不斷攀升。測試測試用例的好處在開始實施測試之前設計好測試用例，可以避免70常見黑盒測試用例設計方法等價類劃分法邊界值分析法錯誤推測法因果圖法判定表驅(qū)動法正交試驗設計法功能圖法場景法常見黑盒測試用例設計方法等價類劃分法71等價類劃分法等價類劃分的辦法是把程序的輸入域劃分成若干部分，然后從每個部分中選取少數(shù)代表性數(shù)據(jù)作為測試用例。劃分等價類和列出等價類表確定測試用例等價類劃分法等價類劃分的辦法是把程序的輸入域劃分成若干部分，72劃分等價類和列出等價類表等價類是指輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效，并合理地假設：測試某等價類的代表值就等于對這類其他值的測試。等價類劃分有兩種不同的情況：有效等價類和無效等價類。劃分等價類和列出等價類表等價類是指輸入域的子集合。在該子集合73劃分等價類和列出等價類表有效等價類：指對于程序的規(guī)格說明書來說是合理的、有意義的輸入數(shù)據(jù)構成的集合。利用有效等價類可以檢驗程序是否實現(xiàn)了規(guī)格說明書中所規(guī)定的功能和性能。無效等價類：與有效等價類的定義恰巧相反。劃分等價類和列出等價類表有效等價類：指對于程序的規(guī)格說明書來746條確定等價類的原則1、在輸入條件規(guī)定了取值范圍或者值個數(shù)的情況下，可以確定一個有效等價類和兩個無效等價類。2、在輸入條件規(guī)定了輸入值的集合或者規(guī)定了“必須如何”的條件的情況下，可以確定一個有效等價類和一個無效等價類。3、在輸入條件是一個布爾量的情況下，可以確定一個有效的等價類和一個無效的等價類6條確定等價類的原則1、在輸入條件規(guī)定了取值范圍或者值個數(shù)的756條確定等價類的原則4、在規(guī)定了輸入數(shù)據(jù)的一組值（假定n個），并且程序要對每一個輸入值分別處理的情況下，可以確定n個有效的等價類和一個無效的等價類。5、在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下，可以確定一個有效等價類類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。6、在確知已劃分的等價類中，各元素在程序處理中的方式不同的情況下，則應再將該等價類進一步地劃分為更小的等價類。6條確定等價類的原則4、在規(guī)定了輸入數(shù)據(jù)的一組值（假定n個）76確定測試用例步驟為每個等價類規(guī)定一個惟一的編號。設計一個新的測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類，重復這一步，最后使得所有的有效等價類均被測試用例所覆蓋。設計一個新的測試用例，使其只覆蓋一個無效等價類。重復這一步使所有無效等價類均被覆蓋。確定測試用例步驟為每個等價類規(guī)定一個惟一的編號。77等價類劃分法例題一個程序讀入3個整數(shù)，把這3個數(shù)值看作一個三角形的3條邊的長度值。這個程序要打印出信息，說明這個三角形是不等邊的、是等腰的、還是等邊的。構成三角形的3條邊必須滿足：

A>0,B>0,C>0，且A+B>C,B+C>A,A+C>B如果是等腰的，還要判斷A=B,或者B=C,或者A=C如果是等邊的，則需要判斷是否A=B,且B=C,且A=C.等價類劃分法例題一個程序讀入3個整數(shù)，把這3個數(shù)值看作一個三78等價類表輸入條件有效等價類無效等價類是否三角形的3條邊(A>0）(1)(B>0）(2)(C>0）(3)(A+B>C)(4)(B+C>A)(5)(A+C>B)(6)(A≤0）(7)(B≤0）(8)(C≤0）(9)(A+B≤C)(10)(B+C≤A)(11)(A+C≤B)(12)是否等腰三角形(A=B）(13)(B=C)(14)(C=A)(15)(A≠B)and(B≠C)and(C≠A)(16)是否等邊三角形(A=B）and(B=C)and(C=A)(17)(A≠B)(18)(B≠C)(19)(C≠A)(20)等價類表輸入條件有效等價類無效等價類(A>0）79設計測試用例設計測試用例80邊界值分析法邊界值分析：是考慮邊界條件而選取測試用例的一種黑盒測試方法，是對等價類劃分方法的補充。實踐證明，軟件在輸入、輸出域的邊界附近容易出現(xiàn)差錯，而不是在輸入范圍的內(nèi)部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。邊界值分析法邊界值分析：是考慮邊界條件而選取測試用例的一種81邊界值分析法使用邊界值分析方法設計測試方案首先應該確定邊界情況，通常輸入等價類和輸出等價類的邊界，就是應該注重測試的程序邊界情況。選取的測試數(shù)據(jù)應該正好等于、剛剛小于和剛剛大于邊界值，也就是說，按照邊界值分析法，應該選取剛好等于、稍小于和稍大于等價類邊界值作為測試數(shù)據(jù)，而不是選取每個等價類內(nèi)的典型值或任意值作為測試數(shù)據(jù)。邊界值分析法使用邊界值分析方法設計測試方案首先應該確定邊界情82基于邊界值分析方法選擇測試用例的原則如果輸入條件規(guī)定了值的范圍，則應取剛達到這個范圍的邊界的值，以及剛剛超越這個范圍邊界的值作為測試輸入數(shù)據(jù)。如果輸入條件規(guī)定了值的個數(shù)，則用最大個數(shù)，最小個數(shù)，比最小個數(shù)少一，比最大個數(shù)多一的數(shù)作為測試數(shù)據(jù)。根據(jù)規(guī)格說明的每個輸出條件，考慮值的范圍情況。基于邊界值分析方法選擇測試用例的原則如果輸入條件規(guī)定了值的范83基于邊界值分析方法選擇測試用例的原則。根據(jù)規(guī)格說明的每個輸出條件，考慮值的個數(shù)情況。如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最后一個元素作為測試用例。如果程序中使用了一個內(nèi)部數(shù)據(jù)結構，則應當選擇這個內(nèi)部數(shù)據(jù)結構的邊界上的值作為測試用例分析規(guī)格說明，找出其它可能的邊界條件?；谶吔缰捣治龇椒ㄟx擇測試用例的原則。根據(jù)規(guī)格說明的每個輸出84錯誤推測方法基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。錯誤推測方法的基本思想：列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)他們選擇測試用例。錯誤推測方法基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤，85錯誤推測方法常見依據(jù)在單元測試時曾列出的許多在模塊中常見的錯誤。以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等。已發(fā)現(xiàn)缺陷的測試方法的推廣。容易發(fā)生錯誤的情況。補充等價類和邊界值法遺漏的一些等價類組合。一些位置使用了共享變量，設計測試用例，修改一個共享變量，看其他位置有沒有同時做修改錯誤推測方法常見依據(jù)在單元測試時曾列出的許多在模塊中常見的錯86因果圖設計方法因果圖方法是對等價類的擴展，可以理解為“等價類組合判定表”。因果圖即輸入等價類與輸出等價類的關系圖因果圖設計方法因果圖方法是對等價類的擴展，可以理解為“87因果圖生成測試用例的基本步驟分析軟件規(guī)格說明描述中，那些是原因(即輸入條件或輸入條件的等價類)，那些是結果(即輸出條件)，并給每個原因和結果賦予一個標識符。分析軟件規(guī)格說明描述中的語義。找出原因與結果之間，原因與原因之間對應的關系。根據(jù)這些關系，畫出因果圖。因果圖生成測試用例的基本步驟分析軟件規(guī)格說明描述中，那些是88因果圖生成測試用例的基本步驟表明約束條件。由于語法或環(huán)境限制，有些原因與原因之間，原因與結果之間的組合情況不不可能出現(xiàn)。為表明這些特殊情況，在因果圖上用一些記號表明約束或限制條件。把因果圖轉(zhuǎn)換成判定表為判定表中每一列表示的情況設計測試用例。因果圖生成測試用例的基本步驟表明約束條件。由于語法或環(huán)境限制89正交試驗法正交試驗設計方法：是從大量的試驗數(shù)據(jù)中挑選適量的、有代表性的點，從而合理的安排測試的一種科學的試驗設計方法正交試驗法正交試驗設計方法：是從大量的試驗數(shù)據(jù)中挑選適量的、90正交試驗測試用例設計步驟提取功能說明，構造因子狀態(tài)表。加權篩，生成因素分析表利用正交表構造測試數(shù)據(jù)集。正交試驗測試用例設計步驟提取功能說明，構造因子狀態(tài)表。91正交試驗法優(yōu)點節(jié)省測試工時。可控制測試用例的數(shù)量。測試用例具有一定的覆蓋率。正交試驗法在軟件測試中是一種有效的方法，例如在平臺參數(shù)配置方面，我們要選擇哪種組合方式是最好的，每個參數(shù)可能就是一個因子，參數(shù)的不同取值就是平水，采用正交試驗法設計出最少的測試組合，達到有效測試目的。正交試驗法優(yōu)點節(jié)省測試工時。92功能圖分析方法功能圖方法：用功能圖形象地表示程序功能說明，并生成功能圖的測試用例。又可以稱作流程測試或狀態(tài)遷移測試類似于白盒測試中的邏輯覆蓋和路徑法需要懂得控制語句（循環(huán)，順序，選擇，重復）功能圖分析方法功能圖方法：用功能圖形象地表示程序功能說明，并93功能圖生成測試用例過程在每個狀態(tài)生成局部測試用例。測試路徑生成：從初始狀態(tài)到最后狀態(tài)的測試路徑測試用例合成：合成測試路徑和功能圖中每個狀態(tài)的局部測試用例。測試用例合成算法：條件構造樹。功能圖生成測試用例過程在每個狀態(tài)生成局部測試用例。94場景法事件觸發(fā)控制流程，事件觸發(fā)時的情景便形成場景。同一事件不同的觸發(fā)順序和處理結果就形成事件流用例場景用來描述流經(jīng)用例的路徑，從用例開始到結束遍歷這條路徑的有基本流和備選流。場景法事件觸發(fā)控制流程，事件觸發(fā)時的情景便形成場景。95測試用例選擇的綜合策略1、首先進行等價類劃分，包括輸入條件和輸出條件的等價類劃分，將無限測試變成有限測試，這是減少工作量和提高測試效率的有效方法。2、在任何情況下都必須使用邊界值分析方法。經(jīng)驗表明，用這種方法設計出的測試用例發(fā)現(xiàn)程序錯誤的能力最強測試用例選擇的綜合策略1、首先進行等價類劃分，包括輸入條件和96測試用例選擇的綜合策略3、可以用錯誤推測法追加一些測試用例，這些需要依靠測試工程師的智慧和經(jīng)驗。4、對照程序邏輯，檢查已設計的測試用例的邏輯覆蓋程序，如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。5、如果程序的功能說明中含有輸入條件的組合，則一開始就可以選因果圖法和判定表驅(qū)動法。6、對參數(shù)配置類的軟件，要用正交試驗法選擇較少的組合方式達到最佳的測試效果測試用例選擇的綜合策略3、可以用錯誤推測法追加一些測試用例，97測試用例選擇的綜合策略7、功能圖法也是很好的測試用例設計方法，我們可以通過不同時期條件的有效性設計不同的測試數(shù)據(jù)。8、對于業(yè)務流清晰的系統(tǒng)，可以利用場景法貫穿整個測試案例過程，在案例中綜合使用各種測試方法。測試用例選擇的綜合策略7、功能圖法也是很好的測試用例設計方法98軟件缺陷軟件缺陷99什么是軟件缺陷符合下面

5條規(guī)則之一的問題稱為軟件缺陷：1、軟件未達到產(chǎn)品說明書標明的功能。2、軟件出現(xiàn)產(chǎn)品說明書指明不會出現(xiàn)的錯誤。（如果軟件含有產(chǎn)品說明中根本沒有存在的功能，這是缺陷）3、軟件功能超出產(chǎn)品說明書指明的范圍。4、軟件未達到產(chǎn)品說明書未指出但應達到的目標。（產(chǎn)品說明書雖然沒有提到，但是按照常理應該達到的功能）5、軟件測試人員或用戶認為軟件難以理解，不易使用，運行速度緩慢等問題。什么是軟件缺陷符合下面5條規(guī)則之一的問題稱為軟件缺陷：100缺陷的生命周期簡單周期：

測試員找到并登記軟件缺陷，軟件缺陷移交到程序員=>程序員修復軟件缺陷，軟件缺陷移交到測試員=>測試員確定軟件缺陷被修復，測試員關閉軟件缺陷。缺陷的生命周期簡單周期：101缺陷的生命周期復雜周期：發(fā)現(xiàn)缺陷（測試員發(fā)現(xiàn)并登記缺陷，軟件缺陷轉(zhuǎn)到程序員）=>軟件缺陷移交到項目管理員=>（以不修復形式解決）項目管理員認為軟件缺陷不重要，軟件缺陷移交到測試員=>重新激活缺陷（測試員不同意，找出通用失敗案例，軟件缺陷移交到項目管理員）=>項目管理員同意缺陷需要修復，缺陷轉(zhuǎn)給程序員=>以修復形式解決（測試員確認軟件缺陷得以修復，測試員關閉軟件缺陷）=>缺陷關閉缺陷的生命周期復雜周期：102報告缺陷的要點復雜周期：發(fā)現(xiàn)了軟件缺陷，需要記錄下來，不但要記錄結果，同時需要詳細描述發(fā)現(xiàn)的步驟，以備程序員重現(xiàn)問題，并解決它。要求報告寫的清楚明了和準確。有時利用截屏技術把當時的情況保存成圖片，可以達到一圖勝千言的效果。參考軟件測試缺陷跟蹤管理說明.pdf文檔（vss\09_測試團隊\公共\規(guī)范說明）報告缺陷的要點復雜周期：103缺陷的嚴重性分類A類——致命性：不能完全滿足系統(tǒng)要求，基本業(yè)務功能未實現(xiàn)系統(tǒng)崩潰、不穩(wěn)定或掛起等導致系統(tǒng)不能繼續(xù)運行、導致系統(tǒng)出現(xiàn)不可預料的嚴重錯誤的問題。缺陷的嚴重性分類A類——致命性：104缺陷的嚴重性分類B類——嚴重錯誤：嚴重地影響系統(tǒng)要求或基本功能的實現(xiàn)，且沒有辦法更正（重新安裝或重新啟動不屬于更正辦法）。使系統(tǒng)不穩(wěn)定、破壞數(shù)據(jù)、產(chǎn)生錯誤結果，部分功能無法執(zhí)行。缺陷的嚴重性分類B類——嚴重錯誤：105缺陷的嚴重性分類C類——一般性錯誤：

1、界面錯誤。2、非重要功能無法正確執(zhí)行，實現(xiàn)不正確，實現(xiàn)不完整，但不影響功能3、非嚴重性產(chǎn)生錯誤結果，但不影響一起功能。4、正確性不受影響，但系統(tǒng)性能和響應時間受到影響。缺陷的嚴重性分類C類——一般性錯誤：106缺陷的嚴重性分類D類——輕微錯誤：使操作者不方便或遇到麻煩，但它不影響執(zhí)行工作功能或重要功能，或?qū)ψ罱K結果影響有限的問題。缺陷的嚴重性分類D類——輕微錯誤：107缺陷的嚴重性分類E類——測試建議：不影響系統(tǒng)運行，對系統(tǒng)的可用性等提示的建議性的問題。例如：

1、系統(tǒng)各個位置初始值的建議。2、流程優(yōu)化建議等等。缺陷的嚴重性分類E類——測試建議：108缺陷分析缺陷分析就是分析缺陷在與缺陷關聯(lián)關系的一個或多個參數(shù)值上的分布。缺陷分析提供了一個軟件可靠性指標缺陷分析109缺陷分析主要參數(shù)狀態(tài)：缺陷的當前狀態(tài)（打開的、正在修復或關閉的等）。優(yōu)先級：必須處理和解決缺陷的相對重要性。嚴重性：缺陷的相關影響。對最終用戶、組織或第三方的影響等等。起源：導致缺陷的起源故障及其位置，或排除該缺陷需要修復的構件缺陷分析主要參數(shù)狀態(tài)：缺陷的當前狀態(tài)（打開的、正在修復或關閉110缺陷分析報告可以將缺陷計數(shù)作為時間的函數(shù)來報告，即創(chuàng)建缺陷趨勢圖或報告；也可以將缺陷計數(shù)作為一個或多個缺陷參數(shù)的函數(shù)來報告，如作為缺陷密度報告中采用的嚴重性或狀態(tài)參數(shù)的函數(shù)。這些分析類型分別為揭示軟件可靠性的缺陷趨勢或缺陷分布提供了判斷依據(jù)缺陷分析報告可以將缺陷計數(shù)作為時間的函數(shù)來報告，即創(chuàng)建缺陷趨111軟件測試的技巧軟件測試的技巧112測試技巧分類結構測試相對于功能測試動態(tài)測試相對于靜態(tài)測試手工測試相對于自動測試測試技巧分類結構測試相對于功能測試113結構測試技巧壓力測試執(zhí)行測試恢復測試操作測試復合性測試（與過程的復合性)安全測試結構測試技巧壓力測試114壓力測試目標模擬出實際用戶環(huán)境怎么用

產(chǎn)生測試數(shù)據(jù)測試組模擬用戶處理被創(chuàng)建的數(shù)據(jù)例子確定是否分配了足夠的磁盤空間通訊的容量是否足夠測試系統(tǒng)過載的情況什么時間使用當關于容量的信息不確定的時候壓力測試目標115性能測試技巧目標確定系統(tǒng)達到了希望達到的性能水平如何使用使用軟件和硬件的監(jiān)視器使用模擬的監(jiān)控模型，對關心的性能指標進行監(jiān)控創(chuàng)建一個小程序例子計算通信的時間單位時間處理的信息量什么時候使用－在程序開發(fā)的早期進行性能測試技巧目標116恢復測試目標當在進行安裝或組裝操作過程中，文件丟失時或發(fā)生意外后系統(tǒng)有能力重新進行操作如何使用程序的安裝，運行方式，工具的使用和關鍵技術經(jīng)過足夠的評估系統(tǒng)開發(fā)完畢后，介紹一下發(fā)生失敗后的處理過程例子人為的使一個系統(tǒng)在安裝或者組裝過程中產(chǎn)生錯誤什么時間去使用當操作的連續(xù)性是個重點的時候恢復測試目標117操作測試目標確定計算機的操作文檔已經(jīng)完整如何使用作為計算機正常操作的一部分來執(zhí)行測試例子操作的介紹被文檔化，操作者被培訓什么時候使用預先將程序進行產(chǎn)品化。操作性是系統(tǒng)的一個重要指標的時候。操作測試目標118復合性測試目標校驗程序的開發(fā)是否依照已定義的標準，流程和操作方式進行的。如何去使用將文檔/程序同標準相比較比較有效的方法是檢查過程例子代碼互查（一行一行）什么時候使用依賴于管理的需要復合性測試目標119安全性測試目標安全性的缺陷很難被發(fā)現(xiàn)。大多數(shù)的情況下組織能夠防止一般性的破壞者。如何使用對安全性的需求進行評審分析與安全性有關的處理流程轉(zhuǎn)包給專業(yè)的人員例子定義了被保護的資源，權限進行了控制，日志文件和審查追蹤是可用的。什么時間使用當被保護的資源對于組織具有重要的價值的時候安全性測試目標120功能測試技巧需求測試回歸測試錯誤處理測試支持手冊的測試系統(tǒng)兼容測試控制性測試并行測試功能測試技巧需求測試121需求測試目標用戶的需求可以被實現(xiàn)如何使用創(chuàng)建測試用例和功能檢查列表例子建立測試矩陣去證實系統(tǒng)需求均被文檔化什么時候使用每一個應用程序都要進行需求測試需求測試目標122回歸測試目標程序修改后，確保功能的正確性如何使用重新測試應用程序中沒有改變的部分例子重新執(zhí)行以前的測試用例什么時間使用當新的程序有可能影響老的功能的時候回歸測試目標123錯誤處理測試目標所有可能的錯誤條件均經(jīng)過了驗證如何使用一組有經(jīng)驗的人員預測在那里會出現(xiàn)問題例子建立一個錯誤處理的列表什么時候使用貫穿整個開發(fā)生命周期錯誤處理測試目標124支持手冊測試目標檢驗操作過程被文檔化了，并且完整了。如何使用對過程有足夠的介紹可以協(xié)助用戶正常使用例子系統(tǒng)在一定的條件下產(chǎn)生一個提示，用戶被告知如何采取必要的操作。什么時候使用最佳時機是在安裝測試的時候，但是應該在開發(fā)全過程中。支持手冊測試目標125兼容性測試目標檢驗當使用適當?shù)膮?shù)和數(shù)據(jù)時，需要的信息可以在兩個系統(tǒng)中正確的交換如何使用文件和數(shù)據(jù)被用來在多系統(tǒng)之間傳遞。例子典型的由一個系統(tǒng)到另一個系統(tǒng)的數(shù)據(jù)交換程序。什么時候使用當兩個應用程序之間的參數(shù)有可能發(fā)生變化的時候兼容性測試目標126管理能力測試目標驗證數(shù)據(jù)交換時有足夠的審計追蹤能力如何使用關鍵數(shù)據(jù)或者有價值的數(shù)據(jù)例子從負面來看程序，是否確保了會出錯的條件都被保護了。什么時候使用系統(tǒng)測試的一部分管理能力測試目標127并行測試目的新版本和老版本同時運行，用以確保新版本的程序運行正確。如何使用需要對兩個系統(tǒng)輸入相同的數(shù)據(jù)來運行例子運行新舊兩個工資支付系統(tǒng)什么時間使用當對新系統(tǒng)的的運行情況不確定的時候并行測試目的128單元測試關注單元一級代碼分析和測試功能分析和測試結構分析和測試以錯誤為導向的分析和測試單元測試關注單元一級129測試要素/測試技巧矩陣測試要素壓力執(zhí)行恢復操作復合性安全性需求回歸錯誤處理手工支持系統(tǒng)兼容管理并行單元可靠性√√√√√授權√√√文件完整性√√√√審查追蹤√√√過程連續(xù)性√√√√測試要素/測試技巧矩陣測試要素壓力執(zhí)行恢復操作復合性安全性需130測試要素/測試技巧矩陣測試要素壓力執(zhí)行恢復操作完整性安全性需求回歸錯誤處理手工支持系統(tǒng)兼容管理平行單元服務水平√√√權限控制√一致性√√√√正確性√√√√√√√√易用性√√√√可維護性√√兼容性√√耦合性√√√性能√√√√可操作性√√測試要素/測試技巧矩陣測試要素壓力執(zhí)行恢復操作完整性安全性需131測試工具的選擇測試工具的選擇132測試工具測試標準邊界值分析因果圖檢查表代碼比較對照以編譯為基礎的分析確認/檢查控制流分析測試工具測試標準133測試工具能證明正確性的數(shù)據(jù)以覆蓋為基礎的測試數(shù)據(jù)字典數(shù)據(jù)流分析以設計為基礎的功能測試設計評審桌面檢查災難性測試測試工具能證明正確性的數(shù)據(jù)134測試工具錯誤猜測執(zhí)行的規(guī)則全面的測試實況調(diào)查流程圖檢查,視察使用儀器設備綜合測試設備映射圖測試工具錯誤猜測135測試工具建模并行操作并行模擬代碼互查風險矩陣系統(tǒng)控制的評審得分快照(把系統(tǒng)一個時刻的情況保存下來)測試工具建模136測試工具完成特征系統(tǒng)日志測試用例測試用例的產(chǎn)生形式跟蹤工具程序容量的測試走查(講解開發(fā)思路)測試工具完成特征137選擇和使用測試工具按照用途選擇匹配的工具在適當?shù)纳芷谶x擇工具按照測試人員的實際技能選擇匹配的工具選擇一個可提供的工具選擇和使用測試工具按照用途選擇匹配的工具138測試工具/測試技巧矩陣測試工具壓力執(zhí)行恢復操作完整性安全性需求回歸錯誤處理手工支持系統(tǒng)兼容管理平行單元確認測試標準√√√√邊界值分析√√因果圖√√√√√檢查表√√√√√√√√√√√√代碼比較√√編譯分析√√確認/檢查√√√√√√√√√控制流√證明正確性的數(shù)據(jù)√√√√√√測試工具/測試技巧矩陣測試工具壓力執(zhí)行恢復操作完整性安全性需139測試工具/測試技巧矩陣測試工具壓力執(zhí)行恢復操作完整性安全性需求回歸錯誤處理手工支持系統(tǒng)兼容管理平行單元以覆蓋為基礎的測試√數(shù)據(jù)字典√√數(shù)據(jù)流分析√以設計為基礎的功能測試√設計評審√桌面檢查√√√√√災難性測試√√√錯誤猜測√√√√√√√√√√√√執(zhí)行規(guī)則√全面的測試√√√√√√√測試工具/測試技巧矩陣測試工具壓力執(zhí)行恢復操作完整性安全性需140測試工具/測試技巧矩陣測試工具壓力執(zhí)行恢復操作完整性安全性需求回歸錯誤處理手工支持系統(tǒng)兼容管理平行單元實況調(diào)查√√√√√√√流程圖√√√√√檢查√√√√√√√√√√√√√使用儀器√√√√√√√綜合測試設備√√√√√√√√映射圖√建?！滩⑿胁僮鳌滩⑿心M√代碼互查√√√√√測試工具/測試技巧矩陣測試工具壓力執(zhí)行恢復操作完整性安全性需141測試工具/測試技巧矩陣測試工具壓力執(zhí)行恢復操作完整性安全性需求回歸錯誤處理手工支持系統(tǒng)兼容管理平行單元風險對照表√√系統(tǒng)控制審計評審√√√打分√系統(tǒng)快照√特征執(zhí)行√系統(tǒng)日志√√√√√√√測試數(shù)據(jù)√√√√√√產(chǎn)生測試數(shù)據(jù)√√√√√√跟蹤√工具程序√√√測試工具/測試技巧矩陣測試工具壓力執(zhí)行恢復操作完整性安全性需142測試工具/測試技巧矩陣測試工具壓力執(zhí)行恢復操作完整性安全性需求回歸錯誤處理手工支持系統(tǒng)兼容管理平行單元容量測試√走查√√√√√測試工具/測試技巧矩陣測試工具壓力執(zhí)行恢復操作完整性安全性需143軟件開發(fā)生命周期/測試工具對照表測試工具需求設計編碼測試安裝維護確認測試標準√√邊界值分析√√因果圖√√檢查表√√√√√√代碼比較√編譯分析√基礎復雜度量測試√√控制流分析√驗證、檢查√√√√√√正確性數(shù)據(jù)√√覆蓋測試對照表√√數(shù)據(jù)字典√軟件開發(fā)生命周期/測試工具對照表測試工具需求設計編碼測試安裝144軟件開發(fā)生命周期/測試工具對照表測試工具需求設計編碼測試安裝維護數(shù)據(jù)流分析√設計為基礎的功能測試√√設計評審√桌面檢查√√√√災難性測試√√錯誤猜測√√√√√√執(zhí)行規(guī)范√全面的測試√實況調(diào)查√√√√√√流程圖√√√檢查√√√√√√使用儀器√√√軟件開發(fā)生命周期/測試工具對照表測試工具需求設計編碼測試安裝145軟件開發(fā)生命周期/測試工具對照表測試工具需求設計編碼測試安裝維護綜合測試工具√映射圖√模型√√并行操作√并行模擬√代碼互查√√√√√√風險列表√√系統(tǒng)控制審計評審√打分√√系統(tǒng)快照√完成特征√系統(tǒng)日志√√√軟件開發(fā)生命周期/測試工具對照表測試工具需求設計編碼測試安裝146軟件開發(fā)生命周期/測試工具對照表測試工具需求設計編碼測試安裝維護測試用例√√√√測試用例得產(chǎn)生形式√√跟蹤√√工具程序√√√容量測試√走查√√√軟件開發(fā)生命周期/測試工具對照表測試工具需求設計編碼測試安裝147測試工具管理工具管理者的職責對工具負責幫助同事使用這些工具培訓工具得使用方法負責同工具的廠家聯(lián)系每年給出有關工具使用和購買得計劃工具得升級工具情況報告工具管理者得任期不易太長測試工具管理工具管理者的職責148測試工具管理工具管理者的職責對工具負責幫助同事使用這些工具培訓工具得使用方法負責同工具的廠家聯(lián)系每年給出有關工具使用和購買得計劃工具得升級工具情況報告工具管理者得任期不易太長測試工具管理工具管理者的職責149軟件的測試整個過程估算測試計劃需求設計編碼測試總結安裝，交付維護軟件的測試整個過程估算150估算估算151估算什么測試對軟件工作量的估算的準確性測試評估軟件系統(tǒng)的狀況的準確性關注點：不準確的估算不適當?shù)拈_發(fā)過程不真實的狀態(tài)報告估算什么測試對軟件工作量的估算的準確性152對工作量的估算如何知道對工作量的估算是正確的估算工作量的工具很容易出錯對軟件工作量的估算需要策略五個一般的方法猜加入一些約束條件以一些數(shù)據(jù)為基礎模擬進行工作將一些參數(shù)模型化對工作量的估算如何知道對工作量的估算是正確的153參數(shù)模型法回歸模型：將現(xiàn)有的參數(shù)與已有的歷史數(shù)據(jù)相擬和。啟發(fā)式模型：對歷史數(shù)據(jù)進行觀察和解釋現(xiàn)象模型：假設軟件開發(fā)過程可以依據(jù)一些更廣泛的可適用的過程解釋。參數(shù)模型法回歸模型：將現(xiàn)有的參數(shù)與已有的歷史數(shù)據(jù)相擬和。154模型遵循的共同模式估算軟件的大小將大小轉(zhuǎn)化成人力的估算，并且作出可能的成本的估算依據(jù)項目的特性進行估算的調(diào)整將整體的估算劃分到不同的項目階段中估算不包括技巧上面的人力和計算機的運行時間將以上內(nèi)容相加模型遵循的共同模式估算軟件的大小155對估算進行檢驗檢驗估算模型的合理性檢驗模型是否包含了必須的測試要素檢驗模型的正確性對估算進行檢驗檢驗估算模型的合理性156校驗估算模型的正確性重新進行估算校驗輸入是否正確校驗輸入是否合理校驗對數(shù)據(jù)的計算是否合理有效比較延期的估算是否符合項目實際情況讓謹慎的人來作測試驗證工作對軟件中的冗余價值估算 校驗估算模型的正確性重新進行估算157影響估算正確與否的因素軟件規(guī)模新設計新代碼的比例復雜程度設計和編碼的困難使用什么語言安全性需求的揮發(fā)性影響估算正確與否的因素軟件規(guī)模158影響估算正確與否的因素組織因素項目計劃人員開發(fā)環(huán)境計算機資源人員利用率膨脹因素估算就是估算，不是保證書影響估算正確與否的因素組織因素159軟件進展測試追蹤系統(tǒng)的瓶頸工作完成點同配置管理系統(tǒng)緊密的結合如何使用模塊列表里程碑工作完成點用計算所有工作的完成度來檢查系統(tǒng)工作過程。軟件進展測試追蹤系統(tǒng)的瓶頸160測試計劃測試計劃161開發(fā)測試計劃目標詳細的描述怎樣能成功的完成測試工作，其中應包含必須的資源和實施計劃。可能的不利因素：沒有得到足夠的培訓心里準備不足缺乏測試工具缺乏管理的標準和支持缺乏客戶和最終使用者的參與沒有足夠的時間進行測試對于獨立的測試人員過度信任版本改變的太快測試人員處于不受重視的情況中不能說不開發(fā)測試計劃目標162實施過程聽取各方面的意見和建議標明項目風險測試要素聯(lián)系測試矩陣建立測試計劃對計劃進行評審實施過程聽取各方面的意見和建議163建立測試計劃定義測試目標開發(fā)測試矩陣軟件模型結構特性批量測試的階段和用例為在線系統(tǒng)作概念上的測試腳本軟件測試矩陣定義測試管理測試計劃的一般性信息定義測試里程碑定義管理上的檢查點書寫測試計劃建立測試計劃定義測試目標164評審測試計劃涉及評審的問題評審測試的開始時間是否會延期有沒有抵觸評審的角色一段時間內(nèi)是否很難得到工作的檢查信息。更換工具有可能導致他們反感評審工作評審結果可能會影響對個人的工作評價對于最終成品的檢查項目的需求規(guī)格說明書軟件返工/維護的文檔升級后的技術文檔被更改的源程序測試計劃用戶手冊（包括在線幫助）評審測試計劃涉及評審的問題165評審測試計劃正式評審中的角色緩和劑（SQA）讀者記錄者作者檢測員正式評審發(fā)現(xiàn)的缺陷應包含的信息起因類型分類級別評審測試計劃正式評審中的角色166評審流程計劃和組織通篇的講解（可選）個人準備評審會議修訂和反復評審流程計劃和組織167需求階段的測試需求階段的測試168測試成本在軟件開發(fā)的所有階段進行測試被設計用來減少測試成本IBM的數(shù)據(jù)大約60個缺陷/千行2/3的缺陷產(chǎn)生在需求和設計階段在需求和設計階段發(fā)現(xiàn)的缺陷修正的花費最小修正系統(tǒng)測試階段發(fā)現(xiàn)的缺陷，花費是以上的10倍發(fā)布產(chǎn)品以后，修正缺陷的花費是原來的100倍測試成本在軟件開發(fā)的所有階段進行測試169生命周期的測試概念在軟件開發(fā)過程中持續(xù)的進行測試在盡可能早的階段點去修正缺陷需要正式的開發(fā)流程來支持組建測試團隊當開發(fā)開始進行的時候，測試就開始進行了生命周期的測試概念在軟件開發(fā)過程中持續(xù)的進行測試170需求階段的測試準備風險列表確定風險組確定風險風險分析風險檢查表建立控制目標確定有足夠的控制力度需求階段的測試準備風險列表171分析測試要素需求的設計是否遵循了已定義的方法提交了已定義的功能說明定義了系統(tǒng)界面已經(jīng)估計了性能標準容忍度被預先估計預先定義了權限規(guī)則需求中預先定義了文件完整性預先定義了需求的變更流程預先定義了失敗的影響權限定義分析測試要素需求的設計是否遵循了已定義的方法172需求走查建立基本規(guī)則選擇小組/通報參與者項目介紹問題/建議形成最終報告需求走查建立基本規(guī)則173需求階段測試所有的花費都是值得的大部分缺陷將不會進入到設計&編碼階段目標需求正確的表現(xiàn)出了用戶的需要需求已經(jīng)被定義和文檔化了花費和收益成正比需求的控制被明確有合理的流程可遵循有合理的方法可供選擇需求階段測試所有的花費都是值得的174設計階段的測試設計階段的測試175設計階段的測試交付的產(chǎn)品輸入說明過程說明文件說明輸出說明控制說明系統(tǒng)流程圖硬件和軟件的需求操作手冊說明書數(shù)據(jù)保留的策略設計階段的測試交付的產(chǎn)品176設計階段測試任務給測試要素打分分析測試要素對設計進行評審檢查修改的部分設計階段測試任務給測試要素打分177分析測試要素測試涉及的內(nèi)容：設計了對數(shù)據(jù)完整性的控制設計了權限規(guī)則設計了對文件完整性的控制設計了審計追蹤設計了發(fā)生意外情況時的計劃設計了如何達到服務水平的方法定義了權限流程定義了完整的方法學設計了保證需求一致性的方法進行了易用性的設計設計是可維護的設計是簡單的交互界面設計完畢定義了成功的標準需要同實際操作者溝通分析測試要素測試涉及的內(nèi)容：178對設計進行評審選擇評審組成員對評審組進行培訓通報項目組分配足夠的時間只對文檔化的事實進行評審和項目組一起進行評審對評審形成建議和項目組對建議一起進行評審準備正式的報告對設計進行評審選擇評審組成員179編碼階段的測試編碼階段的測試180形成的輸出編碼說明書程序文檔計算機程序列表可執(zhí)行的程序程序流程圖操作介紹單元測試結果形成的輸出編碼說明書181測試活動的關注點完成對數(shù)據(jù)完整性的控制定義完畢授權的規(guī)則完成對文件完整性的控制實現(xiàn)審計追蹤規(guī)劃出意外情況發(fā)生后的處理計劃對系統(tǒng)如何達到預定義的服務水平做了計劃完成了對安全問題的處理流程編碼工作是依據(jù)規(guī)定的方法完成的編碼與設計相一致（正確性）編碼與設計相一致（易用性）代碼是可維護的編碼與設計相一致（簡潔性）編碼與設計相一致（耦合性）已開發(fā)了操作流程定義出程序成功的標準（性能上）測試活動的關注點完成對數(shù)據(jù)完整性的控制182測試的職責編碼是一個純技術的工作，幾乎不需要用戶的參與項目領導者有參與測試的責任監(jiān)督過程的有效性測試的職責編碼是一個純技術的工作，幾乎不需要用戶的參與183建議的測試方式桌面調(diào)試語法上的結構上的功能上的代碼互查建立基本的互查規(guī)則選擇互查的team對成員進行培訓選擇互查的方法提供互查的材料流程圖，源程序，典型的處理流程對互查進行必要的管理給出互查結論提供最終的報告建議的測試方式桌面調(diào)試184編碼階段的測試需解決的問題系統(tǒng)是可維護的嗎？系統(tǒng)說明是否已經(jīng)完成了？編碼是否按照既有的標準進行，過程是否易于實踐？是否有足夠的測試計劃用來評估可執(zhí)行的程序？是否編制了足夠的文檔。編碼階段的測試需解決的問題系統(tǒng)是可維護的嗎？185測試關注點在需求，設計，編碼階段多進行一些測試，在系統(tǒng)測試階段就會少一些問題。文檔測試階段的測試計劃測試用例前期測試的測試結果第三方測試反饋，例如：計算機操作人員正式的測試總結報告測試關注點在需求，設計，編碼階段多進行一些測試，在系統(tǒng)測試階186典型測試類型手冊，回歸，功能點測試一致性測試（授權）功能點測試（完整性）功能點測試（審計，追蹤）覆蓋性的測試（測試的連續(xù)性）壓力測試（服務水平）一致性測試（安全性）依照預先定義的測試方法功能點測試（正確性）支持手冊的測試（易用性）檢查（可維護性）災難性的測試（可攜帶性）功能和回歸測試（耦合性）一致性的測試（性能）操作性的測試（易用性）典型測試類型手冊，回歸，功能點測試187建議測試方法測試方法測試用例的概念是簡單的建立有效的測試用例是復雜的設計測試文件測試用例應當包含合法的和非法的輸入每一個動作只進行一次關鍵操作輸入測試數(shù)據(jù)分析結果嘗試將測試文件違反程序的規(guī)則進行輸入容量測試的測試工具以大信息量的數(shù)據(jù)進行輸入這是一個昂貴的測試，應根據(jù)需要來選擇在線系統(tǒng)需要做壓力測試建議測試方法測試方法188測試總結測試總結189測試報告目標表示出目前項目的實際狀況明確什么是測試做的工作，什么是不作的工作。給出系統(tǒng)的操作性能的評價明確什么時候系統(tǒng)可以進行產(chǎn)品化的工作關注點測試報告只有真正需要的時候才有用，需要配合市場和管理測試的信息是不充分的（對于評價一個項目來說）測試狀況并不能真實的反應個人的狀況測試報告目標190測試期間數(shù)據(jù)的收集有關測試結果的積累數(shù)據(jù)測試任務，測試集合和測試事件的描述缺陷分析由于計劃的問題，導致沒有發(fā)現(xiàn)的缺陷的數(shù)據(jù)嚴重的缺陷缺陷類型為什么缺陷沒有發(fā)現(xiàn)效果測試期間數(shù)據(jù)的收集有關測試結果的積累數(shù)據(jù)191測試報告報告目前的軟件狀態(tài)功能/測試矩陣功能測試的狀態(tài)報告，側(cè)重點分析關于功能的工作時間軸期望發(fā)現(xiàn)VS實際發(fā)現(xiàn)的缺陷比沒有發(fā)現(xiàn)的缺陷和改正的缺陷的差距按照類型分類，沒有改正的缺陷的平均值缺陷分類報告測試活動報告測試報告報告目前的軟件狀態(tài)192最終的報告匯總各個階段的項目測試總結報告繼承性測試報告系統(tǒng)測試報告確認測試報告最終的報告匯總各個階段的項目測試總結報告193軟件測試培訓資料軟件測試培訓資料194內(nèi)容軟件測試理論基礎軟件測試流程軟件項目運作流程軟件測試工作流程軟件測試用例設計方法軟件缺陷測試的技巧測試工具的選擇軟件的測試整個過程內(nèi)容軟件測試理論基礎195軟件測試理論基礎軟件測試理論基礎196測試行業(yè)簡介軟件測試在軟件生命周期中占據(jù)重要作用。軟件生命周期的每個階段都應該包含測試從而檢驗本階段的成果是否接近預期的目標，盡可能早的發(fā)現(xiàn)錯誤并加以修正。由于測試的重要性和復雜度，它慢慢的獨立發(fā)展成為一個行業(yè)，并且在迅猛發(fā)展。在典型的軟件開發(fā)項目中，軟件測試工作量往往占軟件開發(fā)總工作量的40％以上。而在軟件開發(fā)的總成本中，用在測試上的開銷要占30％到50％測試行業(yè)簡介軟件測試在軟件生命周期中占據(jù)重要作用。197軟件測試概論（概述）1975年，“測試數(shù)據(jù)選擇的原理”（TowardatheoryofTestData