1、網上訂票系統測試計劃表1-5測試計劃說明表總頁數正文附錄生效日期：2015 年1月14日編制：審核：批準：表1-6修訂歷史記錄日期版本說明作者2015/1/14<>詳細信息姓名目錄1 .簡介 錯誤!未定義書簽目的 錯誤!未定義書簽背景 錯誤!未定義書簽范圍 錯誤!未定義書簽使用文檔 錯誤!未定義書簽2 .測試需求 錯誤!未定義書簽3 .測試風險錯誤!未定義書簽4 .測試策略錯誤!未定義書簽測試類型錯誤!未定義書簽數據和數據庫完整性測試錯誤!未定義書簽功能測試錯誤!未定義書簽業務周期測試錯誤!用戶界面測試錯誤!性能評價錯誤!負載測試錯誤!強度測試錯誤!容量測試錯誤!安全性和訪問控制測

2、試錯誤!故障轉移和恢復測試 錯誤!未定義書簽。配置測試 錯誤!未定義書簽。安裝測試 錯誤!未定義書簽。5 .工具- 296資源 錯誤! 未定義書簽。人力資源錯誤!系統資源錯誤!7 .測試進度和里程碑 錯誤!項目測試進度錯誤!測試里程碑錯誤!8 .可交付工件錯誤!1.簡介目的網上訂票系統的這一 “測試計劃”文檔的目的是:(1)提供一個對項目軟件進行測試的總體安排和進度計劃，確定現有項目的信息和應測試軟件構件。(2)標明推薦的測試需求(高層次)。(3)推薦可采用的測試策略，并對這些策略加以說明。(4)確定所需的資源，并對測試的工作量進行估計。(5)列出測試項目的可交付元素1. 2背景本項目測試的對

3、象是HP LoadRunner軟件自帶的 Web Tours網上訂票系統， 這是一款基于平臺的網站。基于先進的 .NET Framework,默認支持 SOL Server 數據庫，可擴展支持ACCES皿ySql等多種數據庫。支持基于IE > Chrome Firefox、 Opera等瀏覽器。WebTours網站主要是提供方全世界用戶進行網上訂票、查看訂票信息、預 訂機票、修改預訂機票的功能支持。1. 3范圍對Web Tours網站的注冊、登陸、訂票、查詢以及退票功能進行功能測試、 性能測試和界面測試1. 4使用文檔下表列出了制定測試計劃所用的文檔，并標明了文檔的可用性：表1-7測試計

4、劃使用文檔列表文檔(版本/日期)已創建或可用已被接受或已 經過復審作者或 來源備注測試計劃模版是是老師2.測試需求下面列出了那些已被確定為測試對象的項目(用例、功能性需求和非功能性需求)。此列表說明了測試的對象。在此處輸入一個主要測試需求的高層次列表。例如：.功能測試注冊、登陸、訂票、查詢以及退票功能用戶界面測試注冊、登陸、訂票、查詢以及退票功能性能測試注冊、登陸、訂票、查詢以及退票功能3 .測試風險軟件測試風險是不可避免的、 總是存在的，所以對測試風險的管理非常重要， 必須盡力 降低測試中所存在的風險， 最大程度地保證質量和滿足客戶的需求。 在測試工作中，主要的 風險有：1 .質量需求或產品

5、的特性理解不準確，造成測試范圍分析的誤差，結果某些地方始終 測試不到或驗證的標準不對；2 .測試用例沒有得到百分之百的執行，如有些測試用例被有意或無意的遺漏；3 .需求的臨時/突然變化，導致設計的修改和代碼的重寫，測試時間不夠；4 .質量標準不都是很清晰的，如適用性的測試，仁者見仁、智者見智；5 .測試用例設計不到位，忽視了一些邊界條件、深層次的邏輯、用戶場景等；6 .測試環境，一般不可能和實際運行環境完全一致，造成測試結果的誤差；7 .有些缺陷出現頻率不是百分之百，不容易被發現；如果代碼質量差，軟件缺陷很多，被漏檢的缺陷可能性就大；8 .回歸測試一般不運行全部測試用例，是有選擇性的執行，必然

6、帶來風險。前面三種風險是可以避免的，而四至七的四種風險是不能避免的，可以降到最低。最后一種回歸測試風險是可以避免，但出于時間或成本的考慮，一般也是存在的。針對上述軟件測試的風險，有一些有效的測試風險控制方法，如：測試環境不對可以通過事先列出要檢查的所有條目，在測試環境設置好后， 由其他人員按已列出條目逐條檢查；？有些測試風險可能帶來的后果非常嚴重，能否將它轉化為其他一些不會引起嚴重后果的低風險。如產品發布前夕，在某個不是很重要的新功能上發現一個嚴重的缺陷，如果修正這個缺陷，很有可能引起某個原有功能上的缺陷。 這時處理這個缺陷所帶來的風險就很大， 對 策是去掉（Diasble）那個新功能，轉移這

7、種風險；有些風險不可避免，就設法降低風險，如“程序中未發現的缺陷”這種風險總是存在，我們就要通過提高測試用例的覆蓋率（如達到%來降低這種風險；？為了避免、轉移或降低風險，事先要做好風險管理計劃和控制風險的策略，并對風 險的處理還要制定一些應急的、有效的處理方案。4 .測試策略功能測試測試對象的功能測試應該側重于可以被直接追蹤到用例或業務功能和業務 規則的所有測試需求。這些測試的目標在于核實能否正確地接受、處理和檢索數 據以及業務規則是否正確實施。這種類型的測試基于黑盒方法，即通過圖形用戶 界面（GUI）與應用程序交互并分析輸出結果來驗證應用 程序及其內部進程。以下列出的是每個應用程序推薦的測試

8、方法概要： 表1-9功能測試說明表測試目標：確保測試對象的功能正常，其中包括導航、數據輸入、處理和檢 索等。方法：利用有效的和無效的數據來執行各個用例、 用例流或功能，以核 實以下內容：在使用肩效數據時得到預期的結果。在使用無效數據時顯示相應的錯誤消息或警告消息。各業務規則都得到了止確的應用。完成標準：所計劃的測試已全部執行。 所發現的缺陷已全部解決。需考慮的特 殊事項：確定或說明那些將對功能測試的實施和執行造成影響的事項或 因素（內部的或外部的）用戶界面測試通過用戶界面（UI）測試來核實用戶與軟件的交互。UI測試的目標在于確 保用戶界面向用戶提供了適當的訪問和瀏覽測試對象功能的操作。除此之外

9、，UI測試還要確保UI功能內部的對象符合 預期要求，并遵循公司或行業的標準。表1-11用戶界面測試說明表測試目標：核實以下內容：通過瀏覽測試對象可正確反映業務的功能和需求， 這種瀏覽包括 窗口與窗口之間、字段與字段之間的瀏覽，以及各種訪問方法 （Tab健、鼠標移動和快捷鍵）的使用窗口的對象和特征（例如：菜單、大小、位置、狀態和中心）者B 符合標準。方法：為每個窗口創建或修改測試，以核實各個應用程序窗口和對象都 可止確地進行瀏覽，并處于正常的對象狀態。完成標準：證實各個窗口都與基準版本保持一致，或符合可接受標準1需考慮的特 殊事項：并不是所有定制或第三方對象的特征都可訪問。性能評價性能評價是一種

10、性能測試，它對響應時間、事務處理速率和其他與時間相關 的需求進行評測和評估。性能評價的目標是核實性能需求是否都已滿足。實施和 執行性能評價的目的是將測試對象的性能為當作條件（例如工作量或硬件配置）的一種函數來進行評價和微調。注：以下事務均指“邏輯業務事務”。這種事務被定義為將由系統的某個主角通過使用測試對象來執行的特定用例，例如，添加或修改某個合同。表1-12性能測試說明表測試目標：核實所指定的事務或業務功能在以下情況下的性能行為： 正常的預期工作量預期的最繁重工作量方法：使用為功能或業務周期測試制定的測試過程。通過修改數據義件來增加事務數量，或通過修改腳本來增加每項 事務的迭代次數。腳本應該

11、在一臺計算機上運行（最好是以單個用戶、單個事務為 基準），并在多臺客戶機（虛擬的或實際的客戶機，請參見下而 的“需考慮的特殊事項”）上重復。完成標準：單個事務或單個用戶：在每個事務所預期或要求的時間范圍內 成功地完成測試腳本，沒有發生任何故障。多個事務或多個用戶：在可接受的時間范圍內成功地完成測試 腳本，沒有發生任何故障。需考慮的特 殊事項：綜合的性能測試還包括在服務器上添加后臺工作量?？刹捎枚喾N方法來執行此操作，其中包括：直接將“事務強行分配到"服務器上，這通常以“結構化查詢語 言"（SQL）調用的形式來實現。通過創建“虛擬的”用戶負裁來模擬許多個（通常為數百個）客 戶機

12、。此負我可通過遠程終端仿真（Remote TerminalEmulation） 工具來頭現。此技術還可用于在網絡中加載“流 量”。使用多臺實際客戶機（每臺客戶機都運行測試腳本）在系統上添 加負裁。性能測試應該在專用的計算機上或在專用的機時內執行，以便實現完全的控制和精確的評測。性能測試所用的數據庫應該是與實際大小相同或等比例縮放的數據庫。5 .工具自動化性能測試工具：LoadRunner-116 .資源本節列出推薦 網上訂票系統 項目使用的資源，及其主要職責、知識或技能 人力資源下表列出了在此項目的人員配備方面所作的各種假定。注：可視情況刪除或添加項目。表1-20人力資源說明表人力資源角色推薦

13、的最少資源具體職責或注釋測試組長，1人負責擬定軟件項目的測試計劃和方案， 提供測試技術指導，組織測試資源，安 排測試計劃實施，提交測試分析報告， 總結整個測試活動。測試設計員3人參與制定測試計劃，生成測試模型，在 面向對象的設計系統中確定并定義測 試類的操作、屬性和關聯關系，確定測 試用例，指導測試實施，參與測試評估 和測試分析報告的編寫。測試員3人執行實施測試，填寫測試記錄，記錄結 果和缺陷。系統資源下表列出了測試項目所需的系統資源。此時并不完全了解測試系統的具體元素。建議讓系統模擬生產環境，并在適 當的情況下減小訪問量和數據庫大小。表1-21系統資源說明表系統資源資源名稱/類型數據庫服務器

14、網絡或子網一服務器名服務器名一數據庫名客戶端測試PC一包括特殊的配置需求測試存儲庫一網絡或子網一服務器名服務器名測試開發PC7 .測試進度和里程碑項目測試進度以下測試工作任務的起止時間為：(1)制定測試計劃確定測試需求- 評估風險- 制定測試策略- 確定測試資源- 創建時間表- 生成測試計劃(2)設計測試準備測試計劃說明書- 確定并說明測試用例- 復審和評估測試覆蓋(3)實施測試單元測試階段- 集成測試階段- 系統測試階段- 提交測試分析報告(4)測試活動總結測試里程碑對 < 網上訂票系統 > 的測試應包括上面各節所述的各項測試的測試活動。應該為這些測試確定單獨的項目里程碑，以通知

15、項目的狀態和成果。表1-22測試里程碑說明表里程碑任務工作量開始日期結束日期制定測試計劃10學時設計測試10學時實施測試20學時評估測試4學時8.可交付工件這部分內容列出了將要創建的各種文檔、 工具和報告，及其創建人員、交付 對象和交付時間。如：測試計劃說明書、測試用例或測試腳本、開發的測試工具、 測試日志、缺陷報告、測試分析報告、測試總結等。概述(1)測試目的提供一個對項目軟件進行測試的總體安排和進度計劃，確定現有項目的信息和應測試的軟件構件標明推薦的測試需求(高層次)推薦可采用的測試策略， 并對這些策略加以說明確定所需的資源，并對測試的工作量進行估計，列出測試項目的可交付元素。(2)測試范

16、圍描述測試的各個階段，例如：單元測試、集成測試或系統測試，并說明本計劃所針對的測試類型(如功能測試或性能測試) 。簡要地列出測試對象中將接受測試或將不接受測試的 那些特性和功能。如果在編寫此文檔的過程中作出的某些假設可能會影響測試設計、開發或實施，則列出所有這些假設。列出可能會影響測試設計、 開發或實施的所有風險或意外事件。 列出可能會影響 測試設計、開發或實施的所有約束。(3)限制條件a.設備所用到的設備類型、數量和預定使用時間；b.軟件列出將被用來支持本項測試過程而本身又并不是被測軟件的組成部分的軟件，如測試驅動程序、測試監控程序、仿真程序、樁模塊等等；( . 人員列出在測試工作期間預期可由用戶和開發任務組提供的工作人員的人數。技術水平及有關的預備知識，包括一些特殊要求，如倒班操作和數據鍵入人員。( 4)參考文檔列出制作此測試計劃所依據的文檔，如：需求規約、設計規約，概要或詳細設計、業務流程、數據流程等。列出要用到的參考資料，如：測試摘要( 1 )測試目標( 2)資源和工具a. 資源項目使用的資源，及其主要職責、知識或技能。b. 工具列出測試所使用的測試工具或自主開發的測試軟件，說明運用這些工具或開發軟件測試對