圖書管理系統(tǒng)系統(tǒng)測試

1、 【圖書管理系統(tǒng)】 測試計劃說明書 題目： 圖書管理系統(tǒng) 學院： 電子與信息工程學院 班級： 10軟件本（1）班 姓名： 嚴俊琦 陶珍珍 李霞 李玲芬 學號：xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 指導老師： 彭 蕾 目錄1引言.2 1.1編寫目的. .2 1.2 項目背景.2 1.3 參考資料.22任務概述.32.1目標.3 2.2運行環(huán)境.32.3需求概述.32.4 條件與限制.33 測試結果及缺陷分析4 登錄界面：5 情況一、6 情況二、7 情況三、7 情況四：73.1 測試執(zhí)行情況與記錄83.1.1 測試組織83.1.2 測試時間83.1.3 測試版本

2、93.2 覆蓋分析93.2.1 需求覆蓋93.2.2 測試覆蓋93.3 缺陷的統(tǒng)計與分析93.3.1 缺陷匯總93.3.2 缺陷分析103.3.3 殘留缺陷與未解決問題104 測試結論和建議.105評價準則.115.1范圍115.2數(shù)據整理11 5.3 尺度.111 引言1.1 編寫目的 為對項目進行測試，且保證測試質量與進度，以便詳細的記錄測試過程，我們編寫了此測試計劃。1.2 項目背景我校希望能夠充分利用現(xiàn)代科技來提高圖書管理的效率，在原有的辦公系統(tǒng)基礎上進行擴展，將一些可以用計算機來管理的都進行計算機化，使得圖書館管理人員工作更加方便，快捷。說明：<1> 開發(fā)軟件名稱：圖書管

3、理系統(tǒng)。<2> 項目開發(fā)者：電子與信息學院計算機科學系“圖書管理系統(tǒng)” 開發(fā)小組：10 軟件（一)班 1.3 參考資料【1】張海藩軟件工程導論，第五版 清華大學出版社；【2】王珊等，數(shù)據庫原理及設計，清華大學出版社；【3】趙池龍等，軟件工程實踐教程，電子工業(yè)出版社；2 任務概述2.1 目標本文檔的目標是詳細描述對圖書館管理系統(tǒng)進行系統(tǒng)測試的測試過程。本文檔所測試的功能均來自于需求文檔：圖書館管理系統(tǒng)需求規(guī)格說明書。2.2 運行環(huán)境軟件環(huán)境： 操作系統(tǒng)：必須Windows 系列操作系統(tǒng)； 瀏覽器：IE瀏覽器。 硬件環(huán)境： CPU在1GHz以上； 至少256MB內存；2.3需求概述本次

4、測試主要針對本小組開發(fā)的圖書館管理系統(tǒng)進行系統(tǒng)測試，主要包括功能測試、界面測試、文檔測試。在圖書館管理系統(tǒng)需求規(guī)格說明書中列出的系統(tǒng)功能和性能都需要完成測試，在測試工作期間發(fā)現(xiàn)的所有缺陷都需要改正并確認。2.4條件與限制 由于開發(fā)時間和計算機數(shù)量有限，該系統(tǒng)并未提供這一功能，對信息的保護僅限于設置用戶級別，以及提供數(shù)據文件的備份，比較簡單，不能防止惡意的破壞，安全性能有待進一步完善3 測試結果及缺陷分析用例一、用戶名密碼嚴俊琦123456李玲芬123456李霞123456陶珍珍123456登錄界面：情況一、情況二、情況三、情況四：3.1測試執(zhí)行情況與記錄 描述測試資源消耗情況，記錄實際數(shù)據。測

5、試組織 可列出簡單的測試組架構圖，包括：測試組架構 （如存在分組、用戶參與等情況）測試成員 （嚴俊琦）主要測試人員 李霞參與測試人員 嚴俊琦、李玲芬、李霞、陶珍珍測試時間  列出測試的跨度和工作量，最好區(qū)分測試文檔和活動的時間。數(shù)據可供過程度量使用。例如 登錄子系統(tǒng)/子功能實際開始時間實際結束時間總工時/總工作日任務 2012年10月6日10月9日合計 4 天     對于大系統(tǒng)/項目來說最終要統(tǒng)計資源的總投入，必要時要增加成本一欄，以便管理者清楚的知道究竟花費了多少人力去完成測試。測試類型 人員成本 工具設備 其他費用總計 5 人 

6、   在數(shù)據匯總時可以統(tǒng)計個人的平均投入時間和總體時間、整體投入平均時間和總體時間，還可以算出每一個功能點所花費的時/人。用時人員 編寫用例 執(zhí)行測試 總計合計 2 時/人   測試版本 給出測試的版本，如果是最終報告，可能要報告測試次數(shù)回歸測試多少次。列出表格清單則便于知道那個子系統(tǒng)/子模塊的測試頻度，對于多次回歸的子系統(tǒng)/子模塊將引起開發(fā)者關注。3.2 覆蓋分析需求覆蓋     需求覆蓋率是指經過測試的需求/功能和需求規(guī)格說明書中所有需求/功能的比值，通常情況下要達到100的目標。需求/功能

7、（或編號） 測試類型 是否通過 備注YPNN/A 根據測試結果 ，按編號給出每一測試需求的通過與否結論。P表示部分通過，N/A表示不可測試或者用例不適用。實際上，需求跟蹤矩陣列出了一一對應的用例情況以避免遺漏，此表作用為傳達需求的測試信息以供檢查和審核。需求覆蓋率計算 Y項/需求總數(shù) ×100測試覆蓋 需求/功能（或編號） 用例個數(shù) 執(zhí)行總數(shù) 未執(zhí)行 未/漏測分析和原因    實際上，測試用例已經記載了預期結果數(shù)據，測試缺陷上說明了實測結果數(shù)據和與預期結果數(shù)據的偏差；因此沒有必要對每個編號在此包含更詳細的說明的缺陷記錄與偏差，列表的目的僅在于更

8、好的查看測試結果。測試覆蓋率計算 執(zhí)行數(shù)/用例總數(shù) ×1003.3 缺陷的統(tǒng)計與分析     缺陷統(tǒng)計主要涉及到被測系統(tǒng)的質量，因此，這部分成為開發(fā)人員、質量人員重點關注的部分。缺陷匯總  被測系統(tǒng) 系統(tǒng)測試 回歸測試 總計合計 按嚴重程度嚴重 一般 微小按缺陷類型用戶界面 一致性 功能 算法 接口 文檔 用戶界面 其他按功能分布功能一 功能二 功能三 功能四 功能五 功能六 功能七     最好給出缺陷的餅狀圖和柱狀圖以便直觀查看。俗話說一圖勝千言，圖標能夠使閱讀者迅速獲得信息，尤其

9、是各層面管理人員沒有時間去逐項閱讀文章。圖例缺陷分析    本部分對上述缺陷和其他收集數(shù)據進行綜合分析缺陷綜合分析缺陷發(fā)現(xiàn)效率 缺陷總數(shù)/執(zhí)行測試用時可到具體人員得出平均指標用例質量 缺陷總數(shù)/測試用例總數(shù) ×100缺陷密度 缺陷總數(shù)/功能點總數(shù)缺陷密度可以得出系統(tǒng)各功能或各需求的缺陷分布情況，開發(fā)人員可以在此分析基礎上得出那部分功能/需求缺陷最多，從而在今后開發(fā)注意避免并注意在實施時予與關注，測試經驗表明，測試缺陷越多的部分，其隱藏的缺陷也越多。測試曲線圖 描繪被測系統(tǒng)每工作日/周缺陷數(shù)情況，得出缺陷走勢和趨向重要缺陷摘要缺陷編號 簡要描述

10、分析結果 備注殘留缺陷與未解決問題殘留缺陷編號：BUG號缺陷概要：該缺陷描述的事實原因分析：如何引起缺陷，缺陷的后果，描述造成軟件局限性和其他限制性的原因預防和改進措施：彌補手段和長期策略未解決問題功能/測試類型：測試結果：與預期結果的偏差缺陷：具體描述評價：對這些問題的看法，也就是這些問題如果發(fā)出去了會造成什么樣的影響4 測試結論和建議 1. 測試執(zhí)行是否充分（可以增加對安全性、可靠性、可維護性和功能性描述） 2. 對測試風險的控制措施和成效。 3. 測試目標是否完成。 4. 測試是否通過。 5. 是否可以進入下一階段的項目目標。建議：1 對系統(tǒng)存在問題的說明，描述測試軟件所揭露的缺陷和不足，以及可能給軟件實施和運行帶來的影響。2 可能存在潛在的缺陷和后續(xù)工作。3 對缺陷修改和產品設計的建議。4 對過程改進方面的建議5 評價準則5.1 范圍 此測試計劃說明書中的測試用例