Lỗi mở lại so với mới


55

Một lỗi đã được mở, sửa, xác minh và đóng. Một tháng sau, nó xuất hiện trở lại trong phiên bản tiếp theo sau vài lần lặp mà không có hồi quy.

Với điều kiện các đặc điểm lỗi là như nhau, bạn sẽ mở lại ID lỗi hiện có hoặc mở một cái mới có liên kết đến lỗi đã đóng?

Câu trả lời:


86

Đặc điểm không bằng nhau nguyên nhân. Lỗi mới có thể có một lý do cơ bản khác, mặc dù nó có vẻ giống nhau. Vì vậy, hãy mở một lỗi mới và chỉ ra lỗi cũ để giúp nhà phát triển.


23
+1 có rất nhiều differnt bệnh với phương pháp điều trị khác nhau mà chia sẻ chung triệu chứng.
Thất vọngWithFormsDesigner

Sẽ công bằng khi suy luận rằng nếu lỗi được chứng minh là có cùng nguyên nhân, bạn có mở lại không?
KMoraz

@KMoraz: Tôi sẽ nghĩ vậy, nhưng đó chỉ là điều cần xem xét sau khi điều tra chứng minh đó là nguyên nhân chính xác . Do các triệu chứng biến mất trong một thời gian, không chắc đó là cùng một lỗi, mặc dù đó có thể là một lỗi được đưa vào một phần khác của hệ thống, nhưng được mã hóa giống như cách mà lỗi ban đầu được mã hóa và do đó gây ra các triệu chứng tương tự.
Thất vọngWithFormsDesigner

1
@KMoraz Tôi sẽ nói không. Giả sử nó đã được sửa trong 1.0, 1.1 thì không có, nhưng nó đã xuất hiện lại vào ngày 1.2. Trừ khi trình theo dõi vấn đề của bạn cho phép bạn liên kết nó với các bản phát hành máy chủ cùng một lúc, bạn sẽ mất lịch sử mà nó được tìm thấy và sửa trong 1.0. Chỉ cần mở một lỗi mới.
Andy

1
@Andy Đừng nghĩ nó thay đổi bất cứ điều gì, nhưng có lẽ 1.1 đã có nó và không ai để ý ...
joshuahedlund

35

Nếu nó được xác minh và đóng, và hoạt động được một lúc, và sau đó xuất hiện lại sau khi một cái gì đó được thay đổi, thì đó không phải là lỗi tương tự. Nó có thể biểu hiện tương tự như lỗi cũ đã làm, nhưng nguyên nhân của nó có thể khác. Vì vậy, nó không phải là cùng một lỗi. Vì vậy, tôi sẽ mở một cái mới, với một liên kết đến lỗi đã đóng.


16

Mở một lỗi mới, luôn luôn. Tại sao? Giả sử nó giống hệt với lỗi trước đó và bạn đã phát hành bản sửa lỗi cho lỗi trước đó. Ghi chú phát hành của bạn sẽ ghi lại rằng "Khắc phục lỗi XXX." Từ quan điểm theo dõi vấn đề và làm cho ghi chú phát hành rõ ràng hơn, tốt nhất nên tham khảo lỗi mới "Khắc phục lỗi XXX + 1 (tương tự nguyên nhân và hậu quả đối với lỗi XXX)" thay vì nói "Sửa lỗi XXX (Một lần nữa) "hoặc một cái gì đó tương tự.


2
Trích dẫn ID lỗi trong ghi chú vá chỉ là .. rất không thân thiện.
Thomas Bonini

3
@krelp Rất hữu ích khi bạn đang làm việc với nhà cung cấp để khắc phục sự cố và bạn có thể theo dõi ID lỗi bạn nhận được bằng id lỗi trong ghi chú phát hành.
Darryl Braaten

1
@Krelp Tôi tự hỏi tại sao đó là một ý tưởng tồi, vì vậy tôi đã hỏi ở đây: lập trình viên.stackexchange.com/questions/142258/ Lời Có lẽ bạn có một số ý kiến ​​về điều đó? :)
Travis Northcutt

Đây là một điểm tốt
KMoraz

4

Nói chung, mở một lỗi mới.

Tuy nhiên, nếu bạn được phép thực hiện một số điều tra trước, tôi sẽ kiểm tra lịch sử của bạn trong mã nguồn .

Nếu bạn làm việc trong môi trường nhóm, ai đó có thể có mã cũ trên hệ thống của họ (nghĩa là họ đã không thực hiện Nhận mới nhất sau khi sửa lỗi ban đầu được kiểm tra), thực hiện các thay đổi và sau đó kiểm tra mà không thực hiện khác biệt. Thực tế tồi, chắc chắn, nhưng nó xảy ra "tất cả các thời gian."

Nhìn vào lịch sử của (các) tệp đã sửa lỗi sẽ nhanh chóng xác nhận hoặc loại bỏ khả năng đó.


1
"(nghĩa là họ đã không thực hiện Nhận mới nhất sau khi sửa lỗi ban đầu được kiểm tra), thực hiện các thay đổi và sau đó kiểm tra mà không thực hiện khác biệt" ... nếu điều đó xảy ra, hệ thống kiểm soát nguồn của bạn bị hỏng
JoelFan

@JoelFan - không nhất thiết. Đôi khi tự động hợp nhất không hoạt động chính xác và đôi khi hợp nhất thủ công cũng không hoạt động chính xác. Hoặc, đó chỉ có thể là trường hợp họ bỏ lỡ thay đổi khi họ thực hiện khác biệt, v.v. Tất cả những gì tôi nói là mùi này có lỗi của con người và kiểm tra lịch sử kiểm soát nguồn trong 2 phút có thể tiết kiệm rất nhiều rắc rối.
Wonko the Sane

1
Kiểm tra lịch sử dù sao cũng đáng giá ... bởi vì nếu hệ thống kiểm soát nguồn của bạn bị hỏng, bạn muốn biết điều đó.
mjfgates

2
Nếu điều đó xảy ra all the time, đó không phải là SCM bị hỏng, đó là nhóm phát triển của bạn ...
Daenyth

1

Tôi đồng ý với đề xuất của người đăng trước để mở một lỗi mới vì nó có thể không phải là nguyên nhân gốc.

Khuyến nghị thêm của tôi sẽ là đảm bảo bạn luôn thêm các bài kiểm tra đơn vị và tích hợp bao gồm lỗi để trong các phiên bản trong tương lai, bạn sẽ khắc phục được sự cố ngay trước khi xảy ra với khách hàng của mình. Không có gì có vẻ tồi tệ hơn với một khách hàng sau đó nhìn thấy cùng một lỗi trở lại.


1

Không phải là sự tương tự tốt nhất - Chỉ vì các triệu chứng của hai người là như nhau, điều đó không có nghĩa là bệnh / nguyên nhân gây bệnh là như nhau.

Từ wikipedia:

Lỗi phần mềm là lỗi, sai sót, lỗi hoặc lỗi trong chương trình hoặc hệ thống máy tính khiến nó tạo ra kết quả không chính xác hoặc không mong muốn hoặc hành xử theo cách không lường trước được. Hầu hết các lỗi phát sinh từ .....

Một lỗi là một lỗ hổng trong mã và nó có các triệu chứng / hiệu ứng. Một lỗi không phải là triệu chứng. Một lỗi là lỗi trong mã. Chỉ vì các triệu chứng giống nhau, điều đó không nhất thiết có nghĩa là cùng một lỗ hổng đang gây ra các triệu chứng.

Hiểu biết của tôi là bạn nên mở lại một lỗi khi bạn biết chắc chắn rằng một lỗi đã gây ra do cùng một đoạn mã. Điều này có thể xảy ra khi mã hoạt động chính xác trong tất cả các kịch bản thử nghiệm / trường hợp thử nghiệm, nhưng không có trong trường hợp thử nghiệm mới hoặc trường hợp thử nghiệm mà bạn không nghĩ về trước đó. Loại kịch bản này có thể không phổ biến.

Kịch bản khác là các triệu chứng tương tự được gây ra bởi các lỗi mới, tức là các lỗi mới trong các phần khác của cùng một mã hoặc thậm chí trong các hệ thống khác ảnh hưởng đến mã đó.

Vì vậy, đặt cược an toàn nhất là mở một lỗi mới khi các triệu chứng tương tự xảy ra. Nếu bạn thấy rằng cùng một mã cũ chịu trách nhiệm cho lỗi này, thì hãy đóng lỗi mới và mở lại lỗi cũ. Nếu không, hãy để lỗi mới vẫn còn và liên kết nó với lỗi cũ.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.