Cách xử lý các lỗi mà tôi nghĩ là tôi đã sửa, nhưng tôi không hoàn toàn chắc chắn

Có một số loại bọ rất khó sinh sản, rất hiếm khi xảy ra và có vẻ ngẫu nhiên. Nó có thể xảy ra, rằng tôi tìm thấy một nguyên nhân có thể, khắc phục nó, kiểm tra chương trình và không thể tái tạo lỗi. Tuy nhiên, vì không thể tái tạo một cách đáng tin cậy lỗi và nó rất hiếm khi xảy ra, làm thế nào tôi có thể chỉ ra điều này trong một bugtracker? Cách phổ biến để làm điều đó là gì?

Nếu tôi đặt statuscố định và solutioncố định, điều đó có nghĩa là một cái gì đó hoàn toàn cố định, phải không?

Có phải thông thường là đặt statuscố định và solutionmở, để chỉ cho người kiểm tra rằng "có thể đã sửa, nhưng cần chú ý nhiều hơn để đảm bảo"?

Chỉnh sửa: hầu hết (nếu không phải tất cả) bugtrackers có hai thuộc tính cho trạng thái của một lỗi, có thể các tên không giống nhau. Bởi statustôi là mới, được giao, cố định, đóng cửa, vv , và bởi solutiontôi là mở (mới), cố định, không thể giải quyết, không tái sản xuất, nhân bản, không phải là một lỗi , vv

Có phải thông thường là đặt trạng thái thành cố định và giải pháp để mở, để chỉ ra cho người kiểm tra rằng "có thể đã sửa, nhưng cần chú ý nhiều hơn để đảm bảo"?

Dù thông thường hay không, đây là điều đúng đắn nên làm và bạn tự đặt ra lý do tại sao: dù thế nào, đó là một cách tiếp cận tốt để

cho người kiểm tra biết rằng "có thể nó đã được sửa, nhưng cần chú ý nhiều hơn để đảm bảo"

Lưu ý bên lề ngay cả khi trình theo dõi lỗi cụ thể không có trường như bạn mô tả solution, nhà phát triển ít nhất có thể thêm nhận xét dạng tự do giải thích ở trên.

_{... Và nếu trình theo dõi lỗi không cho phép thêm nhận xét cho vấn đề thì nó phải được thay thế bằng một bình luận. Khả năng thêm làm rõ biểu mẫu miễn phí là một tính năng cực kỳ quan trọng vì các vấn đề khác nhau quá nhiều để phù hợp với một số hình thức được xác định trước.}

Nhóm thử nghiệm sẽ quyết định xem sự cố đã được giải quyết chưa và liệu nó có thể đóng lại không. Nếu có thêm hồi quy, tác dụng phụ của bản sửa lỗi hoặc nếu bản thân bản sửa lỗi không hiệu quả trong một kịch bản khác, vấn đề sẽ được mở lại. Nhưng nếu bạn đã thực hiện đủ thử nghiệm của nhà phát triển, thì tốt hơn là đánh dấu nó là cố định.

Có những loại bọ rất khó sinh sản, rất hiếm khi xảy ra và có vẻ ngẫu nhiên. Nó có thể xảy ra, rằng tôi tìm thấy một nguyên nhân có thể, khắc phục nó, kiểm tra chương trình và không thể tái tạo lỗi.

Trên thực tế, nếu tôi không có kịch bản kiểm tra có thể lặp lại, tôi thậm chí sẽ không thử sửa lỗi như vậy trước đó. Nếu bạn muốn người kiểm tra chú ý hơn vào nó, hãy cho họ cơ hội để tạo ra một kịch bản có thể tái tạo.

Ví dụ: giả sử bạn thay đổi chương trình và một người thử nghiệm đầu tư 1 giờ vào việc cố gắng tái tạo lỗi và lỗi không bật lên - đã đủ một giờ chưa? Hoặc việc kiểm tra thêm là lãng phí thời gian vì lỗi đã được sửa?

Mặt khác, khi bạn không thay đổi chương trình và lỗi không xuất hiện sau 1 giờ, rất có thể người kiểm tra nên đầu tư thêm một giờ nữa để thử những thứ khác nhau. Và khi người kiểm tra đầu tư một ngày và không thể tái tạo lỗi nữa - nó có thực sự đáng để thử không?

Nói rằng, bạn có thể nghĩ về cách bạn mô hình hóa quá trình đó trong hệ thống theo dõi lỗi của bạn: không cố gắng sửa nó và bàn giao cho người kiểm tra có thể là một trạng thái lỗi như "mở". Nếu người kiểm tra không thể sao chép nó, thì rõ ràng là "không thể tái tạo". Hy vọng, điều này không xảy ra, họ tìm thấy một kịch bản có thể lặp lại, bạn có thể tìm ra nguyên nhân gốc của lỗi, sửa nó và đặt trạng thái thành "đã sửa". Cố gắng tránh đi vào một cái gì đó như "không biết nếu nó đã được sửa".

Đôi khi bằng chứng duy nhất bạn có là hoàn toàn thống kê, ví dụ: nó xảy ra một hoặc hai lần một tháng, nhưng dường như không liên quan đến bất cứ điều gì. Đây là loại lỗi tồi tệ nhất để chẩn đoán và giải quyết mà tôi đã gặp phải, bởi vì bạn không thể biết liệu các bản sửa lỗi của mình có ảnh hưởng với bất kỳ sự chắc chắn nào không. Một trong những điều cuối cùng tôi phải giải quyết đã kết thúc bằng một sửa chữa thống kê: tần suất của triệu chứng giảm xuống còn 10% mà chúng tôi bắt đầu. Mảnh cuối cùng không bao giờ được tìm thấy, hoặc có thể là nó, nhưng không ai có cách nào để nói.

Hai lời khuyên tôi có (1) cho rằng nhiều nguyên nhân có thể có hiệu lực cho đến khi bạn biết khác, và (2) đưa ra giả thuyết làm thế nào các triệu chứng có thể tồn tại, sau đó xé tan mọi dòng logic thậm chí có liên quan từ xa. Đi bộ sâu đôi khi là phương tiện duy nhất để kết thúc thỏa mãn.