Курсовая работа
Исследование ВОЗМОЖНОСТЕЙ
GRID-технологии применительно к
задаче Тестирования программного
обеспечения.
Савенко Дмитрий Валерьевич
Научный руководитель
Иртегов Д.В.
Новосибирск – 2006
Содержание
Введение.. 3
Что такое GRID и как его можно использовать для задачи тестирования ПО.. 5
Постановка задачи.. 7
Результаты работы... 9
Дальнейшее развитие проекта.. 11
Заключение.. 14
Список литературы... 15
Введение
Актуальность.
Тестирование является одним из важнейших этапов разработки программного обеспечения, всестороннее тестирование — сложный, долгий и ресурсоемкий процесс. Но, тем не менее, необходимый. Любая, сколь угодно малая автоматизация процесса тестирования приложений значительно повышает эффективность разработки приложений и их конечное качество. Распределенное тестирование приложений позволяет проверить их работу на многих различных средах и платформах и всесторонне оценить готовность приложения к выходу в свет. Из вышесказанного следует, что исследования на данную тему, несомненно, актуальны, особенно для организаций, занимающихся разработкой программного обеспечения в промышленных масштабах.
Цели и задачи.
Исследовать принципиальную возможность распределенного автоматического тестирования программного обеспечения, реализовать систему для такого тестирования, опробовать ее на практике.
Обзор существующих решений.
GRID — популярная в настоящее время технология, на базе подходов GRID было создано много приложений, большинство из них имеют ярко выраженную математическую направленность (например, решение больших вычислительных задач методом разделения их на малые части). Однако тщательный анализ существующих платформ для создания GRID-приложений и как приложений, на них реализованных, так и самостоятельных GRID-приложений, не привел ни к чему. А именно, доступных решений, пригодных для распределенного тестирования программного обеспечения, найдено не было.
Были найдены несколько утилит, в той или иной степени облегчающих тестирование приложений на нескольких компьютерах (например, IBM Rational TestAgent [4]), но в них речь не идет о распределенном
тестировании, это всего лишь фреймворки, облегчающие запуск и контроль выполнения программ на разных машинах. Регистрация новых машин — долгий и утомительный процесс, программное обеспечение везде должно быть идентичным, распределение задач на конкретные машины делается самим пользователем — вот неполный список недостатков найденных решений, которые не позволяют назвать их системами распределенного тестирования приложений в полном смысле слова.
Что было сделано.
1. Поставлена задача автоматизации тестирования приложений. Проведено знакомство с идеологией и принципами технологии GRID, проведен анализ возможностей, которые должна предоставлять система.
2. Проведен детальный анализ платформ для реализации GRID-приложений, а также самих GRID-приложений с целью выявить достоинства и недостатки каждой платформы и выбрать ту, которая более всего подходит для нашего проекта. Результаты анализа платформ с комментариями по поводу их применимости в проекте можно найти на сайте проекта. Для создания прототипа системы было решено остановиться на платформе BOINC [3] как наиболее простой в эксплуатации.
3. Написано техническое задание для прототипа системы (доступно на сайте проекта).
4. Написаны все основные компоненты, необходимые для функционирования системы.
5. Собран прототип системы.
6. Разработан веб-интерфейс системы.
7. Проведено тестирование прототипа системы и веб-интерфейса на базе терминального класса лаборатории SWsoft-НГУ.
8. Создан установочный пакет для сервера системы (в формате Debian GNU/Linux).
9. Проведено тестирование установочного пакета.
10. После детального анализа имеющегося прототипа четко определены планы на будущее развитие системы, требования к системе согласованы с представителем отдела внутренних разработок фирмы SWsoft. На лето запланирована следующая стадия работы над системой, а именно реализация проекта в свете нового видения системы, которое было достигнуто при прохождении предыдущих этапов реализации.
Дальнейшее развитие проекта.
При наличии на руках работающего прототипа системы тестирования приложений был проведен анализ его возможностей, а также консультация с представителями фирмы SWsoft, в результате чего была более точно сформулирована задача распределенного тестирования приложений, а также сформулированы четкие требования к системе. К сожалению, детальный анализ показал, что в будущем придется отказаться от фундамента прототипа — системы распределенных вычислений BOINC, так как эта платформа накладывает ряд существенных ограничений, некоторые из которых для нас недопустимы. Однако уже разработан проект, ее заменяющий, и его реализация запланирована на лето (об этом смотрите доклад Кузнецова Алексея).
Также очевидно, что эффективность подобной системы распределенного тестирования при большом количестве разнообразных задач и тестов во многом зависит от грамотного, динамически меняющегося расписания запуска тестов на тех или иных машинах. Поэтому большим полем для исследований видится вопрос поиска и реализации эффективных алгоритмов составления расписания в данном уникальном случае, когда большинство величин задачи (время выполнения определенного теста на определенной машине, время доступности определенной машины и т.д.) могут быть оценены лишь вероятностно. Работы в данном направлении еще не начаты, но планируются в будущем.
Что такое
GRID и как
его можно использовать для задачи
тестирования ПО
Формальное определение.
GRID — это форма распределенных вычислений, включающая динамическое координирование и разделение в общем случае географически отдаленных друг от друга вычислительных ресурсов, а также хранилищ данных, сетевых ресурсов и других форм ресурсов. При этом подразумевается, что взаимодействие между ресурсами будет организовано только лишь при помощи программного обеспечения, без привлечения новых аппаратных устройств сверх тех, что уже имеются для связи ресурсов в сети.
Почему это важно?
Технология GRID предоставляет совершенно новый способ вычисления комплексных задач, не требующий дорогостоящего оборудования и квалифицированного обслуживающего персонала (как того требует типичный кластер), и, следовательно, приемлемый даже для небольших организаций.
Для более подробной информации о GRID см. [1].
Подходы к реализации.
На данный момент существуют две лидирующие универсальные платформы для создания GRID-систем — Globus [2] и BOINC [3]. Краткие обзоры систем с комментариями применительно к нашим задачам доступны на сайте проекта ([5]).
После обсуждения всех «за» и «против» было решено прототип системы делать на основе инструментария BOINC (Berkeley Open Infrastructure for Network Computing), как наиболее простого для освоения. BOINC — это некая заготовка приложения, которая для превращения в действительное приложение должна быть дополнена следующими компонентами: определенная система поступления новых данных для задачи, два серверных демона (ассимилятор и валидатор, подробнее в разделе «Результаты работы») и клиентская часть — то, что будет рассылаться на пользовательские машины, а затем принимать от сервера порции данных, обрабатывать и возвращать серверу ответ. Как видно, BOINC также концентрируется на математических расчетах больших задач, данные которых можно разделить на малые порции (например, обсчет сигналов разных звезд, расшифровка генома человека и т.д.). Наше приложение не является типичным BOINC-приложением, так как по сети передается не просто данные, но код, которые должен быть исполнен. Это повлекло за собой некоторые изменения стандартной архитектуры приложения BOINC, которые описаны в разделе «Результаты работы».
GRID и тестирование приложений.
Технологии распределенных вычислений могут дать следующие преимущества при применении к задаче тестирования приложений:
1. Ускорение тестирования за счет распараллеливания и отсутствия необходимости вмешательства человека в процесс тестирования, также удешевление тестирования по этим же причинам.
2. Возможность быстрого тестирования ПО и его частей на машинах с разной конфигурацией, как аппаратной, так и программной с целью проверить работоспособность программного обеспечения в разных условиях.
3. Возможность использовать по назначению имеющиеся вычислительные мощности, в ином случае просто простаивающие без дела (например, ночью или во время обеденного перерыва). Строго говоря, большая часть вычислительных возможностей машины не используется даже при непосредственной работе программиста на ней, и это может быть исправлено параллельным запуском тестирующего модуля на машине.
Постановка задачи
Далее приведены несколько определений для лучшего понимания сути предмета.
Клиент —
программа или совокупность программ, запускаемая на компьютере пользователя и позволяющая включить его компьютер в GRID-сеть.
Компонент —
объект тестирования. Фактически он может быть многими разными сущностями, например: библиотекой классов Java в jar-файле, dll-библиотекой, набором исходных файлов библиотеки на С++ и т.д.
Юнит-тест или просто тест —
автономный (не требующий управления пользователем) запускаемый модуль (для компилируемых языков это может быть исполняемый файл, для Java — класс со статической функцией main() и т.д.). Тест работает с компонентом определенным образом с целью выявить правильность или неправильность работы компонента при модели использования, заложенной в тесте. Результаты работы теста возвращаются заранее оговоренным способом. Подход к тестированию ПО на основе юнит-тестов называется юнит-тестированием, очень широко применяется и составляет значительную часть всего процесса тестирования.
Задача —
компонент, совокупность всех тестов и другая служебная информация относительно этих тестов и компонента (это, как минимум, системные требования, необходимые для запуска тестов). Результаты выполнения задачи отправляются на сервер и обрабатываются принимающим модулем, который предполагается легко сменяемой частью системы для каждой задачи.
Пользователь —
тот, кто может в какой-то степени управлять сервером, процессом тестирования, задачами и т.д.
Итак, используя вышеизложенные определения, формальная постановка задачи
выглядит так: создать систему, которая на входе принимает компонент и набор тестов к нему, а на выходе выдает результаты выполнения всех тестов (либо отчеты о невозможности корректного выполнения тех или иных тестов в результате либо невозможности найти клиентов, удовлетворяющих заявленным системным требованиям, либо в силу некорректности самих тестов), при этом планирование выполнения тестов и вообще все операции распределения работы по выполнению тестов и контроля выполнения тестов полностью возлагаются на систему, участие человека ограничивается лишь постановкой очередной задачи.
После анализа требований было решено, что система должна предоставлять следующие возможности:
· Система должна обеспечивать возможность запуска тестирующего кода на нескольких компьютерах локальной сети организации, сбора и представления информации о компьютерах в целях разработчиков ПО.
· Количество рабочих станций не должно быть ограничено (от локальной системы тестирования, до тестирования в сети из нескольких тысяч рабочих станций). Более того, сеть тестирования должна уметь динамически менять свой состав и структуру (при подключении или отключении клиентов).
· Система должна управляться пользователем, имеющим в данной системе достаточные права. Настройка системы должна проводиться на сервере, а не на клиентских машинах (после развертывания системы).
· Должна быть предусмотрена возможность остановки тестирования ПО клиентом на рабочей станции. При этом тестирование останавливается и запускается заново на другой машине, либо перестраивается расписание, если нет подходящих машин.
· Система должна обрабатывать корректно сбои на рабочих с
· Система должна запускать тесты в отдельном процессе, чтобы не пасть жертвой тестирования.
· Рабочие станции должны сообщать серверу информацию об установленном ПО (версии JVM, наличии каких либо библиотек, версии ОС и проч.) и конфигурации компьютера.
· Система отбирает для тестирования те машины, которые соответствуют заявленным системным требованиям тестируемого ПО.
· Должна быть предусмотрена возможность тестирования ПО даже в условиях, когда на машине нет ни одного авторизованного пользователя (для Windows это, например, означает использование NT Service).
Результаты работы
Работа над созданием системы, удовлетворяющей вышеизложенным требованиям, велась чуть меньше двух семестров. В этот срок включено и тестирование системы. В итоге имеем работающий прототип системы, который, можно заключить по итогам тестирования, вполне пригоден для решения реальных задач.
Далее подробно опишем функциональность системы, стадии ее работы, начиная от создания новой задачи и заканчивая сбором результатов.
Для создания новой задачи пользователь должен загрузить в систему компонент, набор тестов к нему, и к каждому тесту приложить описание его системных требований (описание представляет собой XML-файл, однако он может быть автоматически сгенерирован веб-интерфейсом после интерактивного диалога с пользователем). Это минимальная информация, необходимая системе, чтобы начать тестирование.
Далее вмешательство пользователя в процесс более не требуется. Задача и тесты регистрируются на сервере. При запросе очередного клиента на выдачу работы сервер ищет подходящий по системным требованиям тест и выдает клиенту. В целях проверки корректности вычислений один и тот же тест выдается нескольким разным клиентам, а затем специальная программа-валидатор получает все результаты и выбирает среди них канонический,
то есть тот, который считается наиболее достоверным.
После завершения клиентом работы над тестом он посылает серверу отчет о ходе работы теста и ее результатах. Эта информация проходит сначала через валидатор, а затем через ассимилятор — программу, которая получает канонический результат и решает, что с ним дальше делать (эта программа должна каким-то образом извещать пользователя о том, что работа над его тестом завершена, и предлагает ему посмотреть результаты).
Таков цикл жизни теста в системе. В нашем случае для создания новых задач и тестов используется веб-интерфейс (вопреки ожиданиям, он оказался довольно сложной частью системы, потребовавшей длительного планирования и реализации, так как требовалось в интерфейсе реализовать возможность задавать различные ограничения на тесты в условиях, когда полный набор возможных ограничений неизвестен). Для теста каноническим считается наихудший
из полученных результатов. Ассимилятор складывает канонические результаты в базу данных, которая доступна пользователю, опять же, через веб-интерфейс.
Описанное выше устройство системы во многом продиктовано требованиями платформы BOINC к проектам, реализованным на ней. Следующая диаграмма проиллюстрирует описанное выше взаимодействие компонентов.
Сервер
— набор демонов, запускаемых на серверной машине. Это следующие программы: валидатор, ассимилятор, feeder, transitioner и file_deleter. Три последние программы поставляются вместе с BOINC и не предполагают изменений, они описаны в документации BOINC (http://boinc.berkeley.edu/create_project.php), и мы на них останавливаться не будем. Первые две были написаны непосредственно нами, их функции описаны выше.
Клиент —
операционная прослойка между сервером и тестирующим модулем, поставляемая вместе с системой BOINC и не требующая вмешательства. Занимается тем, что получает тесты по сети от сервера и передает их тестирующему модулю. Процесс этот происходит следующим образом: сначала клиент проводит несколько тестов производительности машины (простые математические тесты), эта информация отсылается на сервер. Затем, когда клиент решает, что машина пользователя может работать над задачами проекта, к которому подключен пользователь (это реализовано в виде двух схем: либо клиент работает всегда, но с низким приоритетом, либо клиент работает только при включение системного хранителя экрана, что должно свидетельствовать о малой загруженности системы), он отправляет на сервер запрос на выдачу работы на некоторое время. Получив работу, клиент разрывает соединение с сервером, передает полученный тест тестирующему модулю, дожидается завершение его работы, затем снова устанавливает соединение и отправляет результат.
Тестирующий модуль —
был написан полностью нами, непосредственно занимается работой с тестами и рабочей станцией, а именно: собирает специфическую для данного типа тестирования информацию о машине пользователя (например, версия JVM для тестирующего модуля приложений на Java), получает тесты от клиента, запускает их, следит за выполнением затребованных ограничений (по времени выполнения, например), по завершении теста (успешном или не успешном) отправляет отчет о проведении тестирования клиенту, от которого он поступает на сервер.
Важно отметить, что хотя в настоящий момент в прототипе реализован только один тестирующий модуль (для тестирования классов на Java), в систему заложена возможность наличия нескольких тестирующих модулей, предназначенных для тестирования разных сущностей (очевидно, например, что тестирующий модуль для библиотек на C++ будет по своей структуре сильно отличаться от тестирующего модуля для библиотек на Java). При этом на разных клиентских машинах могут быть установлены разные наборы тестирующих модулей.
Дальнейшее развитие проекта
Тестирование прототипа системы показало, что он представляет собой реальный инструмент, вполне пригодный для целей, ради которых он создавался. Однако, несмотря на то, что основная функциональность была реализована, мы не вполне довольны его текущим состоянием главным образом потому, что любое расширение системы крайней затруднено. Это произошло из-за существенных ограничений платформы BOINC на проекты, реализованные с помощью нее. Платформа BOINC выбиралась с целью быстрого и эффективного создания прототипа системы, эта цель достигнута, однако дальнейшее использование BOINC не представляется возможным. Далее приведен список особенностей платформы, являющихся серьезными недостатками в нашем случае.
Скудные возможности для диалога между сервером и клиентами.
Это является основной проблемой. Фактически, весь диалог сводится к тому, что клиент запрашивает работу у сервера и возвращает ему результат. В нашем случае это означает, что сервер не может заранее узнать, обладает ли клиент необходимыми ресурсами для выполнения рабочего модуля. Дело в том, что система определения возможностей клиента находится в зачаточном состоянии (клиентская программа, поставляемая в BOINC, может только измерить производительность системы на нескольких математических тестах на целых и вещественных числах, и именно этими и только этими данными располагает сервер), и стандартных средств для ее расширения не предусмотрено. Нам же крайне важна именно развернутая система определения ресурсов клиентских машин.
Далее, невозможность нормального диалога между клиентом и сервером приводит к тому, что приходится отказаться от какого-либо составления расписания заданий, ведь совершенно непонятно, какой клиент в какое время запросит работу и в какое время вернет результат.
Также принятая в BOINC система рабочих модулей предполагает, что в нашем случае тестирующий модуль должен передаваться каждый раз вместе с очередным тестом, что очень накладно.
Проблемы разграничения полномочий.
Изначально не предполагается различия между клиентами. Фактически, в системе тестирования есть несколько ролей: администратор, разработчик и просто хостер (предоставляет машину, и не имеет права на просмотр результатов исполнения). Примером может служить пользователь рабочей станции из другого отдела компании.
Однако в случае с BOINC мы имеем систему, которая не различает клиентов. Т.е. всякий может подключиться к системе. И все имеют одинаковые права. В этих условиях простая запись в каталог сервера уже является дырой в безопасности. К тому же разграничение полномочий — фактически, задача веб-интерфейса и сетевого экрана, который придется тонко настраивать для того, чтобы оградить систему от нежелательных пользователей. В рамках системы BOINC эта задача требует длительного анализа её разрешимости (разрешимость сомнительна).
В системе BOINC предполагается, что код компонента исходит от администратора системы, то есть, доверенного лица, однако в нашем случае это не так. Необходимо связывать новые рабочие модули с идентификатором пользователя, который их создал.
Хранение рабочих модулей.
BOINC хранит рабочие модули и результаты их работы в виде простых файлов на файловой системе сервера. Мы считаем такой подход неудобным и неправильным. Это порождает необходимость в запутанной системе уникальных имен каталогов и деформацию имен файлов, для того, чтобы файлы не заменялись, если их имена совпадают. Более того, в целях решения проблемы удаления этих файлов разработчикам BOINC пришлось даже ввести отдельного демона — File Deleter, который постоянно работает на сервере и занимается сборкой мусора. Предлагается полностью отказаться от подобного подхода и размещать файлы рабочих модулей и результаты в БД без сохранения их в каталогах сервера.
Ошибки на уровне стандартных приложений.
В целях установления возможностей системы BOINC мы подключались к различным проектам, основанным на ней, и пробовали принимать в них участие. Это выявило несколько интересных фактов о системе, например, подключившись к SETI@home (самому известному проекту на базе BOINC) с домашней машины, я понял, что клиент BOINC для платформы Linux не соответствует никаким критериям качества.
Также при тестировании замечено, что один из необходимых серверных модулей (под названием feeder) время от времени прекращает работу, и реанимировать его удается только при помощи пересоздания проекта с нуля. Причины такого поведения неясны, все попытки поправить положение не увенчались успехом.
Очень неаккуратный, а местами и просто ошибочный код.
В частности, в некоторых местах исходного кода компонентов BOINC были выявлены утечки памяти, консольные утилиты иногда вызывают ошибку Segmentation fault, предлагаемые средства разбора XML чрезвычайно бедны и, ко всему прочему, работают ошибочно (правильный разбор зависит от расстановки пробельных символов в файле, что для формата XML неприемлемо).
Система BOINC поставляется вместе с полными исходными текстами, поэтому теоретически исправить вышеперечисленные недостатки можно. Однако в результате анализа размеров правки системы было решено, что целесообразнее написать все с нуля. Усугубляется же положение еще и тем, что документация имеется только по небольшому числу компонентов системы, остальное же не содержит никаких комментариев, поскольку разработчики посчитали, что эти компоненты переписываться или правиться не будут.
Подробнее о том, какая же архитектура должна прийти на смену BOINC, смотрите доклад Кузнецова Алексея [6].
Заключение
Что сделано:
.
1. Доказана возможность эффективного применения технологии GRID в задаче тестирования программного обеспечения.
2. Написан прототип системы распределенного тестирования приложений.
3. В ходе работы над прототипом и его тестирования детально разобраны и четко поняты требования к реальной системе распределенного тестирования приложений.
4. Разработана модель будущей архитектуры системы (см. [6]).
Планы на будущее:
1. Реализация новой архитектуры системы.
2. Разработка эффективных алгоритмов составления расписания выполнения тестов на разных машинах.
3. Апробация системы в реальных условиях (тестирование в фирме SWsoft).
Список литературы
1. http://grid.org — общая информация о GRID-системах.
2. http://globus.org — популярный GRID-инструментарий Globus.
3. http://boinc.berkeley.edu — популярный GRID-инструментарий BOINC.
4. Kelly Michael, Using Test Agents (http://www-128.ibm.com/developerworks/rational/library/3842.html)
5. http://swsoft.nsu.ru/~savenko/tgrid — сайт проекта.
6. Курсовая работа Кузнецова Алексея.