Jak wiedzieć, kiedy przestać testować?

23

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”).

rsman
źródło
3
kiedy się nie powiedzie ..
Javier
Myślę, że można znaleźć post na blogu Michaela Boltona na temat zatrzymania heurystyki podczas testowania przydatny do przeczytania: http://www.developsense.com/blog/2009/09/when-do-we-stop-test/ Możesz rozpoznać niektóre z heurystycy zasugerowali w tym wątku.
testerab
Z mojego doświadczenia wynika, że ​​wystarczy zastosować zasadę Pareto .
Amir Rezaei

Odpowiedzi:

3

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.

Macneil
źródło
Szybkość znajdowania nowych błędów jest wysoce zależna od czynników zewnętrznych i niestety - niektórzy kierownicy projektów będą w to grać. Cem Kaner przytacza przykłady wysłania zespołu testowego do filmów, aby wskaźnik wykrywania błędów spadł i PM mógł wysłać.
testerab
14

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.

Jon Hopkins
źródło
4

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


źródło
7
Cóż, to jest opis problemu, po prostu przeformułowany, prawda?
Martin Wickman
@Martin: najwyraźniej nie. Zamiast zaczynać od przypadku testowego 1 i kończąc na przypadku testowym ∞, odpowiedź ta powinna skłonić pytającego do rozpoczęcia od najważniejszego przypadku testowego i zakończenia, gdy nie będą już stanowić wartości dodanej.
1
Choć filozoficznie poprawne (i przemyślane), myślę, że OP szuka czegoś bardziej praktycznego.
Martin Wickman
„akceptowalne” można zdefiniować wcześniej. To bardzo pomaga.
@ Thorbjørn: „Można zdefiniować”. Tak ale jak? Właśnie tego szuka PO.
Martin Wickman
3

„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.

CodexArcanum
źródło
2

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ć.

Fernando
źródło
+1 za ciągłe małe dostawy i wczesne testy. Powoduje to również, że wady są łatwiejsze do naprawienia, ponieważ oryginalny programista jest nadal w kontekście i nie przeniósł się do innego obszaru. Pracuję teraz w środowisku, w którym to robimy, i to przerażające, o ile bardziej produktywni są wszyscy.
testerab
2

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.

Brad Cupit
źródło
2

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.

mhatsu
źródło
1

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.

Manoj R.
źródło
3
Więc nawet jeśli nie przetestowałeś połowy tego, co wysyłasz? To wszystko jest złe w tworzeniu oprogramowania. Nie powinieneś już wysyłać z niekompletnymi testami, których nie zakodowałbyś w połowie.
Jon Hopkins
2
Spowoduje to tylko pewną rezygnację psychiczną u testera. Mam zamiar pomyśleć „bez względu na to, co zrobię, nie mogę tego całkowicie przetestować, ponieważ i tak zostanie wysłany X stycznia, więc po prostu zrobię wszystko, co w mojej mocy”. Czyż nie tak powinniśmy budować oprogramowanie?
rsman
Jako tester systemu rzadko znajdowałem się w sytuacji, w której data premiery opóźniała się z powodu dalszych testów. Wiem, że nigdy niczego nie przetestuję całkowicie - staram się ustalić priorytet. Oczywiście jakość połączeń, które wykonuję na temat tego, które obszary najpierw przetestować, zależą od informacji, które otrzymuję na temat ryzyka technicznego i znaczenia biznesowego. Najważniejsze jest to, że ZAWSZE powinna to być decyzja biznesowa, a nie decyzja programistyczna / testowa na temat tego, jaki poziom ryzyka firma jest gotowa podjąć. Możemy doradzić, ale to firma musi zdecydować.
testerab
Chociaż całkowicie się zgadzam: nie jest to zrobione, dopóki nie zostanie przetestowane. (Zwykle zgadzam się z pomysłem, że lepiej byłoby użyć terminu „faza naprawiania” niż faza testowania). Nie zgadzam się tylko z tym, że uważam, że testowanie jest z natury otwarte - nigdy nie można narysować linii i powiedzieć „nie ma więcej testów, które moglibyśmy teraz wykonać”, po prostu „nie ma więcej testów, które naszym zdaniem warto teraz wykonać”.
testerab
1

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.

Larry Coleman
źródło
1

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.

Martin Wickman
źródło
1

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ść?
Diego
źródło
0

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

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

Rachunek
źródło