軟件測試與質(zhì)量控制 教程1-8_第1頁
軟件測試與質(zhì)量控制 教程1-8_第2頁
軟件測試與質(zhì)量控制 教程1-8_第3頁
軟件測試與質(zhì)量控制 教程1-8_第4頁
軟件測試與質(zhì)量控制 教程1-8_第5頁
已閱讀5頁,還剩36頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

軟件測試與質(zhì)量控制教程1-8軟件測試與質(zhì)量控制教程1-8軟件測試與質(zhì)量控制教程1-8軟件測試與質(zhì)量控制教程1-8編制僅供參考審核批準生效日期地址:電話:傳真:郵編:11月標準化修正軟件測試與質(zhì)量控制教程1-8全集[鍵入作者姓名][選取日期][在此處鍵入文檔摘要。摘要通常為文檔內(nèi)容的簡短概括。在此處鍵入文檔摘要。摘要通常為文檔內(nèi)容的簡短概括。]

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論