《圖書管理系統(tǒng)》

一、簡介
1．目的
為了驗證圖書管理系統(tǒng)的圖書管理模塊能否正常實現(xiàn)，以圖書管理系統(tǒng)作為測試對象，展開系統(tǒng)測試。
2．背景
圖書管理系統(tǒng)包括圖書錄入、圖書修改、圖書刪除、圖書查詢等九個子系統(tǒng)，用于管理圖書館日常運作的整個過程。各子系統(tǒng)所處理的業(yè)務前后銜接，數(shù)據(jù)共享。

3．范圍
1.圖書管理模塊

二、測試需求
1.數(shù)據(jù)庫測試；
2.功能性測試；
3.性能測試；

三、測試風險
1.質量需求或產(chǎn)品的特性理解不準確，造成測試范圍分析的誤差，結果某些地方始
終測試不到或驗證的標準不對。
2.測試用例沒有得到百分之百的執(zhí)行，如有些測試用例被有意或無意的遺漏。
3.需求的臨時或突然變化，導致設計的修改和代碼的重寫，測試時間不夠。
4.測試用例設計不到位，忽視了一些邊界條件、深層次的邏輯、用戶場景等。
5.測試環(huán)境，一般不可能和實際運行環(huán)境完全一致，造成測試結果的誤差。
6.有些缺陷出現(xiàn)頻率不是百分之百，不容易被發(fā)現(xiàn)；如果代碼質量差，軟件缺陷很
多，被漏檢的缺陷可能性就大。
前面三種風險是可以避免的，而 4～6 的四種風險是不能避免的，可以降到最低。最后
一種回歸測試風險是可以避免，但出于時間或成本的考慮，一般也是存在的。
針對上述軟件測試的風險，有一些有效的測試風險控制方法，如：
測試環(huán)境不對可以通過事先列出要檢查的所有條目，在測試環(huán)境設置好后，由其他人員53
按已列出條目逐條檢查。
有些測試風險可能帶來的后果非常嚴重，能否將它轉化為其他一些不會引起嚴重后果的
低風險。如產(chǎn)品發(fā)布前夕，在某個不是很重要的新功能上發(fā)現(xiàn)一個嚴重的缺陷，如果修正這
個缺陷，很有可能引起某個原有功能上的缺陷。這時處理這個缺陷所帶來的風險就很大，對
策是去掉那個新功能，轉移這種風險。
有些風險不可避免，就設法降低風險，如“程序中未發(fā)現(xiàn)的缺陷”這種風險總是存在，
我們就要通過提高測試用例的覆蓋率（如達到 99.9%）來降低這種風險。
為了避免、轉移或降低風險，事先要做好風險管理計劃和控制風險的策略，并對風險的
處理還要制訂一些應急的、有效的處理方案。

四、測試策略
1.數(shù)據(jù)和數(shù)據(jù)庫完整性測試
數(shù)據(jù)庫和數(shù)據(jù)庫進程應作為<項目名稱>中的子系統(tǒng)來進行測試。在測試這些子系統(tǒng)時，
不應將測試對象的用戶界面用做數(shù)據(jù)的接口。對于數(shù)據(jù)庫管理系統(tǒng)（DBMS），還需要進行
深入的研究，以確定可以支持以下測試的工具和方法。數(shù)據(jù)庫測試如表 2-2 所示。
表 2-2 數(shù)據(jù)庫測試說明

發(fā)布文章的話表格不能直接復制到上面（下邊那些有?的， 都是帶表格的是表格里的數(shù)據(jù)），想要帶有表格的標準格式就下載一下我發(fā)布過的資源，軟件測試——圖書管理系統(tǒng)的測試計劃書吧

測試目標
確保數(shù)據(jù)庫訪問方法和進程正常運行，數(shù)據(jù)不會遭到損壞。
方法
? 調用各個數(shù)據(jù)庫訪問方法和進程，并在其中填充有效的和無效
的數(shù)據(jù)或對數(shù)據(jù)的請求。
? 檢查數(shù)據(jù)庫，確保數(shù)據(jù)已按預期的方式填充，并且所有數(shù)據(jù)庫
事件都按正常方式出現(xiàn)：或者檢查所返回的數(shù)據(jù)，確保為正當
的理由檢索到了正確的數(shù)據(jù)：
完成標準 所有的數(shù)據(jù)庫訪問方法和進程都按照設計的方式運行，數(shù)據(jù)沒有遭
到損壞。

需考慮的特殊事項
? 測試可能需要 DBMS 開發(fā)環(huán)境或驅動程序以便在數(shù)據(jù)庫中直
接輸入或修改數(shù)據(jù)、
? 進程應該以手工方式調用。
? 應使用小型或最小的數(shù)據(jù)庫（其中的記錄數(shù)很有限）來使所有
無法接受的事件具有更大的可見性。

2.功能測試
測試對象的功能測試應該側重于可以被直接追蹤到用例或業(yè)務功能和業(yè)務規(guī)則的所有
測試需求。這些測試的目標在于核實能否正確地接受、處理和檢索數(shù)據(jù)以及業(yè)務規(guī)則是否正
確實施。這種類型的測試基于黑盒方法，即通過圖形圖書管理界面與應用程序交互并分
析輸出結果來驗證應用程序及其內部進程。表 2-3 列出的是每個應用程序推薦的測試方法概
要。
表 2-3 功能測試說明表

測試目標 確保測試對象的功能正常，其中包括數(shù)據(jù)添加、修改、刪除和查詢。
方法 利用有效的和無效的數(shù)據(jù)來執(zhí)行各個用例、用例流或功能，以核實
以下內容：
? 在使用有效數(shù)據(jù)時得到預期的結果。
? 在使用無效數(shù)據(jù)時顯示相應的錯誤消息或警告消息。
? 各業(yè)務規(guī)則都得到了正確的應用。
完成標準
? 所計劃的測試已全部執(zhí)行。
? 所發(fā)現(xiàn)的缺陷已全部解決。
需考慮的特殊事項
確定或說明那些將對功能測試的實施和執(zhí)行造成影響的事項或因素
（內部的或外部的)。

3.性能評價
性能評價是一種性能測試，它對響應時間、事務處理速率和其他與時間相關的需求進行
評測和評估。性能評價的目標是核實性能需求是否都已滿足。實施和執(zhí)行性能評價的目的是
將測試對象的性能為當做條件（如工作量或硬件配置）的一種函數(shù)來進行評價和微調。性能
測試如表 2-6 所示。
注：以下事務均指“邏輯業(yè)務事務”。這種事務被定義為將由系統(tǒng)的某個主角通過使用
測試對象來執(zhí)行的特定用例，例如，添加或修改某個合同。
表 2-6 性能測試說明表

測試目標
核實所指定的事務或業(yè)務功能在以下情況下的性能行為：
? 正常的預期工作量。
? 預期的最繁重工作量。

方法
使用為功能或業(yè)務周期測試制定的測試過程。
通過修改數(shù)據(jù)文件來增加事務數(shù)量，或通過修改腳本來增加每項事
務的迭代次數(shù)。
腳本應該在一臺計算機上運行（最好是以單個用戶、單個事務為基
準），并在多臺客戶機（虛擬的或實際的客戶機，請參見下面的“需
考慮的特殊事項”）上重復。

完成標準 ? 單個事務或單個用戶：在每個事務所預期或要求的時間范圍內
成功地完成測試腳本，沒有發(fā)生任何故障。
? 多個事務或多個用戶：在可接受的時間范圍內成功地完成測試
腳本，沒有發(fā)生任何故障。
需考慮的特殊事項
綜合的性能測試還包括在服務器上添加后臺工作量。
可采用多種方法來執(zhí)行此操作，其中包括：
直接將“事務強行分配到”服務器上，這通常以“結構化查詢
語言”(SQL）調用的形式來實現(xiàn)。
通過創(chuàng)建“虛擬的”用戶負載來模擬許多個（通常為數(shù)百個）56
客戶機。此負載可通過“遠程終端仿真”（Remote Terminal Emulation）
工具來實現(xiàn)。此技術還可用于在網(wǎng)絡中加載“流量”。
使用多臺實際客戶機（每臺客戶機都運行測試腳本）在系統(tǒng)上
添加負載。
性能測試應該在專用的計算機上或在專用的機時內執(zhí)行，以便
實現(xiàn)完全的控制和精確的評測。
性能測試所用的數(shù)據(jù)庫應該是與實際大小相同或等比例縮放的
數(shù)據(jù)庫。

五、測試工具
此項目將使用表 2-14 所示的工具。
注：可以視情況刪除或添加項目。
表 2-14 測試工具
工具 廠商 版本

測試管理 Quality Center HP
10.0

功能性測試
QTP
HP
12.0

性能測試
LoadRunner
HP
12.0

六、資源
1.人力資源
表 2-15 列出了在此項目的人員配備方面所做的各種假定。
表 2-15 人力資源說明表

人力資源
角色
推薦的最少資源 具體職責或注釋

測試組長
1 負責擬訂軟件項目的測試計劃和方案，提供
測試技術指導，組織測試資源，安排測試計
劃實施，提交測試分析報告，總結整個測試
活動。

測試設計員 1 參與制訂測試計劃，生成測試模型，在面向
對象的設計系統(tǒng)中確定并定義測試類的操
作、屬性和關聯(lián)關系。
確定測試用例，指導測試實施，參與測試評
估和測試分析報告的編寫。
測試員
1 執(zhí)行實施測試，填寫測試記錄，記錄結果和
缺陷。

2.系統(tǒng)資源
表 2-16 列出了測試項目所需的系統(tǒng)資源。
此時并不完全了解測試系統(tǒng)的具體元素。建議讓系統(tǒng)模擬生產(chǎn)環(huán)境，并在適當?shù)那闆r下
減小訪問量和數(shù)據(jù)庫大小。

表 2-16 系統(tǒng)資源說明表

系統(tǒng)資源
服務器名 172.16.112.177
數(shù)據(jù)庫名 sa
客戶端測試 PC 172.16.112.177

七、測試進度和里程碑
1.項目測試進度
以下測試工作任務的起止時間為：
① 圖書錄入功能
② 圖書修改功能
③ 圖書刪除功能
④ 圖書查詢功能

2.測試里程碑
對<項目名稱>的測試應包括上面各節(jié)所述的各項測試的測試活動。應該為這些測試確
定單獨的項目里程碑，如表 2-17 所示，以通知項目的狀態(tài)和成果。
表 2-17 測試里程碑說明表
里程碑任務 工作量 開始日期 結束日期
圖書錄入功能
圖書修改功能
圖書刪除功能
圖書查詢功能

八、可交付工件
這部分內容列出了將要創(chuàng)建的各種文檔、工具和報告，及其創(chuàng)建人員、交付對象和交付時間。例如，測試計劃說明書、測試用例或測試腳本、開發(fā)的測試工具、測試日志、缺陷報
告、測試分析報告、測試總結等。
（1）概述
① 測試目的
提供一個對項目軟件進行測試的總體安排和進度計劃，確定現(xiàn)有項目的信息和應測試的
軟件標明推薦的測試需求（高層次）和可采用的測試策略，并對這些策略加以說明確定所需
的資源，并對測試的工作量進行估計，列出測試項目的可交付元素。
② 測試范圍
描述測試的各個階段，例如，單元測試、集成測試或系統(tǒng)測試，并說明本計劃所針對的
測試類型（如功能測試或性能測試)。簡要地列出測試對象中將接受測試或將不接受測試的
些特性和功能。
如果在編寫此文檔的過程中做出的某些假設可能會影響測試設計、開發(fā)或實施，則列出
所有這些假設。列出可能會影響測試設計、開發(fā)或實施的所有風險或意外事件。列出可能會
影響測試設計、開發(fā)或實施的所有約束。
③ 限制條件
a. 設備所用到的設備類型、數(shù)量和預定使用時間。
b. 軟件列出將被用來支持本項測試過程而本身又并不是被測軟件的組成部分的軟件，
如測試驅動程序、測試監(jiān)控程序、仿真程序、樁模塊等。
c. 列出在測試工作期間預期可由用戶和開發(fā)任務組提供的工作人員的人數(shù)。技術水平
及有關的預備知識，包括一些特殊要求，如倒班操作和數(shù)據(jù)輸入人員。
④ 參考文檔
列出制作此測試計劃所依據(jù)的文檔，例如，需求規(guī)約、設計規(guī)約，概要或詳細設計、業(yè)
務流程、數(shù)據(jù)流程等。列出要用到的參考資料。
（2）測試摘要
① 測試目標
② 資源和工具
a. 資源
項目使用的資源，及其主要職責、知識或技能。
b. 工具
列出測試所使用的測試工具或自主開發(fā)的測試軟件，說明運用這些工具或開發(fā)軟件測試
對象的何種特性。
③ 送測要求
④ 測試種類
（3）測試風險
（4）暫停標準和再啟動要求
（5）測試任務和進度
列出要測試中的每一項測試內容，例如：
模塊功能測試；
接口正確性測試；
數(shù)據(jù)文件存取的測試；
運行時間的測試；
設計約束和極限的測試等。
并針對每項測試內容給出測試條件，如：
所用到的設備、數(shù)量和預定使用時間；
給出對這項測試的進度安排，包括進行測試的日期和工作內容（如熟悉環(huán)境、培訓、準
備輸入數(shù)據(jù)等）。
（6）測試提交物
① 測試計劃
② 測試用例
③ 缺陷記錄
④ 測試總結

總結

以上是生活随笔為你收集整理的软件测试——图书管理系统的测试计划书的全部內容，希望文章能夠幫你解決所遇到的問題。

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