Co to jest zasięg kodu i jak go mierzysz?

Co to jest zasięg kodu i jak go mierzysz?

Zadano mi to pytanie dotyczące naszego zakresu automatyzacji testowania kodu. Wydaje się, że poza zautomatyzowanymi narzędziami jest to więcej sztuki niż nauki. Czy istnieją jakieś rzeczywiste przykłady użycia pokrycia kodu?

Pokrycie kodu jest miarą tego, ile wierszy / bloków / łuków kodu jest wykonywanych podczas uruchomionych testów automatycznych.

Pokrycie kodu jest gromadzone za pomocą specjalistycznego narzędzia do instrumentowania plików binarnych w celu dodania wywołań śledzenia i uruchomienia pełnego zestawu automatycznych testów na oprzyrządowanym produkcie. Dobre narzędzie da ci nie tylko procent wykonanego kodu, ale także pozwoli ci na wwiercenie się w dane i zobaczenie dokładnie, które wiersze kodu zostały wykonane podczas danego testu.

Nasz zespół korzysta z Magellan - wewnętrznego zestawu narzędzi do pokrywania kodu. Jeśli prowadzisz sklep .NET, Visual Studio ma zintegrowane narzędzia do zbierania pokrycia kodu. Możesz także rzucić niestandardowe narzędzia, jak opisano w tym artykule .

Jeśli prowadzisz sklep w C ++, Intel ma narzędzia, które działają w systemach Windows i Linux, chociaż ich nie używałem. Słyszałem również, że istnieje narzędzie gcov dla GCC, ale nic o tym nie wiem i nie mogę podać linku.

Jeśli chodzi o to, jak go wykorzystujemy - pokrycie kodu jest jednym z naszych kryteriów wyjścia dla każdego kamienia milowego. Mamy właściwie trzy wskaźniki pokrycia kodu - zasięg z testów jednostkowych (od zespołu programistów), testy scenariuszy (od zespołu testowego) i zasięg łączony.

BTW, podczas gdy pokrycie kodu jest dobrą miarą tego, ile testów wykonujesz, niekoniecznie jest to dobra miara tego, jak dobrze testujesz swój produkt. Istnieją inne wskaźniki, których należy użyć wraz z pokryciem kodu w celu zapewnienia jakości.

Pokrycie kodu zasadniczo sprawdza, czy część twojego kodu jest objęta testami. Jeśli więc masz 90% pokrycia kodu, oznacza to, że istnieje 10% kodu, który nie jest objęty testami. Wiem, że możesz myśleć, że 90% kodu jest objęte, ale musisz spojrzeć z innej strony. Co powstrzymuje Cię przed uzyskaniem 100% pokrycia kodu?

Dobrym przykładem będzie:

if(customer.IsOldCustomer()) 
{
}
else 
{
}

Teraz w powyższym kodzie są dwie ścieżki / gałęzie. Jeśli zawsze trafiasz do gałęzi „TAK”, nie zakrywasz innej części i będzie to widoczne w wynikach pokrycia kodu. Jest to dobre, ponieważ teraz wiesz, że to, co nie jest objęte, i możesz napisać test obejmujący inną część. Jeśli nie było zasięgu kodu, to po prostu siedzisz na bombie czasowej, aby eksplodować.

NCover to dobre narzędzie do pomiaru pokrycia kodu.

Pamiętaj tylko, że posiadanie „100% pokrycia kodu” nie oznacza, że ​​wszystko jest testowane całkowicie - podczas gdy oznacza to, że każda linia kodu jest testowana, nie oznacza to, że są one testowane w każdej (wspólnej) sytuacji.

Używałbym pokrycia kodu, aby wyróżnić fragmenty kodu, dla których prawdopodobnie powinienem pisać testy. Na przykład, jeśli jakiekolwiek narzędzie do pokrywania kodu pokazuje, że myImportantFunction () nie jest wykonywane podczas uruchamiania moich bieżących testów jednostkowych, prawdopodobnie powinny zostać poprawione.

Zasadniczo 100% pokrycia kodu nie oznacza, że ​​Twój kod jest idealny. Użyj go jako przewodnika do napisania bardziej kompleksowych testów (jednostkowych).

Uzupełnienie kilku punktów do wielu poprzednich odpowiedzi:

Pokrycie kodu oznacza, jak dobrze twój zestaw testowy pokrywa twój kod źródłowy. tzn. w jakim zakresie kod źródłowy jest objęty zestawem przypadków testowych.

Jak wspomniano w powyższych odpowiedziach, istnieją różne kryteria zasięgu, takie jak ścieżki, warunki, funkcje, instrukcje itp. Jednak dodatkowe kryteria, które należy uwzględnić, to

1. Pokrycie warunku: wszystkie wyrażenia logiczne, które mają być ocenione na wartość prawda i fałsz.
2. Zakres decyzji: Nie tylko wyrażenia boolowskie mają być raz ocenione na prawdziwość i fałsz, ale także na całe kolejne ciało if-elseif-else.
3. Pokrycie pętli: oznacza, że ​​każda możliwa pętla została wykonana raz, więcej niż raz i zero czasu. Ponadto, jeśli mamy założenie dotyczące maksymalnego limitu, wówczas, jeśli jest to wykonalne, przetestuj maksymalne czasy graniczne i, jeden więcej niż maksymalne czasy graniczne.
4. Zakres wejścia i wyjścia: Sprawdź wszystkie możliwe połączenia i ich wartość zwrotną.
5. Pokrycie wartości parametru (PVC). Aby sprawdzić, czy wszystkie możliwe wartości parametru są testowane. Na przykład ciąg może być dowolnym z tych często: a) null, b) pusty, c) biały znak (spacja, tabulatory, nowa linia), d) prawidłowy ciąg, e) nieprawidłowy ciąg, f) ciąg jednobajtowy, g ) łańcuch dwubajtowy. Nie przetestowanie każdej możliwej wartości parametru może pozostawić błąd. Testowanie tylko jednego z nich może skutkować 100% pokryciem kodu, ponieważ każdy wiersz jest objęty, ale ponieważ testowana jest tylko jedna z siedmiu opcji, oznacza to, że tylko 14,2% pokrycia wartości parametru.
6. Zasięg dziedziczenia: W przypadku źródła obiektowego zwracając obiekt pochodny, do którego odwołuje się klasa podstawowa, należy sprawdzić zasięg w celu oceny, czy zwracany jest obiekt rodzeństwa.

Uwaga: Analiza kodu statycznego wykryje, czy istnieje kod nieosiągalny lub kod wiszący, tj. Kod nieobjęty żadnym innym wywołaniem funkcji. A także inne pokrycie statyczne. Nawet jeśli statyczna analiza kodu zgłasza, że ​​objęty jest kodem 100%, nie daje raportów o zestawie testowym, jeśli testowane jest całe możliwe pokrycie kodu.

Zakres kodu został dobrze wyjaśniony w poprzednich odpowiedziach. To raczej odpowiedź na drugą część pytania.

Użyliśmy trzech narzędzi do określenia zasięgu kodu.

1. JTest - autorskie narzędzie zbudowane na JUnit. (Generuje również testy jednostkowe.)
2. Cobertura - narzędzie do pokrywania kodu o otwartym kodzie źródłowym, które można łatwo połączyć z testami JUnit w celu generowania raportów.
3. Emma - kolejny - ten, którego użyliśmy w nieco innym celu niż testowanie jednostkowe. Służy do generowania raportów zasięgu, gdy użytkownicy końcowi uzyskują dostęp do aplikacji internetowej. W połączeniu z narzędziami do testowania stron internetowych (przykład: Canoo) można uzyskać bardzo przydatne raporty zasięgu, które informują o tym, ile kodu jest pokrywane podczas typowego użytkowania przez użytkownika końcowego.

Używamy tych narzędzi do

• Sprawdź, czy programiści napisali dobre testy jednostkowe
• Upewnij się, że cały kod jest przechodzony podczas testowania czarnej skrzynki

Pokrycie kodu jest po prostu miarą testowanego kodu. Istnieje wiele kryteriów zasięgu, które można zmierzyć, ale zazwyczaj to różne ścieżki, warunki, funkcje i stwierdzenia w programie tworzą całkowity zasięg. Metryka pokrycia kodu to tylko odsetek testów, które wykonują każde z tych kryteriów pokrycia.

Jeśli chodzi o sposób pokrycia testu jednostki śledzenia w moich projektach, używam narzędzi do analizy kodu statycznego, aby śledzić.

Dla Perla jest doskonały moduł Devel :: Cover , którego regularnie używam na swoich modułach.

Jeśli kompilacją i instalacją zarządza moduł :: Build, możesz po prostu uruchomić, ./Build testcoveraby uzyskać ładną stronę HTML, która informuje o pokryciu według poddziału, linii i stanu, z ładnymi kolorami ułatwiającymi sprawdzenie, która ścieżka kodu nie została uwzględniona.

W poprzednich odpowiedziach Kodeks został dobrze wyjaśniony. Ja po prostu dodając pewną wiedzę związaną z narzędziami jeśli pracują nad iOSi OSXplatformy, Xcode zapewnia obiektu do pokrycia testu i monitor kodu.

Linki referencyjne:

https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/07-code_coverage.html

https://medium.com/zendesk-engineering/code-coverage-and-xcode-6b2fb8756a51

Oba są pomocnymi linkami do nauki i odkrywania pokrycia kodu za pomocą Xcode.

W przypadku PHP powinieneś rzucić okiem na Github od Sebastiana Bergmanna

Zapewnia funkcje gromadzenia, przetwarzania i renderowania informacji o zasięgu kodu PHP.

https://github.com/sebastianbergmann/php-code-coverage