W tym samouczku przedstawiono siedem podstawowych zasad testowania oprogramowania, które powinien znać każdy tester oprogramowania i specjalista ds. Zapewnienia jakości.
7 Zasady testowania oprogramowania
- Testy wykazały obecność defektów
- Wyczerpujące testy nie są możliwe
- Wczesne testy
- Grupowanie defektów
- Paradoks pestycydów
- Testowanie zależy od kontekstu
- Brak błędów, błąd
Nauczmy się zasad testowania na poniższym przykładzie wideo:
Kliknij tutaj, jeśli wideo nie jest dostępne
tło
Ważne jest, aby uzyskać optymalne wyniki testów podczas przeprowadzania testów oprogramowania bez odchodzenia od celu. Ale w jaki sposób ustalasz, że postępujesz zgodnie z właściwą strategią testowania? W tym celu musisz trzymać się kilku podstawowych zasad testowania. Oto siedem typowych zasad testowania, które są szeroko stosowane w branży oprogramowania.
Aby to zrozumieć, rozważ scenariusz, w którym przenosisz plik z folderu A do folderu B.
Pomyśl o wszystkich możliwych sposobach przetestowania tego.
Oprócz zwykłych scenariuszy możesz również przetestować następujące warunki
- Próba przeniesienia pliku, gdy jest otwarty
- Nie masz uprawnień do wklejenia pliku do folderu B
- Folder B znajduje się na dysku współdzielonym, a pojemność pamięci jest pełna.
- Folder B ma już plik o tej samej nazwie, w rzeczywistości lista jest nieskończona
- Lub załóżmy, że masz 15 pól wejściowych do przetestowania, z których każde ma 5 możliwych wartości, liczba testowanych kombinacji wyniosłaby 5 15
Gdybyś przetestował wszystkie możliwe kombinacje projektu, CZAS I KOSZTY REALIZACJI wzrósłby wykładniczo. Potrzebujemy pewnych zasad i strategii, aby zoptymalizować wysiłek związany z testowaniem
Oto 7 zasad:
1) Wyczerpujące testy nie są możliwe
Tak! Wyczerpujące testy nie są możliwe. Zamiast tego potrzebujemy optymalnej ilości testów w oparciu o ocenę ryzyka aplikacji.
A pytanie za milion dolarów brzmi: jak określić to ryzyko?
Aby odpowiedzieć na to pytanie, zróbmy ćwiczenie
Twoim zdaniem, która operacja najprawdopodobniej spowoduje awarię systemu operacyjnego?
Jestem pewien, że większość z was zgadłaby, otwierając 10 różnych aplikacji jednocześnie.
Więc gdybyś testował ten system operacyjny, zdałbyś sobie sprawę, że defekty można znaleźć w działaniach wielozadaniowych i muszą zostać dokładnie przetestowane, co prowadzi nas do następnej zasady Klaster defektów
2) Grupowanie defektów
Klaster defektów, który stwierdza, że niewielka liczba modułów zawiera większość wykrytych defektów. Oto zastosowanie zasady Pareto do testowania oprogramowania: około 80% problemów występuje w 20% modułów.
Z doświadczenia możesz zidentyfikować takie ryzykowne moduły. Ale takie podejście ma swoje własne problemy
Jeśli te same testy będą powtarzane w kółko, ostatecznie te same przypadki testowe nie będą już zawierać nowych błędów.
3) Paradoks pestycydów
Powtarzające się stosowanie tej samej mieszanki pestycydów do zwalczania owadów w rolnictwie z czasem doprowadzi do rozwoju odporności owadów na pestycydy, przez co pestycydy będą nieskuteczne w stosunku do owadów. To samo dotyczy testowania oprogramowania. Jeśli zostanie przeprowadzony ten sam zestaw powtarzalnych testów, metoda będzie bezużyteczna do wykrywania nowych defektów.
Aby temu zaradzić, przypadki testowe muszą być regularnie przeglądane i korygowane, dodając nowe i różne przypadki testowe, aby pomóc znaleźć więcej błędów.
Testerzy nie mogą po prostu polegać na istniejących technikach testowania. Musi nieustannie dążyć do ulepszania istniejących metod, aby testy były bardziej skuteczne. Ale nawet po całym wysiłku i ciężkiej pracy podczas testów, nigdy nie możesz twierdzić, że Twój produkt jest wolny od błędów. Aby wyjaśnić ten punkt, obejrzyjmy to wideo przedstawiające publiczne uruchomienie systemu Windows 98
Myślisz, że firma taka jak MICROSOFT nie przetestowałaby dokładnie swojego systemu operacyjnego i zaryzykowałaby swoją reputację tylko po to, by zobaczyć, jak ich system operacyjny ulega awarii podczas publicznego uruchomienia!
4) Testy wykazały obecność defektów
Stąd zasada testowania mówi, że - Testowanie mówi o obecności defektów, a nie o ich braku. tzn. testowanie oprogramowania zmniejsza prawdopodobieństwo nieodkrytych defektów pozostających w oprogramowaniu, ale nawet jeśli nie zostaną znalezione żadne defekty, nie jest to dowód poprawności.
Ale co, jeśli pracujesz wyjątkowo ciężko, zachowując wszelkie środki ostrożności i sprawiasz, że oprogramowanie jest w 99% wolne od błędów. A oprogramowanie nie spełnia potrzeb i wymagań klientów.
To prowadzi nas do naszej następnej zasady, która stwierdza, że - Brak błędu
5) Brak błędu - błąd
Możliwe, że oprogramowanie, które jest w 99% wolne od błędów, nadal nie nadaje się do użytku. Może się tak zdarzyć, jeśli system zostanie dokładnie przetestowany pod kątem nieprawidłowych wymagań. Testowanie oprogramowania to nie tylko znajdowanie usterek, ale także sprawdzanie, czy oprogramowanie spełnia potrzeby biznesowe. Brak błędu jest błędem, tj. Znajdowanie i naprawianie usterek nie pomaga, jeśli wersja systemu jest bezużyteczna i nie spełnia potrzeb i wymagań użytkownika.
Aby rozwiązać ten problem, następna zasada testowania głosi, że Early Testing
6) Wczesne testy
Wczesne testowanie - testowanie powinno rozpocząć się jak najwcześniej w cyklu życia oprogramowania. Dzięki temu wszelkie wady wymagań lub fazy projektowania są wychwytywane na wczesnym etapie. Znacznie taniej jest naprawić usterkę na wczesnych etapach testowania. Ale jak wcześnie należy rozpocząć testy? Zaleca się rozpoczęcie wyszukiwania błędu w momencie zdefiniowania wymagań. Więcej na temat tej zasady w późniejszym samouczku szkoleniowym.
7) Testowanie zależy od kontekstu
Testowanie zależy od kontekstu, co w zasadzie oznacza, że sposób testowania witryny e-commerce będzie inny niż sposób testowania gotowej aplikacji komercyjnej. Nie wszystkie opracowane programy są identyczne. Możesz użyć innego podejścia, metodologii, technik i typów testów w zależności od typu aplikacji. Na przykład testowanie dowolnego systemu POS w sklepie detalicznym będzie się różniło od testowania bankomatu.
Mit: „Zasady służą jedynie jako odniesienie. Nie będę ich używał w praktyce”.
To jest bardzo nieprawdziwe. Zasady testowania pomogą Ci stworzyć skuteczną strategię testowania i przygotować szkic przypadków testowych wychwytujących błędy.
Ale uczenie się zasad testowania jest jak nauka jazdy po raz pierwszy.
Początkowo, kiedy uczysz się jeździć, zwracasz uwagę na wszystko, takie jak zmiana biegów, prędkość, obsługa sprzęgła itp. Ale z doświadczeniem, po prostu skupiasz się na prowadzeniu reszty. Takich, że możesz nawet rozmawiać z innymi pasażerami w samochodzie.
To samo dotyczy zasad testowania. Doświadczeni testerzy przyswoili sobie te zasady do tego stopnia, że stosują je nawet bez zastanowienia. Stąd mit, że zasady nie są stosowane w praktyce, jest po prostu nieprawdą.