開發與測試：確保我們的資訊及通訊科技（ICT）系統真正運作順暢！（課程綱要第 7.3 節）
各位未來的 ICT 專家，大家好！歡迎來到系統生命週期中最關鍵的階段：開發與測試（Development and Testing）。想像系統開發就像烤一個複雜的蛋糕。分析階段是挑選食材，設計階段是撰寫食譜，而開發階段則是實際把它烤出來。
但在端出蛋糕（執行實施）之前，您必須先「試吃」（測試）！它烤熟了嗎？味道對嗎？會不會散掉？在 ICT 中，測試就是我們在系統交給真實用戶使用前，找出並修復所有錯誤（程式臭蟲/Bug）的過程。讓我們深入探討如何打造穩固、可靠且零錯誤的 ICT 系統。
1. 測試的必要性
為什麼我們必須費心進行測試？課程綱要明確指出：在系統實施前必須進行測試。
為什麼測試是不可或缺的：
• 捕捉錯誤（Bug）：所有程式都有錯誤。測試能在這些錯誤對用戶或機構造成嚴重後果前，將其找出來。
• 確保符合需求：測試能確認新系統的運作是否與客戶在分析階段提出的要求完全一致。
• 系統可靠性：經過嚴格測試的系統，在上線後較不容易當機或產生錯誤數據。
• 建立用戶信心：如果系統從第一天就運作完美，用戶會立即信任它。
您知道嗎？ 1996 年亞利安 5 號火箭（Ariane 5）因軟體錯誤導致價值 3.7 億美元的失敗，追溯源頭竟是軟體中一段未以極端數據進行測試、未受處理的數據轉換錯誤。記得一定要測試！
快速複習：測試的目的
測試的主要目的很簡單：確保系統產生的實際輸出結果（Actual Outcomes）與設計階段定義的預期輸出結果（Expected Outcomes）完全吻合。如果不一致，我們就要修復錯誤！
2. 測試策略與範疇
您無法一次測試所有東西。課程綱要指明了測試策略的三個關鍵層次：
測試每個模組（單元測試，Unit Testing）
此策略涉及將系統的每個個別部分、組件或「模組」拆開來進行獨立測試。
• 什麼是模組？一個獨立的程式碼區塊或子系統，例如資料庫資料表結構、單一表單或計算子程序。
• 優點：處理一小段程式碼時，更容易隔離並找出錯誤的確切來源。
類比：如果您正在建造一座樂高城堡，模組測試就是在將所有牆壁組合在一起之前，先確認每一小段牆面都組裝正確。
測試每個功能（Testing Each Function）
此策略會檢查系統中的每一項特定功能或操作運作，以確保它準確執行其預期工作。
• 什麼是功能？一項特定任務或操作能力，例如搜尋客戶記錄、計算總銷售稅、列印收據或驗證密碼。
• 目的：驗證客戶指定的每項獨立需求在觸發時是否都能產生預期輸出。
測試整個系統（整合測試，Integration Testing）
當所有模組與個別功能都能單獨正常運作後，我們就要測試整個系統如何協同運作。
• 這能確認數據是否能正確地從一個模組與功能流向另一個（例如：輸入表單能否成功將輸入的詳細資料傳輸至資料庫結構中並產生摘要報告）。
• 這提供了全面的測試，確保所有部分在真實環境條件下作為一個統一系統協同運作。
重點總結：測試策略的進程：測試每個模組 → 測試每個功能 → 測試整個系統。
3. 設計測試計劃
測試計劃（Test Plan）是一份正式文件，詳述了將要執行的每一項測試。它確保測試過程是有結構、完整的，並為補救措施（Remedial Action，即修復問題的方法）提供明確步驟。
良好測試計劃的組成要素：
對於每個測試案例（Test Case），您必須定義四個關鍵要素：
1. 測試數據（Test Data）：您將輸入系統的數據（輸入項）。
2. 預期結果（Expected Outcomes）：系統應該產生的結果。這是預先手動計算或預測出來的。
3. 實際結果（Actual Outcomes）：輸入測試數據後，系統實際產生的結果。
4. 測試後的補救措施（Remedial Action Following Testing）：若實際結果與預期結果不符時所採取的行動（例如：「調整驗證程序」或「檢查檔案結構定義」）。
記憶小撇步：您可以將測試計劃記為 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）
特性：數據是有效的，但剛好位於可接受範圍的上限或下限（邊界）。
用途：確保系統能正確處理邊界條件。程式設計師常會犯邊界比較錯誤（例如誤用 < 而非 <=）。極端數據能抓出這種錯誤。
範例：如果年齡範圍是 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 / Character Check）：確保數據僅包含允許的字元（例如：電話號碼中僅限數字）。
• 長度檢查（Length Check）：確保輸入項具有精確或允許的字元數量。
• 存在檢查（Presence Check）：防止關鍵欄位被留空。
• 格式檢查（Format Check）：確認數據符合預定的模式（例如：郵遞區號的 LLNN NLL）。
• 核對碼（Check Digit）：透過重新計算校驗和來驗證數字代碼（例如條碼或 ISBN）。
重點總結：開發與測試是密不可分的。您開發一小部分，然後使用正常、極端和異常數據徹底測試它。一份結構化的測試計劃，就是通往成功、零臭蟲系統上線的路線圖！