測試計劃

時間：2024-11-03 06:27:25 計劃我要投稿

有關測試計劃三篇

　　時間過得太快，讓人猝不及防，我們的工作又將在忙碌中充實著，在喜悅中收獲著，此時此刻需要制定一個詳細的計劃了。你所接觸過的計劃都是什么樣子的呢？以下是小編精心整理的測試計劃3篇，希望對大家有所幫助。

有關測試計劃三篇

測試計劃篇1

　　利用現代的設計技術和正式的技術復審可以減少代碼中存在的初始錯誤，但是錯誤總是存在的，如果開發者找不到錯誤，那么，客戶就會找到它們。越來越多的軟件組織認識到軟件測試是軟件質量保證的重要元素之一，很多軟件開發組織將30%—40%甚至更多的項目資源用在測試上，軟件測試技術和軟件測試策略受到了高度的重視和廣泛的應用。

　　本文不想就軟件測試技術和軟件測試策略作深入的理論分析，而是列舉一個在軟件系統測試階段進行的壓力測試實例，希望能通過這個實例與從事軟件測試相關工作的朋友進行交流。

　　首先介紹一下實例中軟件的項目背景，該軟件是一個典型的三層C/S架構的MIS系統（客戶端/應用服務器/數據庫管），中間層是業務邏輯層，應用服務器處理所有的業務邏輯，但應用服務器本身不提供負載均衡的能力，而是利用開發工具提供的ORB（對象請求代理）軟件保證多個應用服務器間的負載均衡。本次測試的目的是：進行單個應用服務器的壓力測試，找出單個應用服務器能夠支持的最大客戶端數。測試壓力估算的依據是：假定在實際環中，用戶只啟用一個應用服務器進行所有的業務處理。方法是：按照正常業務壓力估算值的1~10倍進行測試，考察應用服務器的運行情況。

　　壓力測試的詳細計劃如下：

　　壓力測試計劃

　　1、測試計劃名稱

　　河北省公安交通管理信息系統壓力測試計劃。

　　2、測試內容

　　2.1背景

　　本次測試中的壓力測試是指模擬實際應用的軟硬件環境及用戶使用過程的系統負荷，長時間運行測試軟件來測試被測系統的可靠性，同時還要測試被測系統的響應時間。用戶的實際使用環境：

　　◇由兩臺 XSeries250 PC Server組成的Microsoft Cluster；

　　◇數據庫管理系統采用Oracle8.1.6；

　　◇應用服務器程序和數據庫管理系統同時運行在Microsoft Cluster上。

　　◇有200個用戶使用客戶端軟件進行業務處理，每年通過軟件進行處理的總業務量為：150萬筆業務/年。

　　2.2測試項

　　應用服務器的壓力測試；

　　2.3不被測試的特性

　　◇系統的客戶端應用程序的內部功能；

　　◇數據庫中的數據量對程序性能的影響。

　　3、測試計劃

　　3.1測試強度估算

　　測試壓力估算時采用如下原則：

　　◇全年的業務量集中在8個月完成，每個月20個工作日，每個工作日8個小時；

　　◇采用80—20原理，每個工作日中80%的業務在20%的時間內完成，即每天80%的業務在1.6小時內完成；

　　測試壓力的估算結果：

　　去年全年處理業務約100萬筆，其中15%的業務處理每筆業務需對應用服務器提交7次請求；70%的業務處理每筆業務需對應用服務器提交5次請求；其余15%的業務每筆業務向應用服務器提交3次請求。根據以往統計結果，每年的業務增量為15%，考慮到今后三年業務發展的需

　　要，測試需按現有業務量的2倍進行。

　　每年總的請求數量為：（100*15%*7+100*70%*5+100*15%*3）*2=300萬次/年。

　　每天的請求數量為：300/160=1.875萬次/天。

　　每秒的請求數量為：（18750*80%）/（8*20%*3600）=2.60次/秒。

　　正常情況下，應用服務器處理請求的能力應達到：3次/秒。

　　3.2測試環境準備

　　3.2.1基本硬件及軟件環境的準備

　　1)網絡環境：公司內部的以太網，與服務器的連接速率為100M，與客戶端的連接速率為10/100M自適應。

　　2)使用兩臺IBM XSeries250（1G內存）PC Server作Microsoft Cluster，安裝系統軟件

　　20xx Advance Server及Microsoft Cluster Server（MSCS）。

　　3)數據庫管理系統的.安裝及配置：在測試用的IBM XSeries服務器上安裝Oracle8.1.6，數據庫采用

　　Fail Safe（ofs）的Active/Passive配置。安裝數據庫管理系統及支撐軟件（包括VisiBroker和BDEAdministrator）。

　　4)安裝被測的應用服務器程序。

　　5)客戶端的PC機：10臺（PⅢ600/128M RAM）。

　　3.2.2系統客戶端測試程序的編寫系統客戶端測試程序使用Delphi編寫，要求測試程序實現如下功能：

　　1)模擬一個主要的向應用服務器發送請求并接收響應信息的功能。要求交替模擬兩種情況：第一種，發送的請求至少包括10個參數，參數類型涵蓋字符、日期、數字種類型；接收的

　　響應信息不少于1個參數；第二種，發送的請求不少于1個參數；接收的響應信息至少包括10個參數，參數類型涵蓋字符、日期、數字種類型。

　　2)必須能夠通過參數設定在每臺PC機上運行的客戶端測試程序個數、請求的時間間隔（單位：毫秒）、運行時間（單位：小時）。

　　3)在數據庫中建立測試記錄表，生成測試記錄，向數據庫寫入測試記錄的功能不通過被測的應用服務器實現。日志內容包括：發送測試請求的機器名、客戶端測試程序序號、發出請求時間、收到響應時間、處理是否成功。表名：TEST_LOG，字段名：MACHINE、ID、START_TIME、END_TIME、FLAG。

　　3.2.3系統本底數據的準備

　　為考察系統運行一段時間后系統的響應性能，參照實際運行情況及發展進行系統的本底數據準備。業務處理中涉及到的業務表中都要求按設計規模進行本底數據的準備。要求準備的數據記錄的有效性符合系統要求，數據有效性的具體要求參見數據庫設計及系統設計文檔。

　　3.3破壞性測試

　　按照設計連接的客戶端連接數量進行測試，把應用服務器處理請求的設計頻度增加1－10倍，分別測試出現錯誤的狀態和和出現錯誤的比率，考察是否出現不可恢復錯誤，系統設計要考

　　慮出現嚴重錯誤情況下負荷減輕錯誤自動恢復的實現方法。

　　計劃時間：2天；這個時間包括破壞性的修復和自動恢復的實現需要的時間。

　　在測試過程中每10分鐘記錄一次IBM Xseries PC

　　Server的內存及CPU使用情況，包括被測程序的內存占用百分比、數據庫管理系統的內存占用百分比、操作系統的內存占用百分比。

　　3.4強度穩定性測試

　　選擇一種負荷比設計負荷重的情況（應用服務器處理請求的頻度為應用服務器處理請求的設計頻度的

　　1.5倍），進行24小時穩定性測試。

　　3.5測試方法和工具

　　黑盒測試

　　測試工具：無外購的測試工具，自己編制的測試工具。

　　3.6測試時間計劃

　　3.6.1環境準備：2天。

　　其中：基本硬件、軟件環境及系統本底數據的準備：1天，

　　系統客戶端測試程序的編寫及測試：1天。

　　3.6.2破環性測試：2天。

　　3.6.3強度穩定性測試：1天。

　　3.7測試中的問題及處理

　　3.7.1暫停標準和再啟動要求

　　暫停標準：被測試軟件在強度穩定性測試中頻繁出現異常（每小時出現1次以上）時。用戶或公司要求暫停測試時。

　　再啟動要求：通過調試后，預計被測試軟件的可靠性有所提高時，可再次啟動測試。

　　3.7.2不可預見問題

　　不可預見問題包括：

　　◇測試環境被破壞而導致測試無法進行；

　　◇當出現上述不可預見問題時，測試終止，就已完成的測試內容編制測試總結報告，并在報告中說明測試終止的原因。

　　3.8測試報告 20xx.06.21

　　測試總結報告提交日期：20xx.06.21。

　　3.8.1應生成的測試文件

　　測試記錄（測試負責人和參與測試的人員簽字）；

　　測試總結報告。

　　3.8.2測試總結報告中必須包含的內容

　　被測試軟件名稱、測試項、測試環境；

　　被測試軟件的壓力測試結論：響應時間、最大/最小并發數、失敗的次數、正常連續運行的最長/最短時間，并發數與失敗的關系。

　　4、人員和職責

　　4.1職責

　　測試工程師：負責編寫測試計劃，組織測試，對測試過程進行記錄，收集、整理測試記錄數據，對測試結果進行分析，編寫測試總結報告。

　　軟件工程師：負責編寫、調試客戶端測試軟件；數據庫管理系統的安裝、ofs配置及系統的本底數據準備。系統工程師：負責測試用的硬件維護及操作系統安裝、MSCS配置。

　　總工程師：負責對測試計劃及測試總結報告進行批準。

　　用戶：必要時可參加測試，并提出具體的測試要求；可要求暫停測試。

　　4.2人員和訓練要求

　　本次測試無特別的人員及培訓要求。

　　5、批準

　　本測試計劃必須經過總工程師批準后才能開始實施。

測試計劃篇2

　　在來到佳木斯牡佳客專九標中心試驗室的這段時間里，我完成了從在校大學生到中心試驗室試驗員的身份及心態轉變。雖然走出了學校，離開了象牙塔，但我已經做好了足夠的心理準備接受工作中所有未知的挑戰。

　　在來到牡佳中心試驗室以后，在王主任的培訓學習中對試驗檢測工作有所了解，在工作中從整理配合比資料開始逐漸的學習規范和專業知識，同時配合張健主任進行耐久性試驗和土工格柵的檢測，在實際操作中加深對規范的理解并能熟練操作。由于王建國主任的正確指導及同事們的協助配合，我不僅較好的完成了本職工作，而且在實踐中不斷得到鍛煉及提高，在工作上有所長進。

　　現在我在試驗室中負責混凝土配合比、土工、土工格柵及耐久性試驗，同時輔助進行外加劑的試驗檢測。目前工區即將冬休，試驗委托量已降為平時的十之二三，不過隨之而來的則是明年配合比的選定，故而容不得有一絲懈怠。

　　從現在至元旦，我將為自己制定學習計劃，確立目標并不停的提高自己。

　　1、不斷提高自己的理論知識水平，通過文獻、書本及教學視頻不斷的學習專業知識、對于掌握的'試驗項目能夠知其然亦知其所以然，理解試驗的每一個參數，對試驗的結果有自己的判斷。

　　2、進行混凝土配合比試驗的過程，也是我學習的過程。我可以在混凝土配合比的各項試驗中，了解混凝土試件的取樣及試件尺寸、熟悉試件的制作及養護條件、掌握試件各項力學性指標的試驗方法及步驟。查漏補缺，發現自己的不足，加深對混凝土配合比的理解。對相關國家標準、規范，試驗室相關文件的學習也不會停止，通過對標準規范的學習，結合實際的試驗操作，讓自己的試驗操作更規范更準確。

　　3、對于我未曾接觸的如水泥、粉煤灰等材料的相關試驗，我會在膠凝室空閑的時間內對照規范學習試驗與操作，基本達到認識和熟悉水泥、粉煤灰常規檢測項目的目標。而對于較為熟悉的土工試驗項目，我也會學習其余的土工試驗，對已經掌握的試驗項目也要精益求精，保證不會出錯。

　　4、努力做到在工作時提前準備，合理安排工作日程，讓自己能夠發揮自己最大的潛能和積極主動性，提高工作效率。

測試計劃篇3

　　測試計劃中所有測試方法和模塊已經執行通過所有的測試案例已經執行過

　　所有的重要等級為1/2的Bug已經解決并由測試驗證

　　第2章項目背景

　　2、1測試范圍

　　說明本計劃涵蓋的測試范圍，比如功能測試、集成測試、系統測試、驗收測試等、通常說明什么是要測試的，什么是不要測試的是非常重要的、明確規定這些問題后，測試人員對該做什么有一個清晰的認識

　　（1）簡要地列出測試對象中將接受測試或將不接受測試的那些性能和功能

　　（2）如果在編寫此文檔的過程中作出的某些假設可能會影響測試設計、開發或實施，則列出所有這些假設

　　（3）列出可能會影響測試設計、開發或實施的所有風險或意外事件

　　（4）列出可能會影響測試設計、開發或實施的所有約束

　　提示和技巧：

　　需要測試和特別注意測試那些部分？測試是否專么針對與某些問題的解決哪些部分不需要測試，為什么？哪些部分需要推遲測試，為什么是否要驗證每個模塊的穩定性？測試的`優先級和先后順序

　　2、2測試目標

　　系統目標對測試人員了解自己需要做什么是非常重要的、測試項目負責人應積極與系統設計人員或開發人員溝通，以取得相關資料、測試人員必須知道系統是做什么并且幫助項目實現這種目標、在計劃中包括系統視圖和目標后，要確保所有的測試人員都知道項目和系統的目標、通常情況下項目計劃都是模糊的、模糊的目標必須通過成員的努力轉換成可衡量和實現的東西、沒有固定的視圖和目標，你將無法完成部分任務、而且，你會發現很難將對產品的認識向別人轉述

　　2、3聯系方式

　　列出項目參與人員的職務、姓名、E—mail和電話

【測試計劃】相關文章：

測試計劃模板09-20

測試方案模板08-24

測試工作總結05-20