1、第 10 頁軟件測試計劃說明書§1. 引言1.1. 編寫目的本計劃是教務管理系統的總體測試計劃。目的是說明各種測試階段任務、人員分配和時間安排、工作規范等。也是為以后的測試設計、測試開發、測試執行、測試評估有所標準。1.2. 項目背景a本項目的名稱為教務管理系統；b本項目是由計算機科學與技術學院08計11班郭瓊、王娟、何婷婷、李姣、金歡歡、褚強、孫超為了進行軟件測試實訓而進行開發的。1.3. 定義1.3.1.測試用例中的編號功能名+界面名(每個字第一個漢語拼音大寫)+編號 例如：登錄 第一個用例 DL 0001 1.3.2.測試用例文件名命名規則模塊名+測試用例 例如：學生模塊 學生

2、測試用例 1.3.3.黑盒測試 黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試著眼于程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。 1.3.4.白盒測試白盒測試也稱結構測試或邏輯驅動測試，它是按照程序內部的結構測試程序，通過測試來檢測產品內部動作是否按照設計規格說明書的規定正常進行，檢驗程序中的每條通路是否都能按預定要求正確工作。 這一

3、方法是把測試對象看作一個打開的盒子，測試人員依據程序內部邏輯結構相關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試，通過在不同點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致。1.3.5.靜態測試靜態方法是指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性。對需求規格說明書、軟件設計說明書、源程序做結構分析、流程圖分析、符號執行來找錯。靜態方法通過程序靜態特性的分析，找出欠缺和可疑之處，例如不匹配的參數、不適當的循環嵌套和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引用和可疑的計算等。靜態測試結果可用于進一步的查錯，并為測試用例選取提供指導1

4、.3.6.動態測試動態方法是指通過運行被測程序，檢查運行結果與預期結果的差異，并分析運行效率和健壯性等性能，這種方法由三部分組成：構造測試實例、執行程序、分析程序的輸出結果。1.3.7. 組件功能測試 組建功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。1.3.8.業務測試業務測試，在單元測試的基礎上，將所有業務流程的模塊按照設計要求（如根據結構圖組裝成為子系統或系統，進行測試。1.3.9.壓力、容量、性能測試就是將業務測試完后的系統進行進一步的業務流程測試，例如：在線人數和系統反包括：各個功能點是否以實現，業務流程是否正確。 2.1.2.產品規

5、定的操作和運行穩定。例如：進行一些評判學生成績的數據庫操作時，數據庫會不會正常運行。2.1.3.Bug數和缺陷率控制在可接收的范圍之內。例如：估計總代碼行數為6000行 缺陷數為30個，那么測試缺陷密度 = 1000 × 30 / 6000 = 5。目標是測試缺陷密度小于1。2.1.4.產品可以通過用戶檢測，初步讓客戶滿意。 可以到達運行基本不出BUG，可以正常使用。1.4. 運行環境測試工具：Junit運行工具：Myeclipse，Tomcat數 據 庫：DB2機型操作系統CPU內存Acer Aspire4520Window7旗艦版Build7600AMD Turion64 X2

6、TL-603GHP Compaq 6535sWindow7旗艦版Build7600AMD Athlon X2 DualCore QL-642GThinkpad R400LinuxUbuntu 10.10Inter(R) Core(TM)2 Duo2GLenove 旭日 C466MLinuxUbuntu 10.04Inter Pentium 雙核 T23903G1.5. 條件與限制首先，本測試計劃說明書是一個計劃說明書，受限于產品開發人員提交產品測試的內容和時間。根據開發人員提交模塊的實際情況，本計劃會做出相應修改。§2. 計劃2.1. 測試方案 3.1.1測試模型：W型，測試伴隨著整

7、個軟件開發周期，而且測試的對象不僅僅是程序，需求、功能和設計同樣要測試。3.1.2測試方法：黑盒測試，白盒測試，靜態測試，動態測試。2.2. 測試項目3.2.1.組件功能測試 3.2.1.1.易用性： 1):確認按鈕要支持回車的快捷方式。 2）:界面要支持鍵盤自動瀏覽按鈕功能，即按Tab鍵、回車鍵的自動切換功能。 3):界面上首先要輸入的和重要信息的控件在Tab順序中應當靠前,位置也應放在窗口上較醒目的位置。4):同一界面上的控件數目最好不要太多，最好不要超過10個，多于10個時可以考慮使用分頁界面顯示。5):默認按鈕要支持Enter及選擇操作，即按Enter后自動執行默認按鈕對應操作。6):

8、可控制項檢測到非法輸入后應該給出說明并能自動獲得焦點。7):Tab鍵的順序與控件排列順序要一致，目前流行總體從上到下，同時行間從左到右的方式。8):界面空間較小時使用下拉框而不用選項框。9):選項數較少時使用選項框，相反使用下拉列表框。3.2.1.2.規范性： 1):圖標能直觀的代表要完成的操作。 2):滾動條的長度要根據顯示信息的長度或寬度能及時變換，以利于用戶了解顯示信息的位置和百分比。3):菜單和狀態條中通常使用5號字體。工具條一般比菜單要寬，但不要寬的太多，否則看起來很不協調。3.2.2.業務測試功能測試完成后進行業務測試，業務測試關注的要點是業務流程，及數據流從軟件中的一個模塊流到另

9、一個模塊的過程中的正確性。3.2.3.壓力、容量、性能測試3.2.3.1. 壓力測試說明 壓力測試根據實際情況包含性能測試，重點模擬客戶進行多用戶測試。壓力測試有一條8：2原則。及百分之八十的業務量在百分之二十的時間內輸入。例如:正常每天有100條新數據，測試時在兩小時內輸入80條數據。3.2.3.2.壓力測試方法及標準 設計試圖對 Web 服務進行壓力測試的壓力測試系統時，要讓它們以某種特定的方式運行代碼。這些風格超越了功能驗證，目的是要弄清楚被測試的Web服務是不是不僅能做我們認為它能做的事，而且在被施加了某些高強度壓力的情況下仍然繼續正常運行。壓力測試必須對Web服務應用四個基本條件：

10、1、重復： 最明顯的且最容易理解的壓力條件就是測試的重復。測試的重復就是一遍又一遍地執行個別操作或功能，比如重復調用一個 Web 服務。功能驗證測試可以用來被弄清楚一個操作能否正常執行。而壓力測試將確定一個操作能否正常執行，并且能否繼續在每次執行時都正常。 2、并發：并發是同時執行多個操作的行為。換句話說，就是在同一時間執行多個測試。這個原則不一定適用于所有的產品（比如無狀態服務），但是多數軟件都具有某個并發行為或多線程行為元素，這一點只能通過執行多個代碼示例才能測出來壓力測試需要一次模擬多個客戶機來進行測試。3、量級：壓力系統應該應用于產品的另一個條件考慮到了每個操作中的負載量。重復執行一個

11、操作，但是操作自身也要盡量給產品增加負擔。例如，一個 Web 服務允許客戶機輸入一條消息，可以通過模擬輸入超長消息的客戶機來使這個單獨的操作進行高強度的使用。換句話說就是，您增加了這個操作的量級。這個量級 總是特定于應用的，但是可以通過查找產品的可被用戶計量和修改的值來確定它 例如，數據的大小、延遲的長度、資金數量的轉移、輸入速度以及輸入的變化等等。4、隨機變化： 任何壓力系統都多多少少具有一些隨機性。如果隨機使用前面的壓力原則中介紹的無數變化形式，就能夠在每次測試運行時應用許多不同的代碼路徑。下面是幾個關于怎樣在測試生命周期內改變測試的示例。使用重復時，在重新啟動或重新連接服務之前，您可以改

12、變重復操作間的時間間隔、重復的次數，或者也可以改變被重復的 Web 服務的順序。使用并發，您可以改變一起執行的 Web 服務、同一時間運行的 Web 服務數目，或者也可以改變關于是運行許多不同的服務還是運行許多同樣的實例的決定。量級或許是最容易更改的 每次重復測試時都可以更改應用程序中出現的變量（例如，發送各種大小的消息或數字輸入值）。如此反復，是很好的測試情況。3.2.4.認可度和可用性測試 認可度和可用性測試，是項目進行驗收時的測試。是需求方與開發項目組共同進行業務測試和壓力測試等，使得項目能夠成功的被需求方驗收。2.3. 測試機構及人員測試團隊：08計11第一開發小組測試流程：測試步驟動

13、作負責人相關記錄要求1編譯代碼王娟、何婷婷成功編譯表單確認可測試2審核并測試郭瓊、李姣審核編譯表單李姣審核3接受測試金歡歡無金歡歡簽字編譯表單4開始測試褚強、孫超BUG單編寫BUG單2.4. 測試計劃及人員分工測試階段開始時間完成時間測試人員階段完成標志測試環境準備2011-06-262011-06-26王娟測試工具安裝完畢文檔測試2011-06-262011-06-26王娟、何婷婷保證文檔有效無誤測試策略2011-06-262011-06-26褚強、孫超完成檢查表，對文檔進行分解執行測試2011-06-262011-06-26王娟、何婷婷保證文檔有效無誤系統測試2011-06-262011-

14、06-27所有小組人員所有系統測試完畢并進行缺陷反饋設計測試用例2011-06-262011-06-26褚強、孫超、郭瓊、金歡歡測試用例覆蓋所有功能測試用例review2011-06-262011-06-27郭瓊、金歡歡、李姣確定最終的測試用例執行測試2011-06-262011-06-27郭瓊、金歡歡、李姣確定系統的完整認可度測試2011-06-272011-06-27王娟、何婷婷系統能滿足需求文檔編寫2011-06-272011-06-27所有小組人員測試總結報告 3.4.1測試分工模塊名稱測試人員需求跟蹤王娟、何婷婷數據庫維護金歡歡、李姣環境維護郭瓊、褚強安全模塊褚強、孫超討論組模塊王娟

15、、李姣教務處開設課程模塊郭瓊、何婷婷教師成績管理模塊金歡歡、孫超用戶登錄模塊褚強、王娟管理員數據管理模塊李姣、金歡歡學生成績查詢模塊何婷婷、孫超管理員人員管理模塊郭瓊§3. 測試項目說明3.1. 測試項目名稱及測試內容4.1.1.項目名稱：教務管理系統4.1.2.測試內容： 4.1.2.1.功能測試 1）：登錄功能Ø 用戶是否可以成功登登錄Ø 是否可以區分不同類別的用戶登錄Ø 錯誤密碼是否可以登錄 2）：學生模塊的查看成績模塊Ø 學生是否能看到自己的成績Ø 學生能否越權看到別人的成績Ø 學生是否越權能修改成績 3）：教師的成

16、績評定Ø 教師是否可以評定所教學生成績Ø 教師是否可以越權修改成績Ø 教師是否可以越權評定非自己學生的成績 4）：教務處及管理員人員管理Ø 教務處及管理員是否可以添加用戶Ø 教務處及管理員是否可以刪除用戶Ø 教務處及管理員是否可以修改用戶5）：教務處及管理員課程管理Ø 教務處及管理員是否可以添加課程Ø 教務處及管理員是否可以刪除課程Ø 教務處及管理員是否可以開設課程Ø 教務處及管理員是否可以修改課程 6）：管理員的數據管理功能Ø 管理員是否可以成功的導入數據Ø 管理員是否可以

17、導出數據4.1.2.2.業務測試 1）：成績管理Ø 教師評判成績是否能和Xs數據庫關聯Ø 學生是否能看到成績 2）：課程管理Ø 教務處添加課程對數據庫Kc是否起到關聯Ø 教務處開設課程是否對數據庫Js是否起到關聯Ø 教務處刪除或修改課程是否對數據庫Ks和Js起到關聯 3）：數據管理Ø 管理員導入的數據是否可以和數據庫關聯Ø 管理員導出的數據是否是數據庫的良好的數據3.2. 測試用例3.2.1. 輸入注：這里以學生登錄為例賬號："學生"密碼：正確的密碼3.2.2. 輸出登錄該學生主頁3.2.3. 步驟及操作1、 打開教務管理系統的首頁2、 選