1LLM обеспечивает комплексную автоматизацию тестирования.

1.1 Видение: автономное вождение уровня L4/5.

Деятельность по тестированию в основном вращается вокруг разработки тестов, написания вариантов использования, выполнения, анализа результатов и дополнительной проверки. В прошлом автоматизированное тестирование часто ограничивалось автоматизацией выполнения вариантов использования и по-прежнему требовало написания автоматических вариантов использования вручную, не говоря уже об анализе результатов выполнения вариантов использования и обслуживании вариантов использования и сред. Представьте себе возможность реализации сквозной автоматизации всей деятельности по тестированию в сочетании с AI4SE, сформировав следующие 4 этапа и 8 ключевых задач, как показано на рисунке ниже.

Автор рекомендует начинать с модульного тестирования - тестирования интерфейсов - автоматизации всей деятельности по тестированию, начиная с раннего возраста, и продолжать расширять расширение кольца автоматизации в соответствии с методом PDCA для постепенной реализации сквозной автоматизации. деятельности по тестированию.

2 Интерпретация восьми ключевых задач четырех этапов

2.1 Автоматизация написания тест-кейсов

В мире боевых искусств скорость является ключом к успеху. Обеспечение быстрой обратной связи по качеству тестирования посредством автоматизации может решить большинство проблем тестирования. Автоматизированное тестирование в традиционном смысле — это на самом деле автоматизированное выполнение тестовых примеров. Типичная проблема неудачной реализации такого автоматизированного теста — «слишком поздно писать автоматизированные тесты». Из-за этого типа автоматизированной реализации предел ввода и вывода представляет собой линейную зависимость, то есть, если вы инвестируете одного человека в посадку рассады риса, вы получите один день результатов, если вы инвестируете двух человек, вы получите результат; результаты двух человек и дней. Даже по мере расширения масштабов инвестиций негативные последствия синергии снизят норму прибыли от такого подхода. Учитывая степень автоматизации при написании тест-кейсов, команда может быстрее выбраться из трясины инвестиций в автоматизированное тестирование, быстрее достичь точки безубыточности и сформировать петлю положительной обратной связи по автоматизированному тестированию. Вот почему LLM впервые использовался при (автоматическом) написании тестовых примеров.

[Модульное тестирование] В настоящее время эта часть автоматизации в основном используется для автоматического создания модульных тестовых случаев. Согласно теории PDCA, задачи этой работы ясны, легко проверяемы и могут быть быстро возвращены. Это воплощение сквозной автоматизации тестирования. Текущее решение в этой части заключается в использовании нескольких агентов для реализации генерации-проверки-восстановления-фильтрации тестовых примеров посредством нескольких раундов диалога для улучшения эффекта генерации. Говорят, что предстоящая новая версия плагина IDE от Alibaba Tongyi Lingma предоставит дополнительное решение. Конечно, команда авторов уже реализовала это решение. Хотя это решение полезно для создания эффектов, оно также требует времени. Генерация отдельных тестовых примеров в IDE на самом деле является задачей, зависящей от времени, и это основная проблема, которую предстоит решить позже. Конечно, основное внимание уделяется тому, как повысить уровень успеха первого поколения с помощью различных методов.

[Ручные тестовые примеры] Некоторые команды, такие как Byte, Huawei, ICBC и т. д., изучают создание (ручных) тестовых примеров на основе LLM. В настоящее время эффект создания контрольных точек достиг возможности (аутсорсинга) инженеров по тестированию среднего уровня. Конечно, ядро ​​всего решения по-прежнему существует: в качестве базы знаний используются исторические PRD и пары вариантов использования. Если вы используете в качестве входных данных только проверенный PRD, его будет практически невозможно использовать в производстве.

[Автоматизированные тестовые сценарии] На более высоких уровнях, таких как автоматическое создание тестовых сценариев интерфейса, автор также обратил внимание на команду Huawei, которая также использует пары сценариев «шаги-код» сценария использования в качестве базы знаний, когда тестировщики нацелены на. определенный PRD. После написания шагов теста для тестового примера он автоматически транслируется в соответствующий тестовый сценарий через LLM. Исходя из этого, автор не может не думать, что для команд, которые в истории внедряли такие практики автоматизации, как BDD/ATDD, на самом деле есть огромное сокровище.

Подводя краткий итог, можно сказать, что текущее решение для генерации модульных тестовых сценариев на основе LLM является зрелым, и последующей целью является увеличение скорости. Создание ручных тестовых сценариев и автоматизированных тестовых сценариев интерфейса/UI в значительной степени зависит от построения баз знаний, таких как база знаний требований-прецедентов, база знаний ручных сценариев использования-автоматизированных вариантов использования и т. д. Неожиданным открытием стало то, что у команды BDD/ATDD есть хорошие шансы добиться значительного прогресса.

2.2 Автоматизация выполнения тест-кейсов

Эта часть состоит из двух частей: выполнение варианта использования и подготовка среды.

Степень автоматизации тестовой среды определяет удобство подготовки теста, согласованность среды и повторяемость теста. Управление средой и данными — ключ к успешному внедрению автоматизированного тестирования. В то время как многие люди сосредотачиваются на поверхностных вопросах, таких как то, как и где писать тестовые примеры, например, на тестовой платформе, опытные водители сосредотачиваются на основных проблемах, таких как сравнительный анализ, обновление и обслуживание тестовой среды и тестовых данных, чтобы Убедиться, что команда может плавно выйти в море и не удариться напрямую о камни.

Быстрый вопрос для определения зрелости: какова отправная точка для выполнения набора автоматических тестовых сценариев? Чем ближе он к динамическому применению/инициализации, использованию и повторному использованию среды, тем выше зрелость?

В этой ссылке LLM не применяется напрямую, но посредством оркестровки конвейера LLM, тестовая среда, динамический сбор тестовых данных, инициирование и выполнение тестовых примеров и другие задачи могут быть организованы через модуль инструментов LLM, что делает его Полный комплексный драйвер LLM. Ключевая часть комплексной автоматизации тестирования.

Если кратко подвести итог, то эта часть связана не столько с возможностями приложения LLM, сколько с платформой DevOps организации и возможностями управления средой/данными.

2.3 Сбор и анализ результатов

После автоматизации посредством написания тест-кейсов создание вариантов использования больше не является узким местом, а затраты команды на получение автоматизированных тест-кейсов близки к 0. В этом случае пик нагрузки приходится на анализ результатов выполнения тестов. Как и другие тесты, автоматическое тестирование также имеет проблемы «ложных срабатываний» и «пропущенных отрицательных результатов».

Из-за огромного количества тестовых случаев, даже если существует небольшая вероятность ложного сбоя, будет значительное количество неудачных вариантов использования, требующих устранения неполадок вручную. Однако, поскольку это ложные неудачные варианты использования, результат устранения неполадок должен быть следующим. «марш смерти», и весь процесс неизбежно. Это стресс, но он только создает разочарование для команды. Поэтому в этом случае команде необходимо рассмотреть возможность внедрения автоматизированного анализа результатов тестирования и повысить уверенность в результатах определения «ложного провала (ложного положительного результата)». В конце концов, неправильная оценка «ложных сбоев» может напрямую привести к онлайн-дефектам.

В области эксплуатации и технического обслуживания концепция AIOPS была предложена очень рано, и анализ первопричин (RCA) является одним из основных сценариев. Группа эксплуатации и технического обслуживания использует различные алгоритмы искусственного интеллекта, чтобы попытаться быстро и точно обнаружить работу и события технического обслуживания и неисправности после их возникновения. Выполняйте анализ первопричин и даже внедряйте автоматические рекомендации/автоматическую реализацию решений. В эпоху LLM многие команды по эксплуатации и техническому обслуживанию также переключили свое внимание с традиционных алгоритмов искусственного интеллекта на LLM. Фактически, аналогичные возможности можно использовать для анализа результатов выполнения тестовых примеров.

На таких конференциях, как AIDD/QECON в 2024 году, команды Huawei и других компаний поделились своими случаями анализа первопричин неудачных вариантов использования. Этот тип решения на самом деле является расширением, основанным на точном тестировании. Например, во время выполнения определенного (автоматизированного) варианта использования, помимо сбора результатов выполнения варианта использования (пройден/не пройден), тестовая платформа должна также собирать

а) Журналы выполнения самого тестового примера

б) Журналы, генерируемые в тестируемом приложении во время выполнения тестового примера (требуется окрашивание трафика + наблюдаемая платформа)

В сочетании с базой знаний об основных причинах неудачного выполнения варианта использования, историческими записями выполнения и другими данными мы можем определить, соответствует ли успех/неуспех выполнения этого варианта использования ожиданиям и является ли это дефектом (истинно положительным) или ложный провал (ложноотрицательный).

С другой стороны, путем определения показателей завершения теста, таких как «требования/цепочка вызовов/покрытие строки кода», мы можем улучшить обнаружение «ложной корректности (пропущенного отрицательного результата)», то есть обнаружение пропущенных дефектов тестирования. и провести дополнительное тестирование. Это уже эффективное решение для выбора эффективных вариантов использования при создании сценариев модульного тестирования на основе LLM.

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

2.4 Отчеты о вариантах использования и дополнительное тестирование

Это последняя ссылка в PDCA. По результатам анализа варианты использования дополняются или исправляются.

Создание протоколов испытаний LLM в настоящее время является наиболее широко используемым приложением. На этой основе, оценив заранее установленный стандарт завершения (стандарт выхода из теста), выясните пробел, а затем проведите дополнительное тестирование, то есть войдите во второй раунд процесса автоматизации сквозного тестирования, а затем приблизьтесь к стандарту завершения. . Это направление дальнейших усилий.

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