Duża stłuczka to dowód, a nie wyjaśnienie.
Gdy zapis nie jest wczytywany, zadanie znika, lub migracja narusza zasadę gry, pierwszy artefakt może być ogromny: setki pól, zagnieżdżone kolekcje, długa historia akcji, migawka treści i środowisko, które już nie istnieje. Ten artefakt jest cenny, ponieważ reprodukuje problem. Jest to trudne, ponieważ daje deweloperowi znacznie więcej informacji, niż mogą one uzasadnić na raz. Czytanie go linia po linii często tworzy przypuszczenia, a nie wyjaśnienie.
Delta debugowanie zmienia cel. Zamiast prosić osobę, aby dostrzec jedną odpowiednią wartość, zapytaj deterministyczne przewidywać, czy kandydat nadal wykazuje niepowodzenie. Następnie usunąć lub uprościć części stanu, podczas gdy przewidywanie pozostaje prawdziwe. Końcowym wynikiem jest minimalny przypadek regresji: wystarczająco mały, aby dokonać przeglądu, stabilny wystarczająco, aby powtórzyć, i wyraźnie o niezmiennym, który pozostaje złamany.
Minimalne nie oznacza wizualnie malutki lub uniwersalnie najmniejszy. Przydatnym celem jest materialnie zredukowane counterexample w ramach ograniczonego kosztu. Reduktor może zatrzymać się, gdy nie można usunąć całej grupy, gdy budżet wykonania jest wyczerpany, lub gdy oprawa jest zrozumiały na tyle, aby stać się test regresji. Zachowana własność ma znaczenie więcej niż abstrakcyjny optymalny.
Ustanowienie odtwarzalności przed redukcją
Redukcja działa tylko wtedy, gdy awaria jest powtarzalna. Najpierw uchwyć dokładną prognozę: czy obecny ładowarka wyrzuca zastrzeżony błąd, czy niezmienny zwraca false, czy wynikowy stan różni się semantycznie od oczekiwanego wyniku, czy też sekwencja działania powoduje niepoprawną dotację? Unikać używania niejasnego prognozowania, takiego jak "gra wygląda źle". Przewidywanie musi zwrócić tę samą odpowiedź dla tych samych wejść, lub reduktor będzie gonić hałas.
Zapis środowiska obok kandydata: tworzenie aplikacji lub commit, wersja migracyjna, wersja adaptera, zawartość i konfiguracja migawki, deterministyczny materiał siewny, założenia platformy i hash urządzenia startowego. Jeśli zegar na żywo, losowe źródło, zdalna konfiguracja pobrać lub pracownik tła może zmienić wynik, zastąpić go determinującą granicą testową lub zapisać go jako wyraźne ograniczenie. Reduktor nie może potajemnie testować nowego środowiska przy każdej próbie.
W przypadku awarii action- sekwencji, zachować stan początkowy i uporządkowane działania oddzielnie. Stan końcowy może ukryć operację, która go wyprodukowała. Uchwyt sekwencyjny może wyrazić "zacząć od tego profilu, wykonać te siedem żądań, a następnie niezmienny zawodzi". Ta separacja pozwala reduktora zmniejszyć pola, kolekcje i działania bez mylenia jednego rodzaju dowodów dla innego.
Zredukuj pola i zbiory w partycjach
Zacznij od grubych partycji. Podziel górny poziom zapisu na grupy pól, usuń jedną grupę z kopii roboczej i uruchom predykat. Jeśli awaria będzie trwać, zachowaj usunięcie; jeśli zniknie, przywróć grupę i podziel ją. Jest to bardziej efektywne niż usunięcie jednego pola na raz z dużego obiektu. Kontynuuj do zagnieżdżonych rekordów i kolekcji, gdy zostanie zidentyfikowany odpowiedni region.
Kolekcje wymagają szczególnej opieki. Pozycje inwentaryzacyjne, rekordy zadań, liczniki i historia zdarzeń mogą odnosić się do siebie. Usunięcie jednego wpisu może zmienić indeksy listy, zasady wydajności lub bilans agregatów. Normalizacja zamawiania w przypadku, gdy zamówienie nie ma znaczenia, zachowanie stabilnych identyfikatorów tam, gdzie wymagają ich odniesienia, oraz stwierdzenie, czy brakujący element powinien być nieobecny, zerowy, czy też reprezentowany przez wyraźny spadek spuścizny. Reduktor nie powinien przekształcać rzeczywistej wady migracyjnej w błąd parsera spowodowany przez nieprawidłowo ukształtowane wejście testowe.
Użyj wartości kurczącej się po redukcji strukturalnej. Przesuń liczbę całkowitą w kierunku zera lub ważnej granicy, skróć struny, zastąp długi identyfikator bezpiecznym identyfikatorem testowym i zredukuj znaczniki czasu do stabilnej epoki tylko wtedy, gdy ich dokładna wartość nie jest warunkiem testowym. Każde uproszczenie musi utrzymać przewidywanie prawdziwe. To często ujawnia, że pozorny złożony błąd profilu jest naprawdę "jeden emerytowany ID elementu plus pełny inwentarz" lub "jeden ujemny licznik po pominiętej wersji".
Ograniczenie sekwencji akcji bez zmiany ich znaczenia
Niektóre błędy pojawiają się dopiero po czasie: zakup ponownie spróbować po ponownym połączeniu, zapisać po aktualizacji konfiguracji, lub migracji po przerwaniu tutorial. Zastosuj tę samą partycjonującą ideę do działań. Usuń przyległą połowę sekwencji, powtórnie i zachować usunięcie, jeśli niezmienny nadal zawodzi. Następnie subdivid. Zachować wymagane działania konfiguracji, ale wyzwanie przypadkowej nawigacji, powtarzające się odczyty i niepowiązane mutacje.
Działania powinny mieć stabilne parametry i oczekiwania. Reduktor, który zastępuje każde żądanie nowym identyfikatorem transakcji losowej, nie testuje już oryginalnej semantyki ponownych prób. Reduktor, który usuwa początkowe obciążenie flagi może zmienić kontekst konfiguracji. Identyfikacja działania zapisu, odpowiednie dane wejściowe, zaufane i niezaufane źródło oraz punkt, w którym sprawdzany jest invariant. To sprawia, że sekwencja końcowa jest przydatna zarówno dla deweloperów jak i QA.
Gdy sekwencja zależy od współzależności, wybierz terminarz determinalistyczny. Zapisuj kolejność, w której pracownicy lub symulowani klienci osiągają krytyczne granice. Jeśli awaria występuje tylko w ramach wyścigu, test może potrzebować kontrolowanej bariery, a nie zależnej od czasu rozmowy uśpienia. Celem nie jest udawanie współzależności jest proste; jest to, aby obserwowane wzajemne powtarzalne się na tyle, aby uzasadnić.
Zachować naruszonego niezrównoważonego w ostatecznym artefakcie
Małe urządzenie bez twierdzenia staje się kolejnym tajemniczym plikiem. Przechowuj naruszonego niezmiennego obok urządzenia w sposób jasny: duplikat uprawnienia do jednej tożsamości transakcji, nieznany numer katalogowy po migracji, negatywna waluta, niedostępny zakończony quest, lub semantyczne niedopasowanie po podróży w obie strony. Wpisz oczekiwaną klasyfikację i obserwowany. Oprawa powinna zawieść z jakiegoś powodu, nie tylko dlatego, że funkcja zwraca fałszywe.
Porównaj przed i po stanie semantycznie. Surowy diff może zawierać przepisywane znaczniki czasu, ponownie uporządkowane tablice, generowane identyfikatory, lub serializacyjne formatowanie. Semantyczne diff podkreśla wartości, które wpływają na niezmiennym. Może zgłosić, że element zmienił się z ważnego spadku spadków do nieznanego ID, lub że równowaga została zwiększona dwukrotnie dla tego samego klucza księgi. Zachować standaryzer wąski i udokumentowany; szeroki standaryzer może usunąć bardzo wady reduktor ma na celu zachowanie.
Napisz manifest powtórki ze ścieżką mocowania, haszem źródłowym, zredukowanym hashem, odciskiem środowiskowym, nasionem deterministycznym, sekwencją działania, jeśli istnieje, przewidywać nazwę i oczekiwany wynik. Ten manifest pozwala innej osobie ponownie uruchomić sprawę bez dostępu do oryginalnego stanu przerostu. Sprawia to również, że urządzenie jest odpowiednie dla CI, gdzie zminimalizowany przypadek powinien być szybki i jasny, a nie zależny od prywatnej maszyny lokalnej.
Wiedz, kiedy należy zatrzymać redukcję
Każdy przewidywany czas trwania. Niektóre migracje są powolne; niektóre scenariusze wymagają adapterów serwisowych; niektóre warunki niepowodzenia są niepewne, dopóki środowisko nie zostanie ustalone. Ustaw budżety na próby, czas ścienny i licznik artefaktu. Zatrzymaj, gdy oprawa jest na tyle mała, aby wyjaśnić problem, gdy nie można usunąć partycji bez utraty awarii, lub gdy pozostała praca wymaga oceny domeny, a nie mechanicznego kurczenia.
Redukcja ma ograniczenia. Nie może zdecydować, czy dziedziczny element powinien mapować do zamiany, czy emerytowany quest potrzebuje rekompensaty, czy też zachowana wartość jest zgodna z prawem w przeprojektowanej gospodarce. Są to decyzje produktowe. Nie może również bezpiecznie ograniczyć zaszyfrowanych lub wrażliwych danych poprzez skopiowanie ich do szerokiego oprzyrządowania. W takich przypadkach należy stworzyć syntetyczny odpowiednik, który zachowuje stan strukturalny, czy też utrzymać ograniczone dochodzenie w odpowiedniej granicy dostępu.
Nie publikuj stanu surowego gracza jako utrwalacz regresji. Nazwy strip, dane kontaktowe, dane odbiorcze, identyfikatory urządzeń, żetony dostępu, i wszelkie pola nie potrzebne do przewidywania. Minimalne utrwalenie jest okazją do poprawy prywatności, jak również diagnozy. Ostateczny artefakt powinien być bezpieczny, aby włączyć do projektu korpus testowy i wystarczająco przydatne, aby zapobiec nawrotom.
Praktyczna lista kontrolna
- Określić determinującą awarię przewidywać przed usunięciem jakiegokolwiek stanu.
- Zapis środowiska aplikacji, adaptera, zawartości, konfiguracji, nasion i oprawy.
- Zachować stan początkowy i sekwencję działania oddzielnie, gdy zachowanie rozwija się w czasie.
- Zredukuj najpierw grupy najwyższego poziomu, a następnie zagnieżdżone pola, kolekcje i wartości.
- Zachowanie referencji i ważności strukturalnej przy jednoczesnym kwestionowaniu znaczenia semantycznego.
- Używaj kontrolowanego harmonogramu konkursowego zamiast powtarzania zależnego od czasu.
- Przechowywać naruszone niezmienne, oczekiwana klasyfikacja, semantyczny diff, i repease manifest z wynikiem.
- Zatrzymaj się na przydatnym ograniczonym liczniku; nie optymalizować na czas nieokreślony dla teoretycznej minimalności.
- Redakcja lub syntetyzacja danych wrażliwych przed przystąpieniem do rutynowych testów.
Często zadawane pytania
Delta debuguje tylko w wypadku?
Nie. Przewidywanie może być katastrofą, ale może to być również naruszona gra niezmienna, błędne odliczanie uprawnień, nieudany save- load podróż, odrzucona klasyfikacja migracji, lub niedopasowanie między oczekiwanym i obserwowanym stanem. Jest to najbardziej przydatne, gdy złożone wejście niezawodnie daje wynik, który nie powinien wystąpić.
Co jeśli awaria jest przerwana?
Najpierw zmniejszyć niedeterminowość. Napraw nasiona, uchwycić konfigurację, izolować granice czasu i sieci, a concurrency. Jeśli wynik pozostaje probabilistic, użyj roleold- oparte przewidywania tylko z ostrożnością i rekordu, że ograniczenie. Stabilny mniejszy scenariusz jest zazwyczaj cenniejszy niż duży płaski osprzęt.
Czy reduktor może działać na podstawie danych produkcyjnych?
Rutynowa redukcja nie powinna. Użyj syntetycznych lub zredagowanych uchwytów i kontrolowanego środowiska. Ograniczone dochodzenie incydentów może potrzebować chronionych dowodów, ale to jest oddzielny proces operacyjny z kontroli dostępu, zasad zatrzymywania, i przeglądu. Nie zrobić regresji pakiet kopii danych gracza.
Co twierdzi Persistium tutaj?
Persistium jest w fazie rozwoju jako rodzina produktów local- first niezawodności. Ta uwaga przedstawia ogólnie użyteczny przepływ pracy redukcyjnej i nie twierdzi, że produkt publiczny automatycznie diagnozuje arbitralne oszczędności, zaobserwował niepowodzenia klienta, lub obsługuje usługi analizy hostingowej.
