BÀI VIẾT
Pipeline xanh nhưng bỏ qua test: kiểm thử chính đường phát hành
Dùng lỗi có chủ đích để kiểm chứng cổng chất lượng, báo cáo, điều kiện chạy và tính độc lập của bộ test trong CI/CD.
Trong bài viết
Màu xanh cần có một ý nghĩa cụ thể
Một tình huống giả định: nhóm đổi thư mục test, pipeline vẫn xanh nhưng không còn tìm thấy ca kiểm tra nào. Không có lỗi ứng dụng nào được phát hiện vì bộ test chưa thực sự chạy. Đây là lý do cần kiểm thử đường CI/CD như một sản phẩm: nó nhận đầu vào, thực hiện quyết định và tạo đầu ra ảnh hưởng đến việc phát hành.
Trước hết, viết ý nghĩa mong đợi của một lần chạy thành công. Ví dụ: đúng bản mã đã được dựng, các nhóm kiểm tra bắt buộc đã chạy, kết quả được thu thập và điều kiện chặn đã được áp dụng. Phân biệt công việc bị bỏ qua có chủ đích với công việc chưa chạy do cấu hình sai. Hai trạng thái ấy không nên cùng bị hiểu thành đạt.
Theo dấu từ thay đổi tới gói được kiểm tra
Chọn một nhánh thử riêng và môi trường không phát hành sản phẩm thật. Ghi những sự kiện cần kích hoạt pipeline như thay đổi ứng dụng, thay đổi test và cập nhật cấu hình. Kiểm tra các điều kiện lọc đường dẫn để biết có vùng mã quan trọng nào vô tình không kích hoạt bộ kiểm tra. Mỗi ngoại lệ cần lý do dễ rà soát.
Đối chiếu mã nguồn được lấy, phiên bản được dựng và gói cuối được kiểm tra. Nếu test chạy trên một bản nhưng bước triển khai dùng bản khác, báo cáo thành công không xác nhận gói sắp phát hành. Giữ định danh bản mã và gói trong bằng chứng. Đừng chỉ dựa vào thời gian chạy gần nhau để kết luận chúng thuộc cùng một thay đổi.
Kiểm tra môi trường dựng từ đầu có đủ phụ thuộc và dữ liệu cần thiết. Một lần chạy dùng bộ nhớ đệm có thể che bước cài đặt thiếu hoặc tệp chỉ tồn tại trên máy người viết. Thử điều kiện không có cache trong phạm vi được phép, rồi so kết quả. Cache nên hỗ trợ tốc độ mà không thay đổi tính đúng của quyết định chất lượng.
Cố tình tạo lỗi để thử cổng chặn
Đưa vào một ca kiểm tra thất bại rõ ràng trên nhánh thử. Kỳ vọng không chỉ là nhìn thấy chữ lỗi trong log: bước tổng hợp phải nhận trạng thái thất bại và chặn đúng hành động phía sau. Lỗi có thể bị che khi lệnh trung gian nuốt mã thoát hoặc bước được cấu hình bỏ qua. Đây là phép thử trực tiếp cho cổng chất lượng.
Tiếp tục thử bộ test không tìm thấy ca nào và công việc bị gián đoạn. Theo chính sách của đội, chúng phải được phân loại riêng để người đọc biết thiếu bằng chứng gì. Kiểm tra báo cáo vẫn được lưu khi test lỗi. Nếu chỉ có báo cáo trong lần đạt, người điều tra sẽ thiếu dấu vết đúng lúc cần hiểu nguyên nhân nhất.
Khi chia test chạy song song, đối chiếu danh sách ca dự kiến với ca thực chạy trên mọi phần. Không chỉ cộng số lượng vì ca trùng có thể bù cho ca bị bỏ sót. Kiểm tra dữ liệu và tài khoản có độc lập không. Một đơn hàng dùng chung bị xóa bởi phần chạy khác dễ tạo lỗi chập chờn và khiến đội mất niềm tin vào kết quả.
Đừng để thử lại xóa lịch sử lỗi
Nếu cho phép chạy lại, báo cáo cần giữ lần thất bại đầu cùng kết quả cuối. Một lần đạt sau thử lại là dấu hiệu cần xem xét, không tự chứng minh lỗi không tồn tại. Phân biệt vấn đề môi trường, bộ test và sản phẩm bằng bằng chứng. Việc tạm cách ly một ca cần người phụ trách và điều kiện đưa trở lại rõ ràng.
Hồ sơ xác nhận pipeline nên gồm sự kiện kích hoạt, bản mã, các nhóm test, trạng thái cổng và báo cáo lỗi thử. AI có thể rà cấu hình hoặc đề xuất tình huống, nhưng phải kiểm chứng hành vi bằng lần chạy thật trong môi trường cho phép. Pipeline đáng tin khi màu xanh mang ý nghĩa đã thống nhất và trạng thái thiếu bằng chứng không bị giấu đi.
Về nguồn tham khảo
Chủ đề tham khảo từ bộ AI Tester Skills. Bài viết và tình huống minh họa được biên soạn lại cho người đọc.
Thảo luận
Bình luận được duyệt trước khi công khai. Email của bạn được giữ riêng tư.