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

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

СИСТЕМА РАСПРЕДЕЛЕННОГО 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 для наших целей.