軟體測試計劃文件
1.引言
1.1 編寫目的
滿足大學生選課需求，解決選課難的問題
1.2 專案背景
如今，網上選課已成為大學生必經之路，但是普通的官方系統難以滿足大學生需求，我們擬在大學內推廣該軟體以解決大學選課難的問題
1.3 術語定義
Ad hoc testing（隨機測試），沒有書面測試用例、記錄期望結果、檢查列表、指令碼或指令的測試。主要是根據測試者的經驗對軟體進行功能和效能抽查。隨機測試是根據測試說明書執行用例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。
Alpha testing （α測試），是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際操作環境下進行的受控測試，Alpha測試不能由程式設計師或測試員完成。
Automated Testing（自動化測試），使用自動化測試工具來進行測試，這類測試一般不需要人干預，通常在GUI、效能等測試中用得較多。
Beta testing（β測試），測試是軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試。開發者通常不在測試現場，Beta測試不能由程式設計師或測試員完成。
Black box testing（黑盒測試），指測試人員不關心程式具體如何實現的一種測試方法。根據軟體的規格對軟體進行各種輸入和觀察軟體的各種輸出結果來發現軟體的缺陷的測試，這類測試不考慮軟體內部的運作原理，因此軟體對使用者來說就像一個黑盒子。
Bug (錯誤)，有時稱作defect（缺陷）或error（錯誤），軟體程式中存在的程式設計錯誤，可能會帶來不必要的副作用，軟體的功能和特性與設計規格說明書或使用者需求不一致的方面。軟體缺陷表現特徵為：軟體未達到產品說明書標明的功能；軟體出現產品說明書指明不會出現的錯誤；軟體功能超出產品說明書指明的範圍；雖然產品說明書未指出但是軟體應達到的目標；軟體測試人員或使用者認為軟體難以理解，不易使用，執行速度緩慢等問題。
Bug report（錯誤報告），也稱為“Bug record（錯誤記錄）”，記錄發現的軟體錯誤資訊的文件，通常包括錯誤描述、復現步驟、抓取的錯誤影像和註釋等。
Build（工作版本），軟體開發過程中用於內部測試的功能和效能等不完善的軟體版本。工作版本既可以是系統的可操作版本，也可以是展示要在最終產品中提供的部分功能的部分系統。
Compatibility Testing（相容性測試），也稱“Configuration testing（配置測試）”，測試軟體是否和系統的其它與之互動的元素之間相容，如：瀏覽器、作業系統、硬體等。驗證測試物件在不同的軟體和硬體配置中的執行情況。
Crash（崩潰），計算機系統或元件突然並完全的喪失功能，例如軟體或系統突然退出或沒有任何反應（當機）。
Debug（除錯），開發人員確定引起錯誤的根本原因和確定可能的修復措施的過程。一般發生在子系統或單元模組編碼完成時，或者根據測試錯誤報告指出錯誤以後，開發人員需要執行除錯過程來解決已存在的錯誤。
Performance testing（效能測試），評價一個產品或元件與效能需求是否符合的測試。包括負載測試、強度測試、資料庫容量測試、基準測試等型別。
Regression testing（迴歸測試），在發生修改之後重新測試先前的測試以保證修改的正確性。理論上，對軟體的任何新版本，都需要進行迴歸測試，驗證以前發現和修復的錯誤是否在新軟體版本上再現。
Software life cycle（軟體生命週期），開始於一個軟體產品的構思，結束於該產品不再被使用的這段期間。
Static testing（靜態測試），不透過執行來測試一個系統。如程式碼檢查，文件檢查和評審等。
User interface testing （使用者介面測試），指測試使用者介面的風格是否滿足客戶要求，文字是否正確，頁面是否美觀，文字，圖片組合是否完美，操作是否友好等等。UI 測試的目標是確保使用者介面會透過測試物件的功能來為使用者提供相應的訪問或瀏覽功能。確保使用者介面符合公司或行業的標準。包括使用者友好性、人性化、易操作性測試。
1.4 參考資料
<<軟體工程方法與實踐>>
<<軟體工程實驗教程>>
<<資料庫系統概論>>
<<Qt 快速入門>>
2.任務概述
2.1 目標
主要目標:能夠與官方選課系統對接,幫助大學生選課
覆蓋範圍：大學校內，使用者擬定為在校大學生
驗收標準：可完成選課並實現資料共享即可驗收
2.2 測試環境
硬體環境：PC機
軟體環境：eclipse SDK，SQL server
2.3 需求分析
2.3.1 資料需求
2.3.2 事務需求
2.4 條件與限制
硬體裝置：
CPU Core i3-2100及以上
記憶體 2GB DDR3-160及以上
外存 120/128GB SATA3.0及以上
軟體系統保證：安裝eclipse SDK、JavaServlet
人員齊備：全員到齊
時間限制：一週
3.計劃
3.1 測試方案
主要內容是需求，分析，設計，實現。
3.2測試專案
●功能測試
線上選課：利用滑鼠和鍵盤實現選擇需要的課程
線上退課：利用滑鼠和鍵盤退掉已選課程
●迴歸測試
定義
迴歸測試是指修改了舊程式碼後，重新進行測試以確認修改沒有引入新的錯誤或導致其他程式碼產生錯誤。
意義
1.避免在迴歸測試中應各種操作誤差所引起的測試結果異常。
2.可以保持和原始測試一直性。
3.可以提高測試效率。
4.測試經理可以更好的掌握測試存在的問題
●介面測試
1. 簡介說明 說明文字是否合理，位置 ，是否正確。
2. 背景/色調 是否正確、美觀、，是否符合使用者需求
3. 登入介面是否正常，能否正常登入
4. 能否正常選課和退選
5. 測試登入後能否正常退出
6. 頁面元素的容錯性列表
7. 頁面元素清單（為實現功能、是否將所需要的元素全部都列出來，如按鈕，單選框，核取方塊，列表框，超鏈框，輸入框等等）。
8. 頁面元素的容錯性是否存在。
●負載測試
透過增加併發使用者數和（或）事務數量來測量元件或系統能夠承受的負載。
●文件測試
1. 測試方案（主要設計怎麼測試什麼內容和採用什麼樣的方法，經過分析，在這裡可以得到相應的測試用列表）
2. 測試執行策略（可以主要包括哪些可以先測試，哪些可以放在一起測試之類的），
3. 測試用例(主要根據測試用例列表，寫出每一個用例的操作步驟和緊急程度，和預置結果)，
4. BUG描述報告(主要可以包括，測試環境的介紹，預置條件，測試人員，問題重現的操作步驟和當時測試的現場資訊)，
5. 整個專案的測試報告(從設計和執行的角度上來對此專案測試情況的介紹，從分析中總結此次設計和執行做的好的地方和需要努力的地方和對此專案的一個質量評價)。
3.3 測試準備
3.3.1. 測試計算機，是相對比較“乾淨”的。 因為測試都是有風險的，有的時候會導致藍色畫面，計算機重新啟動，優勢時候則要求更換作業系統。
3.3.2. 功能測試環境 和 效能測試環境 要分開。 效能測試是持續的，有的用例要一次執行十幾天，只有單獨的效能測試環境才能滿足這個要求。
3.3.3 提前準備好軟體和硬體。
3.3.4 測試支援平臺。 測試用例管理程式，bug管理程式，測試報告生成程式。
3.3.5 把搭建測試環境時遇到的問題和相應的解決辦法記錄下來。
3.4 測試機構及人員
測試機構人員組成：羅驍，曾理，曾正旗，施宏飛，聶良疆
測試文件書寫：施宏飛，聶良疆
軟體執行人員：羅驍，曾理
軟體完善人員：曾正旗
4.測試專案說明
4.1 測試專案名稱及測試內容
|
測試專案名稱 |
測試內容 |
|
登入功能 |
使用者能否正常輸入使用者名稱、密碼和正常登入 |
|
選課功能 |
使用者能否正常選課 |
|
退課功能 |
使用者能否對已選課程進行退課 |
|
檢視功能 |
使用者能否檢視已選課程和自己的選課之前和之後課表 |
4.2 測試用例
|
用例編號 |
輸入資料 |
預期的輸出結果 |
|
SL1 |
使用者未輸入使用者名稱或密碼 |
介面提示“請輸入完整資訊！”。 |
|
SL2 |
使用者輸入錯誤使用者名稱 |
介面提示“使用者名稱不存在！”。 |
|
SL3 |
使用者輸入錯誤密碼 |
介面提示“密碼不正確！”。 |
|
SL4 |
使用者在主介面點選選課按鈕 |
使用者進入選課介面，並能看到當前可選課程。 |
|
SL5 |
使用者在選課介面中點選課程 |
介面彈出小視窗，顯示該課程的資訊，包括上課時間、上課地點、上課老師和已選人數。 |
|
SL6 |
使用者在選課介面中點選與上課時間不衝突的課程後選課按鈕 |
介面彈出“成功選課！”，並在課表中加入已選課程 |
|
SL7 |
使用者在選課介面中點選與上課時間衝突的課程後選課按鈕 |
介面彈出“與上課時間衝突！” |
|
SL8 |
使用者點選選課介面的返回按鈕 |
返回主介面。 |
|
SL9 |
使用者在主介面點選退課按鈕 |
使用者進入退課介面，並能看到已選課程，若沒有已選課程，則介面提示“沒有已選課程！” |
|
SL10 |
使用者在退課介面點選退課按鈕 |
介面彈出小視窗：是否退課？ |
|
SL11 |
點選退課介面小視窗中確定按鈕 |
退課介面刪除該課程，在課表中刪除該課程，在選課介面中新增該課程。 |
|
SL12 |
點選退課介面的返回按鈕 |
返回主介面 |
|
SL13 |
在主介面中點選檢視按鈕 |
進入課表介面，顯示當前該使用者課表。 |
|
SL14 |
在課表介面中點選課程 |
介面彈出小視窗，顯示該課程的資訊，包括上課時間、上課地點和上課老師。 |
|
SL15 |
點選主介面登出按鈕 |
使用者退出系統，進入登入介面。 |
4.3 進度
小組成員全體參與每個測試用例。
4.4 條件
硬體條件：正常可執行電腦，鍵盤滑鼠。
軟體條件：Eclipse軟體和SQLserver軟體。
人員條件：全體小組成員。
4.5 測試資料
[1]計算機軟體測試文件編制規範GB/T 9386-2008.
[2]竇萬峰.軟體工程方法與實踐[M].北京：機械工業出版社，2009.
5.評價
5.1 準則
質量準則：錯誤率在1%左右，點選按鈕系統反應時間不超過0.5秒。
覆蓋準則：用例覆蓋度99%。
5.2 結束標準
各個用例預期結果和實際結果一致。
整合測試文件
1.簡介
1.1 目的
本文件用於描述輔助選課系統整合測試所要遵循的規範以及確定測試方法、測試環境、測試用例的編寫和測試整個進度的計劃安排、人力資源安排等。
測試目的：整合測試目的是測試組成輔助選課系統的各個子模組間的介面及功能實現等。
1.2 背景
面對當前大學生選課時遇到選課時間慢、選的課程不滿意等問題，我們團隊準備開發出一個輔助選課系統，以幫助學生更好地選課。
1.3 範圍
需要整合的模組為登入模組、選課模組、退課模組和檢視模組。
1.4 參考文件
[1]計算機軟體測試文件編制規範GB/T 9386-2008.
[2]竇萬峰.軟體工程方法與實踐[M].北京：機械工業出版社，2009.
2.測試約束
2.1 測試進出條件
2.1.1 進入條件
程式能夠成功執行並顯示系統登入介面
2.1.2 退出條件
致命和嚴重級別缺陷清除率達到100%，致命和嚴重級別缺陷修復率達到100%，一般缺陷的遺留個數小於等於2個。
2.2 測試透過和失敗準則
輸入測試用例後的結果與預期結果相近或者相同，測試即為成功，否則測試失敗。
2.3 測試啟動/結束/暫停/再啟動準則
2.3.1 測試啟動準則
程式執行成功，能夠輸入測試用例。
2.3.2 測試結束準則
當對程式的各個功能都進行覆蓋測試併成功修復錯誤以後退出測試。
2.3.3 測試暫停/再啟動準則
當測試過程中出現致命、嚴重以及一般級別缺陷後，測試工作需要暫停，當修復致命、嚴重以及一般級別缺陷後再重新啟動測試工作。
3.測試需求
需求功能點：使用者登入，選課，退課，顯示功能
介面：硬體介面，以及人際互動介面。
4.測試風險
不可抗力因素：應及時儲存程式的程式碼，做好文件的整理工作。
測試環境風險：弄清楚測試環境和生產環境配置，測試環境交叉影響較大，儘量增多測試環境資料量。
迴歸測試風險：迴歸測試一般時間相對來說較少，應該儘量測試多的迴歸功能點，防止漏測；另外還有減少迴歸驗證缺陷時業務流走不通導致的打回修復再驗證造成的時間延後問題。
5.整合策略
採用自下而上的整合順序，先將個模組實現的功能進行測試，在整合後對整體功能進行測試，整合環境為Eclipse開發環境。
6.整合計劃
小組成員前期先將個模組的功能實現比測試，中後期將各個模組之間的關係整理好，在整合環境下將各個功能模組進行整合並測試最終的功能。
7測試策略
7.1 策略描述
先對最底層的各個小功能測試，然後逐層上升，將出現整合，直到實現最終的預期功能
7.2 測試型別
●功能測試：登入功能：預期結果：當出現執行成功後輸入使用者名稱和密碼，登入成功顯示選課系統的選單；使用者名稱不存在顯示“使用者名稱不存在，請重新輸入”，密碼不正確顯示“密碼不正確，請重新輸入“。
測試結果：
選課功能：預期結果：登入成功後點選“選課”按鈕，顯示選課介面，在選擇合適的課程後點選課程後面的選課按鈕，選課成功顯示“選課成功”；選課人數達到上限顯示“人數已到上限，請重新選擇”。
測試結果：
退課功能：預期結果：選課成功後點選“退課”按鈕，顯示退課介面，選擇想要退掉的課程後點選課程後面的退課按鈕，退課成功顯示“退課成功”。
測試結果：
顯示功能：預期結果：登入成功後點選“我的課程”按鈕，顯示該使用者的所以課程。
測試結果：
●介面測試：硬體介面：鍵盤和滑鼠點選是否有效果
軟體介面：
●容錯測試:暫無
●迴歸測試:暫無