Аннотация
Создание тест-кейсов на основе требований — важная, но трудоёмкая часть системного тестирования. В статье рассматривается, насколько эффективно с этой задачей на данный момент справляется большая языковая модель ChatGPT-4 Turbo. Для эксперимента использовались пять проектов с реальными SRS-документами, включающими функциональные и нефункциональные требования. С помощью цепочки промптов модель генерировала тест-кейсы для каждого юзкейса, а оценку качества проводили сами разработчики.
Результаты показали: 87% кейсов оказались валидными, причём 15% из них ранее вовсе не учитывались при ручном тестировании. Кроме того, модель помогла выявить избыточные проверки, часть из которых разработчики пропустили. Исследование демонстрирует потенциал LLM как инструмента поддержки в тест-дизайне — для повышения полноты покрытия и оптимизации тестовых наборов.
Введение
Спецификация требований к программному обеспечению (SRS) — это документ, который описывает функциональные и нефункциональные требования к программному обеспечению. Функциональные требования описывают поведение системы в конкретных условиях, часто в форме сценариев использования (юзкейсов). Юзкейс — это сценарий использования программного обеспечения, перечисляющий шаги событий, которые обычно определяют взаимодействие между ролью пользователя и системой для выполнения требования. Системное тестирование включает в себя валидирование разработанного программного обеспечения на соответствие этим требованиям, чтобы убедиться в его правильности и полноте с использованием набора тест-кейсов.
Эффективность любого тестирования зависит от качества тест-кейсов. Разработка тест-кейсов включает в себя определение сценариев, входных данных и ожидаемых результатов. Например, генерация тест-кейсов для страницы входа будет включать шаги для ввода правильных учётных данных и успешного входа, а также шаги для ввода неверных учётных данных и получения сообщений об ошибках.
Разработка тест-кейсов — это важная задача, но она может быть трудоёмкой и подверженной ошибкам при ручном выполнении. Это требует тщательного понимания документа SRS и разработки тест-кейсов для покрытия различных сценариев, включая крайние или исключительные случаи. Этот трудоёмкий процесс может привести к пропуску важных тест-кейсов или наличию избыточных тестов.
Большие языковые модели (LLM), такие как GPT от OpenAI, продемонстрировали перспективы в задачах понимания и генерации естественного языка. Использование LLM для генерации тест-кейсов на основе документов SRS может потенциально автоматизировать и ускорить этот процесс, облегчая работу инженеров-программистов, снижая усилия на создание тест-кейсов и улучшая их качество.
Наше исследование направлено на понимание эффективности использования LLM для генерации тест-кейсов.
Наши исследовательские вопросы:
RQ1: Насколько эффективны большие языковые модели (LLM) в генерации всесторонних и валидных тест-кейсов непосредственно на основе документов спецификации требований к программному обеспечению (SRS)?
RQ2: Какова доля сгенерированных LLM тест-кейсов, которые являются валидными, но ранее были упущены разработчиками, и какую ценность эти тест-кейсы могут добавить в части снижения усилий разработчиков и улучшения покрытия тестами?
RQ3: В какой степени LLM могут выявлять избыточные тест-кейсы в тестовом наборе, и насколько точно эти выявления соответствуют подтвержденным избыточностям, определённым разработчиками?
2. Методы исследования
В этом разделе мы описываем характеристики нашего набора данных и объясняем подход, который применяется для разработки эффективного промпта к ChatGPT. Затем разработанный промпт используется для генерации тест-кейсов на основе требований, используя ChatGPT. Мы также обсудим метрики, которые использовались для оценки качества и эффективности сгенерированных тест-кейсов.
2.1 Набор данных: проекты, использованные в исследовании
Мы использовали набор данных, состоящий из пяти документов SRS, полученных из студенческих инженерных проектов. Эти проекты были разработаны для реальных клиентов, реализованы и протестированы. Каждый документ SRS включает функциональные и нефункциональные требования, с функциональностью, заданной через сценарии использования.
Проекты отличались по размеру, от 7 000 до 12 000 строк кода, с размером команд от 3 до 4 человек. Каждый документ SRS содержал от 11 до 29 юзкейсов, охватывающих от 3 до 4 различных типов пользователей. Технологический стек, применявшийся в этих проектах, обычно включал HTML и ReactJS для фронтенда, Django и NodeJS для бэкенда, а также базы данных PostgreSQL, MySQL, MongoDB. В Таблице 1 представлена сводка характеристик SRS для каждого проекта:
Портал программы студенческого менторства (SMP): Проект, направленный на улучшение коммуникации и управления в рамках программы менторства в университете. Платформа облегчает взаимодействие между администраторами, наставниками и студентами.
Портал больничных: Создан для упрощения процесса подачи и утверждения больничных студентов бакалавриата и магистратуры. Портал взаимодействует с врачами и администраторами, поддерживая базу данных о больничных.
Платформа управления событиями студенческих клубов: Платформа для организации и управления мероприятиями, проводимыми студенческими клубами. Позволяет клубам предлагать мероприятия на утверждение, а студентам — записываться на них. Каждый клуб имеет свою страницу для управления.
Портал управления Ph.D. программой: Платформа для улучшения управления академическими процессами докторских программ. Включает функции для оценки диссертаций, экзаменов, ежегодных отзывов и стипендий.
Вебсайт для изменений: Платформа, поддерживающая инициативных молодых людей, стремящихся к позитивным изменениям. Вебсайт предоставляет инструменты и ресурсы для реализации изменений и поддерживает сбор средств через пожертвования.
2.2 Разработка промпта
Для генерации эффективных тест-кейсов первым шагом было разработать подход к формированию промптов, который обеспечивал бы генерацию лучших тестов-кейсов для заданной SRS. Опираясь на рекомендации по шаблонам промптов, таким как роль промпта, использование разделителей, указание форматов вывода и предоставление чётких описаний задач, мы экспериментировали с двумя подходами к промптам:
Подход 1 — Один промпт. В рамках этого подхода мы формировали один промпт, состоящий из (1) всей SRS, (2) инструкций по генерации тест-кейсов с указанным форматом вывода для них. Наши эксперименты показали, что сгенерированные тест-кейсы были недостаточно детализированными, что может указывать на то, что промпт был слишком длинным, а задача — слишком сложной, чтобы выполнить её за один запрос. В среднем генерировалось 2-3 тест-кейса для каждого юзкейса.
Подход 2 — Цепочка запросов. В этом подходе мы сначала предоставляли SRS в начальном промпте. Затем следовали индивидуальные промпты для каждого юзкейса, направляющие LLM на генерацию тест-кейсов в заданном формате. Мы заметили значительное увеличение среднего числа сгенерированных тест-кейсов, примерно до 9-11 тест-кейсов на каждый сценарий.
В Таблице 2 приведено сравнение тест-кейсов, сгенерированных двумя подходами.
Исходя из этих экспериментов, можно утверждать, что цепочка запросов с первым промптом, содержащим SRS, а последующими промптами на генерацию тест-кейсов для каждого юзкейса, даёт лучшие тест-кейсы.
Для оценки качества сгенерированных тест-кейсов мы выбрали двухступенчатый подход к цепочке запросов:
(1) Ознакомление. Инструктируем LLM ознакомиться с предоставленным документом SRS.
Промпт 1: Ты — инженер-программист. Ты находишься на первом этапе жизненного цикла разработки ПО, и у тебя есть документ SRS для портала отслеживания больничных. Текст, приведённый ниже в тройных кавычках, является Спецификацией требований для этого портала. Прочитай его, и обращайся к нему для ответа на вопросы в следующих запросах. SRS: ”’...”’
(2) Генерация тест-кейсов. Далее задаём LLM запрос на генерацию тест-кейсов для конкретных юзкейсов, указанных в SRS.
Промпт 2: Используя SRS для портала отслеживния больничных, который был предоставлен ранее, создай все возможные тест-кейсы, используя метод на основе спецификаций, для каждого возможного юзкейса в табличном формате с следующими 4 столбцами: функциональность/условие для тестирования, входное действие/входные значения, ожидаемый результат/поведение и дополнительные комментарии. Кейс использования: ”’...”’
2.3 Генерация тест-кейсов
Мы использовали модель ChatGPT-4 Turbo с подходом формирования промптов №2 для создания тест-кейсов из пяти документов SRS. Сначала ChatGPT ознакомился с каждым документом, а затем генерировал тест-кейсы для каждого юзкейса в стандартизированном табличном формате, где детализировались условия, входные действия, ожидаемые результаты и комментарии. Этот процесс упрощал анализ.
Для каждого SRS с 12 юзкейками мы отправляли 13 промптов: первый был для ознакомления с документом, а остальные 12 — для генерации тест-кейсов для каждого юзкейса. Все тесты стандартизировались с одинаковыми настройками температуры и использовалась одна и та же версия модели (GPT-4 Turbo).
Для каждого SRS мы многократно применяли подход, генерируя кумулятивный тестовый набор из каждого прогона. Это продолжалось до тех пор, пока не прекращалось увеличение набора тест-кейсов, что означало отсутствие новых уникальных тестов. Например, на первом прогоне было сгенерировано 5 уникальных тестов, на втором — 7, из которых 4 совпали с первым набором, в итоге получилось 8 уникальных тестов. Этот процесс продолжался, пока размер объединённого набора не стал стабильным, подтверждая, что новые тесты больше не генерировались.
Примеры таких тестов, сгенерированных с помощью описанного подхода, приведены в Таблице 3.
Функциональность/Условие для тестирования | Вводимые действия/Вводимые значения | Ожидаемый вывод/Поведение | Дополнительные комментарии |
Пользователь с правильными учетными данными может войти | Введите правильное имя пользователя и пароль | Успешный вход, доступ в портал предоставлен | Проверьте, что пользователи с правильными учетными данными могут войти успешно |
Пользователь с неверными учетными данными не может войти | Введите неверное имя пользователя или пароль | Неуспешный вход, доступ в портал отклонен | Проверьте, что пользователи с неверными учетными данными не могут войти |
Двухфакторная аутентификация | Включите двухфакторную аутентификацию и введите правильный код аутентификации | Успешный вход, доступ в портал предоставлен | Проверьте, что двухфакторная аутентификация работает как ожидается |
2.4 Качественная оценка тест-кейсов
Для оценки качества и эффективности тест-кейсов, сгенерированных ChatGPT, была проведена качественная оценка с участием разработчиков, создававших SRS документы. Оценка сосредоточилась на определении полезности, релевантности и полноты тестов в контексте отражения предполагаемых функциональных требований. Важно было, чтобы тест-кейсы оценивались разработчиками, обладающими глубоким пониманием требований и функциональных спецификаций своих проектов.
Сбор обратной связи. Для каждого юзкейса разработчиков попросили проверить тест-кейсы, сгенерированные ChatGPT, и дать обратную связь для каждого тест-кейса, используя критерии:
Валидность. Тест-кейс считается валидным, если он подходит для проверки функциональности юзкейса.
Избыточность. Тест-кейс является избыточным, если условие, которое он проверяет, пересекается с тем, что уже охвачено другими тест-кейсами, что приводит к ненужному тестированию тех же участков кода и функций.
Не реализованный, но валидный. Тест-кейсы, которые не были реализованы в самом проекте, но являются валидными и не избыточными. Эта обратная связь была важна для понимания потенциальных пробелов в оригинальном покрытии тестами и того, как LLM могут помочь их преодолеть.
Неактуальность. Тесты с нерелевантными условиями, которые не могут быть использованы для тестирования функциональности.
Пропущенные тест-кейсы. В конце командам было предложено указать, какие тест-кейсы LLM не сгенерировал, но которые они использовали в своем тестировании. Этот аспект был важен для выявления областей, в которых понимание ChatGPT могло быть неполным или неточным.
2.5 Проверка избыточных тест-кейсов, выявленных ChatGPT
Избыточные тест-кейсы нежелательны, так как они приводят к дублированию усилий, увеличению времени выполнения и усложнению поддержки тестов. Для повышения эффективности и упрощения процесса тестирования важно устранить избыточность, позволяя разработчикам сосредоточиться на значимых тестах.
Для этого мы расширили методологию, включив в неё идентификацию избыточных тестов среди сгенерированных ChatGPT. Анализ избыточности проводился на уровне всей SRS, поскольку выявление её только на уровне юзкейсов не даёт значимых результатов из-за перекрытия между юзкейсами. Мы попросили ChatGPT явно пометить тесты, которые могут пересекаться с уже существующими в наборе. В то же время разработчики проверяли тесты и помечали избыточные с их точки зрения.
После этого мы сравнили два набора избыточных тестов — помеченные ChatGPT и разработчиками. Для пересекающихся случаев избыточности разработчики проверили выводы ChatGPT, классифицируя их как валидные или ложные срабатывания. Также ChatGPT выявил новые избыточные тесты, которые были упущены разработчиками. Этот процесс дал нам понимание о том, как эффективно LLM могут помогать в выявлении избыточности и улучшении рабочих процессов, ускоряя обнаружение неэффективных тестов.
3. Результаты
Ответ на RQ1: Насколько эффективны большие языковые модели (LLM) в генерации полных и валидных тест-кейсов непосредственно на основе документов Спецификации требований к ПО (SRS)?
Мы обнаружили, что в среднем ChatGPT генерировал 10–11 тест-кейсов на каждый юзкейс при использовании подхода с цепочкой промптов в два этапа. По результатам обратной связи с разработчиками, 72,5% сгенерированных тестов были валидными и использовались в рабочем процессе. Ещё 15,2% тестов ранее не рассматривались, но оказались валидными условиями тестирования. В итоге 87,7% тестов, сгенерированных LLM, были признаны валидными.
Оставшиеся тесты делились на следующие категории: 9,7% были признаны неактуальными из-за нерелевантности или изменений в системных требованиях, а также из-за избыточных проверок безопасности для защищённой внутренней сети. ChatGPT имеет ограниченное понимание поведения системы, опираясь лишь на предоставленную SRS, что привело к пропуску некоторых условий тестирования. Однако такие случаи были редкими — всего 2-3 теста на SRS. Дополнительно 2,6% тестов были признаны избыточными.
Избыточные тесты выявлялись, когда ChatGPT не мог определить перекрывающиеся шаги (функции) между несколькими юзкейсами. Например, в юзкейсе для портала больничных шаги для двух ролей (врача и администратора) пересекались, но LLM не учёл, что это общее требование для обеих ролей, и сгенерировал один и тот же тест дважды. Также генерировались избыточные тесты для валидации ввода/обработки ошибок, которые можно было бы объединить в один тест. Эти избыточности были выявлены разработчиками на первом наборе тестов, сгенерированном ChatGPT. Позднее мы специально попросили LLM идентифицировать и проверять избыточные тесты.
Результаты, представленные в таблице №4, демонстрируют, что LLM генерирует большинство валидных тестов, а лишь небольшая часть тестов попадает в категории не реализованных, неприменимых или избыточных.
RQ2: Какова доля тест-кейсов, сгенерированных LLM, которые являются валидными, но ранее упущенными разработчиками, и какую ценность эти тест-кейсы добавляют в плане снижения усилий разработчиков и улучшения тестового покрытия?
Среди всех валидных тест-кейсов, сгенерированных LLM, 15,2% были классифицированы разработчиками как «не реализованные, но действительные». Эти тест-кейсы охватывали сценарии, которые были либо исключены из приоритетных, либо не были рассмотрены разработчиками в процессе первоначального тестирования, что делает их валидными. Конкретно эти новые тест-кейсы способствовали:
Улучшению пользовательского опыта, таким как напоминания, механизмы обратной связи с пользователем и восстановление истории версий.
Функциям доступности, таким как совместимость с экранными ридерами и поддержка голосового ввода.
Усилению безопасности, включая многофакторную аутентификацию и проверки валидации.
Разработчики объяснили отсутствие этих тестов ограничениями по времени или низким приоритетом данных функций на этапе начального тестирования. Эти добавления заполнили пробелы в тестовом покрытии, позволив протестировать критичные, но ранее упущенные аспекты функциональности. Разработчики признали, что эти тест-кейсы добавили ценность, выявив крайние случаи и проектные моменты, которые оказались важными для улучшения общего качества программного обеспечения.
RQ 3: Насколько эффективно LLM могут выявлять избыточные тест-кейсы в тестовом наборе, и насколько точно эти выявления соответствуют избыточностям, подтверждённым разработчиками?
ChatGPT выявил в среднем 12,82% избыточных тест-кейсов от общего числа для каждого SRS, в то время как разработчики отметили 8,3% избыточных тестов. После проверки были выявлены следующие закономерности:
47,19% избыточных тестов, выявленных ChatGPT, также были помечены разработчиками, что указывает на значительное совпадение и согласование между двумя наборами.
22,65% избыточных тест-кейсов, выявленных ChatGPT, были новыми, то есть они не были помечены разработчиками изначально, но позже были подтверждены как валидные избыточные тест-кейсы.
30,16% избыточных тестов, выявленных ChatGPT, оказались ложными положительными результатами, то есть они были помечены как избыточные, но на самом деле были необходимы для обеспечения полного тестового покрытия.
Этот анализ демонстрирует, что ChatGPT эффективно помогает разработчикам в выявлении избыточных тестов, а также в обнаружении избыточностей, которые могли быть упущены. Однако относительно высокая доля ложных срабатываний указывает на необходимость улучшения модели в плане понимания контекста и пересекающихся функциональностей. Например, ChatGPT иногда ошибочно помечал тесты с похожей функциональностью для разных ролей пользователей (например, пересылка запросов на больничный как врачом, так и администратором) как избыточные, хотя эти тесты необходимы для проверки различных ролей.
4. Похожие работы
Традиционные подходы. Генерация тест-кейсов из документов SRS обычно осуществляется с помощью ручных методов, подходов на основе ключевых слов, а также моделей и других более сложных техник. Однако эти методы часто сталкиваются с проблемами, такими как ограниченная масштабируемость и субъективность.
Недавние достижения в LLM. Появление больших языковых моделей (LLM), таких как ChatGPT, открыло новые возможности для автоматической генерации тест-кейсов. LLM показали свою способность понимать естественный язык и генерировать код, что можно использовать для преобразования текстовых требований в тестовые сценарии.
Промпт-инжиниринг. Промпт-инжиниринг играет ключевую роль в получении эффективных и точных ответов от LLM. Несколько исследований описали шаблоны промптов и использовали такие методы, как роль-промптинг, цепочка промптов и цепочка мыслей, для оптимизации работы LLM. Мы применили эти подходы в наших экспериментах, уточняя промпты для нахождения наиболее эффективных решений для нашей задачи.
LLM в разработке программного обеспечения. Лин и др. исследовали использование LLM для генерации кода в процессе разработки программного обеспечения. Их исследование подчеркивает важность тонкой настройки и дообучения LLM на специфичных данных для создания надёжных конвейеров генерации кода, использующих семантическое понимание.
Автоматическая генерация пользовательских историй. Рахман и др. изучали автоматическую генерацию пользовательских историй из текстовых требований с помощью методов обработки естественного языка. Исследование получило положительные отзывы от разработчиков, использующих опросник RUST, что подтверждает потенциал LLM в этой области.
Генерация тест-кейсов с использованием LLM. Несколько исследований фокусируются на применении LLM для генерации входных данных для системных тестов и автоматизации различных этапов тестирования программного обеспечения. Ван и др. провели обширный обзор использования LLM в тестировании ПО. Матур и др. предложили использование T5 и GPT-3 для автоматической генерации тест-кейсов. Луу и др. сообщили о применении LLM, таких как ChatGPT, для метаморфного тестирования. Ю и др. исследовали проблемы, возможности и вызовы использования LLM для генерации и миграции тестовых сценариев.
LLM для создания модульных тестов. LLM также применялись для создания модульных тестов на основе исходного кода. Исследования Сапожникова и др. и Эль Хаджи и др. показали полезность LLM для генерации читаемых и комплексных модульных тестов. Также есть исследования, которые изучают, как LLM могут генерировать модульные тесты, помогающие программистам создавать более читаемые тесты, охватывающие различные пограничные случаи.
Основной вклад. Хотя существующие исследования рассматривали разные аспекты применения LLM в тестировании ПО, наша работа отличается тем, что она предоставляет целенаправленную и всестороннюю оценку сгенерированных тест-кейсов на основе документов SRS. Мы включаем обратную связь от разработчиков, которые создавали и реализовывали SRS, классифицируя сгенерированные тесты в пять категорий: (1) валидные тесты, (2) избыточные условия, (3) не реализованные, но валидные тесты, (4) не применимо, (5) пропущенные тесты (подробности в разделах 2 и 3).
5. Заключение и будущее направление работы
Разработка тест-кейсов на основе требований для системного тестирования — это важная задача, напрямую влияющая на качество конечного программного обеспечения. Ручное создание таких тестов может быть трудозатратным и подверженным ошибкам. В этой статье мы представляем результаты исследования по использованию больших языковых моделей (LLM) для автоматической генерации тест-кейсов из документов SRS.
В нашем эксперименте мы использовали пять завершённых программных проектов, для которых были доступны документы SRS. Получение документации требований в реальных инженерных проектах представляет собой сложную задачу из-за их высокой конфиденциальности, а также необходимости проведения интервью и сбора обратной связи от команд разработчиков на каждом этапе эксперимента, включая категоризацию результатов, сгенерированных LLM. Мы осознаём, что наш набор данных мал и может не быть достаточно репрезентативным для обоснованных обобщений, но эта работа представляет собой первый шаг в исследовании потенциала генерации тест-кейсов на основе требований. Кроме того, она закладывает основу для дальнейших улучшений, направленных на повышение надёжности таких тестов.
Мы использовали двухступенчатый подход к запросам, чтобы направить LLM на генерацию тест-кейсов. На первом этапе LLM знакомится с документом SRS, а на втором этапе с помощью промптов мы просим его генерировать тест-кейсы для каждого юзкейса. Этот метод оказался более эффективным, чем подход, при котором LLM генерирует тест-кейсы для всей SRS одновременно.
Наши эксперименты показали, что LLM могут генерировать валидные тест-кейсы, многие из которых были упущены разработчиками. Однако, сгенерированные тесты содержат избыточные условия, которые могут быть уменьшены с помощью более целенаправленных запросов. Анализ избыточности подчеркнул, что LLM помогают не только выявлять упущенные, но и избыточные условия. Однако ложные срабатывания в избыточных тестах могут снизить эффективность тестов.
Хотя инструменты ИИ ещё не могут полностью заменить тестирование, они значительно уменьшают нагрузку на разработчиков. В будущем мы планируем расширить исследование, сравнив несколько LLM и использовав более обширные данные SRS. Будущая работа будет направлена на улучшение точности LLM в обнаружении избыточности, возможно через дообучение на данных программной инженерии или добавление контекста на уровне системы. Также включение архитектурных документов может повысить надёжность генерации тестов, улучшив понимание системы.
В мире разработки и тестирования важно не только понимать теоретические подходы, но и уметь применять их на практике с использованием актуальных инструментов. Если вы хотите улучшить свои навыки в области тестирования, автоматизации и работы с современными технологиями, вам подойдут следующие открытые уроки:
Gatling и K6: тесты для gRPC, WebSocket и HTTP — 29 апреля, 20:00
Альтернативные тест раннеры. Использование stestr в API и юнит тестировании — 30 апреля, 20:00
Больше актуальных навыков по тестированию вы можете получить в рамках практических онлайн-курсов от экспертов отрасли.