Отладка и тестирование программного обеспечения

Тестирование программного обеспечения является обязательной частью цикла разработки любого программного продукта. Рассматриваемый в данном дипломном проекте программный продукт состоит из 3-х основных частей (модулей) и каждый из них имеет свои особенности:

• 1. менеджер проектов в первую очередь работает с файловой системой и осуществляет операции чтения, записи и вывода информации;
• 2. конфигуратор кластера собирает и модифицирует конфигурационные структуры разработанного формата в выделяемой оперативной памяти с последующей их записью или «превращением» в реальные конфигурационные файлы узлов;
• 3. блок мониторинга практически непрерывно ведет обмен информацией между узлами кластера через систему встроенную сообщений QNX и визуализирует статистическую информацию в графической форме на интерфейсе пользователя.

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

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

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

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