軟體測試計劃書

標籤：

1.       引言1.1.  目的

測試軟體中的各個功能模組是否滿足使用者要求，並測試是否存bug。預期達到能夠使系統進行快速的改進和系統的提高。為了在軟體投入生產性運行之前，儘可能多地發現軟體的錯誤。

1.2.  背景

a．     為方便學習和工作比較忙碌的上班族和學生記錄資訊，避免遺忘而出現特大損失。

 

 b．    該開發項目的曆史，列出使用者和執行此項目測試的機構或人群;該項目前後經曆了三個階段，前期設計階段，然後是開發階段，最後是軟體的測試階段。項目的使用者針對的是本學校的一些想要在空閑時間背單詞的學生，系統的功能測試主要由專業的軟體測試人員進行測試。

1.3.  範圍

主要測試軟體的功能是否滿足客戶的需要，效能是否優越以及系統所存在的問題。對系統的各個模組進行詳細的測試，並記錄測試的結果，對測試的結果進行細緻的分析處理。測試時對系統的各個功能模組進行拆分測試，並以每一個模組都要測試到。對所有可能的結果進行測試，以及測試過程中存在的問題進行分析，然後提交測試的記錄。最後，對軟體存在的問題以及效能的測試進行全面分析，並給予記錄。

在測試的過程中需要提出各個問題的假設，以及根據需求報告文檔中存在的項目功能模組和使用者的需求來改善系統。列出可能會影響測試設計、開發、或實施的所有風險或意外事件。列出可能會影響測試設計、開發或實施的所有約束。

1.4.  定義                                                

 資訊（Information）：有關資料庫中單詞的詞義，詞性，單詞本身等

管理（Manage）：各級詞庫的選擇

1.5.  參考資料

列出編寫本計劃及測試整個過程中所要參考的檔案、資料。

      

編號	資料名稱	作者	日期	出版單位
1	《軟體測試入門與提高》	張成明	2008.6	清華大學出版社
2	《軟體測試基礎教程》	劉建宇	2007.3	郵電大學出版社
	《軟體測試自動化的引入和應用》	李剛	2004.4	機械工業出版社

 

 

 

2.       測試內容

下表列出了測試需求，並對其進行了優先順序定義：

子系統名稱	模組名稱	測試點	優先順序	說明
今日事	語音錄入	開始錄音		第一操作
		結束錄音		開始錄音的後續操作
		儲存錄音		結束錄音的後續操作
		點擊空白處		沒有反應
		返回		退出語音錄入功能

3.       測試規則3.1.  進入準則

安裝安裝包以後就可以進行使用。

3.2.  暫停/退出準則

軟體系統在進行單元、整合、確認、系統、安裝、驗收測試時，發現一級錯誤（大於等於1）、二級錯誤（大於等於2）暫停測試返回開發。軟體系統經過單元、整合、確認、系統、安裝、驗收測試，分別達到單元、整合、確認、系統、安裝、驗收測試停止標準。軟體系統通過驗收測試，並已得出驗收測試結論。軟體項目需暫停以進行調整時，測試應隨之暫停，並備份暫停點資料。軟體項目在其開發生命週期內出現重大估算，進度偏差，需暫停或終止時，測試應隨之暫停或終止，並備份暫停或終止點資料

 

3.3.  測試方法

首先，進行對功能模組進行劃分，明確功能測試的人員負責情況。其次對各個模組進行測試。黑箱測試也稱功能測試或資料驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程式看作一個不能開啟的黑盒子，在完全不考慮程式內部結構和內部特性的情況下，測試者在程式介面進行測試，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入數鋸而產生正確的輸出資訊，並且保持外部資訊（如資料庫或檔案）的完整性。黑箱測試方法主要有等價類別劃分、邊值分析、因—果圖、錯誤推測等，主要用於軟體確認測試。黑箱測試著力於程式外部結構、不考慮內部邏輯結構、針對軟體介面和軟體功能進行測試。“黑盒法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程式中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。

 

 

3.4.  當完成模組測試後進行整個系統的功能測試測試手段

路徑測試(path testing) 。一條路徑包含測試員所執行的所有步驟，或程式為了得到正確狀態所通過的所有語句。路徑測試包括測試通過程式的很多重路徑。通過非平凡程式的所有路徑是不可能的。因此，有些測試員進行子路徑測試(subpath testing),測試很多部分路徑。、

　　語句與分支覆蓋率(statement and branch coverage)。如果測試執行了程式中的所有語句(或程式碼)，則達到100%的語句覆蓋率。如果執行了所有語句和一個語句到另一個語句之間的所有分支，則達到100%的語句和分支覆蓋率。設計自己的測試,達到高的語句與分支覆蓋率,有時叫做“基於覆蓋率的測試(coverage-based testing)” 。(達到覆蓋率目標後,可以停止測試，或停止設計更多的測試) 。把它叫做語句與分支覆蓋率，是為了與關注其他類型覆蓋率的測試相區別。配置覆蓋率就是一個很好例子，這種手段執行同一條語句很多次，但是潛在產生非常不同的結果。

配置覆蓋率(configuration coverage) 。如果必須測試100台列印饑的相容性，並且已經測試了10台,就達到10%的印表機覆蓋率。更一般地，配置覆蓋率度量測試員已經運行(並且程式已經通過)的配置測試占計劃啟動並執行配置測試總數的百分比。

基於規格說明的測試(specification-based testing) 。這種測試關注驗證在規格說明中所做的有關產品的每個事實聲明。(事實聲明是可以用真或假表示的任何語句。)常常包括手冊、市場開發文檔或廣告、技術支援人員寄給客戶的印刷品中的所有聲明。

　　基於需求的測試(requirements-based testing) 。測試關注證明程式滿足需求文檔中的所有需求(或關注逐個需求地證明某個需求沒有被滿足。)

　　組合測試(combination testing) 。相互組合測試兩個或更多變數。本章最後的“測試手段附錄”還要討論這個問題。組合測試很重要，但是很多測試員對這種測試研究得還很不夠。

 

3.5.  測試要點

主要測試系統的功能是否符合客戶要求，各個模組之間的銜接程度是否順暢，並測試軟體是否存在缺陷和漏洞。

3.6.  測試載入器

1. 負載壓力測試工具

這類測試載入器的主要目的是度量應用系統的可擴充性和效能，是一種預測系統行為和效能 的自動化測試載入器。在實施並發負載過程中，通過即時效能監測來確認和尋找問題，並針對所 發現問題對系統效能進行最佳化，確保應用的成功部署。負載壓力測試工具能夠對整個企業架構 進行測試，通過這些測試，企業能最大限度地縮短測試時間，最佳化效能和加速應用系統的發布 周期。

1. 功能測試工具

通過自動錄製、檢測和回放使用者的應用操作，將被測系統的輸出記錄同預先給定的標準結 果比較，功能測試工具能夠有效地協助測試人員對複雜的企業級應用的不同發布版本的功能進 行測試，提高測試人員的工作效率和品質。其主要目的是檢測應用程式是否能夠達到預期的功 能並正常運行。

1. 測試管理工具

一般而言，測試管理工具對測試需求、測試計劃、測試案例、測試實施進行管理，並且測 試管理工具還包括對缺陷的跟蹤管理。測試管理工具能讓測試人員、開發人員或其他的IT人員 通過一個中央資料倉儲，在不同地方就能互動資訊。

4.       測試環境4.1.  硬體環境1> 安卓系統智能機4.2.  軟體環境

安卓4，0以上系統

4.3.  安全性環境要求

作業系統的安全性，測試載入器的安全性，測試軟體的安全性。

5.       專案工作

以下是測試學生資訊管理系統時與測試有關的任務：

5.1.  測試規劃

1. 回應時間

   我把“回應時間”的概念確定為“對請求作出響應所需要的時間”，把回應時間作`為使用者視角的軟體效能的主要體現。回應時間劃分為“呈現時間”和“系統回應時間”兩個部分。

2. 並發使用者數

   我把“並發使用者數”與“同時線上數”進行區別對待，我的“並發使用者數”的標準是：並發使用者數取決於測試對象的目標業務情境，因此，在確定這個“並發使用者數”前，必須（必要）先對使用者的業務進行分解、分析出典型的業務情境（也就是使用者最常使用、最關注的業務操作），然後基於情境採用某些方法（有多種計算並發使用者數的數學模型與公式）獲得“並發使用者數”。

  這樣做的原因是：假設一個應用系統、最高峰有500人同時線上、但這500人卻不是並發使用者數、因為假設在一個時間點上、有50%的人在填寫複雜的表格（填寫表格動作對伺服器沒有任何負擔、只有在“提交”動作的時候才會對伺服器系統構成壓力）、有40%的人在不停的從一個頁面跳轉到另外一個頁面（不停發出請求與回應、產生伺服器壓力）、還有10%的人掛線上上，沒有任何操作在發獃：）（沒有對伺服器構成壓力的動作）。因此只有那40%的人真正對伺服器產生了壓力，從這裡例子可以看出、並發使用者數關心的是不但是業務並發使用者數、還取決於商務邏輯、業務情境。因此我們需要本文第六部分效能測試文檔4、5、6。

3.  輸送量

    我把輸送量定義為“單位時間內系統處理的客戶請求的數量”，直接體現軟體系統的效能承載能力，對於互動式應用系統來說、輸送量反映的是伺服器承受的壓力、在容量規劃的測試中、輸送量是一個重要指標、它不但反映在中介軟體、資料庫上、更加體現在硬體上。我們在以下方面利用這個指標：

（1）用來協助設計效能測試情境，衡量效能測試是否達到了預計的設計目標、比如J2EE應用系統的串連池、資料庫事務發生頻率、事務發生次數。

（2） 用來協助分析效能瓶頸、參照本文第二部分總的RBI方法。

4.  效能計數器

   效能計數器式描述伺服器或作業系統效能的一些資料指標、例如對WINDOWS來說使用記憶體數、CPU使用率、進程時間等都是常見的計數器。

對於效能計數器這個指標來說、需要考慮到的不但有硬體計數器、web伺服器計數器、Weblogic伺服器計數器、Servlet效能計數器、EJB2的效能計數器、JSF效能計數器、JMS效能計數器。找到這些指標是使用效能計數器的第一步、關鍵是找到效能瓶頸、確定系統閥值、提供最佳化建議才是效能計數器使用的關鍵。效能計數器複雜而繁多、與代碼上下文環境、系統配置情況、系統架構、開發方式、使用到的規範實現、工具、類庫版本都有緊密的聯絡、在此不作贅述。

5.  考慮時間

   我把考慮時間確定為“休眠時間”。從業務系統的角度來說，這個時間指的是使用者在驚醒操作時、每個請求之間的時間間隔、從自動化測試的角度來說、要真實的測試類比使用者操作、就必須在測試指令碼中讓各個操作之間等待一段時間、體現在指令碼上就是在操作之間放置一個Think的函數，體現為指令碼中兩個請求語句之間的間隔時間、不同的測試載入器提供了不同的函數或方法來實現考慮時間、比如HP LoadRuner和IBM Rational Performance Tester的方式就完全不同。

 

5.2.  測試設計

使用者層：

主要是面向產品最終的使用操作者的測試。這裡重點突出的是在操作者角度上，測試系統對使用者支援的情況，使用者介面的規範性、友好性、可操作性，以及資料的安全性。主要包括：使用者手冊、使用協助、支援客戶的其他產品技術手冊是否正確、是否易於理解、是否人性化。

　使用者介面測試

　　在確保使用者介面能夠通過測試對象控制項或入口得到相應訪問的情況下，測試使用者介面的風格是否滿足使用者要求，例如：介面是否美觀、介面是否直觀、操作是否友好、是否人性化、易操作性是否較好。

　　可維護性測試

　　可維護性是系統軟、硬體實施和維護功能的方便性。目的是降低維護功能對系統正常運行帶來的影響。例如：對支援遠程維護系統的功能或工具的測試。

　　安全性測試

　　這裡的安全性主要包括了兩部分：資料的安全性和操作的安全性。核實只有規格規定的資料才可以訪問系統，其他不符合規格的資料不能夠訪問系統;核實只有規格規定的操作許可權才可以訪問系統，其他不符合規格的操作許可權不能夠訪問系統;

　應用程式層：

　　針對產品工程應用或行業應用的測試。重點站在系統應用的角度，類比實際應用環境，對系統的相容性、可靠性、效能等進行的測試。

　系統效能測試

　　針對整個系統的測試，包含並發效能測試、負載測試、壓力測試、強度測試、破壞性測試。並發效能測試是評估系統交易或業務在漸增式並發情況下處理瓶頸以及能夠接收業務的效能過程；強度測試是在資源情況低的情況下，找出因資源不足或資源爭用而導致的錯誤；破壞性測試重點關注超出系統正常負荷N倍情況下，錯誤出現狀態和出現比率以及錯誤的恢複能力。

　系統可靠性、穩定性測試

　一定負荷的長期使用環境下，系統可靠性、穩定性。

　系統相容性測試

　系統中軟體與各種硬體裝置相容性，與作業系統相容性、與支撐軟體的相容性。

　系統組網測試

　組網環境下，系統軟體對接入裝置的支援情況。包括功能實現及群集效能。

　系統安裝升級測試

　安裝測試的目的是確保該軟體在正常和異常的不同情況下進行安裝時都能按預期目標來處理。例如，正常情況下，第一次安裝或升級、完整的或自訂的安裝都能進行安裝。異常情況包括磁碟空間不足、缺少目錄建立許可權等。還有一個目的是核實軟體在安裝後可立即正常運行。另外對安裝手冊、安裝指令碼等也需要關注。

5.3.  測試執行準備

容錯移轉和恢複測試可確保測試對象能成功完成轉移，並能從導致意外資料損失或資料完整性破環的各種硬體、軟體、網路故障中恢複資料。容錯移轉測試可確保：對於必須持續啟動並執行系統，一旦發生故障，備用系統就將不失時機地“頂替”發生故障的系統，以避免丟失任何資料或事務。恢複測試是一種對抗性的測試過程。在這種測試中，將把應用程式或系統至於極端的條件下（或者是類比的極端條件下），以產生故障（例如裝置輸入/輸出（I/O）故障或無效的資料庫指標和關鍵字）。然後調用恢複進程並檢測和檢查應用程式和系統，核實應用程式或系統和資料已得到了正確的恢複。

5.4.  測試執行

1．前提條件確保測試專案的功能正常。此類測試基於黑盒技術，該技術通過圖形化使用者介面（GUI）與應用程式進行互動，並對互動的輸出或結果進行分析，以此來核實應用程式及其內部進程,這是目前的測試重點。

執行用例及未經處理資料記錄

2．  提交測試問題單和測試報告

3．  迴歸及驗收測試

4．  輸出工件

利用有效和無效的資料來執行各個用例流，以核實以下內容：

a)   在使用有效資料時得到預期的結果

b)   在使用無效資料時顯示相應的錯誤訊息或警告訊息。

 

 

6.       實施計劃6.1.  工作量估計

根據工作內容和專案工作對包括測試設計的工作量、測試執行和測試總結的工作量，以人月或人日計，     並詳細注釋測試設計、測試執行和測試總結工作所佔的比重。軟體測試工作量應為開發工作量的30%-40%為宜。

 

 

工作階段	所需工作日	占項目的比例
測試規劃階段	1	15%
測試設計階段	1	15%
測試實施階段	1	20%
測試執行階段	1	20%
測試總結階段	1	15%

6.2.  人員需求及安排

下表列出了在此測試活動的人員安排：

角色	人員	具體職責/備忘
測試經理	劉鈞韜	負責軟體測試的總體安排監督工作
測試設計	馬思勉	負責設計測試方案以及測試案例
測試人員	李聰卓	負責對對項目按照測試方案進行具體測試
記錄人員	張子超	負責系統測試過程中記錄測試資訊

6.3.  進度安排

下表列出了測試的時間安排：

項目裡程碑	開始時間	結束時間	輸出要求/備忘
測試規劃	09:00	10：00
測試設計	10:10	11:10
測試設計實施	11:30	13:30
測試執行	14:00	15:30
測試總結	16:00	18:00

 

6.4.  可交付工件

本節列出了將要建立的各種文檔、工具和報告，及其建立人員、交付對象和交付時間。

7.       風險管理

L=Low(風險與處理的優先順序為低) M=Middle(風險與處理的優先順序為中) H=High(風險與處理的優先順序為高)

 

	功能測試階段	安裝測試階段	文檔測試
正確性	H	H	H
檔案完整性	H	H	H
處理的連續性	M	M	M
存取控制	M	M	M
符合性	H	H	H
可靠性	H	H	H
易操作性	H	H	H
可維護性	H	H	H
可移植性	H	H	H

2.問題嚴重度描述

問題嚴重度	描述
致命缺陷	1． 由於程式所引起的死機,非法退出 2． 死迴圈 3． 資料庫發生死結 4． 因錯誤操作導致的程式中斷 5． 主要功能丟失或功能嚴重錯誤 6． 與資料庫連接錯誤 7． 資料通訊錯誤
嚴重缺陷	1． 程式錯誤 2． 程式介面錯誤 3． 資料庫的表、商務規則、預設值未加完整性等約束條件
一般性缺陷	1． 操作介面錯誤（包括資料視窗內列名定義、含義是否一致）  2． 簡單的輸出限制未放在前台進行控制 3． 資料庫表中有過多的空欄位

軟體測試計劃書