Главная              Рефераты - Разное

Уточнение требований к системе 6 Архитектура системы 8 - реферат

Курсовая работа

СИСТЕМА РАСПРЕДЕЛЕННОГО UNIT-ТЕСТИРОВАНИЯ «Testing grid»: уточнение требований и разработка архитектуры системы

Кузнецов Алексей Александрович

Научный руководитель

доцент ФИТ НГУ, Иртегов Дмитрий Валентинович, начальник отдела внутренних разработок SWsoft Дерябин Олег Владиславович

_____________________________

Новосибирск – 2006


Оглавление

Введение и постановка задачи. 3

Уточнение требований к системе. 6

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

Выводы.. 13

Список литературы.. 13

Введение и постановка задачи

Цель проекта «Testing Grid»— создание системы распределенного unit-тестирования с использованием некоторых подходов GRID. Тестирование является одним из важнейших этапов разработки приложения, всестороннее тестирование — сложный, долгий и ресурсоемкий процесс. Но, тем не менее, необходимый. Для облегчения и автоматизации этого процесса и нужна эта система.

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

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

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

В этой связи было принято решение о создании прототипа системы на основе некоторых открытых и некоммерческих сторонних разработок, которые уже существовали. Выбор подобной основы пал на достаточно популярный набор компонент BOINC, который, предположительно, представлял собой набор компонентов, использование которых в нашей системе представлялось целесообразным.

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

К сильным сторонам системы BOINC были отнесены следующие факты:

1. Использование протокола HTTP для коммуникации между клиентским и серверным приложениями. Данный факт, как мы убедились в дальнейшем, имеет важнейшее значение.

2. Наличие ЭЦП, как механизма защиты системы от вредоносного кода предполагается, что это позволяет исключить возможность исполнения вредоносного кода.

3. Наличие Web-интерфейса для управления системой.

К слабым сторонам системы BOINC были отнесены следующие факты:

1. В системе очень слабо развита система авторизации. Возникает проблема разграничения полномочий пользователей системы. Изначально не предполагается различия между клиентами. Фактически, в системе тестирования есть несколько ролей: администратор, разработчик и просто участник (предоставляет машину, и не имеющий права на просмотр результатов исполнения.

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

2. Хранение рабочих модулей и результатов их работы осуществляется файловой системой. Это порождает очень любопытную систему уникальных имен каталогов и деформацию имен файлов, для того, чтобы файлы не заменялись, если их имена совпадают. Удаление этих файлов — цель дополнительного демона FileDeleter, который постоянно работает на сервере.

3. Скудные возможности для диалога между сервером и клиентами. Фактически, весь диалог сводится к тому, что клиент запрашивает работу у сервера и возвращает серверу результат. В нашем случае это означает, что сервер не может заранее узнать, обладает ли клиент необходимыми ресурсами для выполнения рабочего модуля. Дело в том, что система определения возможностей клиента находится в зачаточном состоянии, и стандартных средств для ее расширения не было предусмотрено. Нам же крайне важна именно развитая система определения ресурсов клиентских машин. Также принятая в BOINC система рабочих модулей предполагает, что в нашем случае очередной тестирующий модуль должен передаваться каждый раз вместе с тестируемым модулем, что накладно.

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

5. Значительное разнообразие использованных средств, использованных для создания системы BOINC. По данной системе можно судить об этапах развития сети Интернет на протяжении последних 10 лет. К их числу можно отнести: PHP, CGI, Python, C\С++, XML, системные сценарии (shell-scripts) для Linux и многое другое. Подобный коктейль средств не был желателен с точки зрения, как безопасности, так и интеграции различных компонент.

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

Как можно видеть из приведенных выше сведений, сильные стороны системы оказались в её концепции, а не реализации. Реализация же данной системы не была проведена достаточно качественно, и дополнительная реализация многих возможностей, полезных для распределенного тестирования оказывается крайне затрудненной. В этой связи была поставлена задача выработки концепции и архитектуры системы на основе полученного опыта эксплуатации и адаптации системы BOINC для наших целей.

Уточнение требований к системе

В конце января текущего года состоялась встреча группы разработчиков системы с заказчиком системы в лице Дерябина О.В.. На этой встрече обсуждались описанные выше особенности инструментария BOINC и были конкретизированы многие требования к системе.

Контекст использования системы. В настоящий момент система рассчитывается на использование в локальной сети предприятия. Однако было решено не делать существенного различия между использованием системы в локальной сети и в условиях открытого Интернета.

Требования к мерам по обеспечению безопасности. Предполагается использование стандартных механизмов авторизации: сессии, HTTPS (SSL), доступ с помощью пароля и имени пользователя. Были определены основные роли пользователей системы, а именно:

Участник- Исполнение заданий с разрешения администратора- Доступ к главной странице web-интерфейса (возможность стать участником)- Просмотр некоторой статистики. Разработчик:- То же, что и участник+ Добавлять задания+ Смотреть результаты исполнения заданий в рамках своего проекта. Администратор:- То же, что и участник+ Наделение участников полномочиями администратора или разработчика+ Разрешать/запрещать участие пользователей (в т.ч. по IP-адресам в сети)
Требования к производительности. Первоначально система рассчитывается на десятки пользователей, объединенных в одну группу, и сотни unit-тестов в течение 12 часов. Типичным примером использования системы является следующий пример: Ночью выделенный сервер собирает проект и отправляет его на тестирование. К утру результаты тестирования должны быть получены разработчиками.
Архитектура системы и её развертывание. Система будет представлять собой клиент-серверную систему. Внешние системы. Предполагается использовать БД MySQL для хранения данных. Альтернатива MySQL - PostgreSQL. Предполагается начинать с поддержки ОС Linux как для серверных, так и для клиентских компонент.
Уточнения в формулировке основных понятий предметной области. Под unit-тестом понимается самодостаточный компонент, который дает в результате выполнения один из следующих ответов: {Тест пройден, Тест не пройден, Произошла фатальная ошибка, Превышен лимит времени исполнения}

Режимы работы системы. Клиентская часть системы должна быть способна работать в любом из 3-х режимов:

1. Экранная заставка

2. Фоновая задача с минимальным приоритетом

3. Задача реального времени (высокий приоритет подразумевает, что нет ограничения на использование ресурсов клиентской системы)

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

Система должна поддерживать JUnit тесты [3, 4]. Мы отказываемся от создания собственной системы unit-тестирования. Следует отметить, что в настоящий момент система JUnit является стандартом де-факто для unit-тестирования кода, написанного на Java, поддержка этой системы включена в большинство как коммерческих, так и свободно распространяемых средств разработки, в частности Eclipse, IntelliJ Idea, Net Beans и.т.д. В то же время не известны попытки создания распределенной системы тестирования на основе JUnit.

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

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

Изложенные требования отразили потребность сохранить сильные стороны концепции BOINC, вместе с тем дали достаточно информации для начала разработки архитектуры системы.

Достаточно внимательный взгляд на требования приводит к мысли о том, что существуют технологии, получившие всеобщее признание и позволяющие построить систему, удовлетворяющую требованиям. Речь идет об использовании Java2 Enterprise Edition для создания серверных компонент системы, при этом клиентская часть системы может быть реализована независимо и может использовать какие-либо другие технологические решения. Далее будет показано, каким образом следует использовать J2EE для разрешения существующих проблем. В настоящее время примеры использования J2EE для целей unit-тестирования не известны.

Использование сервлетов для взаимодействия с клиентскими приложениями и JSP

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

Предполагается полностью отказаться от стратегии формирования URL на ресурсы, что позволит хранить рабочие модули и результаты в БД. Вместо URL предлагается использовать методы GET и POST протокола HTTP, с помощью которых передавать необходимые сведения. Здесь и стоит применить сервлеты.

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

Предлагается использовать информацию в формате XML для связи уровней представления и логики приложения. Использование таких технологий как XSLT при генерации разного рода отчетов позволит гибко настраивать как внешний вид, так и содержание отчетов. Реализация на Java позволит отказаться от жесткой привязки, как к операционной системе, так и к БД. Предлагается использовать JNDI для сведения подобных зависимостей к минимуму.

Предварительная схема работы системы распределения тестовых заданий:

Рис. 1. Предварительная схема работы системы распределения тестовых заданий.

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

На следующей схеме представлена последовательность взаимодействия основных компонент системы, отвечающих за прием, проверку результатов тестирования и фиксацию полученных сведений в БД.

Рис 2. Предварительная схема работы системы обработки результатов тестирования.

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

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

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

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

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

Выводы

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

Оригинальное решение будет основано на одной из ключевой технологии Java2 Enterprise Edition – сервлетах. Использование сервлетов/JSP оправдано также и для создания web-интерфейса системы, поэтому было решено использовать именно сервлеты для коммуникации клиентских машин с сервером управления.

Необходимо также отметить, что ограничив рассмотрение вопроса только с позиции применения Java2, существуют немало различных подходов, в частности основанных на XML-RPC или SOAP [2]. Эти подходы также обеспечивают высокую переносимость, безопасность, расширяемость, и предлагают собственные решения по доставке исполняемого кода от серверов управления к клиентским машинам. Но существуют также и ограничения, связанные с использованием этих подходов.

Список литературы

1. University of California, Creating BOINC projects http://boinc.berkeley.edu/create_project.php

2. Karre A. A do-it-yourself framework for grid computing, 2003

http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-grid_p.html

3. Beck K., Gamma E. JUnit Cookbook

http://junit.sourceforge.net/doc/cookbook/cookbook.htm

4. Morris D. JUnit Automates Java Testing, 2003