6 phút đọcRead in English
Chạy suite từ CI và theo lịch, và giữ cho test flaky không che mất lỗi thật
Chặn merge pull request bằng VibeQA, chạy mọi suite mỗi đêm, nhận tin khi có lỗi mới, và xử lý test flaky trong CI bằng quarantine mà không giấu bug thật.
Suite đã duyệt chỉ có ích khi chúng chạy đúng lúc (trước khi một pull request được merge, mỗi đêm trên staging, và bất cứ khi nào có người cần) và khi vài test flaky trong CI không dạy mọi người lờ màu đỏ đi. Trong VibeQA, cả ba thời điểm đều khởi động cùng một thứ, một lần chạy cả project: mỗi suite đã duyệt một run, mỗi run trong sandbox mới của riêng nó. Bạn bắt đầu bằng nút Chạy tất cả suite, từ CI, hoặc theo lịch.
API key cho CI
CI nói chuyện với VibeQA qua một API key. Owner và admin tạo key trong Cài đặt → API key. Key chỉ hiện
một lần, và CI gửi nó trong header x-api-key.
Key hành động với tư cách người tạo ra nó, theo vai trò hiện tại của người đó. Nếu vai trò của người đó thay đổi, key thay đổi theo; nếu người đó bị xoá khỏi tổ chức, key của họ ngừng hoạt động. Hãy đặt tên key theo nơi dùng nó, ví dụ "GitHub Actions · storefront", để sau này thu hồi cho dễ quyết.
Chặn merge một pull request
Cũng trang đó có sẵn một workflow GitHub Actions để bạn sao chép. Nó chạy mọi suite đã duyệt của một dự án trên URL preview của pull request, chờ kết quả, lưu báo cáo JUnit và làm job fail khi có suite fail. Phần cốt lõi:
api=https://vibeqa.mintera.world/v1
key="x-api-key: $VIBEQA_API_KEY"
body=$(jq -n --arg name "PR #$PR" --arg url "$APP_URL" '{name: $name, appUrl: $url}')
batch=$(curl -fsS -X POST "$api/projects/$VIBEQA_PROJECT_ID/runs" \
-H "$key" -H 'content-type: application/json' -d "$body" | jq -r .batch.id)
until state=$(curl -fsS "$api/run-batches/$batch" -H "$key") &&
[ "$(jq -r .status <<<"$state")" = finished ]; do sleep 15; done
curl -fsS "$api/run-batches/$batch/junit" -H "$key" -o vibeqa-junit.xml
case "$(jq -r .result <<<"$state")" in
passed) exit 0 ;;
failed) exit 1 ;;
*) exit 2 ;; # error hoặc cancelled: VibeQA không chạy được một số suite
esac
Workflow bản đầy đủ còn bỏ cuộc sau một giờ và huỷ lần chạy; ở đây chúng tôi lược phần đó. Thay vì
appUrl, bạn có thể dùng tên một môi trường đã khai báo trong dự án, ví dụ staging. URL preview phải
truy cập được từ internet; địa chỉ nội bộ và loopback bị từ chối.
Khi mọi run đã xong, result nhận một trong bốn giá trị:
result | Khi nào |
|---|---|
passed | Không có gì fail và không có lỗi |
failed | Một suite fail, hoặc bản thân test của nó bị hỏng |
error | Có suite không chạy được vì phía chúng tôi: hạ tầng hoặc AI model |
cancelled | Mọi run đều bị huỷ |
Workflow thoát với mã 2 cho mọi trường hợp không phải pass hay fail, để bạn tự quyết lỗi phía chúng tôi có nên chặn merge hay không. Đánh dấu job là bắt buộc trong branch protection là xong.
Một giới hạn: VibeQA không đăng commit status hay comment lên pull request. Cổng chặn chính là job CI của bạn và báo cáo JUnit của nó.
Lịch chạy
Trong tab Cài đặt của dự án, mục Lịch chạy chạy tất cả suite theo thời gian biểu: mỗi ngày, ngày làm việc, mỗi thứ Hai, mỗi giờ, hoặc một biểu thức cron của bạn, theo múi giờ bạn chọn. Lịch cũng có thể trỏ tới một môi trường.
Vài quy tắc giữ cho lịch không chồng chất:
- Tối đa mỗi giờ một lần.
- Nếu lần chạy theo lịch trước chưa xong, lần này bị bỏ qua, và lịch ghi rõ lý do.
- Các lần lỡ trong lúc VibeQA ngừng hoạt động không được chạy bù.
Hiện chưa có giới hạn số run mỗi ngày cho từng tổ chức, và một lịch cứ bị bỏ qua mãi cũng không tự tắt.
Nhận tin
Trong Tích hợp, một thông báo gửi kết quả chạy cả project tới Slack, Telegram hoặc kênh khác. Có hai sự kiện dành cho việc này:
- Mọi lần chạy cả project xong: một tin cho mỗi lần Chạy tất cả suite hoặc mỗi lần chạy theo lịch, kèm số suite pass và fail.
- Lỗi mới khi chạy cả project: chỉ khi một suite lần trước pass mà lần này fail.
Tin nhắn liệt kê những gì mới hỏng so với lần chạy trước, những gì đã pass trở lại, và link tới bảng run. Với lịch chạy hằng đêm, sự kiện thứ hai thường là thứ đáng có riêng một kênh.
Lịch sử test
Mỗi suite có tab Lịch sử: mọi test qua các lần chạy gần đây, tỉ lệ pass, và đánh dấu test flaky (giao
diện ghi là "Chập chờn"). Test được ghép giữa các lần chạy theo id case, như TC-2.3, khi tiêu đề có id
đó, và theo tiêu đề trong các trường hợp còn lại.
Một test là flaky khi nó đổi giữa pass và fail ít nhất hai lần trong từ năm kết quả trở lên, hoặc hai lần chỉ pass sau khi chạy lại. Hai lần đổi, không phải một: một test fail rồi pass sau khi được sửa không phải là flaky.
Lịch sử tính theo từng suite. Hiện chưa có danh sách test flaky cho cả dự án hay cả tổ chức.
Quarantine test flaky trong CI
Một test flaky cứ ba đêm fail một lần sẽ dạy mọi người lờ màu đỏ đi. Hãy quarantine nó bằng nút Cách ly, tối đa 30 ngày, kèm lý do, ví dụ "Sandbox thanh toán hay timeout; ticket SHOP-88". Test vẫn chạy và lịch sử vẫn được ghi, nên bạn thấy được khi nào nó ổn lại. Trong thời gian quarantine, chỉ riêng lỗi của nó không làm run fail: run pass với dòng "Đạt: các test lỗi đều đang được cách ly." Bạn có thể Bỏ cách ly sớm.
Quarantine có một giới hạn cứng. Re-verify và dry run vẫn tính test đó, nên quarantine không bao giờ làm im repro của một defect, và dry run trước khi duyệt vẫn báo mọi lỗi.
Chuỗi bài khép lại ở đây
Đây là bài cuối của chuỗi. Chúng tôi bắt đầu với automation testing là gì và vì sao bộ test end-to-end dần xuống cấp, và mọi bài sau đó đều là một câu trả lời cho câu hỏi ấy: test design có người review được, mỗi lần chạy tách biệt, kết quả tách lỗi phía chúng tôi khỏi lỗi của bạn, và bản fix được kiểm ba lần. Nếu muốn thử trên app của bạn, đăng ký miễn phí cho một dự án.