軟件測試與質量控制教程1-8.doc

精品文檔軟件工程軟件測試與質量控制教程1-8全集鍵入作者姓名選取日期在此處鍵入文檔摘要。摘要通常為文檔內容的簡短概括。在此處鍵入文檔摘要。摘要通常為文檔內容的簡短概括。目錄軟件測試與質量控制 教程14概述4什么是軟件測試4為什么要做軟件測試4軟件測試人員做什么4軟件測試環(huán)境4軟件缺陷有哪些4什么是測試用例5軟件測試分類5靜態(tài)測試和動態(tài)測試5黑盒測試和白盒測試5單元測試、集成測試、系統(tǒng)測試和驗收測試5功能測試和性能測試6回歸測試和冒煙測試6軟件測試分類關系6軟件配置管理7軟件測試管理7組織管理8計劃管理8用例管理9文檔管理10軟件測試與質量控制 教程210概述10測試需求概念10測試需求分析工作步驟10小結11項目說明11軟件測試與質量控制 教程311概述11測試計劃主要內容11項目說明13軟件測試與質量控制 教程413概述13黑盒測試方法13等價類劃分法14劃分步驟14劃分方法14等價類劃分法測試用例設計原則14實例分析15邊界值分析法16確定邊界16邊界值分析法測試用例設計原則16實例分析16因果圖法17為什么要用因果圖18因果圖符號和概念18實例分析19錯誤推測法22不同測試方法選擇原則22項目說明23軟件測試與質量控制 教程523概述23缺陷分類23缺陷描述24缺陷處理流程26項目說明27軟件測試與質量控制 教程627概述27自動化測試工具分類27自動化測試工具一覽28WinRunner功能測試工具30項目說明30軟件測試與質量控制 教程731概述31代碼檢查31白盒測試方法31邏輯覆蓋法31語句覆蓋32判定覆蓋32條件覆蓋32判定條件覆蓋32條件組合覆蓋32路徑覆蓋32各種邏輯覆蓋之間關系32基本路徑法33控制流圖33復合條件分解34環(huán)形復雜度34基本路徑法測試用例設計步驟35實例分析35軟件測試與質量控制 教程837概述37測試報告主要內容37項目說明38軟件測試與質量控制 教程1概述軟件測試是IT行業(yè)的一項職業(yè)性活動。對應的工作崗位有軟件測試工程師、測試經理等崗位，另外軟件開發(fā)工程師也需要掌握單元測試的有關內容。軟件測試過程伴隨軟件開發(fā)過程始終。作為一名職業(yè)軟件測試人員，有必要對軟件測試的基礎知識有所了解。什么是軟件測試軟件測試就是發(fā)現并指出軟件中存在缺陷的過程。這里所說的軟件既包括運行程序也包括軟件設計開發(fā)過程中產生的需求、設計等相關文檔以及編碼過程中產生的源程序代碼。為什么要做軟件測試傳統(tǒng)行業(yè)都有質量檢查環(huán)節(jié)，對生產出來的產品進行質量檢驗，以確保生產出的產品是合格的。軟件產品的質量檢驗是通過軟件測試來完成的。軟件設計開發(fā)過程中可能會出現很多問題，需要通過軟件測試手段來發(fā)現軟件缺陷，保證軟件質量。軟件測試人員做什么軟件測試人員的目標就是盡可能早的找出軟件缺陷，并確保其得到修復。軟件測試人員的主要工作包括制定測試計劃、設計測試用例、執(zhí)行測試、對發(fā)現的缺陷進行跟蹤管理、對測試結果進行分析總結等內容。軟件測試環(huán)境軟件測試環(huán)境就是軟件運行的平臺，包括軟件、硬件和網絡。硬件主要包括PC機、筆記本、服務器、各種PDA終端設備等。軟件主要是指軟件運行的操作系統(tǒng)，數據庫管理系統(tǒng)，Web服務器、瀏覽器等。網絡主要針對的是C/S結構和B/S結構的軟件所使用的網絡設備情況(類型、速度等)。軟件缺陷有哪些軟件出現的故障我們一般叫軟件缺陷，符合以下5條規(guī)則的情況都可以稱為軟件缺陷：1. 軟件未達到產品說明書標明的功能；2. 軟件出現了產品說明書指明不會出現的錯誤；3. 軟件功能超出產品說明書指明范圍；4. 軟件未達到產品說明書雖未指明但應達到的目標；5. 軟件測試人員認為軟件難以理解、不易使用、運行速度緩慢或者最終用戶認為不好。什么是測試用例測試用例是測試執(zhí)行的依據，是指在測試執(zhí)行之前設計的一套詳細的測試方案，包括測試環(huán)境、測試步驟、測試數據和期望結果。軟件測試分類人們根據測試目的和測試角度的不同將軟件測試分成眾多的類別。我們經常聽到諸如靜態(tài)測試、動態(tài)測試、黑盒測試、白盒測試、單元測試、集成測試等名詞。作為一名軟件測試人員，我們有必要了解這些軟件測試分類的具體內容。靜態(tài)測試和動態(tài)測試軟件測試按照是否需要運行程序可以分為靜態(tài)測試和動態(tài)測試。靜態(tài)測試是指不實際運行被測軟件，只是靜態(tài)地檢查程序界面、文檔和源程序代碼中可能存在的錯誤的過程。其中代碼測試主要測試源代碼是否符合相應的標準和規(guī)范；界面測試主要測試軟件的實際界面與需求中的說明是否相符；文檔測試主要測試用戶使用手冊和需求說明是否真正符合用戶的實際需求。動態(tài)測試是指實際運行被測軟件，輸入相應的測試數據，檢查實際輸出結果和預期結果是否相符的過程。黑盒測試和白盒測試軟件測試按照是否需要了解程序內部結構可以分為黑盒測試和白盒測試。黑盒測試是指把被測軟件當作是一個黑盒子，測試人員不需要知道盒子里面的結構，只關心軟件的輸入數據和輸出結果，設計相應測試用例測試軟件的過程。白盒測試是相對黑盒測試來說的。是指把被測軟件當作是一個透明盒子，測試人員需要知道被測軟件的程序結構，然后設計相應測試用例測試軟件的過程。黑盒測試和白盒測試都有相應的測試用例設計方法，后續(xù)我們將進行詳細介紹。單元測試、集成測試、系統(tǒng)測試和驗收測試軟件測試按測試階段可以分為單元測試、集成測試、系統(tǒng)測試和驗收測試。單元測試是指對軟件中的最小可測試單元進行檢查和驗證。最小可測試單元可以是函數(面向過程程序)，也可以是類(面向對象程序) ，需要根據實際情況具體分析。單元測試在編碼完成程序編譯之后執(zhí)行，一般由軟件開發(fā)人員完成。單元測試依據程序的源代碼和詳細設計文檔，主要采用白盒測試方法，先檢查代碼編寫規(guī)范性(靜態(tài)測試)，然后運行代碼，檢查實際運行結果(動態(tài)測試)。單元測試一般需要編寫測試程序對程序模塊進行測試。集成測試是單元測試的下一階段，是指將通過測試的單元模塊組裝成系統(tǒng)或子系統(tǒng)，再進行測試，主要測試不同模塊的接口部分。集成測試的目的是檢查各個單元模塊集成在一起后是否能正常運行。集成測試在單元測試完成后執(zhí)行，一般由軟件開發(fā)人員和軟件測試人員共同完成。集成測試依據單元測試的模塊和概要設計文檔，采用白盒和黑盒測試方法。集成測試可以采用增量和非增量兩種方式進行。增量式集成是指按照一定次序(自頂至下或自底向上)逐步集成程序，這種測試方式需要編寫測試程序。非增量式集成是指一次性把所有程序模塊集成為一個完整系統(tǒng)，這種測試方式不需要編寫測試程序。系統(tǒng)測試是集成測試的下一階段，是指將整個軟件系統(tǒng)看作一個整體進行測試，包括功能測試、性能測試以及軟件所運行的軟硬件環(huán)境兼容性測試等內容。系統(tǒng)測試在集成測試完成后執(zhí)行，由軟件測試人員完成。系統(tǒng)測試主要依據軟件需求文檔，采用黑盒測試方法。先測試系統(tǒng)的功能是否滿足需求，然后測試系統(tǒng)的性能是否滿足需求，最后測試系統(tǒng)在不同軟硬件環(huán)境中的兼容性。驗收測試在系統(tǒng)測試完成后執(zhí)行，測試內容包含系統(tǒng)測試的內容，另外還包括對用戶文檔的測試。驗收測試的測試人員以用戶為主。功能測試和性能測試軟件測試按測試內容可以分為功能測試和性能測試。功能測試是黑盒測試的一個方面，主要檢查待測軟件的功能是否滿足用戶的需求。功能測試可以細分為邏輯功能測試、界面測試、易用性測試、安裝測試和兼容性測試等內容。功能測試可以使用自動化測試工具進行。后續(xù)第13章將介紹WinRunner功能測試開發(fā)內容。性能測試是黑盒測試的另一個方面，主要檢查待測軟件的性能是否滿足用戶的需求。性能測試可以細分為一般性能測試、穩(wěn)定性測試、負載測試和壓力測試等內容。性能測試一般使用自動化測試工具進行?；貧w測試和冒煙測試回歸測試和冒煙測試是兩個不相干的概念，我們單獨描述?；貧w測試是指測試過程中對軟件的新版本進行測試時，重復執(zhí)行上一個版本測試時的測試用例。回歸測試在集成測試階段進行。冒煙測試是指在對一個軟件新版本進行系統(tǒng)大規(guī)模的測試之前，先驗證一下軟件的基本功能是否實現，是否具備可測性。冒煙測試一般在系統(tǒng)測試之前進行。軟件測試分類關系前面我們對常見的軟件測試分類進行了簡單介紹。這么多的測試分類，看上去很復雜，實際上只是分類角度有所不同。同一種測試，按照不同角度劃分，可以屬于不同的測試分類。下圖描述了這些測試分類之間的關系。軟件配置管理在一個實際的軟件開發(fā)項目中，軟件開發(fā)過程產生的各種產品必須納入軟件配置管理范圍。軟件測試人員在測試過程中往往需要對各種開發(fā)測試產品(文檔、代碼等)進行各種配置管理操作，例如從配置庫獲取配置項，將創(chuàng)建的測試產品添加到配置庫等操作。軟件配置管理(測試相關)項目主要教學生使用微軟公司的配置管理工具Microsoft Visual SourceSafe(VSS)，要求學生完成以下工作任務：使用VSS建立項目配置庫和各個配置項，對新建配置庫進行用戶權限管理，對新建配置庫進行配置項出入庫操作。項目的工作場景一般是企業(yè)的各個項目組或者獨立的測試部門。項目目的主要是培養(yǎng)學生使用配置管理工具執(zhí)行與軟件測試相關的操作能力。該項目能為測試員、測試工程師、測試經理、SCM以及軟件開發(fā)這些崗位的相關工作提供幫助。軟件測試管理軟件測試管理就是以測試項目為管理對象，通過一個臨時性的專門的測試組織，運用專門的軟件測試知識、技能、工具和方法，對測試項目進行計劃、組織、執(zhí)行和控制，并在時間成本、軟件測試質量等方面進行分析和管理活動。軟件測試管理貫穿整個測試項目的生命周期，是對測試項目的全過程進行管理。組織管理測試項目成功完成的關鍵因素之一就是要有高素質的軟件測試人員，并將他們有效地組織起來，分工合作，形成一支精干的隊伍，使他們發(fā)揮出最大的工作效率。測試的組織與人員管理就是對測試項目相關人員在組織形式、人員組成與職責方面所做的規(guī)劃和安排。組織結構是指用一定的模式對責任、權威和關系進行安排，直至通過這種結構發(fā)揮功能。進行軟件測試的測試組織結構形式很多，目前常見的測試組織結構有獨立的測試小組和集成的測試小組兩種形式。1. 獨立測試小組2. 集成測試小組獨立的測試小組，即主要工作是進行測試的小組，他們專門從事軟件的測試工作。測試組設組長一名，負責整個測試的計劃、組織工作。測試組的其他成員由具有一定的分析、設計和測試經驗的專業(yè)人員組成，人數根據具體情況可多可少，一般35人為宜。測試組長與開發(fā)組長在項目中的地位是同級、平等的關系。集成測試小組是將測試與基本設計因素組合起來，構成的測試組織結構。這是與獨立測試有關的一種集成測試組織形式，即集成測試小組是由需要向同一個項目經理匯報工作的測試人員和開發(fā)人員組成。計劃管理測試計劃就是描述所有要完成的測試工作，包括被測試項目的背景、目標、范圍、方式、資源、進度安排、測試組織，以及與測試有關的風險等方面。測試計劃制定及管理的主要工作內容如下：1. 結合已批準的軟件系統(tǒng)測試需求及所使用的測試工具，測試負責人與項目經理協(xié)商，逐步確定測試項目的測試目標、范圍、粒度(覆蓋標準)以及測試方案(包括各個測試階段的出入口準則的協(xié)商)，在初步估計測試項目規(guī)模及工作量的基礎上，協(xié)助測試項目開發(fā)計劃書的可行性；2. 基于項目的系統(tǒng)功能集成方案及系統(tǒng)版本發(fā)布計劃，配合項目經理逐步細化項目計劃中的階段小版本創(chuàng)建和發(fā)布里程碑點，并逐步細化測試方案及測試規(guī)模估計；3. 策劃測試實施前準備內容、資源安排(包括人員分配，進度安排等，尤其要留有合理的測試Bug、用例管理時間)，細化項目測試計劃相關內容；4. 測試負責人必要時還須與項目經理根據項目特性，確定系統(tǒng)冒煙測試的范圍，粒度以及入口接受標準等內容，細化項目測試方案相關內容；5. 形成系統(tǒng)測試計劃書(可包括單元、集成、系統(tǒng)階段)并提交評審，按項目評審規(guī)程執(zhí)行；6. 當項目開發(fā)計劃或測試需求發(fā)生變更時，按配置管理過程執(zhí)行。用例管理測試用例及管理的工作任務是根據批準的測試需求及方案，策劃測試過程執(zhí)行依據，確保測試范圍有效并正確。測試用例設計及管理的主要工作內容如下：用例設計：1. 參與需求評審，正確理解系統(tǒng)需求并確認需求的可測性，獲取測試項目需求；2. 根據批準的測試項目需求，測試目標的邏輯實現和約束，測試工具及其測試環(huán)境等限制條件，確定系統(tǒng)的測試中自動和手動測試的范圍，并分別編寫系統(tǒng)測試用例；3. 參與系統(tǒng)設計，協(xié)助驗證系統(tǒng)體系結構及其邏輯實現層次的合理性，功能模塊間的內部及其接口的正確性，結合系統(tǒng)功能集成方案，編寫集成測試用例；4. 測試負責人或項目經理需針對系統(tǒng)體系結構設計方案、系統(tǒng)功能集成方案、系統(tǒng)版本發(fā)布計劃以及項目開發(fā)計劃等內容，組織編寫創(chuàng)建腳本和冒煙測試用例；5. 測試負責人或項目經理負責基于系統(tǒng)的詳細設計，確定單元測試范圍和粒度，有效路徑和值域等，組織單元測試中自動和手動測試用例的編寫；6. 測試負責人或項目經理負責按測試用例編寫要求、需求跟蹤矩陣表完成編寫符合性和需求覆蓋性、有效性、完整性檢查，并參照項目評審規(guī)程實施評審活動；7. 當項目測試需求發(fā)生變更時，按配置管理過程執(zhí)行。用例管理：1. 測試負責人或項目經理負責進行階段測試用例的實施、跟蹤及用例統(tǒng)計分析工作，及時改進測試用例管理活動；2. 測試負責人或項目經理實時或定期根據Bug數據、狀態(tài)和測試用例執(zhí)行情況進行分析，以確定是否需要對目前測試的模塊新增設計新的測試用例：a) 對不穩(wěn)定的模塊，測試負責人負責與項目經理多次討論確定測試范圍、粒度和執(zhí)行方案等，并制定測試人員完成新增測試用例的編寫；b) 對極其不穩(wěn)定或未能達到測試入口標準的模塊，則要求退回開發(fā)部重新開發(fā)；3. 由測試負責人和項目經理負責進行測試用例的完整性和有效性檢查后，組織討論新增測試用例，批準后由測試人員或開發(fā)人員執(zhí)行；文檔管理測試文檔是對要執(zhí)行的軟件測試及測試的結果進行描述、定義、規(guī)定和報告的任何書面或圖示信息。由于軟件測試是一個很復雜的過程，同時也涉及到軟件開發(fā)中其他一些階段的工作，因此，必須把對軟件測試的要求、規(guī)劃、測試過程等有關信息和測試的結果，以及對測試結果的分析、評價，以正式的文檔形式給出。測試文檔對于測試階段工作的指導與評價作用更是非常明顯的。需要特別指出的是，在已開發(fā)的軟件投入運行的維護階段，常常還要進行再測試或回歸測試，這時還會用到測試文檔。測試文檔的編寫是測試管理的一個重要組成部分。根據測試文檔所起的不同作用，通常把它分成兩類，即前置作業(yè)文檔和后置作業(yè)文檔。測試計劃及測試用例的文檔屬于前置作業(yè)文檔。 后置作業(yè)文檔是在測試完成后提交的，主要包括軟件缺陷報告和分析總結報告。軟件測試與質量控制 教程2概述測試需求分析是軟件測試工作的首要工作任務，該項工作任務在項目開發(fā)階段需求分析基本完成時切入。測試組人員需要參與開發(fā)項目的需求評審，確定項目的測試需求。測試需求分析的工作產品是測試需求文檔。測試需求概念確切地講，所謂的測試需求就是在項目中要測試什么。我們在測試活動中，首先需要明確測試需求(What)，才能決定怎么測(How)，測試時間(When)，需要多少人(Who)，測試的環(huán)境是什么(Where)，測試中需要的技能、工具以及相應的背景知識，測試中可能遇到的風險等等，以上所有的內容結合起來就構成了測試計劃的基本要素。而測試需求是測試計劃的基礎與重點。 就像軟件的需求一樣，測試需求根據不同的公司環(huán)境，不同的專業(yè)水平，不同的要求，詳細程度也是不同的。但是，對于一個全新的項目或者產品，測試需求力求詳細明確，以避免測試遺漏與誤解。測試需求，簡單理解就是測試人員要對哪些點進行測試。測試需求的內容由軟件測試人員根據用戶需求說明書和開發(fā)設計說明書整理編寫。依據軟件需求規(guī)格說明書中相關內容，將系統(tǒng)要實現的功能點羅列出來，測試需求就是這些羅列出來的功能點。測試需求分析工作步驟我們來總結一下測試需求分析的一般步驟：1. 閱讀需求規(guī)格說明書，找出與指定功能相關的描述內容。2. 列出描述內容中所有直接提及要實現的功能點3. 根據說明書內容，查找是否存在文檔中未提及但是需要達到的功能點，有則列出來4. 將列出的內容整理成測試需求文檔小結測試需求分析工作是一個細致活，需要測試人員有足夠的耐心和細心，對功能點的羅列不能太粗，要盡量具體、完整。根據羅列的功能點整理測試需求列表時，一般來說功能點與測試點是一對一的關系。但是可以根據實際情況進行適當的歸納合并或整理細化?？偟膩碚f測試需求列表不能太籠統(tǒng)，要具體、詳細、可測試。這是測試需求分析工作中要重點注意的。項目說明測試需求分析項目主要教學生理解分析軟件需求說明文檔，整理獲得測試需求，編寫測試需求文檔，為制定測試計劃做好準備。學生要求完成以下工作任務：分析ATM模擬系統(tǒng)軟件需求說明書，整理系統(tǒng)的功能測試需求，編寫測試需求文檔。項目的工作場景一般是企業(yè)的各個項目組或者獨立的測試部門。項目目的主要是培養(yǎng)學生準確獲取測試需求的能力。該項目能為測試員、測試工程師、測試經理這些崗位的相關工作提供幫助。軟件測試與質量控制 教程3概述測試計劃制定就是根據之前確認的測試需求，確定項目測試階段的目標和策略，確保測試工作有序、有效進行。測試計劃的制定工作一般由測試經理牽頭執(zhí)行，一般測試人員只是協(xié)助工作。測試計劃主要內容(1)測試環(huán)境確保項目測試環(huán)境符合測試要求，減少嚴重影響測試結果的真實性和正確性風險。包括：硬件環(huán)境：指測試必需的服務器、客戶端、網絡連接設備，以及打印機/掃描儀等輔助硬件設備所構成的環(huán)境；軟件環(huán)境：指被測軟件運行時的操作系統(tǒng)、數據庫及其他應用軟件構成的環(huán)境，包括版本及補丁號。在實際測試中，可遵循下列原則：1) 符合軟件運行的最低要求，首先要保證能支撐軟件正常運行；2) 選用比較普及的操作系統(tǒng)和軟件平臺。3) 營造相對簡單、獨立的測試環(huán)境。4) 無毒的環(huán)境。利用有效的正版殺毒軟件檢測測試環(huán)境以確保其沒有病毒。測試工具：指測試過程使用的所有測試工具、測試管理工具等，包括工具名、版本、生產廠商、用途。(2)測試方案對測試階段進行劃分，說明各測試階段的目標、工作內容、管理方法、采用的樣式、出口標準、停止標準、選取測試用例的原則等。(3)測試需求列出每一項測試需求名稱、內容、目的。(4)測試優(yōu)先級說明測試階段或測試項的優(yōu)先順序和測試的重點內容。(5)測試機構及人員測試機構名稱、測試組成員和職責。(6)進度 說明各測試階段活動的詳細時間、人員、工作量安排，包括計劃、管理、測試、熟悉環(huán)境和工具、準備輸入數據、校驗輸出結果等時間。測試階段測試活動計劃開始時間計劃開始時間測試人員預計工作量（人天數）備注(7)問題響應要求問題分類問題嚴重程度響應時間立即解決程序錯誤，影響繼續(xù)測試高度關注問題嚴重普通排隊一般問題低優(yōu)先級建議性問題(8)測試風險預估序號風險內容描述優(yōu)先級影像度（I）概率（P）緩解策略(9)測試風險管理說明風險管理的責任人，風險跟蹤與管理的周期、方法等。(10)評價說明所選擇的測試用例能檢查的范圍及局限性。說明用來判斷測試工作是否能通過的評價尺度，如合理的輸出結果的類型，量值范圍等。描述測試完成后應提交的文檔。如：測試計劃書、測試用例、測試問題報告、測試分析報告等。項目說明制定測試計劃項目主要教學生修改整理已有的測試計劃草稿文檔，對完成的測試計劃文檔進行評審，形成基線，納入軟件配置管理。整個項目分成兩個模塊完成，模塊一為編寫測試計劃書，模塊二為測試計劃評審。要求學生完成以下工作任務：按要求修改補充已有的測試計劃草稿文檔內容，為測試計劃評審準備評審文檔，分角色參與測試計劃評審工作，將評審后的文檔形成基線，納入配置庫管理。項目的工作場景一般是企業(yè)的各個項目組或者獨立的測試部門。項目目的主要是培養(yǎng)學生對測試過程的整體把握能力，讓學生熟悉項目評審環(huán)節(jié)的各項工作。該項目能為測試經理、測試員、測試工程師、SQA和SCM這些崗位的相關工作提供幫助。軟件測試與質量控制 教程4概述在測試執(zhí)行之前，測試人員需要設計一套詳細的測試方案，測試方案的核心內容就是測試用例，測試用例是測試執(zhí)行的最小單位，一般包括測試環(huán)境、測試步驟、測試數據和預期結果幾部分的內容。測試用例設計是軟件測試活動最重要的工作之一。根據測試階段的不同，測試用例設計又分為單元測試用例設計、集成測試用例設計以及系統(tǒng)測試用例設計等多項內容。本課程主要關注的是集成測試用例設計和系統(tǒng)測試用例設計中的功能測試用例設計內容。其他測試用例設計內容會放在后續(xù)的軟件綜合項目開發(fā)課程中學習。黑盒測試方法黑盒測試方法用來設計系統(tǒng)測試用例。常用的黑盒測試方法有等價類劃分法、邊界值分析法、因果圖法、決策表法、正交實驗法、錯誤推測法等等價類劃分法我們都知道，最理想的測試方法是窮舉測試，即測試所有可能的情況。但是在實際工作中由于數據量較大或者數據域本身就是無窮的而無法進行窮舉測試。這時候我們一般考慮對輸入數據的范圍進行有限劃分，從每個劃分類別中選取一個有代表性的測試數據進行測試，就等同于對這個劃分類別的其他數據進行測試。等價類劃分法是一種黑盒測試方法。等價類是指某個輸入域的子集，在該子集中，各個輸入數據對于揭露軟件中的錯誤都是等效的。等價類可以分為有效等價類和無效等價類。其中有效等價類是符合需求規(guī)格說明書的合理輸入數據集合，無效等價類是不符合需求規(guī)格說明書的無意義的輸入數據集合。劃分步驟等價類劃分可以按以下步驟進行：(1)先考慮輸入數據的數據類型(合法類型和非法類型)；(2)再考慮數據范圍(合法類型中的有效區(qū)間和無效區(qū)間)；(3)用表格方法列舉所有的等價類，為每一個等價類編號。劃分方法常見的等價類劃分方法有以下幾種情況：(1)在輸入條件規(guī)定了取值范圍或值的個數的情況下,則可以確立一個有效等價類和兩個無效等價類。(2)在輸入條件規(guī)定了輸入值的集合或者規(guī)定了必須如何的條件的情況下,可確立一個有效等價類和一個無效等價類。(3)在輸入條件是一個布爾量的情況下,可確定一個有效等價類和一個無效等價類。(4)在規(guī)定了輸入數據的一組值（假定n個）,并且程序要對每一個輸入值分別處理的情況下,可確立n個有效等價類和一個無效等價類。(5)在規(guī)定了輸入數據必須遵守的規(guī)則的情況下,可確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。(6)在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下,則應再將該等價類進一步的劃分為更小的等價類。等價類劃分法測試用例設計原則用等價類劃分法設計測試用例應該遵循以下原則：(1)設計一個新的測試用例,使其盡可能多地覆蓋尚未被覆蓋地有效等價類,重復這一步，直到所有的有效等價類都被覆蓋為止；(2)設計一個新的測試用例,使其僅覆蓋一個尚未被覆蓋的無效等價類,重復這一步，直到所有的無效等價類都被覆蓋為止。實例分析設有一個檔案管理系統(tǒng)，要求用戶輸入以年月表示的日期。假設日期限定在2013年1月2113年12月，并規(guī)定日期由6位數字字符組成，前4位表示年，后2位表示月?，F用等價類劃分法設計測試用例，來測試程序的日期檢查功能。(1)劃分等價類并編號,等價類劃分的結果如表3.1所示。表3.1等價類列表輸入條件有效等價類編號無效等價類編號日期的類型及長度6位數字字符1有非數字字符2少于6位數字字符3多于6位數字字符4年份范圍在20132113之間5小于20136大于21137月份范圍在0112之間8等于009大于1210(2)設計測試用例，以便覆蓋所有的有效等價類在表中列出了3個有效等價類，編號分別為1、5、8，設計的測試用例如下：表3.2有效等價類測試用例測試數據期望結果覆蓋的有效等價類201309輸入有效1、5、8(3)為每一個無效等價類設計一個測試用例，設計結果如下：表3.3無效等價類測試用例測試數據期望結果覆蓋的無效等價類13June無效輸入22013無效輸入320130102無效輸入4201212無效輸入6211401無效輸入7201500無效輸入9201314無效輸入10邊界值分析法長期的測試工作經驗告訴我們，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是發(fā)生在輸入輸出范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。確定邊界使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況。應當選取正好等于，剛剛大于或剛剛小于邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。常見的邊界值有以下幾種情況：(1)對16-bit的整數而言32767和-32768是邊界。(2)屏幕上光標在最左上、最右下位置。(3)報表的第一行和最后一行。(4)數組元素的第一個和最后一個。(5)循環(huán)的第0次、第1次和倒數第2次、最后一次。邊界值分析法測試用例設計原則用邊界值分析法設計測試用例應遵循以下原則：對于一個含有n個變量的程序，應保留其中一個變量，其余的變量取正常值，被保留的變量取邊界和邊界附近的值，對每個變量重復進行上述取值方法，設計測試用例。實例分析NextDate函數包含三個變量：month、day和year，函數的輸出為輸入日期后一天的日期。例如，輸入為2013年9月9日，則函數的輸出為2013年9月10日。要求輸入變量month、day和year均為整數值，并且滿足下列條件：(1)1month12(2)1day31(3)1920year2050下面我們用邊界值分析法來設計測試用例。在NextDate函數中，規(guī)定了變量mouth和變量day的取值范圍為1mouth12和1day31，并設定變量year的取值范圍為1920year2050。這些就是邊界條件。根據這些邊界條件設計的測試用例如表3.4所示。表3.4 NextDate函數邊界值測試用例編號mouthdayyear預期輸出Test1Test2Test3Test4Test5Test6Test76666666151515151515151919192019211975204920502051year超出范圍1920.6.161921.6.161975.6.162049.6.162050.6.16year超出范圍Test8Test9Test10Test11Test12Test13666666-112303132200120012001200120012001day超出1312001.6.22001.6.32001.7.1輸入日期超界day超出131Test14Test15Test16Test17Test18Test19-112111213151515151515200120012001200120012001Mouth超出1122001.1.162001.2.162001.11.162001.12.16Mouth超出112因果圖法因果圖是一種利用圖解法分析輸入的各種組合情況,從而設計測試用例的方法,它適合于檢查程序輸入條件的各種組合情況。為什么要用因果圖我們前面介紹的等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關系。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。但是如果在測試時必須考慮輸入條件的各種組合，則可能的組合數目將是天文數字，因此必須考慮采用一種適合于描述多種條件的組合、相應產生多個動作的形式來進行測試用例的設計，這就需要利用因果圖。因果圖符號和概念(1) 以下4種符號分別表示了現實世界中的4種因果關系(圖3.1)。圖3.1因果關系(2)因果圖使用上圖的簡單符號表示因果關系，用圓圈表示節(jié)點，以直線連接左右節(jié)點。左邊節(jié)點點表示輸入狀態(tài)(原因)，右邊節(jié)點表示輸出狀態(tài)(結果)。(3)一般用Ci表示原因，ei表示結果，Ci和ei的取值都是0或者1，0表示某種狀態(tài)不出現，1表示某種狀態(tài)出現。因果圖概念(1)關系：原因和結果之間存在如下關系(圖3.1)。(a)表示恒等，若Ci=1，則ei=1，否則ei=0；(b)表示非，若Ci=1，則ei=0，否則ei=1；(c)表示或，若C1或C2或C3是1，則ei是1，否則ei是0，或可以有任意個輸入；(d)表示與，若C1且C2是1，則ei是1，否則ei是0，與可以有任意個輸入。(2)約束：輸入狀態(tài)(原因)之間或輸出狀態(tài)(結果)之間存在的某種依賴關系(圖3.2)。E約束(異)：原因a和b中最多有一個可能為1，即a和b不能同時為1。I約束(或)：原因a、b和c中至少有一個必須是1，即a、b和c不能同時為0。O約束(唯一)：原因a和b必須有一個，且僅有一個為1。R約束(要求)：原因a是1時，b必須是1，即不可能a是1時b是0。圖3.2約束關系實例分析假設有一個中國象棋的軟件程序，我們需要測試棋子【馬】的走法。下面我們采用因果圖來設計測試用例。(1)首先我們分析一下中國象棋中的走馬規(guī)則：a)如果落點在棋盤外，則不移動棋子；b)如果落點與起點不構成日字型，則不移動棋子；c)如果落點處有自己方棋子，則不移動棋子；d)如果在落點方向的鄰近交叉點有棋子（絆馬腿），則不移動棋子；e)如果不屬于a-d條，且落點處無棋子，則移動棋子；f)如果不屬于a-d條，且落點處為對方棋子(非老將)，則移動棋子并除去對方棋子；g)如果不屬于a-d條，且落點處為對方老將，則移動棋子，并提示戰(zhàn)勝對方，游戲結束。根據分析情況，我們得到以下原因和結果，如表3.5所示。表3.5中國象棋走馬程序分析編號原因編號結果C1落點在棋盤上e1不移動棋子C2落點與起點構成日字e2移動棋子C3落點方向的鄰近交叉點無棋子e3移動棋子，并除去對方棋子C4落點處為自己方棋子e4移動棋子，并提示戰(zhàn)勝對方，結束游戲C5落點處無棋子C6落點處為對方棋子（非老將）C7落點處為對方老將(2) 接下來我們畫出中國象棋走馬規(guī)則因果圖。圖3.3因果圖，其中10表示中間節(jié)點(3)然后根據因果圖得到判斷表(分成兩個表)表3.6決策表(1)序號12345678910111213141516原因C10101010101010101C20011001100110011C30000111100001111C40000000011111111結果100000000100000000e11111111011111111表3.7決策表(2)序號1234567890111213141516原因100101010101010101C50011001100110011C60000111100001111C70000000011111111結果e20010000e30000100e40000001注：1、第2表中部分列被合并表示不可能發(fā)生的現象；2、通過中間節(jié)點將用例的判定表簡化為兩個小表。減少工作量。(4)根據判定表寫測試用例表表3.8中國象棋走馬測試用例編號輸入條件操作步驟期望輸出Test1條件a-d不成立，移動馬，落點是對方老將1、點擊自方馬；2、點擊對方老將。移動棋子并提示戰(zhàn)勝對方。Test2條件a-d不成立，移動馬，落點是對方棋子（非老將）1、點擊自方馬；2、點擊對方棋子。移動棋子并除去對方棋子。Test3條件a-d不成立，移動馬，落點無棋子1、點擊自方馬；2、點擊無棋子的落點。移動棋子。Test4絆馬腿，落點為對方老將1、點擊自方馬；2、點擊對方老將。不移動棋子。Test5絆馬腿，落點為對方棋子（非老將）1、點擊自方馬；2、點擊對方棋子。不移動棋子。Test6絆馬腿，落點無棋子1、點擊自方馬；2、點擊無棋子落點。不移動棋子。Test7落點為自方棋子1、點擊自方馬；2、點擊自方棋子。不移動棋子。Test8不構成日字，落點為對方老將1、點擊自方馬；2、點擊對方老將。不移動棋子。Test9不構成日字，落點為對方棋子（非老將）1、點擊自方馬；2、點擊對方棋子。不移動棋子。Test10不構成日字，落點無棋子1、點擊自方馬；2、點擊無棋子落點。不移動棋子。Test11落點在棋盤外1、點擊自方馬；2、點擊棋盤外。不移動棋子。錯誤推測法錯誤推測法是指在測試程序時，人們可以根據經驗或直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例的方法。錯誤推測方法的基本思想：列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據他們選擇測試用例。例如，在單元測試時曾列出的許多在模塊中常見的錯誤。以前產品測試中曾經發(fā)現的錯誤等，這些就是經驗的總結。還有，輸入數據和輸出數據為0的情況。輸入表格為空格或輸入表格只有一行。這些都是容易發(fā)生錯誤的情況?？蛇x擇這些情況下的例子作為測試用例。不同測試方法選擇原則除了上述幾種常用的黑盒測試方法外，還有一些黑盒測試方法，如決策表法、正交試驗法、流程分析法和狀態(tài)遷移圖法等，這里就不一一介紹了。通常，在確定測試方法時，應遵循以下原則：1.根據程序的重要性和一旦發(fā)生故障將造成的損失來確定測試等級和測試重點。2.認真選擇測試策略，以便能盡可能少的使用測試用例，發(fā)現盡可能多的程序錯誤。因為一次完整的軟件測試過后，如果程序中遺留的錯誤過多并且嚴重，則表明該次測試是不足的，而測試不足則意味著讓用戶承擔隱藏錯誤帶來的危險，但測試過度又會帶來資源的浪費。因此測試需要找到一個平衡點。3.通常在確定測試策略時，有以下5條參考原則：(1)在任何情況下都必須采用邊界值分析法。這種方法設計出的測試用例發(fā)現程序錯誤的能力最強。(2)必要時采用等價類劃分法補充測試用例。(3)采用錯誤推斷法再追加測試用例。(4)對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準，則應當再補充更多的測試用例。(5)如果程序的功能說明中含有輸入條件的組合情況，則應一開始就選用因果圖法。項目說明測試用例設計項目主要教學生運用黑盒測試方法對待測試項目進行功能測試用例設計，編寫測試用例文檔，對測試用例進行評審，形成基線，納入軟件配置管理。整個項目分為四個模塊完成，模塊一為黑盒測試方法，模塊二為功能測試用例設計，模塊三為編寫測試用例文檔，模塊四為測試用例評審。學生要求完成以下工作任務：運用黑盒測試方法設計ATM模擬系統(tǒng)的功能測試用例，編寫測試用例文檔，為測試用例評審準備評審文檔，分角色參與測試用例評審工作，將評審后的文檔形成基線，納入配置庫管理。項目的工作場景一般是企業(yè)的各個項目組或者獨立的測試部門。該項目能為測試員、測試工程師、測試經理、SQA和SCM這些崗位的相關工作提供幫助。軟件測試與質量控制 教程5概述缺陷跟蹤管理是軟件測試工作的一個重要部分，軟件測試的目的是為了盡早發(fā)現軟件系統(tǒng)中的缺陷，因此，對缺陷進行跟蹤管理，確保每個被發(fā)現的缺陷都能夠及時得到處理是軟件測試工作的一項重要內容。缺陷分類軟件缺陷分類的原因在于給出Bug的嚴重級別，判定修復的優(yōu)先級?？梢园凑誃ug的嚴重級別分類。表4.1缺陷分類表級別說明1類Bug：致命錯誤(1)需求說明書中的功能未實現；(2)由于系統(tǒng)崩潰、死機、非法退出、死循環(huán)、數據庫異常、通訊異常、文件操作異常等原因造成功能不能實現，并且不能通過其他方法實現。2類Bug：嚴重錯誤(1)重要功能基本能實現，但系統(tǒng)不穩(wěn)定、會導致數據破壞丟失、run-time error錯誤等；(2)重要功能不能按正常操作實現，但通過其他方法可以實現。3類Bug：一般錯誤(1)次要功能不能正常實現；(2)操作界面錯誤(包括數據窗口內列名定義、含義不一致)；(3)打印內容、格式錯誤；(4)簡單的輸入限制未放在前臺進行控制；(5)刪除操作未給出提示；(6)數據庫表中有過多的空字段；(7)因錯誤操作迫使程序中斷；(8)系統(tǒng)找不到規(guī)律的時好時壞；(9)數據庫的表、業(yè)務規(guī)則、缺省值未加完整性等約束條件。4類Bug：細微錯誤最好能改進的：(1)界面不規(guī)范；(2)輔助說明描述不清楚；(3)輸入輸出不規(guī)范；(4)長操作未給用戶提示；(5)提示窗口文字未采用行業(yè)術語；(6)可輸入區(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志。5類Bug：改進建議(1)可以作為下一個版本的改進；(2)暫不作為修訂內容。缺陷描述對缺陷的描述應該包含以下的內容：表4.2缺陷描述內容說明內容描述項說明是否必填可追蹤信息缺陷ID唯一的缺陷ID，可以根據該ID追蹤缺陷，一般就是測試用例的編號是缺陷基本信息缺陷狀態(tài)缺陷的狀態(tài)，分為“待分配”、“待修正”、“待驗證”、“待評審”、“關閉”是缺陷標題描述缺陷的標題是缺陷嚴重程度描述缺陷的嚴重程度，一般分為“致命”、“嚴重”、“一般”、“建議”四種是缺陷緊急程度描述缺陷的緊急程度，從14，1是優(yōu)先級最高的等級，4是優(yōu)先級最低的等級是缺陷提交人缺陷提交人的名字(郵件地址)是缺陷提交時間缺陷提交的時間是缺陷所屬項目/模塊缺陷所屬的項目和模塊，最好能較精確的定位至模塊是缺陷指定解決人缺陷指定的解決人，在缺陷“提交”狀態(tài)為空，在缺陷“分發(fā)”狀態(tài)下由項目經理指定相關開發(fā)人員修改是缺陷指定解決時間項目經理指定的開發(fā)人員修改此缺陷的deadline是缺陷處理人最終處理缺陷的處理人是缺陷處理結果描述對處理結果的描述，如果對代碼進行了修改，要求在此處體現出修改是缺陷處理時間缺陷處理的時間是缺陷驗證人對被處理缺陷驗證的驗證人是缺陷驗證結果描述對驗證結果的描述（通過、不通過）是缺陷驗證時間對缺陷驗證的時間是缺陷詳細描述缺陷詳細描述對缺陷的詳細描述；之所以把這項單獨列出來，是因為對缺陷描述的詳細程度直接影響開發(fā)人員對缺陷的修改，描述應該盡可能詳細。是測試環(huán)境說明測試環(huán)境說明對測試環(huán)境的描述是必要的附件必要的附件對于某些文字很難表達清楚的缺陷，使用圖片等附件是必要的否缺陷處理流程缺陷處理流程中的角色分工如下：(1)測試人員：進行測試的人