webtours測試計劃

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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