Module 2 - Test Planning軟件測試計劃

1、Module Two-Software Test PlanningGeorge Cao Created on March 2, 2011 Last revised on Mar 3, 2014 Software Test Technology學習目標學習目標通過本章的學習，應該： 熟悉軟件測試計劃的要點； 需求階段的測試內(nèi)容及需求測試的方法； 熟悉測試的標準； 熟悉測試工具的選擇； 熟悉測試環(huán)境的搭建; 熟悉測試進度的建立；1.能夠閱讀測試計劃相關(guān)的技術(shù)文檔（SRS,測試計劃和測試進度計劃）。Study PurposeModule Two: Test Planning 2.1 Establis

2、h the Test Plan 2.2 Test the Software Requirement 2.3 Test Strategies 2.4 Test Environment 2.5 Test Management 2.6 Technical Document Reading 2.7 Test in Semester Project軟件測試階段組成軟件測試階段組成測試計劃制訂過程測試計劃制訂過程(活動活動)分析和測試軟件分析和測試軟件需求需求定義測試策略定義測試策略定義測試定義測試環(huán)境環(huán)境定義測試管理定義測試管理編寫和編寫和評審評審測試計劃測試計劃 測試活動進度綜述，可供項目經(jīng)理產(chǎn)生項目

3、進度時參考； 測試方法: 測試分類,如黑盒測試, 測試內(nèi)容,如安全測試； 測試工具，包括如何和何時獲取工具； 實施測試和報告結(jié)果的過程； 系統(tǒng)測試進入和結(jié)束準則； 設(shè)備資源: 設(shè)計、開發(fā)和執(zhí)行測試所需的人員和設(shè)備； 恰當?shù)臏y試覆蓋率目標； 測試所需的特殊軟件和硬件配置； 測試哪些特性，不測試哪些特性； 風險和意外情況計劃。 測試計劃測試計劃（Test Plan）要點）要點目前最常用的覆蓋評測是基于需求的測試覆蓋和基于代碼的測試覆蓋。 基于需求的 測試覆蓋測試用例表示的測試數(shù)（已計劃的、已實施的或成功的）/需要測試的需求總數(shù)。 1. 基于代碼的測試覆蓋 2. 基于代碼的測試覆蓋，評測測試過程中已

4、經(jīng)執(zhí)行的代碼的多少，一般通過工具度量得到： 找出程序經(jīng)過一系列測試而沒有執(zhí)行的部分代碼 創(chuàng)建一個附加的測試用例來增加覆蓋率 決定代碼覆蓋的定量度量。測試覆蓋率測試覆蓋率實驗指導實驗指導1解讀解讀2014-3-3軟件121 測試計劃是描述軟件測試努力的目標、范圍、方法和焦點的文檔。 由于測試的種類多、內(nèi)容廣并且時間分散，并且不同的測試工作由不同的人員來執(zhí)行，因此一般把(單元測試、集成測試、系統(tǒng)測試)、(驗收測試)各階段的測試計劃分開寫。 Sample實驗報告實驗報告1文檔解讀的問題文檔解讀的問題 1項目的背景是什么？ 2. 測試的方法內(nèi)容是什么？ 3. 所需的測試工具是什么？ 4. 測試通過/失

5、敗的準則是什么？ 5測試任務有哪些？ 6測試環(huán)境需求是什么？ 7功能測試的方案是什么？ 8測試計劃識別出哪些風險與應急措施？ 9. 測試的進入和拒絕準則是什么？ 填寫其他的文檔理解問題-進度計劃進度計劃 2014-3-4126班班 test schedule (sample).mppModule Two: Test Planning 2.1 Establish the Test Plan 2.2 Test the Software Requirement 2.3 Test Strategies 2.4 Test Environment 2.5 Test Management 2.6 Techn

6、ical Document Reading 2.7 Test in Semester Project 軟件需求文檔軟件需求文檔 需求文檔是進行設(shè)計、編碼、測試的基礎(chǔ)文件，軟件需求文檔中，需要描述下列內(nèi)容： 說明 一般描述 各種限制條件、假定和以來 功能需求 非功能需求 參考2.2 2.2 測試軟件需求測試軟件需求 需求測試的方法需求測試的方法評審評審(Review) ： 走查 (Walkthrough) 復查一般是讓工作中合作者檢查產(chǎn)品并提出意見。同級互查可以面對面進行，也可以通過E-Mail實現(xiàn)，并沒有統(tǒng)一標準。發(fā)現(xiàn)文檔缺陷同級互查的能力是三種方法中最弱的。 相比較審查走查較為寬松，其事先需

7、要收集數(shù)據(jù)，也沒有輸出報告的要求。 審查 (Inspection) 審查是為發(fā)現(xiàn)缺陷而進行的。關(guān)鍵組件的審查通過會議進行，會前每個與會者需要進行準備，會議必須按規(guī)定的程序進行，缺陷被記錄并形成會議報告。審查被證明是非常有效的發(fā)現(xiàn)缺陷的方法。 Requirement Review Process需求評審是技術(shù)評審的一種，后者通常指對需求、設(shè)計、代碼和測試的評審，四者的評審過程和方法都是相同，所以系統(tǒng)設(shè)計、代碼和測試的評審過程全部都可以參考此處的內(nèi)容。技術(shù)評審的目的是在軟件開發(fā)階段對有關(guān)技術(shù)性文檔進行正確性的檢查，側(cè)重于在缺陷導入階段就盡早盡可能地發(fā)現(xiàn)他們以防止他們進入下一個階段（To focus

8、 on discovering defects at the defect import phase as early as possible and prevent them from entering the next phase），從而節(jié)約成本，使后續(xù)過程的變更減少，減少重復工作的工作量（to reduce rework effort），降低風險。技術(shù)評審嘗試發(fā)現(xiàn)更多的缺陷而不能發(fā)現(xiàn)所有的缺陷。角色與職責角色與職責角色角色主要職責主要職責項目經(jīng)理規(guī)劃技術(shù)評審，確保所有的交付物都準備好了評審組長Review Leader評審前介紹評審檢查單組織(Organize)評審的成員審計評審檢查單的

9、覆蓋情況提供評審分析報告評審組員評審交付物并發(fā)現(xiàn)缺陷作者Author 把交付物分發(fā)(Distribute)給評審組員介紹交付物修正缺陷并修改交付物記錄員Recorder在評審記錄單上記錄缺陷本角色由評審組長指派技術(shù)評審程序技術(shù)評審程序1）組織評審組一般地，由PM擔任管理評審的組長，由DM 擔任SDS/SRS評審的組長，由技術(shù)組長擔任代碼評審的組長，由測試經(jīng)理擔任測試評審的組長。 評審小組由評審組長組織，作者不能作為評審組長。2）在進度計劃上列出正式評審（Formal Review）活動PM 及 DM必須識別并在項目進度計劃中作為重要的里程碑列出所有正式的技術(shù)評審任務 。3）發(fā)送評審檢查單及交付

10、物評審組長和作者分別把評審檢查單及交付物發(fā)送給評審組員。技術(shù)評審程序技術(shù)評審程序4）執(zhí)行評審會議如果必要，評審組長應該在會議開始前向所有的評審組員介紹評審檢查單的內(nèi)容；作者概要地介紹交付物的內(nèi)容 ；評審組員及作者在會上討論發(fā)現(xiàn)的缺陷；需要修正的缺陷被記錄到評審記錄單上；會議結(jié)束前，評審組長應該用評審檢查單來監(jiān)督是否所有的簡檢查單項都被覆蓋了。5）交付物的修改及追蹤會后，記錄員把評審記錄單發(fā)布到配置管理工具上，作者根據(jù)發(fā)現(xiàn)的缺陷修改交付物。當作者把所有的缺陷都修改完成后,他應該通知（inform）所有的評審組員 。 6）關(guān)閉（Close）此次評審評審組長負責對發(fā)現(xiàn)缺陷的追蹤直至問題關(guān)閉，并發(fā)布（

11、submit）評審分析報告給項目有關(guān)干系人。需求評審檢查單需求評審檢查單(Requirement Review Checklist)從以下幾個方面來評價需求文檔：從以下幾個方面來評價需求文檔：需求文檔是否符合公司的格式要求？需求是否正確？這是“真正的”需求嗎？描述的產(chǎn)品是否就是要開發(fā)的產(chǎn)品？需求是否完備？需求是否可實現(xiàn)？是否考慮過將來可能會提出的軟件需求；有沒有遺漏、重復或不一致(矛盾)的地方；與所有其他系統(tǒng)成份的重要接口是否都已經(jīng)描述；所有圖表是否清楚，在不補充說明時能否理解；是否確定了需求的優(yōu)先級；理解需求理解需求理解什么？理解什么？理解系統(tǒng)的目標理解系統(tǒng)的業(yè)務（業(yè)務流程、方法等）理解需求

12、的范圍和需求（功能）清單參與需求評審提出Q&A問題清單，與系統(tǒng)分析師SA及客戶溝通原則：不限于自己負責的模塊，整個系統(tǒng)都要熟悉分小組解讀SRS的部分章節(jié)內(nèi)容（2.2小節(jié)前的內(nèi)容為公共部分必看，后面每個小組讀一個用例），并對照需求評審檢查單和需求理解內(nèi)容（見前2頁），提出至少兩個需求理解方面的問題。隨機分配其他小組來解答另外一個小組的問題。老師點評并總體回答問題。項目小組按照需求評審記錄單的格式，填寫問題 到實驗報告里。SRSUSE CASE for Stock Maintenance實驗指導實驗指導1需求評審實訓（填寫實驗報告）需求評審實訓（填寫實驗報告）review定義測試范圍需要考

13、慮哪些一些因素？定義測試范圍需要考慮哪些一些因素？確立測試標準常用的規(guī)則有哪些？確立測試標準常用的規(guī)則有哪些？影響測試環(huán)境有哪些因素？影響測試環(huán)境有哪些因素？Module Two: Test Planning 2.1 Establish the Test Plan 2.2 Test the Software Requirement 2.3 Test Strategies 2.4 Test Environment 2.5 Test Management 2.6 Technical Document Reading 2.7 Test in Semester Project2.3 測試策略測試策略

14、測試策略考慮的問題：測試策略考慮的問題： 測試范圍 測試方法 測試標準 測試工具2.3.1 確定測試范圍確定測試范圍 測試過度，則在測試覆蓋中存在大量冗余；測試范圍過小，則存在遺漏錯誤的風險。 定義測試范圍是一個在測試時間、費用和質(zhì)量風險之間尋找平衡的過程。 通過分析產(chǎn)品的需求文檔識別哪些需要被測試。 測試范圍不能僅僅由測試人員來確定。 定義測試范圍需要考慮下列一些因素：定義測試范圍需要考慮下列一些因素： 首先測試最高優(yōu)先級的需求。 測試新的功能和代碼 或者改進的舊功能。 使用等價類劃分來減小測試范圍（冗余） 重點測試經(jīng)常出問題的地方 確定測試范圍方法確定測試范圍方法 可采用提問單的方式來確定

15、測試范圍 哪些功能是軟件的特色？ 哪些功能是用戶最常用的？ 如果系統(tǒng)可以分塊賣的話，哪些功能塊在銷售時最昂貴？ 哪些功能出錯將導致用戶不滿或索賠？ 哪些程序是最復雜、最容易出錯的？ 哪些程序是相對獨立，應當提前測試的？ 哪些程序最容易擴散錯誤？ 哪些程序是全系統(tǒng)的性能瓶頸所在？ 哪些程序是開發(fā)者最沒有信心的？ 2.3.2 選擇測試方法選擇測試方法 在不同的開發(fā)階段，需要選擇不同的測試方法。 在瀑布生命期模型中不同的階段可以選擇的不同的測試方法： 需求分析階段：靜態(tài)測試 概要設(shè)計與詳細設(shè)計階段：靜態(tài)測試 編碼和單元測試階段：靜態(tài)測試和動態(tài)測試、白盒測試 集成測試階段：動態(tài)測試、白盒測試、黑盒測試

16、 系統(tǒng)測試階段：動態(tài)測試、黑盒測試 驗收測試階段：動態(tài)測試、黑盒測試2.3.3 定義測試標準定義測試標準 定義測試標準的目的是設(shè)置測試中遵循的規(guī)則。 需要制訂以下幾種標準： 測試開始標準test entry criteria 測試退出標準test exit criteria比如發(fā)布給客戶前的系統(tǒng)測試結(jié)束標準是什么？ 測試暫停與繼續(xù)標準test rejection/continual criteria制訂測試標準常用規(guī)則制訂測試標準常用規(guī)則 基于測試用例的規(guī)則基于測試用例的規(guī)則 當測試用例的不通過率達到某一百分比時，則拒絕繼續(xù)測試。 優(yōu)點是適用于所有的測試階段 缺點是太依賴于測試用例。 基于基于

17、“測試期缺陷密度測試期缺陷密度”的規(guī)則的規(guī)則 “測試期缺陷密度”：測試一個CPU小時發(fā)現(xiàn)的缺陷數(shù)。 如果在相鄰n個CPU小時內(nèi)“測試期缺陷密度”全部低于某個值m時，則允許正常結(jié)束測試。 2.3.4 選擇自動化測試工具選擇自動化測試工具 使用測試工具可以帶來下面一些主要的好處： 能夠很好地進行性能測試和壓力測試 能夠縮短測試周期 能夠提高測試工作的可重復性 選擇自動化測試工具需要注意以下幾方面：選擇自動化測試工具需要注意以下幾方面： 并不是所有的測試工作都可以由測試工具來完成 并不是一個自動化工具就可以完成所有的測試 使用自動化工具本身也是需要時間的，這個時間有可能超過手工測試的時間 如果測試人

18、員不熟悉測試工具的使用，有可能不能更多發(fā)現(xiàn)軟件錯誤，從而影響測試工作質(zhì)量 自動化測試工具并不能對一個軟件進行完全的測試 購買自動化測試工具，有可能使本項目的測試費用超出預算Module Two: Test Planning 2.1 Establish the Test Plan 2.2 Test the Software Requirement 2.3 Test Strategies 2.4 Test Environment 2.5 Test Management 2.6 Technical Document Reading 2.7 Test in Semester Project2.4 測試

19、環(huán)境測試環(huán)境 從軟件的編碼、測試到用戶實際使用，存在著：開發(fā)環(huán)境、測試環(huán)境和用戶環(huán)境。 “環(huán)境”，指的是被測試軟件所運行的軟件環(huán)境和硬件環(huán)境。 測試環(huán)境是測試人員為進行軟件測試而搭建的環(huán)境，一般情況下，將包括多種典型的用戶環(huán)境。 測試環(huán)境的環(huán)境項測試環(huán)境的環(huán)境項 計算機平臺 操作系統(tǒng) 瀏覽器 軟件支持平臺 外部設(shè)備 網(wǎng)絡環(huán)境 其它專用設(shè)備如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境Cohabit kuhbit 同居同居如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)

20、境Cohabit kuhbit 同居同居如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境20110315S1如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境。（同傳）（同傳）如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境如何配置測試環(huán)境20110322S1mediocre,mi:diuk, mi:diuk中等

21、的、平凡的中等的、平凡的 Module Two: Test Planning 2.1 Establish the Test Plan 2.2 Test the Software Requirement 2.3 Test Strategies 2.4 Test Environment 2.5 Test Management 2.6 Technical Document Reading 2.7 Test in Semester Project2.5 測試管理測試管理 在測試管理方面，需要考慮的主要問題包括： 選擇缺陷管理工具和測試管理工具 定義工作進度 建立風險管理計劃（一般在整個項目RSKM中統(tǒng)

22、一管理） 在測試計劃階段，需要確定用什么工具進行測試管理和缺陷管理。如JIRA, QC(Quality Control), TD(TestDirector)或 Bugzilla等。 在執(zhí)行測試的過程中，缺陷管理工具和測試管理工具并不是必須的。但多數(shù)公司都會使用缺陷管理工具。2.5.1缺陷工具和管理工具的選擇缺陷工具和管理工具的選擇 定義工作進度的過程定義工作進度的過程同項目進度計劃的制定過程同項目進度計劃的制定過程確認工作任務估算工作量編寫進度計劃2.5.2定義工作進度定義工作進度確認測試工作任務確認測試工作任務 測試人員的測試工作任務可以分為兩類，一類是可以直接和需求文檔對應起來的，另外一類和需求文檔沒有直接的關(guān)聯(lián)（純測試工作）。 在需求文檔中，描述了軟件的功能性需求和非功能性需求，對需求中的每一個條目，都應該有相應的測試工作與之對應起來。 確認好測試任務后，還應該排列這些任務的優(yōu)先級。 與需求文檔沒有直接關(guān)聯(lián)的測試任務：與需求文檔沒有直接關(guān)聯(lián)的測