火龍果軟件軟件測試課件(徐芳高職高專)

1軟件測試技術(shù)2第二章測試計劃2.1測試計劃要點和制訂過程2.2測試軟件需求2.3測試策略2.4測試環(huán)境2.5測試管理2.6測試計劃編寫3開發(fā)生命周期需求分析設(shè)計定義程序編制維護(hù)建立建立建立修改測試生命周期測試計劃測試設(shè)計定制個案測試執(zhí)行評估缺陷跟蹤越早測試越好2.1測試計劃要點和制訂過程軟件測試生命周期4軟件測試階段組成測試計劃測試設(shè)計測試開發(fā)測試執(zhí)行測試評估5測試計劃的目標(biāo)

收集并組織測試計劃信息將軟件細(xì)化為可檢驗的測試需求建立測試計劃6測試計劃制訂過程分析和測試軟件需求定義測試策略定義測試環(huán)境定義測試管理編寫和審核測試計劃7

測試活動進(jìn)度綜述，可供項目經(jīng)理產(chǎn)生項目進(jìn)度時參考；測試方法，包括測試工具的使用；測試工具，包括如何和何時獲取工具；實施測試和報告結(jié)果的過程；系統(tǒng)測試進(jìn)入和結(jié)束準(zhǔn)則；設(shè)計、開發(fā)和執(zhí)行測試所需的人員；設(shè)備資源：需要什么樣的機(jī)器和測試基準(zhǔn)；恰當(dāng)?shù)臏y試覆蓋率目標(biāo)；測試所需的特殊軟件和硬件配置；測試應(yīng)用程序策略；測試哪些特性，不測試哪些特性；風(fēng)險和意外情況計劃。測試計劃要點8測試計劃：考慮測試內(nèi)容系統(tǒng)功能用戶界面系統(tǒng)性能負(fù)載測試強(qiáng)化測試容量測試配置測試安裝測試92.2測試軟件需求需求分析過程收集用戶需求編寫需求定義文檔編寫軟件功能說明編寫軟件需求跟蹤矩陣審核軟件需求文檔10需求分析中測試人員工作理解需求，參與審核需求文檔理解項目的目標(biāo)、限制，了解用戶應(yīng)用背景編寫測試計劃準(zhǔn)備資源11軟件需求文檔

需求文檔是進(jìn)行設(shè)計、編碼、測試的基礎(chǔ)文件，軟件需求文檔中，需要描述下列內(nèi)容：說明一般描述各種限制條件、假定和以來功能需求非功能需求參考12需求跟蹤矩陣對于需求文檔中的每項需求，要確保以下問題：是否完成了相應(yīng)的設(shè)計？是否編寫完成了相應(yīng)的代碼？在哪里可以找到這些代碼？是否編寫完成了相應(yīng)的單元測試用例？是否進(jìn)行了單元測試？是否完成了相應(yīng)的集成測試用例？是否進(jìn)行了集成測試？需求跟蹤矩陣即描述上述問題。13什么是好的需求文檔？具有清晰的格式和文檔結(jié)構(gòu)需求的內(nèi)容正確需求的內(nèi)容完整需求具有可行性必要性對不同的需求的優(yōu)先等級進(jìn)行定義描述明確，無歧義、二義，上下文一致可證實和可測試性可修改性可追蹤需求文檔被及時更新14從以下幾個方面來評價需求文檔：需求文檔是否符合公司的格式要求？需求是否正確？要保證需求文檔中所描述的內(nèi)容是真實可靠的這是“真正的”需求嗎？描述的產(chǎn)品是否就是要開發(fā)的產(chǎn)品？需求是否完備？列出的需求是否能減去一部分？需求是否兼容？需求有可能是矛盾的。需求是否可實現(xiàn)？需求是否合理？需求是否可測？如何進(jìn)行需求測試？15需求測試的方法：復(fù)查(Review)復(fù)查一般是讓工作中合作者檢查產(chǎn)品并提出意見。同級互查可以面對面進(jìn)行，也可以通過E-Mail實現(xiàn)，并沒有統(tǒng)一標(biāo)準(zhǔn)。發(fā)現(xiàn)文檔缺陷同級互查的能力是三種方法中最弱的。走查(Walkthrough)相比較審查走查較為寬松，其事先需要收集數(shù)據(jù)，也沒有輸出報告的要求。審查(Inspection)審查是為發(fā)現(xiàn)缺陷而進(jìn)行的。關(guān)鍵組件的審查通過會議進(jìn)行，會前每個與會者需要進(jìn)行準(zhǔn)備，會議必須按規(guī)定的程序進(jìn)行，缺陷被記錄并形成會議報告。審查被證明是非常有效的發(fā)現(xiàn)缺陷的方法。16定義測試需求

用戶需求定義測試需求根據(jù)用戶需求定義并完善測試需求，以作為整個測試的標(biāo)準(zhǔn)172.3測試策略測試策略考慮的問題：測試范圍測試方法測試標(biāo)準(zhǔn)測試工具182.3.1確定測試范圍測試過度，則在測試覆蓋中存在大量冗余；測試范圍過小，則存在遺漏錯誤的風(fēng)險。定義測試范圍是一個在測試時間、費用和質(zhì)量風(fēng)險之間尋找平衡的過程。通過分析產(chǎn)品的需求文檔識別哪些需要被測試。測試范圍不能僅僅由測試人員來確定。19定義測試范圍需要考慮下列一些因素：首先測試最高優(yōu)先級的需求。測試新的功能和代碼或者改進(jìn)的舊功能。使用等價類劃分來減小測試范圍重點測試經(jīng)常出問題的地方20確定測試范圍方法可采用提問單的方式來確定測試范圍哪些功能是軟件的特色？哪些功能是用戶最常用的？如果系統(tǒng)可以分塊賣的話，哪些功能塊在銷售時最昂貴？哪些功能出錯將導(dǎo)致用戶不滿或索賠？哪些程序是最復(fù)雜、最容易出錯的？哪些程序是相對獨立，應(yīng)當(dāng)提前測試的？哪些程序最容易擴(kuò)散錯誤？哪些程序是全系統(tǒng)的性能瓶頸所在？哪些程序是開發(fā)者最沒有信心的？212.3.2選擇測試方法在不同的開發(fā)階段，需要選擇不同的測試方法。在瀑布生命期模型中不同的階段可以選擇的不同的測試方法：需求分析階段：靜態(tài)測試概要設(shè)計與詳細(xì)設(shè)計階段：靜態(tài)測試

編碼和單元測試階段：靜態(tài)測試和動態(tài)測試、白盒測試集成測試階段：動態(tài)測試、白盒測試、黑盒測試

系統(tǒng)測試階段：動態(tài)測試、黑盒測試驗收測試階段：動態(tài)測試、黑盒測試222.3.3定義測試標(biāo)準(zhǔn)定義測試標(biāo)準(zhǔn)的目的是設(shè)置測試中遵循的規(guī)則。需要制訂以下幾種標(biāo)準(zhǔn)：測試入口標(biāo)準(zhǔn)測試出口標(biāo)準(zhǔn)測試暫停與繼續(xù)標(biāo)準(zhǔn)23制訂測試標(biāo)準(zhǔn)常用規(guī)則（一）基于測試用例的規(guī)則當(dāng)測試用例的不通過率達(dá)到某一百分比時，則拒絕繼續(xù)測試。優(yōu)點是適用于所有的測試階段缺點是太依賴于測試用例。

基于“測試期缺陷密度”的規(guī)則“測試期缺陷密度”：測試一個CPU小時發(fā)現(xiàn)的缺陷數(shù)。如果在相鄰n個CPU小時內(nèi)“測試期缺陷密度”全部低于某個值m時，則允許正常結(jié)束測試。

24制訂測試標(biāo)準(zhǔn)常用規(guī)則（二）基于“運行期缺陷密度”的規(guī)則“運行期缺陷密度”：軟件運行一個CPU小時發(fā)現(xiàn)的缺陷數(shù)如果在相鄰n個CPU小時內(nèi)“運行期缺陷密度”全部低于某個值m時，則允許正常結(jié)束測試。252.3.4選擇自動化測試工具使用測試工具可以帶來下面一些主要的好處：能夠很好地進(jìn)行性能測試和壓力測試能夠縮短測試周期能夠提高測試工作的可重復(fù)性26選擇自動化測試工具需要注意以下幾方面：并不是所有的測試工作都可以由測試工具來完成并不是一個自動化工具就可以完成所有的測試使用自動化工具本身也是需要時間的，這個時間有可能超過手工測試的時間如果測試人員不熟悉測試工具的使用，有可能不能更多發(fā)現(xiàn)軟件錯誤，從而影響測試工作質(zhì)量自動化測試工具并不能對一個軟件進(jìn)行完全的測試購買自動化測試工具，有可能使本項目的測試費用超出預(yù)算272.4測試環(huán)境從軟件的編碼、測試到用戶實際使用，存在著：開發(fā)環(huán)境、測試環(huán)境和用戶環(huán)境?！碍h(huán)境”，指的是被測試軟件所運行的軟件環(huán)境和硬件環(huán)境。測試環(huán)境是測試人員為進(jìn)行軟件測試而搭建的環(huán)境，一般情況下，將包括多種典型的用戶環(huán)境。28測試環(huán)境的環(huán)境項

計算機(jī)平臺操作系統(tǒng)瀏覽器軟件支持平臺外部設(shè)備網(wǎng)絡(luò)環(huán)境其它專用設(shè)備29在配置測試環(huán)境方面，同樣面臨著在測試范圍中的平衡問題。在搭建測試環(huán)境的時候，要排列配置的優(yōu)先級，主要考慮：使用的頻度或者范圍失效的可能性能最大限度模擬真實環(huán)境如何配置測試環(huán)境302.5測試管理在測試管理方面，需要考慮的主要問題包括：選擇缺陷管理工具和測試管理工具定義工作進(jìn)度建立風(fēng)險管理計劃31在測試計劃階段，需要確定用什么工具進(jìn)行測試管理和缺陷管理。如TestDirector或Bugzilla等。在執(zhí)行測試的過程中，缺陷管理工具和測試管理工具并不是必須的。但多數(shù)公司都會使用缺陷管理工具。2.5.1缺陷工具和管理工具的選擇

32定義工作進(jìn)度的過程確認(rèn)工作任務(wù)估算工作量編寫進(jìn)度計劃2.5.2定義工作進(jìn)度33確認(rèn)工作任務(wù)

工作任務(wù)可以分為兩類，一類是可以直接和需求文檔對應(yīng)起來的，另外一類和需求文檔沒有直接的關(guān)聯(lián)。在需求文檔中，描述了軟件的功能性需求和非功能性需求，對需求中的每一個條目，都應(yīng)該有相應(yīng)的測試工作與之對應(yīng)起來。確認(rèn)好測試任務(wù)后，還應(yīng)該排列這些任務(wù)的優(yōu)先級。34與需求文檔沒有直接關(guān)聯(lián)的任務(wù)：

執(zhí)行測試時設(shè)置和配置系統(tǒng)開發(fā)和安裝專用測試工具學(xué)習(xí)使用測試工具定制測試工具將測試用例編寫為腳本或數(shù)據(jù)文件重新運行以前沒通過的測試用例產(chǎn)生測試報告和測試總結(jié)文檔編寫測試計劃編寫質(zhì)量報告、缺陷報告人員培訓(xùn)與程序員之間的交流與客戶之間的交流35估算工作量工作量可以使用“人*日”、“人*月”、“人*年”這樣的單位。測試工作量的估算可以采用以下方法：建立詳細(xì)的工作分解結(jié)構(gòu)分析以往項目，尋找歷史數(shù)據(jù)使用評估模型在估算工作量時，還要注意一些“返工”的問題。36編寫進(jìn)度計劃進(jìn)度計劃可以用甘特圖的形式來表示。

37在進(jìn)度計劃中，要確保：所有任務(wù)都已經(jīng)被列出計劃中包含了任務(wù)編號、任務(wù)名稱、開始時間、完成時間、持續(xù)時間等信息計劃是可行的，資源要求能夠被滿足按照此計劃開展實際工作如果有變化，該計劃將被及時更新382.5.3建立風(fēng)險管理計劃

在測試中面臨的問題：由于設(shè)計、編碼出現(xiàn)了大的質(zhì)量問題，導(dǎo)致測試工作量、測試時間增加；在開始測試時，所需要的硬件、軟件沒有準(zhǔn)備好未能完成對測試人員的技術(shù)培訓(xùn)測試時的人力資源安排不足在測試過程中，發(fā)生了大量的需求變更在測試過程中，項目的開發(fā)計劃被進(jìn)行大幅度調(diào)整不能及時準(zhǔn)備好所需要的測試環(huán)境不能及時準(zhǔn)備好測試數(shù)據(jù)39風(fēng)險管理的過程：識別風(fēng)險評估風(fēng)險制訂對策跟蹤風(fēng)險402.6測試計劃編寫測試計劃是描述軟件測試努力的目標(biāo)、范圍、方法和焦點的文檔。由于測試的種類多、內(nèi)容廣并且時間分散，并且不同的測試工作由不同的人員來執(zhí)行，因此一般把單元測試、集成測試、系統(tǒng)測試、驗收測試各階段