電腦科學與技術系
實驗報告
專業名稱電腦科學與技術系
課程名稱軟體測試
專案名稱實驗室管理系統軟體測試報告
班級 12計本（3）班
學號 1204013013、1204013019、1204013016、1204013018、1204013017
組長侯康康
同組人員楊陳兵，徐金林，王詩繁，王朔
實驗日期 2023年10月30 日
目錄：1引言
2測試概述
2.1測試目的
2.2測試任務
2.3測試範圍
2.4測試物件
3 資源需求
3.1 人員及要求
3.2 裝置需求
3.2.1 測試裝置
3.2.2 被測產品
4 測試環境需求
4.1 測試環境
4.2 侷限性
5 測試方案
5.1測試方法
5.2測試用例
5.3測試工具
6 測試準備
7 測試專案說明
8 測試的條件與限制
9.進度安排
10、測試風險評估
一、 引言
隨著現代科技的發展，實驗室越來越離不開我們。然而實驗室的管理也愈發重要，本系統主要用於實驗室管理，總體任務是使得實驗室管理愈加規範化，合理化，自動化。基於這一點，本實驗主要用於實驗室資訊、裝置、人員、管理以及使用者管理，分別針對其各自的增刪改查等進行管理。
二、測試概述
2.1測試目的
本次軟體測試是的目的是盡可能多地早一些找出我們課程設計「實驗室管理系統」中存在的缺陷，並確保其得以修復。
2.2測試任務
通過測試可以確定以下測試目標：
（1）測試已實現的系統是否達到設計的要求，包括：各個功能點是否以實現，業務流程是否正確。
（2）系統規定的操作和執行穩定且符合要求。
（3）bug數和缺陷率控制在可接收的範圍之內。
2.3測試範圍
實驗室資訊管理新增模組；
實驗室資訊管理刪除模組；
實驗室資訊管理查詢模組；
實驗室資訊管理修改模組；
實驗室專案管理新增模組；
實驗室專案管理刪除模組；
實驗室專案管理查詢模組；
實驗室專案管理修改模組；
實驗室裝置資訊管理新增模組；
實驗室裝置資訊管理刪除模組；
實驗室裝置資訊管理查詢模組；
實驗室裝置資訊管理修改模組；
實驗室人員管理新增模組；
實驗室人員管理刪除模組；
實驗室人員管理查詢模組；
實驗室人員管理修改模組；
使用者管理新增模組；
使用者管理刪除模組；
使用者管理查詢模組；
使用者管理修改模組；
許可權管理新增模組；
許可權管理刪除模組；
許可權管理查詢模組；
許可權管理修改模組；
基本資訊管理新增模組；
基本資訊管理刪除模組；
基本資訊管理查詢模組；
基本資訊管理修改模組；
2.4測試物件
實驗室管理系統主模組及其他功能模組的實現與其存在的bug情況。
三、資源需求
3.1 人員（及要求） 本次試驗所需人數為五人，需要所繫並掌握測試工具junit、mercuryinteractive（mi）、segue、rational、 loadrunner,***puware和empirix等
3.2 裝置需求
3.2.1 測試裝置測試裝置電源電源，電腦，印表機。
3.2.2 測試輔件網線、usb線，紙張等。
3.2.3 被測產品實驗室作業系統。
四、測試環境需求
4.1 測試環境
本實驗在windows系統環境下進行的，使用的是myeclipse，tomcat等軟體下進行的。
4.2 侷限性
本實驗是在內部測試的，沒有經過大量的使用者測試，使得測試不夠完善。
4.3 配合人員
本實驗主要有分工合作的形式完成的，每人負責其中的乙個子部分，最終整合。
五、測試方案
5.1測試方法
單元測試：純**的測試（白盒測試）。主要測試**語句的正確性，如所有的**是否都可以跑到，是否有冗餘的**等等。
整合測試：介面測試（灰盒測試，結合白盒和黑盒測試）。主要測試**塊之間的介面。看看資料的傳輸是否有問題。
系統測試：黑盒測試。不接觸**，只對整個系統做功能的測試和效能的測試。
確認測試：是客戶做的測試。也可以叫做驗收測試。客戶對他提出的需求，對應我們所製作的軟體看看是否達到其要求。
5.2測試用例
用例設計：
表1 登陸測試表
表2一般使用者管理測試表
5.3測試工具
軟體測試方面的工具很多，主要有junit、mercuryinteractive（mi）、segue、rational、 loadrunner,***puware和empirix等等
六：測試準備
1.測試計算機，是相對比較「乾淨」的。 因為測試都是有風險的，有時候會導致藍屏，計算機重新啟動，優勢時候則要求更換作業系統。
2.功能測試環境和效能測試環境要分開。 效能測試是持續的，有的用例要一
次執行十幾天，只有單獨的效能測試環境才能滿足這個要求。
3.提前準備好軟體和硬體。
4.測試支援平台。 測試用例管理程式，bug管理程式，測試報告生成程式。
5.把搭建測試環境時遇到的問題和相應的解決辦法記錄下來。
七：測試專案說明
測試專案說明
八、測試的條件與限制
需要測試工具，裝置，要求工具安全，裝置齊全。在測試過程中測試工具，人員操作，裝置等都會影響測試結果。而裝置陳舊，人員不熟練等因素等都有可能影響測試，使結果達不到要求。
九、進度安排
十、測試風險評估
（1）需求的變更：因為軟體測試的依據是客戶的需求。客戶需求一旦變更，訊息有沒有及時聯通的話軟體測試人員對bug的判斷就會有誤差。
（2）人員臨時缺少：在測試計畫中，要嚴格計畫中工作分配，同時對這種風險進行規避。要考慮到一點出現這種情況工作的交接。
運維管理系統軟體測試報告
2007 12 12 目錄1 引言 2 1.1 編寫目的 2 1.2 專案背景 2 1.3 定義 2 1.4 參考資料 2 2 軟體概述 2 2.1 目標錯誤！未定義書籤。2.2 功能錯誤！未定義書籤。2.3 效能錯誤！未定義書籤。2.3.1 資料精確度錯誤！未定義書籤。2.3.2 時間特性錯誤！未...
企業費用管理系統軟體測試報告詳細
企業費用管理系統 測試報告 指導老師 董老師李剛徐傳運 班級 106213801 團隊成員 蔣森維陳豪陳青雲陶霞黃為 變更報告 目錄1 引言 2 1.1 系統概述 2 2 文件目的 2 2.1 測試開始和結束日期 32.2 參加測試的人員 3 2.3 被測試物件的介紹 3 2.3.1 登入頁面測試 ...
管理系統軟體測試計畫
小型超市管理系統 測試計畫 1 測試環境 作業系統windows 8 visual c visual basic 2 系統風險 優先順序 1 測試該系統面臨的風險 2 系統的程式 是否存在問題或漏洞 3 執行在該系統的資料庫是否能正常使用 4 測試該系統實現的優先順序 5 首先,對系統的 進行精細測...