Rodzaje testowania oprogramowania
Testów jednostkowych
Testowanie jednostkowe wykonuje się na indywidualnej funkcji, klasie lub module niezależnie niż testowanie w pełni działającego oprogramowania. Korzystając z frameworka do testowania jednostki, programista może tworzyć przypadki testowe z wejściem i oczekiwanym wyjściem. Posiadając setki, tysiące lub dziesiątki tysięcy przypadków testów jednostkowych dla dużego projektu oprogramowania, zapewnia, że wszystkie poszczególne jednostki działają zgodnie z oczekiwaniami. Podczas zmiany jednostki, która ma przypadki testowe, przypadki testowe dla tego modułu należy zbadać i ustalić, czy potrzebne są nowe przypadki testowe, dane wyjściowe uległy zmianie lub obecne przypadki testowe można usunąć, ponieważ nie są już istotne. Tworzenie dużej ilości testów jednostkowych jest najłatwiejszym sposobem na osiągnięcie wysokiego pokrycia przypadków testowych dla bazy kodu oprogramowania, ale nie zapewni, że produkt końcowy działa jako system zgodnie z oczekiwaniami.
Testy funkcjonalności
Testowanie funkcjonalne jest najczęstszą formą testowania. Kiedy ludzie odnoszą się do testowania oprogramowania bez większych szczegółów, często oznaczają testy funkcjonalne. Testy funkcjonalne sprawdzi, że podstawowe funkcje oprogramowania działają zgodnie z oczekiwaniami. Można napisać plan testowy opisujący wszystkie funkcjonalne przypadki testowe, które zostaną przetestowane, co odpowiada głównym funkcjom i możliwościom oprogramowania. Podstawowe testy funkcjonalności będą „Szczęśliwa ścieżka ” Testowanie, które nie próbują łamać oprogramowania ani używać go w żadnych trudnych scenariuszach. Powinno to być absolutne absolutne minimum testowania każdego projektu oprogramowania.
Testy integracyjne
Po testowaniu jednostkowym i testowaniu funkcjonalnym może istnieć kilka modułów lub cały system, który nie został jeszcze przetestowany jako całość. Lub mogą istnieć komponenty, które są w dużej mierze niezależne, ale czasami używane razem. Komponenty lub moduły czasowe są testowane niezależnie, ale nie jako cały system, wówczas należy przeprowadzić testy integracji, aby zweryfikować funkcję komponentów razem jako system działający zgodnie z wymaganiami i oczekiwaniami użytkownika.
Test naprężeń
Pomyśl o testach warunków skrajnych, jakbyś testował prom kosmiczny lub samolot. Co to znaczy umieścić oprogramowanie lub system w „stresie”? Stres jest niczym więcej niż intensywnym obciążeniem określonego typu, który najprawdopodobniej przełamie Twój system. Może to być podobne do „testowania obciążenia” w sensie stawiania systemu pod wysoką współbieżnością z wieloma użytkownikami uzyskującym dostęp do systemu. Ale podkreślenie systemu może się zdarzyć również w innych wektorach. Na przykład uruchamianie oprogramowania na sprzętowym komponencie, gdy sprzęt ma fizyczne pogorszenie i działa w trybie zdegradowanym. Stres jest unikalny dla wszystkich rodzajów oprogramowania, a systemy i projektowanie testów warunków skrajnych powinny znajdować się na podstawie tego, jakie przyczyny naturalne lub nienaturalne najprawdopodobniej podkreślają Twoje oprogramowanie lub system.
Testowanie obciążenia
Testowanie obciążenia to specyficzny rodzaj testów warunków skrajnych, jak omówiono powyżej, w którym duża liczba jednoczesnych połączeń użytkownika i dostępów jest automatyzowana w celu generowania symulacji efektu dużej liczby autentycznych użytkowników dostępu do systemu oprogramowania w tym samym czasie. Celem jest ustalenie, ilu użytkowników może uzyskać dostęp do Twojego systemu w tym samym czasie bez zerwania systemu oprogramowania. Jeśli system może łatwo poradzić sobie z normalnym ruchem 10 000 użytkowników, co się stanie, jeśli Twoja witryna lub oprogramowanie stanie się wirusowe i uzyska 1 milion użytkowników? Czy to nieoczekiwane "OBCIĄŻENIE" Zniszcz swoją witrynę lub system? Testy obciążenia to symuluje, więc czujesz się komfortowo z przyszłym wzrostem użytkowników, ponieważ wiesz, że Twój system może obsłużyć zwiększone obciążenie.
Test wydajności
Ludzie mogą stać się całkowicie sfrustrowani i rozpaczać, gdy oprogramowanie nie spełnia wymagań dotyczących wydajności. Wydajność ogólnie oznacza, jak szybko można wykonać ważne funkcje. Im bardziej złożone i dynamiczne funkcje są dostępne w systemie, tym ważniejsze i nieoczyne staje się przetestowanie jego wydajności, weźmy podstawowy przykład, system operacyjny systemu Windows lub Linux. System operacyjny jest wysoce złożonym oprogramowaniem, a przeprowadzanie testów wydajności w jego systemie może obejmować szybkość i czas funkcji, takich jak uruchamianie, instalowanie aplikacji, wyszukiwanie pliku, uruchamianie obliczeń na GPU i/lub dowolnym innym miliony działań, które można wykonać. Podczas wybierania przypadków testu wydajności należy zachować ostrożność, aby zapewnić, że ważne i prawdopodobne, że nieudane funkcje wydajności testowane.
Testowanie skalowalności
Testowanie na laptopie jest dobre, ale nie do końca dobre, gdy budujesz sieć społecznościową, system e -mail lub oprogramowanie superkomputerów. Gdy twoje oprogramowanie ma być wdrażane na 1000 serwerach, wszystkie funkcjonujące zgodnie z tym, wówczas testowanie lokalnie w jednym systemie nie odkryją błędów, które występują, gdy oprogramowanie jest wdrażane „na skalę” na setkach tysięcy instancji. W rzeczywistości twoje testy prawdopodobnie nigdy nie będą mogły działać na pełną skalę przed wydaniem produkcji, ponieważ byłoby zbyt drogie i nie praktyczne, aby zbudować system testowy z 1000 serwerów kosztującym miliony dolarów. Dlatego testy skalowalności odbywają się na wielu serwerach, ale zwykle nie pełna liczba serwerów produkcyjnych, aby spróbować odkryć niektóre wady, które można znaleźć, ponieważ systemy są używane w większej infrastrukturze.
Testowanie analizy statycznej
Analiza statyczna to testowanie, które odbywa się poprzez sprawdzenie kodu oprogramowania bez faktycznego uruchamiania. Aby przeprowadzić analizę statyczną, ogólnie korzystasz z narzędzia, jest wiele, jedno słynne narzędzie jest okładka. Analiza statyczna jest łatwa do uruchomienia przed wydaniem oprogramowania i może znaleźć wiele problemów z jakością w kodzie, które można naprawić przed wydaniem. Błędy pamięci, błędy obsługi typu danych, dereferencje zerowe, niezainicjowane zmienne i wiele innych wad można znaleźć. Języki takie jak C i C ++ bardzo korzystają z analizy statycznej, ponieważ języki zapewniają wielką swobodę programistom w zamian za wielką moc, ale może to również tworzyć świetne błędy i błędy, które można znaleźć za pomocą testowania analizy statycznej.
Testowanie wtrysku błędów
Niektóre warunki błędów są bardzo trudne do symulacji lub wyzwalania, dlatego oprogramowanie może być zaprojektowane do sztucznego wstrzykiwania problemu lub usterki do systemu bez wady w naturalny sposób. Celem testowania wtrysku usterki jest sprawdzenie, w jaki sposób oprogramowanie radzi sobie z tymi nieoczekiwanymi błędami. Czy to wdzięcznie reaguje na sytuację, czy rozbija się, czy też przynosi nieoczekiwane i nieprzewidywalne problematyczne wyniki? Załóżmy na przykład, że mamy system bankowy i istnieje moduł do przesyłania środków wewnętrznie z konta A na konto B. Jednak ta operacja transferu jest wywoływana dopiero po tym, jak system już zweryfikował, że te konta istniały przed wywołaniem operacji transferu. Mimo że zakładamy, że oba konta istnieją, operacja transferu ma przypadek awarii, w którym jedno konto docelowe lub źródłowe nie istnieje, i że może rzucić błąd. Ponieważ w normalnych okolicznościach nigdy nie otrzymujemy tego błędu z powodu wstępnego testowania danych wejściowych, więc aby sprawdzić zachowanie systemowe, gdy przeniesienie się nie powiedzie z powodu nieistniejącego konta, wstrzykujemy fałszywy błąd do systemu, który zwraca nieistniejący konto w celu przeniesienia i przetestowania, jak reaguje reszta systemu w takim przypadku. Bardzo ważne jest, aby kod wtrysku usterki był dostępny tylko w scenariuszach testowych, a nie wydany do produkcji, gdzie może wywołać spustoszenie.
Testowanie z przepełnieniem pamięci
Podczas korzystania z języków takich jak C lub C ++ programista ponosi wielką odpowiedzialność za bezpośrednie adresowanie pamięci, co może powodować śmiertelne błędy w oprogramowaniu. Na przykład, jeśli wskaźnik jest zerowy i odniesiony, oprogramowanie zawiedzie. Jeśli pamięć jest przydzielana do obiektu, a następnie ciąg jest kopiowany przez przestrzeń pamięci obiektu, odwołanie się do obiektu może spowodować awarię lub nawet nieokreślone niewłaściwe zachowanie. Dlatego bardzo ważne jest użycie narzędzia do próbowania złapania błędów dostępu do pamięci w oprogramowaniu, które wykorzystują języki takie jak C lub C ++, które mogą mieć te potencjalne problemy. Narzędzia, które mogą wykonać ten rodzaj testowania, obejmują open source Valgrind lub narzędzia zastrzeżone, takie jak PurifyPlus. Te narzędzia mogą zapisać dzień, w którym nie jest jasne, dlaczego oprogramowanie zawiesza się lub źle się zachowuje, i bezpośrednio wskazują na lokalizację w kodzie, który ma błąd. Niesamowite, prawda?
Testowanie przypadków granicznych
Łatwo jest popełniać błędy w kodowaniu, gdy jesteś na tak zwanej granicy. Na przykład automatyczna maszyna do banku twierdzi, że możesz wypłacić maksymalnie 300 USD. Wyobraź sobie więc, że Coder napisał następujący kod naturalnie podczas budowania tego wymogu:
If (amt < 300)
startWithDrawl ()
w przeciwnym razie
błąd („możesz wycofać %s”, AMT);
Czy możesz zauważyć błąd? Użytkownik, który próbuje wycofać 300 USD, otrzyma błąd, ponieważ nie jest mniej niż 300 USD. To jest błąd. Dlatego testowanie graniczne odbywa się naturalnie. Zagraniczne wymagania upewnij się, że po obu stronach granicy i granicy oprogramowanie działa poprawnie.
Testowanie fuzz
Szybka generowanie danych wejściowych do oprogramowania może wytworzyć tyle możliwych kombinacji wejściowych, nawet jeśli te kombinacje wejściowe są totalne i nigdy nie byłyby dostarczane przez prawdziwego użytkownika. Ten rodzaj testowania fuzz może znaleźć błędy i luki w zabezpieczeniach, które nie są znalezione za pomocą innych środków ze względu na dużą objętość danych wejściowych i scenariuszy testowanych szybko bez ręcznego generowania przypadków testów.
Testy eksploracyjne
Zamknij oczy i wizualizuj, co oznacza słowo „eksploruj”. Obserwujesz i badasz system, aby dowiedzieć się, jak naprawdę funkcjonuje. Wyobraź sobie, że otrzymujesz nowe krzesło biurkowe w wysyłce i ma 28 części w osobnych plastikowych torbach bez instrukcji. Musisz zbadać swoje nowe przybycie, aby dowiedzieć się, jak funkcjonuje i jak się składa. Z tym duchem możesz zostać testerem eksploracyjnym. Nie będziesz miał dobrze zdefiniowanego planu testów przypadków testowych. Zbadasz i badasz swoje oprogramowanie, szukając rzeczy, które sprawiają, że wypowiesz cudowne słowo: „Ciekawe!". Po nauce badasz dalej i znajdujesz sposoby na przełamanie oprogramowania, o którym projektanci nigdy nie myśleli, a następnie dostarczasz raport, który szczegółowo opisuje wiele złych założeń, błędów i ryzyka w oprogramowaniu. Dowiedz się więcej o tym w książce zatytułowanej Explore It.
Testowanie penetracji
W świecie bezpieczeństwa oprogramowania testowanie penetracji jest jednym z głównych sposobów testowania. Wszystkie systemy, czy to biologiczne, fizyczne, czy oprogramowanie, mają granice i granice. Te granice mają na celu umożliwienie tylko konkretnym komunikatom, ludziom lub komponentom wprowadzania systemu. Bardziej konkretnie, rozważmy system bankowości internetowej, który wykorzystuje uwierzytelnianie użytkownika do wprowadzenia witryny. Jeśli witryna może zostać zhakowana i wpisana do zaplecza bez odpowiedniego uwierzytelniania, to byłaby penetracja, której należy chronić. Celem testowania penetracji jest wykorzystanie znanych i eksperymentalnych technik do ominięcia normalnej granicy bezpieczeństwa systemu lub strony internetowej. Testy penetracji często polega na sprawdzeniu wszystkich portów, które słuchają i próba wprowadzenia systemu za pośrednictwem otwartego portu. Inne popularne techniki obejmują wtrysk SQL lub pękanie haseł.
Testowanie regresji
Po wdrożeniu oprogramowania, które jest wdrażane w terenie, ważne jest, aby zapobiec wprowadzaniu błędów do funkcjonalności, która już działała. Celem rozwoju oprogramowania jest zwiększenie możliwości produktu, wprowadzenie błędów lub spowodowanie, że stara funkcjonalność przestała działać, co nazywa się regresją. Regresja to błąd lub wada, która została wprowadzona, gdy wcześniej możliwość działała zgodnie z oczekiwaniami. Nic nie może zrujnować reputacji twojego oprogramowania lub marki szybciej niż wprowadzenie błędów regresji do oprogramowania i posiadanie prawdziwych użytkowników znalezienia tych błędów po wydaniu.
Przypadki testowania regresji i plany testowe powinny być zbudowane wokół podstawowej funkcjonalności, która musi kontynuować pracę, aby upewnić się, że użytkownicy mieli dobre doświadczenie w aplikacji. Wszystkie podstawowe funkcje oprogramowania, które użytkownicy spodziewają się działać w określony sposób, powinny mieć przypadek testowy regresji, który można wykonać, aby zapobiec zerwaniu funkcjonalności w nowej wersji. Może to być od 50 do 50 000 przypadków testowych, które obejmują podstawową funkcjonalność oprogramowania lub aplikacji.
Testowanie bisekcji kodu źródłowego
W oprogramowaniu wprowadzono błąd, ale nie jest oczywiste, która wersja wydania wprowadziła nowy błąd. Wyobraź sobie, że było 50 zatwierdzeń oprogramowania z ostatniego znanego czasu, w którym oprogramowanie działało bez błędu, do tej pory…
Testowanie lokalizacji
Wyobraź sobie aplikację pogodową, która pokazuje obecną i przewidywaną pogodę w Twojej lokalizacji, a także opis warunków pogodowych. Pierwszą częścią testowania lokalizacji jest upewnienie się, że prawidłowy język, alfabet i znaki są odpowiednio wyświetlane, w zależności od geolokalizacji użytkownika. Aplikacja w Wielkiej Brytanii powinna być wyświetlana w języku angielskim z postaciami łacińskimi; Ta sama aplikacja w Chinach powinna być wyświetlana w chińskich znakach w języku chińskim. Bardziej skomplikowane testy lokalizacyjne, szerszy zakres osób z różnych geolokacji będzie łączył się z aplikacją.
Testowanie dostępności
Niektórzy obywatele w naszej społeczności mają niepełnosprawność, a zatem mogą mieć problemy z korzystaniem z tworzonego oprogramowania, więc przeprowadzane są testy dostępności, aby upewnić się, że populacje niepełnosprawne mogą nadal uzyskać dostęp do funkcjonalności systemu. Na przykład, jeśli założymy, że 1% populacji jest ślepy na kolory, a nasz interfejs oprogramowania zakłada, że użytkownicy mogą rozróżnić czerwony i zielony, ale te ślepe osoby nie mogą powiedzieć różnicy. Dlatego dobrze rozebrane interfejs będzie miał dodatkowe wskazówki wykraczające poza kolor, aby wskazać znaczenie. Inne scenariusze oprócz testowania ślepoty kolorów zostałyby również uwzględnione w testowaniu dostępności oprogramowania, takie jak pełna ślepota wizualna, głuchota i wiele innych scenariuszy. Dobry oprogramowanie powinno być dostępne przez maksymalny odsetek potencjalnych użytkowników.
Testowanie aktualizacji
Proste aplikacje w telefonie, systemy operacyjne, takie jak Ubuntu, Windows lub Linux Mint, oraz oprogramowanie uruchamiające okręty podwodne nuklearne wymaga częstego aktualizacji. Proces samego aktualizacji może wprowadzić błędy i wady, które nie istniałyby w nowej instalacji, ponieważ stan środowiska był inny, a proces wprowadzania nowego oprogramowania na górze starego. Weźmy prosty przykład, mamy laptopa z Ubuntu 18.04 i chcemy uaktualnić do Ubuntu 20.04. Jest to inny proces instalowania systemu operacyjnego niż bezpośrednie czyszczenie dysku twardego i instalowanie Ubuntu 20.04. Dlatego po zainstalowaniu oprogramowania lub dowolnej z jego funkcji pochodnych może nie działać w 100% zgodnie z oczekiwaniami lub tak samo jak w przypadku świeżo zainstalowanego oprogramowania. Powinniśmy więc najpierw rozważyć przetestowanie samego aktualizacji w wielu różnych przypadkach i scenariuszach, aby upewnić się, że aktualizacja działała do zakończenia. A następnie musimy również rozważyć przetestowanie rzeczywistej aktualizacji postu, aby upewnić się, że oprogramowanie zostało złożone i działać zgodnie z oczekiwaniami. Nie powtórzylibyśmy wszystkich przypadków testowych świeżo zainstalowanego systemu, co byłoby stratą czasu, ale będziemy uważnie zastanowić się nad naszym wiedzą o systemie, co może się zepsuć podczas aktualizacji i strategicznie dodać przypadki testowe dla tych funkcji.
Black Box & White Box Testowanie
Czarne pudełko i białe pudełko to mniej specyficzne metodologie testowe i więcej rodzajów kategoryzacji testowania. Zasadniczo testy Black Box, które zakładają, że tester nie wie nic o wewnętrznym działaniu oprogramowania i buduje plan testowy i przypadki testowe, które po prostu patrzą na system z zewnątrz, aby zweryfikować jego funkcję. Testowanie białych pudełek odbywa się przez architektów oprogramowania, którzy rozumieją wewnętrzne funkcjonowanie systemu oprogramowania i projektują przypadki, wiedząc o tym, co mogłoby, powinny i prawdopodobnie złamać. Zarówno testowanie czarnych, jak i białych pudełek prawdopodobnie znajdą różne rodzaje wad.
Blogi i artykuły na temat testowania oprogramowania
Testowanie oprogramowania to dziedzina dynamiczna oraz wiele interesujących publikacji i artykułów, które aktualizują społeczność o najnowocześniejszym myśleniu o testowaniu oprogramowania. Wszyscy możemy skorzystać z tej wiedzy. Oto próbka interesujących artykułów z różnych źródeł blogów, które możesz chcieć przestrzegać:
- 7 wskazówek do naśladowania przed testowaniem bez wymagań; http: // www.Testingjournals.com/
- 60 najlepszych narzędzi do testowania automatyzacji: przewodnik listy Ultimate; https: // testGuild.com/
- Narzędzia do testowania bazy danych typu open source; https: // www.SoftWareTestingMagazine.com/
- 100 -procentowe pokrycie testu jednostkowego nie wystarczy; https: // www.Koczka.com/
- Testy łuszczące się w Google i sposób ich łagodzenia; https: // testowanie.Googleblog.com/
- Co to jest testowanie regresji? ; https: // test.IO/Blog/
- 5 Kluczowe kroki testowania oprogramowania powinien wykonać każdy inżynier; https: // techbeacon.com/
Produkty do testowania oprogramowania
Większość cennych zadań testowych można zautomatyzować, więc nie powinno być zaskoczeniem, że użycie narzędzi i produktów do wykonywania niezliczonych zadań dotyczących zapewnienia jakości oprogramowania jest dobrym pomysłem. Below we will list some important and highly valuable software tools for software testing that you can explore and see if they can help.
Junit
Do testowania oprogramowania opartego na Javie Junit zapewnia kompleksowy pakiet testowy dla jednostek i funkcjonalne testy kodu przyjazne dla środowiska Java.
Selen
Do testowania aplikacji internetowych Selenium zapewnia możliwość automatyzacji interakcji z przeglądarkami internetowymi, w tym testowanie kompatybilności między przeglądarkami. Jest to najważniejsza infrastruktura testowa do automatyzacji testowania sieci.
Ogórek
Ramy testowe oparte na zachowaniu pozwala użytkownikom biznesowym, menedżerom produktu i programistom wyjaśnienie oczekiwanej funkcjonalności w języku naturalnym, a następnie zdefiniowanie tego zachowania w przypadkach testowych. To sprawia, że czytelne przypadki testowe i jasne mapowanie na oczekiwaną funkcjonalność użytkownika.
Oczyścić
Znajdź wycieki pamięci i uszkodzenia pamięci w czasie wykonywania, wykonując oprogramowanie z osadzonym Purify Plus Instrumentation, które śledzi zużycie pamięci i wskazuje błędy w kodzie, które nie są łatwe do znalezienia bez oprzyrządowania.
Valgrind
Narzędzia typu open source, które będą wykonywać oprogramowanie i umożliwią interakcję z nim, wskazując raport błędów błędów kodowania, taki jak wycieki pamięci i uszkodzenia. Nie trzeba ponownie kompiluwać ani dodawać oprzyrządowania do procesu kompilacji, ponieważ Valgrind ma inteligencję do dynamicznego zrozumienia kodu maszynowego i bezproblemowego wstrzykiwania oprzyrządowania, aby znaleźć błędy kodowania i pomóc ulepszyć kod.
Pokrycie
Narzędzie statyczne analizy, które znajdzie błędy kodowania w oprogramowaniu, zanim jeszcze skompilujesz i uruchomisz kod. Ochrona może znaleźć luki w zabezpieczeniach, naruszenia konwencji kodowania, a także błędy i wady, których nie znajdzie kompilator. Martwy kod można znaleźć, niezainicjowane zmienne i tysiące innych rodzajów defektów. Ważne jest, aby wyczyścić kod za pomocą analizy statycznej przed wypuszczeniem go do produkcji.
Jmeter
Ramy open source do testowania wydajności zorientowanego na programistów opartych na Javie, stąd J w nazwie. Testowanie strony internetowej jest jednym z głównych przypadków użycia dla JMeter oprócz testowania wydajności baz danych, systemów pocztowych i wielu innych aplikacji opartych na serwerze.
Metasploit
W przypadku testów bezpieczeństwa i penetracji Metasploit to ogólna struktura z tysiącami funkcji i możliwości. Użyj konsoli interakcji, aby uzyskać dostęp do wstępnie zakodowanych exploitów i spróbuj zweryfikować bezpieczeństwo aplikacji.
Badania akademickie dotyczące testów oprogramowania
- University of Sheffield Testing Group
- Laboratorium weryfikacji oprogramowania i walidacji University of Kentucky
- North Dakota State University Testing Testing Research Group
- Testowanie systemowe Inteligentne laboratorium; Praga z uniwersytetu technicznego czeskiego
- NASA: Jon McBride Software Testing and Research (JSTAR)
- McMaster University; Laboratorium badań jakości oprogramowania
- Ontario Tech University; Laboratorium badań jakości oprogramowania
- University of Texas @ Dallas; STQA
Wniosek
Rola oprogramowania w społeczeństwie wciąż rośnie, a jednocześnie światowe oprogramowanie staje się bardziej złożone. Aby świat działał, musimy mieć metody i strategie testowania i walidacji tworzonego oprogramowania, wykonując funkcje, które ma wykonywać. Dla każdego złożonego systemu oprogramowania powinien być opanowany strategia testowa i plan testowy, aby nadal sprawdzać funkcjonalność oprogramowania, ponieważ nadal się poprawiają i zapewniać jego funkcję.