Bản dựng chuyển sang màu đỏ, ai đó nhấp vào “chạy lại”, nó vượt qua và mọi người tiếp tục. Điều này có vẻ vô hại, nhưng các thử nghiệm không ổn định đang dần phá hủy thứ quý giá nhất mà một bộ thử nghiệm có được: niềm tin của mọi người vào nó. Khi lỗi thường là tiếng ồn, lỗi thực sự cũng xuất hiện.

Hướng dẫn này đề cập đến lý do tại sao các bài kiểm tra trở nên không ổn định và cách khắc phục đúng từng nguyên nhân. Chúng tôi đã chạy các bản trình diễn về thời gian và trạng thái chia sẻ trong Python 3.13 và các con số được hiển thị là từ các lần chạy đó. Chúng là những minh chứng nhỏ được thiết kế để làm cho dễ dàng nhận thấy sự không ổn định, do đó tỷ lệ thất bại của bạn sẽ khác nhau.

Kiểm tra không ổn định là gì?

Kiểm thử không ổn định sẽ cho kết quả khác nhau trên cùng một mã. Nó trôi qua trong một lần chạy và thất bại ở lần chạy tiếp theo, mặc dù không có gì trong sản phẩm thay đổi. Quá trình kiểm tra có thể có lỗi hoặc mã có thể chứa một lỗi thực sự không liên tục. Khả năng thứ hai đó chính là lý do tại sao bạn không nên đơn giản loại bỏ chúng.

Tại sao các bài kiểm tra không ổn định lại tốn kém đến vậy

• Mất niềm tin. Khi mọi người cho rằng màu đỏ có nghĩa là “có thể không ổn định”, họ sẽ ngừng điều tra những thất bại thực sự.
• Lãng phí thời gian. Các nhà phát triển dành hàng giờ để chạy lại quy trình và kiểm tra các lỗi không liên quan đến thay đổi của họ.
• Phân phối chậm hơn. Việc hợp nhất và phát hành chờ khi chạy lại, làm suy yếu quan điểm của CI/CD.
• Lỗi ẩn. Các điều kiện cạnh tranh trong sản phẩm có thể trông giống như tiếng ồn khi thử nghiệm và đó là những lỗi gây tổn hại trong quá trình sản xuất.

Sơ lược về các nguyên nhân phổ biến

Nguyên nhân 1: Thời gian và giấc ngủ cố định

Đây là nguyên nhân phổ biến nhất. Quá trình kiểm thử giả định rằng công việc nền sẽ hoàn tất sau một khoảng thời gian trễ cố định. Để thấy được hiệu quả, chúng tôi đã viết một bài kiểm tra nhỏ trong đó công việc mất tới 2 mili giây, trong khi bài kiểm tra chỉ đợi 1 mili giây trước khi kiểm tra:

def flaky_timing():
    result = {}
    def work():
        time.sleep(random.uniform(0, 0.002))
        result["done"] = True
    threading.Thread(target=work).start()
    time.sleep(0.001)        # hope it has finished
    assert result.get("done")

Cách khắc phục là chờ điều kiện thực tế, với giới hạn trên rộng rãi:

def fixed_timing():
    result = threading.Event()
    def work():
        time.sleep(random.uniform(0, 0.002))
        result.set()
    threading.Thread(target=work).start()
    assert result.wait(timeout=1)   # continues as soon as it is ready

Chúng tôi đã chạy mỗi phiên bản 200 lần:

Kết quả không chỉ là độ tin cậy. Phiên bản cố định sẽ di chuyển ngay khi công việc hoàn thành nên thường nhanh hơn. Giấc ngủ dài hơn sẽ làm cho phiên bản đầu tiên ít bị lỗi hơn, nhưng mỗi lần chạy sau đó sẽ chậm hơn và nó vẫn có thể bị lỗi trên máy CI đang bận.

Trong các thử nghiệm trình duyệt, nguyên tắc tương tự cũng được áp dụng. Sử dụng tính năng tự động chờ của Playwright hoặc Selenium waits rõ ràng, thay vì time.sleep:

# Playwright: retries until true or a timeout is reached
expect(page.get_by_text("Order placed")).to_be_visible()

# Selenium: an explicit wait for a condition
WebDriverWait(driver, 10).until(
    EC.visibility_of_element_located((By.ID, "confirmation"))
)

Nguyên nhân 2: Trạng thái chia sẻ và thứ tự kiểm tra

Khi các thử nghiệm chia sẻ dữ liệu, một thử nghiệm có thể ảnh hưởng đến dữ liệu khác và kết quả phụ thuộc vào thứ tự chúng chạy. Hai thử nghiệm này sử dụng một danh sách chung:

store = []

def test_add():
    store.append("x")
    assert len(store) == 1

def test_empty():
    assert store == []

Quá trình chạy của chúng tôi đã xác nhận điều này và đó là lý do tại sao một bộ phần mềm có thể trôi qua trong nhiều tháng và sau đó bị hỏng khi ai đó thêm các lần chạy song song hoặc plugin đặt hàng ngẫu nhiên. Cách chữa trị là sự cô lập:

• Cung cấp cho mỗi bài kiểm tra dữ liệu mới, sử dụng công cụ cố định để thiết lập và dọn dẹp dữ liệu đó. Hướng dẫn pytest của chúng tôi chỉ ra cách thực hiện.
• Tạo các bản ghi duy nhất, chẳng hạn như email có hậu tố ngẫu nhiên, thay cho “người dùng thử nghiệm” được chia sẻ.
• Gói các kiểm tra cơ sở dữ liệu vào một giao dịch và khôi phục nó khi thiết lập của bạn cho phép.
• Chạy thử nghiệm theo thứ tự ngẫu nhiên thường xuyên để những vấn đề này xuất hiện sớm.

Nguyên nhân 3: Ngày, múi giờ và tính ngẫu nhiên

Một bài kiểm tra vượt qua cả tuần có thể thất bại vào thứ Bảy, lúc nửa đêm hoặc vào ngày cuối cùng của tháng. Biến thời gian thành đầu vào, thay vì đọc đồng hồ bên trong logic của bạn:

def is_weekend(today=None):
    today = today or datetime.date.today()
    return today.weekday() >= 5

is_weekend(datetime.date(2026, 11, 7))   # True  (a Saturday)
is_weekend(datetime.date(2026, 11, 9))   # False (a Monday)

Những bài kiểm tra đó cho cùng một câu trả lời vào bất kỳ ngày nào. Tương tự như vậy, hãy đặt một hạt giống cố định cho các giá trị ngẫu nhiên trong các thử nghiệm và ghi lại nó khi bạn sử dụng dữ liệu ngẫu nhiên để có thể tái tạo lỗi. Đừng giả sử một thứ tự cụ thể từ các bộ, từ điển từ các nguồn bên ngoài hoặc các truy vấn cơ sở dữ liệu không có ORDER BY.

Nguyên nhân 4: Bộ chọn giòn

Thử nghiệm tìm thấy nút có div:nth-child(3) > span sẽ bị hỏng khi thực hiện bất kỳ chỉnh sửa bố cục nào và có thể chỉ thất bại đối với một số kích thước hoặc biến thể màn hình. Ưu tiên các công cụ định vị dựa trên những gì người dùng nhìn thấy hoặc các thuộc tính kiểm tra chuyên dụng. Hướng dẫn của chúng tôi về Bộ định vị nhà viết kịch giải thích thứ tự thử chúng. Hoạt ảnh cũng là một nguồn rắc rối thường gặp khác, vì vậy hãy cân nhắc việc tắt chúng trong môi trường thử nghiệm.

Nguyên nhân 5: Dịch vụ và mạng bên ngoài

Nếu thử nghiệm gọi nhà cung cấp thanh toán thực hoặc API của bên thứ ba thì kết quả của thử nghiệm sẽ phụ thuộc vào giới hạn tốc độ và thời gian hoạt động của người khác. Giả lập những cuộc gọi đó cho hầu hết các cuộc thử nghiệm và giữ một số lượng nhỏ các cuộc kiểm tra hợp đồng riêng biệt đối với dịch vụ thực để bạn vẫn biết liệu nó có thay đổi hay không. Hướng dẫn của chúng tôi về thử nghiệm đơn vị và thử nghiệm tích hợp giải thích cách phân chia chúng.

Làm thế nào để chẩn đoán một bài kiểm tra không ổn định

1. Xác nhận. Chạy thử nghiệm nhiều lần mà không thay đổi. Với pytest, một vòng lặp shell đơn giản sẽ hoạt động và một plugin như pytest-repeat sẽ cung cấp cho bạn --count=100.
2. Ghi lại bằng chứng. Lưu nhật ký, ảnh chụp màn hình và dấu vết cho từng lỗi. Trình xem dấu vết của nhà viết kịch đặc biệt hữu ích ở đây.
3. Nhấn mạnh các điều kiện. Chạy nó với CPU hạn chế, song song hoặc theo thứ tự ngẫu nhiên. Làm cho nó thất bại thường xuyên hơn làm cho việc học tập dễ dàng hơn.
4. Kiểm tra nó một mình. Nếu nó luôn vượt qua một mình nhưng không thành công trong bộ phần mềm, nghi ngờ trạng thái chia sẻ.
5. Tìm kiếm các mẫu. Kiểm tra xem máy nào, thời gian trong ngày và các bài kiểm tra lân cận có liên quan.
6. Kiểm tra sản phẩm. Hãy thành thật hỏi xem đây có phải là tình trạng chạy đua thực sự trong ứng dụng của bạn hay không.

Việc thử lại tự động có phải là cách khắc phục không?

Thử lại là một mạng lưới an toàn ngắn hạn hữu ích và chúng không phải là cách chữa trị. Một lần thử lại tự động trong CI có thể giúp công việc tiếp tục diễn ra trong khi bạn điều tra, nhưng một bài kiểm tra cần thử lại để vượt qua vẫn cho bạn biết điều gì đó. Tệ hơn nữa, một lỗi sản phẩm thực sự không liên tục, xảy ra lỗi 20% thường sẽ xảy ra khi thử lại mà không được chú ý.

Sử dụng số lần thử với các quy tắc sau: giới hạn ở một hoặc hai lần, ghi lại mọi bài kiểm tra cần một lần thử và coi danh sách đó là danh sách việc cần làm của bạn. Thử nghiệm được báo cáo là “đã vượt qua khi thử lại” sẽ được coi là sự cố cần điều tra chứ không phải là thành công.

Một quy trình nhóm cho các bài kiểm tra không ổn định

1. Đo lường. Theo dõi những thử nghiệm nào thất bại rồi chuyển tiếp cùng một cam kết. Nhiều công cụ CI và phóng viên thử nghiệm có thể cho thấy điều này.
2. Cách ly. Chuyển một thử nghiệm không ổn định đã được xác nhận ra khỏi quá trình chặn để nó không làm gián đoạn mọi người nhưng vẫn tiếp tục chạy và theo dõi nó.
3. Chỉ định chủ sở hữu và thời hạn. Việc cách ly không có thời hạn sẽ trở thành nghĩa địa.
4. Sửa hoặc xóa. Nếu thử nghiệm không đáng sửa, hãy xóa thử nghiệm đó và kiểm tra xem phạm vi áp dụng của thử nghiệm đó có còn tồn tại ở nơi khác hay không.
5. Ngăn chặn. Chạy thử nghiệm mới nhiều lần trước khi hợp nhất. Một bài kiểm tra thất bại một lần trong năm mươi lần chạy sẽ tốt hơn là bị phát hiện trong sáu tháng.

Hãy coi thử nghiệm không ổn định là một lỗi được ưu tiên chứ không phải là tiếng ồn xung quanh. Mức độ nghiêm trọng và mức độ ưu tiên cũng được áp dụng ở đây, như được đề cập trong mức độ nghiêm trọng so với mức độ ưu tiên. Nếu tình trạng không ổn định phổ biến, hãy đọc về lỗi tự động hóa thử nghiệm rộng hơn và xem xét liệu bạn có quá nhiều thử nghiệm ở cấp trình duyệt hay không.

Lời kết

Các bài kiểm tra không ổn định có vẻ ngẫu nhiên nhưng hiếm khi như vậy. Gần như mọi người đều đưa ra một giả định về thời gian, trật tự, dữ liệu hoặc môi trường không phải lúc nào cũng đúng. Chọn bài kiểm tra thường thất bại nhất trong quy trình của bạn trong tuần này. Chạy nó năm mươi lần, tìm ra giả định và sửa nó mãi mãi. Một bản sửa lỗi thực sự sẽ dạy cho một nhóm hơn một trăm lần chạy lại.

Câu hỏi thường gặp

Tiếp tục học hỏi