webtours測試計劃

1、網(wǎng)上訂票系統(tǒng)測試計劃表1-5 測試計劃說明表總頁數(shù)正文附錄生效日期： 2015年 1月 14日編制：審核：批準：表1-6修訂歷史記錄日期版本說明作者2015/1/14<x.x><詳細信息><姓名>目錄1.簡介 121.1目的121.2背景121.3范圍121.4使用文檔122.測試需求133.測試風險144.測試策略144.1測試類型14數(shù)據(jù)和數(shù)據(jù)庫完整性測試14功能測試15業(yè)務周期測試16用戶界面測試17性能評價18負載測試20強度測試20容量測試22安全性和訪問控制測試23故障轉移和恢復測試24配置測試27安裝測試285.工具-296資源 296.1人力

2、資源296.2系統(tǒng)資源307.測試進度和里程碑317.1項目測試進度317.2測試里程碑328.可交付工件321.簡介1.1目的網(wǎng)上訂票系統(tǒng)的這一“測試計劃”文檔的目的是：（1） 提供一個對項目軟件進行測試的總體安排和進度計劃，確定現(xiàn)有項目的信息和應測試軟件構件。（2）標明推薦的測試需求（高層次）。（3）推薦可采用的測試策略，并對這些策略加以說明。（4）確定所需的資源，并對測試的工作量進行估計。（5）列出測試項目的可交付元素12背景本項目測試的對象是HP LoadRunner軟件自帶的Web Tours網(wǎng)上訂票系統(tǒng)，這是一款基于ASP.NET平臺的網(wǎng)站。基于先進的.NET Framework，

3、默認支持SOL Server數(shù)據(jù)庫，可擴展支持ACCESS、MySql等多種數(shù)據(jù)庫。支持基于IE、Chrome、Firefox、Opera等瀏覽器。Web Tours網(wǎng)站主要是提供方全世界用戶進行網(wǎng)上訂票、查看訂票信息、預訂機票、修改預訂機票的功能支持。13范圍對Web Tours網(wǎng)站的注冊、登陸、訂票、查詢以及退票功能進行功能測試、性能測試和界面測試14使用文檔下表列出了制定測試計劃所用的文檔，并標明了文檔的可用性：表1-7 測試計劃使用文檔列表文檔（版本/日期）已創(chuàng)建或可用已被接受或已經(jīng)過復審作者或來源備注測試計劃模版是是老師2.測試需求下面列出了那些已被確定為測試對象的項目（用例、功能性

4、需求和非功能性需求）。此列表說明了測試的對象。在此處輸入一個主要測試需求的高層次列表。例如：2.1功能測試注冊、登陸、訂票、查詢以及退票功能2.2用戶界面測試注冊、登陸、訂票、查詢以及退票功能2.3性能測試注冊、登陸、訂票、查詢以及退票功能3.測試風險軟件測試風險是不可避免的、總是存在的，所以對測試風險的管理非常重要，必須盡力降低測試中所存在的風險，最大程度地保證質量和滿足客戶的需求。在測試工作中，主要的風險有：1質量需求或產(chǎn)品的特性理解不準確，造成測試范圍分析的誤差，結果某些地方始終測試不到或驗證的標準不對；2測試用例沒有得到百分之百的執(zhí)行，如有些測試用例被有意或無意的遺漏；3需求的臨時/突

5、然變化，導致設計的修改和代碼的重寫，測試時間不夠；4質量標準不都是很清晰的，如適用性的測試，仁者見仁、智者見智；5測試用例設計不到位，忽視了一些邊界條件、深層次的邏輯、用戶場景等；6測試環(huán)境，一般不可能和實際運行環(huán)境完全一致，造成測試結果的誤差；7有些缺陷出現(xiàn)頻率不是百分之百，不容易被發(fā)現(xiàn)；如果代碼質量差，軟件缺陷很多，被漏檢的缺陷可能性就大；8回歸測試一般不運行全部測試用例，是有選擇性的執(zhí)行，必然帶來風險。前面三種風險是可以避免的，而四至七的四種風險是不能避免的，可以降到最低。最后一種回歸測試風險是可以避免，但出于時間或成本的考慮，一般也是存在的。針對上述軟件測試的風險，有一些有效的測試風險

6、控制方法，如：測試環(huán)境不對可以通過事先列出要檢查的所有條目，在測試環(huán)境設置好后，由其他人員按已列出條目逐條檢查； 有些測試風險可能帶來的后果非常嚴重，能否將它轉化為其他一些不會引起嚴重后果的低風險。如產(chǎn)品發(fā)布前夕，在某個不是很重要的新功能上發(fā)現(xiàn)一個嚴重的缺陷，如果修正這個缺陷，很有可能引起某個原有功能上的缺陷。這時處理這個缺陷所帶來的風險就很大，對策是去掉(Diasble)那個新功能，轉移這種風險； 有些風險不可避免，就設法降低風險，如“程序中未發(fā)現(xiàn)的缺陷”這種風險總是存在，我們就要通過提高測試用例的覆蓋率（如達到99.9%）來降低這種風險； 為了避免、轉移或降低風險，事先

7、要做好風險管理計劃和控制風險的策略，并對風 險的處理還要制定一些應急的、有效的處理方案。4.測試策略 4.1功能測試 測試對象的功能測試應該側重于可以被直接追蹤到用例或業(yè)務功能和業(yè)務規(guī)則的所有測試需求。這些測試的目標在于核實能否正確地接受、處理和檢索數(shù)據(jù)以及業(yè)務規(guī)則是否正確實施。這種類型的測試基于黑盒方法，即通過圖形用戶界面 (GUI) 與應用程序交互并分析輸出結果來驗證應用程序及其內(nèi)部進程。以下列出的是每個應用程序推薦的測試方法概要：表1-9 功能測試說明表測試目標：確保測試對象的功能正常，其中包括導航、數(shù)據(jù)輸入、處理和檢索等。方法：利用有效的和無效的數(shù)據(jù)來執(zhí)行各個用例、用例流或功能，以核實

8、以下內(nèi)容：在使用有效數(shù)據(jù)時得到預期的結果。在使用無效數(shù)據(jù)時顯示相應的錯誤消息或警告消息。各業(yè)務規(guī)則都得到了正確的應用。完成標準：所計劃的測試已全部執(zhí)行。所發(fā)現(xiàn)的缺陷已全部解決。需考慮的特殊事項：確定或說明那些將對功能測試的實施和執(zhí)行造成影響的事項或因素（內(nèi)部的或外部的）4.2用戶界面測試 通過用戶界面 (UI) 測試來核實用戶與軟件的交互。UI 測試的目標在于確保用戶界面向用戶提供了適當?shù)脑L問和瀏覽測試對象功能的操作。除此之外，UI 測試還要確保 UI 功能內(nèi)部的對象符合預期要求，并遵循公司或行業(yè)的標準。表1-11 用戶界面測試說明表測試目標：核實以下內(nèi)容：通過瀏覽測試對象可正確反映業(yè)務的功能

9、和需求，這種瀏覽包括窗口與窗口之間、字段與字段之間的瀏覽，以及各種訪問方法（Tab 健、鼠標移動和快捷鍵）的使用窗口的對象和特征（例如：菜單、大小、位置、狀態(tài)和中心）都符合標準。方法：為每個窗口創(chuàng)建或修改測試，以核實各個應用程序窗口和對象都可正確地進行瀏覽，并處于正常的對象狀態(tài)。完成標準：證實各個窗口都與基準版本保持一致，或符合可接受標準需考慮的特殊事項：并不是所有定制或第三方對象的特征都可訪問。4.3性能評價 性能評價是一種性能測試，它對響應時間、事務處理速率和其他與時間相關的需求進行評測和評估。性能評價的目標是核實性能需求是否都已滿足。實施和執(zhí)行性能評價的目的是將測試對象的性能為當作條件（

10、例如工作量或硬件配置）的一種函數(shù)來進行評價和微調。注：以下事務均指“邏輯業(yè)務事務”。這種事務被定義為將由系統(tǒng)的某個主角通過使用測試對象來執(zhí)行的特定用例，例如，添加或修改某個合同。表1-12性能測試說明表測試目標：核實所指定的事務或業(yè)務功能在以下情況下的性能行為：正常的預期工作量預期的最繁重工作量方法：使用為功能或業(yè)務周期測試制定的測試過程。通過修改數(shù)據(jù)文件來增加事務數(shù)量，或通過修改腳本來增加每項事務的迭代次數(shù)。腳本應該在一臺計算機上運行（最好是以單個用戶、單個事務為基準），并在多臺客戶機（虛擬的或實際的客戶機，請參見下面的“需考慮的特殊事項”）上重復。完成標準：單個事務或單個用戶：在每個事務所

11、預期或要求的時間范圍內(nèi)成功地完成測試腳本，沒有發(fā)生任何故障。多個事務或多個用戶：在可接受的時間范圍內(nèi)成功地完成測試腳本，沒有發(fā)生任何故障。需考慮的特殊事項：綜合的性能測試還包括在服務器上添加后臺工作量。 可采用多種方法來執(zhí)行此操作，其中包括：直接將“事務強行分配到”服務器上，這通常以“結構化查詢語言”(SQL) 調用的形式來實現(xiàn)。通過創(chuàng)建“虛擬的”用戶負載來模擬許多個（通常為數(shù)百個）客戶機。 此負載可通過“遠程終端仿真”(Remote Terminal Emulation) 工具來實現(xiàn)。 此技術還可用于在網(wǎng)絡中加載“流量”。使用多臺實際客戶機（每臺客戶機都運行測試腳本）在系統(tǒng)上添加負載。 性能

12、測試應該在專用的計算機上或在專用的機時內(nèi)執(zhí)行，以便實現(xiàn)完全的控制和精確的評測。性能測試所用的數(shù)據(jù)庫應該是與實際大小相同或等比例縮放的數(shù)據(jù)庫。5.工具自動化性能測試工具：LoadRunner-116.資源本節(jié)列出推薦 <網(wǎng)上訂票系統(tǒng)> 項目使用的資源，及其主要職責、知識或技能。6.1人力資源下表列出了在此項目的人員配備方面所作的各種假定。注：可視情況刪除或添加項目。表1-20人力資源說明表人力資源角色推薦的最少資源具體職責或注釋測試組長，1人負責擬定軟件項目的測試計劃和方案，提供測試技術指導，組織測試資源，安排測試計劃實施，提交測試分析報告，總結整個測試活動。測試設計員3人參與制定測

13、試計劃，生成測試模型，在面向對象的設計系統(tǒng)中確定并定義測試類的操作、屬性和關聯(lián)關系，確定測試用例，指導測試實施，參與測試評估和測試分析報告的編寫。測試員3人執(zhí)行實施測試，填寫測試記錄，記錄結果和缺陷。6.2系統(tǒng)資源下表列出了測試項目所需的系統(tǒng)資源。 此時并不完全了解測試系統(tǒng)的具體元素。建議讓系統(tǒng)模擬生產(chǎn)環(huán)境，并在適當?shù)那闆r下減小訪問量和數(shù)據(jù)庫大小。表1-21系統(tǒng)資源說明表系統(tǒng)資源資源名稱/類型數(shù)據(jù)庫服務器網(wǎng)絡或子網(wǎng)服務器名服務器名數(shù)據(jù)庫名客戶端測試 PC包括特殊的配置需求測試存儲庫網(wǎng)絡或子網(wǎng)服務器名服務器名測試開發(fā) PC7.測試進度和里程碑7.1項目測試進度以下測試工作任務的起止時間為：（1）

14、制定測試計劃- 確定測試需求- 評估風險- 制定測試策略- 確定測試資源- 創(chuàng)建時間表- 生成測試計劃（2）設計測試-準備測試計劃說明書-確定并說明測試用例-復審和評估測試覆蓋（3）實施測試- 單元測試階段- 集成測試階段- 系統(tǒng)測試階段- 提交測試分析報告（4） 測試活動總結 1.217.2測試里程碑 對 <網(wǎng)上訂票系統(tǒng)> 的測試應包括上面各節(jié)所述的各項測試的測試活動。應該為這些測試確定單獨的項目里程碑，以通知項目的狀態(tài)和成果。表1-22測試里程碑說明表里程碑任務工作量開始日期結束日期制定測試計劃10學時1.121.14設計測試10學時1.151.16實施測試20學時1.181.

15、20評估測試4學時1.211.218.可交付工件 這部分內(nèi)容列出了將要創(chuàng)建的各種文檔、工具和報告，及其創(chuàng)建人員、交付對象和交付時間。如：測試計劃說明書、測試用例或測試腳本、開發(fā)的測試工具、測試日志、缺陷報告、測試分析報告、測試總結等。8.1概述（1）測試目的 提供一個對項目軟件進行測試的總體安排和進度計劃，確定現(xiàn)有項目的信息和應測試的軟件構件標明推薦的測試需求（高層次）推薦可采用的測試策略，并對這些策略加以說明確定所需的資源，并對測試的工作量進行估計，列出測試項目的可交付元素。 （2）測試范圍描述測試的各個階段，例如：單元測試、集成測試或系統(tǒng)測試，并說明本計劃所針對的測試類型（如功能測試或性能

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