LLM помогает составить тест-план: как увидеть непокрытые требования

Перед релизом аналитик передал требования, а QA уже написал десятки тестов. LLM предлагает ещё один внушительный тест-план, но остаётся практический вопрос: проверен ли запрет редактирования закрытого заказа? Количество пунктов в плане этого не показывает. Полезнее собрать связь между требованиями, нужными классами проверок и конкретными тестами.

Модель помогает читать требования, предлагать граничные случаи и сопоставлять тесты с формулировками. Инженер определяет, что именно требуется проверить. Затем простой расчёт покажет пробелы и даст очередь работы. Такой процесс дополняет существующий набор тестов: команде не нужно заново генерировать весь план при каждом изменении документа.

Сделайте ожидания явными

У требования должны быть ID и список обязательных видов проверки. Для запрета редактирования закрытого заказа нужны как минимум успешное изменение открытого заказа и отказ для закрытого. Для ограничения количества товара нужны допустимое значение и граница. Набор классов зависит от требования; универсальный список из десятка категорий создаст множество бессмысленных пробелов.

Сохраните у теста ID требования, класс проверки и статус экспертной проверки связи. Модель может предложить соответствие, которое выглядит правдоподобно по названию. Перед включением в покрытие QA читает шаги, проверяемое условие и ожидаемый результат. Связь «тест упоминает заказ» недостаточна, чтобы закрыть требование о запрете изменения.

Соберите матрицу и очередь

Код ниже принимает небольшой реестр требований и тестов. Неутверждённые предложения модели сохраняются в отдельном списке и не закрывают пробел. Утверждённые связи группируются по требованию и виду проверки. Если тест ссылается на несуществующий пункт или неизвестный класс, скрипт завершится с ошибкой: такую связь нужно исправить в реестре.

Пример не запускает тесты приложения и не измеряет их результат. Он отвечает на другой рабочий вопрос: есть ли проверенные сценарии для всех обязательных классов. Статус прохождения теста стоит добавить отдельным измерением после соединения с результатами CI. Иначе наличие сценария легко перепутать с его успешным выполнением.

requirements = {
    "R-order": {"positive", "negative"},
    "R-quantity": {"positive", "boundary"}}
tests = [
    {"id":"T1", "requirement":"R-order", "kind":"positive", "reviewed":True},
    {"id":"T2", "requirement":"R-order", "kind":"negative", "reviewed":False},
    {"id":"T3", "requirement":"R-quantity", "kind":"positive", "reviewed":True},
    {"id":"T4", "requirement":"R-quantity", "kind":"boundary", "reviewed":True}]
covered = {rid:set() for rid in requirements}
pending = []
seen = set()
for test in tests:
    if test["id"] in seen:
        raise ValueError("Duplicate test ID")
    seen.add(test["id"])
    rid, kind = test["requirement"], test["kind"]
    if rid not in requirements or kind not in requirements[rid]:
        raise ValueError("Invalid traceability link")
    if test["reviewed"]:
        covered[rid].add(kind)
    else:
        pending.append(test["id"])
gaps = {rid:sorted(required-covered[rid])
        for rid, required in requirements.items() if required-covered[rid]}
slots = sum(len(kinds) for kinds in requirements.values())
filled = sum(len(kinds) for kinds in covered.values())
assert gaps == {"R-order":["negative"]}
assert pending == ["T2"]
assert (filled, slots) == (3, 4)
print({"covered_slots":filled, "required_slots":slots, "gaps":gaps, "review_queue":pending})

Попросите модель предложить недостающий сценарий

Исходный пункт R-order: «Разрешено менять открытый заказ; закрытый заказ доступен только для чтения». Пользователь QA: «Предложи негативный сценарий для R-order, позитивный уже есть». К запросу добавьте существующий T1 и найденный пробел negative. Модель получает точную незакрытую ячейку, а не задачу написать тестирование всего продукта.

Верни JSON с test_id, requirement_id, kind, preconditions, steps, expected. Для R-order / negative проверь попытку изменить закрытый заказ через тот же интерфейс, через который изменение реально доступно. Опиши наблюдаемое состояние после отказа. Не добавляй новые продуктовые правила. Не ставь reviewed=true: связь подтверждает QA.

Полезный expected включает отказ в изменении и сохранение прежних значений заказа. Просто скрыть кнопку недостаточно, если сценарий проверяет API. QA читает предложение и присваивает ему T2; до проверки связь остаётся reviewed=false. Затем матрица показывает, что предложение существует, но обязательная ячейка ещё не принята.

Как использовать результат на планировании

Результат показывает три закрытые ячейки из четырёх и пробел negative у R-order. Первый кандидат на работу — T2: проверить, действительно ли его шаги запрещают изменение закрытого заказа. После экспертного подтверждения связь закроет ячейку. Если тест проверяет только скрытую кнопку в интерфейсе, для API-запрета понадобится другой сценарий.

Показатель 3 из 4 относится к заданным классам сценариев. Он не означает, что приложение протестировано на 75 процентов: здесь не учитываются все входы, комбинации состояний и реализация проверок. В отчёте показывайте сами незакрытые пары и их важность. Четыре однотипных позитивных теста не компенсируют отсутствие проверки обязательного запрета.

Что передать модели следующим запросом

Передавайте конкретный пробел, исходный пункт и уже существующие тесты для него. Просите предложить шаги и ожидаемый результат, сохраняя requirement_id. Это сокращает повторяющиеся предложения и направляет генерацию на реальную незавершённую работу. При изменении требования пересматривайте его связи: старый тест может продолжать проходить, проверяя уже отменённое поведение.

Встройте предложения тестов в работу QA

Следующий шаг — автоматизировать предложения тестов и встроить проверку в рабочий интерфейс QA. На курсе вы соберёте LLM-приложение с инструментами, API и веб-интерфейсом, освоите версии промптов и оценку качества. Эти части помогут сравнивать инструкции на реальных требованиях и выпускать изменения, сохраняя понятную трассу от исходного пункта до предложенного сценария. Откройте программу платного курса «LangChain 1.0.x: c нуля до продакшн LLM-приложений».