03.06.2025 08:13
21_copilots 1 408 Источник

Я — Solution Architect с 19 годами в айти и частенько помогаю новичкам в тестировании. Но джуны постоянно жалуются на вагон теории, отсутствие практики и примеров, где всё собрано в одном месте.

Поэтому написал эту статью, где взял OWASP Juice Shop — уязвимый веб-магазин, развернул его через Docker по адресу http://135.181.239.135:4000 и протестировал с помощью ИИ.

Также расскажу про:

  1. ИИ для запуска тест-кейсов — как запускать автотесты без глубоких знаний скриптов.

  2. Обучение ИИ-генерации тест-кейсов — как помогает придумывать, что тестировать.

  3. Написание баг-репортов с ИИ— как нейросеть делает отчёты о багах чёткими и профильными.

  4. Эксплоративное тестирование с ИИ — как он подсказывает, где искать баги.

  5. ИИ как твой учитель — как ИИ даёт фидбэк и учит тестировать лучше.

  6. Подводные камни ИИ для джунов — чего остерегаться, чтобы не плодить баги.

ИИ для запуска тест-кейсов

Чтобы всем было проще — притворюсь джуном-тестировщиком. У меня будет OWASP Juice Shop, крутящийся в Docker. И задача — протестировать его.

Но на этом этапе джун ещё не умеет писать скрипты на Selenium или Playwright. То есть знает, как проверять UI, кликать кнопки, заполнять формы, но как это закодить — нет.

За помощью обращаюсь к ИИ — Workik.

Возвращаясь к Juice Shop, решаю, что хочу протестировать форму логина: ввести данные, нажать «Log in» и проверить, что всё работает. ИИ поможет настроить Cypress, не искать селекторы и не молиться о том, чтобы фронт не поменял классы. Но с Workik всё проще. Этот бесплатный инструмент генерит тесты на Cypress по описанию функциональности. Я просто пишу, что хочу протестировать, а ИИ выдаёт готовый код, который можно запустить.

Шаг 1: Заходим в Workik и описываем задачу

Я открываю https://workik.com/cypress-test-case-generator в браузере. Там есть поле, куда вбить описание теста. Пишу что-то вроде:

Тестирование формы логина в OWASP Juice Shop на http://135.181.239.135:4000/#/login. 
Проверить: 
1. Успешный вход с email "test@test.com" и паролем "password123".
2. Ошибка при неверном пароле "wrongpass".
3. Ошибка при пустом email.

Жму «Generate», и Workik выдаёт мне готовый код на Cypress. Вот пример того, что я получаю (чуть упрощённый, но близко к реальности):

// cypress/integration/login.spec.js

describe('Тестирование формы логина в OWASP Juice Shop', () => {
    const baseUrl = 'http://135.181.239.135:4000/#/login';

    beforeEach(() => {
        // Переход на страницу логина перед каждым тестом
        cy.visit(baseUrl);
    });

    it('Успешный вход с валидными данными', () => {
        // Вводим корректные данные
        cy.get('input[type="email"]').type('test@test.com');
        cy.get('input[type="password"]').type('password123');
        
        // Отправляем форму
        cy.get('button[type="submit"]').click();
        
        // Проверяем, что пользователь успешно вошел
        cy.url().should('include', '/');
        cy.contains('Welcome back!').should('be.visible'); // Проверьте, что это сообщение отображается
    });

    it('Ошибка при неверном пароле', () => {
        // Вводим email и неверный пароль
        cy.get('input[type="email"]').type('test@test.com');
        cy.get('input[type="password"]').type('wrongpass');
        
        // Отправляем форму
        cy.get('button[type="submit"]').click();
        
        // Проверяем наличие сообщения об ошибке
        cy.contains('Invalid email or password').should('be.visible'); // Проверьте текст ошибки
    });

    it('Ошибка при пустом email', () => {
        // Оставляем email пустым и вводим пароль
        cy.get('input[type="email"]').type('');
        cy.get('input[type="password"]').type('password123');

        // Отправляем форму
        cy.get('button[type="submit"]').click();
        
        // Проверяем наличие сообщения об ошибке
        cy.contains('Email is required').should('be.visible'); // Проверьте текст ошибки
    });
});

Шаг 2: Настраиваем окружение и запускаем тесты

Чтобы запустить этот код, нужен Cypress. У меня уже есть Node.js (если нет, качаю с nodejs.org). Открываю терминал, создаю папку для проекта:

mkdir juice-shop-tests
cd juice-shop-tests
npm init -y
npm install cypress --save-dev

Так должна выглядеть папка после:

Теперь инициализирую Cypress:

npx cypress open

Cypress открывает окно, где я выбираю E2E Testing

Дальше соглашаюсь со стандартной конфигурацией и открываю браузер:

создаю новый файл конфигурации,

например, login.spec.cy.js, и копирую туда код от Workik. Жму «Run», и Cypress запускает тесты в браузере. Я вижу, как он открывает Juice Shop, вводит данные, кликает кнопки и проверяет результаты. Если всё ок - тесты зелёные. Если что-то падает, Cypress показывает, где косяк. Остаётся только понять, почему этот косяк там появился.
Скриншот для примера:

Шаг 3: Учимся на результатах

Допустим, тест с неверным паролем упал, потому что Juice Shop выдаёт не «Invalid email or password», а «Wrong credentials». Я открываю код, меняю строку:

cy.get('#errorMessage').should('contain', 'Wrong credentials');

Запускаю снова — тест проходит. Workik не только дал мне код, но и помог понять, как работает валидация ошибок. А ещё я заметил, что он не предложил тест на SQL-инъекцию. Я возвращаюсь в Workik, добавляю в описание: «Проверить SQL-инъекцию с email ' OR '1'='1», и получаю новый тест:

it('should handle SQL injection attempt', () => {
  cy.get('#email').type("' OR '1'='1");
  cy.get('#password').type('password123');
  cy.get('#loginButton').click();
  cy.get('#errorMessage').should('contain', 'Invalid email or password');
});

Теперь я знаю, что Juice Shop не падает на инъекции, и что такое уязвимости.

Шаг 4: Интеграция (для амбициозных джунов)

Можно закинуть тесты в CI/CD, например, в GitHub Actions. Workik даёт код, который я пушу в репо, а в .github/workflows/cypress.yml добавляю:

name: Cypress Tests
on: [push]
jobs:
  cypress-run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '16'
      - run: npm install
      - run: npx cypress run

Теперь тесты бегут при каждом пушe – Workik сделал автоматизацию доступной даже для джуна.

Плюсы для джуна:
· Создаёте описание на человеческом языке, а Workik генерит код на Cypress.
· Смотрите на сгенерированные тесты и начинаете шарить, как работает Cypress.
· Workik не просит денег, в отличие от многих других инструментов.
· Тесты готовы за минуту, а вы можете сосредоточиться на анализе багов.

Подводные камни:
· Workik иногда генерит неидеальные селекторы. Если #loginButton поменяется на .btn-login, тест может упасть, и надо будет всё править руками.
· Бесплатная версия может иметь лимиты на количество тестов. Если я захочу тестировать весь Juice Shop, придётся быть экономным или искать альтернативы.
· ИИ не знает всех нюансов приложения. Если Juice Shop выдаёт нестандартные ошибки, нужно самому вникать и корректировать тесты.

Учимся через ИИ-генерацию тест-кейсов

Форма логина в Juice Shop кажется простой — ввёл email, пароль, кликнул «Log in», и готово. Но любой опытный тестировщик скажет, что предварительно надо проверить кучу сценариев: от пустых полей до хакерских SQL-инъекций. Джун не сможет держать в голове все эти edge cases. Поэтому снова идём к Workik, где описываем функциональность, а он генерит тест-кейсы, которые не только решают задачу, но и учат думать, как настоящий тестировщик.

Пример: вам надо протестировать форму логина в Juice Shop. Вы знаете, что нужно проверить успешный вход и, может, неверный пароль. Но что ещё?

Шаг 1: Описываем задачу в Workik

Открываю https://workik.com/cypress-test-case-generator. В поле ввода формирую описание, стараясь быть понятным, но не слишком заморачиваясь с деталями:

Тестирование формы логина в OWASP Juice Shop на http://135.181.239.135:4000/#/login. 
Проверить: 
- Успешный вход с email "test@test.com" и паролем "password123".
- Ошибка при неверном пароле.
- Ошибка при пустом email.
- Попытка SQL-инъекции в поле email.
- Длинный email (более 100 символов).

Жму «Generate», и Workik выдаёт мне код на Cypress. Вот что я получаю (чуть упрощённый пример, но близко к тому, что даёт инструмент):

describe('OWASP Juice Shop Login Form Tests', () => {
  beforeEach(() => {
    cy.visit('http://135.181.239.135:4000/#/login');
  });

  it('should login successfully with valid credentials', () => {
    cy.get('#email').type('test@test.com');
    cy.get('#password').type('password123');
    cy.get('#loginButton').click();
    cy.url().should('include', '/#/');
    cy.get('#welcomeMessage').should('contain', 'Welcome');
  });

  it('should show error for invalid password', () => {
    cy.get('#email').type('test@test.com');
    cy.get('#password').type('wrongpass');
    cy.get('#loginButton').click();
    cy.get('#errorMessage').should('contain', 'Invalid email or password');
  });

  it('should show error for empty email', () => {
    cy.get('#password').type('password123');
    cy.get('#loginButton').click();
    cy.get('#errorMessage').should('contain', 'Email is required');
  });

  it('should handle SQL injection attempt', () => {
    cy.get('#email').type("' OR '1'='1");
    cy.get('#password').type('password123');
    cy.get('#loginButton').click();
    cy.get('#errorMessage').should('contain', 'Invalid email or password');
  });

  it('should handle long email input', () => {
    const longEmail = 'a'.repeat(100) + '@test.com';
    cy.get('#email').type(longEmail);
    cy.get('#password').type('password123');
    cy.get('#loginButton').click();
    cy.get('#errorMessage').should('contain', 'Email too long');
  });
});

Джун вряд ли до этого момента задумывался о SQL-инъекции и длинном email. Но Workik не просто дал тесты, а показал, какие сценарии важны.

Шаг 2: Запускаем и анализируем

Чтобы запустить эти тесты, нужно настроить Cypress. Как это делать — рассказал в прошлой главе. Дальше копирую код в файл, скажем, login-edge-cases.spec.js, и запускаю:

npx cypress open

Cypress открывает браузер, и я вижу, как тесты бегут один за другим. Успешный вход — зелёный. Неверный пароль — зелёный. Пустой email — зелёный. SQL-инъекция — зелёный. Но вот тест с длинным email падает. Смотрю лог: вместо «Email too long» Juice Shop выдаёт что-то вроде «Invalid input». Тогда меняю строку:

cy.get('#errorMessage').should('contain', 'Invalid input');

Запускаю снова — и всё зелёное. В итоге я не только прогнал тесты, но и понял, как приложение обрабатывает длинные строки. Workik заставил задуматься о краевых случаях, и наглядно показал, что такое «валидация на сервере».

Шаг 3: Учимся думать как тестировщик

Я всегда советую Workik новичкам, потому что он не просто генерит код, а учит анализировать приложение глазами тестировщика. Джуны, когда видят тест на SQL-инъекцию, начинают гуглить: «А что это вообще такое?» И узнают, что хакеры могут ломать базы через формы, если их плохо защитили.
Но теперь джун не просто тыкает кнопки, а думает: «А где ещё в Juice Shop можно попробовать инъекцию? Может, в поиске или в корзине?».

Или например длинный email. Не многие в начале решают проверить, что будет, если вбить 100 символов. Но Workik подкинул этот кейс, и теперь вы знаете, что надо тестировать границы — максимумы, минимумы, всякие странные вводы.

Шаг 4: Прокачиваемся дальше

Чтобы закрепить знания, я возвращаюсь в Workik и пробую описать другую функциональность, например, добавление товара в корзину:

Тестирование добавления товара в корзину в OWASP Juice Shop. 
Проверить:
- Добавление одного товара.
- Добавление товара с количеством 0.
- Добавление товара с отрицательным количеством.

Workik выдаёт новые тесты, и я вижу, что он предложил проверить, не крашнется ли корзина при вводе -1. У вас возникнет вопрос: «Серьёзно? Кто-то вобьёт минус один?» Но запустив тест я нахожу баг: Juice Shop позволяет добавить отрицательное количество, и корзина показывает странную сумму.

Плюсы для джунов:
· Workik подкидывает неочевидные кейсы, вроде SQL-инъекций или длинных строк.
· Анализ сгенерированных тестов помогает понять, как писать свои.
· Понятный интерфейс и не надо платить.
· Учит находить баги и новые алгоритмы работы.

Подводные камни:
· Workik может не угадать точные селекторы или сообщения об ошибках. Если Juice Shop выдаёт не «Email is required», а «Please enter email», надо править тест руками.
· Бесплатная версия может ограничивать количество генераций. Если вы тестируете весь Juice Shop, придётся экономить или искать другие инструменты.
· ИИ не знает контекста. Если вы напишите размытое описание, вроде «протестировать логин», Workik может упустить важные моменты.
· Стопроцентно доверять ИИ нельзя: если Workik не предложил тест на XSS-уязвимость, это не значит, что её не надо проверять.

Упрощаем баг-репорты с ИИ

Найти баг — это только полдела. Ещё надо описать его так, чтобы разрабы поняли суть и не докопались с вопросами. Но писать крутой баг-репорт джуну — задача не из простых.

Пример: я тестирую Juice Shop, и в форме логина нахожу баг — если ввести email длиннее 100 символов, приложение выдаёт ошибку 500 вместо нормального сообщения. Без ИИ я бы написал что-то вроде: «Ну, короче, если длинный email, то всё ломается». Разрабы за такой репорт закидали бы камнями.
Поэтому рассказываю, как с помощью Workik и нескольких лайфхаков получать отчёты, от которых разрабы не будут фыркать.

Шаг 1: Ловим баг с Workik

Вы уже знаете, как Workik генерит тесты на Cypress (из прошлой главы). Затем я прогнал тест на длинный email, который нашёл в форме логина:

it('should handle long email input', () => {
  const longEmail = 'a'.repeat(100) + '@test.com';
  cy.get('#email').type(longEmail);
  cy.get('#password').type('password123');
  cy.get('#loginButton').click();
  cy.get('#errorMessage').should('contain', 'Email too long');
});

Тест падает, потому что вместо «Email too long» я вижу ошибку 500. Cypress показывает мне лог: «Server responded with 500 Internal Server Error». Да, это баг. Но как его описать джуну? Workik и Cypress подбрасывают зацепки: шаги теста, скриншот экрана и логи.

Шаг 2: Собираем баг-репорт с помощью ИИ

Чтобы баг-репорт был крутым, он должен включать:

  • Название: Короткое и ясное, чтобы сразу было понятно, что сломалось.

  • Шаги воспроизведения: Что я делал, чтобы баг вылез.

  • Ожидаемое поведение: Что должно было случиться.

  • Фактическое поведение: Что случилось на самом деле.

  • Скриншоты/логи: Доказательства, чтобы разрабы не докапывались.

  • Окружение: Где я тестировал (браузер, URL, версия).

Cypress, на котором Workik генерит тесты, автоматически сохраняет скриншоты и видео, если тест падает. Я открываю папку cypress/screenshots и нахожу картинку, где видно ошибку 500. В логах Cypress вижу точный запрос, который ушёл на сервер, и ответ. Теперь я иду в баг-трекер (допустим, Jira) и начинаю писать репорт, используя данные из теста.

Вот как выглядит мой баг-репорт:

Баг-репорт
Название: Ошибка 500 при попытке входа в OWASP Juice Shop через API
Шаги воспроизведения:

  1. Открыл OWASP Juice Shop по URL: http://localhost:3000/#/login.

  2. Запустил автоматический тест в Cypress для проверки входа через API.

  3. Тест отправил GET-запрос на /api/Challenges/?name=Score%20Board.

  4. Тест отправил GET-запрос на /rest/admin/application-configuration.

Ожидаемое поведение:

  • GET-запросы должны вернуть статус 200 и данные (например, список челленджей и конфигурацию приложения).

  • Пользователь должен успешно войти в приложение через API.

Фактическое поведение:

  • GET-запрос на /api/Challenges/?name=Score%20Board вернул статус 500 Internal Server Error.

  • GET-запрос на /rest/admin/application-configuration вернул статус 500 Internal Server Error.

  • Вход через API не произошёл, тест упал.

Скриншоты/Логи:

  • Скриншот из папки cypress/screenshots, где видно ошибку 500 (прикреплен к баг-репорту).

  • Логи Cypress: 

    GET 500 /api/Challenges/?name=Score%20Board
GET 500 /rest/admin/application-configuration

  • Дополнительно: в ответе сервера на оба запроса вернулся код EIO:4&transport=polling&t=PSMpFoK&sid=eGEJ5Qk20S0rHOuhCAAE.

Окружение:

  • Браузер: Google Chrome (последняя версия на момент теста).

  • URL: http://localhost:3000/#/login.

  • Тестирование проводилось через Cypress (версия неизвестна, но могу уточнить, если нужно).

  • OWASP Juice Shop запущен локально.

Шаг 3: Упрощаем процесс с ИИ-инструментами

Workik и Cypress — это уже мощно, но можно пойти дальше. Есть ИИ-инструменты, которые напрямую помогают писать баг-репорты. Например, если я использую Testim (хотя он не бесплатный, но для примера сойдёт) или BugBug, они могут анализировать падение теста и предлагать готовый текст для репорта. Допустим, я прогнал тест в BugBug, и он выдал:

Test failed: Expected text "Email too long" not found. Actual: 500 Internal Server Error.
Suggested bug report:
- Steps: Navigate to login page, enter email >100 chars, enter password, click Log in.
- Expected: Error message about email length.
- Actual: Server error 500.
- Attachments: Screenshot, video.

Я беру этот текст, редактирую и кидаю в Jira. Даже без BugBug я могу заюзать ИИ-ассистента, вроде ChatGPT или Grok, чтобы улучшить репорт. Пишу: «Эй, Grok, сделай мой баг-репорт более профессиональным», и он выдаёт отполированный текст, который выглядит, будто его писал сеньор.

Шаг 4: Учимся на баг-репортах

ИИ не только помогает писать репорты, но и учит, как их делать лучше. Разрабам всегда нужны чёткие инструкции. И если вы забыли указать окружение, а разраб спрашивает: «Это в Chrome или Firefox?», то в следующий раз добавьте эту инфу. Если ваш репорт слишком длинный, ИИ поможет сократить с помощью команды: «Сократи шаги до 3-4».

На Juice Shop я нашёл ещё один баг: если в корзине ввести отрицательное количество товара, сумма становится отрицательной. Я прогнал тест через Workik, получил скриншот и написал репорт:

Название: Отрицательная сумма в корзине при вводе отрицательного количества
Шаги:

  1. Открыть http://135.181.239.135:4000/#/basket.

  2. Добавить товар в корзину.

  3. В поле количества ввести -1.

  4. Проверить сумму.

  5. Ожидаемое: Ошибка или блокировка отрицательного количества.Фактическое: Сумма становится отрицательной.

  6. Скриншоты: [Скрин из Cypress].

  7. Окружение: Chrome 126, Juice Shop на http://135.181.239.135:4000.

Плюсы для джуна:
· ИИ (Workik, Cypress) даёт шаги, скриншоты и логи, чтобы репорт был понятным.
· На описание бага тратится 5 минут вместо часа.
· Репорты выглядят профессионально.
· Анализ репортов помогает учиться делать их лучше.

Подводные камни:
· ИИ может упустить контекст. Если баг связан с UX (например, кнопка выглядит криво), Cypress не покажет это на скриншоте, и мне надо самому описать.
· Автогенерированные репорты иногда слишком сухие. Надо добавлять детали, чтобы разрабы поняли, почему это важно.
· Если вы слишком полагаетесь на ИИ, можно забыть, как писать репорты вручную.
· Бесплатные инструменты, как Workik, не всегда дают видео или подробные логи. Иногда приходится копать самому.

Эксплоративное тестирование с ИИ

Если по-простому, то эксплоративное тестирование — это когда ты юзаешь приложение как пользователь, но с мозгами тестировщика.
Звучит круто, но на деле у джунов возникают вопросы: «Где искать баги? Что тыкать? Вдруг я всё сломаю?». Juice Shop — это вообще минное поле: уязвимости, странные сценарии, скрытые косяки. В роли джуна я бы без подсказок тыкал кнопки наугад и, скорее всего, пропустил бы что-то важное.

То есть эксплоративное тестирование — это когда ты не следуешь строгим тест-кейсам, а исследуешь приложение, пробуя странные сценарии, ломая функционал и выискивая уязвимости. Для Juice Shop это идеально: там полно дыр, от XSS до SQL-инъекций.
Но обычно джун не знает, с чего начать. Поэтому предлагаю сходить к ИИ, чтобы сориентироваться, какие области рискованные и какие сценарии стоит проверить.

Шаг 1: Получаем подсказки от ИИ

Я открываю Workik (https://workik.com/cypress-test-case-generator) и решаю использовать его не только для автотестов, но и для идей эксплоративного тестирования. В поле ввода пишу что-то вроде:

Исследовать OWASP Juice Shop на http://135.181.239.135:4000. Найти потенциальные уязвимости в форме логина, корзине и поиске. Подсказать сценарии для эксплоративного тестирования.

Workik анализирует мой запрос и выдаёт не только тесты, но и предложения, которые я могу использовать для ручного исследования. Вот пример, что он может предложить (чуть упрощённый, но в духе инструмента):

OWASP Juice Shop — это уязвимое веб-приложение, предназначенное для обучения и тестирования навыков безопасности. Эксплоративное тестирование — отличный способ поиска уязвимостей, так как оно позволяет исследовать приложение с помощью различных сценариев.

Вот несколько потенциальных уязвимостей и сценариев для тестирования в формах логина, корзины и поиска.

Рекомендации для эксплоративного тестирования

1. Форма логина

Потенциальные уязвимости:

  • SQL-инъекция: Попытайтесь ввести SQL-коды в поля email и пароля.

  • XSS (кросс-сайтовый скриптинг): Попробуйте вставить JavaScript-код в поля ввода (например, ">).

  • Переполнение доступности: Проверьте, как приложение обрабатывает ссылки для восстановления пароля и активации учетных записей. Исследуйте открытые перенаправления.

Сценарии для тестирования:

  • Введите SQL-команду в поле логина, например: test@test.com' OR '1'='1.

  • Введите в поле пароля значение '); DROP TABLE users; --.

  • Проверьте поведение системы при вводе PHP кода: ``.

  • Пытаясь восстановить пароль, войдите в адресную строку и измените URL для получения уязвимого кода.

2. Корзина

Потенциальные уязвимости:

  • Manipulation (манипуляция) с количеством: Изменение количества товара через инструменты разработчика или путем модификации кода страницы.

  • CSRF (межсайтовая подделка запроса): Проверьте, есть ли в приложении защита от CSRF для добавления товара в корзину.

  • Brute Force (грубо силовая атака): Пытайтесь добавлять большое количество товаров за короткий промежуток времени.

Сценарии для тестирования:

  • Используйте инструменты разработчика (DevTools) для изменения значения количества товара в корзине. Попробуйте добавить великие числа, чтобы проверить реакцию системы.

  • Проверьте, может ли злоумышленник отправить запрос добавления товара от имени пользователя без проверки CSRF токена.

  • Попытайтесь добавить тот же товар в корзину несколько раз подряд, чтобы проверить, вызывает ли это какие-либо ошибки или предупреждения о перегрузке.

3. Поиск

Потенциальные уязвимости:

  • Injection (инъекция): Попробуйте выполнить SQL или другие инъекции через поле поиска.

  • XSS: Попробуйте вставить JavaScript-код в поле поиска.

  • Логические ошибки: Изучите как приложение обрабатывает некорректные или неожиданные данные в поисковых запросах.

Сценарии для тестирования:

  • Введите SQL-запрос в поле поиска, например: SELECT * FROM products;.

  • Попробуйте вставить JavaScript-код в поиск: "&gt;<img src="x">.

  • Введите несуществующий товар и посмотрите, как система реагирует на ошибку (например, просматривает ли она индикатор "Товар не найден" или просто возвращает пустую страницу).

Общие рекомендации

  • Изучите логи: Попросите разработчика или тестировщика предоставить логи приложения для понимания того, как система реагирует на нестандартные вводы.

  • Документируйте результаты: Обязательно фиксируйте результаты каждого сценария, чтобы можно было такнифицировать их для дальнейшего обучения и улучшения безопасности.

  • Используйте инструменты: Не забывайте о возможностях инструментов, таких как Burp Suite или OWASP ZAP, для более детального сканирования и анализа.

Скорее всего, джун посмотрит на эти подсказки и подумает: «Ого, XSS? Это что, можно сайт сломать через форму?». Workik не только даёт идеи, но и рассказывает, какие уязвимости бывают. Погуглив, что такое XSS или CSRF, вы поймёте, что эксплоративное тестирование — это не просто тыкать кнопки, а искать слабые места приложения.

Шаг 2: Исследуем с ИИ-подсказками

Вооружившись идеями от Workik, я открываю Juice Shop и начинаю копать. Первая цель — форма логина. Следуя подсказке, ввожу в поле email <script>alert('hack')</script> и жму «Log in». Вдруг вижу всплывающее окно с надписью «hack» — это XSS-уязвимость. Теперь пишем баг-репорт (как в примере из прошлой главы):

Название: XSS-уязвимость в форме логина
Шаги:

  1. Открыть http://135.181.239.135:4000/#/login.

  2. В поле Email ввести <script>alert('hack')</script>.

  3. В поле Password ввести любой пароль.

  4. Нажать «Log in».

Ожидаемое: Введённый скрипт экранируется, никакого алерта.  

Фактическое: Появляется alert с текстом «hack».  

Скриншоты: [Скрин с алертом].  

Окружение: Chrome 126, Juice Shop на http://135.181.239.135:4000.

Этот баг — чистое золото, и я нашёл его, потому что ИИ подсказал попробовать XSS. Без Workik всё бы ограничилось пустыми полями и неверными паролями.

Дальше иду в корзину. Workik предложил проверить отрицательное количество товаров. Добавляю яблоко в корзину, ввожу -1 в поле количества — и сумма становится отрицательной.

Ещё один баг:

Название: Отрицательная сумма в корзине при вводе -1

Шаги:  

1. Открыть http://135.181.239.135:4000/#/basket.  

2. Добавить товар (например, Apple Juice).  

3. В поле количества ввести -1.  

4. Проверить сумму.  

Ожидаемое: Ошибка или запрет на отрицательное количество.  

Фактическое: Сумма становится отрицательной.  

Скриншоты: [Скрин с минусовой суммой].  

Окружение: Chrome 126, Juice Shop на http://135.181.239.135:4000.

Закончили с репортами, пойдём дальше.

Шаг 3: Усиливаем с другими ИИ-фишками

Workik — это круто, но можно пойти дальше. Например, есть ИИ-инструменты вроде BugBug или Testim, которые анализируют поведение пользователей или прошлые баги и подсказывают, где копать. Допустим, я подключаю BugBug (хотя он частично платный, но для примера сойдёт). Он смотрит на логи Juice Shop и говорит: «Часто падают запросы в поиске, попробуй там поковыряться». Я иду в поиск, ввожу %' OR '1'='1, — и поиск выдаёт все товары, включая скрытые. Это потенциальная SQL-инъекция.

Ещё одна фишка — ИИ-ассистенты, вроде Grok. Я могу спросить: «Эй, Grok, какие уязвимости стоит проверить в веб-магазине?». И он ответит: «Проверяй формы ввода (например, комментарии, поиск, поля профиля) на возможность внедрения скриптов. Пример: <script>alert('test')</script>.

Шаг 4: Учимся быть параноиком

Самое крутое в эксплоративном тестировании с ИИ — оно учит быть параноиком (в хорошем смысле). Workik подсказал про XSS, и теперь я везде ищу, куда можно закинуть скрипт. Нашёл баг в поиске: если ввести <script>alert('boom')</script>, страница тоже выдаёт алерт. Или в корзине: попробовал добавить 999999 товаров, и сервер лёг с ошибкой 503. Каждый баг — это урок: я начинаю понимать, где приложение слабое, и учусь предугадывать косяки.

Плюсы для джуна:
· ИИ подсказывает, где искать баги, чтобы не тыкать наугад.
· Нашли XSS — погуглили, что это, и теперь знаете, как тестировать безопасность.
· С ИИ сложнее упустить что-то важное.
· Баги вроде XSS или отрицательной суммы прокачивают вашу насмотренность.

Подводные камни:
· Workik может упустить специфические баги Juice Shop, вроде уязвимостей в API, если я не укажу это в описании.
· Подсказки иногда слишком общие. «Проверь XSS» — ок, но где именно? Надо самому копать.
· Риск переусердствовать с ИИ. Если я только и делаю, что следую подсказкам, могу забыть, как думать самому.
· Бесплатные инструменты, как Workik, не дают глубокого анализа логов или поведения пользователей. Для этого нужны платные версии.

ИИ как твой учитель, страж и суперсила

Я помню, в начале карьеры, каждый день напоминал качели между «я всё сломал» и «кажется, я гений». Тест-кейсы, баг-репорты, эксплоративное тестирование — всё это как квесты в RPG, где я только-только выбрал персонажа. ИИ, кстати, у нас тогда не было. Сейчас джун может легко прокачивать навык тестирования, находить косяки и становиться умнее.

Финально рассказываю, как сделать ИИ наставником, какие ловушки поджидают на этом пути и почему он — ваша суперсила. На примере OWASP Juice Shop и Workik (https://workik.com/cypress-test-case-generator).

Представьте: я прогнал тест на форму логина через Workik, и он упал, потому что я ждал сообщение «Email too long», а получил «Invalid input». Cypress (спасибо Workik за код) показывает лог, а я (в качестве джуна) начинаю вникать: «Ага, значит, сервер не валидирует длинные строки как надо». ИИ, встроенный в такие инструменты, подсказывает: «Попробуй уточнить ожидание или проверь серверный лог».

Или, например, я написал баг-репорт, но он вышел корявым — шаги нечёткие, скриншотов нет. Я кидаю текст в Grok и прошу: «Эй, сделай репортик покрасивее». ИИ выдаёт отполированный текст с чёткими шагами и даже советует: «Добавь версию браузера, разрабы любят точность». Я такой: «О, точно, надо запомнить!».

Workik учит и через сгенерированные тест-кейсы. Когда он предлагает проверить SQL-инъекцию в форме логина (' OR '1'='1), вы не только запускаете тест, но и гуглите: «А что это за инъекция такая?». Через час вы уже в курсе, как хакеры ломают базы, и начинаете искать похожие дыры в поиске или корзине. ИИ не просто даёт код, а заставляет думать: «Где ещё может быть косяк? Что я упустил?».

Также ИИ доступен 24/7. Сеньоры заняты, а ИИ всегда под рукой. Если я застрял на баге в корзине Juice Shop (например, отрицательное количество товаров), я могу спросить: «Grok, почему сумма в минус уходит?». И он объяснит: «Скорее всего, нет валидации на сервере. Проверь API-запросы». Я лезу в DevTools, нахожу запрос и вижу, что сервер принимает -1 без вопросов. Это не просто ответ, а урок, как копать глубже. С ИИ вы учитесь тестировать не только UI, но и API, безопасность, UX — всё, что делает QA крутым.

Подводные камни ИИ для джунов

Но не всё так радужно. ИИ — крутой помощник, но иногда он может завести в дебри. Вот какие ловушки я заметил, пока тестировал Juice Shop:
- Слепая вера: Workik сгенерил тест на XSS, но оказалось, что он упустил проверку XSS в поиске. Если ленитесь проверять, можно пропустить баг.
- Ограничения бесплатных инструментов: Workik — бесплатный, и это кайф, но он не всегда знает точные селекторы или специфику Juice Shop. Если форма логина поменяла ID, тест падает, и надо фиксить руками. Платные инструменты, вроде Testim, дают больше аналитики.
- Сухие подсказки: ИИ иногда выдаёт общие советы, типа «проверь XSS». Ок, но где? Без контекста можно потратить часы на поиски. Учусь задавать ИИ чёткие вопросы, вроде: «Где в Juice Shop искать XSS-уязвимости?».
- Лень вместо роста: Если вы только копируете код от Workik и не вникаете, как он работает, то не растёте. Например, когда я понял, как Cypress проверяет URL (cy.url().should('include', '/#/')), я начал писать свои тесты, а не просто брать готовые.
- Контекстные косяки: ИИ не знает, что в Juice Shop есть скрытые уязвимости, вроде подмены ID в API. Если я не укажу это в запросе к Workik, он не предложит проверить.

В следующей части статьи я расскажу про этот же процесс, но уже со взглядом и руками опытного сеньора-тестировщика, а значит — и другими инструментами.

А если вам нужен ИИ-помощник для сотрудника — познакомьтесь ближе с продуктами Minervasoft. Ассистент с генеративным ИИ Minerva Copilot встраивается в любую систему компании и подсказывает ответы из корпоративной базы знаний в зависимости от контекста. Быстро, качественно и со ссылками на статьи.

Кроме того, благодаря технологии DataHub система управления знаниями Minerva Knowledge становится корпоративным «мозгом» для GenAI. Платформа объединяет любые источники информации в компании, в том числе внутренние системы, базы знаний и другие хранилища данных.

Узнать подробнее

Комментарии (1)


  1. alcochtivo
    03.06.2025 11:57
    #28389462

    А ещё я заметил, что он не предложил тест на SQL-инъекцию. Я возвращаюсь в Workik, добавляю в описание: «Проверить SQL-инъекцию с email ' OR '1'='1», и получаю новый тест...

    Теперь я знаю, что Juice Shop не падает на инъекции, и что такое уязвимости.

    А точно в такой последовательности сработает?