Всем привет! Продолжаю цикл статей про применение ИИ в тестирование. Здесь можно прочитать первую статью «ИИ в тестировании: зачем мы пошли в пилот и почему начали с чата, а не с агентов». Сегодня поговорим про тестирование требований, а именно про первый и самый важный этап — подготовку контекста.
В своей статье под контекстом я буду подразумевать структурированную информацию о продукте:
описания компонентов;
бизнес-правила;
сценарии использования;
связи между сущностями.
то есть всё то, что нужно ИИ для понимания предметной области.
Без правильного контекста LLM не сможет нормально найти противоречия в требованиях, не увидит связи между компонентами и не сможет предложить качественные тест-кейсы.
Мало просто собрать всю информацию по продукту, её ещё нужно структурировать. И только после того, как вы подготовите полный и актуальный контекст, в дело уже вступает промпт для тестирования требований (об этом — в следующей статье цикла).
Часть I. Простой кейс (как на пилоте)
На пилотном продукте подготовка контекста не показалась мне сложным этапом. У нас был небольшой калькулятор страховой премии для онкологических заболеваний: довольно простой фронт: пять основных экранов, без тяжёлой логики. Требования тоже были не очень объёмными.
Я собрала контекст по продукту в 5 шагов:
Шаг 1. Сбор всей информации в одну папку
Цель: чтобы всё, что относится к продукту, лежало рядом и было доступно и вам, и модели.
Что я делала на пилоте:
скопировала весь текст из Confluence в один файл;
выгрузила таблицы с описанием элементов в формате CSV;
сохранила всё в одной папке.
Шаг 2. Структурирование
Цель: чтобы ИИ не «тонул» в простыне текста, а видел границы смысловых блоков.
Я структурировала материал по UI-компонентам. Внутри каждого компонента описание его элементов, сценарии и прочая информация. Вы можете использовать любую удобную вам структуру, выделять функциональности, сценарии или комбинировать подходы. Также вы можете использовать комбинированный подход.
Не нужно всё делать вручную. Если информация разбросана по разным файлам, можно попросить ИИ собрать её в один файл и разложить в том виде, который вам нужен.
Шаг 3. Markdown для логического разделения
Цель: чтобы модель легче ориентировалась в иерархии.
Используйте Markdown: заголовки для разделов, списки для правил, блоки для сценариев. Это помогает ИИ лучше понимать структуру.
Markdown не обязательно размечать самостоятельно — делегируйте эту задачу ИИ, он прекрасно справляется с форматированием текстовых файлов.
Шаг 4. Разбиение на файлы
Если информации, наоборот, слишком много, разбейте ее на несколько файлов.
Один файл — одна логическая единица.
Оптимальный размер: от 5 до 15 страниц текста.
Шаг 5. Актуализация контекста
Не забывайте вовремя актуализировать контекст. Если у вас появились новые требования или изменились старые — сразу вносите правки в файлы контекста.
На этом шаге снова можно привлечь ИИ, например, попросить внести правки в нужные места или кратко описать изменения и узнать, в какие именно файлы нужно добавить информацию.
Немного дополнительных лайфхаков:
Когда контекст готов, попросите ИИ создать README.md файл с описанием структуры папки.
Включайте конкретные примеры использования компонентов или сценариев. ИИ, как и человек, лучше понимает на примерах.
Создайте словарь терминов: отдельный файл с определениями ключевых терминов помогает правильно интерпретировать домен.
Проверьте контекст перед использованием: попросите ИИ кратко резюмировать, что он понял из контекста, так проще поймать проблемы на раннем этапе.
Ошибка | Последствие |
Слишком мало контекста | ИИ не видит связей между частями продукта |
Слишком много неструктурированного / дублирующего текста | Сложнее анализировать, выше риск «шума» |
Устаревший контекст | Ложные замечания и лишние вопросы |
Нет явных связей между сущностями и компонентами | Противоречия между разделами ТЗ не всплывают |
Часть II. Сложный кейс (после пилота)
И все было бы чудесно, если бы любое ТЗ не превышало 10 страниц текста и копирование из Confluence занимало бы пару минут.
После успешного пилота я столкнулась с суровой реальностью других команд, чьи ТЗ могли занимать до ста страниц текста, таблиц и макетов, и простое «копирование из Confluence» становилось очень не простым. Я начала исследовать проблему.
Шаг 1. Экспорт и ограничения формата
Было очевидно, что требования из Confluence нужно экспортировать одним файлом и дальше как-то разобрать на части. Выбор форматов экспорта в Confluence невелик: PDF и Word. Ни тот ни другой в чистом виде Cursor не читает так, как нам нужно для дальнейшей работы.
Но оказалось, что Cursor хорошо пишет скрипты на python, которые разбирают файлы на текст и изображения.
Шаг 2. Извлечение текста и картинок из PDF (Python)
Скрипт мне целиком написал Cursor, я только обозначила задачу — вытащить из PDF весь текст и сохранить в Markdown, вытащить все изображения и сохранить в PNG в отдельной папке.
Пример скрипта для извлечения текста и изображений из PDF (с использованием разных библиотек)
#!/usr/bin/env python # -*- coding: utf-8 -*- """ Скрипт для извлечения текста и изображений из PDF файла """ import sys import os from pathlib import Path def extract_text_pdfplumber(pdf_path): """Извлечение текста с помощью pdfplumber (лучше для таблиц)""" try: import pdfplumber print(f"Извлечение текста из {pdf_path} с помощью pdfplumber...") text_content = [] with pdfplumber.open(pdf_path) as pdf: total_pages = len(pdf.pages) print(f"Всего страниц: {total_pages}") for i, page in enumerate(pdf.pages, 1): text = page.extract_text() if text: text_content.append(f"\n{'='*80}\nСТРАНИЦА {i}\n{'='*80}\n\n{text}") print(f"Обработано страниц: {i}/{total_pages}", end='\r') print(f"\nИзвлечение завершено!") return '\n'.join(text_content) except ImportError: print("pdfplumber не установлен. Попробуем pymupdf...") return None except Exception as e: print(f"Ошибка при извлечении текста (pdfplumber): {e}") return None def extract_text_pymupdf(pdf_path): """Извлечение текста с помощью pymupdf (быстрее и точнее)""" try: import fitz # pymupdf print(f"Извлечение текста из {pdf_path} с помощью pymupdf...") doc = fitz.open(pdf_path) total_pages = len(doc) print(f"Всего страниц: {total_pages}") text_content = [] for page_num in range(total_pages): page = doc[page_num] text = page.get_text() if text: text_content.append(f"\n{'='*80}\nСТРАНИЦА {page_num + 1}\n{'='*80}\n\n{text}") print(f"Обработано страниц: {page_num + 1}/{total_pages}", end='\r') doc.close() print(f"\nИзвлечение завершено!") return '\n'.join(text_content) except ImportError: print("pymupdf не установлен. Попробуем PyPDF2...") return None except Exception as e: print(f"Ошибка при извлечении текста (pymupdf): {e}") return None def extract_text_pypdf2(pdf_path): """Извлечение текста с помощью PyPDF2 (базовый вариант)""" try: import PyPDF2 print(f"Извлечение текста из {pdf_path} с помощью PyPDF2...") text_content = [] with open(pdf_path, 'rb') as file: pdf_reader = PyPDF2.PdfReader(file) total_pages = len(pdf_reader.pages) print(f"Всего страниц: {total_pages}") for i, page in enumerate(pdf_reader.pages, 1): text = page.extract_text() if text: text_content.append(f"\n{'='*80}\nСТРАНИЦА {i}\n{'='*80}\n\n{text}") print(f"Обработано страниц: {i}/{total_pages}", end='\r') print(f"\nИзвлечение завершено!") return '\n'.join(text_content) except ImportError: print("PyPDF2 не установлен.") return None except Exception as e: print(f"Ошибка при извлечении текста (PyPDF2): {e}") return None def extract_images_pymupdf(pdf_path, output_dir): """Извлечение изображений из PDF с помощью pymupdf""" try: import fitz # pymupdf print(f"\nИзвлечение изображений из {pdf_path}...") doc = fitz.open(pdf_path) total_pages = len(doc) images_dir = Path(output_dir) / "extracted_images" images_dir.mkdir(exist_ok=True) image_count = 0 for page_num in range(total_pages): page = doc[page_num] image_list = page.get_images() for img_index, img in enumerate(image_list): xref = img[0] base_image = doc.extract_image(xref) image_bytes = base_image["image"] image_ext = base_image["ext"] image_filename = f"page_{page_num + 1}_img_{img_index + 1}.{image_ext}" image_path = images_dir / image_filename with open(image_path, "wb") as img_file: img_file.write(image_bytes) image_count += 1 doc.close() print(f"Извлечено изображений: {image_count}") return images_dir except ImportError: print("pymupdf не установлен. Изображения не будут извлечены.") return None except Exception as e: print(f"Ошибка при извлечении изображений: {e}") return None def main(): # Получаем директорию, где находится скрипт script_dir = Path(__file__).parent.absolute() os.chdir(script_dir) # Получаем имя PDF файла из аргументов командной строки или используем первый найденный PDF if len(sys.argv) > 1: pdf_path = sys.argv[1] else: # Ищем первый PDF файл в текущей директории pdf_files = list(Path('.').glob('*.pdf')) if not pdf_files: print("Ошибка: не найден PDF файл!") print("Использование: python extract_pdf.py [путь_к_pdf_файлу]") return pdf_path = str(pdf_files[0]) print(f"Используется найденный PDF файл: {pdf_path}") if not os.path.exists(pdf_path): print(f"Ошибка: файл {pdf_path} не найден!") return # Определяем базовое имя файла для выходных файлов pdf_name = Path(pdf_path).stem # Пробуем извлечь текст разными методами text = None # Сначала пробуем pdfplumber (лучше для таблиц) text = extract_text_pdfplumber(pdf_path) # Если не получилось, пробуем pymupdf if not text: text = extract_text_pymupdf(pdf_path) # Если и это не сработало, пробуем PyPDF2 if not text: text = extract_text_pypdf2(pdf_path) if not text: print("\nОшибка: не удалось извлечь текст. Установите одну из библиотек:") print(" pip install pdfplumber") print(" pip install pymupdf") print(" pip install PyPDF2") return # Сохраняем текст output_txt = f"{pdf_name}_извлеченный_текст.txt" with open(output_txt, 'w', encoding='utf-8') as f: f.write(text) print(f"\nТекст сохранен в: {output_txt}") # Пробуем извлечь изображения images_dir = extract_images_pymupdf(pdf_path, ".") if images_dir: print(f"Изображения сохранены в: {images_dir}") # Также сохраняем в Markdown для удобства output_md = f"{pdf_name}_извлеченный_текст.md" md_content = f"# Извлеченный текст из {Path(pdf_path).name}\n\n{text}" with open(output_md, 'w', encoding='utf-8') as f: f.write(md_content) print(f"Текст также сохранен в Markdown: {output_md}") print("\nГотово! Файлы подготовлены для анализа.") if __name__ == "__main__": main()
Большой плюс скриптов: часть работы делает Python на вашем ноутбуке, а токены при этом не тратятся. Когда скрипт отработал так, как нужно: текст отдельно, картинки отдельно, я перешла к структурированию текста.
Шаг 3. Структурирование извлеченного текста
Дальше всё полностью зависит от ваших нужд и фантазии.
Если у вас постановки изначально чёткие и удобные, этот шаг можно пропустить.
Если же вам хочется пересобрать требования в другом виде или формате — ИИ вам в этом поможет.
Я лично опробовала два варианта:
Вариант А. Жёстко заданный промпт
Я сама задала в промте четкую структуру и ограничения: сначала описать компоненты фронтенда, внутри каждого компонента перечислить элементы, их описание, логику работы и валидацию, а в конце — все пользовательские сценарии.
Для нейросети это несложная задача. Главное, задать в промте финальную проверку результата: все ли требования учтены в итоговом файле, ничего ли не пропущено. Можно попросить ИИ сделать отчет: времени у него уйдёт немного, а пока модель составляет отчет, она часто сама замечает, если что-то забыла или упустила.
Вариант Б. «Свободный» эксперимент
Во втором случае я попросила ИИ переписать требования с учётом лучших практик системного и бизнес-анализа, при этом не придумывать ничего лишнего, а помечать по тексту, где не хватает информации. Так я познакомилась с форматом FURPS+. Такие требования читать максимально удобно и приятно, но это был просто эксперимент. Для себя я вынесла то, что нейросеткам не всегда нужно давать огромные промты и жесткие рамки, в определенных случаях они могут выдавать качественный результат, даже если вы описали задачу верхнеуровнево.
Шаг 4. Картинки после парсинга: от img_1 к смыслу и к обогащению ТЗ
После того как я распарсила и структурировала текст, я вернулась к моим изображениям, извлеченным из ТЗ. У меня оказалось несколько десятков макетов и диаграмм, но у всех были имена вроде img_1, img_2. Мне захотелось отсортировать их и дать осмысленные названия опять же силами ИИ.
Вариант 1. Python: сортировка, OCR и осмысленные имена файлов
Первый путь — без траты токенов на «переименование картинок».
С помощью Python-скрипта я сортировала извлечённые изображения: диаграммы и схемы складывала отдельно от прочих картинок. Для диаграмм подключала OCR — с изображения считывалось название, и файл пересохранялся уже с понятным именем. Например, вместо img_12.png на диске появлялось что-то вроде Диаграмма_редактирования_клиента.png.
Зачем это нужно? Не только для порядка в папке: когда дальше вы отдаёте картинку в чат с ИИ, проще ссылаться на артефакт и сверять его с текстом ТЗ.
Вариант 2. Vision в Cursor: макеты и пользовательские флоу
Второй путь — без Python, но с моделью с компьютерным зрением в Cursor.
Я передавала в чат макеты мобильного приложения, экспортированные из Figma. На выходе получала:
структурированное описание экрана — блоки, поля, кнопки, тексты, состояния;
и то, что мне зашло сильнее всего, — описание пользовательского флоу.
Флоу модель собирала сама: смотрела на серию экранов, опиралась на то, что видела, и на здравый смысл. На макетах часто есть мелкие элементы или полупрозрачный шрифт, которые я с первого взгляда пропускала, модель это всегда замечала. Полученные сценарии я всё равно проверяла самостоятельно: это черновик для контекста, а не финальное ТЗ.
Вариант 3. Диаграммы: от описания к тестовым сценариям
Третий путь опять же про диаграммы и схемы, но уже более детальный, поэтому его можно разделить на два шага:
Попросить ИИ проанализировать диаграмму, описать её текстом: сущности, связи, развилки, исключения, правила, которые логично вывести из схемы (с пометкой, что это интерпретация).
Сгенерировать сценарии — отдельным запросом попросить написать по диаграмме пользовательские или тестовые сценарии. Здесь уже работают правила из моей инструкции по диаграммам.
Что я вынесла из этих кейсов:
Сначала просим оформить черновой список всех веток и сценариев «простым текстом», потом уже конвертируем в нужный формат (Markdown, csv или любой другой формат).
На больших схемах (много развилок, десятки потенциальных путей) часто теряются детали. Надежнее разрезать схему на несколько более мелких фрагментов и попросить ИИ проанализировать как схему целиком, так и по частям. Тогда у него сложится общая картина и не будут упущены никакие детали.
В промпте стоит явно зафиксировать правила: переносить формулировки с диаграммы без искажений, не придумывать ветки, которых нет на схеме и в требованиях, а непонятные места помечать, например, (?).
На ревью нужно проверить: все ли ветки дошли до конечных состояний, не «оборвались» ли сценарии на стыке фрагментов, нет ли выдуманных проверок.
Для очень простых диаграмм (пара развилок, три–четыре сценария) быстрее разобрать схему вручную — использование ИИ окупается, когда веток много.
Шаг 5. Дообогащение текстовых требований
Когда у вас уже есть и структурированный текст, и текстовые описания макетов и диаграмм, последним шагом попросить ИИ дообогатить требования, т.е. встроить новые данные в нужные разделы, не переписывая уже согласованный смысл и не удаляя исходные формулировки без причины. Полезно попросить ИИ оставить отметку о том, что блок основан на визуальном анализе макета или диаграммы.
Итог шага 4: на руках максимально полные требования в удобном формате — с ними может работать и нейросеть, и человек.
Ревью результатов
И в простом, и в сложном сценарии после участия ИИ и скриптов нужна проверка человеком:
совпадает ли извлечённый текст с исходным PDF;
не «поплыла» ли структура при пересборке;
корректны ли имена и содержание диаграмм;
не противоречит ли текст, полученный с макетов, основному ТЗ;
если по диаграмме генерировались сценарии — покрыты ли все ветки, нет ли лишних.
Этап ревью — самая важная часть работы с ИИ-инструментами, которую нельзя пропускать.
И что в итоге?
Контекст — это фундамент всей вашей работы с ИИ. Без полного и актуального контекста даже хороший промпт даст слабый результат. Мы очень часто забываем актуализировать требования, потому что большую часть информации держим у себя в голове. Но при работе с ИИ такой подход не прокатит - если вы хотите быстрых и качественных результатов, придется привести документацию в порядок. Но в конечном итоге, это будет плюсом для всей команды.
