Zyski:
- Umiejętność odczytywania metryk, takich jak pokrycie linii, gałęzi i stanu, w formie mapy, a nie zaufania, oraz zrozumienia, że duże pokrycie może dawać pseudozaufanie
- Możliwość umieszczenia zakresu wymagań obok zakresu kodu i uwidocznienia luk w identyfikowalności za pomocą sztucznej inteligencji
- Możliwość oceniania funkcji za pomocą wzoru ryzyko = prawdopodobieństwo × wpływ, kierowania ograniczonych wysiłków testowych na najwyższe ryzyko i dokumentowania celowego wykraczania poza zakres
Nie możesz wiecznie testować każdego oprogramowania; Czas i zasoby są ograniczone. Zatem prawdziwe pytanie brzmi: gdzie umieścić ograniczony wysiłek związany z testowaniem? Na to pytanie odpowiadają dwie koncepcje. Pokrycie testów — metryka mierząca, jaka część kodu lub wymagań jest dotknięta testami — reprezentuje to, co jest testowane. Testowanie oparte na ryzyku – podejście polegające na określeniu priorytetu testu na podstawie prawdopodobieństwa pogorszenia się obszaru i szkód, jakie spowoduje w przypadku jego pogorszenia – kieruje wysiłki w kierunku największego ryzyka. Sztuczna inteligencja (AI) jest potężnym partnerem analitycznym w obu przypadkach: uwidacznia luki w zasięgu, sugeruje obszary ryzyka. Pozostaje jednak zasadnicze zastrzeżenie: liczba zakresów, które widzi sztuczna inteligencja, może wprowadzać w błąd; Nawet 100% pokrycia wierszy można osiągnąć za pomocą testów, które niczego nie weryfikują. Twoim zadaniem jest odczytanie zakresu jako mapy, a nie zaufania.
Prawidłowe odczytywanie wskaźników zasięgu
Istnieje kilka rodzajów zakresu i nie wszystkie są jednakowo znaczące:
- Pokrycie linii: ile linii kodu zostało wykonanych co najmniej raz. Najczęstsze, ale najsłabsze kryterium; To, że linia działa, nie jest dowodem na to, że zachowuje się ona prawidłowo.
- Pokrycie gałęzi: czy przetestowano każdą gałąź if (zarówno prawdziwą, jak i fałszywą). Bardziej znaczące niż linia.
- Pokrycie warunku: oddzielne testowanie każdego warunku podrzędnego w złożonych warunkach.
- Pokrycie ścieżki: kombinacje ścieżek logicznych w kodzie. Jest to najbardziej wszechstronne, choć trudne do osiągnięcia w praktyce.
Uwaga: procent pokrycia nie jest „wynikiem jakości”. 100% pokrycia wierszy informuje, że wiersze działają; nie dlatego, że daje poprawny wynik (pseudoprzejście w jednostce 1). Użyj zakresu jako odpowiedzi na pytanie „gdzie nigdy nie szukałem”, a nie jako zapewnienia, że „wszystko zostało przetestowane”.
Zakres martwych punktów
Metryki pokrycia mierzą jedynie ilość kodu, która została wykonana; nie widzi: (1) nieprzetestowanych wymagań (kod istnieje, ale reguła biznesowa jest błędna), (2) brakującego kodu (brak możliwości dla kontrolki, która nigdy nie została napisana), (3) kombinacji danych/stanów, (4) użyteczności, wydajności, bezpieczeństwa. Dlatego obok pokrycia kodu należy umieścić pokrycie wymagań (każde kryterium akceptacji musi zostać spełnione przez co najmniej jeden test). Sztuczna inteligencja jest bardzo pomocna w tworzeniu mapowania testów wymagań (macierzy identyfikowalności).
Testowanie oparte na ryzyku: gdzie włożyć wysiłek?
Ryzyko = prawdopodobieństwo (szansa złamania) × uderzenie (szkoda w przypadku złamania). Dzięki sztucznej inteligencji możesz ocenić listę funkcji na tych dwóch osiach i utworzyć mapę cieplną. Wysokie prawdopodobieństwo × wysokie domeny (płatność, uwierzytelnianie, integralność danych) zasługują na najintensywniejsze testy; niskie × niskie obszary (rzadko używany ekran preferencji) wystarczy przetestowanie światła.
obszar
prawdopodobieństwo
Wpływ
Ryzyko
Gęstość testu
Przepływ płatności
średni
bardzo wysoki
wysoki
Głębokość + automatyzacja
uwierzytelnianie
średni
bardzo wysoki
wysoki
Głębokość + bezpieczeństwo
Wyszukiwanie produktów
wysoki
średni
Średnio-wysoki
Automatyzacja + odkrycie
Zdjęcie profilowe
niski
niski
niski
kontrola światła
Strona pomocy
niski
za nisko
za nisko
recenzja
Pułapka pogoni za zasięgiem
Uznanie procentu pokrycia za cel (np. zasada „zespół musi przekroczyć 90% pokrycia”) ma niebezpieczny efekt uboczny: programiści i testerzy skupiają się na zwiększaniu odsetka, a nie na zajmowaniu się rzeczywistym ryzykiem. Rezultatem jest często rozdęty zakres bez asercji i trywialnych testów — liczba wygląda ładnie, ale nie ma żadnej ochrony. Jest to zjawisko zepsucia kryterium, gdy samo staje się celem: „kiedy środek staje się celem, przestaje być dobrym środkiem”. Używaj zakresu jako narzędzia diagnostycznego, a nie karty raportów wydajności.
Zdrowszym podejściem jest kierunkowe odczytywanie zakresu: „Dlaczego pokrycie oddziałów w krytycznym module płatniczym utrzymuje się na poziomie 40%?” Pytanie brzmi: „czy ogólny zasięg wynosi 90%?” Jest to o wiele cenniejsze niż pytanie. Niech sztuczna inteligencja podzieli raport dotyczący zakresu według modułu i poziomu ryzyka; Zaznacz obszary wysokiego ryzyka przy niskim pokryciu. W ten sposób zakres staje się kompasem, który kieruje pracą, a nie ślepym procentem.
Uwaga: Hasło „100% zasięgu” jest pułapką. Testowanie jakiegoś kodu (prostych akcesorów, części generowanych automatycznie) ma niską wartość; wysiłek włożony w tę czynność jest kradziony regułom biznesowym wysokiego ryzyka. Celem jest przetestowanie każdego ważnego zachowania i ryzyka, a nie każdej linii.
Słaba zachęta/silna zachęta
Słabe: „Zwiększ zakres testów”.
Strong: „Biorąc pod uwagę tę listę kryteriów akceptacji i istniejące przypadki testowe. (1) Tabelaryczne, które kryteria akceptacji nie zostały spełnione przez żadne testy (luka w pokryciu wymagań). (2) Oceń każdą cechę w skali 1-5 na osi prawdopodobieństwa i wpływu; uszereguj według ryzyka = prawdopodobieństwo × wpływ. (3) W moim ograniczonym czasie zasugeruj, które 5 luk powinienem zamknąć w pierwszej kolejności, zaczynając od najwyższego ryzyka. Nie traktuj pokrycia linii kodu jako jedynego kryterium; nadaj priorytet ryzyku biznesowemu. Kryteria: [...] Testy: [...]”
Potężny monit; łączy zakres z ryzykiem biznesowym i priorytetowo traktuje ograniczoną siłę roboczą.
Cztery szablony do kopiowania
1) Luka w zakresie wymagań:
Biorąc pod uwagę następujące kryteria akceptacji i te przypadki testowe. Utwórz tabelę identyfikowalności: każde kryterium -> test(y), które je spełnia. Kryteria, które nie mają żadnych testów, nazywane są „LUKĄ W ZAKRESIE”, a testy, które nie łączą się z żadnymi kryteriami, nazywane są „KONIECZNYMI?” Ocena: Kryteria: [...] / Testy: [...]
2) Punktacja ryzyka:
Oceń tę listę cech/modułów w skali 1-5 na osi prawdopodobieństwa (prawdopodobieństwo złamania) i uderzenia (uszkodzenie w przypadku uszkodzenia). Ryzyko = prawdopodobieństwo × wpływ. Posortuj w tabeli i określ zalecany typ testowania (jednostka/API/UI/rozpoznanie/bezpieczeństwo) dla każdego obszaru wysokiego ryzyka. Lista: [...]
3) Interpretacja zakresu:
Przedstawiono następujący raport pokrycia (procent linii, oddział %). Powiedz mi tak:- Czego NIE dowodzą te liczby?- Jakie obszary mogą być zagrożone pomimo dużego pokrycia wierszy?- Jakie dodatkowe badania polecilibyście w przypadku luk, których pokrycie nie dostrzega (wymagania, kombinacja danych, bezpieczeństwo)?Raport: [wklej]
4) Plan ograniczony czasowo:
Pozostało [X godzin] do transmisji. Podano następujący ranking ryzyka i luki w pokryciu. W tym okresie przygotowywany jest plan testów, który zmniejszy maksymalne ryzyko, w kolejności priorytetów. Jasno określ, czego NIE należy świadomie testować i jakie ryzyko się z tym wiąże.Dane: [...]
trzy mini etui
Przypadek 1 — 100% pokrycia, zero zaufania. Jeden zespół mógł pochwalić się 94% pokryciem linii. Analiza „interpretacji zakresu” wykazała, że większość testów nie zawierała twierdzeń, co oznacza, że przeprowadzały testy, ale niczego nie weryfikowały. Rzeczywisty zasięg ochronny był znacznie niższy. Zespół skupił się nie na liczbach, ale na testowaniu mutacji (część 10); rzeczywisty współczynnik wychwytywania błędów podwoił się.
Przypadek 2 – Priorytet skorygowany na podstawie mapy ryzyka. Jeden z zespołów poświęcił 40% czasu na testowanie rzadko używanego ekranu raportowania, pomijając przepływ płatności, ponieważ „po prostu działa”. Ocena ryzyka AI wykazała tę nierównowagę. Praca została rozdzielona; Dwa tygodnie później w przepływie płatności wykryto poważny błąd, który został zamknięty przed publikacją.
Przypadek 3 — Świadomość poza zakresem. Po 4 godzinach od wydania zespół zdecydował, co przetestować, a co świadomie pominąć, korzystając z szablonu „ograniczonego harmonogramu”. Głęboko przetestowano dwa strumienie wysokiego ryzyka; ekran preferencji niskiego ryzyka został udokumentowany jako „akceptowane ryzyko” i pominięty. Decyzja była przejrzysta i uzasadniona; Wersja wyszła bezpiecznie.
Typowe błędy
- Mylenie procentu pokrycia z jakością. Odczytywanie pokrycia wysokich wierszy jako „przetestowanego” zapewnienia.
- Patrzę tylko na pokrycie kodu. Pomijanie pokrycia wymagań (testowanie każdego kryterium akceptacji).
- Równe testowanie bez uwzględnienia ryzyka. Alokacja siły roboczej do obszarów niskiego ryzyka i zaniedbywanie przepływów krytycznych.
- Ukrywanie się poza zasięgiem. Brak dokumentowania tego, co nie zostało przetestowane, gdy nie było wystarczająco dużo czasu; Niespodzianki po premierze.
- Akceptowanie oceny ryzyka AI bez zastrzeżeń. AI nie zna w pełni kontekstu produktu; Dostosuj wyniki okiem eksperta.
Podsumowując
Pokrycie testami i testowanie oparte na ryzyku to dwa narzędzia umożliwiające skierowanie ograniczonych wysiłków we właściwe miejsce. Metryki pokrycia (linia, gałąź, stan, ścieżka) pokazują, czego dotknięto, ale nie dowodzą, że zachowało się prawidłowo; Zakres jest mapą, zaufanie nie. Umieść pokrycie wymagań obok pokrycia kodu. Oceń cechy za pomocą wzoru ryzyko = prawdopodobieństwo × wpływ i skieruj wysiłek na największe ryzyko. Sztuczna inteligencja uwidacznia luki, ocenia ryzyko, planuje ograniczony czas; ale ostateczny priorytet i decyzja o „świadomej rezygnacji” należy do eksperta, który zna kontekst biznesowy.
Zadanie aplikacji
Wybierz moduł z własnego projektu. Uruchom szablon „luki w zakresie wymagań” z AI i dowiedz się, które kryteria akceptacji nie są testowane. Następnie oceń podfunkcje modułu na osi prawdopodobieństwa × wpływu za pomocą „punktacji ryzyka”. Rozdaj (hipotetyczne) 3 godziny czasu testowania, jakie posiadasz w ramach „ograniczonego harmonogramu”; Zapisz, czego świadomie nie będziesz testować i jakie jest akceptowane ryzyko. Dodaj konkretny test, który zamknie lukę w pokryciu największego ryzyka, jaką znajdziesz.
lista kontrolna
- [ ] Odczytuję procent pokrycia jako mapę, a nie jakość.
- [ ] Oprócz pokrycia kodu usunąłem także pokrycie wymagań.
- [ ] Oceniłem cechy według prawdopodobieństwa × wpływu i uszeregowałem je według ryzyka.
- [ ] Przekierowałem wysiłek testowy na najwyższe ryzyko.
- [ ] Udokumentowałem obszary, które nie były świadomie testowane i uznawałem ryzyko.
- [ ] Sprawdziłem ocenę ryzyka AI w oparciu o kontekst mojego produktu.