課程登錄系統

測試計劃

 

1.0 版

修訂歷程

日期

版本

說明

作者

1999 年 3 月 27 日 1.0 第 1 版及第 2 版的測試計劃 K. Stone
 
 
 
 
 
 
 
 
 
 
 
 

 

 

目錄

  1. 目標
  2. 範圍
  3. 參考資料
  4. 測試需求
  5. 測試策略
    1. 測試類型
      1. 資料和資料庫完整性測試
      2. 系統測試
      3. 企業週期測試
      4. 使用者介面測試
      5. 效能測試
      6. 負荷量測試
      7. 壓力測試
      8. 容量測試
      9. 安全和存取控制測試
      10. 失效接手 / 回復測試
      11. 配置測試
      12. 安裝測試
    2. 工具
  6. 資源
    1. 工作者
    2. 系統
  7. 專案里程碑
  8. 工作成果
    1. 測試套組
    2. 測試日誌
    3. 問題報告
  9. 專案作業

測試計劃

 

1、目標

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

    • 識別應測試的現有專案資訊和軟體元件。
    • 列出建議的測試需求(高階)。
    • 建議並說明要採用的測試策略。
    • 識別所需的資源,以及提供測試工作的預估。
    • 列出測試作業的工作成果元素。

2、範圍

    本「測試計劃」適用於將在「課程登錄系統」第 1 版和第 2 版中處理的整合和系統測試。請注意,有一個各別的測試計劃 [17],說明「架構原型」的測試策略。

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

    本「測試計劃」適用於測試願景文件 [3]、使用案例規格 [5-12] 及增補規格中定義的所有「課程登錄系統」需求。

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 Supplementary Specification, WyIT400, V1.0, 1999, Wylie College IT.
    14. Course Registration System Software Development Plan, WyIT418, V2.0, 1999, Wylie College IT.
    15. Course Registration System Software Architecture Document, WyIT431, V1.0, 1999, Wylie College IT.
    16. Course Registration System Requirements Attributes Guidelines, WyIT404, V1.0, 1999, Wylie College IT.
    17. Course Registration System Test Plan for the Architectural Prototype, WyIT432, V1.0, 1999, Wylie College IT.

4、測試需求

    以下清單識別那些被確定為測試目標的測試(使用案例、 功能需求、非功能需求)。這份清單代表將會測試哪些項目。有關每一項測試的詳細資料將在稍後識別「測試案例」及開發「測試 Script」時決定。

    (附註:本「測試計劃」的未來版本可能會使用 Rational RequisitePro 直接鏈結至「願景文件」、「使用案例文件」及「增補規格」中的需求。)

    資料和資料庫完整性測試

    驗證對「課程型錄資料庫」的存取權。

    驗證同時記錄讀取權。

    驗證「課程型錄」更新期間的鎖定。

    驗證是否正確擷取資料庫資料的更新項目。

    系統測試(亦即,功能測試)

    驗證登入使用案例 [6]

    驗證關閉登錄使用案例 [5]

    驗證維護學生資訊使用案例 [10]

    驗證維護教授資訊使用案例 [7]

    驗證送出成績使用案例 [11]

    驗證檢視學期成績單使用案例 [12]

    驗證課程登錄使用案例 [8]

    驗證選取執教課程使用案例 [9]

    增補規格 4.1 節:「應記載所有的系統錯誤。嚴重的系統錯誤應導致系統依序關機」。

    增補規格 4.1 節:「系統錯誤訊息應包含錯誤的文字說明、 系統錯誤碼(如果適用的話)、偵測錯誤狀況的模組、 資料戳記,以及時間戳記。所有的系統錯誤都應保留在「錯誤日誌資料庫」中」。

    願景文件 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 大型電腦上運作的現有「課程帳單結算系統」整合」。

    企業週期測試

驗證下載新的課程型錄之後的作業。

驗證跨多個學期及多年的作業。

驗證學期跨越年度輪替時是否正確運作。

    使用者介面測試

    驗證可透過一個範例畫面集輕易導覽。

    驗證範例畫面符合 GUI 標準。

    願景文件第 10 節:「系統應易於使用,並且應適用於具備電腦素養的學生和教授的目標市場」。

    願景文件 12.1 節:「桌面使用者介面應與 Windows 95/98 相容」。

    增補規格 5.1 節:「桌面使用者介面應與 Windows 95/98 相容」。

    增補規格 5.2 節:「「課程登錄系統」的使用者介面應設計為易於使用,並且應適用於具備電腦素養的使用者群組,而無需系統的額外訓練」。

    增補規格 5.3 節:「「課程登錄系統」的每一項特性都應備有供使用者使用的內建線上說明。「線上說明」應包含有關使用系統的逐步指示。「線上說明」應包含詞彙及字首語的定義」。

    效能測試

    驗證存取外部「財務」系統的回應時間。

    驗證存取外部「課程型錄」子系統的回應時間。

    驗證遠端登入的回應時間。

    驗證遠端送出課程登錄的回應時間。

    願景文件 12.3 節:「系統應提供對舊版「課程型錄資料庫」的存取權,且延遲時間為 10 秒或以下」。

    增補規格 7.2 節:「系統應提供對舊版「課程型錄資料庫」的存取權,且延遲時間為 10 秒或以下」。

    負荷量測試

    驗證負荷了 200 位登入的學生時的系統回應。

    驗證 50 位學生同時存取「課程型錄」時的系統回應。

    增補規格 7.2 節:「系統應支援可以同時有 2000 位使用者在任何給定的時間存取中央資料庫,以及最多可以同時有 500 位使用者在任何時間存取本端伺服器」。

    壓力測試

    驗證 UNIX 伺服器的主要使用期間的系統回應。

    驗證最多學生登入期間的系統回應。

    容量測試

    驗證「課程型錄資料庫」的容量為 90% 時的系統回應。

    安全及存取控制測試

    驗證從本端 PC 登入。

    驗證從遠端 PC 登入。

    驗證透過使用者名稱和密碼機制的登入安全。

    增補規格 4.2 節:「所有的功能都應可從遠端透過網際網路連線存取」。

    失效接手 / 回復測試

    增補規格 6.1 節:「「課程登錄系統」應 24 小時全年無休以提供服務。懸置時間不應超過 4%」。

    增補規格 6.2 節:「「平均失效時間」應超過 300 個小時」。

    配置測試

    願景文件 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 執行時期環境相容。」

    安裝測試

    增補規格 8.1 節:「「課程登錄」之 PC 用戶端部分的升級版本應可透過網際網路從 UNIX 伺服器下載」。

    驗證伺服器部分的安裝。

    驗證用戶端部分的安裝。

5、測試策略

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

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

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

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

    1. 測試類型

1、資料和資料庫完整性測試

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

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

2、系統測試

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

 

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

3、企業週期測試

「企業週期測試」應模擬在系統上經過一段時間所執行的活動。應識別期間(如一年),並且應執行會在一年期間發生的交易和活動。這包括所有日期緊密的每日、每週、每月的週期和事件,如備忘錄。

 

測試目標 確定應用程式及背景處理流程按照必要的企業模型和排程適當運作。
方法:
  • 測試將會執行下列動作來模擬數個企業週期:
  • 將會修改 / 加強進行應用程式功能測試所用的測試來增加每一個功能執行的次數,以模擬在指定期間的數位不同的使用者。
  • 將使用有效及無效的日期或時段,執行所有時間或日期緊密的功能。
  • 將在適當的時間執行 / 啟動按定期排程進行的所有功能。
  • 測試將包括使用有效及無效的資料來驗證下列各項:
  • 使用有效的資料時發生預期的結果。
  • 使用無效的資料時會顯示適當的錯誤 / 警告訊息。
  • 適當地套用了每一個企業規則。
完成標準:
  • 已執行所有規劃的測試。
  • 已處理所有識別出的問題。
特殊考量:
  • 系統日期和事件可能需要特殊的支援活動
  • 需要企業模型來識別適當的測試需求和程序。

4、使用者介面測試

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

 

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

5、效能測試

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

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

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

 

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

- 正常參與的容量

- 參與較差情況的容量

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

6、負荷量測試

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

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

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

7、壓力測試

壓力測試是為了要找出由於資源不足或資源競爭所導致的錯誤。記憶體或磁碟空間不足可以揭露軟體在正常狀況下並不明顯的問題。 共用資源(像是資料庫鎖定或網路頻寬)的競爭可能導致其他的問題。壓力測試識別系統可以處理的尖峰負荷量。

附註:以下所指的交易是指邏輯企業交易。

測試目標: 確認系統及軟體功能在下列壓力狀況下,能夠適當運作且沒有錯誤:
  • 伺服器上可用的記憶體很少或沒有(RAM 和 DASD)
  • 連接(或模擬)了最大用戶端數(實際或實體上可行)
  • 多位使用者針對相同的資料 / 帳戶執行相同的交易
  • 最壞情況的交易量 / 混合(請參閱上述的效能測試)。

附註:壓力測試的目標也可以描述為識別及記載一些狀況,在這些狀況下,系統無法繼續適當運作。

方法:
  • 使用針對「效能測試」所開發的測試。
  • 若要測試有限資源,則測試應在單一機器上執行,並且應縮減(或限制)伺服器上的 RAM 和 DASD。
  • 針對其餘的壓力測試,應使用多個用戶端,執行相同的測試或補充測試來產生最壞情況的交易量 / 混合。
完成標準: 已執行所有規劃的測試,並達到 / 超過指定的系統限制,而沒有發生軟體失效(或是發生的系統失效超出指定狀況的狀況)。
特殊考量:
  • 對網路加壓可能需要使用網路工具,以訊息 / 封包載入網路。
  • 應暫時縮減用於系統的 DASD,以限制可供資料庫擴充的空間。
  • 多個用戶端同時存取相同記錄 / 資料帳戶的同步化。

8、容量測試

「容量測試」會讓系統承載大量的資料,以判定是否已達到導致系統失效的限制。容量測試並識別系統可以處理達一段給定期間的連續最大負荷量或容量。比方說,如果軟體處理一組資料庫記錄以產生報告,則「容量測試」會使用大型的測試資料庫,並檢查軟體的運作是否正常以及產生的報告是否正確。

測試目標: 驗證應用程式 / 系統在下列高容量實務下是否順利運作:
  • 連接(或模擬)了最大用戶端數(實際或實體上可行),而這些用戶端全部都執行相同的、最壞情況(效能)的企業功能達一段較長的期間。
  • 已達到資料庫大小上限(實際上或是按比例),並且同時執行了多個查詢 / 報告交易。
方法:
  • 使用針對「效能測試」所開發的測試。
  • 應使用多個用戶端,執行相同的測試或補充測試來產生最壞情況的交易量 / 混合(請參閱上述的壓力測試)達一段較長的期間。
  • 建立最大資料庫大小(實際上、按比例的,或是填入代表性的資料),並且使用多個用戶端來同時執行查詢 / 報告交易達一段較長的時期。
完成標準: 已執行所有規劃的測試,並達到 / 超過指定的系統限制,而沒有發生軟體失效。
特殊考量:
  • 會考量哪一段時期為高容量狀況的可接受時間(如以上所述)?

9、安全和存取控制測試

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

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

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

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

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

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

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

10、失效接手 / 回復測試

失效接手 / 回復測試是要確定應用程式或整個系統可以順利地從各式各樣的硬體、 軟體或網路失效(帶有不當的資料或資料完整性流失)中,失效接手或回復。

失效接手測試是要確定,針對那些必須保持執行的系統,當失效接手狀況發生時,替代或備用系統能適當地「接管」失敗的系統,而不會流失資料或交易。

回復測試是一種對抗測試流程,其中應用程式或系統暴露在極端的狀況(或模擬狀況)下,像是裝置 I/O 失效或資料庫指標 / 鍵無效。會呼叫回復程序,並且會監視和(或)視察應用程式 / 系統來確認已達到適當的應用程式 / 系統 / 和資料回復。

測試目標: 驗證回復流程(以手動或自動方式)適當地將資料庫、 應用程式和系統還原至理想的、已知的狀態。測試中要包含下列類型的狀況:
  • 用戶端電源岔斷
  • 伺服器電源岔斷
  • 透過網路伺服器的通訊岔斷
  • DASD 和(或)DASD 控制器的岔斷、通訊或電源流失
  • 週期不完整(資料過濾流程遭岔斷、資料同步化流程遭岔斷)。
  • 資料庫指標 / 鍵無效
  • 資料庫中的資料元素無效 / 毀損
方法: 應使用針對「應用程式功能」及「企業週期」測試所建立的測試來建立一系列的交易。在達到後所要的測試起點之後,應個別執行(或模擬)下列動作:
  • 用戶端電源岔斷:關閉 PC 電源
  • 伺服器電源岔斷:模擬或起始伺服器的關閉電源程序
  • 透過網路伺服器岔斷:模擬或起始網路通訊流失(實際切斷通訊線或關閉網路伺服器 / 路由器的電源)。
  • DASD 和(或)DASD 控制器的岔斷、通訊或電源流失: 模擬或實際消除與一或多個 DASD 控制器或裝置的通訊。

在達到上述的狀況 / 模擬狀況之後,應執行其他的交易,而在到達這第二個測試點狀態時,應呼叫回復程序。

不完整週期的測試利用上述的相同方法,不過應中止或提早終止資料庫流程本身。

需要先達到已知的資料庫狀態,才能進行下列狀況的測試。應在資料庫內直接手動毀損數個資料庫欄位、 指標和鍵(透過資料庫工具)。應已使用「應用程式功能」及「企業週期測試」中的測試來執行其他的交易,並且已執行完整的週期。

完成標準: 在上述的所有案例中,應用程式、資料庫及系統應在回復程序完成時,回到已知的理想狀態。這種狀態包括資料的毀損限於已知的毀損欄位、指標 / 鍵,以及報告指出流程或交易由於岔斷而未完成。
特殊考量:
  • 回復測試具有高度侵害性。切斷接線連接(模擬電源或通訊流失)可能並不理想或不可行。可能需要替代的方法,例如診斷軟體工具。
  • 需要來自「系統」(或「電腦作業」)、「資料庫」及「網路作業」等群組的資源。
  • 這些測試應在幾小時後或在隔離的機器上執行。

11、配置測試

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

 

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

12、 安裝測試

安裝測試有兩個目的。第一個目的是確定軟體可以安裝在所有可能的配置上(例如,新的安裝、 升級,以及完整安裝或自訂安裝),並且在正常及異常狀況的狀況下都可以安裝。異常狀況包括磁碟空間不足、 缺乏建立目錄的專用權等等。第二個目的是要確認軟體在安裝之後能夠正確運作。這通常表示執行若干個針對「功能」測試所開發的測試。

 

測試目標: 驗證及檢驗用戶端軟體在下列狀況下適當安裝到每一個用戶端上:
  • 新機器進行新的安裝,從未安裝過。
  • 更新先前安裝了相同版本的機器
  • 更新先前安裝了較舊版本的機器
方法:
  • 以手動方式或開發自動化 Script 來檢驗目標機器的狀況(新的 - 從未安裝、已安裝相同的或較舊的版本)。
  • 啟動 / 執行安裝。
  • 使用預定的「整合」或「系統」測試 Script 子集,執行交易。
完成標準: 順利執行交易,沒有任何失敗。
特殊考量:
  • 應選取哪些交易以組成信心測試(順利安裝應用程式,且沒有遺失主要軟體元件)?

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

6、資源

    本節呈現用於測試「課程登錄系統」的建議資源、 它們的主要責任,以及它們的知識或技能集。

    1. 工作者

此表格顯示測試作業的人員配置假設。

人力資源

工作者

建議的資源下限

(已配置為專職的工作者數)

特定的責任/意見

測試管理人員 1 - Kerry Stone 提供管理監督

責任:

  • 提供技術指示
  • 獲取適當的資源
  • 管理報告
測試設計師 Margaret Cox

Carol Smith

Sophie King

識別、優先順序化及實作測試案例

責任:

  • 產生測試計劃
  • 產生測試套組
  • 評估測試作業的效用
系統測試人員 Carol Smith

Sophie King

Adrian Harmsen

執行測試

責任:

  • 執行測試
  • 記載結果
  • 回復錯誤
  • 文件問題
測試系統管理人員 Simon Jones 確認測試環境和資產受到管理及維護。

責任:

  • 管理測試管理系統
  • 安裝 / 管理對測試系統的工作者存取權
資料庫管理 / 資料庫管理人員 Margaret Cox 確認測試資料(資料庫)環境和資產受到管理及維護。

責任:

  • 管理測試資料(資料庫)
設計師 Margaret Cox 識別及定義測試類別的作業、屬性和關聯

責任:

  • 識別及定義測試類別
  • 識別及定義測試套件
實作人員 Margaret Cox

Adrian Harmsen

實作及單元測試測試類別和測試套件

責任:

  • 建立及測試在「測試套組」中實作的類別和套件。

2、系統

下表說明用於測試「課程登錄系統」的系統資源。

系統資源

資源

名稱 / 類型 / 序號

Wylie College Server 序號:X179773562b
  課程型錄資料庫 版本 Id:CCDB-080885
  帳單結算系統 版本 Id:BSSS-88335
用戶端測試 PC
 
  10 部遠端 PC(具備網際網路存取權) 序號:A8339223

序號:B9334022

序號:B9332544

<7 TBD>

  6 部本端 PC(透過 LAN 連接) 序號:R3322411(登錄人員)

序號:A8832234(IT 實驗室)

序號:W4592233(IT 實驗室)

序號:X3333411(教職員辦公室)

序號:A987344(科學實驗室)

序號:X9834000(學生活動中心)

測試儲存庫
 
  Wylie College Server 序號:X179773562b
測試開發 PC - 6 序號:A8888222

序號:R3322435

序號:I88323423

序號:B0980988

序號:R3333223

序號:Y7289732

載入模擬器 序號:ABC-123

 

 

7、專案里程碑

    測試活動和里程碑極度取決於開發反覆。「建構階段」將會分成 3 個反覆。每一個反覆都包含測試的規劃、 設計、開發、執行及評估的完整測試週期。

    請參閱軟體開發計劃 [14] 及「反覆計劃」,以取得顯示開發反覆的主要排程和「建構階段」計劃。

    下表顯示「測試里程碑」。投入成本、開始日期和結束日期可以在規劃反覆內容時完成。

    里程碑作業 工作 (pd) 開始日期 結束日期
    反覆 C1:測試版

    測試規劃

    測試設計

    測試開發

    測試執行

    測試評估

    TBD 3 月 15 日 4 月 12 日
    反覆 C2:R1.0 版

    測試規劃

    測試設計

    測試開發

    測試執行

    測試評估

    TBD 4 月 13 日 5 月 14 日
    反覆 C3:R2.0 版

    測試規劃

    測試設計

    測試開發

    測試執行

    測試評估

    TBD 5 月 15 日 6 月 17 日

     

8、工作成果

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

    請注意,這其中的部分工作成果產生了多次;每一個測試週期或反覆產生一次。其他的工作成果(如「測試計劃」)則會在每一個開發反覆時更新。

    工作成果 擁有者 審查 / 分送 到期日
    測試計劃 K. Stone 資深專案管理團隊 3 月 28 日
    測試環境 S. Jones - 3 月 28 日
    測試套組 C. Smith 和 M. Cox 內部同儕審查 3 月 28 日
    測試聚集 M. Cox 內部同儕審查 3 月 31 日
    測試 Script M. Cox - 4 月 2 日
    測試 Stub、驅動程式 M. Cox - 4 月 4 日
    測試問題報告 C. Smith 資深專案管理團隊 TBD
    測試結果 C. Smith 測試管理人員 TBD
    測試評估報告 C. Smith 資深專案管理團隊 TBD

     

1、測試套組

      「測試套組」將定義所有的測試案例以及與各個測試案例相關聯的測試 Script。

2、測試日誌

已規劃使用 RequisitePro 來識別測試案例及追蹤每一個測試案例的狀態。測試結果將會彙總在 RequisitePro 中,分為未測試、已通過、有條件通過或失敗。在摘要中,將會設定 RequisitePro 來支援每一個測試案例的下列屬性,如需求屬性準則 [16] 中所定義:

    • 測試狀態
    • 建置號碼
    • 測試人員
    • 測試日期
    • 測試附註

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

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

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

9、專案作業

以下是測試「課程登錄系統」的測試相關作業:

 

規劃測試

識別測試的需求

評定風險

開發測試策略

識別測試資源

建立排程

產生測試計劃

設計測試

工作量分析

開發測試套組

識別及說明測試案例

識別及結構化測試 Script

審查及存取測試涵蓋面

實作測試

設定測試環境

記錄或程式化測試 Script

開發測試 Stub 和驅動程式

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

建立外部聚集

執行測試

執行測試 Script

評估測試的執行

回復中止的測試

驗證結果

探索非預期的結果

記載問題

評估測試

評估測試案例涵蓋面

評估程式碼涵蓋面

分析問題

判定是否已達成「測試完成標準」及「順利完成標準」

建立測試評估報告

 

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

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