Korzystanie z analizy luk w procesie testowania w celu wyrównania programistów i testerów

jest powszechnie uznanym przekonaniem, że programiści i testerzy radzą sobie jak kreda i ser. Programiści często patrzą z góry na testerów, postrzegając ich jako nieelastyczny i nieprzydatny opór przy opracowywaniu nowego kodu, którzy nie dostarczają jasnych szczegółów w swoich zgłoszeniach błędów. Podobnie, testerzy często postrzegają programistów z irytacją za to, że nie informują ich o zmianach w kodzie i wprowadzają nowe zmiany podczas cykli testowych. Dlatego analiza luk w procesie testowania jakości może być szczególnie korzystna dla dostosowania zarówno programistów, jak i testerów.

chociaż ten widok może być apokryficzny, często zdarza się, że programiści i testerzy nie komunikują się dobrze. Często komunikacja odbywa się tylko za pośrednictwem kierownictwa (kierowników projektów i kierowników liniowych) lub za pośrednictwem biletów W Jira. W rezultacie testy często okazują się niewystarczające. W szczególności zbyt często nowy kod jest źle testowany lub w ogóle nie testowany. Badania wykazały, że ten nieprzetestowany nowy kod jest największym źródłem przyszłych błędów i błędów. W tym miejscu pojawia się koncepcja analizy luk testowych.

na tym blogu zbadamy, czym jest analiza luk testowych, pokażemy, jak może pomóc zidentyfikować kod, który należy przetestować i zbadać, czy takie podejście jest panaceum, które może wypełnić lukę między programistami a testerami.

co to jest analiza luk testowych?

kiedy po raz pierwszy tworzysz system oprogramowania, łatwo jest mieć pewność, że testujesz cały system. Testerzy są w stanie pobrać specyfikację kodu i użyć kombinacji testów planowych i eksploracyjnych, aby upewnić się, że testują każdą ruchomą część bazy kodu. Jednak większość oprogramowania nie jest statyczna. Firmy produkują monolityczne okresowe wydania długowiecznego kodu lub stosują pewien poziom ciągłej integracji i ciągłego wdrażania (CI / CD). W obu przypadkach baza kodu stale się zmienia. Jednak zbyt często przypadki testowe nie są aktualizowane w tym samym tempie. Czasami testerzy po prostu nie wiedzą, że dokonano zmiany kodu. Innym razem zmiana kodu jest wypychana zaraz po uruchomieniu określonego zestawu testów. Wydaje się, że testy te przeszły, ale zmiana kodu mogła je złamać.

Analiza luk testowych to proces identyfikacji tych luk, w których nowy kod został wdrożony, ale nie został jeszcze przetestowany. Wymaga to połączenia statycznej analizy wszystkich zmian kodu i dynamicznej analizy wszystkich bieżących testów. Porównując te dwie analizy, można łatwo zobaczyć, gdzie znajdują się luki. Oznacza to, że obszary nowego kodu, które zostały odpowiednio przetestowane. Zazwyczaj odbywa się to poprzez wykreślenie kodu za pomocą postaci diagramu drzewa, w którym kod jest podzielony na bloki funkcjonalne, poniżej każdego bloku znajdują się klasy składowe, poniżej znajdują się rzeczywiste metody i funkcje. Na każdym poziomie hierarchii względny rozmiar bloku wskazuje ilość kodu. Nakładając drzewo pokazujące zmiany kodu na drzewo pokazujące aktualny stan testowania, łatwo jest zauważyć obszary, w których brakuje pokrycia testowego.

mapa drzewa pokazująca niezmieniony kod (szary), zmieniony/nowy kod, który jest testowany (zielony), zmieniony kod, który jest niesprawdzony (pomarańczowy) i nowy kod, który jest niesprawdzony (czerwony).

dlaczego analiza luk testowych może mieć znaczenie w procesie testowania?

w artykule z 2013 r.naukowcy z Uniwersytetu Technicznego w Monachium przeprowadzili badania mające na celu zbadanie korelacji między nowym, nieprzetestowanym kodem a przyszłymi błędami oprogramowania. Współpracowali z Munich Re (dużą firmą ubezpieczeniową), monitorując ich długowieczny system informatyczny poprzez 2 wydania. Podczas wydania ustalono, który KOD JEST NOWY, a także sprawdzono, który Kod został przetestowany, a który został wydany bez testów. Następnie przez długi czas monitorowali system i śledzili wszystkie zgłoszone błędy z powrotem do pierwotnego źródła. Odkryli dwie kluczowe rzeczy. Po pierwsze, mniej więcej jedna trzecia całego kodu została wydana bez testów. Po drugie, kiedy prześledzili błędy, które odkryli, od 70 do 80% wszystkich błędów było w niesprawdzonym kodzie. Poniższy wykres pokazuje to wyraźniej.

jak widać, Stary testowany kod nie miał błędów. Nowy Testowany kod miał od 22 do 30% błędów, a pozostałe błędy były rozłożone dość równomiernie między Nowy, nieprzetestowany kod i stary, nieprzetestowany kod. Ponieważ jednak nowy kod stanowił tylko 15% całego kodu, widać, że nowy, nieprzetestowany kod powodował nieproporcjonalnie dużą liczbę błędów.

Analiza luk testowych ma na celu identyfikację tego nieprzetestowanego nowego kodu. Jednak może również pomóc w inny sposób. Na przykład, ponieważ monitoruje to, co testujesz, może zidentyfikować obszary istniejącego kodu, które są nieaktualne (np. są nadal testowane, ale nie są wywoływane przez żaden kod). Może również wskazać, na których obszarach musisz skoncentrować swoje zasoby testowe. Prowadząc go regularnie, menedżerowie mogą usprawnić planowanie testów, koncentrując się na testowaniu nowego kodu i starając się zapewnić równomierny zasięg testów.

Programiści i testerzy dopasowani do analizy luk testowych

Analiza luk testowych jest wyraźnie potężną koncepcją. Ale jest też jasne, że nie wszystkie drużyny skorzystają na tym w równym stopniu. Najbardziej skorzystają zespoły, które utrzymują długowieczne bazy kodowe z okresowymi monolitycznymi wydaniami. W długowiecznych bazach kodowych programiści często pracują nad kodem napisanym przez innych ludzi. Testerzy mogą polegać na planach testowych wyprodukowanych wcześniej w kilku wersjach. Biorąc pod uwagę w połączeniu, czynniki te mogą oznaczać, że nikt nie jest do końca jasny, który kod jest testowany lub w jaki sposób kod ten współdziała z innymi częściami systemu. Tutaj, TGA może pozwolić testerom zobaczyć dokładnie, co Kod się zmienił, co pozwala im skupić się na tym. Mogą również zidentyfikować kod w istniejącym systemie, który nie jest testowany.

zespoły używające CI/CD mogą również skorzystać z tego podejścia, ponieważ pozwoli to testerom szybko zidentyfikować dokładnie, jaki kod został zmieniony, a więc pozwoli im skoncentrować się na tym. Może również uniknąć problemu wymienionego powyżej, w którym kawałek kodu jest zmieniany bezpośrednio po przetestowaniu, a następnie zostaje wydany ze zmianami nieprzetestowanymi.

z drugiej strony zespoły, które pracują nad nowym lub krótkotrwałym kodem, odniosą mniejsze korzyści, ponieważ z definicji większość kodu będzie początkowo nietestowana. Tutaj ważne jest, aby używać standardowych metod testowania, aby upewnić się, że testy są dobre. Może jednak być przydatne dla takich zespołów, aby rozpocząć monitorowanie zasięgu testu za pomocą TGA, ponieważ pozwoli im to uniknąć przyszłych problemów.

jakie są potencjalne problemy?

jest kilka problemów z TGA. Jeden z największych odnosi się do faktu, że nie może powiedzieć, który kod jest aktywnie wywoływany w bazie kodowej. Programiści często dodają nowy kod w ramach przygotowań do przyszłych wydań, ale ponieważ jest on nieaktywny, pakiet testowy nie może go wywołać. W rezultacie kod ten będzie zawsze wyświetlany jako nowy, nieprzetestowany kod. Podobnie, wiele dużych baz kodowych zawiera bloki starego lub osieroconego kodu. Należy je okresowo czyścić, ale ponownie zniekształcą obraz analizy luki testowej.

kolejną ważną obserwacją jest to, że tylko dlatego, że kawałek kodu jest testowany, nie wyklucza, że kod ten uruchamia błędy w innym miejscu. Niektóre z najgorszych błędów to te, w których mała zmiana w jednym kawałku kodu powoduje, że funkcja lub metoda zawodzi w całkowicie niezwiązanym bloku kodu. Dlatego ważne jest, aby nadal wykonywać zarówno badania eksploracyjne, jak i testy regresyjne. To, co może zrobić TGA, to zidentyfikować obszary w istniejącej bazie kodu, które nie są prawidłowo testowane podczas testów regresji.

jakie inne alternatywy pomagają wypełnić lukę?

Analiza luk testowych jest zdecydowanie przydatnym narzędziem dla niektórych zespołów. Istnieją jednak inne sposoby uniknięcia rozbieżności między tym, co testują testerzy, a tym, co kodują koderzy. Jednym ze sposobów jest użycie bardziej inteligentnej automatyzacji testów, która jest w stanie zidentyfikować, gdzie i kiedy rzeczy się zmieniły, zarówno na frontendzie, ale także, co ważne, w backendzie. W Functionize nasze testy wykorzystują inteligentne odciski palców w połączeniu z uczeniem maszynowym i samoleczeniem, aby zmniejszyć konserwację testów. Dzięki temu testy mogą aktywnie dostosowywać się do zmian frontendowych, a także monitorować takie rzeczy, jak wywołania serwera, czasy odpowiedzi i czy przyciski/funkcje są rzeczywiście widoczne. Oznacza to, że twoi testerzy nie zostaną złapani przez zmiany wprowadzone w kodzie zaplecza lub zmiany projektu/CSS, które zmieniają układ frontend.

nasz inteligentny system może również tworzyć testy poprzez monitorowanie interakcji użytkowników z systemem. Pomaga to zapewnić mniejszą liczbę luk w zakresie testu. Jedno z naszych najnowszych narzędzi pozwala na pisanie nowych testów w prostym języku angielskim. Są one analizowane przez nasze narzędzie do przetwarzania języka naturalnego i przekształcane w użyteczne testy. Oznacza to, że programiści mogą po prostu określić, co będzie trzeba przetestować przy użyciu zwykłego języka angielskiego, zmniejszając tym samym lukę między tymi dwoma dyscyplinami.

wnioski

Analiza luk testowych pomaga zidentyfikować, który kod jest wypuszczany, a tym samym może pomóc w bardziej efektywnym skupieniu zasobów testowych. Nic dziwnego, że nietestowany kod jest znacznie bardziej podatny na błędy, więc użyteczne jest każde narzędzie, które może pomóc w prawidłowym przetestowaniu tego kodu. Jednak, jak widzieliśmy, TGA może jedynie uzupełniać istniejące najlepsze praktyki. Ważne jest, aby nadążyć za testami regresyjnymi i testami eksploracyjnymi. Wiele korzyści z TGA można również osiągnąć za pomocą inteligentnych narzędzi testujących. Ale ogólnie rzecz biorąc, najważniejszą rzeczą, której należy unikać, jest izolowanie zespołu testowego od pracy programistów. Aby źle cytować stare powiedzenie, powinieneś upewnić się, że lewa ręka wie, co robi prawa ręka!