程式測試是「檢查」：以不同輸入執行程式，核對輸出是否符合規格，目標是盡早發現錯誤。
除錯是「修正」：在已知有錯的情況下，追蹤程式在某一行／某一步出現偏差的原因，並修改程式使其回到正確軌道。
- 測試回答：結果是否正確？
- 除錯回答：錯在哪裡？為甚麼會錯？如何改？
6.1 測試與除錯概觀
本節重點在於分清「程式測試」與「除錯」的角色，以及理解它們如何配合，逐步提升程式的正確性與可靠性。
- 程式測試：用事先設計的測試數據執行程式，並把實際輸出與預期輸出作比較，以發現錯誤。
- 除錯：當測試顯示有錯時，追蹤程式的執行流程與變量狀態，找出錯因並修改程式，再重複測試直至修正。
- 核心觀念：測試用來「揭示錯誤」；除錯用來「定位及修正錯誤」。兩者缺一不可。
重點摘要
- 理解：測試 ≠ 除錯；測試用來比對輸出，除錯用來追蹤原因並修正。
- 掌握：由規格 → 測試個案 → 執行 → 記錄 → 修正 → 再測試的完整流程。
- 作答技巧：答案要寫到「測試數據」「預期輸出」「實際輸出」「邊界情況」等關鍵字。
- 目的：提升信心、揭示錯誤、驗證是否符合規格（例如輸入範圍、輸出格式）。
- 限制：測試能證明「程式有錯」，但不能證明「程式永遠不會錯」。因此需要設計多角度的測試數據。
- 關鍵：測試不是隨機輸入，而是有策略地覆蓋正常、邊界與無效情況。
在考試或作業中，建議把測試寫成「測試個案」形式，清楚列出：
| 元素 | 內容 | 作用 |
|---|---|---|
| 輸入（測試數據） | 例如：50 | 指定測試條件 |
| 預期輸出 | 例如：及格 | 用規格推算的正確結果 |
| 實際輸出 | 程式執行後得到的結果 | 用來判斷是否通過 |
只寫「我試過幾個數」通常不夠；要寫到「為甚麼選這些數（例如邊界值）」。
- 閱讀題目規格（例如輸入限制、輸出格式、特殊情況）。
- 設計測試數據：包括正常、邊界、無效及（如適用）真實數據。
- 逐一執行程式並記錄實際輸出。
- 把實際輸出與預期輸出比較，判斷通過／不通過。
- 若不通過，進入除錯；修正後再進行回歸測試，確保新改動沒有引入新錯誤。
- 重現：用同一組輸入重做一次，確認錯誤可重複出現。
- 定位：找出出錯位置（例如報錯行號、追蹤表、逐行檢查變量）。
- 推斷成因：判斷是條件、循環、變量更新或資料型別問題。
- 修正：一次只改一個地方，避免同時改太多而難以追蹤效果。
- 再測試：用原本令它出錯的輸入＋其他關鍵測試數據再測一次。
- 定義題：用一句完整句子描述，並包含「測試數據」「預期／實際輸出」或「追蹤／修改程式」等字眼。
- 情境題：指出應先測試還是先除錯；若已知輸出錯但程式能運行，通常先做除錯。
- 改進題：建議加入更多測試個案（尤其邊界與無效數據），以及加入輸入驗證。
- 只測一兩個「正常值」就判斷程式正確。
- 修正後沒有再測試，導致同一錯誤或新錯誤仍然存在。
- 沒有把「預期輸出」寫清楚，令測試結果難以判斷。
程式測試的定義
程式測試：使用預先設計的測試數據執行程式，並把實際輸出與預期輸出作比較，以檢查程式是否符合要求並發現錯誤。
除錯的定義
除錯：根據測試結果，追蹤程式的執行流程，找出錯誤成因並修改程式；通常需要重複「發現錯誤 → 分析 → 修改 → 再測試」。
互動：分辨「測試」或「除錯」
請按「下一題」開始。每題會描述一個行動，請判斷它屬於「程式測試」還是「除錯」。
作答提示： 「程式測試是使用預先設計的測試數據執行程式，並比較實際輸出與預期輸出，以檢查結果是否正確及揭示錯誤； 除錯是追蹤程式的執行流程並修改程式，以找出及更正錯誤。」
6.2 程式錯誤類型
程式錯誤有下列錯誤類型：
- 語法錯誤：違反語言文法規則，直譯器無法開始執行程式（例如漏冒號、縮排不正確、括號不配對）。
- 運行時錯誤：程式開始執行後，在某一步才出現錯誤並中止（例如 ZeroDivisionError、IndexError）。
- 邏輯錯誤：程式可以順利執行完畢，但演算法或條件設計不當，導致輸出不符合預期。
重點摘要
- 快速判斷：不能執行 → 多為語法錯誤；執行途中崩潰 → 多為運行時錯誤；能跑完但結果錯 → 多為邏輯錯誤。
- 閱讀錯誤訊息：留意錯誤類型與行號，配合追蹤變量更容易定位問題。
- 語法錯誤：程式無法開始執行，通常一按「執行」就立即報錯。
- 運行時錯誤：程式起初能跑，但在某一步因不合法操作而中止（例如除以 0、索引超界）。
- 邏輯錯誤：程式能跑完並輸出結果，但結果與題意／預期不符。
- 漏冒號（如 if、for、while 行尾）。
- 縮排層級錯誤（同一區塊必須對齊）。
- 括號、引號未配對。
處理方法：根據報錯行號，先檢查該行及其上一行的語法（例如缺少符號常在上一行）。
- 除以 0：計算前先檢查分母是否為 0。
- 索引超界：使用清單／字串前先確認長度；循環範圍要正確。
- 型別不匹配：輸入資料需轉換型別；運算前確保資料型別正確。
預防方法：加入輸入驗證（例如檢查範圍、格式）及適當的條件判斷。
邏輯錯誤通常不會「報錯」，只能靠測試發現結果不對。常見來源包括：
- 條件判斷寫反（>／>= 混淆）。
- 循環次數少一次或多一次（邊界處理不當）。
- 更新了錯誤的變量（例如應加 i 卻加了常數）。
處理方法：使用追蹤表逐步寫出變量值，或在關鍵位置輸出變量以檢查流程。
- 錯誤訊息通常包含錯誤類型（例如 IndexError）及出錯行號。
- 閱讀時可由最後一行開始看錯誤類型，再回到上方找出是哪一行引致錯誤。
- 定位後，檢查該行使用的變量在當刻是否合理（例如索引值是否超界）。
- 把程式拆成小步驟（分段測試），更容易找出問題位置。
- 先處理「會令程式停機」的語法／運行時錯誤，再處理邏輯錯誤。
- 修正後要做回歸測試：重新測試之前成功的個案，確保沒有引入新錯誤。
例子：三種常見錯誤
以下例子會在小測之中再次練習。
例 1：語法錯誤
for i in range(5)
print("你好")
目的：輸出 5 次「你好」。
問題：for 行尾漏了冒號，Python 會報 SyntaxError。
例 2：運行時錯誤
numbers = [3, 5, 9]
print(numbers[3])
目的：輸出清單中的某個元素。
問題：合法索引只有 0、1、2；numbers[3] 會觸發 IndexError。
例 3：邏輯錯誤
total = 0
for i in range(1, 11):
total = total + 2
print(total)
目的：計算 1 + 2 + … + 10。
問題：每次只加 2，而不是加 i；程式能執行完畢，但結果錯誤。
小測 1：看 Python 程式碼，判斷錯誤類型
每題會先交代程式「原本想做到的效果」，再提供一段含錯誤的 Python 程式碼，請判斷屬於哪一類錯誤。
互動：判斷錯誤類型（語法／運行時／邏輯）
請按「下一題」開始。請留意：題目會先說明目的，再顯示含錯誤的程式碼。
6.3 測試數據設計與數據驗證
本節重點在於：如何設計有代表性的測試數據，以及如何在程式中加入數據驗證，避免不合理輸入引致錯誤或不正確輸出。
- 能應用數據驗證檢查去設計適當的測試數據，尤其是邊界情況。
- 能分辨正常數據／邊界數據／無效數據四類測試數據。
重點摘要
- 設計測試數據不是「隨便試幾個」，而是要有系統地覆蓋正常值、邊界值與無效輸入。
- 數據驗證的目的：在程式處理前先把不合理輸入擋走，避免出錯或產生不可靠結果。
- 要點：每個測試個案都要寫出「輸入」「預期輸出」及其屬於哪一類測試數據。
- 對應規格：先讀清楚題目要求，例如輸入範圍、允許的格式、特別情況（如空值）。
- 覆蓋情況：至少包括正常數據、邊界數據與無效數據；如題目提到真實數據來源，可加入實際數據。
- 可判斷：每個測試都要能推算預期輸出，否則測試結果無法判斷對錯。
- 正常數據：落在合法範圍內、具代表性的典型值。
- 邊界數據：貼近合法範圍邊界的值（例如最小值、最大值及其附近）。
- 無效數據：超出範圍或不符合格式的輸入（例如負數、不合理字串）。
- 實際數據：真實收集得到的資料（例如上一年實際成績清單）。
若輸入範圍是 0–100，邊界值通常包括：
- 最小值：0
- 最小值附近：1
- 最大值附近：99
- 最大值：100
邊界值最容易暴露「> / >=」等條件錯誤或循環次數多／少一次的問題。
把輸入按性質分成幾組「等價類別」，每組選一個代表值測試即可。例如：
- 0–49（不及格）
- 50–100（及格）
- < 0 或 > 100（無效）
- 範圍檢查：數值是否在允許範圍內（例如 0–100）。
- 型別／格式檢查：是否為整數／是否符合日期格式等。
- 長度檢查：字串長度是否符合要求（例如密碼最少 8 個字元）。
- 存在性檢查：輸入是否為空（例如不可留空）。
- 查表檢查：輸入是否在允許清單內（例如年級只能是 1–6）。
最常見做法是在處理前先檢查，若無效就輸出錯誤訊息或要求重新輸入。例如：
mark = int(input("分數（0-100）："))
if mark < 0 or mark > 100:
print("錯誤")
else:
# 只在有效情況下才繼續處理
...
重點是：無效數據不應直接進入主計算流程。
建議把測試記錄成表格，最少包含：測試輸入、預期輸出、實際輸出、是否通過、備註。
這樣做能清楚展示你有系統地測試，亦方便日後回歸測試。
常見測試數據類型
- 正常數據：落在合法範圍之中的典型值。
- 邊界／極端數據：貼近範圍邊界的值，例如最小值、最大值及其附近。
- 無效數據：明顯不合理或超出範圍的輸入。
例子：輸入一個分數（0–100），輸出「及格／不及格／錯誤」：
mark = int(input("分數（0-100）："))
if mark < 0 or mark > 100:
print("錯誤")
elif mark >= 50:
print("及格")
else:
print("不及格")
幾個可能的測試個案：
- 75 → 及格（正常數據）
- 50 → 及格（邊界數據）
- 0 → 不及格（邊界數據）
- -5 → 錯誤（無效數據）
- 123 → 錯誤（無效數據）
互動：測試數據類型練習
請按「下一題」開始。每題會描述一組輸入或一份數據來源，請判斷它屬於：正常數據／邊界數據／無效數據。
6.4 除錯：手動方法與除錯工具
本節整理常用的除錯方法。重點不是「猜」，而是以有系統的方式追蹤程式狀態，逐步收窄問題範圍。
- 手動方法：空運行（逐步手算）、追蹤表、手動計算輸出。
- 程式追蹤：觀察程式的實際執行流程及變量變化。
- 斷點：在開發工具中設定暫停位置，逐步執行並查看變量。
- 旗標（標記）：利用變量或輸出訊息，標記程式是否曾執行到某一行或某一分支。
- 存根：為尚未完成的子程式建立「暫代版本」，方便整體測試與整合。
重點摘要
- 先重現錯誤，再定位；定位時以追蹤表或輸出變量縮小範圍。
- 一次只改一個地方，改完要回歸測試，避免引入新問題。
- 善用斷點／逐步執行，比「盲改」更有效率。
有效除錯的第一步是把問題描述清楚：哪一組輸入會出錯？出現了甚麼不合理輸出或錯誤訊息？
- 先重現：用同一輸入再次執行，確認問題穩定存在。
- 再定位：找出是哪一段邏輯導致偏差，而不是一開始就到處修改。
把程式逐行「手算」一次，並記錄每一步的變量值，有助發現條件判斷或循環更新是否正確。
在考試中，追蹤表往往比長篇文字更清楚。
在關鍵位置加入輸出語句，查看變量是否如預期更新，例如：
print("i =", i, "sum =", sum)
- 優點：容易做、工具需求低。
- 注意：完成後要移除多餘輸出，避免影響程式行為或輸出格式。
斷點可令程式在指定行暫停，配合逐步執行功能，可逐行觀察變量、呼叫流程及分支走向。
- 適合處理：循環、巢狀條件、函式呼叫等較複雜情況。
- 常見用途：確認某條分支是否被執行、某變量何時被改寫。
除了看「結果」，更要看「過程」：程式是按哪一條路徑執行？變量在每一步如何變化？
在沒有除錯工具時，追蹤表＋輸出變量就是最實用的追蹤方法。
當程式由多個子程式組成，且部分子程式尚未完成時，可以先用存根回傳固定結果，測試整體流程是否正常。
- 優點：可先測「整體」再逐步替換成真實子程式。
- 做法：每完成一部分，就加入測試並確保仍然通過。
- 一次只改一個地方，便於判斷改動是否有效。
- 保留證據：記錄出錯輸入與輸出、截圖錯誤訊息。
- 修正後進行回歸測試：重測舊測試個案＋新增關鍵個案。
- 避免「盲改」：先理解原因，再動手修改。
空運行／追蹤表
例子：計算 1 + 2 + 3：
sum = 0
i = 1
while i <= 3:
sum = sum + i
i = i + 1
print(sum)
可以畫追蹤表，逐行寫出 i 及 sum 的值，從而檢查循環更新是否正確。
閱讀錯誤訊息
Python 出錯時通常會顯示一段錯誤回溯，例如：
ZeroDivisionError: division by zero
閱讀時可由下而上看：最後一行是錯誤類型；上方會顯示出錯行號與呼叫順序。
6.5 比較不同解決方案／演算法
比較解決同一問題的不同程式或演算法，常見比較角度包括：
- 步驟數量：大約需要多少次運算（例如循環次數）。
- 效率與資源使用：時間與記憶體的消耗。
- 可讀性與可維護性：程式是否容易理解、修改與擴展。
重點摘要
- 比較效率時，優先觀察循環結構：是否有巢狀循環？是否重複做相同步驟？
- 比較可讀性時，留意：變量命名、模組化、是否有重複代碼、是否容易改規格。
- 書面答案要「有理由」：指出哪一段設計令它較快／較省記憶體／較易維護。
- 步驟／時間：運算次數、循環次數、是否重複掃描資料。
- 空間：是否建立了額外清單、暫存表或大型陣列。
- 可讀性／維護性：結構是否清晰、是否容易加入新功能或改規格。
在不做精確計算下，可用循環結構估算：
- 單層循環：大約做 n 次。
- 巢狀循環：大約做 n × n 次（即 n²）或更多。
- 若每次循環內還要再掃一次資料，通常效率較低。
- 把結果「預先計算並儲存」：通常較快，但會用更多記憶體。
- 不儲存、每次重新計算：通常較省記憶體，但可能較慢。
比較題常見答案：指出某版本用多一個清單／字典換取更少重複計算。
- 變量名稱有意義（total 比 t 更清楚）。
- 把重複步驟抽成函式／子程式，避免複製貼上。
- 條件與循環結構清晰；不使用過多「魔法數字」。
- 加入必要註解，說明「為甚麼這樣做」，而非只解釋語法。
可用以下句式：
- 「版本一 較有效率，因為它只需一次循環掃描資料，而版本二 需要重複掃描／有巢狀循環。」
- 「兩者效率相近，但版本一 較易維護，因為它把功能分拆成子程式／命名較清晰／較少重複代碼。」
問題：計算 1 + 2 + … + n。
做法一：循環相加
total = 0
for i in range(1, n+1):
total += i
需要重複加 n 次。
做法二：使用公式
total = n * (n + 1) // 2
只需固定數量的運算步驟，通常更有效率。
- 只寫「版本 A 較快」但沒有指出原因（例如哪個循環或哪個重複步驟）。
- 忽略可讀性：效率相同時，往往要比較哪個較易理解與修改。
- 沒有提及資源：某些版本快但用更多記憶體，應清楚指出取捨。
下面的小測包含 40 題。每題會提供兩段 Python 程式碼（版本一／版本二），請你選擇最合適的比較說法。
互動：40 題演算法比較（版本一與版本二）
請按「下一題」開始。每題會顯示兩段程式碼，然後你用 A / B / C / D 去形容兩個版本的關係。
6.6 40 題 Python 除錯挑戰（語法／運行時／邏輯錯誤）
執行 Python 程式並修正錯誤。每條題目會：
- 提供一段含有語法／運行時／邏輯錯誤的起始程式碼。
- 提供少量提示、參考答案及講解，協助你完成修正。
技術說明：所有題目文字及程式碼都放在 ../data/dch6/debug-python-40.json， 由 python.js 與 challenge-exercises.js 統一載入。
重點摘要
- 建議流程：先理解目的 → 預測輸出 → 執行 → 讀錯誤訊息 → 修正 → 再測試。
- 善用提示與參考答案：先自己嘗試，再對照差異，理解「為甚麼要改」。
- 完成後加測：用邊界／無效輸入再試，確認真正修正而非碰巧通過。
每題通常會提供（由題庫檔案載入）：
- 題目目的：程式應做到甚麼。
- 起始程式碼：包含錯誤的版本。
- 提示：指出可能出錯的位置或方向。
- 參考答案：修正後的程式碼（用作對照）。
- 講解：說明錯因與修正重點。
題庫欄位對照（方便理解畫面資料來源）： purpose（目的）、 starterCode（起始程式碼）、 hints（提示）、 fixedCode（參考答案）、 explanation（講解）、 equals（預期輸出／判斷標準），以及 errorType（錯誤類型）與 difficulty（難度）。
這種設計的目的，是讓你以「先嘗試、再反思」方式建立除錯能力，而不是只背答案。
- 讀目的：先用自己的話重述題意，確認要輸出甚麼。
- 先觀察再執行：快速掃一眼程式，猜測可能出錯位置（例如縮排、條件）。
- 執行並閱讀結果：若有錯誤訊息，先記下錯誤類型與行號。
- 修正（一次一處）：先修最明顯／最致命的錯（例如語法錯誤），改完立即再測。
- 回歸測試：用原本令它出錯的輸入＋多一兩個關鍵測試再試一次。
- if/for/while/def 行尾是否有冒號。
- 同一區塊的縮排是否一致（空格／定位鍵混用容易出事）。
- 括號、引號是否成對。
- 除法的分母是否可能為 0。
- 清單／字串索引是否超出範圍。
- 輸入能否成功轉型（例如把字串轉成整數）。
處理方向：先用輸入驗證把不合理情況排除，再處理核心邏輯。
- 條件判斷是否符合題意（例如及格是 >= 50 還是 > 50）。
- 循環次數是否正確（常見「少一次／多一次」）。
- 變量更新是否正確（是否更新了對的變量、在對的時機更新）。
處理方法：畫追蹤表，或在關鍵位置輸出變量值以核對流程。
- 先獨立嘗試：至少嘗試定位錯誤位置，避免一開始就直接看答案。
- 使用提示：當你已知道大概出錯位置但想不到怎樣改時，再查看提示。
- 對照答案：不要只「抄」，而是比較你與答案差異，寫下「哪一行、改了甚麼、為甚麼」。
- 多試兩三個輸入（尤其是邊界值與無效輸入）。
- 確認輸出格式完全符合要求（例如是否多了空格、換行）。
- 移除多餘的除錯輸出（例如臨時加的 print()）。
- 在彈出視窗內可用左右方向鍵切換上一張／下一張。
- 按 Esc 可關閉視窗；手機可左右滑動切換。
載入中…
如畫面長期停留在此，請檢查是否已成功載入 python.js 及 challenge-exercises.js。
技術說明：這 40 題會沿用與 ACH4 相同的 Python 引擎。 challenge-exercises.js 會根據 ../data/dch6/debug-python-40.json 產生每一題的卡片， 再由 python.js 自動為每個 textarea.code-editor 加上行號、執行按鈕及「重設程式」功能。