開發測試與 Amazon Q Developer

開發測試與 Amazon Q Developer 共同構成 AWS Certified Developer Associate（DVA-C02）考試任務陳述 3.2——「在開發環境中測試應用程式」——的核心範疇。2024 年 12 月發布的考試指南 V2.1 縮減了 CI/CD 的考題範圍，但新增了 Amazon Q Developer 作為範疇內的生成式 AI 配對程式設計師。這項單一異動重塑了考試對開發測試的定義：你現在必須了解如何使用 AWS SAM local 在本機執行 Lambda、如何模擬 AWS SDK 呼叫、如何針對沙箱 AWS 帳號進行整合測試、如何從終端機追蹤 CloudWatch Logs，以及 Amazon Q Developer 如何透過 /dev、/review 和 /test 加速上述所有流程。本章逐一說明 DVA-C02 可能考到的每一個開發測試概念，從基本的 sam local invoke 到 Amazon Q Developer 自訂功能以及 CodeGuru Profiler 火焰圖。若你已讀過 IaC 章節中關於 AWS SAM 與 CloudFormation 的內容，本主題正是其自然延伸——SAM 負責建立範本，開發測試則驗證範本在 sam deploy 執行之前確實可行。

什麼是 AWS 上的開發測試？

AWS 上的開發測試是在程式碼進入共用環境之前驗證無伺服器及雲端原生應用程式的實踐。DVA-C02 考試以三個相互重疊的回饋迴圈來描述它。內層迴圈以次秒計：你儲存檔案、執行單元測試、取得紅燈／綠燈訊號，然後持續迭代。中層迴圈以秒到分鐘計：你啟動 sam local start-api 或 sam local invoke，用 curl 或 Lambda 測試事件呼叫它，並在本機 Docker Lambda 模擬環境中驗證處理函式。外層迴圈以分鐘到數十分鐘計：你用 sam sync 或 sam deploy 部署到個人沙箱 AWS 帳號，針對真實 AWS 服務執行整合測試，用 sam logs 或 aws logs tail 追蹤 CloudWatch Logs，再持續迭代。開發測試的精髓在於如何保持在最快且仍能提供可信訊號的迴圈中——而 Amazon Q Developer 正是橫跨三個迴圈的 V2.1 加速層。

開發測試在 DVA-C02 考試地圖中的位置

開發測試散布於 DVA-C02 的每個領域：

• 領域 1（開發，32%）：在本機呼叫 Lambda 處理函式、提供 Lambda 測試事件、模擬 AWS SDK 呼叫，以及將 API Gateway 接線至 sam local start-api。
• 領域 2（安全，26%）：Amazon Q Developer 安全掃描、CodeGuru Reviewer 拉取請求安全發現，以及在提交前攔截硬式編碼憑證的反模式。
• 領域 3（部署，24%）：SAM Accelerate（sam sync）的快速迭代、buildspec.yml 中的測試勾點，以及沙箱帳號部署作為部署測試閘門。這是任務 3.2 的主要所在。
• 領域 4（疑難排解，18%）：以 sam logs 和 aws logs tail 追蹤 CloudWatch Logs、CodeGuru Profiler 用於執行時期效能熱點，以及在本機重現生產環境追蹤。

儘管核心任務陳述屬於領域 3，開發測試題目散布於整份考試之中。熟記這套工具鏈，大約能解鎖題庫中約 10% 的可觀分數。

三個測試迴圈的全局視角

AWS 上的每個開發測試工作流程都依循相同模式循環：（1）以測試表達預期行為——單元測試、整合測試或端對端測試；（2）針對測試替身（模擬）、本機模擬器（SAM local、LocalStack）或真實沙箱帳號執行；（3）收集訊號——通過／失敗、日誌輸出、追蹤或分析器火焰圖；（4）將訊號回饋至程式碼。Amazon Q Developer 嵌入這個循環——它在步驟 1 生成測試（/test）、在步驟 1 和步驟 4 審查程式碼（/review），並在步驟 3 解釋失敗（工作區聊天）。把這個循環當作貫穿本章的心智錨點。

白話文解釋

SAM local 測試加上 Amazon Q Developer，乍看之下像是指令列旗標、Docker 容器和 AI 聊天指令交織成的一鍋粥。以下三個類比分別從不同角度點亮工作流程的某個面向。逐一閱讀，抽象概念便會化為熟悉的心智圖像。第一個類比涵蓋本機模擬，第二個涵蓋單元測試作為受控練習，第三個涵蓋 AI 輔助程式碼審查如同身旁的可信夥伴。

類比一——飛行模擬器（本機模擬）

把你的 Lambda 處理函式想成一架客機，生產 AWS 是真實的飛行空域。把全新飛機直接開進商業航線是魯莽之舉，所以航空公司會先讓飛行員在全動式飛行模擬器中訓練。sam local invoke 就是桌面規模的模擬器——空間有限但速度快，非常適合用單一事件酬載演練單次起飛動作。sam local start-api 則是連接了合成 API Gateway 的完整駕駛艙，讓 HTTP 流量感覺如同真實的航管通話。LocalStack 進一步將模擬器擴展成整座模型機場，配備塑膠製的 S3 跑道和你可以滑行其間的 DynamoDB 航廈。這一切都不是真實天空，但每次墜機都能安全地落在地面上。

類比二——駕訓班的三角錐（單元測試）

用 botocore.stub.Stubber 或 aws-sdk-client-mock 對 Lambda 處理函式進行單元測試，感覺就像你第一次學開車時的空曠停車場。教練擺出橘色三角錐代表行人、停放的車輛和狹窄路口——這些佔位物行為可預測，讓你能專注在方向盤和煞車上。被樁接（stub）的 DynamoDB 客戶端就是那個三角錐：它代替真實服務站在那裡，回傳固定的回應，從不離開停車場。你可以在一個下午重複練習同樣的倒車入庫百次，每次微調手的位置，因為沒有任何真實代價。整合測試則在安靜的住宅街道上進行，生產環境才是高速公路。

類比三——坐在你旁邊的配對程式設計師（AI 輔助審查）

Amazon Q Developer 是那位資深工程師，他把椅子滑到你桌旁，整個下午都陪著你。當你用白話文描述一個功能，/dev 便勾勒出檔案結構、編輯範本，並留下一份供你審核的差異比對——就像同事建議說：「我來起草，你來批評。」/review 是同一位同事在你提交之前掃描未提交的變更，指出遺漏的空值檢查或洩漏的祕密，讓人工審閱者根本看不到問題。/test 是那位隊友說：「你思考下一個功能時，我來幫這個函式補上 pytest 測試案例。」CodeGuru Reviewer 是後來在合併時自動審查 PR 的自動化兄弟，CodeGuru Profiler 則是觀察已部署程式碼執行狀況的效能教練。

SAM Local：在筆電上執行 Lambda 函式

SAM Local 是 DVA-C02 期望你在不部署的情況下測試 Lambda 處理函式時第一個想到的工具。它作為 AWS SAM CLI 的一部分出貨，依賴本機安裝的 Docker，並提供三個核心子指令，幾乎涵蓋所有內層迴圈的測試場景。

sam local invoke — 單次 Lambda 呼叫

sam local invoke 以一個 JSON 事件檔案單次執行 Lambda 函式後即退出。指令如下：

sam local invoke ProcessOrderFunction --event events/order-created.json

SAM CLI 讀取 template.yaml，找到 ProcessOrderFunction 資源，拉取符合其 Runtime 屬性的 Lambda runtime Docker 映像（例如 public.ecr.aws/lambda/python:3.12），掛載你的打包程式碼，並將事件檔案透過 stdin 傳入。處理函式執行後，日誌輸出至你的終端機，然後退出。這是針對由 S3、EventBridge、SQS 或 DynamoDB Streams 觸發的事件驅動函式最快的本機回饋迴圈——你只需擷取或手工製作一次事件 JSON，便可隨意重複執行處理函式。

你也可以自動產生具代表性的事件酬載，而非手動編寫：

sam local generate-event s3 put --bucket my-bucket --key file.txt > events/s3.json
sam local generate-event dynamodb update > events/ddb.json
sam local generate-event apigateway aws-proxy > events/apigw.json

sam local generate-event 是「如何為 Lambda 函式取得真實測試事件酬載？」這個問題在考試中的標準答案。

sam local start-api — 本機 API Gateway + Lambda

sam local start-api 在 http://127.0.0.1:3000 模擬 API Gateway，並將 HTTP 請求路由至你 template.yaml 中以 AWS::Serverless::Function 宣告且 Events 類型為 Api 或 HttpApi 的 Lambda 函式。接著你用 curl 呼叫本機端點：

sam local start-api --port 3000
curl http://127.0.0.1:3000/orders -d '{"sku":"ABC"}' -H 'Content-Type: application/json'

每個請求都會為每次呼叫啟動一個全新的 Docker 容器（除非設定了暖容器），這與真實 Lambda 每次請求冷啟動的行為非常接近。當你想演練前端或整合測試將命中的同一份 API 合約時，這就是你該用的工具。

sam local start-lambda — 本機 AWS Lambda 服務

sam local start-lambda 在 http://127.0.0.1:3001 建立一個模擬的 AWS Lambda 服務端點。將 AWS SDK 客戶端指向這個端點：

import boto3
client = boto3.client("lambda", endpoint_url="http://127.0.0.1:3001",
                     region_name="us-east-1", aws_access_key_id="x", aws_secret_access_key="x")
client.invoke(FunctionName="ProcessOrderFunction", Payload=b'{}')

這讓你的整合測試驅動程式能夠透過 SDK 呼叫 Lambda 函式，方式與生產程式碼完全相同——非常適合測試客戶端重試邏輯、SDK 分頁，或透過 Invoke API 呼叫 Lambda 的 Step Functions 工作流程。

以 SAM 在本機除錯

SAM Local 支援透過 --debug-port 將除錯器附加至執行中的 Lambda 容器：

sam local invoke --debug-port 5858 ProcessOrderFunction

VSCode、PyCharm 和 JetBrains IDE 即可附加並在你的處理函式內設定中斷點，即使該處理函式實際上是在模擬 /var/task 的 Docker 容器中執行。

SAM Accelerate 與 sam sync — 中層迴圈加速器

SAM Accelerate 是 V2.1 時代對「我只改了一行 Lambda 程式碼——為什麼部署要花 90 秒？」這個問題的答案。sam sync 是主角指令。它不再每次儲存時重新打包、重新上傳、重新執行 CloudFormation，而是偵測哪些資源變更，並直接透過服務 API 就地更新。Lambda 程式碼更新使用 UpdateFunctionCode；Step Functions 狀態機更新使用 UpdateStateMachine；API Gateway 更新直接呼叫 REST API。典型的來回時間從 60–90 秒降至 10 秒以內。

sam sync --stack-name my-app-dev --watch

加上 --watch，SAM CLI 會持續執行並在每次儲存檔案時重新部署——相當於雲端版的即時重載。這被明確標示為「僅限開發使用」，不能取代在 CI/CD 中由 sam deploy 產生可供審查的 CloudFormation 變更集。

何時使用 sam sync 與 sam deploy

• sam sync --watch：在個人沙箱帳號中進行內層迴圈迭代。速度優先於安全。
• sam deploy：推送至共用環境、預覽變更集，以及 CI/CD pipeline。安全優先於速度。

DVA-C02 將此框架為直接的任務 3.2 題目：「哪個 SAM CLI 指令能加速本機開發期間的迭代？」答案：sam sync。

LocalStack：社群 AWS 模擬器

LocalStack 是一個第三方（社群版開源、Pro 版商業授權）的本機 AWS 雲端模擬器。它在 Docker 中執行，並為包括 S3、DynamoDB、SQS、SNS、Lambda、API Gateway、Kinesis、Step Functions、Secrets Manager、Parameter Store 等在內的眾多服務提供 AWS 相容端點。你只需將 AWS SDK 指向 http://localhost:4566，即可如常呼叫 AWS API。

s3 = boto3.client("s3", endpoint_url="http://localhost:4566",
                  region_name="us-east-1", aws_access_key_id="test", aws_secret_access_key="test")
s3.create_bucket(Bucket="my-bucket")
s3.put_object(Bucket="my-bucket", Key="k", Body=b"hello")

LocalStack 以保真度換取速度：它非常適合演練跨服務流程（S3 → Lambda → DynamoDB）的整合測試，但它並非 AWS 的一比一複製。IAM 強制執行、最終一致性時序，以及部分較新功能是近似模擬，並非精確重現。

LocalStack 與 SAM Local 的比較

• SAM Local 只模擬 Lambda（在 start-api 模式下前置一個本機 API Gateway）。它在 Docker 下使用真實的 Lambda runtime 基礎映像，因此處理函式的執行環境非常接近生產環境。
• LocalStack 模擬更廣泛的 AWS 服務範疇。SQS 佇列、DynamoDB 資料表、S3 儲存貯體、EventBridge 規則等都可在 localhost:4566 存取。各服務的保真度較低。
• 兩者並用：以 SAM Local 進行以 Lambda 為中心的處理函式測試；在測試需要跨越 S3 儲存貯體或 DynamoDB 資料表而不想使用真實 AWS 帳號時，改用 LocalStack。

DVA-C02 不會深入考你 LocalStack 的內部機制，但考試指南 V2.1 關於「本機模擬 AWS 服務」的措辭與 LocalStack 的定位相符。你只需了解它的存在、它是社群維護的產品（非 AWS 官方產品），以及它是整合測試中取代真實沙箱帳號的一個選項。

LocalStack 與 AWS 沙箱帳號的取捨

• LocalStack：不產生 AWS 費用、速度極快、可在筆電上離線執行、保真度較低。
• AWS 沙箱帳號：完整 AWS 保真度、有實際費用、需要網路連線、佈建速度較慢。

成熟的團隊通常依測試類別擇一使用：LocalStack 用於開發者內層迴圈的整合測試，沙箱帳號用於作為 PR 合併閘門的 CI 階段。

SDK 模擬模式：無網路呼叫的單元測試

整合測試很有價值，但最快的測試迴圈是完全不產生網路流量的純單元測試。AWS SDK 模擬程式庫讓你能以回傳固定回應的樁（stub）取代真實客戶端。DVA-C02 認識三種標準模式：Python（boto3）的 botocore.stub.Stubber、Node.js v3 SDK 的 aws-sdk-client-mock，以及 VCR 等卡帶式重播程式庫。

boto3 Stubber（Python）

botocore.stub.Stubber 是在 Python 測試中對 AWS SDK 呼叫進行樁接的內建方式。它讓你能針對客戶端排入預期的回應和錯誤：

import boto3
from botocore.stub import Stubber

client = boto3.client("dynamodb", region_name="us-east-1")
stubber = Stubber(client)
stubber.add_response("get_item",
                     {"Item": {"pk": {"S": "user#1"}, "name": {"S": "Alice"}}},
                     expected_params={"TableName": "Users", "Key": {"pk": {"S": "user#1"}}})
stubber.activate()

# 受測程式碼呼叫 client.get_item(...) → 回傳固定回應

Stubber 也支援 add_client_error，可注入 ThrottlingException、ConditionalCheckFailedException 或 ProvisionedThroughputExceededException 以測試重試與退避邏輯。它包含在 boto3 中，不需額外相依套件。

aws-sdk-client-mock（Node.js v3 SDK）

對於模組化的 AWS SDK for JavaScript v3，aws-sdk-client-mock 是社群標準的模擬程式庫。每個服務客戶端（DynamoDBClient、S3Client、SQSClient）都可以透過流暢的 API 進行模擬：

import { mockClient } from "aws-sdk-client-mock";
import { DynamoDBClient, GetItemCommand } from "@aws-sdk/client-dynamodb";

const ddbMock = mockClient(DynamoDBClient);
ddbMock.on(GetItemCommand).resolves({ Item: { pk: { S: "user#1" } } });

// 受測程式碼呼叫 new DynamoDBClient().send(new GetItemCommand(...)) → 已模擬

你可以按輸入參數比對、以特定錯誤名稱拒絕，以及在測試間重設。對 Node.js 處理函式而言，aws-sdk-client-mock 是「如何對呼叫 DynamoDB 的處理函式進行單元測試？」這個問題在考試中的標準答案。

VCR／卡帶模式

VCR 風格程式庫（Python 的 vcrpy、Node.js 的 node-vcr／nock）在第一次執行時錄製真實的 AWS HTTPS 回應，並在後續執行時重播。錄製的流量以 YAML／JSON「卡帶」檔案形式提交至版本庫。優點：由於錄製的回應來自真實 AWS，保真度極高。缺點：AWS API 變動時必須重新錄製卡帶，且提交前必須清除機密資訊。謹慎使用卡帶——通常用於斷言程式碼正確解析特定 AWS 回應格式的合約測試。

選擇模擬策略

• 對 AWS 呼叫周圍商業邏輯進行單元測試：Stubber／aws-sdk-client-mock。
• 針對真實 AWS 回應格式的合約測試：卡帶／VCR。
• 完整跨服務流程：LocalStack 或沙箱帳號整合測試。
• Lambda 處理函式端對端：以生成的事件執行 sam local invoke。

針對開發帳號的整合測試

在某個時間點，本機模擬的保真度不再足夠，你需要真實的 AWS。DVA-C02 認可的模式是沙箱開發帳號——一個獨立的 AWS 帳號（理想上透過 AWS Organizations 或 Control Tower 佈建），供每位開發者個人實驗使用。整合測試部署至此帳號、演練真實 AWS 服務、斷言結果，然後拆除。主要實踐原則：

• **以帳號隔離，而非以區域隔離。**區域隔離無法防止 IAM 或配額意外。
• 堆疊名稱包含開發者／分支後綴，讓多位開發者得以並存：my-app-jaric-feature-x。
• 測試腳本中使用 sam deploy --stack-name ... --capabilities CAPABILITY_IAM 以確保堆疊可重現。
• 測試後一律以 sam delete 拆除（或按排程清理），避免閒置資源產生費用。
• 在開發帳號上設定 AWS Budgets 警示，以防失控的測試在一夜之間產生鉅額帳單。

這種模式下的整合測試看起來就像呼叫真實 AWS API 的普通測試案例——boto3.client("dynamodb").put_item(...)、等待、讀回、斷言。沒有模擬。這能捕捉 IAM 權限漂移、真實的最終一致性窗口，以及模擬永遠無法暴露的服務限制交互作用。

將測試整合至 CI/CD

在 AWS CodeBuild 的 buildspec.yml 中：

phases:
  install:
    runtime-versions: { python: 3.12 }
    commands:
      - pip install -r requirements-test.txt
  pre_build:
    commands:
      - pytest tests/unit
  build:
    commands:
      - sam build && sam deploy --stack-name test-$CODEBUILD_BUILD_NUMBER --no-confirm-changeset
      - pytest tests/integration
  post_build:
    commands:
      - sam delete --stack-name test-$CODEBUILD_BUILD_NUMBER --no-prompts

這是 DVA-C02 期望的經典三段式架構：單元測試作為建置閘門、部署至臨時堆疊、整合測試作為推送閘門，以及無論如何都會執行的拆除步驟。關於 buildspec 的更深入說明，請參閱 CI/CD pipeline 工具主題。

開發期間的 CloudWatch Logs——sam logs 與 aws logs tail

當 Lambda 函式在開發環境中失敗，你的第一反應應該是追蹤它的 CloudWatch Logs。DVA-C02 考試有兩個指令需要特別注意。

sam logs

sam logs 依 template.yaml 中的邏輯 ID 篩選並追蹤你 SAM 堆疊中函式的日誌：

sam logs -n ProcessOrderFunction --stack-name my-app-dev --tail
sam logs -n ProcessOrderFunction --stack-name my-app-dev --start-time '10min ago' --filter ERROR

--tail 旗標讓串流保持開啟，並在新日誌事件到達時即時印出——在另一個終端機執行 sam sync --watch 時不可或缺。--filter 旗標接受 CloudWatch Logs 篩選條件模式。

aws logs tail

aws logs tail 是原生的 AWS CLI 指令（非 SAM 專屬），可追蹤任何 CloudWatch Logs 群組：

aws logs tail /aws/lambda/ProcessOrderFunction --follow --since 10m
aws logs tail /aws/lambda/ProcessOrderFunction --filter-pattern '{ $.level = "ERROR" }'

--follow 是 CLI 版的 tail -f。當你的 Lambda 日誌以 JSON 格式輸出時（結構化日誌主題強烈建議如此），{ $.level = "ERROR" } 這樣的 JSON 篩選模式即可發揮作用。這兩個指令是 DVA-C02 在開發期間認可的即時日誌追蹤標準答案。

Lambda 主控台的測試事件

Lambda 主控台的測試頁籤讓你能儲存具名事件範本——s3-put、sqs-batch、api-gateway-proxy——並對函式目前已部署的版本觸發它們。這本質上是 sam local generate-event 的網頁 UI 版本。DVA-C02 將「Lambda 測試事件」和「API Gateway 測試主控台」視為第一類開發測試原語，即使沒有本機設定也一樣。

API Gateway 測試主控台

對 REST API 而言，API Gateway 主控台中的每個方法都有一個測試按鈕，可合成一個請求（查詢字串、路徑參數、標頭、主體），呼叫後端整合，並顯示映射後的回應以及執行日誌。這是在開發期間不需接線 curl 就能驗證映射範本或 Lambda 授權者的最快方式。

Amazon Q Developer：V2.1 的 AI 配對程式設計師

Amazon Q Developer 是 DVA-C02 考試指南 V2.1 明確納入範疇的生成式 AI 配對程式設計師。它以 IDE 插件的形式提供給 Visual Studio Code 和 JetBrains IDE（IntelliJ IDEA、PyCharm、WebStorm、Rider、PhpStorm、GoLand、RubyMine），另有 CLI 版本。AWS 管理主控台中也有獨立的 Amazon Q Developer 體驗。就考試而言，請專注於 IDE 功能，因為任務 3.2 關注的是開發測試。

內嵌程式碼建議

當你輸入程式碼時，Amazon Q Developer 會串流顯示幽靈文字補全——從單行提示到完整函式主體。按 Tab 鍵接受。這些建議以公開程式碼加上 AWS 內部最佳實踐訓練而成，因此程式碼片段傾向於直接使用現代 AWS SDK 慣例（JavaScript v3 SDK、帶有分頁器的 boto3 等）。

/dev — 功能開發 Agent

/dev 將 Amazon Q Developer 化為多步驟的程式碼撰寫 agent。你在聊天面板中以自然語言描述功能，/dev 便會規劃、編輯並在你的工作區中建立檔案以實作它。典型提示如下：

/dev 新增一個 GET /orders/{id} 的 API 路由，由讀取 Orders DynamoDB 資料表的 Lambda 函式支撐。更新 template.yaml，在 src/orders/get.py 中新增處理函式，並新增單元測試。

/dev 會產生一份差異比對，你可以逐檔審核、接受或拒絕。對 DVA-C02 而言，/dev 代表 V2.1 的「AI 生成程式碼」能力。

/review — 程式碼審查 Agent

/review 分析你目前的工作區或未提交的變更，找出品質、正確性、安全性和程式碼風格問題。它以嚴重程度和說明呈現發現，類似資深工程師審查 PR。/review 是 CodeGuru Reviewer 的互補工具——/review 在開發者 IDE 中按需執行；CodeGuru Reviewer 則在版本庫的拉取請求上執行。

/test — 單元測試生成

/test 為選取的函式或檔案生成單元測試。你反白標示一個處理函式，在聊天視窗輸入 /test，Amazon Q Developer 便會起草涵蓋正常路徑和錯誤條件的 pytest 或 Jest 測試案例。這是考試中最相關的 Amazon Q Developer 功能——任務 3.2 關注的是測試，而 /test 是 V2.1「AI 為你撰寫測試」的頭號功能。

# 已選取：src/orders/get.py:get_handler
# 由 /test 生成至 tests/test_get_handler.py
def test_get_handler_returns_404_when_item_missing(mocker):
    ddb = mocker.patch("src.orders.get.ddb_client")
    ddb.get_item.return_value = {}
    resp = get_handler({"pathParameters": {"id": "missing"}}, None)
    assert resp["statusCode"] == 404

安全掃描

Amazon Q Developer 對你的工作區執行自動安全掃描，標示硬式編碼憑證、不安全的加密 API、注入風險，以及 AWS 特定的反模式（例如 SAM 範本中過度寬鬆的 IAM 政策）等問題。安全發現內嵌顯示於 IDE 中，可能時提供一鍵修正。對 DVA-C02 而言，這滿足「程式碼中的敏感資料」（任務 2.3）的交叉考點——Amazon Q Developer 在提交之前就能攔截硬式編碼的機密資訊。

文件生成

Amazon Q Developer 能從現有程式碼生成 README 檔案、JSDoc／docstring 注釋，以及架構摘要。/doc 是 Amazon Q Developer 家族中較新的指令，可產生與程式碼實際行為一致的專案層級文件。

工作區聊天

聊天面板以你開啟的工作區為基礎——Amazon Q Developer 對開啟的檔案建立索引，並能回答「DynamoDB 資料表在哪裡定義？」或「解釋這個正規表達式的作用」等問題。這讓熟悉新程式碼庫的速度大幅提升，也是 V2.1「解釋現有程式碼」的能力所在。

自訂功能——讓 Q Developer 與你的程式碼庫對齊

Amazon Q Developer 自訂功能讓團隊能透過 AWS CodeStar Connections 將 Amazon Q Developer 指向自己的私有程式碼庫，使建議反映出團隊的內部 API、命名慣例和工具程式庫。自訂功能是付費功能，透過 IAM Identity Center 管理。對 DVA-C02 而言，你只需知道自訂功能存在，以及它能讓 Amazon Q Developer 的建議更貼近你自己團隊的程式碼風格。

Amazon Q Developer 與 GitHub Copilot——考試框架

DVA-C02 不會要求你商業比較 AI 配對程式設計師，但它會測試你是否知道 Amazon Q Developer 是 AWS 整合的選項，以及其與考試相關的能力包含：內嵌建議、/dev、/review、/test、安全掃描、文件生成、工作區聊天和自訂功能。熟記這八項。

Amazon CodeGuru Reviewer 與 Profiler

Amazon CodeGuru 有兩個與開發測試相關的子服務：CodeGuru Reviewer 負責靜態分析和 PR 審查，CodeGuru Profiler 負責執行時期效能分析。儘管部分來源聲稱 CodeGuru 已從考試中移除，但兩者在 DVA-C02 V2.1 中仍屬考試範疇——考試指南保留了「程式碼品質」和「效能最佳化」的職責，這些職責直接對應到 CodeGuru。

CodeGuru Reviewer——拉取請求上的自動程式碼審查

CodeGuru Reviewer 連接至你的原始碼版本庫（CodeCommit、GitHub、Bitbucket、GitHub Enterprise），並自動分析拉取請求。它找出以下問題：

• AWS 最佳實踐違規（錯誤的 SDK 用法、缺少重試邏輯、不佳的 Lambda 模式）。
• 安全漏洞（硬式編碼憑證、過度寬鬆的 IAM、不安全的反序列化）。
• 程式碼品質問題（資源洩漏、執行緒安全、並發錯誤）。

發現結果以附說明和程式碼範例的 PR 內嵌注釋呈現。這與 Amazon Q Developer /review 互補——CodeGuru Reviewer 在每個 PR 的版本庫層自動執行，而 /review 在IDE 層按需執行。

CodeGuru Profiler——執行時期效能分析

CodeGuru Profiler 以 agent 形式在你的生產或預生產應用程式中執行（Java、Python、基於 JVM 的工作負載），對 CPU 和牆鐘時間進行取樣。它輸出火焰圖並提供建議，識別：

• CPU 熱點方法，消耗超出預期的運算週期。
• 效率低下的熱點（例如，緊密迴圈中低效的字串串接）。
• 特定的 AWS SDK 反模式（每次請求建立新客戶端而非重複使用）。

對 Lambda 而言，CodeGuru Profiler 以 Lambda 層或透過 AWS Distro for OpenTelemetry 附加。Profiler 的建議直接回饋至開發迴圈——關於低效 DynamoDB 查詢的 Profiler 發現，會成為新的單元測試案例（「這個查詢應改用 GSI」），進而成為修正，再進而觸發重新分析。

CodeGuru 與 Amazon Q Developer 安全掃描的比較

• CodeGuru Reviewer：在 PR 層自動執行，語言支援有限（主要為 Java 和 Python），針對版本庫範圍的審查進行調整。
• Amazon Q Developer 安全掃描：IDE 層，在提交前執行，語言支援更廣泛，回饋速度更快。
• 兩者並用：提交前執行 Q Developer 掃描，提交後在 PR 時執行 CodeGuru Reviewer，部署後執行 CodeGuru Profiler。

Lambda 處理函式的單元測試模式

對 Lambda 處理函式進行單元測試，本質上就是對普通函式進行單元測試——但 (event, context) 的處理函式簽名以及大量使用 AWS SDK 的特性，造就了幾個值得熟記的反覆出現的模式。

模式一——將商業邏輯從處理函式中抽離

可測試的 Lambda 會將處理函式拆分為薄薄的轉接器和純商業函式：

# src/orders/get.py
def _fetch_order(ddb, order_id: str) -> dict | None:
    r = ddb.get_item(TableName="Orders", Key={"id": {"S": order_id}})
    return r.get("Item")

def handler(event, context):
    order_id = event["pathParameters"]["id"]
    item = _fetch_order(boto3.client("dynamodb"), order_id)
    return {"statusCode": 404 if not item else 200, "body": json.dumps(item or {})}

測試以 Stubber 覆蓋 _fetch_order，並以一個小型的處理函式層級測試搭配模擬客戶端——這讓 90% 的邏輯保留在純函式測試中。

模式二——使用 Stubber，而非模組層級的 patch

botocore.stub.Stubber 比 mocker.patch("boto3.client") 更乾淨，因為它會驗證呼叫參數和回應格式。

模式三——注入客戶端，不要匯入單例

在處理函式外部建立客戶端（以重用執行上下文），但將它們傳入商業函式，讓測試能夠覆寫它們。這是「輕量級依賴注入」模式，與 Lambda 冷啟動最佳化指南完美搭配。

模式四——以 fixture 驅動事件酬載

將真實的事件 JSON 儲存於 tests/fixtures/（由 sam local generate-event 生成），並在測試中載入。這讓單元測試使用與 sam local invoke 相同的事件酬載，橋接了單元測試與整合測試之間的落差。

模式五——凍結時間以確保冪等性鍵的確定性

使用 uuid.uuid4() 或 datetime.now() 作為冪等性鍵的 Lambda 處理函式，必須以模擬時鐘（Python 的 freezegun、Jest 的 jest.useFakeTimers()）進行測試，以確保測試結果具確定性。

AWS API 的 VCR／卡帶模式

VCR 風格卡帶程式庫是「錄製一次，永遠重播」的測試工具。vcrpy（Python）和 nock／node-vcr（Node.js）攔截 HTTPS 呼叫，將真實的請求／回應對儲存至 YAML 卡帶檔案並提交至版本庫，後續執行時從卡帶重播。

import vcr

@vcr.use_cassette("cassettes/list_buckets.yaml",
                  filter_headers=["authorization", "x-amz-security-token"])
def test_list_buckets():
    s3 = boto3.client("s3", region_name="us-east-1")
    response = s3.list_buckets()
    assert "Buckets" in response

在以下情況使用卡帶：

• 你需要真實的 AWS 回應格式來測試你的解析器。
• 你希望一次錄製，然後快速進行確定性重播。
• 你能接受當 AWS API 版本變更時重新錄製卡帶的代價。

在以下情況避免使用卡帶：

• 請求主體在不同執行間會變化（時間戳記、UUID）。
• 測試需要注入失敗模式——Stubber 更適合這種情況。
• 你無法在提交卡帶前可靠地清除機密資訊。

測試的環境特定組態

每套開發測試策略最終都需要環境特定的組態——不同的 DynamoDB 資料表名稱、功能旗標、LocalStack 與真實 AWS 的端點 URL。DVA-C02 期望你了解三種標準做法：

• SAM 範本 Parameters + !Ref：傳入 Environment: dev|test|prod 並以此分支資源名稱。
• AWS Systems Manager Parameter Store：在處理函式執行時期讀取 /myapp/${env}/dbTable。
• AWS AppConfig：用於具備即時回滾功能的執行時期功能旗標。

在測試中，將環境名稱硬式編碼為 test，撰寫設定 fixture 將測試值填入 Parameter Store（透過 LocalStack 或真實沙箱帳號），然後像生產環境一樣執行處理函式。

常見考試陷阱——開發測試與 Amazon Q Developer

DVA-C02 在題庫中反覆使用相同的幾個開發測試陷阱。徹底學懂它們。

陷阱一——SAM Local 不模擬 IAM

sam local invoke 以你的開發者 AWS 憑證（或 --profile）執行你的處理函式，而非以 Lambda 函式宣告的執行角色。這意味著一個在生產環境中因缺少 IAM 權限而會失敗的函式，可能在本機通過測試。務必在真實 AWS 帳號中執行整合測試以捕捉 IAM 漂移。

陷阱二——Amazon Q Developer 不是部署工具

Amazon Q Developer 生成程式碼、測試、審查和文件。它不負責部署——那是 sam deploy、CodePipeline 和 CodeDeploy 的工作。若情境將 Amazon Q Developer 描述為「處理藍綠部署」，那就是混淆選項。

陷阱三——LocalStack 不是 AWS 產品

「哪個 AWS 自有工具在本機模擬 AWS 服務？」——答案是 AWS SAM CLI（sam local），而非 LocalStack。LocalStack 是第三方產品。

陷阱四——sam sync 使 CloudFormation 狀態漂移

在同一個堆疊上使用 sam sync 後再執行 sam deploy 會產生漂移錯誤，因為 sam sync 繞過了 CloudFormation。請將 sam sync 保留在僅限開發的堆疊中。

陷阱五——/test 生成，不執行

Amazon Q Developer /test 撰寫測試檔案。你仍然需要用 pytest、jest 或你選擇的測試框架執行它們。生成是 AI 的工作；執行是你的 CI/CD 或本機執行器的工作。

陷阱六——CodeGuru Reviewer 不是即時的

CodeGuru Reviewer 在拉取請求時執行，而非每次儲存時執行。即時 IDE 回饋是 Amazon Q Developer 的領域。

陷阱七——Stubber 不產生網路呼叫

botocore.stub.Stubber 在呼叫離開客戶端之前就加以攔截——你的測試不需要網路存取、AWS 憑證或環境變數。若測試似乎停住不動，請檢查是否有程式碼路徑繞過了被樁接的客戶端。

陷阱八——Lambda 主控台測試事件會命中真實 AWS

Lambda 主控台的測試按鈕會呼叫 AWS 中已部署的函式，而非本機副本。若你的處理函式向 S3 寫入，測試將會建立真實的 S3 物件。若要本機隔離，請改用 sam local invoke。

FAQ——開發測試與 Amazon Q Developer

Q1. 對 DVA-C02 而言，用一句話描述 SAM Local 是什麼？

SAM Local 是 AWS SAM CLI 的子指令群（sam local invoke、sam local start-api、sam local start-lambda、sam local generate-event），使用 Docker 在你的筆電上模擬 AWS Lambda 執行環境，讓你無需部署即可測試處理函式、在本機演練 API Gateway，以及生成真實的事件酬載。它是 AWS 自有的「如何在本機執行 Lambda？」解決方案，且依賴 Docker 已安裝。

Q2. 何時應使用 sam sync，何時應使用 sam deploy？

在個人沙箱帳號中進行內層迴圈迭代時使用 sam sync --watch——它繞過 CloudFormation 變更集，直接透過服務 API 更新 Lambda 程式碼、Step Functions 和 API Gateway，將來回時間從 60 秒以上縮短至 10 秒以內。推送至共用環境、預覽變更集，以及任何 CI/CD pipeline 時使用 sam deploy。絕對不要在同一個堆疊上混用兩者，否則會產生 CloudFormation 漂移錯誤。

Q3. Amazon Q Developer 如何加速開發測試？

Amazon Q Developer 為你的 IDE 新增四項與測試相關的功能：/test 為選取的函式生成單元測試，/review 按需執行程式碼品質和安全性審查，/dev 以包含測試的多檔案差異比對實作一項功能，其安全掃描器則在提交前標示硬式編碼憑證和不安全模式。在 DVA-C02 考試中，/test 是重點，因為任務 3.2 明確關注測試。

Q4. Amazon Q Developer /review 與 Amazon CodeGuru Reviewer 有何不同？

/review 在 IDE 中按需執行，針對你目前的工作區或未提交的變更——即時、由開發者主動觸發的回饋。CodeGuru Reviewer 在原始碼版本庫的拉取請求層執行（CodeCommit、GitHub、Bitbucket）——自動化、對整個團隊可見的每次 PR 回饋。兩者互補：提交前用 /review，提交後用 CodeGuru Reviewer。

Q5. 如何在不命中 AWS 的情況下對呼叫 DynamoDB 的 Lambda 處理函式進行單元測試？

對 Python 而言，使用 botocore.stub.Stubber 對真實的 boto3 客戶端排入固定回應——不需要網路呼叫或憑證。對 Node.js v3 SDK 而言，使用 aws-sdk-client-mock 搭配 mockClient(DynamoDBClient).on(GetItemCommand).resolves(...)。兩個程式庫都能讓你注入正常路徑回應、錯誤回應（節流、條件檢查失敗）並斷言輸入參數。將商業邏輯從處理函式中抽離，讓大多數測試能針對純函式而非轉接器。

Q6. SAM Local 與 LocalStack 有何不同？

SAM Local 是 AWS 自有產品，只模擬 Lambda（在 start-api 模式下前置本機 API Gateway）。它拉取真實的 Lambda 基礎映像，因此處理函式保真度高。LocalStack 是第三方社群模擬器，在單一端點 http://localhost:4566 背後涵蓋更廣泛的 AWS 服務範疇（S3、DynamoDB、SQS、SNS、Step Functions、Secrets Manager 等）。各服務的保真度較低。以 SAM Local 進行以 Lambda 為中心的測試，以 LocalStack 進行不想在真實 AWS 帳號中執行的跨服務整合流程。

Q7. 如何在開發期間追蹤 Lambda 日誌？

兩個指令。sam logs -n FUNCTION --stack-name STACK --tail 依 template.yaml 中的邏輯 ID 追蹤 SAM 管理的 Lambda 的 CloudWatch Logs。aws logs tail /aws/lambda/FUNCTION --follow 是通用的 AWS CLI 指令，依名稱追蹤任意 CloudWatch Log 群組，不論是否由 SAM 管理。兩者均接受篩選條件模式——當你的 Lambda 以 JSON 格式輸出日誌時，使用 { $.level = "ERROR" } 這樣的 JSON 篩選條件模式。

Q8. Amazon CodeGuru Profiler 的作用是什麼？應在何時執行？

CodeGuru Profiler 是執行時期分析 agent，對已部署應用程式的 CPU 和牆鐘時間進行取樣，並針對熱點方法、資源洩漏，以及「每次請求建立新客戶端」等 AWS SDK 反模式提供火焰圖和修正建議。請在預備環境或生產環境（而非本機開發環境）執行它，因為它需要具代表性的負載。Profiler 發現結果回饋至開發環境，成為新的單元測試和修正工單，閉合了本機測試無法完成的效能迴圈。

Q9. 我可以對自己的私有程式碼庫使用 Amazon Q Developer 自訂功能嗎？

可以。Amazon Q Developer 自訂功能讓管理員能透過 AWS CodeStar Connections 連接私有版本庫，並訓練一個讓 Q Developer 建議使用你團隊內部 API、命名慣例和工具程式庫的自訂模型。自訂功能是管理員管理的功能，透過 IAM Identity Center 提供，且需計費。對 DVA-C02 而言，你只需知道此功能存在——不會被問到計費或設定步驟。

Q10. 我必須記住哪些 DVA-C02 開發測試指令和工具？

必記：sam local invoke、sam local start-api、sam local start-lambda、sam local generate-event、sam sync --watch、sam logs --tail、aws logs tail --follow；botocore.stub.Stubber（Python）、aws-sdk-client-mock（Node.js v3）；Amazon Q Developer /dev、/review、/test、安全掃描、工作區聊天、自訂功能；Amazon CodeGuru Reviewer（PR 時期的靜態分析）和 CodeGuru Profiler（執行時期火焰圖）；Lambda 主控台測試頁籤和 API Gateway 測試主控台。這些名稱和語法能回答大多數任務 3.2 的題目。

總結——開發測試與 Amazon Q Developer 一覽

• AWS 上的開發測試分為三個迴圈：內層（單元測試，秒級）、中層（SAM local + Docker，秒到分鐘級）、外層（沙箱帳號，分鐘級）。
• sam local invoke、sam local start-api 和 sam local start-lambda 是 AWS 自有的在 Docker 下本機執行 Lambda 的方式。
• sam sync --watch 是 V2.1 中層迴圈加速器；它為了開發速度而繞過 CloudFormation。絕不與同一堆疊的 sam deploy 混用。
• LocalStack 是涵蓋更廣泛 AWS 服務範疇的第三方模擬器；適用於不需要真實 AWS 帳號的跨服務整合。
• botocore.stub.Stubber（Python）和 aws-sdk-client-mock（Node.js v3）是考試認可的 SDK 模擬程式庫。
• VCR／卡帶程式庫錄製並重播真實 AWS HTTPS 流量——適合合約測試，但有機密洩漏風險。
• 針對沙箱開發 AWS 帳號的整合測試能捕捉 IAM、配額和最終一致性問題，這些都是模擬無法發現的。
• sam logs --tail 和 aws logs tail --follow 是 DVA-C02 認可的兩個命令列日誌追蹤原語。
• Amazon Q Developer 是 V2.1 的 AI 配對程式設計師：內嵌建議、/dev 用於功能開發、/review 用於程式碼審查、/test 用於測試生成、安全掃描器、工作區聊天，以及用於對齊團隊程式碼庫的自訂功能。
• /test 是考試權重最高的 Amazon Q Developer 功能，因為任務 3.2 關注的是測試。
• CodeGuru Reviewer 新增 PR 層自動程式碼審查；CodeGuru Profiler 新增執行時期火焰圖和 AWS SDK 反模式偵測。
• 常見陷阱：SAM Local 不模擬 IAM、Amazon Q Developer 不部署、LocalStack 不是 AWS 自有產品、/test 生成但不執行，以及 sam sync 使 CloudFormation 狀態漂移。

掌握這些開發測試概念，任務 3.2 便會成為你在 DVA-C02 考試中正確率最高的部分之一——這套心智模型也直接延伸至 SAM + CloudFormation 部署、CI/CD pipeline 設計，以及使用 CloudWatch 和 X-Ray 進行的部署後疑難排解。