Zyski:
- Umiejętność zaprojektowania roli sztucznej inteligencji i punktów akceptacji człowieka w kompleksowym przepływie kontroli jakości od pomysłu do wydania w kontekście CI/CD
- W CI/CD nie zezwalanie sztucznej inteligencji na automatyczne „zdanie” testu, ale stosowanie limitów w celu ochrony poufnych danych i kluczy
- Umiejętność przeprowadzania testów bezpieczeństwa w ramach władzy i w celach obronnych oraz przyjmowania zasad odpowiedzialnego ujawniania informacji i przejrzystości etycznej.
W poprzednich dziesięciu jednostkach wykorzystywaliśmy sztuczną inteligencję w poszczególnych zadaniach: generowaniu scenariuszy, kodzie automatyzacji, raportowaniu błędów, analizie zasięgu, testowaniu mutacji. Ta ostatnia jednostka łączy je wszystkie w jeden odpowiedzialny przepływ pracy. Współczesna kontrola jakości nie jest pracą, która kończy się przy biurku jednej osoby; Jest to proces funkcjonujący w ramach CI/CD (Continious Integration / Continuous Delivery — potok, w którym kod jest stale łączony, automatycznie testowany i przygotowywany do częstej i bezpiecznej publikacji). Sztuczna inteligencja może dotknąć każdego etapu tego procesu. Jednak wraz ze wzrostem mocy sztucznej inteligencji rośnie znaczenie odpowiedzialnego korzystania z niej: prywatność, uprawnienia w testowaniu bezpieczeństwa, etyka i, co najważniejsze, pozostawienie decyzji dotyczącej jakości w gestii człowieka. W tej jednostce nauczysz się kompleksowego przepływu i granic.
Kompleksowy przepływ kontroli jakości oparty na sztucznej inteligencji
Rola sztucznej inteligencji w podróży funkcji od pomysłu do wydania:
1. Analiza wymagań. AI sygnalizuje niejasności w wymaganiach i brakujących kryteriach akceptacji („ta zasada nie określa, ile znaków musi mieć minimalne hasło”).
2. Projekt testu. Wśród kryteriów akceptacji znajdują się projekty scenariuszy i przypadków (część 2), przypadki brzegowe (część 3).
3. Automatyzacja. Jednostki (6), API (5) i UI (4) wersje robocze kodu testowego; każdy jest potwierdzony przez mutację ( 10 ).
4. Integracja CI/CD. Testy uruchamiają się automatycznie przy każdym łączeniu kodu. AI tworzy wersję roboczą konfiguracji potoku (YAML), podsumowuje logi nieudanych testów, sugeruje możliwą pierwotną przyczynę.
5. Decyzja o zwolnieniu. Zbierane są wyniki analizy ryzyka (8) i regresji (9), ale ekspert decyduje, czy może się to powieść.
6. Monitorowanie produkcji i informacja zwrotna. Błędy na żywo stają się przyszłymi testami; AI proponuje przypadek regresji z wady produkcyjnej.
Wskazówka: skonfiguruj sztuczną inteligencję jako warstwę w CI/CD, która „przyspiesza sprawdzanie wersji roboczych przez człowieka”, a nie „pisze testy i podejmuje decyzje”. Żadne automatycznie wygenerowane testy nie powinny być wprowadzane do rurociągu bez ich sprawdzenia i zatwierdzenia przez człowieka.
AI w CI/CD: gdzie tak, gdzie nie
Scena
Pasuje do AI
człowiek jest niezbędny
Wersja robocza kodu testowego
Tak
Rewizja + mutacja
Projekt rurociągu YAML
Tak
Uwierzytelnianie + sprawdzanie tajnego klucza
Nieudane podsumowanie dziennika
Tak
Potwierdzenie pierwotnej przyczyny
Diagnoza testu kruchego
Tak
Decyzja o rozwiązaniu trwałym
„Czy istnieje wersja?”
nie
Ekspercka ocena i odpowiedzialność
Automatycznie „zdaj” test
nigdy
—
Uwaga: nigdy nie dawaj AI poleceń typu „napraw to, aby przejść test negatywny” w CI/CD. To mija się z celem testowania i automatycznie zakrywa błędy. AI może wyjaśnić błąd, zasugerować korektę; ale „pomalowanie testu na zielono” musi być świadomą i przemyślaną decyzją danej osoby.
Prywatność, dane i bezpieczeństwo: niezmienne granice
Prywatność. W środowisku testowym wrażliwe są rzeczywiste dane klientów, kopie produkcyjnej bazy danych, klucze API i informacje o systemie wewnętrznym. Nie udostępniaj ich publicznym narzędziom AI. Dane osobowe podlegają przepisom KVKK i podobnym przepisom; Maskuj logi i zrzuty ekranu. Jeśli to możliwe, używaj syntetycznych (fikcyjnych) danych testowych.
Testowanie bezpieczeństwa — defensywne i autoryzowane. Testy bezpieczeństwa poznane w tym module (testy autoryzacyjne/IDOR, limity przesyłania plików, walidacja danych wejściowych) służą wyłącznie do testowania własnego produktu w ramach pisemnego upoważnienia i określonego zakresu. Używanie sztucznej inteligencji do uzyskiwania dostępu do cudzego systemu bez pozwolenia, wykorzystywania prawdziwych luk w zabezpieczeniach lub przeprowadzania testów wykraczających poza zakres jest zarówno nieetyczne, jak i nielegalne. Kiedy znajdziesz lukę w zabezpieczeniach, postępuj zgodnie z zasadą odpowiedzialnego ujawniania – zachowaj lukę w tajemnicy i zgłoś ją odpowiedniej stronie, aby mogła zostać naprawiona.
Etyka i przejrzystość. Nie przedstawiaj testów opracowanych przez sztuczną inteligencję jako własnej pracy; Stwierdzenie, że korzystasz ze sztucznej inteligencji w zespole, oznacza przejrzystość. Jesteś odpowiedzialny za niedokładność wyników wytworzonych przez sztuczną inteligencję – „AI to napisała” nie jest wymówką.
Słaba zachęta/silna zachęta
Słabe: „Skonfiguruj potok testowy dla CI.”
Mocne: „Narysuj YAML przepływu pracy CI dla akcji GitHub: uruchom testy jednostkowe i API dla każdego PR, wygeneruj raport pokrycia, co tydzień przeprowadzaj testy mutacji (Stryker). Nie osadzaj kluczy tajnych w kodzie; używaj tylko odniesienia do sekretów. Blokuj scalanie, jeśli testy są czerwone. To jest wersja robocza; przejrzę i edytuję kroki zarządzania kluczami tajnymi i ich walidacji. NIE DODAWAJ kroku „napraw” lub „migracji” automatycznego testowania.
Potężny monit; Nakłada ograniczenia na poufność, weryfikację ludzką i „zakaz testów automatycznych”.
Cztery szablony do kopiowania
1) Kompleksowy plan testów:
Twoja rola: starszy lider ds. kontroli jakości. Przygotuj kompleksowy plan testów od pomysłu do wydania dla następującej funkcjonalności: [funkcja + kryteria akceptacji]. Fazy: analiza wymagań (niepewności), projekt testów, warstwy automatyzacji (jednostka/API/UI), integracja CI/CD, kryteria decyzji o wydaniu, śledzenie produkcji. Określ rolę punktów akceptacji AI i CZŁOWIEKA na każdym etapie oddzielnie.
2) Zarys rurociągu CI/CD:
Wersja robocza CI YAML dla [GitHub Actions/GitLab CI/Azure Pipelines]:- Test jednostkowy + API + zakres w PR- Zapobieganie łączeniu w teście czerwonym- Wartości tajne tylko z sekretami; osadzanie w kodzieTo jest wersja robocza; Przeanalizuję kluczowe etapy zarządzania i zatwierdzania. Dodanie kroku testu autokorekty/pozytywnego.
3) Nieudana analiza dziennika testów:
Na tym wydruku CI testy są czerwone. Sprawdź dziennik; pogrupuj awarie, rozróżnij możliwą pierwotną przyczynę i KTÓRA może być prawdziwą awarią, a która może być delikatnym problemem związanym z testem/środowiskiem. Jeśli istnieją dane osobowe, zamaskuj je. Decyzja i poprawki będą moje. Log: [wklej]
4) Wstępna kontrola bezpieczeństwa/prywatności:
Zanim te dane/dziennik testowy zostaną przesłane do narzędzia AI, sprawdź: czy zawierają dane osobowe, klucz API, wewnętrzny adres systemu, dane produkcyjne? Wypisz, które obszary, jeśli w ogóle, należy zamaskować/usunąć. Przetwarzanie takie jakie jest. Treść: [wklej]
trzy mini etui
Przypadek 1 — Szybkość przepływu od końca do końca. Jeden z zespołów zajął się nową funkcją „odnawiania subskrypcji” w ramach kompleksowego przepływu opartego na sztucznej inteligencji: od razu zaznaczono niepewność wymagań, opracowano trójwarstwowe testy i zweryfikowano je pod kątem mutacji, powiązano z CI. Ta funkcja skróciła cykl testowania, który w tradycyjnym procesie trwał 5 dni, do 2 dni; ale ludzka akceptacja została zachowana na każdym etapie, a niepewność wymagań (co się stanie, jeśli odświeżenie się nie powiedzie) została zamknięta przed publikacją.
Przypadek 2 — Powrót po wycieku klucza. Deweloper zlecił AI wygenerowanie CI YAML, a sztuczna inteligencja umieściła na przykład realnie wyglądający klucz API w YAML. Ujęto to na etapie „wstępnej kontroli bezpieczeństwa/prywatności”. klucz przekonwertowany na odwołanie do sekretów. Bez etapu audytu klucz wyciekłby do kontroli wersji (historia git).
Przypadek 3 – Granica uprawnień. Członek zespołu chciał zastosować poznany test IDOR w działającym systemie partnera biznesowego, powołując się na „Byłem ciekawy”. Lider ds. kontroli jakości zatrzymał się: przeprowadzanie testów bezpieczeństwa w innym systemie bez pisemnej autoryzacji i określonego zakresu jest nielegalne. Testowanie przeprowadzono wyłącznie w środowisku testowym własnych produktów, za zgodą; Osoba odpowiedzialna za otwarcie została powiadomiona odpowiedni zespół.
Typowe błędy
- Sprawianie, że sztuczna inteligencja podejmuje decyzje o wydaniu. Zadając pytanie „Czy można to wypuścić?” do AI i umieszczenie odpowiedzi w miejscu podpisu.
- „Zaliczenie” testu automatycznego. W CI, AI maluje test na zielono; ukrywanie błędów.
- Przekazanie poufnych danych/kluczy do pojazdu. Udostępnianie danych produkcyjnych, danych osobowych lub kluczy API bez nadzoru.
- Nieautoryzowane testy bezpieczeństwa. Osoba atakująca testuje na innym systemie bez zakresu i pozwolenia.
- Wprowadzanie testów do rurociągu bez przeglądu. Automatycznie uruchamiaj szkic AI bez zgody człowieka.
- Zrzucanie winy na AI. Bronić nieprawidłowego wyniku, mówiąc „AI to napisała”.
Podsumowując
Kompleksowa kontrola jakości to proces rozciągający się od wymagań po śledzenie produkcji i realizowany w ramach CI/CD; Na każdym etapie sztuczna inteligencja tworzy wersje robocze, podsumowuje dziennik i sugeruje pierwotne przyczyny. Ale granice są niezmienne: ludzie podejmują decyzje dotyczące testów i wydają zgodę; Sztuczna inteligencja nigdy nie ma uprawnień do automatycznego „zdania” testu; poufne dane i klucze nie dostały się do pojazdu; Testy bezpieczeństwa przeprowadzane są wyłącznie na Twoim własnym produkcie, w ramach pisemnego upoważnienia i określonego zakresu, w celach obronnych, a ustalenia są zgłaszane z odpowiedzialnym ujawnieniem. Zachowaj przejrzystość, gdy korzystasz ze sztucznej inteligencji; Jesteś odpowiedzialny za dokładność wyników. AI przyspiesza; Gwarantujesz jakość i etykę.
Zadanie aplikacji
Przygotuj plan od pomysłu do wydania, korzystając z szablonu „kompleksowego planu testów” dla funkcji z własnego projektu; Na każdym etapie zaznacz oddzielnie rolę AI i punktów akceptacji człowieka. Następnie wygeneruj YAML z „zarysem potoku CI/CD” i zastosuj „wstępną kontrolę bezpieczeństwa/prywatności” do tego YAML, aby sprawdzić, czy są osadzone dane klucza/tajne. Na koniec wypisz wszystkie punkty „decyzji ludzkiej” w swoim planie i uzasadnij w jednym zdaniu, dlaczego tych decyzji nie można przekazać AI.
lista kontrolna
- [ ] Decyzje o wydaniu i testowaniu przypisuję aprobacie człowieka; Nie przekazałem tego AI.
- [ ] W CI/CD nie dałem AI pozwolenia na automatyczne „zaliczenie/poprawienie” testu.
- [ ] Sprawdziłem i zamaskowałem poufne dane, dane osobowe oraz klucze przed wysłaniem ich do pojazdu.
- [ ] Brałem pod uwagę jedynie testy bezpieczeństwa na moim własnym produkcie, w ramach pisemnego upoważnienia i zakresu.
- [ ] Zająłem się wykrytymi lukami w zasadzie odpowiedzialnego ujawniania informacji.
- [ ] Wyraźnie oświadczyłem, że korzystam ze sztucznej inteligencji i ponoszę odpowiedzialność za dokładność wyników.
Egzamin modułowy
1. Jak najdokładniej definiuje się „fałszywe podanie” w kontekście kontroli jakości?
- A) Chociaż test zmienia kolor na zielony, w rzeczywistości nie potwierdza żadnego zachowania; ✔ Nie zmienia koloru na czerwony, nawet jeśli kod jest uszkodzony
- B) Test przebiega bardzo wolno i przekracza limit czasu.
- C) Test wykrywa prawdziwy błąd i zmienia kolor na czerwony
- D) Test działa tylko w środowisku produkcyjnym
Objaśnienie: Pseudozaliczenie ma miejsce wtedy, gdy test mówi „zaliczony”, ale w rzeczywistości nie potwierdza niczego znaczącego; Test jest zielony, ale nawet jeśli oprogramowanie jest wadliwe, nie wykryje go. Jest to ryzyko numer jeden związane ze sztuczną inteligencją w zapewnianiu jakości, ponieważ sztuczna inteligencja ma tendencję do tworzenia testów, które wyglądają schludnie, ale są puste.
2. Jakie jest najdokładniejsze umiejscowienie sztucznej inteligencji w procesie testowania i kontroli jakości?
- A) Sztuczna inteligencja może zdecydować, czy wersja może zostać opublikowana bez zgody człowieka
- B) Sztuczna inteligencja to asystent, który generuje szkice i pomysły; Decyzja i odpowiedzialność „czy jest gotowy do publikacji” należy do eksperta ✔
- C) Sztuczna inteligencja pisze tylko tekst i w ogóle nie radzi sobie z kodem testowym
- D) Sztuczna inteligencja zawsze pisze poprawny test niż człowiek, więc sprawdzanie nie jest konieczne
Opis: Sztuczna inteligencja to asystent testowania, generator szkiców i mnożnik pomysłów; tworzy scenariusze testowe, kod automatyzacji i wersje robocze raportów. Jednakże odpowiedzialność i ostateczne zatwierdzenie decyzji dotyczących jakości, takich jak „czy to oprogramowanie jest gotowe do publikacji” lub „czy ten test przeszedł pomyślnie”, należy do kompetentnego eksperta.
3. Biorąc pod uwagę fakt, że błędy występują najczęściej przy wartościach progowych, która technika projektowania testów polega na osobnym testowaniu 17, 18 i 19 lat dla granicy wieku 18 lat?
- A) Test przejścia stanu
- B) Tabela decyzyjna
- C) Analiza wartości brzegowych ✔
- D) Testowanie eksploracyjne
Wyjaśnienie: Analiza wartości granicznych opiera się na obserwacji, że błędy występują najczęściej na granicach i bada oddzielnie wartości progowe (tuż poniżej, tuż powyżej i tuż powyżej granicy). Jest to potężna technika, która uzupełnia klasy równoważności.
4. Które podejście powinno być preferowane przy wyborze elementów, aby zmniejszyć kruchość kodu automatyzacji testów interfejsu użytkownika utworzonego za pomocą sztucznej inteligencji?
- A) Używanie najdłuższej możliwej ścieżki XPath
- B) Wybór elementu zgodnie z jego położeniem w pikselach na ekranie
- C) Używanie selektorów opartych na nazwach klas CSS
- D) Korzystanie ze stabilnych atrybutów (data-testid) dodanych do testów ✔
Objaśnienie: Długie ścieżki XPath i nazwy klas CSS są w ogromnym stopniu zależne od struktury i projektu strony; Psuje się przy najmniejszej zmianie interfejsu. Zmiany w projekcie nie mają wpływu na stabilne atrybuty dodane specjalnie na potrzeby testowania (np. data-testid), dzięki czemu testy są niezawodne.
5. Dlaczego w teście API nie wystarczy sprawdzenie kodu statusu HTTP (np. 200)?
- A) Ponieważ dane treści z prawidłowym kodem statusu mogą być uszkodzone i samo sprawdzenie statusu tego nie wykryje (pseudo-zaufanie) ✔
- B) Ponieważ kody stanu nie są w ogóle wiarygodne w testach API
- C) Ponieważ sprawdzanie kodu statusu znacznie spowalnia test
- D) Ponieważ kod statusu nigdy nie jest zwracany w testach API
Objaśnienie: Chociaż serwer zwraca poprawny kod statusu, może zwrócić uszkodzone dane w treści (zły typ, brakujące pole, niepoprawnie obliczona wartość). Test, który patrzy tylko na sytuację, nie jest w stanie tego zobaczyć i daje fałszywą pewność. Należy zatem dodać również walidację schematu/umowy i reguły biznesowej.
6. Dlaczego tak ważne jest, aby podczas drukowania testów jednostkowych powiedzieć AI, aby „ręcznie obliczyła oczekiwaną wartość zgodnie z zasadą akceptacji, nie odwoływała się do bieżącego wyjścia funkcji”?
- A) Ponieważ obliczenia ręczne przyspieszają testy
- B) Ponieważ w przeciwnym razie test uzna obecne (być może błędne) zachowanie kodu za „poprawne” i potwierdzi błąd ✔
- C) Ponieważ sztuczna inteligencja w ogóle nie potrafi obliczać liczb dziesiętnych
- D) Ponieważ reguły akceptacji nigdy nie są używane w testach
Objaśnienie: Jeśli sztuczna inteligencja uzyska oczekiwaną wartość z wyniku testowanej funkcji, sprawi, że test będzie „zaliczony”, nawet jeśli funkcja jest wadliwa; Oznacza to, że niezależnie od kodu, test liczy się jako prawdziwy. Obliczanie oczekiwanej wartości niezależnie od reguły akceptacji gwarantuje, że test jest strażnikiem reguły, a nie odzwierciedleniem kodu.
7. Która z poniższych cech najbardziej wyróżnia dobry raport o błędzie?
- A) Aby był możliwie długi i techniczny
- B) Napisane przez sztuczną inteligencję
- C) Zawiera deterministyczne kroki odtwarzania, które programista może wykonać niezależnie i spowodować błąd ✔
- D) To tylko zrzut ekranu
Wyjaśnienie: Prawdziwą wartością raportu o błędzie jest to, że programista może odtworzyć błąd bez Twojej pomocy. Zapewniają to deterministyczne, identyfikowalne etapy odtwarzania od zera; Jeśli brakuje tych kroków, raport często kończy się informacją „nie udało się wygenerować”.
8. Jakie jest najtrafniejsze określenie związku pomiędzy wagą a priorytetem w przypadku błędu w pisowni nazwy firmy na stronie głównej?
- A) Intensywność i priorytet powinny zawsze mieć tę samą wartość
- B) Zarówno waga, jak i priorytet tego błędu są zdecydowanie niskie
- C) Ważność i priorytet to to samo pojęcie, wystarczy jedna etykieta
- D) Intensywność techniczna może być niska, ale priorytet biznesowy (reputacja) może być wysoki; Obydwa są różnie oceniane ✔
Wyjaśnienie: Ważność to techniczny wpływ błędu (literówka jest technicznie niska), priorytetem jest to, jak pilnie należy go naprawić (wysoki, ponieważ jest to element reputacji, który widzi każdy odwiedzający). Jedno i drugie nie zawsze zmierza w tym samym kierunku; Ten przykład dotyczy sytuacji o niskim priorytecie i niskim priorytecie.
9. Która interpretacja zestawu testów z 90% pokryciem linii jest najdokładniejsza?
- A) Pokazuje, że linie są wykonane, ale nie dowodzi, że zachowują się poprawnie; ✔ wysoki zasięg może dawać fałszywą pewność
- B) Zdecydowanie dowodzi, że 90% oprogramowania jest wolne od błędów
- C) Jest to ostateczny miernik doskonałej jakości testu.
- D) Wskazuje, że nie ma już potrzeby pisania żadnych dodatkowych testów
Objaśnienie: Pokrycie wierszy wskazuje, że wykonano tylko wiersze; Nie dowodzi, że daje prawidłowe wyniki. Nawet przy bezsłownych testach można osiągnąć 90% pokrycia. Zakres to mapa, na której nigdy nie szukano, gdzie, a nie gwarancja, że „wszystko zostało przetestowane”; rzeczywistą ochronę mierzy się za pomocą testów mutacji.
10. W jaki sposób w testowaniu opartym na ryzyku oblicza się ryzyko funkcji, aby ukierunkować ograniczony wysiłek testowy?
- A) Tylko według liczby linii kodu
- B) Mnożąc prawdopodobieństwo awarii i efekt, jaki nastąpi, gdy się zepsuje ✔
- C) Tylko w kolejności, w jakiej funkcja została opracowana
- D) Nadanie priorytetu tylko tej funkcji, dla której najłatwiej jest napisać testy
Wyjaśnienie: W testowaniu opartym na ryzyku ryzyko ocenia się jako prawdopodobieństwo = prawdopodobieństwo (prawdopodobieństwo awarii) × wpływ (uszkodzenie w przypadku uszkodzenia). Domeny o wysokim prawdopodobieństwie i dużym wpływie (płatność, uwierzytelnianie) zasługują na najintensywniejsze testy, podczas gdy domeny o niskim × niskim poziomie są poddawane lekkim testom.
11. Jakie jest główne ryzyko dodania ponownej próby do testu, który czasami kończy się pomyślnie, a czasami kończy się niepowodzeniem (kruchy/łuszczący się), mimo że kod się nie zmienił?
- A) Skrócenie czasu trwania testu
- B) Zmniejsza procent pokrycia
- C) Zakrywanie prawdziwego błędu współbieżności lub pierwotnej przyczyny i tłumienie symptomu ✔
- D) Zmiana nazwy testu
Objaśnienie: Ponów próbę to narzędzie diagnostyczne, a nie leczenie. Niezdecydowanie często wynika z aktualnej sytuacji rasowej lub uzależnienia; Dokonanie „zaliczenia” testu przez ponowną próbę zakrywa ten prawdziwy błąd i może spowodować poważne problemy na żywo. Najpierw należy znaleźć przyczynę pierwotną.
12. Jak działa testowanie mutacji, najuczciwsza metoda pomiaru tego, czy zestaw testów faktycznie chroni?
- A) Poprzez pomiar prędkości jazdy w ramach testów
- B) Licząc, ile linii kodu zostało napisanych
- C) Uruchamiając testy w różnej kolejności
- D) Celowo tworząc małe przerwy w kodzie i mierząc, czy testy je wyłapią ✔
Opis: testowanie mutacji powoduje niewielkie, zamierzone zniekształcenia (mutacje) w kodzie źródłowym; Dobry zestaw testów powinien wychwycić te zniekształcenia i zmienić kolor na czerwony. Mutacje, które nie zostały wyłapane (przetrwały), wskazują, że testy nie zachowują tego zachowania. Wynik mutacji jest znacznie bardziej uczciwą miarą jakości niż procent pokrycia.
13. Jakie są główne ograniczenia, których należy przestrzegać podczas przeprowadzania testów bezpieczeństwa (np. testów autoryzacyjnych/IDOR)?
- A) Należy tego dokonać wyłącznie na własnym produkcie, w ramach pisemnego upoważnienia i w określonym zakresie, w celach obronnych ✔
- B) Można go swobodnie zastosować do dowolnego interesującego systemu
- C) Można go wypróbować na działających systemach partnerów biznesowych bez pozwolenia
- D) Wszelkie wykryte luki należy natychmiast opublikować publicznie.
Opis: Testy bezpieczeństwa poznane w tym module służą wyłącznie do testowania własnego produktu w celach obronnych, w ramach pisemnego upoważnienia i określonego zakresu. Uzyskiwanie dostępu do cudzego systemu bez pozwolenia lub przeprowadzanie testów wykraczających poza zakres jest zarówno nieetyczne, jak i nielegalne; Wszelkie znalezione luki są zgłaszane w drodze odpowiedzialnego ujawniania informacji.
14. Jakich uprawnień nigdy nie należy nadawać sztucznej inteligencji w procesie CI/CD?
- A) Podsumowanie dzienników nieudanych testów
- B) Uprawnienie do automatycznego „zdania” nieudanego (czerwonego) testu lub pomalowania go na zielono ✔
- C) Sugerowanie wersji roboczej kodu testowego
- D) Przygotowanie pliku YAML potoku
Opis: sztuczna inteligencja może wygenerować zarys kodu testowego, potok YAML i podsumowanie dziennika w CI/CD; jednakże nigdy nie należy zapewniać możliwości automatycznego „zaliczenia/naprawy” nieudanego testu. To mija się z celem testowania i automatycznie zakrywa błędy. Pomalowanie testu na zielono powinno być świadomą i przemyślaną decyzją danej osoby.