本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
版本測試
版本測試會產生並執行測試計畫,以驗證真實環境中的程式碼變更。發行測試代理程式會針對您部署的 Web 應用程式和 REST APIs,執行探索性 UAT 和迴歸測試 — 功能迴歸、使用者旅程驗證、整合測試和邊緣案例探索。
版本測試的運作方式
重要
版本測試會針對您的目標應用程式執行實際請求,包括寫入操作 (POST、PUT、DELETE)。代理程式會探索端點、提交表單和測試錯誤處理,這些動作可能會在目標應用程式中建立、修改或刪除資料。只有在您的風險描述檔可接受變動動作作為探索性測試的一部分時,才使用 。確保您的應用程式可以容忍探索性寫入操作,而不會產生意外後果,例如傳送客戶通知、處理付款或永久刪除記錄。我們建議針對預備部署執行 ;只有當應用程式的寫入操作可安全進行自動化測試時,才應將生產應用程式設為目標。
觸發時,發行測試代理程式:
產生測試計畫 — 根據程式碼變更或使用者提供的測試意圖來建立測試計畫。從提取請求或分支觸發時,計劃以受影響的功能為目標。手動觸發或從聊天觸發時,您可以提供測試意圖,說明要驗證的內容。計畫涵蓋功能正確性、整合行為和面向使用者的案例。
針對執行中的應用程式執行測試 — 根據目標 URL (Web 應用程式或 API 端點),代理程式會探索應用程式並執行產生的測試。對於 Web 應用程式,這包括瀏覽器型 UI 互動和視覺化檢查。對於 APIs,這包括直接 HTTP 端點測試、結構描述驗證和錯誤處理驗證。
報告調查結果 — 結果會傳回特定失敗、受影響的功能、重製步驟和建議的修正。
版本測試支援 Web 應用程式 (React、Angular、Vue、伺服器轉譯) 和 REST APIs。
支援的測試類型
UI 測試 — 使用 Web 應用程式的視覺化互動進行瀏覽器型測試
API 測試 — REST APIs 的直接 HTTP 端點測試
定義測試設定檔
測試設定檔會定義您要測試的 Web 和 API 應用程式,以及必要的組態。每個測試設定檔都會指定目標應用程式及其測試類型。
若要建立測試設定檔:
在 DevOps Agent Web 應用程式中,導覽至左側導覽中的 Release Manager。
選取測試設定檔按鈕。
選擇新增測試設定檔。
使用下列詳細資訊填寫表單:
名稱 — 測試描述檔的描述性名稱 (例如 "MyApp Staging")
目標 URL — 預備或測試應用程式部署的 URL。代理程式會傳送真實的 HTTP 流量,包括寫入操作 (POST、PUT、DELETE)。除非您了解並接受資料修改的風險,否則請勿使用生產 URLs。
測試類型 — 選取 UI 測試 (以瀏覽器為基礎的視覺化互動測試) 或 API 測試 (直接 HTTP 端點測試)
選擇新增測試設定檔以儲存。
從測試描述檔執行測試
從測試設定檔頁面,您可以手動觸發測試執行:
在清單中找到您的測試設定檔。
選擇開始測試。
(選用) 指定特定指示,以及在測試意圖中測試的內容。例如,「驗證結帳流程是否正確處理過期的優惠券」或「使用無效的輸入測試使用者註冊表單」。
代理程式會根據您的意圖產生測試計畫 (如果未提供意圖,則廣泛探索)、執行測試,並在提議變更下的發行管理員區段中報告結果。
從 DevOps Agent 聊天執行測試
從 DevOps Agent 聊天,您可以請求版本測試。請客服人員列出您的測試設定檔,或指定要執行的測試設定檔。客服人員將詢問任何所需的追蹤資訊,例如要測試的內容或要關注的領域。
範例:
「列出我的測試設定檔」
「執行測試設定檔 my-test-profile」
「在我的應用程式上執行版本測試,網址為 https://https://staging.myapp.com 並驗證付款流程」
代理程式會在探索應用程式時回報進度,並傳回具有特定問題清單、螢幕擷取畫面 (適用於 UI 測試) 和重製步驟的結果。
從 IDE 執行測試
從 Kiro IDE 或 Claude Code,編碼代理程式可以叫用發行測試:
首先,安裝 Kiro power 或 Claude Code 外掛程式。
指定測試要求或意圖,描述要驗證的內容 (例如,「驗證重構後驗證登入流程是否有效」)
編碼代理程式會將測試意圖和目標測試設定檔傳遞給發行測試代理程式
發行測試代理程式會產生並執行測試,然後回報問題清單
如果發現問題,編碼代理程式會提供 來修正問題
在 CI/CD 管道中發行測試
GitHub Actions
aws-actions/devops-agent-release-testing@v1 GitHub 動作會在部署後觸發發行測試代理程式,並在遞交或提取請求上將結果報告為 GitHub 檢查執行。
先決條件
在您的客服人員空間中設定的測試設定檔
在您的客服人員空間中透過 Webhook 叫用 DevOps 代理程式設定的
步驟 1:設定 GitHub 儲存庫秘密
在您的 GitHub 儲存庫中,前往設定 → 秘密和變數 → 動作 → 儲存庫秘密並新增:
| 秘密 | 說明 |
|---|---|
| DEVOPS_AGENT_WEBHOOK_URL | 來自 代理程式空間的 Webhook URL |
| DEVOPS_AGENT_WEBHOOK_SECRET | 來自 代理程式空間的 Webhook 簽署秘密 |
如需建立 Webhook 端點的資訊,請參閱 透過 Webhook 叫用 DevOps 代理程式。
步驟 2:將 動作新增至您的工作流程
將發行測試步驟新增至您的工作流程 (例如 .github/workflows/release-tests.yml):
name: Release Tests on: push: branches: [main] pull_request: branches: [main] permissions: checks: write contents: read pull-requests: read jobs: test: runs-on: ubuntu-latest steps: - name: Trigger Release Tests uses: aws-actions/devops-agent-qa@v1 with: webhook-url: ${{ secrets.DEVOPS_AGENT_WEBHOOK_URL }} webhook-secret: ${{ secrets.DEVOPS_AGENT_WEBHOOK_SECRET }} test-profile-id: <YOUR_TEST_PROFILE_ID> test-requirement: <WHAT_TO_TEST> # optional env: GITHUB_TOKEN: ${{ github.token }}
將 取代<YOUR_TEST_PROFILE_ID>為 代理程式空間的測試設定檔 ID (開頭為 ki-)。test-requirement 輸入是選用的 - 用來將代理程式聚焦在特定區域 (例如,「驗證重構後驗證登入流程」)。
動作輸入
| Input | 必要 | 說明 |
|---|---|---|
| Webhook-url | 是 | 來自 代理程式空間的 Webhook URL |
| Webhook-secret | 是 | HMAC-SHA256 身分驗證的 Webhook 簽署秘密 |
| test-profile-id | 是 | 要觸發的測試設定檔 ID (以 開頭ki-) |
| test-requirement | 否 | 用於測試的選用焦點區域 |
必要的工作流程許可
| 權限 | Reason |
|---|---|
| 內容:讀取 | 私有儲存庫中的動作/簽出需要 |
| pull-requests:讀取 | 從合併遞交 SHA 解析 PR 編號 |
運作方式
您的工作流程觸發條件 (例如,部署到預備環境之後)。
動作會在遞交或 PR 上建立 Check Run (
in_progress),顯示為待定檢查。動作會簽署 Webhook 並傳送至您的客服人員空間。
發行測試代理程式會挑選任務,並針對您的應用程式執行測試。
結果會回報為 GitHub 檢查執行 (包含詳細摘要的通過/失敗)。
您可以在從 Agent Space 連結的 DevOps Agent Web 應用程式中檢視完整的執行詳細資訊 (時間軸、測試案例、UI 測試的螢幕擷取畫面)。
檢閱測試結果
測試結果會顯示在 DevOps Agent Web 應用程式的建議變更下的變更區段中。每個測試執行會顯示:
狀態 — 已完成、失敗或進行中
類別 — 版本測試
持續時間 — 測試執行需要多長時間
來源 — 無論是手動觸發、從聊天觸發,還是從 CI/CD 管道觸發
選取測試執行以檢視詳細結果,包括特定測試失敗、螢幕擷取畫面 (適用於 UI 測試)、重製步驟和建議的修正。