教務管理系統(tǒng)測試計劃

1、軟件測試方案說明書§ 1 引言1.1. 編寫目的本方案是教務治理系統(tǒng)的總體測試方案.目的是說明各種測試階段任務、人員分配和時間安排、工作標準等.也是為以后的測試設計、測試開發(fā)、測試執(zhí)行、測試評估有所標準.1.2. 工程背景a.本工程的名稱為教務治理系統(tǒng)；b.本工程是由計算機科學與技術學院08計11班郭瓊、王娟、何婷婷、李姣、金歡歡、褚強、孫超為了進行軟件測試實訓而進行開發(fā)的.1.3. 定義測試用例中的編號功能名+界面名每個字第一個漢語拼音大寫+編號例如：登錄第一個用例DL0001測試用例文件名命名規(guī)那么模塊名+測試用例例如：學生模塊學生測試用例黑盒測試黑盒測試也稱功能測試,它是通過測

2、試來檢測每個功能是否都能正常使用.在測試中,把程序看作一個不能翻開的黑盒子,在完全不考慮程序內部結構和內部特性的情況下,在程序接口進行測試,它只檢查程序功能是否根據(jù)需求規(guī)格說明書的規(guī)定正常使用,程序是否能適當?shù)亟邮蛰斎霐?shù)據(jù)而產生正確的輸出信息.黑盒測試著眼于程序外部結構,不考慮內部邏輯結構,主要針對軟件界面和軟件功能進行測試.白盒測試白盒測試也稱結構測試或邏輯驅動測試,它是根據(jù)程序內部的結構測試程序,通過測試來檢測產品內部動作是否根據(jù)設計規(guī)格說明書的規(guī)定正常進行,檢驗程序中的每條通路是否都能按預定要求正確工作.這一方法是把測試對象看作一個翻開的盒子,測試人員依據(jù)程序內部邏輯結構相關信息,設計或

3、選擇測試用例,對程序所有邏輯路徑進行測試,通過在不同點檢查程序的狀態(tài),確定實際的狀態(tài)是否與預期的狀態(tài)一致.靜態(tài)測試靜態(tài)方法是指不運行被測程序本身,僅通過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性.對需求規(guī)格說明書、軟件設計說明書、源程序做結構分析、流程圖分析、符號執(zhí)行來找錯.靜態(tài)方法通過程序靜態(tài)特性的分析,找出欠缺和可疑之處,例如不匹配的參數(shù)、不適當?shù)难h(huán)嵌套和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引用和可疑的計算等.靜態(tài)測試結果可用于進一步的查錯,并為測試用例選取提供指導動態(tài)測試動態(tài)方法是指通過運行被測程序,檢查運行結果與預期結果的差異,并分析運行效率和健壯性等性

4、能,這種方法由三局部組成：構造測試實例、執(zhí)行程序、分析程序的輸出結果.組件功能測試組建功能測試就是對產品的各功能進行驗證,根據(jù)功能測試用例,逐項測試,檢查產品是否到達用戶要求的功能.業(yè)務測試業(yè)務測試,在單元測試的根底上,將所有業(yè)務流程的模塊根據(jù)設計要求如根據(jù)結構圖組裝成為子系統(tǒng)或系統(tǒng),進行測試.壓力、容量、性能測試就是將業(yè)務測試完后的系統(tǒng)進行進一步的業(yè)務流程測試,例如：在線人數(shù)和系統(tǒng)反包括：各個功能點是否以實現(xiàn),業(yè)務流程是否正確.產品規(guī)定的操作和運行穩(wěn)定.例如：進行一些評判學生成績的數(shù)據(jù)庫操作時,數(shù)據(jù)庫會不會正常運行.數(shù)和缺陷率限制在可接收的范圍之內.例如：估計總代碼行數(shù)為6000行缺陷數(shù)為3

5、0個,那么測試缺陷密度=1000X30/6000=5目標是測試缺陷密度小于1.產品可以通過用戶檢測,初步讓客戶滿意.可以到達運行根本不出BUG,可以正常使用.1.4. 運行環(huán)境測試工具：Junit運行工具：Myeclipse,Tomcat數(shù)據(jù)庫：DB2操作系統(tǒng)CPU內存AcerAspire4520Window7旗艦版AMDTurion64X23GBuild7600TL-60HPCompaqWindow7旗艦版AMDAthlonX22G6535sBuild7600DualCoreQL-64ThinkpadR400LinuxUbuntuInter(R)Core(TM)22GDuoLenove旭日L

6、inuxUbuntuInterPentium雙3G1.5. 條件與限制首先,本測試方案說明書是一個方案說明書,受限于產品開發(fā)人員提交產品測試的內容和時間.根據(jù)開發(fā)人員提交模塊的實際情況,本方案會做出相應修改.§ 2 方案2.1. 測試方案測試模型:W型,測試伴隨著整個軟件開發(fā)周期,而且測試的對象不僅僅是程序,需求、功能和設計同樣要測試.測試方法：黑盒測試,白盒測試,靜態(tài)測試,動態(tài)測試.2.2. 測試工程組件功能測試易用性：2.3. 認按鈕要支持回車的快捷方式.2):界面要支持鍵盤自動瀏覽按鈕功能,即按Tab鍵、回車鍵的自動切換功能.3):界面上首先要輸入的和重要信息的控件在Tab順序

7、中應當靠前,位置也應放在窗口上較醒目的位置.4):同一界面上的控件數(shù)目最好不要太多,最好不要超過10個,多于10個時可以考慮使用分頁界面顯示.5):默認按鈕要支持Enter及選擇操作,即按Enter后自動執(zhí)行默認按鈕對應操作.6):可限制項檢測到非法輸入后應該給出說明并能自動獲得焦點.7):Tab鍵的順序與控件排列順序要一致,目前流行總體從上到下,同時行間從左到右的方式.8):界面空間較小時使用下拉框而不用選項框.9):選項數(shù)敕少時使用選項框,相反使用下拉列表框.標準性：1):圖標能直觀的代表要完成的操作.2):滾動條的長度要根據(jù)顯示信息的長度或寬度能及時變換,以利于用戶了解顯示信息的位置和百

8、分比.3):菜單和狀態(tài)條中通常使用5號字體.工具條一般比菜單要寬,但不要寬的太多,否那么看起來很不協(xié)調.業(yè)務測試功能測試完成后進行業(yè)務測試,業(yè)務測試關注的要點是業(yè)務流程,及數(shù)據(jù)流從軟件中的一個模塊流到另一個模塊的過程中的正確性.壓力、容量、性能測試壓力測試說明壓力測試根據(jù)實際情況包含性能測試,重點模擬客戶進行多用戶測試.壓力測試有一條8:2原那么.及百分之八十的業(yè)務量在百分之二十的時間內輸入.例如：正常每天有100條新數(shù)據(jù),測試時在兩小時內輸入80條數(shù)據(jù).壓力測試方法及標準設計試圖對Web效勞進行壓力測試的壓力測試系統(tǒng)時,要讓它們以某種特定的方式運行代碼.這些風格超越了功能驗證,目的是要弄清楚

9、被測試的Web效勞是不是不僅能做我們認為它能做的事,而且在被施加了某些高強度壓力的情況下仍然繼續(xù)正常運行.壓力測試必須對Web效勞應用四個根本條件：1、重復：最明顯的且最容易理解的壓力條件就是測試的重復.測試的重復就是一遍又一遍地執(zhí)行個別操作或功能,比方重復調用一個Web效勞.功能驗證測試可以用來被弄清楚一個操作能否正常執(zhí)行.而壓力測試將確定一個操作能否正常執(zhí)行,并且能否繼續(xù)在每次執(zhí)行時都正常.2、并發(fā)：并發(fā)是同時執(zhí)行多個操作的行為.換句話說,就是在同一時間執(zhí)行多個測試.這個原那么不一定適用于所有的產品比方無狀態(tài)效勞,但是多數(shù)軟件都具有某個并發(fā)行為或多線程行為元素,這一點只能通過執(zhí)行多個代碼例

10、如才能測出來壓力測試需要一次模擬多個客戶機來進行測試.3、量級：壓力系統(tǒng)應該應用于產品的另一個條件考慮到了每個操作中的負載量.重復執(zhí)行一個操作,但是操作自身也要盡量給產品增加負擔.例如,一個Web服務允許客戶機輸入一條消息,可以通過模擬輸入超長消息的客戶機來使這個單獨的操作進行高強度的使用.換句話說就是,您增加了這個操作的量級.這個量級總是特定于應用的,但是可以通過查找產品的可被用戶計量和修改的值來確定它一例如,數(shù)據(jù)的大小、延遲的長度、資金數(shù)量的轉移、輸入速度以及輸入的變化等等.4、隨機變化：任何壓力系統(tǒng)都多多少少具有一些隨機性.如果隨機使用前面的壓力原那么中介紹的無數(shù)變化形式,就能夠在每次測

11、試運行時應用許多不同的代碼路徑.下面是幾個關于怎樣在測試生命周期內改變測試的例如.使用重復時,在重新啟動或重新連接效勞之前,您可以改變重復操作間的時間問隔、重復的次數(shù),或者也可以改變被重復的Web效勞的順序.使用并發(fā),您可以改變一起執(zhí)行的Web效勞、同一時間運行的Web效勞數(shù)目,或者也可以改變關于是運行許多不同的服務還是運行許多同樣的實例的決定.量級或許是最容易更改的一每次重復測試時都可以更改應用程序中出現(xiàn)的變量例如,發(fā)送各種大小的消息或數(shù)字輸入值.如此反復,是很好的測試情況.認可度和可用性測試認可度和可用性測試,是工程進行驗收時的測試.是需求方與開發(fā)工程組共同進行業(yè)務測試和壓力測試等,使得工

12、程能夠成功的被需求方驗收.2.3. 測試機構及人員測試團隊：08計11第一開發(fā)小組測試流程：測試步驟動作負責人相關記錄要求1編譯代碼王娟、何婷婷成功編譯表單確認可測試2審核并測試郭瓊、李姣審核編譯表單李姣審核3接受測試金歡歡無金歡歡簽字編譯表單4開始測試褚強、孫超BUG單編寫B(tài)UG單2.4. 測試方案及人員分工測試階段開始時間完成時間測試人員階段完成標志測試環(huán)境準備2021-06-262021-06-26王娟測試工具安裝完畢文檔測試2021-06-262021-06-26王娟、何婷婷保證文檔有效無誤測試策略2021-06-262021-06-26褚強、孫超完成檢查表,對文檔進行分解執(zhí)行測試20

13、21-06-262021-06-26王娟、何婷婷保證文檔有效無誤系統(tǒng)測試2021-06-262021-06-27所有小組人員所有系統(tǒng)測試完畢并進行缺陷反饋設計測試用例2021-06-262021-06-26褚強、孫超、郭瓊、金歡歡測試用例覆蓋所后功能測試用例review2021-06-262021-06-27郭瓊、金歡歡、李姣確定最終的測試用例執(zhí)行測試2021-06-262021-06-27郭瓊、金歡歡、李姣確定系統(tǒng)的完整認可度測試2021-06-272021-06-27王娟、何婷婷系統(tǒng)能滿足需求文檔編寫2021-06-272021-06-27所有小組人員測試總結報告測試分工模塊名稱測試人員需

14、求跟蹤王娟、何婷婷數(shù)據(jù)庫維護金歡歡、李姣環(huán)境維護郭瓊、褚強平安模塊褚強、孫超討論組模塊王娟、李姣教務處開設課程模塊郭瓊、何婷婷教師成績治理模塊金歡歡、孫超用戶登錄模塊褚強、王娟治理員數(shù)據(jù)治理模塊李姣、金歡歡學生成績查詢模塊何婷婷、孫超治理員人員治理模塊郭瓊§ 3 測試工程說明3.1. 測試工程名稱及測試內容工程名稱：教務治理系統(tǒng)測試內容：功能測試1)：登錄功能用戶是否可以成功登登錄是否可以區(qū)分不同類別的用戶登錄錯誤密碼是否可以登錄2):學生模塊的查看成績模塊學生是否能看到自己的成績學生能否越權看到別人的成績學生是否越權能修改成績3):教師的成績評定教師是否可以評定所教學生成績教師是否

15、可以越權修改成績教師是否可以越權評定非自己學生的成績4):教務處及治理員人員治理教務處及治理員是否可以添加用戶教務處及治理員是否可以刪除用戶教務處及治理員是否可以修改用戶5):教務處及治理員課程治理教務處及治理員是否可以添加課程教務處及治理員是否可以刪除課程教務處及治理員是否可以開設課程教務處及治理員是否可以修改課程6):治理員的數(shù)據(jù)治理功能治理員是否可以成功的導入數(shù)據(jù)治理員是否可以導出數(shù)據(jù)業(yè)務測試1)：成績治理教師評判成績是否能和Xs數(shù)據(jù)庫關聯(lián)學生是否能看到成績2):課程治理教務處添加課程對數(shù)據(jù)庫Kc是否起到關聯(lián)教務處開設課程是否對數(shù)據(jù)庫Js是否起到關聯(lián)教務處刪除或修改課程是否對數(shù)據(jù)庫Ks和Js起到關聯(lián)3:數(shù)據(jù)治理治理員導入的數(shù)據(jù)是否可以和數(shù)據(jù)庫關聯(lián)治理員導出的數(shù)據(jù)是否是數(shù)據(jù)庫的良好的數(shù)據(jù)3.2. 測試用例3.2.1. 輸入注：這里以學生登錄為例賬號："學生"密碼：正確的密碼3.2.2. 輸出登錄該學生主頁3.2.3. 步驟及操作1、 翻開教務治理系統(tǒng)的首頁2、 選擇學生身