работа (стр. 2 из 3)
Задача — компонент, совокупность всех тестов и другая служебная информация относительно этих тестов и компонента (это, как минимум, системные требования, необходимые для запуска тестов). Результаты выполнения задачи отправляются на сервер и обрабатываются принимающим модулем, который предполагается легко сменяемой частью системы для каждой задачи.
Пользователь — тот, кто может в какой-то степени управлять сервером, процессом тестирования, задачами и т.д.
Итак, используя вышеизложенные определения, формальная постановка задачи выглядит так: создать систему, которая на входе принимает компонент и набор тестов к нему, а на выходе выдает результаты выполнения всех тестов (либо отчеты о невозможности корректного выполнения тех или иных тестов в результате либо невозможности найти клиентов, удовлетворяющих заявленным системным требованиям, либо в силу некорректности самих тестов), при этом планирование выполнения тестов и вообще все операции распределения работы по выполнению тестов и контроля выполнения тестов полностью возлагаются на систему, участие человека ограничивается лишь постановкой очередной задачи.
После анализа требований было решено, что система должна предоставлять следующие возможности:
· Система должна обеспечивать возможность запуска тестирующего кода на нескольких компьютерах локальной сети организации, сбора и представления информации о компьютерах в целях разработчиков ПО.
· Количество рабочих станций не должно быть ограничено (от локальной системы тестирования, до тестирования в сети из нескольких тысяч рабочих станций). Более того, сеть тестирования должна уметь динамически менять свой состав и структуру (при подключении или отключении клиентов).
· Система должна управляться пользователем, имеющим в данной системе достаточные права. Настройка системы должна проводиться на сервере, а не на клиентских машинах (после развертывания системы).
· Должна быть предусмотрена возможность остановки тестирования ПО клиентом на рабочей станции. При этом тестирование останавливается и запускается заново на другой машине, либо перестраивается расписание, если нет подходящих машин.
· Система должна обрабатывать корректно сбои на рабочих станциях. В этом случае нужно производить перезапуск тестирования на другой подходящей рабочей станции.
· Система должна запускать тесты в отдельном процессе, чтобы не пасть жертвой тестирования.
· Рабочие станции должны сообщать серверу информацию об установленном ПО (версии 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, может только измерить производительность системы на нескольких математических тестах на целых и вещественных числах, и именно этими и только этими данными располагает сервер), и стандартных средств для ее расширения не предусмотрено. Нам же крайне важна именно развернутая система определения ресурсов клиентских машин.