Praca dyplomowa z testowania - od pytania do pomysłu

9421
wyświetleń
Praca dyplomowa z testowania - od pytania do pomysłu
W jednym z maili do redakcji pojawiło się proste stwierdzenie: "Poszukuję pomysłów na napisanie pracy magisterskiej z testowania". Rozmowa zakończyła się: "Dzięki za pomoc". Choć nasze propozycje zostały jedynie częściowo zaakceptowane, oto jak udało się zamienić rozmowę o testowaniu w temat pracy dyplomowej.

Michał: "Poszukuję pomysłów na napisanie pracy magisterskiej z testowania. Mam problem ze zdefiniowaniem elementu badawczego w swojej pracy, a praca magisterska powinna takowy zawierać. Generalnie pracuję jako tester (głównie manualny) i chciałbym wykorzystać ten czas na poznanie jakiegoś nowego narzędzia, podejścia do testowania. Znane mi technologie to .NET oraz T-SQL.
 
Początkowo chciałem napisać o testowaniu jednostkowym na poziomie bazy danych z wykorzystaniem narzędzia tSQLt (http://tsqlt.org/), ale co tutaj badać? Skuteczność, chyba słabo, a zapoznanie się z narzędziem to raczej temat na pracę inżynierską. Potem wpadłem na pomysł, żeby porównać unit testy na poziomie bazy z np. NUnitem. Tylko z jaką tezą wyjść? Bo przecież zawsze można powiedzieć, że testy na poziomie bazy są lepsze, bo nie potrzeba do tego działającej aplikacji i można zacząć testować przy okazji tworzenia modelu danych.
"

 

testerzy.pl: "Temat z testowanie mutacyjnym będzie ciekawy jeśli zestawi się ze sobą więcej niż jeden typ testów. Pytanie czy potrafi Pan pokazać skuteczność skryptów automatycznych bez aplikacji korzystającej z bazy?"

 

Michał: "Testowanie mutacyjne i zestawienie więcej niż jednego typu testów, to macie na myśli zestawienie mutacji z np. fuzz testingiem, czy raczej na poziomie testów mutacyjnych próba wykonania testów wartości brzegowych, klas równoważności, itd. Wykazanie skuteczności skryptów automatycznych bez aplikacji może umożliwić właśnie fuzz testing (przy założeniu, że logika systemu leży po stronie bazy danych (procedury, funkcje, triggery), a aplikacja tak naprawdę wywołuje owe procedury, itd. z pewnymi danymi wejściowymi."

 

testerzy.pl: "W odniesieniu do testowania poprawności baz danych na różnych poziomach testów.
Załóżmy posiadanie bazy danych podpiętej do prostego interfejsu, który będzie czytał dane z bazy.
Załóżmy, że baza jest okodowana przy pomocy unit testów.
Załóżmy, że interfejs podpięty do bazy danych jest okodowany przy pomocy testów automatycznych
[opcjonalnie] Załóżmy, że baza może być testowana manualnie przez interfejs.
 
Jeśli na poziomie bazy danych pojawią się defekty (wprowadzone np. mutacyjnie) to:
1. który z określonych typów testów będzie miał większą skuteczność w ich wykryciu?
2. jak należałoby zmodyfikować poszczególne testy aby uzyskały one zdolność do wykrycia problemu?
3. które defekty nie zostaną wykryte bez względu na to jakie testy przeprowadzimy?
"

 

Michał: "Postanowiłem, że napiszę pracę wykorzystując swój pierwotny pomysł dotyczący testowania mutacyjnego baz danych, ale skorzystam także z Waszych wskazówek by zestawić go z innymi testami:
1. Fault injection
2. Fuzz testing
3. Robustness testing

Stworzę bazę, do której napiszę testy jednostkowe w tSQLt, podepnę do interfejsu napisanego w C# .NET, do którego stworzę testy jednostkowe w NUnit.

Teraz wykorzystując testy jednostkowe oraz różne rodzaje testów (mutation, fault, itd.) sprawdzę, które podejście wykryje najwięcej błędów, jak można je poprawić (tak jak sugerowaliście).

Zastanawiam się też nad dołożeniem do tego technik czarnoskrzynkowych: klasy równoważności, wartości brzegowe, tablicę decyzyjną, przejścia między stanami, czy testowanie w oparciu o przypadki testowe, bo dałoby to bardziej przekrojowe spojrzenie na temat. Dodatkowo czy wchodzić w kwestie wydajnościowe przy tym? To chyba będzie wtedy o wszystkim i o niczym.
"

 

Michał ponownie: "Trochę doczytałem i jeśli dobrze myślę to:
Robustness testing jest metodologią testowania, do której należą fuzz testing, mutation testing oraz fault injection
Mutation testing to wprowadzenie defektów do aplikacji, celem sprawdzenia czy testy, które mamy działają
Fuzz testing - wprowadzenie losowych danych do programu (czyli np. może służyć do weryfikacji testów jednostkowych, po wykonaniu mutation testing)
Fault injection - tu mam trochę problem, bo to wg definicji wprowadzenie błędnych danych do aplikacji, tylko czym to się różni od fuzz testingu (tam wprowadzamy losowe, czyli też poniekąd błędne dane). To ma bardziej związek z testowaniem zabezpieczeń?

Czyli widziałbym to tak:
1. Mam tą bazę z unit testami.
2. Robię fuzz testing, sprawdzam ile unit testów przeszło
3. Robię mutation testing, sprawdzam ile unit testów przeszło
4. Robię fuzz testing z tymi samymi danymi wejściowymi, co w pkt. 2, tyle, że na bazie po wykonaniu mutacji i sprawdzam ile unit testów tak przeszło
5. Teraz miejsce na poprawę unit testów i ponowne przejście ścieżek 2-4
"

 

* Pisownia oryginalna.

** Są to fragmenty maili.

 

Jeśli i Ty szukasz pomysłów na pracę dypomową lub chcesz o niej porozmawiać, zapraszamy do kontaktu.

 

9421
wyświetleń

To powinno Cię zainteresować