為了確保事情或工作得以順利進行，通常需要預先制定一份完整的方案,，方案一般包括指導思想,、主要目標,、工作重點,、實施步驟,、政策措施,、具體要求等項目,。那么我們該如何寫一篇較為完美的方案呢,？下面是小編為大家收集的方案策劃書范文,，僅供參考，希望能夠幫助到大家,。

測試計劃如何編寫 測試計劃和測試方案區(qū)別篇一

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

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

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

壓力測試計劃

1,、測試計劃名稱

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

2、測試內(nèi)容

2.1背景

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

◇由兩臺 xseries250 pc server組成的microsoft cluster,；

◇數(shù)據(jù)庫管理系統(tǒng)采用oracle8.1.6,；

◇應用服務器程序和數(shù)據(jù)庫管理系統(tǒng)同時運行在microsoft cluster上。

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

2.2測試項

應用服務器的壓力測試；

2.3不被測試的特性

◇系統(tǒng)的客戶端應用程序的內(nèi)部功能,；

◇數(shù)據(jù)庫中的數(shù)據(jù)量對程序性能的影響,。

3、測試計劃

3.1測試強度估算

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

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

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

測試壓力的估算結果：

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

要,，測試需按現(xiàn)有業(yè)務量的2倍進行,。

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

每天的請求數(shù)量為：300/160=1.875萬次/天,。

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

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

3.2測試環(huán)境準備

3.2.1基本硬件及軟件環(huán)境的準備

1)網(wǎng)絡環(huán)境：公司內(nèi)部的`以太網(wǎng),，與服務器的連接速率為100m，與客戶端的連接速率為10/100m自適應,。

2)使用兩臺ibm xseries250（1g內(nèi)存）pc server作microsoft cluster,，安裝系統(tǒng)軟件

20xx advance server及microsoft cluster server（mscs）。

3)數(shù)據(jù)庫管理系統(tǒng)的安裝及配置：在測試用的ibm xseries服務器上安裝oracle8.1.6,，數(shù)據(jù) 庫采用

fail safe（ofs）的active/passive配置,。 安裝數(shù)據(jù)庫管理系統(tǒng)及支撐軟件（包括visibroker和bdeadministrator）,。

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

5)客戶端的pc機：10臺（pⅲ600/128m ram）,。

3.2.2系統(tǒng)客戶端測試程序的編寫系統(tǒng)客戶端測試程序使用delphi編寫，要求測試程序?qū)崿F(xiàn)如下功能：

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

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

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

3)在數(shù)據(jù)庫中建立測試記錄表,，生成測試記錄，向數(shù)據(jù)庫寫入測試記錄的功能不通過被測的應用服務器實現(xiàn),。日志內(nèi)容包括：發(fā)送測試請求的機器名,、客戶端測試程序序號、發(fā)出請求時間,、收到響應時間,、處理是否成功。表名：test_log,，字段名：machine,、id、start_time,、end_time,、flag。

3.2.3系統(tǒng)本底數(shù)據(jù)的準備

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

3.3破壞性測試

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

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

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

在測試過程中每10分鐘記錄一次ibm xseries pc

server的內(nèi)存及cpu使用情況，包括被測程序的內(nèi)存占用百分比,、數(shù)據(jù)庫管理系統(tǒng)的內(nèi)存占用百分比,、操作系統(tǒng)的內(nèi)存占用百分比。

3.4強度穩(wěn)定性測試

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

1.5倍）,，進行24小時穩(wěn)定性測試,。

3.5測試方法和工具

黑盒測試

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

3.6測試時間計劃

3.6.1環(huán)境準備：2天,。

其中：基本硬件、軟件環(huán)境及系統(tǒng)本底數(shù)據(jù)的準備：1天,，

系統(tǒng)客戶端測試程序的編寫及測試：1天,。

3.6.2破環(huán)性測試：2天。

3.6.3強度穩(wěn)定性測試：1天,。

3.7測試中的問題及處理

3.7.1暫停標準和再啟動要求

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

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

3.7.2不可預見問題

不可預見問題包括：

◇測試環(huán)境被破壞而導致測試無法進行,；

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

3.8測試報告 20xx.06.21

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

3.8.1應生成的測試文件

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

測試總結報告,。

3.8.2測試總結報告中必須包含的內(nèi)容

被測試軟件名稱、測試項,、測試環(huán)境,；

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

4,、人員和職責

4.1職責

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

軟件工程師：負責編寫,、調(diào)試客戶端測試軟件,；數(shù)據(jù)庫管理系統(tǒng)的安裝、ofs配置及系統(tǒng)的本底數(shù)據(jù)準備,。系統(tǒng)工程師：負責測試用的硬件維護及操作系統(tǒng)安裝,、mscs配置。

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

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

4.2人員和訓練要求

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

5、批準

本測試計劃必須經(jīng)過總工程師批準后才能開始實施,。

測試計劃如何編寫 測試計劃和測試方案區(qū)別篇二

1．引言

1.1編寫目的

編寫“網(wǎng)上購物系統(tǒng)測試計劃“的目的是：

（1） 提供一個對項目軟件進行測試的總體安排和進度計劃,，確定現(xiàn)有項目的信息和應測試軟件構件，便于測試人員測試,。

（2）推薦可采用的測試策略,，并對這些策略加以說明。

（3）確定所需的資源,，并對測試的工作量進行估計,。

1.2項目背景

1.項目名稱：

網(wǎng)上購物系統(tǒng)

2 軟件應用：

適用于網(wǎng)上產(chǎn)品的信息收集和發(fā)布活動，為用戶提供良好的交易平臺,。

3項目背景：

網(wǎng)上購物系統(tǒng)應該能夠為用戶提供充足的信息和快捷的購買手段,。隨著商品經(jīng)濟的發(fā)展及人們消費水平的提高，還有信息時代的飛躍,，越來越多的人愛上了網(wǎng)購,，從而催生了網(wǎng)上購物系統(tǒng)的誕生。它為人們購物帶來了方便快捷,，節(jié)約了沒時間出去而省下了空間,。 4項目開發(fā)過程：

該項目目前后經(jīng)歷三個階段,，前期設計階段，然后是開發(fā)階段,，最后是軟件的測試階段,。項目的用戶針對的是網(wǎng)上購物的廣大群眾和管理員，系統(tǒng)的功能測試主要由專業(yè)的軟件測試人員進行測試,。

5任務提出者：,；

6開發(fā)者：軟件工程課程設計小組成員：

7用戶：購物者、管理員

8本系統(tǒng)將使用sqlserver20xx作為數(shù)據(jù)庫存儲系統(tǒng),。

1.3定義 1.黑盒測試: 黑盒測試也稱功能測試,，它是通過測試來檢測每個功能是否都能正常使用。在測試中,，把程序看作一個不能打開的黑盒子,，在完全不考慮程序內(nèi)部結構和內(nèi)部特性的情況下，在程序接口進行測試,，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用,，程序是否能適當?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。黑盒測試著眼于程序外部結構,，不考慮內(nèi)部邏輯結構,，主要針對軟件界面和軟件功能進行測試。

2.單元測試：對各個模塊的源代碼進行測試,，保證各模塊基本功能能夠正確的實現(xiàn),；

3 集成測試：將各個模塊進行組合測試，保證所有的功能都能夠正確的實現(xiàn),；

4系統(tǒng)測試：根據(jù)《需求規(guī)格說明書》對軟件進行功能測試,，對重點的模塊進行性能測試，并結合可能的用戶測試,；

5 驗收測試：根據(jù)用戶手冊對功能進行檢查,，復查報告庫中的所有bug，對release版本進行安裝測試,。

6 asp(active server pages)是微軟公司推出的一種用以取代cgi的技術,，基于目前絕大多數(shù)網(wǎng)站應用于windows平臺，asp是一個位于windows服務器端的腳本運行環(huán)境,，通過這種環(huán)境,，用戶可以創(chuàng)建和運行動態(tài)的交互式的web服務器應用程序以及edi（電子數(shù)據(jù)交換）；

7 ado：activex data object, activex 數(shù)據(jù)對象,；

8 sql：structured query language,。

1.4參考資料

a. 網(wǎng)上購物系統(tǒng)開發(fā)計劃書；

b. 網(wǎng)上購物系統(tǒng)需求規(guī)格說明書,；

c. 網(wǎng)上購物系統(tǒng)設計說明書,；

d. 網(wǎng)上購物系統(tǒng)設計模型,；

e. 網(wǎng)上購物系統(tǒng)需求分析設計模型

f. 網(wǎng)上購物系統(tǒng)用戶操作手冊；

2．任務概述

2.1目標

測試網(wǎng)上購物系統(tǒng)中的各個功能模塊是否滿足用戶需求,，并測試是否存在bug,。預期達到能夠使系統(tǒng)進行快速的改進和系統(tǒng)的提高。為了在軟件投入生產(chǎn)性運行之前,，盡可能多地發(fā)現(xiàn)軟件的錯誤,，從而提高軟件運行的穩(wěn)定性和提高用戶體驗。

2.2運行環(huán)境

操作系統(tǒng)：windows

開發(fā)環(huán)境：vs20xx,，sql server 20xx

處理器：主頻1.6g以上,，硬盤40g，內(nèi)存2g

2.3需求概述

已被確定為測試對象的項目有：

1．數(shù)據(jù)庫測試

2．功能性測試

3．用戶界面測試

4．性能測試

5．安全性和訪問控制測試

6．配置測試

2.4條件與限制

設備所用到的設備類型,、數(shù)量和預定使用時間:

pc,，主頻1.6g以上,，硬盤40g,，內(nèi)存2g 1臺。

3．計劃

3.1測試方案

（1）數(shù)據(jù)和數(shù)據(jù)庫完整性測試

數(shù)據(jù)庫和數(shù)據(jù)庫進程應作為“網(wǎng)上購物系統(tǒng)”中的子系統(tǒng)來進行測試,。 在測試這些子系統(tǒng)時,，不應將測試對象的用戶界面用作數(shù)據(jù)的接口。對于數(shù)據(jù)庫管理系統(tǒng) (dbms),，還需要進行深入的研究,，以確定可以支持以下測試的工具和方法。

（2）功能測試

測試對象的功能測試應該側重于可以被直接追蹤到用例或業(yè)務功能和業(yè)務規(guī)則的所有測試需求,。這些測試的目標在于核實能否正確地接受,、處理和檢索數(shù)據(jù)以及業(yè)務規(guī)則是否正確實施。這種類型的測試基于黑盒方法,，即通過圖形用戶界面 (gui) 與應用程序交互并分析輸出結果來驗證應用程序及其內(nèi)部進程,。以下列出的是每個應用程序推薦的測試方法概要：

（3）用戶界面測試

通過用戶界面 (ui) 測試來核實用戶與軟件的交互。ui 測試的目標在于確保用戶界面向用戶提供了適當?shù)脑L問和瀏覽測試對象功能的操作,。除此之外,，ui 測試還要確保 ui 功能內(nèi)部的對象符合預期要求，并遵循公司或行業(yè)的標準,。

（4）性能評價

性能評價是一種性能測試,，它對響應時間、事務處理速率和其他與時間相關的需求進行評測和評估,。

測試計劃如何編寫 測試計劃和測試方案區(qū)別篇三

各系部：

為了全面實施《大學生體質(zhì)健康標準》,，根據(jù)省體育局、省教育廳體衛(wèi)處的要求,，決定本期對我院畢業(yè)班的學生進行《標準》測試,，具體測試安排如下：

一,、測試對象：全院20xx屆畢業(yè)班學生。其中包括三年制大專班學生和五年制大專班學生全院有88個班級共計870人

二,、測試項目：1,、身高/體重2、肺活量,、握力4,、立定跳遠、1000米（男）,、800米（女）,。

三、測試時間：見附表（音樂系和旅游系安排在20xx年月進行測試,。時間另行通知,。1000米和800米統(tǒng)一安排在周末測試）

四、測試地點：本院區(qū)在體育館和田徑場,；新院區(qū)在科技樓a棟107,、111、208教室和田徑場,。

五,、測試要求：

1請各系部通知到每一個學生，嚴格按照以班為單位參加測試,，測試時請各班班長按學號順序收好學生證,，統(tǒng)一交給各項目測試的負責老師

2各系部認真組織學生在規(guī)定的時間、地點,，必須帶好學生證參加測試,，未帶證不準參加測試。

3．體質(zhì)測試是學生畢業(yè)成績的組成部分對無故不參加測試或測試成績不合格的學生,經(jīng)補測合格后,，方能頒發(fā)畢業(yè)證書

4各測試項目的成績由體育部匯總,，并按照《標準》的要求評定成績、確定等級,，在畢業(yè)的時候放入學生檔案,。