課程登錄系統
架構原型的測試計劃
1.0 版
修訂歷程
日期 | 版本 | 說明 | 作者 |
---|---|---|---|
1999 年 3 月 7 日 | 1.0 | 起始版本 - 原型測試計劃 | K. Stone |
|
|
|
|
|
|
|
|
|
|
|
|
目錄
架構原型
的
測試計劃
1、目標
1.1 用途
本文件說明測試「課程登錄系統」之架構原型的計劃。本「測試計劃」文件支援下列目標:
本「測試計劃」說明整合和系統測試,這些測試將在原型 [16] 之「整合建置計劃」中識別的子系統和元件整合後的架構原型上處理。
假設已周密地在黑箱測試、程式碼的延伸範圍,以及所有模組介面的測試上提供單元測試。
組合架構原型的目的是要測試所選架構的可行性和效能。在這開始階段測試所有的系統和子系統介面以及系統效能非常重要。將不會在原型上處理系統功能和特性的測試。
將會測試下列系統之間的介面:
將會測試與下列裝置的外部介面:
要測試的最重要效能測量值如下:
適用的參考資料有:
以下清單識別那些被確定為測試目標的測試(使用案例、 功能需求、非功能需求)。這份清單代表將會測試哪些項目。
(附註:本「測試計劃」的未來版本可能會使用 Rational RequisitePro 直接鏈結至「使用案例文件」及「增補規格」中的需求。)
2.1 資料和資料庫完整性測試
驗證對「課程型錄資料庫」的存取權。
驗證同時記錄讀取權。
驗證「課程型錄」更新期間的鎖定。
驗證是否正確擷取資料庫資料的更新項目。
2.2、功能測試
願景文件 12.2 節:「系統應與現有的「課程型錄資料庫系統」連結。「課程登錄」應支援 [2] 中定義的資料格式」。
願景文件 12.2 節:「系統應與現有的「帳單結算系統」連結,並且應支援 [1] 中定義的資料格式」。
願景文件 12.2 節:「系統的伺服器元件應在 College Campus Server 上運作,並且應在 UNIX 作業系統下執行」。
增補規格 9.3 節:「系統的伺服器元件應在 Wylie College UNIX Server 上運作」。
願景文件 12.2 節:「系統的用戶端部分應在任何配備 486 微處理器或更快微處理器的個人電腦上運作」。
增補規格 9.3 節:「系統的用戶端部分應在任何至少配備 486 微處理器的個人電腦上運作」。
增補規格 9.1 節「系統應與在 College DEC VAX 大型主機上運作的現有舊版系統(課程型錄資料庫)整合」。
增補規格 9.2 節「系統應與在 College DEC VAX 大型主機上運作的現有「課程帳單結算系統」整合」。
2.3 企業週期測試
無。
2.4 使用者介面測試
驗證可透過一個範例畫面集輕易導覽。
驗證範例畫面符合 GUI 標準。
願景文件第 10 節:「系統應易於使用,並且應適用於具備電腦素養的學生和教授的目標市場」。
願景文件 12.1 節:「桌面使用者介面應與 Windows 95/98 相容」。
增補規格 5.1 節:「桌面使用者介面應與 Windows 95/98 相容」。
增補規格 5.2 節:「「課程登錄系統」的使用者介面應設計為易於使用,並且應適用於具備電腦素養的使用者群組,而無需系統的額外訓練」。
2.5 效能測試
驗證存取外部「財務」系統的回應時間。
驗證存取外部「課程型錄」子系統的回應時間。
驗證遠端登入的回應時間。
驗證遠端送出課程登錄的回應時間。
願景文件 12.3 節:「系統應提供對舊式「課程型錄資料庫」的存取權,且延遲時間為 10 秒或以下」。
增補規格 7.2 節:「系統應提供對舊式「課程型錄資料庫」的存取權,且延遲時間為 10 秒或以下」。
2.6 負荷量測試
驗證負荷了 200 位登入的學生時的系統回應。
驗證 50 位學生同時存取「課程型錄」時的系統回應。
2.7 壓力測試
無。
2.8 容量測試
無。
2.9 安全及存取控制測試
驗證從本端 PC 登入。
驗證從遠端 PC 登入。
驗證透過使用者名稱和密碼機制的登入安全。
2.10 失效接手 / 回復測試
無。
2.11 配置測試
願景文件 12.2 節:「系統的用戶端元件應在 Windows 95、Windows 98 和 Microsoft Windows NT 上執行」。
增補規格 9.4 節:「「課程登錄系統」的 Web 型介面應在 Netscape 4.04 及 Internet Explorer 4.0 瀏覽器中執行」。
增補規格 9.5 節:「Web 型介面應與 Java 1.1 VM 執行時期環境相容。」
2.12 安裝測試
無。
「測試策略」呈現測試軟體應用程式的建議方法。「測試需求」中的上一個章節說明將會測試什麼內容;這個部分則說明測試它的方式。
測試策略的主要考量是要採用的技術,以及確認測試何時完成的標準。
除了針對以下的每一項測試所提供的考量之外,還應在安全環境中,使用已知的、受管制的資料庫來執行測試。
在本質上,下列測試策略是通用的,並且是為了適用於本文件的第 4 節中列出的需求。
3.1 測試類型3.1.1 資料和資料庫完整性測試
資料庫和資料庫流程應當作各別的系統測試。這些系統應在沒有應用程式(作為資料的介面)下進行測試。必須執行對於 DBMS 的深入研究,以找出可能存在可以支援以下指出的測試之工具 / 技術。
測試目標: | 確定資料庫存取方法和流程都適當運作,而沒有任何資料毀損。 |
方法: |
|
完成標準: | 所有的資料庫存取方法和流程都按設計運作,而沒有任何資料毀損。 |
特殊考量: |
|
3.1.2 功能測試應用程式的測試應著重在可以直接追蹤至使用案例(或企業運作)的任何目標需求以及企業規則。 這些測試的目標是要驗證是否適當驗收、處理及擷取資料,以及是否適當實作企業規則。 這種類型的測試係以黑箱技術為基礎,亦即,藉由透過 GUI 與應用程式互動以及分析輸出(結果)來驗證應用程式(以及其內部流程)。以下指出的是針對每一個應用程式所建議的測試概要:
測試目標: | 確定應用程式導覽、資料輸入、處理及擷取適當。 |
方法: |
|
完成標準: |
|
特殊考量: |
|
3.1.3 企業週期測試
3.1.4 使用者介面測試本節不適用於架構原型的測試。
「使用者介面測試」驗證使用者與軟體的互動。「使用者介面測試」的目標是要確保「使用者介面」提供使用者對於應用程式功能的適當存取和導覽。此外,「使用者介面測試」可確保使用者介面功能內的物件如所預期,並且符合業界標準。
測試目標: | 驗證下列各項:
|
方法: |
|
完成標準: | 順利驗證每一個視窗都保持與基準版本一致或是在可接受的標準內 |
特殊考量: |
|
3.1.5 效能側寫
「效能」測試測量回應時間、交易率,以及其他與時間敏感相關的需求。「效能」測試的目標是要驗證及檢驗已達到的效能需求。 「效能」測試通常會執行數次,而每一次都是在系統上使用不同的「背景負荷量」。起始測試應在「額定」負荷量下執行,這類似於在目標系統上所經歷到(或參與到)的正常負荷量。第二個效能測試則是使用尖峰負荷量執行。
此外,還可以將「效能」測試當作條件的一項功能(如工作量或硬體配置),用來側寫及調整系統的效能。
附註:以下的交易指的是「邏輯企業交易」。這些交易被定義為預期系統的使用者利用應用程式執行的一些特定功能,例如新增或修改某給定的合約。
測試目標: | 檢驗在下列兩種狀況下的指定交易或企業運作之「系統回應」時間:
- 正常參與的容量 - 參與較差情況的容量 |
方法: |
|
完成標準: |
|
特殊考量: |
|
3.1.6 負荷量測試負荷量測試會測量受測試的系統承受不同的工作量,以評估系統在這些不同的工作量下持續適當運作的能力。負荷量測試的目標是要判斷及確定系統在超過預期的最大工作量下,能否適當運作。此外,負荷量測試還評估一些效能特性(回應時間、 交易率,以及其他與時間敏感相關的問題)。
附註:以下的交易指的是「邏輯企業交易」。這些交易被定義為預期系統的使用者利用應用程式執行的一些特定功能,例如新增或修改某給定的合約。
測試目標: | 驗證指定的交易或企業案例在不同的工作量狀況下的「系統回應」時間。 |
方法: |
|
完成標準: |
|
特殊考量: |
|
3.1.7 壓力測試
3.1.8 容量測試本節不適用於架構原型的測試。
3.1.9 安全和存取控制測試本節不適用於架構原型的測試。
「安全和存取控制測試」著重在兩個主要的安全範圍:
應用程式安全,包括存取「資料」或「企業運作」。
「系統安全」,包括遠端存取系統。應用程式安全可確保使用者受限於存取特定的功能或限定於他們可以使用的資料,視所要的安全而定。例如,允許任何人輸入資料及建立新帳戶,但是只有管理人員可以刪除它們。如果在資料層上有安全性,則測試可確保「類型」一的使用者可以看到所有的客戶資訊(包括財務資料),而類型二的使用者只能看到同一個用戶端的統計資料。
系統安全可確保只有那些獲授予存取系統的使用者能夠存取應用程式,並且只能透過適當的閘道存取。
測試目標: | 功能 / 資料安全:
驗證使用者只能存取他們的使用者類型獲提供其許可權的那些功能 / 資料。 系統安全:驗證只有那些具有對系統和應用程式的存取權之使用者獲允許存取它們。 |
方法: |
|
完成標準: | 針對每一個已知的使用者類型,可以使用適當的功能 / 資料,並且所有的交易功能都如預期運作,且能在先前的「應用程式功能」測試中執行 |
特殊考量: |
|
3.1.10 失效接手和回復測試
3.1.11 配置測試本節不適用於架構原型的測試。
配置測試驗證軟體在不同的軟體和硬體配置上的運作。在大部分的正式作業環境中,用戶端工作站、網路連線及資料庫伺服器的特定硬體規格各異。用戶端工作站可能載入了不同的軟體,像是應用程式、驅動程式等等。在任何一個時間,許多不同的組合可能在作用中以及使用不同的資源。
測試目標: | 檢驗並驗證用戶端應用程式在指定的用戶端工作站上適當運作。 |
方法: |
|
完成標準: | 針對「原型」和 PC 應用程式的每一個組合,交易都順利完成,而沒有任何失敗。 |
特殊考量: |
|
3.1.12 安裝測試3.2 工具本節不適用於「課程登錄」架構原型的測試。
工具 | 版本 | |
---|---|---|
測試管理 | Rational RequisitePro
Rational Unified Process |
TBD |
測試設計 | Rational Rose | TBD |
問題追蹤 | Rational ClearQuest | TBD |
功能測試 | Rational Robot | TBD |
效能測試 | Rational Visual Quantify | TBD |
測試涵蓋面顯示器或側寫程式 | Rational Visual PureCoverage | TBD |
其他測試工具 | Rational Purify
Rational TestFactory |
TBD |
專案管理 | Microsoft Project
Microsoft Word Microsoft Excel |
TBD |
DBMS 工具 | TBD | TBD |
4、 資源
4.1 角色此表格顯示「原型」測試的人員配置假設。
人力資源
角色 | 建議的資源下限
(已配置為專職的工作者數) |
特定的責任/備註 |
---|---|---|
測試管理人員 | 1 - Kerry Stone | 提供管理監督
責任:
|
測試設計師 | Margaret Cox
Carol Smith |
識別、優先順序化及實作測試案例
責任:
|
系統測試人員 | Carol Smith | 執行測試
責任:
|
測試系統管理人員 | Simon Jones | 確認測試環境和資產受到管理及維護。 責任:
|
資料庫管理 / 資料庫管理人員 | Margaret Cox | 確認測試資料(資料庫)環境和資產受到管理及維護。 責任:
|
設計師 | Margaret Cox | 識別及定義測試類別的作業、屬性和關聯
責任:
|
實作人員 | Margaret Cox | 實作及單元測試測試類別和測試套件
責任:
|
4.2 系統
下表說明用於測試「課程登錄」原型的系統資源。
系統資源
資源 | 名稱 / 類型 / 序號 |
---|---|
Wylie College Server | 序號:X179773562b |
課程型錄資料庫 | 版本 Id:CCDB-080885 |
帳單結算系統 | 版本 Id:BSSS-88335 |
用戶端測試 PC |
|
3 部遠端 PC(具備網際網路存取權) | 序號:A8339223
序號:B9334022 序號:B9332544 |
3 部本端 PC(透過 LAN 連接) | 序號:R3322411(登錄人員)
序號:A8832234(IT 實驗室) 序號:W4592233(IT 實驗室) |
測試儲存庫 |
|
Wylie College Server | 序號:X179773562b |
測試開發 PC - 6 | 序號:A8888222
序號:R3322435 序號:I88323423 序號:B0980988 序號:R3333223 序號:Y7289732 |
5、 專案里程碑
「課程登錄架構原型」的測試納入了先前的章節中所識別的每一項測試工作的測試作業。識別了各別的專案里程碑,以傳達專案的狀態和成果。
請參閱軟體開發計劃 [13] 和 E1 反覆計劃 [14],以取得整體階段或主要專案排程。
里程碑作業 | 工作 (pd) | 開始日期 | 結束日期 |
---|---|---|---|
原型測試規劃 | 2 | 3 月 12 日 | 3 月 15 日 |
原型測試設計 | 3 | 3 月 15 日 | 3 月 18 日 |
原型測試開發 | 4 | 3 月 19 日 | 3 月 23 日 |
原型測試執行 | 3 | 3 月 24 日 | 3 月 26 日 |
原型測試評估 | 1 | 3 月 29 日 | 3 月 29 日 |
下表概述在此「測試計劃」中定義的測試作業之工作成果。
工作成果 | 擁有者 | 審查 / 分送 | 到期日 |
測試計劃 | K. Stone | 資深專案管理團隊 | 3 月 15 日 |
測試環境 | S. Jones | - | 3 月 18 日 |
測試套組 | C. Smith 和 M. Cox | 內部同儕審查 | 3 月 23 日 |
測試聚集 | M. Cox | 內部同儕審查 | 3 月 23 日 |
測試 Script | M. Cox | - | 3 月 23 日 |
測試 Stub、驅動程式 | M. Cox | - | 3 月 23 日 |
測試問題報告 | C. Smith | 資深專案管理團隊 | 3 月 26 日 |
測試結果 | C. Smith | - | 3 月 26 日 |
測試評估報告 | C. Smith | 資深專案管理團隊 | 3 月 29 日 |
6.1 測試套組「測試套組」將定義所有的測試案例以及與各個測試案例相關聯的測試 Script。
6.2 測試日誌已規劃使用 RequisitePro 來識別測試案例及追蹤每一個測試案例的狀態。測試結果將會彙總在 RequisitePro 中,分為未測試、已通過、有條件通過或失敗。在摘要中,將會設定 RequisitePro 來支援每一個測試案例的下列屬性,如需求屬性準則 [17] 中所定義:
- 測試狀態
- 建置號碼
- 測試人員
- 測試日期
- 測試附註
7、 專案作業在 RequisitePro 中更新測試狀態將是「系統測試人員」的責任。
測試結果將保留在「配置控制」下。
6.3 問題報告將使用 Rational ClearQuest 來記載及追蹤個別問題。
以下是測試「課程登錄架構原型」的測試相關作業:
規劃測試 |
|
|
|
|
|
|
設計測試 |
|
|
|
|
|
實作測試 |
|
|
|
|
|
執行測試 |
|
|
|
|
|
|
評估測試 |
|
|
|
判定是否已達成「測試完成標準」及「順利完成標準」 |
建立測試評估報告 |
Copyright (c) IBM Corp. 1987, 2004. All Rights Reserved. |
課程登錄系統專案 Web 範例 |