軟體測試計畫

1) 專案背景

本次的被測專案，是乙個基於b/s結構的web部落格系統。該系統可以實現使用者註冊，以及好友的搜尋增添，基本的文章發布，**上傳等功能。使用者可選擇關注的好友還可以設定部落格訪問許可權：

公開、好友可見，僅自己可見。

2) 編寫目的

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

3) 系統模組圖

4) 參考資料

軟體測試技術（本學期的課本）清華大學出版社

1) 總體策略

軟體系統在進行單元、整合、確認、系統、安裝、驗收測試時，發現一級錯誤（大於等於1）、二級錯誤（大於等於2）暫停測試返回開發。軟體系統經過單元、整合、確認、系統、安裝、驗收測試，分別達到單元、整合、確認、系統、安裝、驗收測試停止標準。軟體系統通過驗收測試，並已得出驗收測試結論。

軟體專案需暫停以進行調整時，測試應隨之暫停，並備份暫停點資料。軟體專案在其開發生命週期內出現重大估算，進度偏差，需暫停或終止時，測試應隨之暫停或終止，並備份暫停或終止點資料

2) 測試範圍

1. 響應時間

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

2. 併發使用者數

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

這樣做的原因是：假設乙個應用系統、最高峰有500人同時**、但這500人卻不是併發使用者數、因為假設在乙個時間點上、有50%的人在填寫複雜的**（填寫**動作對伺服器沒有任何負擔、只有在「提交」動作的時候才會對伺服器系統構成壓力）、有40%的人在不停的從乙個頁面跳轉到另外乙個頁面（不停發出請求與回應、產生伺服器壓力）、還有10%的人掛**上，沒有任何操作在發呆：）（沒有對伺服器構成壓力的動作）。

因此只有那40%的人真正對伺服器產生了壓力，從這裡例子可以看出、併發使用者數關心的是不但是業務併發使用者數、還取決於業務邏輯、業務場景。因此我們需要本文第六部分效能測試文件4、5、6。

3. 吞吐量

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

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

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

4. 效能計數器

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

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

5. 思考時間

我把思考時間確定為「休眠時間」。從業務系統的角度來說，這個時間指的是使用者在驚醒操作時、每個請求之間的時間間隔、從自動化測試的角度來說、要真實的測試模擬使用者操作、就必須在測試指令碼中讓各個操作之間等待一段時間、體現在指令碼上就是在操作之間放置乙個think的函式，體現為指令碼中兩個請求語句之間的間隔時間、不同的測試工具提供了不同的函式或方法來實現思考時間、比如hp loadruner和ibm rational performance tester的方式就完全不同。

3) 風險分析

存在風險：由於測試組成員之前都沒有過軟體測試的經驗，只有一些基礎的理論知識。所以測試準備做得不是很充分。

可能會有部分測試用時過長，或者某個人的測試工作不能按時完成。會造成對整體時間以及測試進度的影響。

風險處理：必要的簡化測試內容，盡量簡化的達到測試目的。完成任務的人員給予尚未解決問題的組員以幫助，盡量短時間完成各自的任務。

1) 里程碑技術

因為測試專案是web程式，所以我們更加注重程式的整合測試，以及對系統進行抗壓測試。

制定負載測試計畫

1 分析應用程式

2 確定測試目標

3 計畫怎樣執行quicktest professional

2) 測試用例設計

主要是進行使用者試用來進行用例設計。

3) 測試實施過程

使用者層：

主要是面向產品最終的使用操作者的測試。這裡重點突出的是在操作者角度上，測試系統對使用者支援的情況，使用者介面的規範性、友好性、可操作性，以及資料的安全性。主要包括：

使用者手冊、使用幫助、支援客戶的其他產品技術手冊是否正確、是否易於理解、是否人性化。

使用者介面測試:

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

可維護性測試:

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

安全性測試:

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

應用層：

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

系統效能測試：

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

系統可靠性、穩定性測試：

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

系統相容性測試：

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

系統組網測試：

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

系統安裝公升級測試：

安裝測試的目的是確保該軟體在正常和異常的不同情況下進行安裝時都能按預期目標來處理。例如，正常情況下，第一次安裝或公升級、完整的或自定義的安裝都能進行安裝。異常情況包括磁碟空間不足、缺少目錄建立許可權等。

還有乙個目的是核實軟體在安裝後可立即正常執行。另外對安裝手冊、安裝指令碼等也需要關注。

1) 測試團隊結構

測試組織：楊國梁

測試人員：閆堅，何鵬飛

報告攥寫：李永俊

2) 功能劃分

工作量（單位：人時）

1) 培訓需求

本次測試運用黑盒測試方法，對拼車系統進行測試。首先，進行對功能模組進行劃分，明確功能測試的人員負責情況。其次對各個模組進行測試。

黑盒測試也稱功能測試或資料驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程式看作乙個不能開啟的黑盒子，在完全不考慮程式內部結構和內部特性的情況下，測試者在程式介面進行測試，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入數鋸而產生正確的輸出資訊，並且保持外部資訊（如資料庫或檔案）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因—果圖、錯誤推測等，主要用於軟體確認測試。黑盒測試著力於程式外部結構、不考慮內部邏輯結構、針對軟體介面和軟體功能進行測試。

「黑盒法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程式中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。

2) 硬體需求

本次測試用的電腦，都是win7系統，記憶體2g，硬碟320g不等。

3) 軟體需求

測試工作所必須的軟體，以及老師拷貝給的軟體。

4) 辦公室空間需求

本次的測試實驗，我們用到四台電腦，在宿舍進行。

5) 相關資訊儲存位置

本次試驗隨時生成測試文件，以word文件的形式儲存。

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

2.本次測試實驗的總時間為五天。我們具體的時間安排以及進度分配如下：

以下是一些與測試有關的任務：

制定測試計畫

確定測試需求

評估風險

制定測試策略

確定測試資源

建立時間表

生成測試計畫

設計測試

準備工作量分析文件

確定並說明測試用例

確定測試過程，並建立測試過程的結構

複審和評估測試覆蓋

實施測試

記錄或通過程式設計建立測試指令碼

確定設計與實施模型中的測試專用功能

建立外部資料集

執行測試

執行測試過程

評估測試的執**況

恢復暫停的測試

核實結果

調查意外結果

記錄缺陷

對測試進行評估

評估測試用例覆蓋

評估**覆蓋

分析缺陷

確定是否達到了測試完成標準與成功標準

軟體測試計畫

軟體測試計畫

軟體測試計畫

軟體測試計畫

相關推薦