Глава 3. Отладка и тестирование программного обеспечения
Тестирование программного обеспечения является обязательной частью цикла разработки любого программного продукта. Рассматриваемый в данном дипломном проекте программный продукт состоит из 3-х основных частей (модулей) и каждый из них имеет свои особенности:
менеджер проектов в первую очередь работает с файловой системой и осуществляет операции чтения, записи и вывода информации;
конфигуратор кластера собирает и модифицирует конфигурационные структуры разработанного формата в выделяемой оперативной памяти с последующей их записью или «превращением» в реальные конфигурационные файлы узлов;
блок мониторинга практически непрерывно ведет обмен информацией между узлами кластера через систему встроенную сообщений QNX и визуализирует статистическую информацию в графической форме на интерфейсе пользователя.
Как видно, каждый из модулей работает с разными сферами информационной среды вычислительного комплекса, что с одной стороны позволяет тестировать каждый из блоков раздельно, а с другой стороны обязывает тщательно проверять влияние друг на друга и совместную работу блоков.
Таким образом, при проведении тестирования данного программного продукта необходимо использовать модульное тестирование, которое предполагает отладку всех модулей в отдельности, а затем совместное тестирование их работы и взаимосвязей.
Для проведения модульного тестирования был составлен алгоритм, показанный на рис. 19, отражающий последовательность действий оператора при работе с программным комплексом на всех стадиях подготовки кластера к функционированию: от создания проекта, до инициализации созданной конфигурации и слежения за ее работоспособностью. Согласно алгоритму проводилось тестирование программы, включающее создание тестовых конфигураций кластера. В качестве тестовой конфигурации создавалось 3 узла в конфигураторе и за каждым из них закреплялось по несколько тестовых процессов, с заданными параметрами (порядок запуска, приоритет и т.д.). Каждый раз процессы распределялись по разному и конфигурация инициализировалась в реальную работающую систему. После инициализации программа запускалась в режиме мониторинга и подключалась к сети. Отображаемая статистическая информация сравнивалась с реальным состоянием узлов и в случае возникновения ошибок код корректировался.
Также довольно большую часть проекта составляют графические интерфейсы пользователя, включающие в себя огромное количество управляющих элементов (списков, кнопок, окон), взаимосвязь между которыми может быть не учтена в ходе разработки программы. Следовательно, программный продукт прошел и тестирование потенциальным пользователем, включающим учет «человеческого» фактора. В данном случае проверялась корректность реакций программы на некорректные действия ее оператора. К примеру, открыв окно конфигуратора, пользователь пытался «загородить» его главным окном программы так, чтобы его не было видно и пытался из главного окна повторно вызвать форму конфигуратора. В такой ситуации программа должна вместо создания нового окна, отображать уже открытое или запрещать его сокрытие вовсе. Вторым примером тестирования интерфейса можно рассмотреть попытки сохранить проект с именем, уже имеющимся в файловой системе. В таком случае программа должна выдавать предупреждающее сообщение об уже существующем уникальном идентификаторе и заставлять оператора выбрать иное название для проекта, предотвращая потерю ранее сохраненных данных.
 Рисунок 19. Алгоритм модульного тестирования блоков программного обеспечения
Глава 4. Контрольный пример
Проверка правильного функционирования программного комплекса проводится с помощью специально разработанных тестов. Для каждого из узлов были созданы тестовые конфигурации, с помощью которых можно будет проверить работоспособность созданного программного обеспечения.
Для того чтобы эмулировать различные отказы, были использованы стандартные утилиты операционных систем типа unix:
утилита /bin/cat – для эмуляции процесса, выполняющегося без каких-либо ошибок;
утилиты /bin/echo и /bin/ls – для эмуляции процессов, завершившихся после непродолжительной работы в системе;
утилита /bin/true – для эмуляции процесса, завершившегося сразу после создания;
утилита /bin/sleep – для эмуляции процессов, завершающихся в произвольный момент времени.
Конфигурация для каждого из узлов приведены в таблицах 3-5.
Идентификатор процесса в системе
|
Путь к процессу
|
Аргументы командной строки
|
Зависимости от других процессов
|
Начальный приоритет
|
1
|
/bin/echo
|
Cluster test
|
8, 2, 4, 5
|
20
|
2
|
/bin/cat
|
-u -c
|
8, 7
|
10
|
3
|
/bin/cat
|
|
4, 7
|
10
|
4
|
/bin/cat
|
|
|
10
|
101
|
/bin/cat
|
|
|
10
|
102
|
/bin/true
|
|
|
10
|
103
|
/bin/sleep
|
60
|
|
10
|
Таблица 3. Конфигурация первого узла кластера
Идентификатор процесса в системе
|
Путь к процессу
|
Аргументы командной строки
|
Зависимости от других процессов
|
Начальный приоритет
|
5
|
/bin/cat
|
|
2, 7
|
10
|
6
|
/bin/cat
|
|
18, 8
|
10
|
7
|
/bin/cat
|
-u
|
8
|
10
|
201
|
/bin/cat
|
|
|
10
|
202
|
/bin/true
|
|
|
10
|
203
|
/bin/true
|
|
|
10
|
204
|
/bin/ls
|
-l /home/cluster/node_2
|
|
10
|
205
|
sleep
|
120
|
|
10
|
Таблица 4. Конфигурация второго узла кластера
Идентификатор процесса в системе
|
Путь к процессу
|
Аргументы командной строки
|
Зависимости от других процессов
|
Начальный приоритет
|
8
|
/bin/cat
|
|
17, 18
|
20
|
9
|
/bin/cat
|
|
1
|
20
|
10
|
/bin/cat
|
|
17, 13
|
20
|
13
|
/bin/cat
|
|
17
|
20
|
17
|
/bin/cat
|
|
|
10
|
18
|
/bin/cat
|
|
26
|
10
|
20
|
/bin/cat
|
-u
|
|
10
|
21
|
/bin/cat
|
|
18
|
10
|
22
|
/bin/cat
|
|
21
|
10
|
23
|
/bin/cat
|
|
22
|
10
|
24
|
/bin/cat
|
|
23
|
10
|
25
|
/bin/cat
|
|
24
|
10
|
28
|
/bin/cat
|
|
|
10
|
31
|
/bin/cat
|
|
35, 32, 33
|
10
|
32
|
/bin/cat
|
|
35, 33
|
10
|
33
|
/bin/cat
|
|
|
10
|
35
|
/bin/cat
|
|
|
10
|
301
|
/bin/cat
|
|
|
10
|
302
|
/bin/ls
|
-l /home/cluster/node_3
|
|
10
|
303
|
/bin/sleep
|
600
|
|
10
|
Таблица 5. Конфигурация третьего узла кластера
Главное окно режима мониторинга состояния кластера (рис. 20) создано с максимально понятным визуальным интерфейсом, позволяющим почти моментально оценить текущее состояния всей сети.
Рисунок 20. Графический интерфейс пользователя в режиме мониторинга состояния кластера
Для этого каждый из узлов изображен в виде персонального компьютера, на экране которого отображается его текущее состояние в текстовом виде. Если узел корректно подключен к сети и исправно функционирует – на его экране будет виден его номер и статус «Ок», если же нет, будет отображена ошибка.
Также, предусмотрено отслеживание корректности подключений между узлами кластера и статус их функционирования. При работающем подключении и обмене сообщениями между узлами линия связи горит зеленым цветом, в противном случае, красным – при сбое соединения.
Однако, пользователю может понадобиться и подробная статистика по конкретному узлу. Для этих целей каждое из изображений совмещает в себе еще и функцию кнопки, при нажатии на которую откроется окно с подробной информацией об узле.
На рис. 21 изображено окно, открывающееся при нажатии оператором на один из узлов в режиме мониторинга. Основная цель такого окна – отобразить подробную информацию о состоянии узла в текущий момент времени.
Рисунок 21. Окно режима мониторинга узлов
В первую очередь пользователь сможет увидеть активен ли в данный момент выбранный узел. Если это так, то строкой ниже будет выдана информация о загрузке процессора, количестве свободной оперативной памяти.
Но главная задача окна статистики – отображение миграции процессов внутри сети.
Процессы, запущенные на узле изначально являются собственными; процессы, переданные на обработку другому узлу в следсвие какой-либо ошибки - переданными, а процессы, взятые на обработку с другого узла – перехваченными. Все 3 вида процессов выводятся в виде списка в отдельных секциях, позволяя оценить обработку задач качественно и количественно.
|
