Co to jest testowanie komponentów? Techniki, przykładowe przypadki testowe
⚡ Inteligentne podsumowanie
Testowanie komponentów polega na sprawdzeniu każdej pojedynczej części aplikacji z osobna, bez integrowania jej z resztą, dzięki czemu możliwe jest znalezienie i usunięcie usterek w pojedynczym module przed rozpoczęciem montażu.
Co to jest testowanie komponentów?
Testowanie komponentów To rodzaj testowania oprogramowania, w którym testowanie jest przeprowadzane na każdym pojedynczym komponencie osobno, bez integrowania go z innymi komponentami. Z perspektywy architektury nazywa się to również testowanie modułów, a niektóre źródła nazywają to testowaniem programu.
Każde oprogramowanie jako całość składa się z kilku komponentów, a testowanie na poziomie komponentów polega na testowaniu tych komponentów indywidualnie. Jest to jedno z najczęściej testy czarnej skrzynki typy wykonywane przez zespół ds. zapewnienia jakości.
Warto na wstępie wspomnieć o nazewnictwie. Słownik ISTQB omawia testowanie komponentów i testów jednostkowych jako synonimy tego samego poziomu testów. Wiele zespołów dostarczających, a także niniejszy artykuł, w praktyce rozdziela te dwa pojęcia: programiści przeprowadzają testy jednostkowe na własnym kodzie, a testerzy następnie przeprowadzają testy komponentów na dostarczonej kompilacji. Tabela porównawcza na końcu artykułu przedstawia to praktyczne rozróżnienie.
Jak pokazuje poniższy diagram, testowanie komponentów ma swoją własną strategię i plan testów, w którym każda część oprogramowania lub aplikacji jest rozpatrywana indywidualnie. Dla każdego komponentu scenariusz testowy jest zdefiniowany, a następnie podzielony na przypadki testowe wysokiego poziomu i na końcu na szczegółowe przypadki testowe niskiego poziomu przypadki testowe z wymaganiami wstępnymi.
Sposób użycia terminu „testowanie komponentowe” różni się w zależności od dziedziny i organizacji. Oto trzy najczęstsze przyczyny tej różnicy w postrzeganiu.
- Wybrany typ modelu cyklu życia rozwoju
- Złożoność testowanego oprogramowania lub aplikacji
- Czy testowanie jest przeprowadzane w izolacji od innych komponentów aplikacji, czy też bez niej
Cykl życia testów oprogramowania generuje wiele artefaktów testowych, czyli dokumentów tworzonych i wykorzystywanych podczas testów. Wśród nich znajdują się polityka testów i strategia testów, które definiują rodzaje testów i ich głębokość w danym projekcie.
Kto przeprowadza testy komponentów
Testowanie komponentów wykonują testerzy. Testowanie jednostkowe wykonują programiści, którzy testują poszczególne funkcje lub procedury. Po zakończeniu testów jednostkowych następuje testowanie komponentów, za które odpowiadają testerzy.
Kiedy przeprowadzać testowanie komponentów
Testowanie komponentów odbywa się wkrótce po testowaniu jednostkowym przez programistów, a kompilacja jest udostępniana zespołowi testującemu. Taka kompilacja nazywana jest kompilacją UT lub kompilacją testów jednostkowych. Na tym etapie testowana jest główna funkcjonalność każdego komponentu.
Kryteria wstępne do testów komponentów
- Opracowano i przetestowano jednostkowo minimalny zestaw komponentów, które mają zostać uwzględnione w kompilacji UT.
Kryteria wyjścia z testów modułowych
- Funkcjonalność każdego komponentu działa zgodnie ze specyfikacją.
- W systemie nie ma już otwartych usterek o znaczeniu krytycznym, wysokim lub średnim lub priorytetowym. dziennik defektów.
Techniki testowania komponentów
Ze względu na głębokość poziomu testowania, testowanie komponentów można podzielić na dwie kategorie.
- CTIS — testowanie komponentów w małych rozmiarach
- CTIL — testowanie komponentów na dużą skalę
CTIS — testowanie komponentów w małych rozmiarach
Testowanie komponentów może być przeprowadzane z izolacją od innych komponentów testowanej aplikacji lub bez niej. Jeśli jest przeprowadzane z izolowanymi komponentami, nazywa się to testowaniem komponentów w małej skali.
1 przykład: W przypadku witryny składającej się z pięciu różnych stron internetowych testowanie każdej strony osobno i w izolacji od pozostałych komponentów jest testowaniem komponentów na małą skalę.
2 przykład: Strona główna guru99.com pokazana poniżej zawiera wiele komponentów, takich jak Strona główna, Testowanie, SAP, Sieć, Musisz się nauczyć!, Big Data, Projekty na żywo i Blog.
Każde oprogramowanie składa się z wielu komponentów w ten sam sposób, a każdy komponent ma swoje własne podkomponenty. Testowanie każdego modułu wymienionego w Przykładzie 2 osobno, bez uwzględnienia jego integracji z pozostałymi komponentami, to testowanie komponentów w małych grupach.
Otwarcie menu rozwijanego Testowanie ujawnia podkomponenty komponentu Testowanie: Testowanie ręczne, MYDŁO, QTP, JUnit, Selenium, Zarządzanie testami i Testowanie mobilne. Na poniższym zrzucie ekranu te podkomponenty są podświetlone na czerwono.
CTIL — testowanie komponentów na dużą skalę
Testowanie komponentów wykonywane bez izolacji od innych komponentów testowanej aplikacji nazywa się w szerokim ujęciu testowaniem komponentów.
Przykład wyraźniej wyjaśnia różnicę. Załóżmy, że aplikacja składa się z trzech komponentów: Komponentu A, Komponentu B i Komponentu C.
Deweloper zbudował Komponent B i chce go przetestować. Aby w pełni przetestować Komponent B, część jego funkcjonalności zależy od Komponentu A, a część od Komponentu C, jak ilustruje poniższy diagram.
Przepływ funkcjonalności jest następujący: A → B → C, co oznacza, że komponent B zależy zarówno od A, jak i od C. W tym przepływie funkcją wywoływaną jest element zastępczy, a sterownikiem jest funkcja wywołująca.
Komponent A i Komponent C nie zostały jeszcze opracowane. Aby w pełni przetestować Komponent B, A i C są zastępowane sterownikiem i modułem zastępczym, w razie potrzeby, dzięki czemu dwa brakujące elementy pełnią funkcję obiektów zastępczych, dopóki nie powstaną prawdziwe.
- Końcówka: Komponent testowany wywołuję stub. Komponent C nie jest gotowy, więc zastępuje go stub i zwraca odpowiedzi oczekiwane przez komponent B.
- Kierowca: Sterownik wywołuje testowany komponent. Komponent A nie jest gotowy, więc sterownik go zastępuje i wywołuje B z wymaganymi danymi wejściowymi.
Przykładowe przypadki testowe do testowania komponentów
Dwie poniższe strony internetowe są ze sobą powiązane funkcjonalnie, co czyni je użyteczną parą komponentów do testowania.
Strona internetowa 1 jest stroną logowania do serwisu demonstracyjnego bankowości.
Gdy użytkownik wprowadzi prawidłowy identyfikator użytkownika i hasło i kliknie przycisk „Wyślij”, strona zostanie przeniesiona na stronę główną witryny demonstracyjnej banku, pokazaną poniżej.
Tutaj strona logowania jest jednym komponentem, a strona główna drugim. Testowanie funkcjonalności każdej strony osobno to testowanie komponentowe.
Scenariusze testowania komponentów na stronie internetowej 1:
- Wprowadź nieprawidłowy identyfikator użytkownika i sprawdź, czy użytkownikowi końcowemu wyświetla się czytelne ostrzeżenie.
- Wprowadź nieprawidłowy identyfikator użytkownika i hasło, kliknij Resetuj i sprawdź, czy pola identyfikatora użytkownika i hasła są wyczyszczone.
- Wprowadź prawidłową nazwę użytkownika i hasło, a następnie kliknij przycisk Zaloguj.
Scenariusze testowania komponentów na stronie internetowej 2:
- Sprawdź, czy wiadomość powitalna dla strony menedżera jest wyświetlana na stronie głównej.
- Sprawdź, czy wszystkie linki znajdujące się po lewej stronie strony internetowej są klikalne.
- Sprawdź, czy identyfikator menedżera jest wyświetlany na środku strony głównej.
- Sprawdź obecność trzech różnych obrazów na stronie głównej, zgodnie ze schematem.
Testowanie jednostkowe a testowanie komponentowe
Poniższa tabela podsumowuje różnice pomiędzy tymi dwoma poziomami w codziennej praktyce.
| Testów jednostkowych | Testowanie komponentów |
| Testowanie poszczególnych programów i modułów w celu wykazania, że program wykonuje się zgodnie ze specyfikacją. | Testowanie każdego obiektu lub części oprogramowania osobno, z izolacją od innych obiektów lub bez. |
| Zweryfikowano na podstawie dokumentacji projektowej. | Zweryfikowano pod kątem wymagań testowych i przypadków użycia. |
| Wykonane przez programistów. | Wykonane przez testerów. |
| Zrobione jako pierwsze. | Wykonane po zakończeniu testów jednostkowych przez programistów. |
| Usterki są zazwyczaj naprawiane na miejscu i nie są formalnie rejestrowane. | Wady są rejestrowane i tracprzechodzą przez proces zarządzania defektami. |






