CC BY
41
Разработка системы автоматизированного создания электронной тестовой документации
Мартюков А. С.
Московский государственный институт электроники и математики, кафедра "Информационные технологии и автоматизированные системы" E-mail: martvukov@ itas.miem. edu.ru
Тестирование является неотъемлемой частью процесса разработки программного обеспечения (ПО) в современных методологиях. В настоящей работе рассматриваются гибкие методологии разработки ПО (agile software development). Разработка по этим методологиям сводится к серии итераций, длящимся две-три недели. В конце каждой итерации предоставляется рабочая версия продукта с внесенными в него изменениями за этот цикл. И к концу каждой итерации в программном продукте должны быть проверены все новые или измененные функции, а так же и весь уже имеющийся функционал, для того чтобы убедиться в том, что внесенные в продукт изменения, в свою очередь, не создали в нем ошибок. Для такой проверки применяют регрессионное тестирование, но проведение его вручную требует сравнительно много времени. Поэтому для того, чтобы уложиться в отведенное на тестирование время и обеспечить нужный уровень покрытия тестируемых элементов, его автоматизируют. Автоматизация тестирования - это процесс верификации тестирования, при котором функции, шаги и проверки тестов выполняются автоматически при помощи специальных средств автоматизации тестирования. Автоматизироваться может:
• тестирование рутинных задач;
• тестирование элементов, к которым нет прямого доступа или он достаточно труден;
• тестирование наиболее приоритетных задач;
• тестирование элементов с большим количеством возможных входных параметров.
Входными данными для автоматизированного тестирования являются тесты, написанные на языке средства автоматизации, а выходными - информация об успешном прохождении теста или о его провале. Эта информация записывается в базу и после завершения тестирования проводится ее анализ. На основе этого анализа формируются:
• задачи для исправления найденных дефектов;
• отчетная документация по процессу тестирования;
• новый тестовый набор регрессионного тестирования.
Для минимизации временных затрат и повышения качества анализа предлагается автоматизированная система логгирования, создания тестовой документации и формирования нового тестового набора для регрессионного тестирования.
Во время проведения автоматизированного тестирования необходимо собирать всю информацию, которая может понадобиться для анализа, в удобном виде.
Для сбора этой информации можно:
• использовать встроенные инструменты логгирования средства автоматизации;
• подключить готовые сторонние средства логгирования;
• написать свой собственный логгер.
В настоящей работе предлагается создание собственного логгера, так как это позволяет получать:
• гибкий интерфейс;
• контроль поведения;
• возможность интеграции с другими системами своими силами.
С помощью этой системы формируются отчеты о тестировании с описанием провалившихся тестов, из них выделяются типовые ошибки и те что требуют анализа. После получения результатов выполнения тестов по этой информации создается тестовая документация. В разрабатываемой системе рассматривается структура документации тестирования по стандарту IEEE 829, состоящего из:
• test Plan;
• test Design Specification;
• test Case Specification;
• test Procedure Specification;
• test Incident Report;
• test log;
• test Summary Report.
Документ с планом тестирования (Test Plan) формируется перед каждым тестированием новой версии программного обеспечения. В нем описываются масштаб, подход, методики, виды и график тестирования. Определяются элементы, которые будут тестироваться и способы оценки корректности их работы, а так же состав команды, проводящей тестирование. Этот документ полезен как тестировщикам, так и менеджерам. После плана тестирования формируется документ Test Design Specification, описывающий техники проектирования тестов и определяющий особенности и возможности тестирования элементов, конкретные критерии прохождения или провала функции при тестировании. Test Case Specification описывает уже построенные тесты: входные и выходные данные, специальные требования, а так же связи и зависимости тестов. Так как один тест может применяться в нескольких документах Test Design Specification, которые используются различными группами в течение длительного времени, должна быть предусмотрена возможность одновременного доступа к этим документам. В документе Test Procedure Specification определяются шаги, необходимые для выполнения тестового набора или действия, используемых для анализа программного обеспечения. В Test Log записывается информация о выполнении всех тестов. Более подробная информация записывается в Test Incident Report, в нем указываются события, которые происходят во время тестирования и требуют анализа в будущем. Главным документом является отчет по тестированию Test Summary Report, подводящий итог тестирования, и предоставляющий оценку на основе этих результатов. Структуру документов, кроме последних трех предлагается оставить как в стандарте IEEE 829, а документы с результатами выполнения тестов (test log и test incident report) дополнить для получения более детальной информации. Кроме данных, указанных в стандарте, в них будут записываться: снимки экрана, мониторинг системы и системных ресурсов во время появления нестандартной ситуации. При формировании отчета по тестированию учитываются следующие необходимые для него свойства:
• он должен быть ориентирован на читателей (от тестировщиков до менеджеров);
• он должен поддерживать различные форматы для интеграции;
• должна быть возможность комбинирования нескольких отчетов;
• должна существовать система фильтрации;
• должно быть централизованное хранение;
• должна быть возможность рассылки всем заинтересованным лицам. Элемент документирования, разрабатываемый в рамках настоящей
исследовательской работы, имеет структуру, показанную на рисунке 1.
Логгер
Сервис
База log-файлов
Файл настроек
Анализатор
• П
эомежуточный формат
Генератор документов
Рис. 1 Структура компонента документирования
В процессе автоматизированного выполнения тестов логгер записывает результаты тестирования в базу данных, после чего они передаются в сервис, являющийся генератором XML-файлов. Так же на вход подается и файл настроек. В нем передается информация о том, для каких тестовых документов нужно будет собрать информацию, и в каком формате нужно будет их создать. Генератор анализирует log файлы, выделяя необходимую информацию о тестах, после чего создает XML-файл с необходимыми данными. XML-файл позволяет хранить информацию, не привязываясь к конечным форматам создаваемых документов. После его создания возможен анализ хранимой в нем информации и перевод ее в нужный формат (например, Microsoft Word или Adobe Portable Document Format). Анализатор XML-файла разбирает подаваемый ему на вход XML-файл и передает данные описания в генератор конечных документов, который и создает все нужные документы в выбранном формате.
Для проведения последующего регрессионного тестирования формируется еще один отдельный документ, который представляет собой Test Case Specification и Test Procedure Specification. В этом документе записан новый тестовый набор, который направлен на тестирование элементов, не прошедших предыдущее тестирование и элементов, в которые могли быть занесены ошибки во время правки найденных ранее замечаний. Формирование этого набора происходит с помощью безопасного метода, основанного на анализе покрытия элементов.
Применение разрабатываемой автоматизированной системы создания документации по результатам тестирования программного обеспечения позволит
- 215 -
сократить время на анализ результатов автоматизированного выполнения тестов, а так же сделать его более точным. На основе полученных данных будет возможно проводить анализ обнаруженных дефектов для выявления причин их появления и определения наиболее проблемных мест как в самом продукте, так и в команде разработки. Так же сокращается время на создание нового регрессионного тестового набора. Возможность же отправки документации и настройки формата позволит своевременно получать наиболее полезную информацию.
Список литературы
1. Institute of Electrical and Electronics Engineers // 829 Standard for Software Test Documentation;
2. Лайза Криспин, Джанет Грегори // Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд.
