Jak wiedzieć, kiedy przestać testować?

Wiem, że to bardzo podstawowe pytanie. W przypadku niektórych aplikacji istnieje duża, prawie nieskończenie duża liczba przypadków testowych dla aplikacji. Testowanie wszystkich tych przypadków testowych nie jest praktyczne. Jak decydujemy, kiedy przestać testować? (inne niż „kiedy zabraknie pieniędzy”).

Książka Glenford Myers The Art of Software Testing ma prostą, ale opartą na zasadach zasadę: Testowanie jest zakończone, gdy przestaniesz znajdować błędy. Lub, bardziej praktycznie, gdy tempo znajdowania nowych błędów znacznie spada.

Błędy mają tendencję do „klastrowania” w niektórych modułach i niektórych funkcjach: w momencie znalezienia błędu w jednym, wiesz, że powinieneś poszukać go dalej, aby znaleźć więcej błędów. Aby znaleźć błędy, możesz skorzystać z technik testowania blackboksów, testów whiteboksów i mutacji. Dopóki znajdziesz błędy, wiesz, że proces testowania działa!

Aby wizualizować swoje postępy, wykreśl liczbę błędów, które Twój zespół znalazł dziennie. Jeśli wykres spadnie, wiesz, że techniki, których używa Twój zespół, i tak ich nie znajdą. Oczywiście, jeśli uważasz, że twoje techniki nie są na równi, przeczytaj książkę Myersa i zastosuj zasady.

Teraz istnieje szansa, że ​​brakuje Ci nowej łatki błędów, a wskaźnik znajdowania błędów znacznie by się zwiększył, gdybyś nadal testował trochę więcej. Jeśli jednak uważasz, że Twoje techniki są prawidłowe, jest to mało prawdopodobne.

Prosta odpowiedź brzmi: to zależy od systemu. Jeśli piszesz wbudowane oprogramowanie do monitorowania serca lub narzędzia do monitorowania bezpieczeństwa reaktora jądrowego, standard jest znacznie wyższy niż w przypadku pisania platformy blogowej.

To jest naprawdę pytanie dla dobrego testera systemu (i nie jestem nim), ale dam mu szansę.

Podstawową miarą będzie zasięg testowy: Ile faktycznie przetestowano aplikacji (zarówno testem jednostkowym, jak i funkcjonalnym).

Musisz ocenić każdy potencjalny przypadek użycia (i parametry dla tego przypadku użycia) pod kątem prawdopodobieństwa faktycznego użycia (abyś mógł upuścić przypadki skrajne), złożoności (prostsze rzeczy mają mniejsze prawdopodobieństwo błędów, a raczej mniej prawdopodobne znaleźć błędy), koszty testowania (pod względem czasu) i potencjalny wpływ defektu, jeśli zostanie wykryty w tym obszarze (tutaj pojawia się reaktor jądrowy vs. platforma blogowa).

Na podstawie tej oceny musisz dowiedzieć się, które z nich zostaną przetestowane i jak szczegółowo. Gdy masz już taką listę, zespół (w tym kierownik produktu / kierownik projektu / przedstawiciel użytkownika) może przejrzeć tę listę i ustalić priorytety na podstawie posiadanych ograniczeń.

Jedną z przydatnych technik do przemyślenia jest to, że możesz również zmieniać przypadki użycia testowane z każdym wydaniem. Na przykład możesz mieć listę niekrytycznych przypadków testowych i przetestować połowę z nich w jednym wydaniu, a połowę w kolejnym (potem na przemian). W ten sposób zwiększasz całkowity zasięg testu dla wysiłku (chociaż istnieje ryzyko wprowadzenia błędów regresji).

Może to również obejmować testowanie platformy - jeśli obsługujesz dwa zaplecza bazy danych (lub wiele przeglądarek), przetestuj połowę aplikacji na jednej, drugą połowę na drugiej, a następnie zamień następną wersję.

(Myślę, że to się nazywa rozbierania, ale nie cytuj mnie w tym.)

Ostatnią rzeczą do przemyślenia nie jest to, co testujesz, ale to, co naprawiasz po wykryciu problemów. Często mówi się „napraw wszystkie błędy”, ale w rzeczywistości istnieje presja czasu i nie wszystkie błędy są równe. Ponownie, regularne zarabianie błędów ze wszystkimi odpowiednimi stronami jest najlepszym rozwiązaniem. Jest to szczególnie istotne tam, gdzie naprawa błędu może być szczególnie uciążliwa, ponieważ generowane przez nią dodatkowe prace związane z ponownym testowaniem i testami regresji mogą przewyższać korzyści wynikające z poprawki.

Gdy ryzyko związane z użytkowaniem oprogramowania zostało zmniejszone do akceptowalnego poziomu.

„Testy programowe można wykorzystać do wykazania obecności błędów, ale nigdy do wykazania ich nieobecności!” - Egerger Dijkstra

Coś dobrego, o czym należy pamiętać podczas wykonywania testów, zautomatyzowanych lub w inny sposób. Możesz tylko udowodnić, że nie znalazłeś więcej błędów, a nie, że już ich nie ma.

Ale im więcej oczu poświęcisz sekcji kodu, tym bardziej będziesz pewny, że działa poprawnie. To bardzo przypomina cytat Knutha na temat optymalizacji pod tym względem: możesz bardzo łatwo testować niewłaściwe rzeczy i możesz testować w niewłaściwych momentach rozwoju.

Zasadniczo chcesz być objęty dwoma dużymi miejscami:

1. Czy oprogramowanie przeszło testy BDD wykazujące, że spełnia określone wymagania. Oprogramowanie nie może nawet zostać nazwane zrobione, jeśli nie jest to prawdą.

2. Czy najbardziej krytyczne, złożone i niepewne segmenty mają odpowiednie testy, aby zapewnić zaufanie? Jeśli jest to pętla rdzenia lub coś, co musiałeś zoptymalizować lub zhakować: przetestuj to. Jeśli jest to skomplikowane i ma wiele logicznych podziałów: wykonaj na nim wiele testów. Jeśli nie możesz go przetestować jednostkowo lub jest osadzony zbyt głęboko, aby praktycznie przetestować bezpośrednio: upewnij się, że kod został sprawdzony, a kod przetestowany pośrednio ręcznie.

Jeśli zaczekasz do zakończenia projektu, rzeczywiście będziesz mieć bardzo dużą liczbę przypadków testowych. Jeśli dostarczasz w sposób ciągły, koncentrując się na małych dostawach, będziesz mieć mniej przypadków testowych na każdej iteracji i będziesz w stanie przetestować wszystko. Jeśli nie możesz wykonać małych dostaw, nadaj priorytet i rozpocznij testowanie od najwyższego priorytetu i przejdź do testowania, aż będziesz musiał przestać.

Jeśli mówisz o testowaniu jednostkowym i robisz TDD (najpierw pisząc testy), to nie jest problem: po prostu przestajesz testować, gdy funkcje są gotowe.

W przyrostowym TDD piszesz test, który się nie udaje, a następnie implementujesz najmniejszą ilość kodu, która może go przekazać, a następnie refaktoryzujesz. Dodawaj testy w ten sposób, aż metoda zakończy działanie.

Oto świetny przykład.

Statystycy również przyjrzeli się temu zagadnieniu - właściwie już w latach 70. i 80. Przy odpowiednich założeniach dotyczących wykrywania błędów próbują oszacować liczbę błędów na podstawie danych z testów. Jest to następnie wykorzystywane do określenia, kiedy zatrzymać, na podstawie optymalizacji funkcji utraty. Zobacz na przykład https://rpubs.com/hoehle/17920 ... krótkie omówienie jednego z artykułów na ten temat, w tym kodu R, jak to zrobić w praktyce.

Oczywiście jednym problemem zawsze będą założenia dotyczące procesu wykrywania błędów. Na przykład w powyższym leczeniu zakłada się, że błędy są wykrywane niezależnie od siebie. W praktyce naprawienie jednego dużego błędu może np. Powodować nowe błędy itp. Ale daje początek i uzupełnia uczucie jelit.

Kiedy nadejdzie data wysyłki. Testowanie oprogramowania nie ma końca. Ale z drugiej strony istnieje coś takiego jak harmonogram. Będziesz musiał przetestować większość swojej funkcjonalności w zaplanowanym czasie i naprawić napotkane błędy. W żaden sposób nie można zagwarantować, że oprogramowanie jest idealne.

Pierwszą rzeczą do przetestowania byłaby „szczęśliwa ścieżka”, przypadki krawędzi i nieprawidłowe dane wejściowe. Jeśli będzie więcej niż jeden współbieżny użytkownik, musisz przetestować pod kątem problemów z współbieżnością, takich jak blokowanie i warunki wyścigu. Jeśli aplikacja korzysta z zasobów zewnętrznych, musisz przetestować zachowanie aplikacji, gdy te zasoby są niedostępne. Następnie możesz użyć kodu, aby wyszukać rzeczy, które mogą spowodować jego uszkodzenie i przetestować je. Po przejściu wszystkich tych testów stosunek kosztów do korzyści w dalszych testach zaczyna rosnąć, dlatego warto zatrzymać się w tym miejscu.

Wszystko sprowadza się do pewności siebie. Czy masz pewność, że system jest wystarczająco przetestowany?

Oczywiście „poziom zaufania” jest wysoce subiektywny, ponieważ nigdy nie możesz czuć się całkowicie pewny, ale wystarczająco pewny - i właśnie tego szukamy. W tym celu musisz stworzyć listę wskaźników, powszechnie znaną jako definicja ukończenia i powinna być czymś, na co zgodzi się cały zespół.

Oto kilka „zakończonych wskaźników” związanych z testem:

• Czy twoja kompilacja i instalacja są całkowicie zautomatyzowane, a wszystkie testy (jednostka, GUI, integracja) są wykonywane automatycznie?
• Czy piszesz testy podczas (a najlepiej przed) pisania kodu, a nie po nim?
• Czy czujesz się wystarczająco bezpiecznie, aby dokonać dużego refaktoryzacji kodu bez wprowadzania błędów?
• Czy poziom pokrycia twojego kodu jest wystarczająco wysoki?
• Czy masz dedykowanego testera w swoim zespole? Czy jest zaangażowany codziennie przez cały okres rozwoju, a nie tylko na koniec?
• Czy Twój tester ręcznie (eksploracyjny) próbował go złamać bez powodzenia?

Jeśli możesz sprawdzić te punkty, prawdopodobnie możesz powiedzieć, że przetestowałeś wystarczająco dużo.

Nigdy, myślę, że nigdy nie zakończysz testowania w systemie. Jest tak wiele zmiennych, którymi nie możesz zarządzać.

Ale, jak wiemy, nie można testować „na zawsze”, więc myślę, że limit zależy w zasadzie od:

• Gdy ryzyko związane z użytkowaniem oprogramowania zostało zmniejszone do akceptowalnego poziomu. (jak mówi @Graham Lee)
• Kim jest użytkownik systemu? może to być ty lub prezydent Stanów Zjednoczonych. W pierwszym przypadku nie obchodzi Cię zbytnio, czy błąd pojawia się, ponieważ rozwiązujesz go i gotowe. W drugim przypadku nie chcesz ŻADNEGO błędu.
• Jakie są twoje relacje z klientem? Może klient jest twoim tatą, więc nie jest taki straszny, a może to duża firma.
• Jak poważny jest dla użytkowników systemu błąd? Czy spowoduje trzecią wojnę światową, czy po prostu brzydką wiadomość?

Gdy ludzie, którzy muszą się wypisać podczas wdrażania, są zadowoleni.

lub w niektórych przypadkach większość odpowiedzialnych stron jest zadowolona.