Jakie są wady testów automatycznych?

Na tej stronie znajduje się wiele pytań, które zawierają wiele informacji na temat korzyści, jakie można uzyskać dzięki automatycznym testom. Ale nie widziałem niczego, co reprezentowałoby drugą stronę medalu: jakie są wady? Wszystko w życiu jest kompromisem i nie ma srebrnych kul, więc z pewnością muszą istnieć ważne powody, aby nie przeprowadzać automatycznych testów. Czym oni są?

Oto kilka, które wymyśliłem:

• Wymaga więcej początkowego czasu programisty dla danej funkcji
• Wymaga wyższego poziomu umiejętności członków zespołu
• Zwiększ potrzeby w zakresie oprzyrządowania (biegacze testowi, struktury itp.)
• Wymagana jest kompleksowa analiza w przypadku napotkania nieudanego testu - czy ten test jest przestarzały z powodu mojej zmiany, czy mówi mi, że popełniłem błąd?

Edytuj
Powinienem powiedzieć, że jestem wielkim zwolennikiem testowania automatycznego i nie chcę się do tego przekonać. Chcę zrozumieć, jakie są wady, więc kiedy idę do mojej firmy, aby to uzasadnić, nie wyglądam, jakbym rzucił się wokół kolejnej wymyślonej srebrnej kuli.

Poza tym, ja nie szukam nikogo, kto by podważył powyższe przykłady. Przyjmuję za prawdę, że muszą być pewne wady (wszystko ma kompromisy) i chcę zrozumieć, co to są.

Prawie przybiłeś najważniejsze. Mam kilka drobnych dodatków, a także wadę udanych testów - kiedy tak naprawdę nie chcesz (patrz poniżej).

• Czas programowania: w przypadku programowania opartego na testach jest to już obliczane dla testów jednostkowych, ale nadal potrzebujesz testów integracyjnych i systemowych, które również mogą wymagać kodu automatyzacji. Raz napisany kod jest zwykle testowany na kilku późniejszych etapach.

• Poziom umiejętności: oczywiście narzędzia muszą być obsługiwane. Ale to nie tylko twój własny zespół. W większym projekcie możesz mieć oddzielny zespół testujący, który pisze testy w celu sprawdzenia interfejsów między produktem twojego zespołu a innymi. Tak wiele osób musi mieć więcej wiedzy.

• Potrzeby w zakresie narzędzi: jesteś na miejscu. Nie wiele do dodania do tego.

• Nieudane testy: To jest prawdziwy robal (dla mnie i tak). Istnieje kilka różnych powodów, z których każdy może być postrzegany jako wada. A największą wadą jest czas niezbędny do podjęcia decyzji, który z tych powodów faktycznie dotyczy twojego nieudanego testu.

  • nie powiodło się z powodu faktycznego błędu. (tylko dla kompletności, ponieważ jest to oczywiście korzystne)
  • nie powiodło się, ponieważ kod testowy został napisany z tradycyjnym błędem.
  • nie powiodło się, ponieważ kod testowy został napisany dla starszej wersji produktu i nie jest już zgodny
  • nie powiodło się, ponieważ wymagania uległy zmianie, a testowane zachowanie jest teraz uważane za „prawidłowe”

• Testy zakończone niepowodzeniem: Są to również wady i mogą być dość złe. Dzieje się tak głównie wtedy, gdy zmieniasz rzeczy i zbliżasz się do odpowiedzi Adama. Jeśli zmienisz coś w kodzie produktu, ale test w ogóle go nie uwzględnia, daje to „fałszywe poczucie bezpieczeństwa”.

  Ważnym aspektem niezakończonych testów jest to, że zmiana wymagań może spowodować, że wcześniejsze zachowanie stanie się nieważne. Jeśli masz przyzwoitą identyfikowalność, zmianę wymagań można dopasować do kodu testowego i wiesz, że nie możesz już ufać temu testowi. Oczywiście utrzymanie tej identyfikowalności to kolejne wady. A jeśli tego nie zrobisz, zakończysz testem, który nie zawiedzie, ale faktycznie sprawdzi, czy Twój produkt działa nieprawidłowo . Gdzieś w dół drogi to cię uderzy ... zwykle kiedy / gdzie najmniej się tego spodziewasz.

• Dodatkowe koszty wdrożenia: Nie uruchamiasz testów jednostkowych jako programista na własnym komputerze. Dzięki automatycznym testom chcesz wykonywać je na zleceniach innych osób w jakimś centralnym miejscu, aby dowiedzieć się, kiedy ktoś zepsuł twoją pracę. Jest to miłe, ale należy je także skonfigurować i utrzymywać.

Właśnie zacząłem wypróbowywać automatyczne testy w naszym zespole, największą wadą, jaką widziałem, jest to, że bardzo trudno jest zastosować stary kod, który nie został zaprojektowany z myślą o automatycznych testach. Bez wątpienia poprawiłoby to nasz kod w dłuższej perspektywie, ale poziom refaktoryzacji potrzebny do zautomatyzowanego testowania przy jednoczesnym zachowaniu naszego rozsądku stanowi bardzo wysoką barierę wejścia na rynek w krótkim okresie, co oznacza, że ​​będziemy musieli być bardzo wybiórczy w kwestii wprowadzenia zautomatyzowanego testy jednostkowe w celu spełnienia naszych krótkoterminowych zobowiązań. Innymi słowy, o wiele trudniej jest spłacić karty kredytowe, gdy już jesteś głęboko zadłużony.

Być może najważniejszą wadą jest ... testy to kod produkcyjny . Każdy napisany test dodaje kod do bazy kodu, który należy utrzymywać i obsługiwać. Niezastosowanie się do tego prowadzi do testów, w które nie wierzysz, więc nie masz innego wyjścia. Nie zrozum mnie źle - jestem wielkim zwolennikiem automatycznych testów. Ale wszystko ma swój koszt, a to jest duży.

Nie powiedziałbym, że są to wady, które można w pełni zastosować, ale te, na które najbardziej uderzyłem, to:

• Czas potrzebny na skonfigurowanie testu w złożonej aplikacji dla przedsiębiorstw.
• Obsługa starych testów, które nie powiedzie się poprawnie, innymi słowy, system ewoluował, a teraz testy są nieprawidłowe.
• Fałszywa pewność wynikająca z niejednolitego lub nieznanego pokrycia testowego.

Nieprawidłowy zasięg testu może prowadzić do fałszywego poczucia bezpieczeństwa. Jeśli zrobisz refaktoryzację i użyjesz testów, aby udowodnić ich ważność, co dowiodło, że twoje testy są w stanie to udowodnić?

Czas potrzebny na utworzenie testu jest czasem dla nas problemem. Nasze zautomatyzowane testy obejmują nie tylko testy jednostkowe, ale także testy przypadków. Są one zwykle szersze i wymagają kontekstu.

Oczywiście moja perspektywa dotyczy aplikacji starszej niż testy jednostkowe.

Powiedziałbym, że głównym problemem z nimi jest to, że mogą zapewnić fałszywe poczucie bezpieczeństwa . Tylko dlatego, że masz testy jednostkowe, nie oznacza to, że w rzeczywistości coś robią, co obejmuje również prawidłowe testowanie wymagań.

Ponadto zautomatyzowane testy mogą również zawierać same błędy , co stawia pytanie, czy testy jednostkowe wymagają samodzielnego testowania, więc niekoniecznie osiągnięcie niczego.

Chociaż testy automatyzacji mają wiele zalet, mają również swoje wady. Niektóre z wad to:

• Wymagana jest biegłość w pisaniu skryptów testowych automatyzacji.
• Debugowanie skryptu testowego jest poważnym problemem. Jeśli w skrypcie testowym występuje jakikolwiek błąd, czasami może to prowadzić do śmiertelnych konsekwencji.
• Konserwacja testu jest kosztowna w przypadku metod odtwarzania. Mimo niewielkiej zmiany w graficznym interfejsie użytkownika skrypt testowy musi zostać ponownie zarejestrowany lub zastąpiony nowym skryptem testowym.
• Utrzymanie plików danych testowych jest trudne, jeśli skrypt testowy testuje więcej ekranów.

Niektóre z powyższych wad często odejmują korzyści z automatycznych skryptów. Chociaż testy automatyzacji mają zalety i odciski, są szeroko dostosowane na całym świecie.

Niedawno zadałem pytanie na temat testów w tworzeniu gier - oto BTW, skąd o tym wiedziałem. Odpowiedzi wskazywały na pewne ciekawe, konkretne wady:

1. To jest kosztowne, gdy twój kod powinien być wysoce sprzężony .
2. Trudno to zrobić, gdy trzeba być świadomym różnych platform sprzętowych, kiedy należy przeanalizować dane wyjściowe dla użytkownika, a wynik kodu ma sens tylko w szerszym kontekście .
3. Testowanie interfejsu użytkownika i interfejsu użytkownika jest bardzo trudne .
4. Co więcej, zautomatyzowane testy mogą być droższe i mniej skuteczne niż kilka bardzo tanich (lub bezpłatnych) beta testerów .

Czwarty punkt przypomina mi o moich doświadczeniach. Pracowałem w bardzo szczupłej, zorientowanej na XP firmie Scrum, w której wysoce zalecane były testy jednostkowe. Jednak na drodze do bardziej szczupłego, mniej biurokratycznego stylu firma po prostu zaniedbała budowę zespołu ds. Kontroli jakości - nie mieliśmy testerów. Tak często klienci znajdowali trywialne błędy przy użyciu niektórych systemów, nawet przy pokryciu testowym> 95%. Chciałbym więc dodać kolejny punkt:

• Zautomatyzowane testy mogą sprawić, że poczujesz, że kontrola jakości i testowanie nie są ważne.

Pomyślałem też o dokumentacji i wysunąłem hipotezę, która może być ważna (w mniejszym stopniu) do testów dwóch. Po prostu czułem, że kod ewoluuje tak szybko, że bardzo trudno jest stworzyć dokumentację zgodną z taką prędkością, dlatego bardziej cenne jest spędzanie czasu na tworzeniu kodu niż pisanie ciężkiej, łatwo przestarzałej dokumentacji. (Oczywiście nie dotyczy to interfejsów API, ale tylko wewnętrznej implementacji.) Test cierpi z powodu tego samego problemu: może być zbyt wolny, aby pisać w porównaniu z testowanym kodem. OTOH, jest to mniejszy problem, ponieważ testy ostrzegają, że są nieaktualne, a twoja dokumentacja pozostanie cicha, dopóki nie przeczytasz jej bardzo, bardzo ostrożnie .

Wreszcie pojawia się problem: automatyczne testowanie może zależeć od narzędzi, a narzędzia te mogą być źle napisane. Jakiś czas temu zacząłem projekt przy użyciu XUL, a pisanie testów jednostkowych dla takiej platformy jest po prostu bolesne. Uruchomiłem inną aplikację przy użyciu Objective-C, Cocoa i Xcode 3, a model testowy na niej był w zasadzie mnóstwem obejść.

Mam inne doświadczenia na temat wad automatycznego testowania, ale większość z nich wymieniono w innych odpowiedziach. Niemniej jednak jestem zagorzałym zwolennikiem zautomatyzowanych testów. Pozwoliło to zaoszczędzić dużo pracy i bólu głowy i zawsze domyślnie go polecam. Uważam, że te wady są jedynie szczegółami w porównaniu z korzyściami z automatycznych testów. (Ważne jest, aby zawsze głosić swoją wiarę po skomentowaniu herezji, aby uniknąć auto da fé.)

Dwa nie wymienione to:

• Czas potrzebny na uruchomienie dużego pakietu testowego

Brałem udział w automatycznych działaniach związanych z kontrolą jakości, w których testowanie trwało pół dnia, ponieważ testy były powolne. Jeśli nie jesteś ostrożny w pisaniu testów, Twój zestaw testów może się również okazać w ten sposób. To nie brzmi jak wielka sprawa, dopóki nie zarządzasz tym razem: „Och, właśnie dokonałem poprawki, ale udowodnienie poprawności zajmie 4 godziny”.

• Słabość niektórych metod pisania testów

Niektóre metody testowania (takie jak zautomatyzowanie interfejsu użytkownika) wydają się łamać za każdym razem, gdy się odwracasz. Szczególnie bolesne, jeśli na przykład skrypt zawiesza proces testowania, ponieważ czeka na pojawienie się przycisku - ale jego nazwa została zmieniona.

Są to dwie rzeczy, nad którymi możesz się obejść, stosując dobrą praktykę testowania: znajdź sposoby na szybkie utrzymanie pakietu testowego (nawet jeśli musisz wykonywać sztuczki, takie jak dystrybucja przebiegów testowych między maszynami / procesorami). Podobnie, należy zachować ostrożność, aby uniknąć słabych metod pisania testów.

Chcę dodać jeszcze jedno, fałszywe poczucie bezpieczeństwa.

Poza bardzo małymi, dobrze zdefiniowanymi zestawami problemów, nie jest możliwe stworzenie kompleksowych testów. W naszym oprogramowaniu mogą nadal występować błędy, których automatyczne testy po prostu nie sprawdzają. Po zautomatyzowanym teście zbyt często zakładamy, że w kodzie nie ma błędów.

Trudno przekonać zarządzającego / venture capital

• testautomation zwiększa koszty początkowe.
• testautomation wydłuża czas wprowadzania na rynek.
• korzyść z testautomacji pojawia się w połowie i logterm. zacięta konkurencja skupia się bardziej na krótkoterminowych korzyściach.

szczegółowe informacje można znaleźć w części Testowanie jednostek zależnych od rynku .

Jedną z głównych wad można pokonać, stosując testy samokształcenia. W tej sytuacji oczekiwane wyniki są przechowywane jako dane i mogą być aktualizowane przy minimalnym przeglądzie przez użytkownika zestawu testów w trybie samouczenia się (pokazują różnice między starym oczekiwanym wynikiem a nowym faktycznym wynikiem - aktualizacja oczekiwana po naciśnięciu y). Tego trybu uczenia się testsuite należy używać ostrożnie, aby nie wykryć zachowania błędnego jako akceptowalnego.