Menu

Samouczek dotyczący pokrycia kodu: gałąź, instrukcja, pokrycie funkcji

  • Główny
  • Inny
  • Samouczek dotyczący pokrycia kodu: gałąź, instrukcja, pokrycie funkcji

code coverage tutorial

Ten kompleksowy samouczek wyjaśnia, czym jest pokrycie kodu w testowaniu oprogramowania, jego rodzaje, zalety i wady:



Ostatecznym celem każdej firmy tworzącej oprogramowanie jest tworzenie oprogramowania o dobrej jakości. Aby osiągnąć ten cel, oprogramowanie musi zostać dokładnie przetestowane.



Testowanie jest zatem integralną częścią tworzenia aplikacji. W związku z tym ważne jest, aby opracowane oprogramowanie zostało sprawdzone przez programistę (co odbywa się w fazie testów jednostkowych), a następnie przekazane zespołowi ds. Kontroli jakości w celu dokładnego przetestowania, aby upewnić się, że zawiera minimalne błędy lub nie zawiera żadnych błędów.



Pokrycie kodu

Oprogramowanie jest testowane jednostkowo przed przekazaniem do właściwego zespołu testowego do testowania. Ponieważ te testy obejmują testowanie na poziomie kodu, wykonuje je programista. Ma to na celu zapewnienie, że każda część testowanego kodu działa zgodnie z oczekiwaniami.

Tutaj małe fragmenty kodu, które zostały opracowane, są testowane oddzielnie, aby zapewnić ich poprawność. Ale pytanie, które często pojawia się w umyśle programisty, brzmi ile testów jednostkowych należy wykonać a odpowiedź na to pytanie leży w zakresie kodu.



Ten samouczek da ci dogłębną wiedzę o tym, czym jest Pokrycie kodu i dlaczego go potrzebujemy. Dowiedziałbyś się, czym różni się to od pokrycia testowego.

Przyjrzymy się również narzędziom i metodologiom, które są używane do pokrycia kodu, a pod koniec tego samouczka zobaczymy zalety i wady. Omówimy tu także niektóre mity związane z pokryciem kodu.

Czego się nauczysz:

Co to jest pokrycie kodu

Pokrycie kodu

Jest to ważna miara testów jednostkowych. Przydaje się do poznania skuteczności testów jednostkowych. Jest to miara, która wskazuje, jaki procent kodu źródłowego zostałby wykonany podczas testowania.

W prostych słowach, zakres, w jakim kod źródłowy programu lub aplikacji zostanie wykonany podczas testowania, określany jest jako Pokrycie kodu.

Jeśli testy wykonują cały fragment kodu, w tym wszystkie gałęzie, warunki lub pętle, wówczas powiedzielibyśmy, że jest pełne pokrycie wszystkich możliwych scenariuszy, a zatem pokrycie kodu wynosi 100%. Aby jeszcze lepiej to zrozumieć, weźmy przykład.

Poniżej podano prosty kod, który służy do dodawania dwóch liczb i wyświetlania wyniku w zależności od wartości wyniku.

Input a, b Let c = a + b If c <10, print c Else, print ‘Sorry’

Powyższy program przyjmuje dwa wejścia, tj. „A” i „b”. Suma obu jest przechowywana w zmiennej c. Jeśli wartość c jest mniejsza niż 10, drukowana jest wartość „c”, w przeciwnym razie drukowane jest słowo „Przepraszamy”.

Teraz, jeśli mamy jakieś testy do walidacji powyższego programu z wartościami a & b takimi, że suma jest zawsze mniejsza niż 10, wtedy inna część kodu nigdy nie zostanie wykonana. W takim scenariuszu powiedzielibyśmy, że pokrycie nie jest pełne.

To był tylko mały przykład wyjaśniający znaczenie zakresu kodu. Im bardziej będziemy eksplorować, tym lepiej zrozumiesz.

Dlaczego potrzebujemy pokrycia kodu

Potrzeba pokrycia kodu

[wizerunek źródło ]

Różne powody sprawiają, że Pokrycie kodu jest niezbędne, a niektóre z nich wymieniono poniżej:

  • Pomaga upewnić się, że oprogramowanie ma mniej błędów w porównaniu z oprogramowaniem, które nie ma dobrego pokrycia kodem.
  • Pomagając w poprawie jakości kodu, pośrednio pomaga w dostarczaniu oprogramowania lepszej „jakości”.
  • Jest to miara, której można użyć do poznania skuteczności testów (skuteczności testów jednostkowych, które są napisane w celu przetestowania kodu).
  • Pomaga zidentyfikować te części kodu źródłowego, które nie zostałyby przetestowane.
  • Pomaga określić, czy obecne testy (testy jednostkowe) są wystarczające, czy nie i czy potrzebne są również dodatkowe testy.

Pokrycie kodu a pokrycie testowe

CC Vs TC

co może otworzyć plik json

Aby zrozumieć różnicę między pokryciem kodu a pokryciem testowym, najpierw zrozumiemy znaczenie pokrycia testowego.

Pokrycie testowe

Jest to miara tego, ile części oczekiwanego testowania zostało objętych podczas testowania oprogramowania. Przez „Oczekiwane testy” mamy na myśli pełny zestaw przypadków testowych, które są napisane do wykonania w celu przetestowania danego oprogramowania.

Załóżmy, że aby przetestować oprogramowanie, napisano zestaw 500 przypadków testowych. Teraz w ramach czynności testowych wykonano tylko 300 przypadków testowych. Załóżmy, że jest to spowodowane brakiem czasu. W tym przypadku poniżej przedstawiono pokrycie testowe.

Pokrycie testów = (Wykonane przypadki testowe / Łączna liczba przypadków testowych) * 100
= (300/500) * 100
= 60%

Porównajmy to z tym, czym jest Pokrycie kodu.

Pokrycie kodu

Jest to miara pokazująca stopień, w jakim kod źródłowy aplikacji jest wykonywany podczas testowania kodu. W ten sposób pokazuje stopień, w jakim kod źródłowy zostałby przetestowany.

Załóżmy, że aby przetestować aplikację z 500 liniami kodu, tylko 400 linii kodu zostanie wykonanych przez testy. Załóżmy, że jest to spowodowane niewykonaniem określonej pętli / warunku. W tym przypadku poniżej przedstawiam pokrycie kodu.

Pokrycie kodu = (liczba wykonanych wierszy kodu / całkowita liczba wierszy kodu) * 100
= (400/500) * 100
= 80%

Poniżej wymieniono różnice między pokryciem kodem a pokryciem testowym:

Pokrycie testowePokrycie kodu
Jest to miara tego, jak duża część oczekiwanego testowania została pokryta podczas testowania oprogramowania.Jest to miara pokazująca stopień, w jakim kod źródłowy aplikacji jest wykonywany podczas testowania kodu.
Pokrycie testowe można obliczyć za pomocą poniższego wzoru:

Pokrycie testów = (Wykonane przypadki testowe / Łączna liczba przypadków testowych) * 100		Pokrycie kodu można obliczyć za pomocą poniższego wzoru:

Pokrycie kodu = (liczba wykonanych wierszy kodu / całkowita liczba wierszy kodu) * 100

Metodologie

Tutaj omówimy różne metody, które są / mogą być używane do pomiaru pokrycia kodu.

Aby zrozumieć te metodologie, spójrzmy na poniższy fragment kodu:

Add (int a, int b) { If (b > a) { b = b - a Print b } If (a > b) { b = a – b Print b } Else Print ‘0’ }

Zakres oświadczenia

Ta metodologia jest miarą, która mówi, czy wszystkie możliwe wykonywalne instrukcje kodu w kodzie źródłowym zostały wykonane przynajmniej raz. Jest to metoda zapewniająca, że ​​każdy wiersz kodu źródłowego zostanie przynajmniej raz objęty testami.

Może się to wydawać proste, ale podczas pomiaru pokrycia wyciągu należy zachować ostrożność. Powodem jest to, że w kodzie źródłowym może istnieć pewien warunek, który może nie zostać wykonany w zależności od wartości wejściowych.

Oznaczałoby to, że testowanie nie obejmowałoby wszystkich wierszy kodu. W związku z tym może być konieczne użycie różnych zestawów wartości wejściowych, aby uwzględnić wszystkie takie warunki w kodzie źródłowym.

Na przykład, w powyższym kodzie źródłowym, jeśli wartości wejściowe są przyjmowane jako 2 i 3, część kodu „Inaczej” nie zostanie wykonana. Jeśli jednak wartości wejściowe są typu 3 i 2, część kodu „Jeśli” nie zostanie wykonana.

Oznacza to, że w przypadku żadnego z zestawów wartości naszego Pokrycia Wyciągu nie byłoby 100%. W takim przypadku może być konieczne wykonanie testów ze wszystkimi trzema [(2, 3), (3, 2), (0, 0)] zestawami wartości, aby zapewnić 100% pokrycia instrukcji.

Pokrycie funkcji

Jak sama nazwa wskazuje, metodologia ta mierzy stopień, w jakim funkcje obecne w kodzie źródłowym są pokrywane podczas testowania. Wszystkie funkcje zawarte w kodzie źródłowym są testowane podczas wykonywania testu. Ponownie, należy upewnić się, że przetestowaliśmy te funkcje pod kątem różnych wartości, aby funkcja została dokładnie przetestowana.

W kodzie źródłowym może istnieć wiele funkcji iw zależności od użytych wartości wejściowych funkcja może być wywołana lub nie. Dlatego celem pokrycia funkcji jest zapewnienie, że mamy każdą funkcję, do której się odwołujemy.

Na przykład, w powyższym kodzie źródłowym, jeśli nasze testy wywołują funkcję „Dodaj” choćby raz, nazwalibyśmy to pełnym pokryciem funkcji.

Pokrycie stanu

W kodzie źródłowym wszędzie tam, gdzie mamy warunek, wynikiem będzie wartość logiczna prawda lub fałsz. Pokrycie warunku ma na celu ustalenie, czy testy obejmują obie wartości, tj. Prawda, fałsz.

W kodzie źródłowym, gdy każdy występujący warunek jest oceniany pod kątem zarówno stanu prawdziwego, jak i fałszywego, wówczas pokrycie warunku dla kodu jest kompletne.

Na przykład, w powyższym kodzie, jeśli używane są zestawy wartości (2, 3) i (4, 2), wówczas pokrycie warunku wyniesie 100%. Gdy używany jest zestaw danych (2, 3), wówczas (b> a) przyjmuje wartość prawda, a (a> b) przyjmuje wartość fałsz. Podobnie, gdy używany jest zestaw danych (4, 2), wówczas (b> a) przyjmuje wartość fałsz, a (a> b) przyjmuje wartość true.

czym otwierać pliki xml

Zatem oba warunki mają uwzględnione obie wartości, tj. Prawda i fałsz. W związku z tym pokrycie warunku wyniesie 100%.

Pokrycie oddziałów

Ta metodologia ma na celu zapewnienie, że każda gałąź pojawiająca się w każdej strukturze warunkowej zostanie wykonana w kodzie źródłowym. Na przykład w powyższym kodzie wszystkie stwierdzenia „If” i wszelkie towarzyszące im stwierdzenia „Else” powinny być objęte testem na 100% pokrycie gałęzi.

Na przykład, w powyższym kodzie, jeśli zestawy wartości (2, 3), (4, 2), (1, 1) są używane, wówczas Pokrycie gałęzi wyniesie 100%. Kiedy używany jest zestaw danych (2, 3), wtedy (b> a) i pierwsza gałąź „Jeśli” jest wykonywana. Podobnie, gdy używany jest zestaw danych (4, 2), wówczas (a> b) zwraca wartość „prawda” i wykonywana jest druga gałąź „Jeśli”.

Następnie z zestawem danych (1, 1) gałąź „Else” przyjmuje wartość true i zostaje wykonana. W ten sposób zapewniając 100% pokrycie oddziałów.

Pokrycie gałęzi a pokrycie stanu

Pokrycie oddziału jest często mylone z pokryciem warunkowym, jednak te dwa sposoby są różne.

Zrozummy to na prostym przykładzie.

If (a >0) & (b >0) Then Print “Hello” Else Print “Bye”

Zapiszmy zestaw danych potrzebny do ukończenia Zakres oddziału:

(1, 1) - W tym przypadku „a” i „b” oba są prawdziwe, więc warunek Jeśli zostanie wykonany.
(1, 0) - W tym przypadku „a” jest prawdą, a „b” byłoby fałszem, więc wykonywana jest część kodu Else.

Jak wiemy, celem usługi Branch Coverage jest, aby każda gałąź została wykonana przynajmniej raz i ten cel został osiągnięty.

Pokrycie stanu:

(1, 0) - W tym przypadku „a” jest prawdą, a „b” byłoby fałszem.
(0, 1) - W tym przypadku „a” jest fałszem, a „b” byłoby prawdą.

Celem pokrycia warunku jest uzyskanie wartości prawdziwej i fałszywej dla każdego wykonywanego warunku i ten cel jest tutaj osiągnięty.

Czy zauważyłeś, że druga część nie jest wykonywana w pokryciu warunkowym? Tutaj pokrycie warunku różni się od pokrycia gałęzi.

Narzędzia do pokrycia kodu

Na rynku dostępnych jest kilka narzędzi do pomiaru pokrycia kodem dowolnego oprogramowania.

Poniżej wymieniono niektóre z narzędzi w celach informacyjnych:

  • Parasoft JTest
  • Testwell CTC ++
  • Pokrycie
  • JaCoCo
  • CodeCover
  • BullseyeCoverage
  • EMMA
  • OpenCover
  • NCover
  • Squish COCO
  • CoverageMeter
  • GCT
  • TCAT C / C ++
  • Małgosia
  • JCov

Zalecana lektura => Narzędzia pokrycia kodu

Powyższy link będzie zawierał następujące informacje o tych narzędziach:

  • Kluczowe cechy
  • Rodzaj licencji
  • Oficjalny adres URL
  • Plusy i minusy
  • Ostatnia wersja

Korzyści

Jak widać powyżej, są to bardzo przydatne wskaźniki testowe z następujących powodów:

  • Pomaga zidentyfikować te obszary w kodzie źródłowym, które pozostałyby niesprawdzone / odkryte podczas testów.
  • Przydaje się do identyfikacji używanego / martwego kodu, poprawiając w ten sposób jakość kodu.
  • Skuteczność testów jednostkowych można poznać za pomocą pokrycia kodu.
  • Oprogramowanie o lepszej jakości może być dostarczane przy użyciu tych metryk.

Wady

  • Próba dążenia do 100% pokrycia kodu czasami powoduje brak solidności testów, co skutkuje brakiem możliwości uchwycenia scenariuszy podatnych na defekty.
  • W przeciwieństwie do powszechnego przekonania, nie można zagwarantować, że zaprojektowane oprogramowanie spełnia wszystkie wymagania.

Mity kontra fakty

MitFakt
Posiadanie 100% pokrycia kodu gwarantuje, że oprogramowanie nie będzie zawierało błędów.Nie, 100% pokrycia kodu nie gwarantuje oprogramowania wolnego od błędów. Dobre pokrycie kodu w połączeniu z dobrymi staraniami zespołu ds. Kontroli jakości może zapewnić oprogramowanie z minimalną liczbą błędów lub bez nich.
100% pokrycia kodu oznacza, że ​​napisany kod jest doskonały.Nie, w rzeczywistości, jeśli ważne wymagania nie zostały uchwycone przez kod w pierwszej kolejności, kod nie może być określony jako doskonały, mimo że Pokrycie kodu wynosi 100%.
Pokrycie kodu mierzy skuteczność testów wykonywanych na produkcie oprogramowania.Nie, Pokrycie kodu to tylko miara używana do testowania skuteczności testów jednostkowych, tj. Testów wykonywanych wyłącznie na kodzie źródłowym Oprogramowania.

FAQ's

P # 1) Jakie jest dopuszczalne pokrycie kodu?

Odpowiedź: Osiągnięcie 100% pokrycia kodu nie powinno być celem podczas testowania kodu oprogramowania. Ale dlaczego nie? Aby zrozumieć powód, być może będziesz musiał zanurkować nieco głębiej, aby zrozumieć podstawowe znaczenie.

Kiedy dążymy do 100% pokrycia, częściej zdarza się, że cały nacisk podczas projektowania testów kładzie się na sprawdzenie, czy każda instrukcja, pętla, gałąź lub warunek zostaną przetestowane. Tak więc wkładamy zbyt wiele wysiłków, które mogą nie być warte rozważenia poświęconego czasu.

Co więcej, skupienie się na wysokim pokryciu skutkuje również pominięciem ważnych scenariuszy, które mogą zawierać defekty, ponieważ naszym celem jest tylko upewnienie się, że każda linia kodu jest testowana.

Skoncentrowanie się na wysokim pokryciu kodu nie zawsze jest tak ważne i nie może być stałą liczbą docelową do testowania różnych kodów. Jednak ogólnie pokrycie 75% - 80% powinno być liczbą idealną.

Podczas testowania naszego kodu, głównym celem powinno być zapewnienie uwzględnienia krytycznych i prawdopodobnie podatnych na błędy scenariuszy. Jeśli zostaną one pominięte, to pomimo 100% pokrycia kodu, nasze testy będą miały po prostu słabą skuteczność.

Pytanie nr 2) Jak mogę sprawdzić zakres mojego kodu?

Odpowiedź: Aby przetestować procent pokrycia kodu, który mógłbyś osiągnąć dzięki testom zaprojektowanym do testowania kodu, mamy na rynku kilka narzędzi. W zależności od używanego języka programowania mamy różne narzędzia.

Niektóre z nich są wymienione poniżej:

  • Jawa - Pokrycie, JaCoCo
  • Javascript - Blanket.js, Istambuł
  • Pyton - Coverage.py
  • Rubin - SimpleCov

Korzystając z tych narzędzi, możemy uzyskać pełny raport pokrycia naszych testów, który pomoże nam dowiedzieć się, która część kodu zostanie wykonana, a która zostanie pominięta w naszych testach.

Pytanie nr 3) Czy Pokrycie kodu to dobra miara?

Odpowiedź: W rzeczywistych scenariuszach jest to przydatne do pewnego stopnia i w określony sposób.

Patrząc najpierw na jego ograniczenia, doskonale wiemy, że posiadanie 100% pokrycia nie gwarantuje, że Kod jest wolny od błędów, ani nie gwarantuje, że wszystkie wymagania zostały uwzględnione w kodzie, tj. Pomimo 100% pokrycia kodu jesteśmy bardzo prawdopodobne, że zawiera błędy w kodzie, ponieważ pokrycie nie gwarantuje, że wszystkie scenariusze zostały przetestowane.

Ponadto, jeśli wymagania zostały pominięte podczas pisania kodu, to nie ma mapowania wymagań z kodem, o który zadbano w ramach Pokrycia kodu.

Powiedziawszy to, nie możemy zaprzeczyć, że kiedy używamy pokrycia kodu jako metryki, daje nam to pojęcie, czy uwzględniliśmy podstawowe wymagania testowania każdej linii naszego kodu. Ten procent pokrycia daje nam wyobrażenie o tym, ile części naszego kodu jest wykonywanych za pomocą naszych testów jednostkowych.

Dowiadujemy się, jaka część naszego kodu byłaby niewykonana. To z kolei pomaga nam zdecydować, o ile więcej testów jednostkowych jest potrzebnych i dla których części kodu.

Możemy zatem stwierdzić, że słabe pokrycie daje nam wyobrażenie o nieskuteczności testów jednostkowych. Jednocześnie zapewnienie 100% pokrycia nie gwarantuje kodu wolnego od defektów. Dlatego trzeba mieć wyważone podejście, w którym nie będziemy przesadnie podkreślać znaczenia ukierunkowania na wysoki procent Pokrycia Kodem.

Pytanie 4) Jak mogę poprawić pokrycie mojego kodu?

Odpowiedź: Raport pokrycia kodu dostarczany przez narzędzia pokrycia, takie jak JaCoCo, Istambuł itp., Pokazuje obszary objęte testami, a także te, które nie zostałyby przetestowane.

Znając nieprzetestowane części kodu, testy można pisać ręcznie lub przy użyciu dowolnego narzędzia do automatyzacji, aby objąć obszary, które w innym przypadku nie zostałyby przetestowane, a tym samym zwiększyć pokrycie kodu.

Ważną rzeczą do zapamiętania jest to, że chociaż możemy napisać setki linii kodu, aby przetestować funkcję w kodzie, ale nadal pokrycie może być znacznie mniejsze. Powodem jest to, że zbyt głębokie posunięcie się do przetestowania części ogromnego kodu nie pomoże w zwiększeniu pokrycia kodu.

Tak więc, jeśli celem jest zwiększenie zasięgu, należy dołożyć starań, aby uwzględnić wszystkie funkcje, warunki i pętle, zamiast nurkować głęboko w jednej funkcji i pisać duże testy dla tej pojedynczej funkcji.

java restful web services pytania do rozmowy kwalifikacyjnej

Wniosek

W dzisiejszym szybko zmieniającym się świecie Internetu wymagane jest wysokiej jakości oprogramowanie.

Zapewnienie dobrej jakości oprogramowania to nie tylko obowiązek Inżyniera QA, ale także programisty. Pokrycie kodu jest więc bardzo przydatne, jeśli chodzi o dostarczanie wysokiej jakości produktu zespołowi kontroli jakości przez programistę (-ów).

Ten samouczek wyjaśnia wszystko o pokryciu kodu i jego zastosowaniach. Zagłębiliśmy się również w zrozumienie różnicy między pokryciem kodu a pokryciem testowym. Poza tym zrozumieliśmy stosowane metodologie oraz różne narzędzia do pokrycia kodu.

Przedstawiono tutaj zalety i wady. Wreszcie obaliliśmy niektóre mity i często zadawane pytania związane z pokryciem kodu

Miłego czytania !!

rekomendowane lektury

^