111 漁會招考技工、工友晉升職員 資訊管理 全國漁會第九次 資訊管理(資訊電腦實務) 考古題詳解

核心觀念

本題考查「資料」與「資訊」的基本定義、彼此關係，以及資料經處理後如何形成可供判斷與決策使用的資訊。

一、資料（Data）

資料是尚未經過充分整理、分析或解釋的原始事實、數字、文字、符號、影像、聲音或紀錄。資料本身通常只呈現客觀現象，未必具有完整意義。

例如：

• 會員編號：A1025
• 進貨數量：500 公斤
• 魚貨價格：每公斤 120 元
• 交易日期：111 年 8 月 15 日
• 感測器測得水溫：28℃

這些內容都是原始紀錄，屬於資料。

二、資訊（Information）

資訊是資料經過蒐集、整理、分類、計算、比較、分析或解釋後，具有明確意義，且能協助使用者了解情況、解決問題或進行決策的內容。

資訊通常具有下列特性：

1. 正確性：內容應符合實際情況。
2. 及時性：在需要時能提供使用。
3. 完整性：涵蓋決策所需的重要內容。
4. 攸關性：與使用者的問題或目的相關。
5. 可理解性：呈現方式應便於閱讀與判斷。

例如，「本月平均魚貨價格為每公斤 135 元，較上月上升 12.5%，主要原因為漁獲量減少」即屬於資訊，因為它不僅呈現數字，也包含比較與原因分析，可供管理人員作為採購、庫存或價格調整的參考。

資料與資訊的關連性

資料與資訊具有「原料與成品」的關係。資料是產生資訊的基礎，資訊則是資料經處理後的有意義結果。

其轉換關係可表示如下：

兩者關係如下：

1. 資料是資訊的來源 沒有原始資料，就無法產生客觀可靠的資訊。

2. 資訊是資料加工後的結果 資訊不是單純堆積資料，而是經過適當處理，使資料產生意義與用途。

3. 相同資料可依目的產生不同資訊 例如同一批銷售資料，財務人員可分析營收與利潤，採購人員可分析庫存需求，管理者則可分析市場趨勢。

4. 資訊的品質取決於資料品質與處理方法 若資料錯誤、不完整或過時，即使使用複雜的分析方法，產生的資訊仍可能錯誤。此概念可用「垃圾進，垃圾出」表示，即：

5. 資訊具有相對性 對某一使用者有用的內容，對另一使用者未必具有相同價值。因此，資訊的價值與使用目的、使用者需求及使用時機有關。

解題方法

本題為申論與說明題，建議依照「定義—比較—關係—流程—實例」的順序作答：

第一步：分別定義資料與資訊

先指出資料是未充分處理的原始事實，資訊是經過處理、具有意義且可供使用的結果。

第二步：說明兩者差異

可從下列面向比較：

核心觀念

本題考查四項資訊安全與網際網路基礎名詞：

1. 零時差攻擊：利用尚未修補、尚未公開修正方法的軟體漏洞。
2. XML：以標籤描述資料結構的可延伸標記語言。
3. HTTPS：在 HTTP 上加入加密與身分驗證的安全通訊協定。
4. 防火牆：依安全規則控管網路流量，保護內部網路資源。

本題屬名詞解釋題，作答時應採用「定義 → 運作方式 → 功能或影響 → 舉例」的架構，才能完整呈現觀念並取得各小題分數。

（1）零時差攻擊（Zero-day Attack）

定義

零時差攻擊是指攻擊者利用軟體、作業系統、網路設備或應用程式中尚未被修補的安全漏洞進行攻擊。由於軟體開發商或使用者從發現漏洞到發布修補程式之間，防禦者幾乎沒有準備時間，因此稱為「零時差」。

「零時差」不是指攻擊發生時間為零，而是指漏洞公開、被發現或遭利用後，系統尚未完成修補的期間。

攻擊特性

• 漏洞尚未有正式修補程式。
• 防毒軟體與入侵偵測系統可能尚未建立相應特徵。
• 攻擊者可藉此進行未經授權存取、植入惡意程式、竊取資料或癱瘓服務。
• 漏洞資訊可能先由攻擊者掌握，再由軟體廠商或研究人員發現。

防禦方式

組織可透過下列方式降低風險：

• 及時更新作業系統、應用程式與韌體。
• 建立弱點管理與修補管理制度。
• 使用入侵防禦系統、端點防護與行為分析。
• 依最小權限原則限制使用者及程式權限。
• 進行網路分區，避免單一設備遭入侵後擴散至整個內部網路。
• 定期備份重要資料，建立事件應變及復原機制。

解題技巧

判斷零時差攻擊的關鍵是「漏洞尚未修補」。若題目只描述一般病毒、木馬或釣魚郵件，並不必然屬於零時差攻擊；必須具有利用未知或尚未完成修補漏洞的特徵。

（2）XML

定義

XML 是 Extensible Markup Language，延伸標記語言 的縮寫，是一種用標籤描述資料內容、結構與層次關係的文字格式。

XML 不同於 HTML 的主要特色，在於 XML 標籤可由設計者依資料需求自行定義。例如：

<student>
 <name>王小明</name>
 <score>85</score>
</student>

其中：

• <student> 表示學生資料。
• <name> 表示姓名欄位。
• <score> 表示成績欄位。
• 標籤本身具有資料意義，可協助不同系統理解資料內容。

主要特性

1. 可延伸性 使用者可依需求建立自訂標籤，不受固定標籤限制。

2. 階層式結構 資料可以父子節點方式表示，適合描述複雜資料。

3. 純文字格式 XML 可由一般文字編輯器開啟，具有跨平台及可讀性高的特性。

4. 資料與呈現分離 XML 主要負責描述與傳遞資料，不負責網頁畫面的排版呈現。

5. 適合系統間資料交換 不同作業系統、程式語言與應用程式可依共同格式交換資料。

XML 與 HTML 的差異

• XML 著重於「資料的描述、儲存與交換」。
• HTML 著重於「網頁內容的呈現」。
• XML 標籤可自行定義。
• HTML 標籤通常依 HTML 標準規範使用。

解題技巧

看到「自訂標籤」「描述資料結構」「資料交換」等關鍵字，即可聯想到 XML。XML 是標記語言，不是資料庫，也不是程式語言。

（3）HTTPS 與 HTTP 的差異

HTTPS 定義

HTTPS 是 HyperText Transfer Protocol Secure，安全超文字傳輸協定，是在 HTTP 之上結合 TLS 加密技術的安全通訊方式。

一般連線流程如下：

1. 使用者透過瀏覽器連線至網站。
2. 伺服器提供數位憑證。
3. 瀏覽器驗證憑證及伺服器身分。
4. 雙方協商安全連線所使用的金鑰。
5. 後續 HTTP 資料以加密方式傳輸。

HTTPS 提供的安全功能

核心觀念

社交工程（Social Engineering）是指攻擊者利用人性的心理弱點、信任關係與溝通習慣，透過欺騙、誘導、冒充或操弄等方式，使受害者洩漏機密資訊、點擊惡意連結、執行危險操作，或協助攻擊者取得未經授權的系統、帳號與資源。

其攻擊重點不是直接突破防火牆或破解加密技術，而是「攻擊人」。常被利用的心理因素包括：

• 信任權威，例如主管、銀行、政府機關或資訊人員。
• 恐懼與急迫感，例如帳號即將停用、涉及違規或必須立即付款。
• 好奇心，例如未婚夫外遇照片、薪資調查或重要文件。
• 貪利心理，例如中獎通知、獎金或免費贈品。
• 從眾與服從心理，例如要求依照主管指示立即提供資料。

社交工程可能造成帳號密碼外洩、個人資料洩漏、惡意程式感染、詐騙匯款及內部資訊遭竊等資安事件。

解題方法

本題要求兩項內容：

1. 說明社交工程的定義。
2. 列出三種社交工程攻擊方式。

作答時應先掌握「利用人的弱點取得未授權結果」這個核心，再列舉不同媒介或情境的攻擊方式。三種攻擊方式最好選擇典型且容易辨識者，並各自附上攻擊手法與實例，以充分展現理解程度。

三種社交工程攻擊方式

一、網路釣魚（Phishing）

攻擊者偽造銀行、政府機關、公司或電子郵件服務商的通知，透過電子郵件、簡訊或通訊軟體傳送惡意連結，誘騙受害者輸入帳號、密碼、信用卡資料，或下載惡意檔案。

例如，攻擊者寄送假冒銀行的電子郵件，聲稱「帳戶異常，請立即登入驗證」，受害者點擊連結後進入偽造網站並輸入帳密，資料便遭攻擊者取得。

釣魚攻擊的特徵包括：

• 寄件者名稱或網域與正式機構相似。
• 內容製造恐慌或急迫感。
• 要求登入、付款、提供個人資料或下載附件。
• 連結網址與真正網站不一致。

二、電話社交工程（Vishing）

Vishing 是 Voice Phishing 的縮寫，指攻擊者透過電話進行語音釣魚，冒充銀行客服、警察、主管、資訊人員或其他可信任對象，誘導受害者提供敏感資料或執行特定操作。

例如，攻擊者冒充資訊室人員，表示公司帳號發生異常，要求員工提供密碼或一次性驗證碼，以便「協助處理」。受害者提供後，攻擊者即可登入系統。

電話社交工程常利用語氣、身分權威及時間壓力降低受害者的警覺性。

三、假冒身分與預設情境（Pretexting）

核心觀念 本題考驗軟體工程（Software Engineering）與資訊管理中「軟體測試（Software Testing）」的核心觀念與實務體系，重點包含：

1. 軟體測試生命週期之階段劃分：依據 V 模式（V-Model）與軟體開發生命週期（SDLC），軟體測試由微觀之個別模組至宏觀之使用者需求，分為單元測試、整合測試、系統測試與驗收測試四個主要階段。
2. 測試模式與測試策略：依據測試者對系統內部程式碼與邏輯結構的流覽程度，劃分為「白箱測試（White Box Testing）」與「黑箱測試（Black Box Testing）」。

解題方法

1. 子題 (1) 切入點：依循標準 V 模式（V-Model）之測試層級進行剖析，由小到大、由內而外推演。說明每個階段的「測試對象」、「對應開發階段」與「測試目標」。
2. 子題 (2) 切入點：採「內部結構可見度」與「測試依據」作為對比基礎。詳細說明白箱測試與黑箱測試的定義、別稱、關注焦點，並列舉該測試模式下的代表性測試技術（例如白箱測試的覆蓋率指標；黑箱測試的邊界值分析等），展現答題深度。

選項分析 本題為申論實務題，按子題要求進行細項分析與深入剖析：

• (1) 軟體測試的主要階段分析（8分） 軟體測試在軟體開發流程中，主要依測試層級與範圍劃分為以下四大階段：

1. 單元測試（Unit Testing）：

• 測試對象：獨立的最小程式單元、函式（Function）、方法（Method）或類別（Class）。
• 對應開發階段：詳細設計（Detailed Design）與程式碼編寫階段。
• 測試內容與目標：驗證單一模組內部的演算法、邏輯判斷與資料結構是否正確。通常由開發人員（Programmer）撰寫測試用例並執行。

2. 整合測試（Integration Testing）：

• 測試對象：已通過單元測試的兩個或多個模組所組合而成的子系統或介面（Interface）。
• 對應開發階段：概要設計 / 架構設計（System Architectural Design）。
• 測試內容與目標：驗證模組與模組之間的介面呼叫、參數傳遞、資料整合與互動機制是否順暢。常見策略包括由上而下（Top-Down）、由下而上（Bottom-Up）或大爆炸（Big Bang）整合法。

3. 系統測試（System Testing）：

• 測試對象：整合完成的完整軟體系統，結合硬體、網路、資料庫與外部介面之整體環境。
• 對應開發階段：系統需求分析（System Requirements Analysis）。
• 測試內容與目標：驗證整個軟體系統是否符合系統需求規格書（SRS）。測試範圍涵蓋「功能性測試」與「非功能性測試」（如效能測試、壓力測試、安全性測試、負載測試與復原測試等）。

4. 驗收測試（Acceptance Testing）：

• 測試對象：準備發布或上線營運的完整軟體系統。

• 對應開發階段：使用者需求定義（User Requirements）。

• 測試內容與目標：由使用者（User）、客戶（Client）或獨立 QA 團隊執行，確認系統是否符合實際業務需求與營運流程。通常包含 Alpha 測試（開發環境下的內部驗收）與 Beta 測試（真實使用環境下的外部廣測）。

• (2) 白箱測試與黑箱測試之說明分析（7分）

1. 白箱測試（White Box Testing）：

核心觀念

本題考驗關聯式資料庫（Relational Database）中標準查詢語言（SQL, Structured Query Language）的基本 SELECT 語法，重點包含以下關鍵元件：

1. 基本查詢結構：使用 SELECT 指定輸出欄位，搭配 FROM 指定目標資料表。
2. 條件篩選與數值比較 (WHERE)：利用 WHERE 子句配合比較運算子（如 >）過濾符合條件之資料列。
3. 字串模糊比對 (LIKE)：使用 LIKE 運算子結合萬用字元 %（代表任意長度之零個或多個字元），進行子字串搜尋。
4. 資料排序 (ORDER BY)：使用 ORDER BY 對查詢結果排序，預設為升冪（ASC，由小到大），若要求由大到小則需明確指定降冪（DESC）。
5. 大小寫規範：國家考試與國營事業/漁會招考中，評分標準通常要求將 SQL 關鍵字寫成大寫（如 SELECT、FROM、WHERE），而資料表與欄位名稱則精確保留題目給定之大小寫（如 BoatDB、TMoney、BName）。

解題方法

(1) 篩選「TMoney」大於 3000 元的 SQL 語法

• 切入點：需從資料表 BoatDB 中選取所有欄位，並針對數值欄位 TMoney 設定過濾條件。
• 步驟：

1. 指定查詢欄位：SELECT *
2. 指定資料來源：FROM BoatDB
3. 設定條件：WHERE TMoney > 3000

• 完整語法：

SELECT *
FROM BoatDB
WHERE TMoney > 3000;

(2) 找出「BName」包含「滿」字串的 SQL 語法

• 切入點：字串中只要含有「滿」字（無論位於開頭、中間或結尾）皆符合條件，屬於模糊搜尋，應採用 LIKE '%滿%'。
• 步驟：

1. 指定查詢欄位：SELECT *
2. 指定資料來源：FROM BoatDB
3. 設定模糊比對條件：WHERE BName LIKE '%滿%'

• 完整語法：

SELECT *
FROM BoatDB
WHERE BName LIKE '%滿%';

(3) 結果依「TMoney」由「大到小」排序的 SQL 語法

• 切入點：將所有資料輸出並依照金額降冪排列，應使用 ORDER BY 子句並加上 DESC 關鍵字。
• 步驟：

1. 指定查詢欄位：SELECT *
2. 指定資料來源：FROM BoatDB
3. 指定排序方式：ORDER BY TMoney DESC

• 完整語法：

核心觀念

本題考查資訊人員在資安與 IT 實務維運中，面對硬體故障的「故障診斷與排除流程（Troubleshooting Methodology）」。 核心觀念涵蓋：

1. 開機自我測試機制 (POST, Power-On Self-Test)：計算機結構中，開機時韌體 (BIOS/UEFI) 針對硬體元件（如 CPU、RAM、顯示卡、主機板）進行初始化檢測的原理與蜂鳴器 (Beep Code) 代碼意義。
2. 分層與分段排除法 (Divide-and-Conquer Methodology)：從物理電源層、硬體韌體層 (POST)、顯示訊號層到系統引導層 (OS Boot Order)，進行由外而內、由軟而硬的邏輯化排查。
3. 最小系統法 (Minimal System Method)：將系統精簡至僅能維持 POST 運轉的最基本硬體組件，快速隔離故障源。

解題方法

採用「邏輯化階梯式排除法（Top-Down Diagnostic Hierarchy）」。 針對「無法開機」這一高廣度實務問題，應依據電腦開機時序（電源通電 $\rightarrow$ POST 自檢 $\rightarrow$ 顯示輸出 $\rightarrow$ OS 載入）切入診斷：

1. 第一階段：物理電源與外圍設備排查（排除外部與假故障）
2. 第二階段：硬體過電與 POST 自檢診斷（最小系統法與蜂鳴器/LED判斷）
3. 第三階段：顯示訊號與輸出介面檢查
4. 第四階段：BIOS/UEFI 設定與儲存裝置引導檢測
5. 第五階段：業務恢復與維運紀錄

此方法符合資訊管理（MIS）實務標準維運程序 (SOP)，兼顧檢修效率、資料安全與業務連續性。

選項分析

本題為實務申論題，無固定單選選項。為使診斷過程完整且嚴密，將「無法開機」常見的四種典型故障徵兆（Symptom Cases）進行逐一說明與診斷對照：

1. 徵兆 A：完全無過電（按下電源開關無任何反應，風扇不轉、燈號不亮）

• 原因分析：電源輸入中斷、電源供應器 (PSU) 損毀、主機板短路、或機殼 Power SW 按鈕線路斷路。
• 處理措施：檢測牆面插座與電源線，測試 PSU 綠線與黑線短路運轉；檢視主機板 $24\text{-pin}$ 與 $8\text{-pin}$ 供電線；使用金屬起子短路主機板開機跳線，排除面板按鈕故障。

2. 徵兆 B：有過電但無畫面，且發出警示嗶聲 (Beep Codes) 或診斷燈異常

• 原因分析：硬體自檢 (POST) 失敗，常見為記憶體 (RAM) 金手指氧化或接觸不良、顯示卡 (GPU) 未插妥、或 CPU 異常。
• 處理措施：依 BIOS 廠牌（如 AMI、Award）之嗶聲代碼判斷（例如一長兩短代表顯卡異常，連續長聲代表記憶體異常）；將 RAM 拔下並以橡皮擦清潔金手指後插回；採最小系統法交叉測試。

3. 徵兆 C：有過電、風扇轉動，但螢幕顯示「無訊號輸入 (No Signal)」

• 原因分析：顯示器電源或訊號線未連接、顯示器輸入源 (Input Source) 設定錯誤、外接顯卡與內顯輸出埠插錯、或 CMOS 設定異常。
• 處理措施：確認 HDMI / DP 線接頭牢固；切換螢幕訊號源；進行 Clear CMOS（拔除 CR2032 水銀電池 $5 \sim 10$ 分鐘，或短路跳線）還原 BIOS 預設設定。

4. 徵兆 D：能過電並通過 POST，但停在開機字樣或顯示 "No bootable device found"

• 原因分析：儲存裝置（SSD/HDD）故障、SATA/NVMe 介面接觸不良、開機順序設定錯誤、或 MBR/GPT 引導磁區損毀。
• 處理措施：進入 BIOS/UEFI 確認是否偵測到硬碟；確認 Boot Order 第一順位；插拔硬碟排線；使用系統救援工具進行開機磁區修復或資料備份。