開發與測試：確保您的資訊及通訊科技（ICT）系統運作順暢！（課程綱要第 7.3 節）
各位未來的 ICT 專家，大家好！歡迎來到系統生命週期中最關鍵的階段：開發與測試（Development and Testing）。想像系統開發就像烤一個複雜的蛋糕：分析階段是挑選食材，設計階段是撰寫食譜，而開發階段則是實際把它烤出來。
但在端出蛋糕（執行實施）之前，您必須先「試吃」（測試）！它烤熟了嗎？味道對嗎？會不會散掉？在 ICT 中，測試就是我們在系統交給真實用戶使用前，找出並修復所有錯誤（程式臭蟲/Bug）的過程。讓我們深入探討如何打造穩固、可靠且零錯誤的 ICT 系統。
1. 測試的必要性
為什麼我們必須費心進行測試？課程綱要明確指出：在系統實施前必須進行測試。
為什麼測試是不可或缺的：
- 捕捉錯誤（Bug）：所有程式都有錯誤。測試能在這些錯誤對用戶或機構造成嚴重後果前，將其找出來。
- 確保符合需求：測試能確認新系統的運作是否與客戶在分析階段提出的要求完全一致。
- 系統可靠性：經過嚴格測試的系統，在上線後較不容易當機或產生錯誤數據。
- 建立用戶信心：如果系統從第一天就運作完美，用戶會立即信任它。
您知道嗎？ 1996 年亞利安 5 號火箭（Ariane 5）因軟體錯誤導致價值 1,860 萬美元的失敗，追溯源頭竟是一小段程式碼未經過極端數據的正確測試。記得一定要測試！
快速複習：測試的目的
測試的主要目的很簡單：確保系統產生的實際輸出結果（Actual Outcomes）與設計階段定義的預期輸出結果（Expected Outcomes）完全吻合。如果不一致，我們就要修復錯誤！
2. 測試策略與範疇
您無法一次測試所有東西。我們會根據開發階段的不同，使用不同的測試策略。
單元測試（Unit Testing）
此策略涉及將系統的每個小部分或「模組」拆開來進行獨立測試。
- 什麼是模組？它可以是一個視窗畫面、一個計算程序，或是某個特定功能（例如「登入」功能）。
- 優點：由於您每次只測試一小段程式碼，因此更容易找出錯誤的確切位置。
類比：如果您正在建造一座樂高城堡，單元測試就是在將所有牆壁組合在一起之前，先確認每一小段牆面都組裝正確。
整合測試（Integration Testing）
當所有模組都能單獨運作後，我們就要測試它們如何相互配合。
- 這能確認數據是否能正確地從一個模組流向另一個模組（例如：數據輸入表單能否正確地將用戶資料傳輸到數據庫架構中）。
- 這是一項更全面的測試，確保所有功能作為一個整體來運作。
重點總結：先測試個別零件（模組），再測試成品（整個系統）。
3. 設計測試計劃
測試計劃（Test Plan）是一份正式文件，詳述了將要執行的每一項測試。它確保測試過程是有結構、完整的，並為補救措施（Remedial Action，即修復問題的方法）提供明確步驟。
良好的測試計劃包含什麼？
對於每個測試案例（Test Case），您必須定義四個關鍵要素：
- 測試數據（Test Data）：您將輸入系統的數據。
- 預期結果（Expected Outcomes）：系統「應該」產生的結果。這是預先手動計算或預測出來的。
- 實際結果（Actual Outcomes）：輸入測試數據後，系統「實際」產生的結果。
- 測試後的補救措施（Remedial Action）：若實際結果與預期結果不符時所採取的行動（例如：「調整驗證程序」或「檢查檔案結構定義」）。
記憶小撇步：您可以將測試計劃記為 T.E.A.R.：Test Data（測試數據）、Expected Outcome（預期結果）、Actual Outcome（實際結果）、Remedial Action（補救措施）。
4. 測試數據的類型：尋找極限
為了適當檢查系統，特別是其驗證程序，我們必須使用不同類型的數據。
4.1 正常數據（Normal Data）
特性：數據是有效的，且在指定的合理限制（範圍）內。
用途：檢查系統是否能準確處理標準、正確的輸入。
範例：如果表單要求年齡在 16 到 60 之間，正常數據可以是 35。
4.2 極端數據（Extreme Data / Boundary Data）
特性：數據是有效的，但剛好位於可接受範圍的上限或下限（邊界）。
用途：確保系統能正確處理邊界條件。程式設計師常會犯「誤差為 1（off-by-one）」的錯誤（例如誤用 < 而非 <=）。極端數據能抓出這種錯誤。
範例：如果年齡範圍是 16 到 60，極端數據就是 16 和 60。
4.3 異常數據（Abnormal Data / Invalid Data）
特性：數據是無效的，理應被系統的驗證檢查拒絕。這包括超出範圍的數據、錯誤的數據類型或格式錯誤。
用途：測試系統驗證程序和錯誤訊息的穩固性。我們測試系統是否能阻擋壞數據進入。
範例：
- 超出範圍： 年齡 5 歲或 75 歲。
- 類型錯誤： 在數字年齡欄位輸入文字「Thirty-Five」。
- 長度不符： 要求十位數的手機號碼卻只輸入兩位數。
常見錯誤警示！
請勿混淆極端數據（有效的且會被接受）與範圍邊界之外的數據（異常的且會被拒絕）。
如果範圍是 10 到 20：
• 正常：15
• 極端：10, 20
• 異常：9, 21, "cat"
4.4 使用真實數據（Live Data）
在測試階段的後期，特別是如果從舊系統遷移數據時，您可能會使用真實數據（Live Data）。
定義：這是曾經由既有（舊）系統處理過的真實數據。
用途：它提供了高度真實的測試環境，因為它模擬了系統正式運作時會遇到的數據量、多樣性和複雜性。
注意：使用真實數據時，必須確保新系統的運作不會影響舊系統的運行，也不會損毀真實且寶貴的數據。這通常在「平行運作」（Parallel Running，一種實施方式，將於下一節介紹）期間進行。
5. 測試特定的系統元件
您的測試計劃必須確保您特別測試了在上一階段設計的組件：
測試數據結構與檔案結構
這能確保數據庫或檔案設定正確。您必須檢查：
- 欄位長度（Field lengths）是否合適（例如：姓名欄位夠長嗎？）？
- 數據類型（Data types）是否正確（例如：「價格」是否設定為貨幣/小數欄位？）？
- 主鍵（Primary Keys）與外鍵（Foreign Keys）是否能正確維持資料表之間的關係？
測試輸入與輸出格式
這是關於檢查系統面向用戶的部分。
- 輸入格式：檢查數據錄入表單是否易於使用，並包含所有必要的欄位。
- 輸出格式：檢查報告、螢幕佈局和發票是否能正確列印或顯示，資訊是否正確且對齊良好。
測試驗證程序（Validation Routines）
正如測試數據部分所述，您必須系統化地檢查所有驗證程序是否運作完美，包括：
- 範圍檢查（Range Check）：它是否確保數據在限制範圍內？
- 類型檢查（Type Check）：它是否確保數據為正確格式（例如：只能是數字）？
- 存在檢查（Presence Check）：它是否阻止用戶遺漏必填欄位？
- 核對碼/核對總和（Check Digit/Sum）：它是否能偵測到意外的數據錄入錯誤？
重點總結：開發與測試是密不可分的。您開發一小部分，然後使用正常、極端和異常數據徹底測試它。一份結構化的測試計劃，就是通往成功、零臭蟲系統上線的路線圖！