Aplikacje AI
Testowanie aplikacji AI: co się psuje i jak to testować.
Aplikacja LLM zawodzi inaczej niż zwykła aplikacja webowa. Model za każdym razem zwraca coś innego, więc nie da się robić asercji na odpowiedzi — sprawdzasz wszystko wokół niej: że odpowiedź przychodzi, jest strumieniowana, się kończy, widocznie zawodzi, respektuje limit i nigdy nie zwraca danych, których dana osoba nie może zobaczyć.
Ostatnia aktualizacja: 24 sierpnia 2026
Czym testowanie aplikacji AI różni się od zwykłego?
Interfejs jest ten sam. Kontrakt nie. Tradycyjna automatyzacja testów opiera się na asercji, która sprawdza się dwa razy z rzędu — kliknij to, zobacz tamto. Model łamie to założenie już przy pierwszym uruchomieniu, dlatego zespoły często uznają, że funkcji AI nie da się testować regresyjnie, i wypuszczają je bez testów.
Da się. Sztuka polega na przeniesieniu asercji z treści na elementy deterministyczne: odpowiedź przyszła w budżecie czasu, została sparsowana do żądanego schematu, powołała się na dokument, który ten użytkownik może czytać, odmowa wyświetliła się jako odmowa, ponowna próba nie obciążyła dwa razy. To wszystko zwykła automatyzacja. Ocena, czy odpowiedź jest dobra, to problem ewaluacji — wymaga własnego wzorca prawdy i należy do narzędzia obok Twoich promptów, a nie do zestawu testów regresji.
Co naprawdę się psuje w aplikacji LLM
To zachowania, a nie opinie o jakości odpowiedzi, i właśnie dlatego da się je testować. Każde z nich dociera do użytkowników jako błąd produktu, a nie jako zła odpowiedź.
| Awaria | Jak dociera do użytkownika | Test |
|---|---|---|
| Odpowiedź jest strumieniowana, po czym urywa się w połowie | Zerwane połączenie w trakcie strumienia zostawia na ekranie niedokończoną odpowiedź, bez błędu i bez ponowienia. Użytkownicy biorą ją za pełną odpowiedź. | Przerwij odpowiedź w połowie strumienia i sprawdź, że interfejs pokazuje stan błędu, a nie ucięty tekst. |
| Model jest wolny, a interfejs nie ma na to rozwiązania | P95 na poziomie czterdziestu sekund, a interfejs nie pokazuje postępu, nie pozwala anulować i nie ma limitu czasu. Ludzie klikają ponownie i teraz rozliczane są dwa żądania. | Przetrzymaj odpowiedź ponad limit czasu i sprawdź, że widoczny jest stan oczekiwania, jest możliwość anulowania, a drugie kliknięcie nie wysyła duplikatu żądania. |
| Dostawca zwraca 429 lub 503 | Limity zapytań i awarie dostawców to codzienność, a nie wyjątek. Aplikacje, które uznają je za niemożliwe, pokazują surowy błąd albo niekończące się kółko ładowania. | Zwróć z dostawcy 429 i 503 i sprawdź, że aplikacja wyświetla komunikat, na który użytkownik może zareagować. |
| Puste odpowiedzi, odmowy i odpowiedzi zablokowane filtrem bezpieczeństwa | Model odmawia albo włącza się filtr bezpieczeństwa, a interfejs wyświetla pustą dymkę, bo obsługuje tylko szczęśliwą ścieżkę. | Wymuś odmowę i puste zakończenie; sprawdź, że żadne z nich nie daje pustej wiadomości ani rozjechanego układu. |
| Rozmowa traci kontekst | Historia jest przycinana, by zmieścić się w oknie, a asystent po cichu zapomina, co mu powiedziano trzy wiadomości wcześniej. Wygląda to tak, jakby produkt był głupi. | Prowadź rozmowę poza limit kontekstu i sprawdź, że aplikacja informuje, co pominęła, zamiast robić to po cichu. |
| Wywołania narzędzi uruchamiają się więcej niż raz | Agent ponawia krok, którego narzędzie już się wykonało. Cokolwiek ono zrobiło — e-mail, obciążenie, zapis — dzieje się dwa razy. | Spraw, by wywołanie narzędzia przekroczyło czas już po sukcesie, i sprawdź, że ponowienie nie powtarza skutku ubocznego. |
| Wyszukiwanie zwraca dokument innego klienta | Magazyn wektorowy jest filtrowany w prompcie, a nie w zapytaniu, więc wyszukiwanie, które zignoruje instrukcję, zwraca dane, do których użytkownik nie ma prawa. | Wyszukaj jako jeden klient dokument należący do innego i sprawdź, że nie ma go w zwróconym zestawie, a nie tylko że nie wspomniano o nim w odpowiedzi. |
| Koszty rosną bez żadnego limitu | Brak limitu na użytkownika, więc jedna pętla albo jedno skryptowane konto zamienia się w rachunek, którego nikt nie zauważa do czasu faktury. | Wywołuj wielokrotnie ten sam endpoint i sprawdź, że istnieje limit — na użytkownika, na klucz, na minutę. |
Bezpieczeństwo
Testy bezpieczeństwa LLM: powierzchnia warta sprawdzenia
Funkcja AI zwykle jest podłączona do dwóch rzeczy, których nie ma zwykła funkcja: płatnego endpointu i komponentu wykonującego instrukcje znalezione w tym, co czyta. Oba poszerzają powierzchnię ataku w sposób, do którego standardowy przegląd bezpieczeństwa aplikacji nie był pisany.
Poniżej w kolejności, w jakiej faktycznie się je znajduje — a ta nie jest kolejnością, w jakiej się o nich pisze.
- 01
Klucze dostawcy w paczce klienta
Klucz dostawcy modelu umieszczony w JavaScripcie front-endu albo dostępny przez trasę proxy bez żadnego uwierzytelniania.
Każdy z narzędziami deweloperskimi może zużyć Twój limit. To najtańsza kontrola z tej listy i najdroższa do pominięcia.
- 02
Prompt injection przez treść
Instrukcje ukryte w czymś, co model czyta — przesłanym dokumencie, pobranej stronie, zgłoszeniu do supportu, treści e-maila — które model następnie wykonuje.
Atakujący nigdy nie dotyka Twojego pola wprowadzania. Wszystko, co system przyjmuje, jest wejściem, niezależnie od tego, czy tak je zaprojektowano.
- 03
Injection, które dociera do narzędzia
Wstrzyknięte instrukcje, przez które agent wywołuje narzędzie: wysyła wiadomość, zapisuje rekord, wysyła żądanie na adres wewnętrzny.
Tu injection przestaje być wpadką, a staje się incydentem. Zasięg szkód to wszystko, co agent może zrobić.
- 04
Ujawnienie promptu systemowego i sekretów
Nakłonienie modelu do powtórzenia własnych instrukcji, definicji narzędzi albo fragmentów konfiguracji, które otrzymał.
Prompt systemowy często zawiera reguły biznesowe, wewnętrzne endpointy, a czasem dane uwierzytelniające, których nikt tam nie chciał umieszczać.
- 05
Wyszukiwanie między klientami
Wyszukiwanie ograniczane prośbą skierowaną do modelu, a nie filtrem w zapytaniu.
Prompt nie jest kontrolą dostępu. Jeśli filtr jest w instrukcjach, jedna zignorowana instrukcja oznacza wyciek danych.
- 06
Wynik renderowany jako znaczniki lub kod
Wynik modelu wstawiany do strony jako HTML albo do powłoki, zapytania czy eval.
Klasyczny injection z nowym źródłem. Model jest teraz niezaufanym wejściem, na które atakujący może wpływać.
- 07
Nieograniczone wydatki jako atak DoS
Endpoint wywołujący płatny model bez limitu zapytań, bez limitu na konto i bez limitu rozmiaru przyjmowanych danych.
Celem ataku nie jest wyłączenie Cię. Chodzi o to, by nabijać rachunek, aż sam się wyłączysz.
- 08
Co zachowują logi
Prompty i odpowiedzi zapisywane w logach i analityce — razem z tym, co użytkownik w nich wkleił.
Ludzie wklejają do okien czatu produkcyjne dane dostępowe i dane klientów. Retencja logów staje się więc kwestią ochrony danych.
Co QA Spider automatyzuje, a czego nie
Sformułowane na tyle wąsko, byś mógł nas z tego rozliczyć.
Automatyzujemy
- Obsługuje Twój produkt w prawdziwej przeglądarce, więc przypadki strumieniowania, limitu czasu, ponowień, pustych stanów i stanów błędu opisane wyżej są zwykłymi testami UI — uruchamiane według harmonogramu i przy każdym wdrożeniu.
- Sprawdza API pod interfejsem, w tym trasy, które front-end wywołuje, by dotrzeć do modelu.
- Zgłasza to, co zawodzi, jako zadanie w Jira, Azure DevOps, ClickUp, GitHub lub Linear — z krokami odtworzenia i zrzutem ekranu.
- Wykonuje powierzchowny przegląd bezpieczeństwa publicznej strony: transport i nagłówki bezpieczeństwa, flagi ciasteczek, mieszana zawartość, ekspozycja formularzy, DNS i ochrona przed podszywaniem się pod e-mail.
Nie robimy
- Obecnie nie oferujemy automatycznego zestawu testów prompt injection ani jailbreak. Jeśli ktoś mówi, że jego crawler robi to od ręki, poproś o pokazanie asercji.
- Nie oceniamy, czy odpowiedź jest poprawna. To zagadnienie ewaluacji, wymaga Twoich wzorcowych danych i jest inną dyscypliną niż testy regresji.
Pytania o testowanie aplikacji AI
- Czym testowanie aplikacji AI różni się od testowania zwykłej aplikacji webowej?
- Interfejs jest taki sam, wynik nie. Zwykła aplikacja zwraca dwa razy tę samą odpowiedź, więc można ją sprawdzić asercją. Model za każdym razem zwraca coś innego, więc asercje przenoszą się na kształt i zachowanie wokół odpowiedzi — że nadeszła, że jest strumieniowana, że się urywa, że widocznie zawodzi i że kosztuje tyle, ile powinna.
- Jak napisać asercję, gdy wynik za każdym razem się zmienia?
- Sprawdzaj kontrakt, a nie treść. Że odpowiedź przyszła w budżecie czasu, że sparsowała się do żądanego schematu, że powołuje się na dokument, który użytkownik może zobaczyć, że odmowa wyświetla się jako odmowa. Ocena sformułowań to ewaluacja, prowadzona osobno od zestawu regresji.
- Czym jest prompt injection i jak go testować?
- To instrukcje ukryte w treści, którą czyta system — dokumencie, stronie, zgłoszeniu — i które model następnie wykonuje. Testuje się go, umieszczając instrukcje w każdym kanale docierającym do modelu i sprawdzając, że efekt nigdy nie następuje: żadne narzędzie nie zostaje wywołane, żadne dane nie wracają, prompt systemowy nie jest powtórzony.
- Jaki jest najczęstszy problem bezpieczeństwa w produktach AI?
- Mało efektowne. Klucz dostawcy osiągalny z przeglądarki, endpoint modelu bez limitu zapytań i wyszukiwanie ograniczane instrukcją w prompcie zamiast filtrem w zapytaniu. Wszystkie trzy łatwiej znaleźć niż wymyślny jailbreak i częściej występują.
- Czy QA Spider może testować mój produkt AI?
- Zachowanie wokół modelu — tak: strumieniowanie, limity czasu, ponowienia, odmowy, stany błędów, limity zapytań i API pod interfejsem, testowane w prawdziwej przeglądarce przy każdym wdrożeniu. Automatycznych zestawów prompt injection dziś nie oferujemy i wolimy to powiedzieć, niż żebyś dowiedział się później.
- Czy sprawdzacie, czy model odpowiada poprawnie?
- Nie. Poprawność wymaga Twoich wzorcowych danych i należy do środowiska ewaluacji, które prowadzisz i wersjonujesz razem z promptami. Testy regresji odpowiadają na inne pytanie: czy to, co działało wczoraj, nadal działa po dzisiejszym wdrożeniu.
Skieruj go na swój produkt AI.
Zachowanie wokół modelu — strumieniowanie, limity czasu, ponowne próby, odmowy, limity zapytań i API pod interfejsem — testowane w prawdziwej przeglądarce przy każdym wdrożeniu.