3. 某企業利用 No Code/Low Code 平台開發內部營運系統。為確保系統在跨部門流程與外部服務整合下仍具良好的可測試性(Testability)，下 列哪一項作法最為合適？
(A)依賴 No Code/Low Code 平台提供的即時預覽與基本單元測試功能， 快速驗證常見流程；
(B)導入可重複執行的自動化測試流程，並透過 API 或服務虛擬化進 行模組化驗證；
(C)將測試聚焦於使用者介面互動與操作流程驗證，檢查系統表面功 能；
(D)依靠使用者回饋與正式上線後的監控資料，作為修正依據

這題最合適的作法是 (B) 導入可重複執行的自動化測試流程，並透過 API 或服務虛擬化進行模組化驗證。

以下是針對這題的邏輯推理與各選項的評估依據：

核心考點分析：

題目強調了兩個關鍵情境：「跨部門流程」與「外部服務整合」。 在軟體工程與系統分析中，要確保這類複雜系統的「可測試性（Testability）」，最大的阻礙通常來自於外部依賴（例如外部 API 斷線、測試資料遭到其他部門覆蓋等）。因此，提高可測試性的核心手段是「解耦（Decoupling）」與「自動化」。

各選項邏輯推導：

• ✅ (B) 為何是最佳解答：

  • 可重複執行的自動化測試： 確保在 No Code/Low Code (NCLC) 平台頻繁的快速迭代中，能有效進行回歸測試（Regression Testing），避免改A壞B。

  • API 或服務虛擬化（Service Virtualization / Mocking）： 這是解決「外部服務整合」測試痛點的標準作法。透過模擬（Mock）外部服務的回應，系統可以在不依賴真實外部環境的情況下進行測試。這大幅提高了系統模組的獨立性與「可測試性」。

• ❌ (A) 為何不適合：

  • NCLC 平台內建的即時預覽與基本單元測試，通常只能驗證「平台內部」的基礎邏輯（如表單驗證、簡單工作流）。面對跨部門與外部 API 的複雜情境時，這類內建工具的涵蓋範圍與深度通常不足，無法作為系統層級整合測試的唯一依賴。

• ❌ (C) 為何不適合：

  • 僅將測試聚焦於 UI 互動是系統測試中的反模式（Anti-pattern）。UI 測試通常執行速度慢且極度脆弱（Brittle），畫面稍微調整就會導致測試失敗。更重要的是，表面功能的運作正常，不代表背後跨部門資料傳遞或外部 API 的資料交換邏輯是正確的。

• ❌ (D) 為何不適合：

  • 依靠上線後的監控與使用者回饋，屬於「被動發現問題」，這完全放棄了在開發/測試階段攔截錯誤的機會。這違反了軟體品質保證（QA）中「將測試左移（Shift-Left Testing）」的原則，且會帶來極高的維運風險與客訴成本。

總結來說： 面對具備外部整合的 NCLC 系統，選項 (B) 提出了具體的工程實踐（自動化與服務虛擬化）來隔離外部變數，是系統分析與架構設計上真正能提升「可測試性」的標準作法。