Dùng AI đọc diff PR để chọn regression test cần chạy
Playbook giúp QA biến diff PR thành ma trận rủi ro và kế hoạch regression test có lý do rõ ràng. AI hỗ trợ đọc thay đổi, nêu giả định và gợi ý phạm vi; QA vẫn là người xác nhận nghiệp vụ và quyết định cuối cùng.
Một PR chỉ đổi vài dòng trong điều kiện áp mã giảm giá. Nhưng nếu QA chỉ nhìn tiêu đề kiểu “fix discount”, phạm vi regression có thể rơi vào hai cực: chạy full suite tốn thời gian, hoặc bỏ sót luồng quan trọng như checkout và tạo đơn.
Diff mới là bằng chứng trực tiếp về phần mã đã thay đổi. Khi kết hợp diff với AI, QA có thể nhanh chóng chuyển thay đổi đó thành một ma trận rủi ro: thành phần nào bị tác động, hành vi nào cần xác nhận và test nào nên được ưu tiên.
AI không thay thế test strategy. Vai trò phù hợp của nó là đọc nhanh, hệ thống hóa giả thuyết và nêu rõ lý do chọn test. Quyết định cuối cùng vẫn thuộc về QA, dựa trên nghiệp vụ, kiến trúc và dữ liệu thực tế.
Mục tiêu: chọn test có lý do, không chọn theo cảm tính
Regression testing nhằm kiểm tra liệu thay đổi mới có làm hỏng hành vi đã có hay không. Khó ở chỗ mô tả PR hoặc tên file thường không phản ánh đầy đủ phạm vi ảnh hưởng.
Ví dụ, một thay đổi trong logic tính giá có thể liên quan đến:
UI hiển thị tổng tiền;
API tạo đơn;
quy tắc áp khuyến mãi;
thông báo lỗi;
luồng checkout.
Thay vì mặc định chạy toàn bộ test, hãy tạo đầu ra có thể kiểm tra lại:
| Thành phần | Bằng chứng trong diff | Rủi ro cần xác nhận | Regression nên cân nhắc |
|---|---|---|---|
| Logic tính giá | Điều kiện tính tổng thay đổi | Tổng tiền hoặc mức giảm sai | Cart, checkout, API tạo đơn |
| Xác thực mã | Nhánh xử lý lỗi thay đổi | Áp mã không đúng hoặc báo lỗi sai | Mã hợp lệ, không hợp lệ, hết hạn |
| UI checkout | Trạng thái hoặc selector thay đổi | Luồng E2E bị lỗi hoặc không ổn định | Flow checkout liên quan |
AI có thể hỗ trợ lập bảng này. Nhưng đầu vào phải có ngữ cảnh: yêu cầu nghiệp vụ, diff, danh sách test hiện có và các khu vực rủi ro mà team đã biết.
Lấy đúng diff trước khi đưa AI phân tích
Theo tài liệu Git, git diff dùng để hiển thị khác biệt giữa working tree, staging area, commit hoặc các cây mã nguồn. Khi review PR tại local, QA thường cần xem thay đổi của nhánh tính năng kể từ điểm chung với nhánh đích.
Có thể dùng --merge-base:
bash
git diff --merge-base <target-branch> <feature-branch>
Với hai commit hoặc nhánh, tùy chọn --merge-base dùng merge base của chúng làm phía “before”. Điều này giúp tập trung vào thay đổi được đưa từ nhánh tính năng, thay vì so sánh trực tiếp hai đầu nhánh có thể chứa lịch sử riêng.
Nếu chỉ cần xem một khu vực cụ thể, có thể giới hạn theo đường dẫn:
bash
git diff --merge-base <target-branch> <feature-branch> -- <path>
Trên GitHub, vào tab Files changed để xem diff của PR. Tài liệu GitHub khuyến nghị review theo từng file; bạn có thể lọc file, dùng file tree để điều hướng và đánh dấu Viewed để theo dõi tiến độ.
Nếu tổ chức có quyền dùng GitHub Copilot, Copilot Chat trong ngữ cảnh PR có thể hỗ trợ làm rõ mục tiêu thay đổi bằng các câu hỏi như:
text
What problem does this pull request solve?
hoặc:
text
Summarize the goals of this PR based on the linked issue.
Đây là bước lấy ngữ cảnh, không phải bước quyết định test scope. QA vẫn cần đọc linked issue, discussion và acceptance criteria.
Quy trình biến diff thành ma trận rủi ro
1. Chuẩn bị gói ngữ cảnh
Đừng chỉ dán diff và hỏi “cần test gì?”. Cách đó buộc AI phải đoán.
Gói ngữ cảnh nên có:
Mục tiêu PR hoặc acceptance criteria;
Diff đã được lọc theo khu vực cần xem;
Danh sách test, spec hoặc tag hiện có;
Quy ước hệ thống: API, UI, background job, feature flag;
Khu vực bắt buộc smoke test hoặc có rủi ro cao.
Không đưa dữ liệu production, token, cookie đăng nhập, khóa API hoặc thông tin khách hàng vào công cụ AI không được tổ chức phê duyệt. Hãy làm sạch diff hoặc thay dữ liệu nhạy cảm bằng placeholder.
2. Yêu cầu AI phân tích thay đổi trước
Trước khi yêu cầu AI viết test case, hãy bắt nó tách rõ bằng chứng khỏi suy luận.
text
Bạn là QA reviewer.
Mục tiêu PR:
<motaPRhoacacceptancecriteria>
Diff:
diff
<diffdalamsach>
Danh sách test hiện có:
<tenspectaghoacnhomtest>
Hãy lập ma trận rủi ro bằng Markdown với các cột:
Thành phần bị thay đổi
Bằng chứng cụ thể từ diff
Hành vi có thể bị ảnh hưởng
Rủi ro nếu lỗi
Regression test nên chạy
Test mới cần bổ sung
Giả định hoặc thông tin còn thiếu
Chỉ kết luận khi có bằng chứng từ diff hoặc mục tiêu PR.
Đánh dấu rõ mọi suy luận chưa được xác nhận.
Không tự bịa tên test, endpoint hoặc quy tắc nghiệp vụ.
Kết quả mong muốn không phải là checklist chung chung. Mỗi đề xuất cần truy ngược được về thay đổi trong diff hoặc yêu cầu của PR.
3. Chuyển ma trận thành kế hoạch chạy test
Sau khi QA đã xem và chỉnh ma trận, dùng prompt tiếp theo:
text
Dựa trên ma trận rủi ro dưới đây, hãy đề xuất kế hoạch regression test.
<matranruiro>
Phân loại thành:
Bắt buộc chạy trước khi merge
Nên chạy nếu có môi trường và dữ liệu phù hợp
Chỉ cần exploratory test
Không đủ thông tin để quyết định
Với mỗi test, nêu:
Mục tiêu kiểm tra
Precondition hoặc test data cần có
Expected result
Lý do liên hệ với diff
Test hiện có có thể tái sử dụng: <danhsachtest>
Không đánh đồng “file thay đổi” với “chức năng bị ảnh hưởng”.
Đừng ưu tiên chỉ theo số dòng code thay đổi. Một thay đổi nhỏ trong quy tắc tính tiền, phân quyền hoặc xử lý dữ liệu có thể cần kiểm tra kỹ hơn một thay đổi giao diện lớn nhưng thuần trình bày.
Ví dụ: thay đổi điều kiện áp mã giảm giá
Giả sử PR yêu cầu: chỉ áp mã giảm giá khi đơn hàng đạt giá trị tối thiểu. Diff cho thấy điều kiện trong logic tính giá thay đổi và UI checkout có thêm xử lý thông báo khi mã không đủ điều kiện.
AI nên gợi ý các nhóm kiểm tra như sau, với điều kiện QA xác nhận chúng phù hợp nghiệp vụ:
Đơn đạt ngưỡng: mã được áp dụng và tổng tiền đúng.
Đơn dưới ngưỡng: mã không được áp dụng, thông báo phù hợp yêu cầu.
Xóa mã sau khi đã áp: tổng tiền trở về giá trị đúng.
Thay đổi số lượng trong giỏ: kiểm tra trạng thái khi tổng đơn đi qua lại quanh ngưỡng.
Tạo đơn qua API: xác nhận quy tắc phía server phù hợp với quy tắc hiển thị trên UI, nếu kiến trúc hệ thống có cả hai lớp.
Đơn đã có mã hợp lệ: kiểm tra nhánh xử lý mới không làm hỏng trạng thái đang tồn tại.
Nếu team dùng Playwright, một phác thảo test có thể là:
text
Scenario: Reject discount code when cart total is below minimum
Given cart total is below the configured minimum
When user applies a valid discount code
Then discount is not applied
And checkout shows the expected validation message
And order total remains unchanged
Đây chưa phải script hoàn chỉnh. QA cần xác nhận giá trị ngưỡng, nội dung thông báo, cách cấu hình mã và expected result từ ticket hoặc tài liệu nghiệp vụ trước khi tự động hóa.
Kiểm tra đầu ra AI trước khi tin vào test plan
AI có thể nhận ra quan hệ bề mặt trong diff, nhưng không tự biết toàn bộ kiến trúc, dữ liệu test hay quy tắc ngầm của sản phẩm. Trước khi chạy hoặc tạo automation, hãy rà các điểm sau:
Có thay đổi gián tiếp không? Logic dùng chung có thể được gọi từ nhiều luồng.
Expected result đã đúng nghiệp vụ chưa? Không để AI tự đặt mã lỗi, thông báo hoặc quy tắc tiền tệ.
Test nào đã tồn tại? Kiểm tra spec, tag và coverage thực tế để tránh tạo test trùng.
Selector có bền không? Ưu tiên locator ổn định theo quy ước của team.
Test data có phù hợp không? Trạng thái đơn hàng, quyền người dùng và điều kiện thời gian thường cần dữ liệu chuẩn bị riêng.
Có cần exploratory test không? UI state, loading, retry hoặc tích hợp bên thứ ba không nên chỉ dựa vào automation.
GitHub cho phép đặt comment trực tiếp trên dòng diff và gom các comment thành một review trước khi submit. Với phát hiện từ AI, hãy chuyển thành câu hỏi có thể hành động: chỉ ra dòng thay đổi, rủi ro và điều cần xác nhận. Đừng dán nguyên văn nhận xét của AI mà chưa kiểm chứng.
Checklist chốt regression scope
[ ] Đã đọc mục tiêu PR, linked issue và acceptance criteria.
[ ] Đã lấy diff phù hợp với nhánh đích.
[ ] AI đã tách rõ bằng chứng, rủi ro và giả định.
[ ] Mỗi test được chọn đều có lý do liên hệ với thay đổi.
[ ] Expected result đã được xác nhận từ nguồn nghiệp vụ.
[ ] Test automation dùng locator và test data đáng tin cậy.
[ ] Không có credential hoặc dữ liệu production trong prompt.
[ ] Các vùng chưa đủ thông tin đã được ghi lại để hỏi developer hoặc product.
AI hiệu quả nhất khi là người phụ tá đọc diff không biết mệt. QA vẫn là người quyết định rủi ro nào cần ưu tiên, hành vi nào được coi là đúng và regression scope nào đủ cơ sở trước khi merge.
Tài liệu tham khảo
Git: git diff
GitHub Docs: Reviewing proposed changes in a pull request