Аспекты применения объектно-ориентированного подхода в регрессионном тестировании компиляторов

Размещено на http: //www. allbest. ru/

ЗАО «МЦСТ»

Аспекты применения объектно-ориентированного подхода в регрессионном тестировании компиляторов

Д.С. Горлушко

Аннотация

Освещаются некоторые аспекты применения объектно-ориентированного подхода к разработке системы регрессионного тестирования компиляторов на ВК серий «Эльбрус-3m» и «МЦСТ-R». Излагаются особенности регрессионного контроля качества компиляторов на проекте. Рассматриваются архитектура системы автоматизированного тестирования и специфика моделей основных функциональных компонент, приводятся сведения о программной реализации продукта.

Ключевые слова: регрессионное тестирование, автоматизация, проектирование, объектно-ориентированный подход, компиляторы.

Annotation

ASPECTS OF USING OBJECT-ORIENTED APPROACH IN COMPILERS REGRESSION TESTING

D. Gorlushko

This article reports some aspects of using object-oriented approach to develop compilers regression testing system on «Elbrus-3m» and «MCST-R» computers. Some features regression testing «Elbrus» compilers are described in first section. System architecture and structure peculiarity of all functional components are in the main part of article. Finally, there is some information about product implementation.

Key words: regrission testing, automation, designing, object-oriented approach, compilers.

Введение

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

1. Особенности регрессионного тестирования компиляторов семейства «Эльбрус»

В соответствии со стандартным определением регрессионное тестирование - это выборочное тестирование, позволяющее убедиться, что изменения не вызвали нежелательных побочных эффектов, или что измененная система по-прежнему соответствует требованиям. Основные задачи регрессионного тестирования [1]:

убедиться, что обнаруженная ошибка исправлена и после этого не появились новые;

гарантировать функциональную преемственность и совместимость новой версии (релиза, патча) с предыдущими;

уменьшить стоимость и сократить время выполнения тестов.

Регрессионное тестирование дорогостоящая операция, требующая значительных вычислительных ресурсов для выполнения необходимых проверок на тестовых задачах и надежного ПО для автоматизации этого процесса.

Что касается последнего, то для обеспечения качества оптимизирующих компиляторов семейства «Эльбрус» с самого начала проекта были разработаны и реализованы системы регрессионного оперативного тестирования и ночного тестирования компиляторов. Существенной особенностью этих программных средств контроля качества является то, что они осуществляют проверки компиляторов исключительно с помощью моделирующих систем для вычислительных комплексов (ВК) серий «Эльбрус-3m» и «МЦСТ-R». С одной стороны, конечно, это позволило начать отладку системы программирования (СП) на пакетах простых тестов задолго до появления первых ВК. С другой стороны, моделирующий комплекс в 10-100 раз медленнее ВК, что делает его непригодным для проверки кода компиляторов на сложных тестовых примерах, т.е. задачах, исполнение которых превышает 100 млрд. тактов процессорного времени. Таким образом, следующим этапом развития средств регрессионного контроля стало проектирование и реализация среды поддержки регрессионного тестирования на вычислительных машинах упомянутых серий архитектур.

Что касается вычислительных ресурсов, то на проекте задействованы парк x86-серверов, около десятка ВК серии «Эльбрус-3m» и несколько ВК серии «МЦСТ-R». Все ВК разрабатываемых архитектур находятся в коллективном пользовании, так что время прохождения пакета может существенно увеличиваться при интенсивной работе сотрудников. Также в силу проведения разного рода отладочных работ на машинах возможны различного рода сбои в работе операционных систем на ВК, а также их зависания. регрессионный тестирование компилятор компьютер

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

2. Архитектура системы

Особенностями архитектуры системы является разбиение на два независимых фреймворка: платформу распределенного запуска и платформу анализа результатов (рис. 1). Подобная схема была применена исследовательской группой факультета математики и физики Чарльзского университета на проекте по разработке универсального средства автоматизации анализа производительности «BEEN» [2]. Такое разбиение информационной системы позволяет проводить независимое проектирование и разработку каждой платформы, а также обеспечивает вертикальную масштабируемость всей системы. Интегрирующим звеном в схеме выступает основной функциональный элемент - ядро системы, связывающее воедино два фреймворка посредством предоставляемых ими интерфейсов. Администрирование ядра и составление расписаний запусков осуществляются менеджерами конфигурирования и планирования запусков подсистемы управления. Данные компоненты в настоящий момент еще находятся в разработке. Таким образом, основными, уже существующими функциональными модулями являются подсистема средств запуска пакетов тестирования, менеджер ресурсов и подсистема визуализации. Далее рассматриваются некоторые аспекты применения ООП при проектировании и реализации этих компонентов.

3. Подсистема средств запуска пакетов тестирования

Архив тестовых пакетов представляет собой структурированное хранилище исходных текстов сложных задач. Как уже отмечалось, особенность этих тестов в том, что они являются реальными пользовательскими приложениями, поэтому имеют нетривиальные схемы сборки, запуска сгенерированного бинарного файла, а также анализа результатов их работы. Все это отражается и на временнй характеристике работы этих пакетов. Таким образом, основными требованиями к средствам запуска являются: надежность процесса, протоколирование получаемых результатов с возможностью восстановления процесса с контрольной точки, а также оперативность решения текущих задач по сопровождению.

Рис. 1 Архитектура системы

Структура этой компоненты среды имеет сервис-ориентированную архитектуру [3], разделенную на модули по их непосредственному назначению. Основные модули подсистемы:

модуль режима запуска выбирает тестируемую компоненту, основные опции запуска, подгружает список модулей соответствующих пакетов тестовых задач, задает порядок действий для проверки пакетов;

модуль пакета задач определяет основную функциональность действий для проверки компиляторов на задачах пакета;

модуль входных данных реализует механизмы запуска задачи, анализа результатов исполнения;

модуль результатов собирает и обрабатывает показатели производительности компилятора;

модуль отчетов генерирует различные отчеты по результатам запусков;

модуль контрольной точки реализует механизм восстановления запуска тестирования пакета с контрольной отметки в случае сбоя работы ВК;

модуль ресурсных ограничений предоставляет удобный интерфейс работы с ресурсными лимитами.

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

Одной из особенностей модели является многоуровневое дерево наследования класса «Задача», позволяющее эффективно реализовать механизм формирования опций компиляции для тестов, настройку ресурсных ограничений, организацию сложных схем компиляции или исполнения и т.д. На рис. 3 приведено сравнение структурного подхода и ООП в части определения опций компиляции задачи. Очевидное нагромождение условных конструкций «IF-THEN-ELSE» в первом случае снижает читаемость кода, усложняет функционал, делая его менее гибким и масштабируемым, тем самым затрудняя его сопровождение. Как следствие, снижается надежность всей системы.

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

Рис. 2 Структурная модель системы

Рис. 3 Сравнение структурного подхода и ООП

Рис. 4 Конфигурационный модуль

Механизм сохранения результатов в случае зависания тестирования на каком-либо ВК обеспечивается объектами классов «контрольная точка для компиляции» и «контрольная точка для исполнения». С их помощью можно возобновлять прерванное тестирование с момента последнего действия [4]. Различия между этими классами - в функции сериализации, которая в классе «контрольная точка для исполнения» позволяет сохранять промежуточные результаты по каждому входному данному.

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

4. Особенности работы с вычислительными ресурсами

Основная задача менеджера ресурсов - эффективное управление всеми имеющимися вычислительными машинами. Как уже упоминалось, на проекте задействованы x86-серверы, а также ВК серий «Эльбрус-3m» и «МЦСТ-R». Для представления этих объектов в системе используется иерархия классов, приведенная на рис. 5. Вершина дерева - абстрактный класс «Сервер» с перечнем требуемых для модели атрибутов и методов. В дочерних классах идут уже необходимые переопределения функций «Установить_<системный параметр>», исходя из конкретной архитектуры вычислительной машины и способов извлечения системных характеристик. После определения данные атрибуты используются менеджером при выборе требующегося вычислительного средства из общего пула для запуска той или иной задачи. Для извлечения значений системных параметров используются одноименные функции «Получить_*».

Работа с выбранным объектом подкласса «Сервер» осуществляется посредством унифицированного для всех типов машин интерфейса, заложенного в базовом (родительском) классе. Этот механизм является примером полиморфного поведения объектов подтипа «Сервер». Данный принцип ООП позволяет значительно упростить схему работы с данными модели, сократить «внешний» программный код [5]. Что касается атрибутов объекта, то доступ к ним осуществляется с помощью функций «Установить_*» и «Получить_*». Таким образом, внутреннее устройство модели скрыто от вмешательств извне, а это уже демонстрация другого принципа ООП - инкапсуляции. Еще один аспект применения этого понятия будет приведен ниже.

Рис. 5 Иерархия классов

Подсистема визуализации результатов тестирования

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

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

Что касается механизма обработки событий, то здесь интерес представляют методы оповещения объекта класса «Меню», в частности, метод проверки актуальности последних результатов, запускаемый подсистемой асинхронно каждую минуту и проверяющий достоверность информации в ОП кэш-сервиса и БД. Если в последней данные обновились в течение предыдущей минуты, то данный метод сбрасывает чекер актуальности результатов и запускает метод «мерцание заголовка». В итоге заголовок в окне браузера начинает оповещать пользователя об обновлении результатов. В рамках подсистемы визуализации это далеко не единственный пример применения механизма обработки событий, так что данное свойство ООП оказалось действительно практически важным при разработке этой компоненты.

Результаты и выводы

Реализация системы регрессионного тестирования была выполнена на языке Perl5 c использованием расширения Moose, позволяющего упростить поддержку ООП. В итоге в системе используется более 150 классов, объем программного кода составляет около 70 тыс. строк. Для сравнения, только отдельные компоненты подсистемы средств запуска, разработанные ранее с использованием структурного подхода к проектированию и реализации, насчитывали порядка 20-30 тыс. строк кода (суммарно же вся система насчитывала более 120 тыс. строк кода). Таким образом, применение ООП позволило построить более компактный код, упростило процесс сопровождения системы, повысило адаптируемость, масштабируемость и надежность.

Внедрение данного ПО состоялось в 2009 году. За это время с помощью разработанной системы удалось отладить три новые версии СП, включено шесть тестовых пакетов сложных задач, выявлено порядка 500 нетривиальных ошибок. Объем запусков тестирования на ВК в настоящий момент составляет более 1000 сложных задач, что соответствует более чем 1500 часам работы всех ВК в неделю.

Заключение

В статье рассмотрены некоторые аспекты применения основных принципов ООП при разработке системы регрессионного тестирования компиляторов на ВК серий «Эльбрус-3m» и «МЦСТ-R». Использование данной концепции при проектировании и реализации всех основных функциональных компонентов продемонстрировало ее эффективность и указало на перспективность дальнейшего развития проекта в данном ключе. В дальнейшем интерес представляют разработка подсистемы управления тестированием, а также реализация модуля обработки результатов и формирования различных статистических отчетов.

Литература

1. William E. Perry, Effective Methods for Software Testing, Publisher: Wiley, 3 edition, 2006.

2. Tomas Kalibera, Jakub Lehotsky, David Majda, Branislav Repsek. Automated Benchmarking and Analysis Tool, 2006 (http://www.acm.org).

3. Канер С., Фолк Дж., Нгуен Енг. Тестирование программного обеспечения. К., ДиаСофт, 2000.

4. Винниченко И. Автоматизация процессов тестирования. СПб., Питер, 2005.

5. Grady Booch, Object-oriented analysis and design with applications, Addison Wesley Professional, 2007.

Размещено на Allbest.ru