密級 中級 (供內(nèi)部測試完畢后使用)

Servlet圖書管理系統(tǒng)

測試報告

報告編號:?ServletBMS-TR-1

（Servlet Book Management System-Testing Report）

部門經(jīng)理______項目經(jīng)理______

開發(fā)經(jīng)理______測試經(jīng)理______

研發(fā)公司:?第六科技有限公司 ???用戶單位:?廣東用戶高教社

版本	作者	時間	變更摘要
1	李測試	2022年6月3日星期五	新建?

目錄

一 引言

1.1編寫目的

1.2項目背景

1.3系統(tǒng)簡介

1.4術語和縮寫詞

1.5參考資料

二 測試概要

2.1測試用例設計

2.2測試環(huán)境與配置

2.3測試方法(和工具)

三 測試結(jié)果及缺陷分析

3.1測試執(zhí)行情況與記錄

3.1.1測試組織

3.1.2測試時間與成本

3.1.3測試版本

3.2覆蓋分析

3.2.1需求覆蓋

3.2.2測試覆蓋

3.3缺陷的統(tǒng)計與分析

3.3.1缺陷匯總

3.3.2缺陷分析

3.3.3未解決問題

四 測試結(jié)論與建議

4.1測試結(jié)論

4.2建議

可能角色可參考相應章節(jié):

項目管理者:測試執(zhí)行中成本、資源和時間.

3.1.1測試組織

3.1.2測試時間與成本

高層經(jīng)理:簡單的圖表與其他項目進行同向比較.

3.2覆蓋分析

3.2.1需求覆蓋

3.2.2測試覆蓋

3.3缺陷的統(tǒng)計與分析

3.3.1缺陷匯總

3.3.2缺陷分析

3.3.3未解決問題

開發(fā)人員:缺陷結(jié)果以及分析,產(chǎn)品開發(fā)質(zhì)量的信息.

二 測試概要

2.2測試環(huán)境與配置

2.3測試方法(和工具)

三 測試結(jié)果及缺陷分析

3.2覆蓋分析

3.2.1需求覆蓋

3.2.2測試覆蓋

3.3缺陷的統(tǒng)計與分析

3.3.1缺陷匯總

3.3.2缺陷分析

3.3.3未解決問題

四 測試結(jié)論與建議

4.1測試結(jié)論

4.2建議

一 引言

1.1編寫目的

本測試報告為Servlet圖書管理系統(tǒng)項目的測試報告，目的在于總結(jié)測試階段的測試以及分析測試結(jié)果，描述系統(tǒng)是否符合需求說明書(ServletBMS -RD-2.0)。預期參考人員包括測試人員、開發(fā)人員、項目管理者、其他質(zhì)量管理人員和需要閱讀本報告的高層經(jīng)理。

1.2項目背景

隨著社會經(jīng)濟的迅速發(fā)展和科學技術的全面進步以及計算機事業(yè)的飛速發(fā)展，以計算機科學與通信技術為基礎的信息管理系統(tǒng)IE處于蓬勃發(fā)展的時期。隨著經(jīng)濟文化水平的顯著提高，人們對生活質(zhì)量及工作環(huán)境的要求也越來越高，但伴隨著人的勞動強度的增大，以及社交活動的廣泛開展，如何來提高人民紙質(zhì)書本閱讀量，是一個很現(xiàn)實的問題。無疑，科技的蓬勃發(fā)展使更多人依賴電子書，逐漸失去了對閱讀紙質(zhì)書本重要性的理解。如今書籍的發(fā)展，也繼承了信息化的發(fā)展道路，網(wǎng)絡的興起，給了人們各種各樣不同的選擇。與此同時，為了管理好一個書店的正常營運，管理問題也就提上了日程。隨著圖書借閱問題的白熱化，管理難度也越來越大，如何優(yōu)化書店的日常管理也就成為了一個大眾化的課題。

在計算機飛速發(fā)展的今天，將計算機這一信息處理利器應用于書店的日常管理已是勢必所然，面且這也將為商店管理帶來前所未有的改變，它可以帶來意想不到的效益，同時也會為書店的飛速發(fā)展提供無限潛力。采用計算機管理信息系統(tǒng)已書店管理科學化和現(xiàn)代化的重要標志。要想在激烈的市場競爭中立于不敗之地，沒有現(xiàn)代化的管理是萬萬不行的。

通過對書店管理日常工作的詳細調(diào)查,搜集了大量的資料,從系統(tǒng)結(jié)構(gòu)的組織，功能的實現(xiàn)，技術的要求以及可行性等多方面進行考慮，我認為本課題是一個適應現(xiàn)今書店信息管理需求的計算機信息管理系統(tǒng)，具有一定的實際開發(fā)價值和使用價值。

1.3系統(tǒng)簡介

本設計以圖書管理業(yè)務為對象,系統(tǒng)實現(xiàn)用的前臺開發(fā)工具是eclipse，后臺數(shù)據(jù)庫為MySQL。設計過程中的重點和難點是對整個系統(tǒng)的需求分析和數(shù)據(jù)庫詳細設計。

該系統(tǒng)對數(shù)據(jù)進行保存、修改、刪除等管理。為用戶提供了一個友好、簡單快捷的運行操作平臺。該系統(tǒng)對數(shù)據(jù)進行保存、修改、刪除等管理，為用戶提供了一個友好、簡單快捷的運行操作平臺。本系統(tǒng)的各界面設計友好、流程正確、功能也較為完善，旨在為用戶提供方便快捷的服務，使人們走近書籍，走進書籍，熱愛讀書。

本次設計意在為圖書管理行業(yè)提供一個簡便、易操作、可靠的借還管理系統(tǒng)，實現(xiàn)圖書借閱、書店人員的更新及管理。

1.4術語和縮寫詞?

數(shù)據(jù)庫:通常指代 MySQL數(shù)據(jù)庫;

系統(tǒng):?通常指代Servlet圖書管理系統(tǒng),即ServletBMS（Servlet Book Management System）.

1.5參考資料

莞理第七測試科技有限公司《公司規(guī)范》,《測試手冊》

圖書管理系統(tǒng)需求說明書

圖書管理系統(tǒng)-完整設計報告書

軟件安裝使用說明文檔

2.0版 ?Servlet圖書管理系統(tǒng)測試計劃

2.0版 ?Servlet圖書管理系統(tǒng)測試用例表

Servlet圖書管理系統(tǒng)測試用例執(zhí)行表

二 測試概要

圖書管理系統(tǒng)需求說明書規(guī)定的系統(tǒng)功能進行功能測試。（其他測試經(jīng)理和質(zhì)量人員關注部分）

2.1測試用例設計

本小節(jié)簡要介紹測試用例的設計方法。

1.等價類劃分：

目標：用最少的測試數(shù)據(jù)，比較高的效率，以達到最好的測試質(zhì)量

只要有輸入框輸入數(shù)據(jù)的地方，就可以用等價類劃分這一方法來測試，從大量數(shù)據(jù)中挑選少量代表數(shù)據(jù)進行測試

等價類劃分為有效等價類和無效等價類

有效等價類：有意義的、合理的輸入數(shù)據(jù)集合，程序可以接收到有效等價類的數(shù)據(jù)并正常執(zhí)行
無效等價類：無意義的、不合理的輸入數(shù)據(jù)集合，程序接收到無效等價類的數(shù)據(jù)，彈出錯誤提示或者不允許用戶輸入的數(shù)據(jù)

2.邊界值

只要有輸入框輸入數(shù)據(jù)的地方，就可以用邊界值這一方法來測試，一般與等價類劃分共同使用，找到有效數(shù)值和無效數(shù)值之間的分界點及其兩邊的點進行測試

根據(jù)需求，取出邊界值

小于最低有效值的整數(shù)

等于最低有效值的整數(shù)

大于最低有效值的整數(shù)

等于最高有效值的整數(shù)

大于最高有效值的整數(shù)

注意：
（1）對于不同控件的有效等價類和有效的邊界值，可以盡可能的在一條用例中進行測試
（2）在使用邊界值測試方法取值時，并非只是取有效邊界值的數(shù)值，而是應包含有效邊界值和無效邊界值

2.2測試環(huán)境與配置

數(shù)據(jù)庫服務器配置

硬盤：可用空間大小大于200GB

操作系統(tǒng)：Windows?10

應用軟件：Python 3.8.8，Anaconda Navigator (Anaconda3)，Python庫selenium 3.141.0；Google Chrome ??版本 99.0.4844.84（正式版本） （64 位），Chrome驅(qū)動 99.0.4844.51/，2022-05-29T08:00:00Z

產(chǎn)品安裝測試所選擇的客戶端/服務器組合：

客戶端操作系統(tǒng)—Windows 95；服務器端操作系統(tǒng)—Sum Solaris 2.6；

客戶端操作系統(tǒng)—Windows 2010；服務器端操作系統(tǒng)—Linux 6.5

2.3測試方法(和工具)

測試中采用的方法主要是黑盒測試。

工具:

Python 3.8.8，Python庫selenium 3.141.0；

Anaconda Navigator (Anaconda3)，

Google Chrome ??版本 99.0.4844.84（正式版本） （64 位），

Chrome驅(qū)動 99.0.4844.51/，2022-05-29T08:00:00Z

三 測試結(jié)果及缺陷分析

3.1測試執(zhí)行情況與記錄

?????描述測試資源消耗情況，記錄實際數(shù)據(jù)。（測試經(jīng)理、項目經(jīng)理關注部分）

3.1.1測試組織

表1 測試人員投入

姓名	職位	職責	可工作時間
	測試團隊負責人	測試協(xié)調(diào)、報告、初步功能測試	100%
	測試員	特征測試、回歸測試、安裝產(chǎn)品和準備測試環(huán)境并服從測試調(diào)配	100%
	測試員	GUI測試、產(chǎn)品安裝測試并服從測試調(diào)配。	100%

3.1.2測試時間與成本??

（測試經(jīng)理、項目經(jīng)理關注部分）

列出測試的跨度工作量和成本，最好區(qū)分測試文檔和活動的時間。數(shù)據(jù)可供過程度量使用。

表6列出了Servlet圖書管理系統(tǒng)的系統(tǒng)測試時間進度計劃。表中列出的冒煙測試時為了盡早看一下軟件的情況，它使我們能發(fā)現(xiàn)主要的阻礙性缺陷，以及存在于測試配置和測試用例中的缺陷。冒煙測試將包含安全測試和特征測試的一個子集。

表6 Servlet圖書管理系統(tǒng)測試的時間進度計劃

任務	開始時間	結(jié)束時間	合計/工作日
配置并調(diào)試兩種測試環(huán)境	4/20	4/25	6
對預備構(gòu)建執(zhí)行冒煙測試	4/25	4/27	3
第一次測試循環(huán)	4/28	5/8	12
第二次測試循環(huán)	5/8	5/18	10
第三次測試循環(huán)	5/18	5/28	10
復查產(chǎn)品是否準備好	5/28	6/10	13
總計			54

我們假定由開發(fā)團隊執(zhí)行的所有單元測試和集成測試都會在第一種測試環(huán)境開始之前完成，在單元測試和集成測試中發(fā)現(xiàn)的所有災難性缺陷都會在系統(tǒng)測試開始之前得到修正。

預計Servlet圖書管理系統(tǒng)的每個測試循環(huán)所需的時間見表4。請注意，每個循環(huán)測試包括針對一個被測構(gòu)建運行一組完整的測試。如果測試Servlet圖書管理系統(tǒng)需要三個測試循環(huán)，則總測試工作將需要表中預估工作量的三倍。

表4預計每個測試循環(huán)所需的工作量

任務	時間/小時
產(chǎn)品安裝測試	35
運行正常功能測試并報告缺陷	30
驗證對缺陷的修正	25
GUI測試	15
報告測試狀態(tài)	15
進行缺陷復查	20
總計	140

測試類型	人員成本	工具設備	其他費用
配置并調(diào)試兩種測試環(huán)境	2*300*6	4*200*10	2*100*10
對預備構(gòu)建執(zhí)行冒煙測試	2*300*3	4*100*3	2*100*3
第一次測試循環(huán)	3*300*12	4*100*12	2*100*12
第二次測試循環(huán)	3*300*10	4*100*10	2*100*10
第三次測試循環(huán)	2*300*10	4*100*10	2*100*10
復查產(chǎn)品是否準備好	3*300*13	4*100*10	2*100*10
總計/RMB	42,900	26,000	11,000

在數(shù)據(jù)匯總時可以統(tǒng)計個人的平均投入時間和總體時間、整體投入平均時間和總體時間，還可以算出每一個功能點所花費的時/人。

?????用時 人員	編寫用例	執(zhí)行測試	總計
	30	200	230
	60	300	360
	40	280	320
合計	130	780	910

這部分用于過程度量的數(shù)據(jù)包括文檔生產(chǎn)率和測試執(zhí)行率。

?????文檔生產(chǎn)率 人員	用例/編寫時間	用例/執(zhí)行時間	平均
	22/30*100%=73.3%	5/200*100%=2.5%	37.9%
	34/60*100%=56.7%	40/300*100%=13.3%	35%
	18/40*100%=45%	29/280*100%=10.4%	27.7%
合計	74/130*100%=56.9%	74/780*100%=9.49%	33.2%

3.1.3測試版本

測試版本:Servlet圖書管理系統(tǒng)第一版本,

即ServletBMS（Servlet Book Management System）

測試次數(shù)回歸測試3次。因為這是產(chǎn)品的第一個版本，所以不需要驗證以前版本中修正過的缺陷是否又重新出現(xiàn)。這個版本關注的是系統(tǒng)測試階段修正的缺陷不會破壞以前能工作的功能。

我們將使用以下方法來對產(chǎn)品的第一個版本進行回歸測試。

發(fā)現(xiàn)缺陷時，它們會被修正。對測試團隊收到的每個軟件構(gòu)件，都會執(zhí)行測試以驗證那些修正過的缺陷沒再重現(xiàn)。換言之，每個缺陷修正都會在聲稱修正了它的版本中進行驗證。

在產(chǎn)品已穩(wěn)定并通過測試用例的證明之后，會進行一次最后的回歸測試，然后再是產(chǎn)品是否準備好的復查。對于這個版本來說，通過回歸測試意味著通過所有的測試用例。

3.2覆蓋分析

3.2.1需求覆蓋

需求覆蓋率是指經(jīng)過測試的需求/功能和需求規(guī)格說明書中所有需求/功能的比值，通常情況下要達到100％的目標。

需求/功能（或編號）	測試類型	是否通過	備注
3.1.1 用戶界面	單元功能測試	P
3.1.2 導航	單元功能測試	Y
3.1.3 用戶認證—讀者	單元功能測試	P
3.1.4 用戶認證—管理員	單元功能測試	P
3.1.5 注冊	單元功能測試	P
3.1.6 圖書管理	單元功能測試	Y
3.1.7 讀者管理	單元功能測試	Y
3.1.8 圖書分類信息	單元功能測試	Y
3.1.9 圖書借閱信息	單元功能測試	P
3.1.10 圖書歸還信息	單元功能測試	Y
3.1.11 管理員管理	單元功能測試	P
3.1.12 熱門推薦	單元功能測試	Y
3.1.13 最佳讀者	單元功能測試	Y
3.1.14 讀者反饋	單元功能測試	Y
3.1.15 圖書查詢	單元功能測試	Y
3.1.16 借閱信息	單元功能測試	Y
3.1.17 借閱歷史	單元功能測試	Y
3.1.18 問題反饋	單元功能測試	P
3.1.19 個人資料	單元功能測試	Y
3.1.20 修改密碼	單元功能測試	Y

根據(jù)測試結(jié)果?，P表示部分通過，N/A表示不可測試或者用例不適用。

需求覆蓋率: Y項13/需求總數(shù)20?×100％=65%

3.2.2測試覆蓋

需求/功能（或編號）	用例個數(shù)	執(zhí)行總數(shù)	未執(zhí)行
3.1.1 用戶界面	3	3	0
3.1.2 導航	2	2	0
3.1.3 用戶認證—讀者	12	12	0
3.1.4 用戶認證—管理員	11	11	0
3.1.5 注冊	4	4	0
3.1.6 圖書管理	3	3	0
3.1.7 讀者管理	13	13	0
3.1.8 圖書分類信息	3	3	0
3.1.9 圖書借閱信息	1	1	0
3.1.10 圖書歸還信息	1	1	0
3.1.11 管理員管理	13	13	0
3.1.12 熱門推薦	1	1	0
3.1.13 最佳讀者	1	1	0
3.1.14 讀者反饋	3	3	0
3.1.15 圖書查詢	3	3	0
3.1.16 借閱信息	2	2	0
3.1.17 借閱歷史	1	1	0
3.1.18 問題反饋	6	6	0
3.1.19 個人資料	1	1	0
3.1.20 修改密碼	2	2	0

測試覆蓋率計算: 執(zhí)行數(shù)74/用例總數(shù)74?×100％=100％

3.3缺陷的統(tǒng)計與分析

????缺陷統(tǒng)計主要涉及到被測系統(tǒng)的質(zhì)量，因此，這部分成為開發(fā)人員、質(zhì)量人員重點關注的部分。

3.3.1缺陷匯總

被測系統(tǒng)	系統(tǒng)測試	回歸測試	總計
1	3	3	7
合計	3	3	6

按缺陷類型

用戶界面	一致性	功能	算法	接口	文檔	其他
5	0	1	0	0	0	0

按功能分布(“1”代表有缺陷)

功能	缺陷
3.1.1 用戶界面	1
3.1.2 導航
3.1.3 用戶認證—讀者	1
3.1.4 用戶認證—管理員	1
3.1.5 注冊	1
3.1.6 圖書管理
3.1.7 讀者管理
3.1.8 圖書分類信息
3.1.9 圖書借閱信息	1
3.1.10 ?圖書歸還信息
3.1.11 管理員管理	1
3.1.12 熱門推薦
3.1.13 最佳讀者
3.1.14 讀者反饋
3.1.15 圖書查詢
3.1.16 借閱信息
3.1.17 借閱歷史
3.1.18 問題反饋	1
3.1.19 個人資料
3.1.20 ?修改密碼

按嚴重程度

嚴重	一般	微小
0	5	0

缺陷的雷達圖和柱狀圖

3.3.2缺陷分析?

?(開發(fā)人員可以在此分析基礎上得出那部分功能/需求缺陷最多)

本部分對上述缺陷和其他收集數(shù)據(jù)進行綜合分析

缺陷綜合分析

缺陷發(fā)現(xiàn)效率 ＝ 缺陷總數(shù)7/執(zhí)行測試用時780 =0.897%

用例質(zhì)量 ＝ 缺陷總數(shù)7/測試用例總數(shù)74?×100％＝9.46%

缺陷密度 ＝ 缺陷總數(shù)7/功能點總數(shù)20?＝35%

重要缺陷摘要

缺陷編號	簡要描述	分析結(jié)果	備注
1	讀者端借閱記錄，沒有續(xù)期而是只有還書一種按鈕	不滿足需求文檔,可能導致用戶不能對超出借閱圖書的還書日期的圖書進行續(xù)訂操作,可能是前端在與后端通信后,沒有對借閱記錄中的還書日期與當前時間進行比較,選擇是還書還是續(xù)期的功能按鈕顯示在前端,或者本系統(tǒng)無法取得正確的當前時間。

3.3.3未解決問題?

未解決問題

???功能/測試類型：單元功能測試

?缺陷具體描述/測試結(jié)果：用戶注冊和管理員提交圖書類別等提交表單信息時,大多數(shù)功能模塊沒有對客戶提交的字段進行相應的判斷包括字段格式、總長度，沒有向客戶進行相應的錯誤類型提示如”反饋信息標題過長”等，而是提示其他通用錯誤類型如：“這是必填字段”?或者停留、直接跳轉(zhuǎn)到?jīng)]有提示的頁面。

???評價：?用戶體驗和交互一般，但是功能上滿足基本需求說明書。

四 測試結(jié)論與建議

??此部分為項目經(jīng)理、部門經(jīng)理以及高層經(jīng)理關注。

4.1測試結(jié)論

(1)本次測試執(zhí)行充分,以下特性較高:安全性、可靠性、可維護性,在功能上基本滿足需求說明書(ServletBMS -RD-2.0)?。

(2)對測試風險的控制措施和成效.

根據(jù)“人機料法環(huán)”分析方法，本測試團隊全面分析出項目風險主要來源

控制措施:1根據(jù)風險發(fā)生的概率和帶來的影響確定風險的優(yōu)先級，然后采取措施避免那些可以避免的風險2，風險轉(zhuǎn)移 3 有些風險不可避免就設法降低風險 4 為了避免轉(zhuǎn)移或降低風險事先要做好風險管理計劃 5 對風險的處理要制定一些應急的有效的處理方案 6 在做計劃時估算資源預算時間等要留有余地不要用到100% 7 制定文檔標準同意建立一種機制保證文檔及時產(chǎn)生。

風險控制成效:測試過程風險控制人王國華發(fā)現(xiàn)測試員黃元鎮(zhèn)不熟悉系統(tǒng)業(yè)務的風險,采取了協(xié)調(diào)開發(fā)組本領域系統(tǒng)業(yè)務專員D同學對測試員黃元鎮(zhèn)進行業(yè)務邏輯輔助和培訓,有效提高和穩(wěn)定了測試工作質(zhì)量。?

測試目標已經(jīng)完成,本版本系統(tǒng)通過了測試,可以進入下一階段項目目標。

4.2建議

本系統(tǒng)比較大的功能性缺陷是讀者端借閱記錄，沒有續(xù)期而是只有還書一種按鈕，不滿足需求文檔,可能導致用戶不能對超出借閱圖書的還書日期的圖書進行續(xù)訂操作。較大的不足是用戶注冊和管理員提交圖書類別等提交表單信息時,大多數(shù)功能模塊沒有對客戶提交的字段進行相應的判斷包括字段格式、總長度，沒有向客戶進行相應的錯誤類型提示，而是提示其他通用錯誤類型如：“這是必填字段”?或者停留、直接跳轉(zhuǎn)到?jīng)]有提示的頁面。用戶體驗和交互一般，但是功能上滿足基本需求說明書。

此版本的系統(tǒng)亟待我們測試小組配合開發(fā)小組進行補充開發(fā)、完善和發(fā)布新版本系統(tǒng)，進一步提高用戶體驗和完全滿足需求說明書。

本測試小組對缺陷修改的建議:建議開發(fā)組人員,開發(fā)時遵照需求說明書進行開發(fā),提高公司協(xié)作交付效率。

對過程改進方面的建議:建議測試小組進行用例設計時,充分在整體上考慮測試用例,在不過度提高單個用例的測試成本時對可以合并測試的用例進行合并,減少冗余和重疊測試。自動化測試后，要手動復現(xiàn)缺陷，即采用自動便捷的自動化測試和靈活的手動測試相結(jié)合的方式。

總結(jié)

以上是生活随笔為你收集整理的Servlet图书管理系统测试报告的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。