Jak radzić sobie z błędami, które, jak sądzę, naprawiłem, ale nie jestem do końca pewien

Istnieje kilka rodzajów błędów, które są bardzo trudne do odtworzenia, zdarzają się bardzo rzadko i na pozór losowo. Może się zdarzyć, że znajdę możliwą przyczynę, naprawię ją, przetestuję program i nie będę mógł odtworzyć błędu. Ponieważ jednak niemożliwe było wiarygodne odtworzenie błędu i zdarzało się to tak rzadko, jak mogę to wskazać w programie do śledzenia błędów? Jaki jest typowy sposób to zrobić?

Gdybym ustawił na statusnaprawiony, a na solutionnaprawiony, oznaczałoby to coś całkowicie naprawionego, prawda?

Czy powszechną praktyką jest ustawianie na statusnaprawione i solutionotwieranie, aby wskazać testerom, że „prawdopodobnie jest naprawiony, ale wymaga więcej uwagi, aby się upewnić”?

Edycja: większość (jeśli nie wszystkie) tropicieli błędów ma dwie właściwości statusu błędu, być może nazwy nie są takie same. statusRozumiem przez to nowy, przypisany, naprawiony, zamknięty itp. , solutionI mam na myśli otwarty (nowy), naprawiony, nierozwiązywalny, nieodtwarzalny, duplikat, nie błąd itp.

Czy powszechną praktyką jest ustawianie statusu na naprawiony i otwieranie rozwiązania, aby wskazać testerom, że „prawdopodobnie jest naprawiony, ale wymaga więcej uwagi, aby się upewnić”?

Zwykle czy nie, tak i tak należy to zrobić, a ty wyjaśniłeś, dlaczego sam: nie ważne jak, jest to dobre podejście do

wskaż testerom, że „prawdopodobnie został naprawiony, ale wymaga więcej uwagi, aby się upewnić”

Uwaga dodatkowa, nawet jeśli określony moduł śledzenia błędów nie ma pola takiego jak opisywane jako solution, programista może przynajmniej dodać komentarz w dowolnej formie wyjaśniający powyżej.

_{... a jeśli narzędzie do śledzenia błędów nie pozwala na dodawanie komentarzy do problemu, należy je zastąpić takim, który to robi. Możliwość dodawania wyjaśnień w dowolnej formie jest niezwykle ważna, ponieważ problemy różnią się zbyt mocno, aby zmieściły się w określonej z góry formie.}

Zespół testowy zdecyduje, czy problem został rozwiązany i czy można go zamknąć. Jeśli wystąpią jakiekolwiek regresje, skutki uboczne poprawki lub jeśli sama poprawka nie działa w innym scenariuszu, problem zostanie ponownie otwarty. Ale jeśli wykonałeś wystarczająco dużo testów dla programistów, lepiej oznaczyć to jako naprawione.

Istnieją rodzaje błędów, które są bardzo trudne do odtworzenia, zdarzają się bardzo rzadko i wydają się przypadkowe. Może się zdarzyć, że znajdę możliwą przyczynę, naprawię ją, przetestuję program i nie będę mógł odtworzyć błędu.

W rzeczywistości, jeśli nie ma powtarzalnego scenariusza testowego, nie próbowałbym nawet wcześniej naprawić takiego błędu. Jeśli chcesz, aby tester zwrócił na to większą uwagę, daj im szansę na stworzenie powtarzalnego scenariusza.

Załóżmy na przykład, że zmieniłeś program, a tester poświęca 1 godzinę na próbę odtworzenia błędu, a błąd nie pojawia się - czy wystarczyła jedna godzina? A może dalsze testowanie jest stratą czasu, ponieważ błąd został już naprawiony?

Z drugiej strony, jeśli nie zmienisz programu, a błąd nie pojawi się w ciągu 1 godziny, najprawdopodobniej tester powinien zainwestować kolejną godzinę w wypróbowanie różnych rzeczy. A kiedy tester zainwestuje jeden dzień i nie będzie mógł już odtworzyć błędu - czy naprawdę warto wtedy go naprawić?

Powiedziawszy to, możesz pomyśleć o tym, jak modelujesz ten proces w systemie śledzenia błędów: brak próby naprawy i przekazanie go testerom może mieć status błędu „otwarty”. Jeśli testerzy nie mogą go odtworzyć, jest to oczywiście „nie do odtworzenia”. Mamy nadzieję, że tak się nie dzieje, znajdują powtarzalny scenariusz, możesz znaleźć podstawową przyczynę błędu, naprawić go i ustawić status na „naprawiony”. Staraj się unikać czegoś takiego jak „nie wiem, czy to naprawiono”.

Czasami jedynym dowodem, który masz, są czysto statystyczne, np. Pojawia się raz lub dwa razy w miesiącu, ale poza tym pozornie nie ma z tym nic wspólnego. Są to najgorsze rodzaje błędów do zdiagnozowania i rozwiązania, jakie kiedykolwiek spotkałem, ponieważ nie można z całą pewnością stwierdzić, czy wprowadzone poprawki mają wpływ. Ostatni z nich, który musiałem rozwiązać, zakończył się poprawką statystyczną: częstotliwość objawów spadła do 10%, od której zaczęliśmy. Ostatni kawałek nigdy nie został znaleziony, a może był, ale nikt nie miał pojęcia, co powiedzieć.

Dwie porady, które mam (1) zakładają, że wiele przyczyn może obowiązywać, dopóki nie dowiesz się inaczej, oraz (2) hipotezę, w jaki sposób objawy mogą istnieć, a następnie rozerwij każdą linię logiki, która jest nawet zdalnie zaangażowana. Głębokie instrukcje są czasem jedynym sposobem na satysfakcjonujący koniec.