How we improved reporting and monitoring of test automation results

trivago · 2023 · 3. Quy mô lớn · Độ khó: Cơ bản — bài gốc

Bối cảnh

Từ 2015 trivago đã đẩy kết quả test tự động vào ELK. Với web app viết lại (Warp) và continuous delivery, sản phẩm chính có hàng chục release mỗi ngày, nên cần biết nhanh một test e2e hỏng là do PR hay do flaky.
Test Selenium đạt tỉ lệ qua trung bình hơn 99% (dưới 1% hỏng trên nhánh main trong lượt chạy đêm), nhưng phần hỏng lẻ tẻ còn lại vẫn gây nghi ngờ.
Chuyển từ Jenkins nội bộ (report HTML gắn vào job, Jenkins phục vụ luôn) sang GitHub Actions với runner tự host trên GCP; đính report dạng zip vào workflow thì phải tải và giải nén mới xem, khó link từ dashboard.

Test report server: sau mỗi lượt chạy, report HTML (plugin Cluecumber) được gsutil rsync lên bucket GCS theo đường dẫn repo/workflow/run id, phục vụ qua một proxy GCS có liệt kê file; link gắn vào status badge, comment PR, Slack.
Kết quả test thành dữ liệu: plugin của framework test đẩy từng kết quả (từ JSON của Cucumber) lên Kafka, kèm link report; Logstash → Elasticsearch → Kibana, từ một lỗi trên dashboard bấm một lần ra report đầy đủ (bước, ảnh, video). Dashboard mẫu dùng chung, team tự làm dashboard riêng.
Alert flaky xuyên nhánh: Grafana gom lỗi theo tên kịch bản và đếm số base URL khác nhau (mỗi PR/nhánh có máy preview riêng); một kịch bản hỏng trên nhiều nhánh cùng lúc thì báo Slack, vì đó là lỗi chung hoặc flaky chứ không phải lỗi của một PR. Bổ trợ cho job phát hiện flaky chạy đêm trên main.

Theo trivago: tăng mạnh độ tin vào test tự động; report server được team khác dùng cho cả test API và báo cáo Webpack bundle vì không gắn với loại test hay framework.

Một lỗi test chỉ hữu ích khi trả lời nhanh được "lỗi của PR này hay lỗi chung"; số nhánh cùng hỏng một kịch bản là tín hiệu rẻ cho câu hỏi đó.
Đưa kết quả test vào pipeline log/metric sẵn có thì có luôn dashboard, truy vấn và alert.