Testy SQL i code review z AI: dane testowe, test mutacyjny, SQL injection i lista 25 punktów

W skrócieAI pisze testy SQL z danymi testowymi i oczekiwanym wynikiem oraz robi przegląd kodu jak doświadczony DBA, ale testy trzeba sprawdzić celowo zepsutą funkcją. Pokazujemy 9 testów od AI, test mutacyjny, procedurę podatną na SQL injection, jej poprawioną wersję i listę kontrolną 25 punktów.

To część 7 z 8 przewodnika AI w SQL. Wszystkie przykłady powstały na bazie DemoShop w SQL Server 2022: fikcyjnym sklepie internetowym z 2,4 mln zamówień. Polecenia wpisujemy do ChatGPT, ale te same możesz podać Microsoft Copilotowi, Claude albo Gemini. Przy skryptach korzystających z mechanizmów serwera w małej szarej ramce znajdziesz ich odpowiedniki dla Oracle i PostgreSQL.

Generowanie testów SQL z AI: dane testowe i oczekiwany wynik

Testy zapytań i funkcji SQL pisze się rzadko, bo są żmudne: trzeba przygotować dane z zachowaniem kluczy obcych, wyliczyć oczekiwany wynik, porównać go z rzeczywistym i posprzątać. To dokładnie ten rodzaj pracy, który AI wykonuje w minutę. Nasz rachunek z tej sekcji brzmi tak: AI napisało ponad 1800 linii testów, my poświęciliśmy kwadrans na sprawdzenie, czy te testy mają sens. Ten kwadrans okazał się konieczny.

Testujemy funkcję, która liczy przychód z opłaconych zamówień każdego klienta w podanym miesiącu. W sekcji o błędach logicznych pokazaliśmy, że zamówienie z dwiema płatnościami potrafi po cichu podwoić przychód, więc ta funkcja jest dobrym kandydatem do zabezpieczenia testami.

/* Funkcja pod testami: przychód z opłaconych zamówień każdego klienta w podanym miesiącu.
   Zamówienie jest opłacone, gdy ma co najmniej jedną płatność SUCCESS.
   Klienci bez opłaconych zamówień w miesiącu też są w wyniku (0 zamówień, 0 zł). */
CREATE OR ALTER FUNCTION dbo.fn_PaidRevenueByCustomer (@MonthStart date)
RETURNS TABLE
AS
RETURN
SELECT c.CustomerID,
       COUNT(o.OrderID)             AS PaidOrders,
       ISNULL(SUM(v.OrderValue), 0) AS PaidRevenue
FROM dbo.Customers AS c
LEFT JOIN dbo.Orders AS o
       ON o.CustomerID = c.CustomerID
      AND o.OrderDate >= @MonthStart
      AND o.OrderDate <  DATEADD(MONTH, 1, @MonthStart)
      AND EXISTS (SELECT 1 FROM dbo.Payments AS p
                  WHERE p.OrderID = o.OrderID AND p.Status = 'SUCCESS')
OUTER APPLY (SELECT SUM(oi.Quantity * oi.UnitPrice * (100 - oi.DiscountPct) / 100) AS OrderValue
             FROM dbo.OrderItems AS oi
             WHERE oi.OrderID = o.OrderID) AS v
GROUP BY c.CustomerID;

Testy uruchamiamy w osobnej, pustej bazie DemoShop_Test o identycznym schemacie, nigdy na danych produkcyjnych. Skrypt tworzący taką bazę jest w plikach do pobrania. W poleceniu wymieniliśmy przypadki brzegowe, które chcemy sprawdzić. Możesz je ustalić sam albo najpierw poprosić AI o propozycję i ją przejrzeć. Do tego trzy wymagania techniczne: jawne identyfikatory w danych testowych, oczekiwany wynik zapisany w tabeli i porównanie przez EXCEPT w obie strony.

Pierwsze uruchomienie: błąd składni i ani jednego testu

Skrypt miał ponad 1600 linii i wyglądał porządnie. W SSMS zatrzymał się jednak od razu, na etapie analizy składni, więc nie wykonał się żaden test:

Błąd był banalny, ale zablokował cały skrypt. To dobra ilustracja zasady, do której wracamy w sekcji Kiedy AI się myli: kod od AI zawsze uruchamiamy, zanim uznamy go za gotowy. Model nie wykonuje swojego kodu, tylko go pisze.

Sprawdzamy oczekiwane wartości, zanim uwierzymy w PASS

Test jest tyle wart, ile jego oczekiwany wynik. Gdyby AI wyliczyło oczekiwaną wartość tak samo błędnie jak funkcja, test przeszedłby i niczego by nie udowodnił. Dlatego każdy przypadek przeliczyliśmy ręcznie z danych, które AI wstawia:

Wszystkie dziewięć oczekiwanych wyników zgadza się z definicją funkcji. Dopiero teraz uruchamiamy poprawiony skrypt:

Po testach sprawdziliśmy jeszcze stan bazy: wszystkie tabele w DemoShop_Test mają zero wierszy, bo każdy przypadek kończy się wycofaniem transakcji.

Czy te testy cokolwiek łapią? Celowo psujemy funkcję

Komplet PASS nie dowodzi jeszcze, że testy działają. Test, który zawsze przechodzi, też daje komplet PASS. Żeby to sprawdzić, wprowadzamy do funkcji błąd, który ktoś mógłby zrobić w dobrej wierze: zamieniamy EXISTS na złączenie z tabelą płatności, bo „złączenie jest prostsze”. Taki zabieg nazywa się testem mutacyjnym.

/* „Optymalizacja”: EXISTS zamieniony na złączenie z Payments.
   Wygląda niewinnie, ale zamówienie z dwiema płatnościami SUCCESS liczy się teraz dwa razy. */
CREATE OR ALTER FUNCTION dbo.fn_PaidRevenueByCustomer (@MonthStart date)
RETURNS TABLE
AS
RETURN
SELECT c.CustomerID,
       COUNT(p.OrderID)             AS PaidOrders,
       ISNULL(SUM(v.OrderValue), 0) AS PaidRevenue
FROM dbo.Customers AS c
LEFT JOIN dbo.Orders AS o
       ON o.CustomerID = c.CustomerID
      AND o.OrderDate >= @MonthStart
      AND o.OrderDate <  DATEADD(MONTH, 1, @MonthStart)
LEFT JOIN dbo.Payments AS p
       ON p.OrderID = o.OrderID
      AND p.Status = 'SUCCESS'
OUTER APPLY (SELECT SUM(oi.Quantity * oi.UnitPrice * (100 - oi.DiscountPct) / 100) AS OrderValue
             FROM dbo.OrderItems AS oi
             WHERE oi.OrderID = p.OrderID) AS v
GROUP BY c.CustomerID;

Ile ten błąd kosztowałby na prawdziwych danych? Uruchomiliśmy obie wersje logiki na grudniu 2025 roku w pełnej bazie DemoShop:

Prawie 50 milionów złotych zawyżonego przychodu w jednym miesiącu, bez żadnego błędu i bez ostrzeżenia. Na przeglądzie kodu taka zmiana mogłaby przejść, bo wygląda jak uproszczenie. Test numer 4 zatrzymuje ją w kilka sekund.

Pliki z tej sekcji: skrypt pustej bazy DemoShop_Test, funkcja poprawna, funkcja z błędem do testu mutacyjnego i poprawiony skrypt testów od AI.

AI jako SQL Code Reviewer

Przegląd kodu (code review) to drugi zestaw oczu przed wdrożeniem. AI nadaje się do tej roli wyjątkowo dobrze, bo nie męczy się, nie przeocza powtarzalnych wzorców i zna typowe błędy bezpieczeństwa. Polecenie może być krótkie, byle nadawało rolę i nazywało obszary oceny:

Do testu wybraliśmy procedurę, jaką można znaleźć w wielu starszych systemach: wyszukiwanie klientów w panelu obsługi, z warunkami sklejanymi w tekst zapytania i wykonywanymi przez EXEC. Do polecenia dopisaliśmy wersję bazy i dołączyliśmy plik z opisem schematu, żeby AI mogło porównać typy parametrów z kolumnami.

/* Procedura wyszukiwania klientów z „dawnego” panelu obsługi */
CREATE OR ALTER PROCEDURE dbo.usp_SearchCustomers
    @LastName nvarchar(100),
    @City     nvarchar(100) = NULL,
    @SortBy   varchar(50)   = 'LastName'
AS
BEGIN
    DECLARE @sql nvarchar(max) =
        N'SELECT * FROM dbo.Customers WITH (NOLOCK) WHERE LastName LIKE ''%' + @LastName + N'%''';
    IF @City IS NOT NULL
        SET @sql = @sql + N' AND City = ''' + @City + N'''';
    SET @sql = @sql + N' ORDER BY ' + @SortBy;
    EXEC (@sql);
END;

Przegląd jest kompletny i trafnie uszeregowany. Na szczególną uwagę zasługują trzy rzeczy. Pierwsza: AI wyjaśnia, dlaczego kolumny sortowania nie da się po prostu przekazać jako parametru (parametr jest wartością, a nie nazwą kolumny) i proponuje listę dozwolonych wartości mapowanych na gotowe fragmenty kodu. Druga: opisuje NOLOCK jako błąd znaczeniowy, a nie optymalizację, bo pozwala czytać dane z niezatwierdzonych transakcji. Trzecia: zauważa, że pusty parametr nazwiska zwróci wszystkich 200 tysięcy klientów.

Czy wstrzyknięcie naprawdę działa? Sprawdzamy na bazie

Opis podatności to jedno, a dowód to drugie. Uruchamiamy starą procedurę z parametrem, który zamyka apostrof i dokleja warunek zawsze prawdziwy:

-- Próba wstrzyknięcia przez parametr z nazwiskiem
EXEC dbo.usp_SearchCustomers
     @LastName = N'x'' OR 1=1 --';

Groźniejsza jest kolumna sortowania, bo przez nią da się dopisać do zapytania dowolne polecenie. Tu dopisaliśmy niewinne SELECT name FROM sys.databases, ale w tym miejscu równie dobrze mogłoby stać polecenie zmieniające albo usuwające dane, wykonane z uprawnieniami aplikacji:

-- Próba wstrzyknięcia przez kolumnę sortowania: drugie zapytanie dopisane do ORDER BY
EXEC dbo.usp_SearchCustomers
     @LastName = N'Kowalsk',
     @City     = N'Gdańsk',
     @SortBy   = 'LastName; SELECT name FROM sys.databases';

Wersja poprawiona przez AI

Te same próby na poprawionej wersji kończą się tak, jak powinny. Nazwisko ze wstrzyknięciem jest traktowane jako zwykły tekst, którego żaden klient nie ma w nazwisku, więc wynik jest pusty. Kolumna sortowania spoza listy powoduje błąd 50002 z komunikatem z procedury.

-- Ta sama próba na procedurze poprawionej przez AI
EXEC dbo.usp_SearchCustomers
     @LastName = N'x'' OR 1=1 --';

-- Kolumna sortowania spoza listy dozwolonych wartości
EXEC dbo.usp_SearchCustomers
     @LastName = N'Kowalsk',
     @City     = N'Gdańsk',
     @SortBy   = 'LastName; SELECT name FROM sys.databases';

-- Normalne wywołanie wersji od AI
EXEC dbo.usp_SearchCustomers
     @LastName = N'Kowalsk',
     @City     = N'Gdańsk',
     @SortBy   = 'FirstName';

Lista kontrolna przeglądu SQL: 25 punktów

Polecenie z ogólną prośbą o przegląd daje dobre wyniki, ale jeszcze lepsze daje lista, według której AI ma przejść punkt po punkcie i przy każdym napisać „spełnione”, „niespełnione” albo „nie dotyczy”. To samo zestawienie przydaje się w przeglądzie robionym przez człowieka. Ułożyliśmy je z problemów, które pokazujemy w tym przewodniku, przy każdym punkcie jest odsyłacz do przykładu.

✕