課程登錄系統

架構原型的測試計劃

1.0 版

 

修訂歷程

日期版本 說明 作者
1999 年 3 月 7 日 1.0 起始版本 - 原型測試計劃 K. Stone
 
 
 
 
 
 
 
 
 
 
 
 

 

 

目錄

  1. 目標
  2. 測試需求
  3. 測試策略
  4. 資源
  5. 專案里程碑
  6. 工作成果
  7. 專案作業

 

架構原型

測試計劃

1、目標

1.1 用途

本文件說明測試「課程登錄系統」之架構原型的計劃。本「測試計劃」文件支援下列目標:

1.2 範圍

本「測試計劃」說明整合和系統測試,這些測試將在原型 [16] 之「整合建置計劃」中識別的子系統和元件整合後的架構原型上處理。

假設已周密地在黑箱測試、程式碼的延伸範圍,以及所有模組介面的測試上提供單元測試。

組合架構原型的目的是要測試所選架構的可行性和效能。在這開始階段測試所有的系統和子系統介面以及系統效能非常重要。將不會在原型上處理系統功能和特性的測試。

將會測試下列系統之間的介面:

    1. 課程登錄
    2. 財務系統
    3. 課程型錄。

將會測試與下列裝置的外部介面:

    1. 本端 PC
    2. 遠端 PC。

要測試的最重要效能測量值如下:

    1. 遠端登入課程登錄系統的回應時間。
    2. 存取「財務系統」的回應時間。
    3. 存取「課程型錄子系統」的回應時間。
    4. 系統負荷了 200 位登入的學生時的學生回應時間。
    5. 50 位學生同時存取「課程型錄」資料庫時的學生回應時間。
1.3 參考資料

適用的參考資料有:

    1. Course Billing Interface Specification, WC93332, 1985, Wylie College Press.
    2. Course Catalog Database Specification, WC93422, 1985, Wylie College Press.
    3. Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie College IT.
    4. Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
    5. Course Registration System Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College IT.
    6. Course Registration System Use Case Spec - Login, WyIT401, V2.0, 1999, Wylie College IT.
    7. Course Registration System Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999, Wylie College IT.
    8. Course Registration System Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie College IT.
    9. Course Registration System Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999, Wylie College IT.
    10. Course Registration System Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie College IT.
    11. Course Registration System Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College IT.
    12. Course Registration System Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie College IT.
    13. Course Registration System Software Development Plan, WyIT418, V1.0, 1999, Wylie College IT.
    14. Course Registration System Iteration Plan, Elaboration Iteration #E1, WyIT420, V1.0, 1999, Wylie College IT.
    15. Course Registration System Software Architecture Document, WyIT431, V1.0, 1999, Wylie College IT.
    16. Course Registration System Integration Build Plan for the Architectural Prototype, WyIT430, V1.0, 1999, Wylie College IT.
    17. Course Registration System Requirements Attributes Guidelines, WyIT404, V1.0, 1999, Wylie College IT.
2、    測試需求 

    以下清單識別那些被確定為測試目標的測試(使用案例、 功能需求、非功能需求)。這份清單代表將會測試哪些項目

    (附註:本「測試計劃」的未來版本可能會使用 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 安裝測試

    無。

3.    測試策略

    「測試策略」呈現測試軟體應用程式的建議方法。「測試需求」中的上一個章節說明將會測試什麼內容;這個部分則說明測試它的方式

    測試策略的主要考量是要採用的技術,以及確認測試何時完成的標準。

    除了針對以下的每一項測試所提供的考量之外,還應在安全環境中,使用已知的、受管制的資料庫來執行測試。

    在本質上,下列測試策略是通用的,並且是為了適用於本文件的第 4 節中列出的需求。

3.1 測試類型

3.1.1 資料和資料庫完整性測試

資料庫和資料庫流程應當作各別的系統測試。這些系統應在沒有應用程式(作為資料的介面)下進行測試。必須執行對於 DBMS 的深入研究,以找出可能存在可以支援以下指出的測試之工具 / 技術。

 

測試目標: 確定資料庫存取方法和流程都適當運作,而沒有任何資料毀損。
方法:
  • 以有效及無效的資料(或資料要求)探查每一個資料庫存取方法和流程,呼叫各個方法和流程。
  • 檢查資料庫,以確保資料如預期般移入、所有的資料庫事件都適當地發生,或是審查傳回的資料以確定擷取的是正確的資料(基於正確的原因)
完成標準: 所有的資料庫存取方法和流程都按設計運作,而沒有任何資料毀損。
特殊考量:
  • 測試可能需要 DBMS 開發環境或驅動程式直接在資料庫中輸入或修改資料。
  • 應以手動方式呼叫流程。
  • 應使用小型或大小縮至最小的資料庫(有限的記錄數)來增加任何無法接受事件的可見性。

 

 

3.1.2 功能測試

應用程式的測試應著重在可以直接追蹤至使用案例(或企業運作)的任何目標需求以及企業規則。 這些測試的目標是要驗證是否適當驗收、處理及擷取資料,以及是否適當實作企業規則。 這種類型的測試係以黑箱技術為基礎,亦即,藉由透過 GUI 與應用程式互動以及分析輸出(結果)來驗證應用程式(以及其內部流程)。以下指出的是針對每一個應用程式所建議的測試概要:

 

測試目標: 確定應用程式導覽、資料輸入、處理及擷取適當。
方法:
  • 使用有效及無效的資料執行每一個使用案例、使用案例流程或功能,來驗證下列各項:
  • 使用有效的資料時發生預期的結果。
  • 使用無效的資料時會顯示適當的錯誤 / 警告訊息。
  • 適當地套用了每一個企業規則。
完成標準:
  • 已執行所有規劃的測試。
  • 已處理所有識別出的問題。
特殊考量:
  • 需要對 Wylie College UNIX Server 及現有的「課程型錄系統」和「帳單結算系統」的存取權,才能執行部分已識別的「原型系統測試」。
 

3.1.3 企業週期測試

本節不適用於架構原型的測試。

3.1.4 使用者介面測試

「使用者介面測試」驗證使用者與軟體的互動。「使用者介面測試」的目標是要確保「使用者介面」提供使用者對於應用程式功能的適當存取和導覽。此外,「使用者介面測試」可確保使用者介面功能內的物件如所預期,並且符合業界標準。

 

測試目標: 驗證下列各項:
  • 導覽應用程式可適當反映企業的運作和需求,包括視窗對視窗、欄位對欄位,以及使用存取方法(Tab 鍵、滑鼠移動、快速鍵)。
  • 視窗的物件和特性(如功能表、大小、位置、狀態和焦點)符合標準。
方法:
  • 針對每一個視窗建立 / 修改測試,來驗證每一個應用程式視窗及物件的導覽和物件狀態是否適當。
完成標準: 順利驗證每一個視窗都保持與基準版本一致或是在可接受的標準內
特殊考量:
  • 自訂物件及第三方物件的所有內容並非都可以存取。
 

3.1.5 效能側寫

「效能」測試測量回應時間、交易率,以及其他與時間敏感相關的需求。「效能」測試的目標是要驗證及檢驗已達到的效能需求。 「效能」測試通常會執行數次,而每一次都是在系統上使用不同的「背景負荷量」。起始測試應在「額定」負荷量下執行,這類似於在目標系統上所經歷到(或參與到)的正常負荷量。第二個效能測試則是使用尖峰負荷量執行。

此外,還可以將「效能」測試當作條件的一項功能(如工作量或硬體配置),用來側寫及調整系統的效能。

附註:以下的交易指的是「邏輯企業交易」。這些交易被定義為預期系統的使用者利用應用程式執行的一些特定功能,例如新增或修改某給定的合約。

 

測試目標: 檢驗在下列兩種狀況下的指定交易或企業運作之「系統回應」時間:

- 正常參與的容量

- 參與較差情況的容量

方法:
  • 使用針對「企業模型測試」(「系統測試」)所開發的「測試 Script」。
  • 修改資料檔(以增加交易數)或修改 Script 來增加每一筆交易發生的反覆數。
  • Script 應在一部機器上執行(單一使用者、單筆交易基準性能測試的最佳情況),並在多個用戶端上重複(虛擬或實際,請參閱以下的特殊考量)。
完成標準:
  • 單一交易 / 單一使用者:在預期的 / 所需的時間配置(每筆交易)內順利完成測試 Script,而沒有發生任何失敗。
  • 多筆交易 / 多位使用者:在可接受的時間配置內順利完成測試 Script,而沒有發生任何失敗。
特殊考量:
  • 綜合性的效能測試包含讓伺服器上負載「背景」負荷量。有數個方法可用來執行這項作業,其中包括:
    • 直接「驅動交易」至伺服器,其格式通常為 SQL 呼叫。
    • 建立「虛擬」使用者負荷量來模擬許多個(通常是數百個)用戶端。使用了「遠端終端機模擬」工具來達成這個負荷量。這種方法也可用來將「資料流量」載入網路。
    • 使用多個實體用戶端,其中每一個用戶端都執行測試 Script 來將負荷量加諸在系統上。
  • 效能測試應在專用機器上或於特定時間執行。這樣可以獲取完全的控制及精準的測量。
  • 用於「效能」測試的資料庫應為實際大小或相等地調整比例。

 

3.1.6 負荷量測試

負荷量測試會測量受測試的系統承受不同的工作量,以評估系統在這些不同的工作量下持續適當運作的能力。負荷量測試的目標是要判斷及確定系統在超過預期的最大工作量下,能否適當運作。此外,負荷量測試還評估一些效能特性(回應時間、 交易率,以及其他與時間敏感相關的問題)。

附註:以下的交易指的是「邏輯企業交易」。這些交易被定義為預期系統的使用者利用應用程式執行的一些特定功能,例如新增或修改某給定的合約。

 

測試目標: 驗證指定的交易或企業案例在不同的工作量狀況下的「系統回應」時間。
方法:
  • 使用針對「企業週期測試」所開發的測試。
  • 修改資料檔(以增加交易數)或測試來增加每一筆交易發生的次數。
完成標準:
  • 多筆交易 / 多位使用者:在可接受的時間配置內順利完成測試,而沒有發生任何失敗。
特殊考量:
  • 負荷量測試應在專用機器上或於特定時間執行。這樣可以獲取完全的控制及精準的測量。
  • 用於負荷量測試的資料庫應為實際大小或相等地調整比例。
 

3.1.7 壓力測試

本節不適用於架構原型的測試。

3.1.8 容量測試

本節不適用於架構原型的測試。

3.1.9 安全和存取控制測試

「安全和存取控制測試」著重在兩個主要的安全範圍:

應用程式安全,包括存取「資料」或「企業運作」。
「系統安全」,包括遠端存取系統。

應用程式安全可確保使用者受限於存取特定的功能或限定於他們可以使用的資料,視所要的安全而定。例如,允許任何人輸入資料及建立新帳戶,但是只有管理人員可以刪除它們。如果在資料層上有安全性,則測試可確保「類型」一的使用者可以看到所有的客戶資訊(包括財務資料),而類型二的使用者只能看到同一個用戶端的統計資料。

系統安全可確保只有那些獲授予存取系統的使用者能夠存取應用程式,並且只能透過適當的閘道存取。

 

測試目標: 功能 / 資料安全: 驗證使用者只能存取他們的使用者類型獲提供其許可權的那些功能 / 資料。

系統安全:驗證只有那些具有對系統和應用程式的存取權之使用者獲允許存取它們。

方法:
  • 功能 / 資料安全:識別並列出每一種使用者類型,以及每一種類型具有其許可權的功能 / 資料。
  • 建立每一種使用者類型的測試,並藉由建立每一種使用者類型特有的交易來驗證許可權。
  • 修改使用者類型,然後針對相同的使用者重新執行測試。在每一個案例中,驗證那些其他的功能 / 資料正確地可供使用或拒絕。
  • 系統存取(請參閱以下的特殊考量)
完成標準: 針對每一個已知的使用者類型,可以使用適當的功能 / 資料,並且所有的交易功能都如預期運作,且能在先前的「應用程式功能」測試中執行
特殊考量:
  • 務必與適當的網路或系統管理人員重新探討 / 討論對系統的存取權。這項測試可能並非必要,因為它可能是網路或系統管理的功能。
 

3.1.10 失效接手和回復測試

本節不適用於架構原型的測試。

3.1.11 配置測試

配置測試驗證軟體在不同的軟體和硬體配置上的運作。在大部分的正式作業環境中,用戶端工作站、網路連線及資料庫伺服器的特定硬體規格各異。用戶端工作站可能載入了不同的軟體,像是應用程式、驅動程式等等。在任何一個時間,許多不同的組合可能在作用中以及使用不同的資源。

 

測試目標: 檢驗並驗證用戶端應用程式在指定的用戶端工作站上適當運作。
方法:
  • 使用整合和系統測試 Script
  • 在測試過程中或開始測試之前,開啟 / 關閉各種 PC 應用程式。
  • 執行所選的交易,將使用者活動模擬到各種 PC 應用程式,或從中模擬出使用者活動。
  • 將用戶端上可用的反覆記憶體減至最少,重複上述流程。
完成標準: 針對「原型」和 PC 應用程式的每一個組合,交易都順利完成,而沒有任何失敗。
特殊考量:
  • 用戶端上可以使用、存取哪些 PC 應用程式?
  • 通常使用哪些應用程式?
  • 應用程式在執行什麼資料(亦即,在 Excel 中開啟了大型的試算表、在 Word 中有 100 頁的文件)。
  • 這項測試的一部分作業也應記載整個系統、網路伺服器、資料庫等等。

 

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 日

     

6、    工作成果

    下表概述在此「測試計劃」中定義的測試作業之工作成果。

    工作成果 擁有者 審查 / 分送 到期日
    測試計劃 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] 中所定義:

在 RequisitePro 中更新測試狀態將是「系統測試人員」的責任。

測試結果將保留在「配置控制」下。

6.3 問題報告

將使用 Rational ClearQuest 來記載及追蹤個別問題。

7、    專案作業

以下是測試「課程登錄架構原型」的測試相關作業:

規劃測試

識別測試的需求

評定風險

開發測試策略

識別測試資源

建立排程

產生測試計劃

設計測試

工作量分析(不適用於「原型」)

開發測試套組

識別及說明測試案例

識別及結構化測試 Script

審查及存取測試涵蓋面

實作測試

設定測試環境

記錄或程式化測試 Script

開發測試 Stub 和驅動程式

識別設計和實作模型中的「測試特有」功能

建立外部聚集

執行測試

執行測試 Script

評估測試的執行

回復中止的測試

驗證結果

探索非預期的結果

記載問題

評估測試

評估測試案例涵蓋面

評估程式碼涵蓋面

分析問題

判定是否已達成「測試完成標準」及「順利完成標準」
建立測試評估報告

Copyright  (c) IBM Corp. 1987, 2004. All Rights Reserved.

課程登錄系統專案 Web 範例
2001.03 版