CC BY
77
Автоматизированное создание тестового регрессионного набора на основе документации процесса тестирования программного
обеспечения
Мартюков A.C.
Московский институт электроники и математики Научно-исследовательского университета
«Высшая школа экономики», кафедра "Информационные технологии и автоматизированные системы"
Аннотация. В данной статье рассматривается автоматизированная система, позволяющая формировать наборы тестов для регрессионного тестирования на основе результатов автоматизированного тестирования программного обеспечения и входной документации, а так же создавать отчетную документацию по этому автоматизированному процессу тестирования.
Введение
Тестирование программного обеспечения является сейчас сложной задачей, требующей освоения множества дисциплин. Это связано с большим количеством видов тестирования, которые необходимо проводить: функциональное тестирование, нагрузочное тестирование(тестирование производительности, тестирование стабильности), тестирование удобства использования, тестирование интерфейса пользователя, тестирование локализации, тестирование совместимости (в данной классификации не рассматривается тестирование безопасности, так как обычно его выделяют в отдельный класс). Основным видом можно назвать функциональное тестирование. Это обусловлено тем, что функциональность является самой важной характеристикой качества программного обеспечения. Функциональность определяется, как способность программы выполнять все функции, которые обозначенные в ее спецификации и удовлетворяющее заданным потребностям пользователей. Поэтому функциональному тестированию уделяют наибольшее внимание.
При функциональном тестировании могут тестироваться новые элементы программы или элементы, которые уже тестировались ранее, но в них были внесены изменения (исправление ошибок, добавление новых функций и т.д.). Тестирование измененной версии программного обеспечения называется регрессионным тестированием. Регрессионное тестирование — вид тестирования программного обеспечения, который выполняется для проверки корректности работы функционала, который уже тестировался ранее. Это наиболее часто применяемый вид функционального тестирования, потому что:
• выпускаются новые версии продукта и их обновления;
• во многих компаниях применяется интеграционная разработка программного обеспечения и на каждой итерации необходимо проверить не только новые элементы и функции, но и уже протестированные ранее элементы на предмет не внесения в них ошибок.
Формирование регрессионного тестового набора
В регрессионном тестировании используются тесты, созданные при проведении предыдущего тестирования. Из этих тестов формируется новое множество тестов, которое направлено на тестирование только измененных или добавленных элементов
программы. Это формирование происходит на основе результатов предыдущего тестирования и информации об изменениях, не связанных с исправлением ошибок. Вся эта информация хранится в документации процесса тестирования.
Но анализ этих данных и создание документации для следующего тестирования отнимает много времени у тестировщика. Для решения этой проблемы предлагается автоматизировать процесс сбора необходимой информации по процессу тестирования, процесс формирования нового регрессионного тестового набора, а так же процесс создания отчетной документации по процессу тестирования.
Для автоматизации формирования нового множества тестов, которое будет использоваться в регрессионном тестировании, предлагается безопасный метод, основанный на входящей документации процесса тестирования.
Документирование процесса тестирования
При создании документации по процессу тестирования предлагается использовать структуру из стандарта IEEE 829. По этому стандарту она состоит из: test Plan;
test Design Specification; test Case Specification; test Procedure Specification; test Incident Report; test log;
test Summary Report.
Первые четыре документа представляют собой входную документацию. Из них берется вся необходимая информация для проведения тестирования и формирования отчетной документации. В отчетную документацию входят: test Incident Report, test log, test Summary Report. Ее формирование происходит на основе входных данных и данных, полученных в результате тестирования (рис.1):
Рис.1 Структура создания отчетной документации
За сбор необходимой информации в процессе тестирования отвечает модуль логирования. В нем реализованы две основные функции:
1. Screen_Shoter - эта функция позволяет сделать снимок экрана при возникновении ситуации, которая не описана в выполняемом тесте, и сохранить его для отчета;
2. Saver_log - эта функция собирает и сохраняет все данные (в нужном формате) в ходе выполнения тестов.
После завершения процесса тестирования все данные, собранные модулем логирования передаются в модуль создания документации. Там данные анализируются и создаются конечные документы по процессу тестирования: результаты выполнения тестов, отчет по инцидентам, конечный отчет.
Когда создана выходная документация, она передается в модуль формирования нового регрессионного тестового набора.
Формирование регрессионного тестового набора
Для формирования регрессионного тестового набора используются данные из входной документации, которые добавленные специально в стандартные документы. Работа по этому методу происходит следующим образом:
• вносятся изменения в документ Test Design Specification;
• после получения отчетной документации проводится ее анализ;
• на основе данных анализа создается файл, в котором находится множество тестов, которые необходимо выполнить для регрессионного тестирования;
• полученный файл передается вместе с входной документацией при следующем тестировании продукта.
Связи элементов программы в документе Test Design Specification указываются следующим образом:
• в документ добавляется еще один столбец с данными;
• в этом столбце указываются номера тестов, которые необходимых для выполнения при изменении элемента программы.
Возможна ситуация, когда один и тот же тест добавляется в регрессионное множество несколько раз (когда изменены несколько элементов для проверки которых необходим этот тест). Это влияет на его приоритет: чем больше раз встречается тест - тем выше его приоритет.
При использовании рассматриваемого метода может возникнуть проблема, связанная с тем, что при составлении документа Test Design Specification в нем могут быть указаны не все связи элементов. Для ее решения при составлении документа анализируются:
• код программы;
• технические риски тестирования, в которых описываются:
о связанные сущности;
о определенные проблемы при подобных изменениях;
о выявленные ранее проблемы, связанные с внесением изменений в данный функционал.
Анализ этих данных позволяет решить проблему формирования документов со связями элементов программы, а так же:
• исключает неполноту информации по программе;
• позволяет автоматизировать часть действий:
о отбор тестов для проверки элементов, в которых были найдены ошибки;
о отбор связанных тестов;
о отбор тестов, необходимых для проверки функций, измененных не из-за ошибки.
Структура автоматизированной системы
Для сокращения времени процесса тестирования и улучшения его качества предлагается автоматизировать часть описанных выше действий. Автоматизированная система, включающая в себя модули логирования, документирования и создания тестового набора имеет структуру, представленную на рис. 2.
Рис. 2 Структура автоматизированной системы
Запуск процесса тестирования происходит в системе непрерывной интеграции вручную или по расписанию. После запуска система собирает новую сборку с последней версией входных данныгх (тесты, документация). Затем модуль управления начинает выполнять нужные тесты на сервере и параллельно запускает логгер. После выполнения всех тестов и записи данных по их выполнению запускается модуль документирования, который создает документы выходной документации (test Incident Report, test log, test Summary Report). Эта документация передается в модуль формирования тестового набора, где на основе ее и входной документации формируется множество тестов для регрессионного тестирования и записывается в специальный файл.
Заключение
Применение рассматриваемого метода формирования тестового набора повысит качество процесса регрессионного тестирования, так как этот метод безопасный и точный. Он так же является универсальным, то есть его можно использовать для большого множества программ с различными вносимыми в них изменениями, а автоматизированная система позволит сократить время проведения процесса тестирования и сделать отчетность по нему максимально наглядной.
