軟體架構測試中，適應度函式用於驗證系統是否符合預期架構特性與品質屬性。依驗證範圍區分，可分為原子性、整體性與持續性適應度函式。原子性函式驗證區域性特性，例如單元測試；整體性函式驗證整體功能，例如端對端測試；持續性函式則持續驗證特定指標，例如監控系統回應時間。觸發方式可分為手動、自動及持續評估。執行環境可在測試系統、生產環境或 CI/CD 管道中。度量型別可分為布林值或數值。自動化執行雖為主流，但部分情況仍需手動執行。

軟體架構測試的適應度函式分類別

在軟體架構設計與開發過程中，適應度函式（Fitness Function）扮演著至關重要的角色。它們提供了一種自動化的方式來驗證系統是否符合預期的架構特性與品質屬性。本文將探討適應度函式的各種分類別及其重要性。

適應度函式的型別

適應度函式可以根據其範圍、觸發方式、執行環境等多個維度進行分類別。這些分類別有助於開發者更好地理解和應用適應度函式於軟體架構驗證中。

1. 依範圍分類別：原子性、整體性與持續性

適應度函式根據其驗證範圍的不同，可以分為原子性（Atomic）、整體性（Holistic）與持續性（Continual）三類別。

原子性適應度函式：驗證系統的特定區域性特性。例如，單元測試驗證單個函式或模組的正確性。

def test_add_function():
    assert add(2, 3) == 5
#### 內容解密：
這段程式碼展示了一個簡單的單元測試，用於驗證 `add` 函式的正確性。透過 `assert` 陳述句，我們可以確保函式輸出符合預期。

整體性適應度函式：提供更廣泛的反饋，驗證系統的整體功能是否符合預期。例如，端對端測試驗證整個系統的工作流程。

describe('User registration', () => {
    it('should register a new user', () => {
        // 模擬使用者註冊流程
        cy.visit('/register');
        cy.get('input[name="username"]').type('newuser');
        cy.get('input[name="password"]').type('password123');
        cy.get('button[type="submit"]').click();
        cy.url().should('include', '/dashboard');
    });
});
#### 內容解密：
這段程式碼展示了一個端對端測試，使用 Cypress 框架模擬使用者註冊流程。透過逐步操作頁面元素並驗證最終結果，確保系統的整體功能正確性。

持續性適應度函式：持續驗證系統的特定指標，無論開發活動是否進行。例如，監控系統的回應時間。

# Prometheus 組態示例
metrics:
  - name: response_time
    type: histogram
    help: "API response time in seconds"
#### 內容解密：
這段組態定義了一個名為 `response_time` 的指標，用於持續監控 API 的回應時間。透過 Prometheus 進行資料收集與分析，可以及時發現效能問題。

2. 觸發方式

適應度函式可以根據觸發方式的不同，分為手動執行、自動觸發（如 CI/CD 管道中的測試）以及持續評估（如監控系統指標）。

  graph LR
    D[D]
    A[開發者提交程式碼] -->|觸發|> B[CI/CD 管道]
    B --> C[執行測試]
    C --> D{測試結果}
    D -->|透過|> E[佈署至生產環境]
    D -->|失敗|> F[通知開發者修正]
此圖示
**圖表翻譯：**
此圖表展示了 CI/CD 管道的典型流程。開發者提交程式碼後，自動觸發 CI/CD 管道執行測試。根據測試結果，決定是否佈署至生產環境或通知開發者進行修正。

3. 執行環境

適應度函式可以在不同的環境中執行，包括測試系統、生產環境或 CI/CD 管道中。

測試系統：執行各種測試，如效能測試或負載測試。

# 使用 Apache JMeter 進行效能測試
jmeter -n -t test_plan.jmx -l results.jtl
#### 內容解密：
這條命令使用 Apache JMeter 執行一個效能測試計劃，並將結果儲存至 `results.jtl` 檔案中。透過效能測試，可以評估系統在高負載下的表現。

生產環境：持續監控系統的執行狀態，如監控服務的回應時間。

4. 度量型別

適應度函式的輸出可以是布林值（如測試是否透過），也可以是數值（如效能指標）。

def calculate_response_time(url):
    start_time = time.time()
    response = requests.get(url)
    end_time = time.time()
    return end_time - start_time

#### 內容解密：
這段程式碼計算了存取指定 URL 的回應時間。透過記錄請求前後的時間差，可以得到一個數值指標，用於評估系統效能。

5. 自動化 vs 手動執行

雖然大多數適應度函式應該自動化執行，但在某些情況下，手動執行是必要的，例如法律合規性測試。

品質屬性需求

品質屬性是軟體架構設計中的關鍵驅動因素。ISO 25010 標準定義了產品品質的八大主要特徵及其子屬性，包括功能適宜性、效能效率、相容性、可用性、可靠性、安全性、可維護性與可移植性。

特徵	子屬性
功能適宜性	功能完整性、功能正確性、功能適當性
效能效率	時間行為、資源利用率、容量
相容性	共存性、互操作性
可用性	適當性可辨識性、易學性、可操作性、使用者錯誤防護、使用者介面美觀性、可存取性
可靠性	成熟度、可用性、容錯性、可還原性
安全性	保密性、完整性、不可抵賴性、可問責性、真實性
可維護性	模組化、可重用性、可分析性、可修改性、可測試性
可移植性	適應性、可安裝性、可替換性

品質屬性的重要性

在軟體架構開發過程中，品質屬性與功能需求、約束條件共同構成了三大關鍵驅動因素。明確定義品質屬性需求，有助於確保系統架構滿足業務與使用者的需求。

可選的適應度函式分類別

除了上述主要分類別外，還有一些可選的分類別標準，如風險導向、業務相關性等。這些分類別有助於在特定情境下進一步指導適應度函式的設計與實施。

適應度函式（Fitness Function）分類別與測試金字塔框架

適應度函式是一種用於軟體開發中的重要概念，主要用於評估系統架構是否符合預期需求。適應度函式的分類別方式可以幫助開發團隊更好地設計和實施自動化測試，以確保系統的品質和穩定性。

適應度函式的分類別

適應度函式可以根據不同的標準進行分類別，包括：

臨時性或永久性

適應度函式的設計初衷決定了它是臨時性還是永久性的。如果某個適應度函式的使用和有效性受到設計上的限制，那麼可以將其標記為臨時性；否則，將被視為永久性。這裡的「永久性」並不意味著該函式會永遠存在，而是表示它沒有特定的結束日期。

例如，在進行某項重構活動時，會使用臨時性的適應度函式來提供額外的指導。一旦重構工作完成，這些臨時性的適應度函式將被廢棄。

// 臨時性適應度函式範例：檢查程式碼覆寫率是否達到特定閾值
function checkCodeCoverage(threshold) {
  // 計算目前程式碼覆寫率
  const coverage = calculateCoverage();
  // 比較目前覆寫率與閾值
  return coverage >= threshold;
}

#### 內容解密：
此範例展示了一個簡單的臨時性適應度函式，用於檢查程式碼覆寫率是否達到預設的閾值。該函式首先計算目前的程式碼覆寫率，然後將其與指定的閾值進行比較。如果覆寫率達到或超過閾值，則傳回 `true`，否則傳回 `false`。這種臨時性的適應度函式通常用於特定的重構或最佳化任務中，一旦任務完成，該函式就會被廢棄。

#### 靜態或動態

靜態適應度函式具有固定的目標指標定義，驗證過程是根據這個靜態指標進行的。例如，在某些範例中，檢查程式碼覆寫率是否始終高於某個靜態值。

```java
// 靜態適應度函式範例：檢查系統的回應時間是否在特定範圍內
public boolean checkResponseTime(long maxResponseTime) {
  long responseTime = measureResponseTime();
  return responseTime <= maxResponseTime;
}

#### 內容解密：
此範例展示了一個靜態適應度函式，用於檢查系統的回應時間是否在預設的最大回應時間以內。該函式首先測量系統的回應時間，然後將其與設定的最大回應時間進行比較。如果回應時間在允許範圍內，則傳回 `true`，否則傳回 `false`。靜態適應度函式適用於那些具有固定效能指標的系統。

動態適應度函式則定義了一個與其他值相關的目標指標範圍。例如，可以定義系統回應時間在特定使用者數量範圍內的目標範圍。

```python
# 動態適應度函式範例：根據使用者數量動態調整回應時間範圍
def check_dynamic_response_time(user_count):
    if user_count < 10000:
        return measure_response_time() <= 50
    elif user_count < 100000:
        return 50 <= measure_response_time() <= 100
    else:
        return False

#### 內容解密：
此範例展示了一個動態適應度函式，用於根據當前使用者數量動態調整系統的回應時間範圍。該函式首先檢查當前使用者數量，然後根據不同的使用者數量範圍設定不同的回應時間閾值。如果系統的回應時間在設定的範圍內，則傳回 `true`，否則傳回 `false`。動態適應度函式能夠更好地適應真實世界的場景，提供更為靈活的評估標準。

### 目標物件

適應度函式和指標的目標物件可能包括軟體開發人員、維運團隊、產品經理以及其他利益相關者。確定目標物件有助於在大型環境中滿足額外的檔案和溝通需求。

### 應用範圍

在大型系統或多系統環境中，可能需要限制適應度函式及其指標的有效性和執行範圍。例如，可以將某個適應度函式限制在特定的子系統或服務中，或者針對不同的技術堆疊使用不同的程式碼覆寫率要求。

### 測試金字塔框架

測試金字塔是一種廣為接受的概念，用於將不同型別的自動化功能測試劃分為三個層次：單元測試、服務/整合測試和端對端（E2E）測試。

#### 測試金字塔的層次結構

1. **基礎層：單元測試**
   - 單元測試是最基本的測試型別，用於驗證個別單元的功能。
   - 優點是能夠精確定位問題所在。
   - 缺點是難以直接推斷出真實使用場景中的錯誤行為。

2. **中間層：服務/整合測試**
   - 服務和整合測試位於中間層，用於驗證多個單元之間的互動。
   - 這類別測試能夠在較大的範圍內驗證系統的功能。

3. **頂層：端對端（E2E）測試**
   - E2E測試通常透過使用者介面（UI）層直接執行，模擬真實使用者的操作。
   - 優點是能夠直接反映真實使用場景中的錯誤。
   - 缺點是當測試失敗時，較難定位具體的錯誤元件。

### 圖表說明

```mermaid
graph LR
    A[測試金字塔] --> B[基礎層：單元測試]
    A --> C[中間層：服務/整合測試]
    A --> D[頂層：端對端測試]
    B --> E[精確定位問題]
    B --> F[難以推斷真實場景錯誤]
    C --> G[驗證多單元互動]
    D --> H[模擬真實使用者操作]
    D --> I[難以定位錯誤元件]

圖表翻譯： 此圖示展示了測試金字塔的結構，包括基礎層的單元測試、中間層的服務/整合測試和頂層的端對端測試。每個層次都有其特定的優缺點。單元測試能夠精確定位問題，但難以推斷真實使用場景中的錯誤；服務/整合測試能夠驗證多個單元之間的互動；而端對端測試則模擬真實使用者的操作，但當測試失敗時較難定位具體的錯誤元件。

隨著軟體開發技術的不斷進步，適應度函式和測試金字塔框架也將不斷演化。未來可能會出現更多動態和智慧的適應度函式，能夠根據真實世界的資料和反饋自動調整評估標準。同時，測試金字塔框架也將進一步完善，以適應新的軟體架構和開發模式。

參考資料

Martin Fowler, “TestPyramid,” MartinFowler.com, May 1, 2012, https://oreil.ly/9o1DV.
Ashley Davis, Bootstrapping Microservices with Docker, Kubernetes, and Terraform (Manning, 2021).
Lisa Crispin and Janet Gregory, Agile Testing: A Practical Guide for Testers and Agile Team (Addison-Wesley, 2008).

透過上述內容的詳細闡述，我們可以看到適應度函式和測試金字塔框架在軟體開發中的重要性，以及如何有效地應用這些概念來提升軟體品質和開發效率。希望這些資訊能夠幫助開發團隊在實際工作中更好地實施自動化測試和品質控制。

適應度函式測試金字塔：架構測試與指標的類別比

在軟體開發領域，測試是確保系統品質的重要環節。測試金字塔（Testing Pyramid）是一種常見的測試策略，用於指導測試的實施。適應度函式測試金字塔（Fitness Function Testing Pyramid）則是將此概念擴充套件至架構測試和指標的領域。

測試金字塔的概念

統計學家George E. P. Box曾說：「所有的模型都是錯誤的，但仍有一些是有用的。」測試金字塔模型正是這樣一個有用的工具，用於幫助我們決定在哪裡投入測試和自動化的努力。

傳統的測試金字塔分為三層：單元測試（Unit Tests）、整合測試（Integration Tests）和端對端測試（End-to-End Tests）。金字塔的底部是單元測試，這些測試執行速度快，易於維護；越往上，測試的執行速度越慢，開發和維護的成本也越高。

適應度函式測試金字塔

適應度函式測試金字塔的概念與傳統的測試金字塔類別似，但專注於架構測試和指標。它同樣分為三層：觸發式原子適應度函式（Triggered Atomic Fitness Functions）、觸發式整體或連續式原子適應度函式（Triggered Holistic or Continuous Atomic Fitness Functions），以及整體適應度函式（Holistic Fitness Functions）。

頂層：整體適應度函式

頂層的測試提供對系統健康狀態和功能性的最複雜的反饋。這些測試最接近真實世界的使用案例，但也是最難構建和維護的。它們可能涉及多個元件，因此更容易出現非確定性行為。

def holistic_fitness_function(system_metrics):
    # 檢查關鍵指標是否在預期範圍內
    if system_metrics['checkout_rate'] < expected_range['checkout_rate']:
        return False
    if system_metrics['revenue_per_minute'] < expected_range['revenue_per_minute']:
        return False
    return True

#### 內容解密：
# holistic_fitness_function函式用於評估系統的整體健康狀態。
# 它檢查系統的關鍵指標，如結帳率和每分鐘收入，是否在預期的範圍內。
# 如果任何指標超出預期範圍，函式傳回False，表示系統存在問題。

中層：觸發式整體或連續式原子適應度函式

中層的測試提供了對系統健康狀態的廣泛反饋，但不是持續執行的。它們可能在整合測試構建過程中被觸發，或在自動化佈署流程中使用測試系統或階段。

public class TriggeredHolisticMetric {
    public boolean evaluate(SystemMetrics systemMetrics) {
        // 檢查系統的整體效能
        if (systemMetrics.getTransactionDuration() > threshold) {
            return false;
        }
        return true;
    }
}

#### 內容解密：
# TriggeredHolisticMetric類別用於評估系統的整體效能。
# evaluate方法檢查系統的交易持續時間是否超過閾值。
# 如果超過閾值，方法傳回false，表示系統效能存在問題。

底層：觸發式原子適應度函式

底層的測試是觸發式原子的，執行速度快，易於維護。它們通常已經整合在CI/CD流程中，構成了定義有用指標的基礎。

function triggeredAtomicFitnessFunction(transactionData) {
    // 檢查交易資料是否符合預期
    if (transactionData.status !== 'success') {
        return false;
    }
    return true;
}

#### 內容解密：
# triggeredAtomicFitnessFunction函式用於檢查交易資料是否符合預期。
# 它檢查交易狀態是否為成功。
# 如果交易狀態不是成功，函式傳回false，表示交易存在問題。

圖表翻譯：

此圖表展示了適應度函式測試金字塔的三個層級。

底層是觸發式原子適應度函式，執行速度快，易於維護。

中層是觸發式整體或連續式原子適應度函式，提供了對系統健康狀態的廣泛反饋。

頂層是整體適應度函式，提供最複雜的反饋，最接近真實世界的使用案例。


適應度函式測試金字塔的概念與傳統的測試金字塔類別似，但專注於架構測試和指標。它幫助我們在測試的執行時間、維護成本和對系統的信心之間取得平衡，從而確保系統的品質和可靠性。

最終，適應度函式測試金字塔為我們提供了一個強大的工具，用於指導架構測試和指標的實施。透過合理地運用這一工具，我們可以提高系統的品質，減少維護成本，並增強對系統的信心。

在實際應用中，我們需要根據具體的系統需求和特點，靈活地運用適應度函式測試金字塔。這包括選擇合適的測試層級、定義適當的指標，以及實施有效的測試策略。

透過這樣的做法，我們可以確保系統的品質和可靠性，同時也提高了開發和維護的效率。

總的來說，適應度函式測試金字塔是一個非常有用的概念，它可以幫助我們更好地進行架構測試和指標的設計和實施，從而提高系統的品質和可靠性。它的應用需要結合具體的系統需求和特點，靈活地選擇和實施適當的測試策略。

這是一個範例，用於展示如何使用適應度函式測試金字塔的概念來指導架構測試和指標的實施。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。

軟體架構測試適應度函式分類別