Lợi nhuận:
- Hiểu mục đích của kiểm thử hồi quy và có thể lựa chọn kiểm thử và đưa ra các trường hợp hồi quy theo những thay đổi của trí tuệ nhân tạo
- Khả năng chẩn đoán nguyên nhân gốc rễ của các thử nghiệm dễ vỡ (thời gian, sự phụ thuộc thứ tự, trạng thái chia sẻ, sự phụ thuộc bên ngoài) và áp dụng các giải pháp lâu dài mà không ngăn chặn triệu chứng
- Khả năng duy trì kỷ luật chạy trước khi phát hành gói đầy đủ trong khi vẫn giữ cho bộ hồi quy nhanh, độc lập và đáng tin cậy bằng cách loại bỏ kiểm tra trùng lặp
Phần mềm thay đổi liên tục; Mọi tính năng mới, mọi bản sửa lỗi đều có thể phá vỡ tính năng đã hoạt động trước đó. Sự gián đoạn tiếp theo của chức năng hoạt động trước đó được gọi là hồi quy. Kiểm tra hồi quy đang kiểm tra lại chức năng hiện có với mỗi thay đổi để nắm bắt những sự xuống cấp này. Theo thời gian, các bộ thử nghiệm này ngày càng lớn hơn — hàng nghìn thử nghiệm — và hai vấn đề lớn nảy sinh: bộ thử nghiệm chậm lại và các thử nghiệm không ổn định — các thử nghiệm không đáng tin cậy đôi khi đạt và đôi khi thất bại trong cùng một mã — phá hủy niềm tin của nhóm vào kết quả thử nghiệm. Trí tuệ nhân tạo (AI) là một công cụ hỗ trợ mạnh mẽ giúp bộ hồi quy được duy trì tốt, nhanh chóng và đáng tin cậy. Nhưng lưu ý chính vẫn là: Mặc dù AI có thể đề nghị "vượt qua" một bài kiểm tra mong manh, nhưng nó thường có thể tạo ra một bản vá che đậy một lỗi thực sự. Công việc của bạn là tìm ra nguyên nhân gốc rễ của sự bất ổn chứ không phải ngăn chặn triệu chứng.
Nguyên nhân cốt lõi của các bài kiểm tra mong manh
Kiểm thử dễ vỡ là vấn đề kiểm thử xảo quyệt nhất: nó không đáng tin cậy cho dù nó vượt qua hay thất bại, đẩy nhóm vào thói quen "chắc là nó lại bị kẹt, chạy lại" - và thói quen này một ngày nào đó sẽ bỏ qua một lỗi thực sự là "không ổn định". Nguyên nhân sâu xa chủ yếu:
- Điều kiện thời gian/cuộc đua: Bài kiểm tra sẽ kiểm tra kết quả mà không cần đợi thao tác kết thúc. Lý do phổ biến nhất.
- Phụ thuộc thứ tự: Các thử nghiệm phụ thuộc vào dữ liệu mà nhau để lại; Nó bị hỏng khi thứ tự thay đổi.
- Trường hợp chung: Nhiều thử nghiệm sử dụng cùng một dữ liệu/người dùng thử nghiệm, xung đột.
- Sự phụ thuộc bên ngoài: Mạng thực, dịch vụ bên thứ ba, thời gian hệ thống, giá trị ngẫu nhiên.
- Sự khác biệt về môi trường: Chuyển sang cục bộ, ở lại CI (môi trường tích hợp liên tục).
Thận trọng: Việc vượt qua bài kiểm tra mong manh bằng cách "thử lại vài lần" thường sẽ che giấu lỗi thực sự tương tranh. Thử lại là một công cụ chẩn đoán, không phải là một phương pháp điều trị. Trước tiên hãy tìm nguyên nhân gốc rễ; Chỉ sử dụng thử lại như là phương sách cuối cùng đối với sự mất ổn định thực sự bên ngoài đã được ghi lại.
Bảo trì thử nghiệm: giữ cho gói hàng hoạt động tốt
Bộ hồi quy giống như một khu vườn; Nếu không được chăm sóc, cỏ dại sẽ xâm chiếm. AI hỗ trợ ba nhiệm vụ bảo trì:
1. Làm sạch bài kiểm tra trùng lặp/không cần thiết. Theo thời gian, một số lượng lớn các trường hợp tích lũy các thử nghiệm giống nhau. AI gợi ý nhóm và hợp nhất các bài kiểm tra tương tự.
2. Chẩn đoán xét nghiệm dễ vỡ. Bạn cung cấp cho AI mã kiểm tra và mẫu không ổn định; gợi ý nguyên nhân gốc rễ có thể và giải pháp lâu dài.
3. Lựa chọn/ưu tiên kiểm tra. Việc chạy toàn bộ gói với mỗi thay đổi sẽ tốn kém. Với phân tích tác động của thử nghiệm (chỉ chọn các thử nghiệm có liên quan dựa trên mã đã thay đổi), AI sẽ đề xuất thử nghiệm nào nên chạy trước. Tuy nhiên, gói phát hành trước đầy đủ là phải.
Kiểm dịch: quản lý quyền kiểm tra dễ vỡ
Bạn nhận thấy rằng quá trình kiểm thử rất mong manh nhưng bạn không có thời gian để khắc phục nguyên nhân gốc rễ ngay lập tức. Phải làm gì? Có hai cách sai: xóa hoàn toàn bài kiểm tra (hành vi đó không còn được lưu giữ nữa) hoặc tắt nó bằng cách thử lại (che đậy lỗi thực sự). Cách đúng là cách ly (tạm thời tách thử nghiệm dễ vỡ khỏi gói chính và theo dõi nó trong một danh sách riêng). Thử nghiệm cách ly không ngăn cản việc hợp nhất phiên bản nhưng vẫn là một khoản nợ rõ ràng và được giải quyết thường xuyên. Điểm quan trọng là: khu cách ly là phòng chờ, không phải thùng rác. Nếu danh sách cách ly ngày càng nhiều thì đây là hồi chuông cảnh báo cho thấy sức khỏe xét nghiệm của đội đang xấu đi. AI có thể xem xét định kỳ danh sách cách ly của bạn và nhóm nó theo nguyên nhân gốc rễ; Nó cho phép các giải pháp tập thể bằng cách tiết lộ các nguyên nhân chung, chẳng hạn như "tất cả 6 bài kiểm tra đều được kết nối với cùng một người dùng thử nghiệm được chia sẻ".
Mẹo: Thêm "chủ sở hữu" và "ngày xem xét lần cuối" vào mỗi bản ghi cách ly. Khu cách ly vô chủ trở thành bãi rác vĩnh viễn; Những bài kiểm tra giòn tồn tại ở đó mãi mãi vì không ai quan tâm.
Bảng chiến lược hồi quy
Trạng thái
Chiến lược
Vai trò của AI
sửa chữa nhỏ
Khu vực bị ảnh hưởng + kiểm tra khói
Chọn các bài kiểm tra liên quan
tính năng mới
Mô-đun liên quan + tích hợp
Đề xuất trường hợp hồi quy mới
công cụ tái cấu trúc lớn
Gói hồi quy đầy đủ
Phân tích khoảng cách bảo hiểm
phát hành trước
Trọn gói + khám phá
Ước tính mức độ ưu tiên và thời lượng
Sửa chữa trực tiếp khẩn cấp
Con đường tập trung + quan trọng
Bộ kiểm tra an toàn tối thiểu
Dấu nhắc yếu / Dấu nhắc mạnh
Yếu: "Bài kiểm tra này đôi khi thất bại, hãy sửa nó."
Mạnh: "Thử nghiệm này thất bại 3 trong số 10 lần chạy, mã không thay đổi. Chẩn đoán nguyên nhân cốt lõi của sự không ổn định: có thể là thời gian/cuộc đua, sự phụ thuộc vào thứ tự, trạng thái chia sẻ, sự phụ thuộc bên ngoài hoặc sự khác biệt về môi trường. Hiển thị dòng nào trong thử nghiệm chỉ ra từng nguyên nhân có thể. Đề xuất giải pháp lâu dài; KHÔNG đề xuất giải pháp ngăn chặn triệu chứng như 'thêm thử lại' — nếu không thể tránh khỏi, hãy viết rõ lý do. Kiểm tra: [mã]. Dấu vết lỗi: [log]."
Lời nhắc mạnh mẽ; hướng chẩn đoán đến nguyên nhân gốc rễ và nghiêm cấm việc ức chế triệu chứng một cách rõ ràng.
Bốn mẫu có thể sao chép
1) Chẩn đoán xét nghiệm dễ vỡ:
Mã kiểm tra này đôi khi đạt và đôi khi thất bại nếu không thay đổi. Liệt kê các ứng cử viên nguyên nhân gốc rễ (chủng tộc, sự phụ thuộc thứ tự, trạng thái chung, sự phụ thuộc bên ngoài, đồng hồ/ngẫu nhiên, sự khác biệt về môi trường) và hiển thị dòng bằng chứng trong bài kiểm tra cho từng nguyên nhân. Đề xuất giải pháp lâu dài; đánh dấu giải pháp ngăn chặn như thử lại là biện pháp cuối cùng và có lý do chính đáng. Kiểm tra: [code] / Mẫu không ổn định: [bao nhiêu lần trong bao nhiêu lần chạy]
2) Đề xuất trường hợp hồi quy:
Thay đổi sau đây đã được thực hiện: [thay đổi/tóm tắt PR]. Liệt kê các hành vi HIỆN TẠI mà thay đổi này sẽ phá vỡ và đề xuất trường hợp kiểm tra hồi quy cho từng hành vi. Đặc biệt nêu bật các lĩnh vực có tác dụng phụ và sự phụ thuộc chung.
3) Dọn dẹp thử nghiệm trùng lặp:
Kiểm tra bộ thử nghiệm dưới đây. Nhóm các trường hợp trùng lặp hoặc chồng chéo để kiểm tra cùng một hành vi; Đề xuất những cái nào tôi nên giữ lại và những cái nào tôi nên kết hợp cho mỗi nhóm. Cảnh báo nếu có nguy cơ mất bảo hiểm. Kiểm tra: [danh sách/mã]
4) Lựa chọn hiệu ứng thử nghiệm:
Các tệp/chức năng sau đã thay đổi: [danh sách]. Từ bộ thử nghiệm hiện có, hãy chọn và căn cứ các thử nghiệm tôi cần chạy trước (những thử nghiệm được liên kết trực tiếp/gián tiếp với mã đã thay đổi). Lưu ý: hãy nhắc tôi rằng tôi vẫn sẽ chạy bộ tiền phát hành đầy đủ.
ba trường hợp nhỏ
Trường hợp 1 - Sai lầm thực sự được che đậy bởi Thử lại. Một đội đã thêm 3 lần thử vào một bài kiểm tra thanh toán còn lại không thường xuyên; Bây giờ bài kiểm tra luôn "đậu". Áp dụng "chẩn đoán thử nghiệm mong manh" cho thấy sự không ổn định xuất phát từ điều kiện chạy đua thực tế: ở mức tải cao, xác nhận thanh toán đôi khi được xử lý kép. Trong nhiều tháng, Retry đã che đậy một lỗi có thể dẫn đến việc mất tiền thực tế trong thời gian thực. Nguyên nhân gốc đã được khắc phục, hãy thử lại.
Trường hợp 2 - Gói hàng bị co lại, tốc độ tăng lên. Một bộ hồi quy gồm 1.400 bài kiểm tra mất 55 phút. Với "làm sạch thử nghiệm trùng lặp", 380 thử nghiệm hóa ra là trùng lặp hoặc bị che đậy; sáp nhập. Gói này giảm xuống còn 900 bài kiểm tra, thời gian giảm xuống còn 34 phút, độ bao phủ không giảm đáng kể. Phản hồi nhanh hơn đã khuyến khích nhóm thử nghiệm thường xuyên hơn.
Trường hợp 3 - Sự phụ thuộc vào đơn hàng. Một bài kiểm tra sẽ luôn đạt cục bộ nhưng nó sẽ thất bại ngẫu nhiên trong CI. Chẩn đoán AI cho thấy bài kiểm tra phụ thuộc vào người dùng được tạo bởi một bài kiểm tra khác, trong CI nó bị hỏng do các bài kiểm tra chạy theo thứ tự song song/khác nhau. Mỗi bài kiểm tra được thực hiện để thiết lập dữ liệu riêng của mình; Sự do dự đã kết thúc.
Những lỗi thường gặp
- Tắt tiếng bài kiểm tra dễ vỡ bằng cách thử lại. Thử lại mà không tìm nguyên nhân gốc rễ; che đậy sai lầm thực sự.
- Văn hóa “mắc kẹt lần nữa”. Thường xuyên bỏ qua kết quả màu đỏ; Một ngày nọ, bỏ qua sai lầm thực sự.
- Không cắt tỉa gói nào cả. Cho phép các bài kiểm tra trùng lặp chồng lên nhau và làm chậm gói.
- Sự phụ thuộc giữa các bài kiểm tra. Các thử nghiệm dựa trên điều kiện/trình tự chung; nguồn của sự không chắc chắn.
- Chỉ kiểm tra phần đã thay đổi và bỏ qua gói đầy đủ. Phím tắt trước khi phát hành; Tác dụng phụ ẩn thoát.
- Dựa vào sự phụ thuộc bên ngoài. Kiểm tra dựa trên giá trị mạng/đồng hồ/ngẫu nhiên thực tế; tự nhiên không ổn định.
Tóm lại
Kiểm tra hồi quy phát hiện những thay đổi phá vỡ các chức năng hoạt động trước đó; Nhưng khi các gói phát triển, sự chậm chạp và quá trình kiểm tra dễ vỡ sẽ làm xói mòn lòng tin. Nguyên nhân cốt lõi của thử nghiệm dễ vỡ thường là do thời gian, sự phụ thuộc vào thứ tự, trạng thái chia sẻ và sự phụ thuộc bên ngoài. AI là công cụ hỗ trợ đắc lực trong việc chẩn đoán, làm sạch và lựa chọn xét nghiệm; Nhưng việc ngăn chặn sự do dự bằng cách thử lại sẽ che đậy những sai lầm thực sự. Tìm nguyên nhân cốt lõi, thực hiện các thử nghiệm độc lập và xác định, cắt tỉa gói thường xuyên, chạy gói đầy đủ trước khi phát hành.
Nhiệm vụ ứng dụng
Chọn một thử nghiệm từ dự án của riêng bạn mà bạn biết là dễ hỏng (hoặc có vẻ không ổn định). Trích xuất các ứng cử viên nguyên nhân gốc rễ và xác minh các dòng bằng chứng trong bài kiểm tra bằng mẫu “chẩn đoán bài kiểm tra dễ vỡ”. Xác định nguyên nhân gốc rễ và thực hiện giải pháp lâu dài mà không cần thử lại. Sau đó, chọn 10 bài kiểm tra từ gói của bạn và tìm những bài kiểm tra có thể kết hợp với "dọn dẹp bài kiểm tra trùng lặp". Báo cáo số lượng điểm không ổn định trong thử nghiệm mà bạn đã giải quyết từ nguyên nhân cốt lõi của chúng và số lượng trường hợp không cần thiết mà bạn đã xóa khỏi bộ phần mềm.
danh sách kiểm tra
- [ ] Tôi đã chẩn đoán được nguyên nhân cốt lõi của bài kiểm tra dễ vỡ; Tôi đã không ngăn chặn triệu chứng đó.
- [ ] Tôi coi Thử lại là biện pháp cuối cùng hợp lý, không phải là cách chữa trị.
- [ ] Tôi đã thực hiện các bài kiểm tra một cách độc lập và mang tính xác định (tách biệt với các phần phụ thuộc bên ngoài).
- [ ] Tôi đã loại bỏ các bài kiểm tra trùng lặp/không cần thiết khỏi bộ hồi quy.
- [ ] Tôi đã chọn thử nghiệm dựa trên sự thay đổi nhưng đã chạy bản phát hành trước gói đầy đủ.
- [ ] Tôi coi trọng mọi màu đỏ, chống lại văn hóa "mắc kẹt lần nữa, vượt qua".