Технологическая реализация системы подготовки обработки детали станка с числовым программным управлением (стр. 9 из 17)
После того как программа отлажена, необходимо выполнить ее окончательную настройку, т.е. задать название программы и выбрать значок, который будет изображать исполняемый файл приложения в папке или на рабочем столе, а также на панели задач во время работы программы [15].
3.2 Правила установки и настройки программного модуля
Процесс установки программы предполагает не только создание каталога и перенос в него выполняемых файлов и файлов данных с промежуточного носителя, но и настройку системы.
Для работы программного модуля, для начала необходимо установить на компьютер программный пакет OneSpaceDesignerModeling 2005 и новее, созданный компанией CoCreate. Процесс установки этого пакета полностью описан в инструкции к дистрибутиву.
Далее в корне любого постоянного диска, необходимо создать каталог с названием "CIP6". Такое название было принято при создании программного модуля, поэтому менять его нельзя. Внутри этого каталога должен быть создан подкаталог "Emul". Сделано это для того, чтобы в каталоге "CIP6" можно было создать ряд других каталогов, в которых могла бы храниться информация, связанная со станком, но не связанная с программным модулем (требование заказчика).
В каталоге "Emul" создаются подкаталоги, содержащие служебные файлы.
Каталог "BMP" содержит файлы изображений, используемые для пояснений и графического оформления программного модуля.
Каталог "DAT" содержит файлы, с настроечными параметрами станка (значения абсолютных координат положения инструмента относительно заготовки в начальном положении). Эти параметры остаются неизменными в течение всего периода между ремонтами. В случае изменения этих значений достаточно открыть каждый из файлов как текстовый, вручную изменить значения этих параметров и сохранить изменения в том же файле. Сделано это для того, чтобы после ремонта станка, программа не нуждалась в повторной компиляции.
Каталог "LSP" содержит группу файлов, отвечающую за визуализацию процесса обработки в пакете 3D моделирования. Часть файлов являются неизменными, они содержат базовую геометрию, которая будет преобразована в частный случай. Это система координат, взаимное положение осей, параметрическая модель патрона и заготовки. Остальные файлы предназначены для изменения базовой геометрии. Эти файлы имеют переменное содержимое, и создаются каждый раз заново. Они строят круги, реальную заготовку, патрон, содержат информацию о перемещениях рабочих органов станка.
Также особой настройки требует и пакет 3D моделирования. Необходимо создать функцию загрузки базовой и дополнительной геометрии из файла (рисунок 12).
Рисунок 12 - Создание дополнительных функций
Ссылка идет на файл, в котором прописаны ссылки на группу других файлов, что упрощает настройку. После этого необходимо прописать в пакете 3D моделирования каталог "Emul", как рабочую директорию.
На этом процесс установки завершается.
3.3 Тестирование и отладка программного модуля
Первые программные системы разрабатывались в рамках программ научных исследований или программ для нужд министерств обороны. Тестирование таких продуктов проводилось строго формализовано с записью всех тестовых процедур, тестовых данных, полученных результатов. Тестирование выделялось в отдельный процесс, который начинался после завершения кодирования, но при этом, как правило, выполнялось тем же персоналом [23].
В тестировании программного модуля можно выделить четыре этапа:
- тестирование отдельных модулей;
- совместное тестирование модулей;
- тестирование спецификации программы;
- тестирование всего комплекса в целом (т.е. поиск несоответствия созданного программного продукта сформулированным ранее целям проектирования, отраженным в техническом задании).
Модульное тестирование (юнит-тестирование) – тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками программного обеспечения.
Интеграционное тестирование – тестируются интерфейсы между компонентами, подсистемами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.
Системное тестирование – тестируется интегрированная система на её соответствие требованиям.
Альфа-тестирование – имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями и заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы специалистам по тестированию для дополнительного исследования в окружении, подобном тому, в котором будет использоваться программное обеспечение.
Бета-тестирование – в некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой группы лиц, с тем чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.
Часто для свободного (открытого) программного обеспечения стадия альфа-тестирования характеризует функциональное наполнение кода, а бета-тестирования – стадию исправления ошибок. При этом, как правило, на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.
На первых двух этапах используются, прежде всего, методы структурного тестирования, так как на последующих этапах тестирования эти методы использовать сложнее из-за больших размеров проверяемого программного обеспечения. Последующие этапы тестирования ориентированы на обнаружение ошибок различного типа, которые не обязательно связаны с логикой программы. Известны два подхода к тестированию модулей: монолитное и пошаговое тестирование.
Существующие на сегодняшний день методы тестирования программного обеспечения не позволяют однозначно и полностью выявить все дефекты и установить корректность функционирования анализируемой программы, поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого программного обеспечения. Такой процесс формальной проверки или верификации может доказать, что дефекты отсутствуют с точки зрения используемого метода.
Это означает, что нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла программного обеспечения.
Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов – это процесс, в высшей степени, творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.
С точки зрения ISO9126, качество (программных средств) можно определить как совокупную характеристику исследуемого программного обеспечения с учётом следующих составляющих:
- надёжность;
- сопровождаемость;
- практичность;
- эффективность;
- мобильность;
- функциональность.
В терминологии профессионалов тестирования, фразы тестирование "белого ящика" и тестирование "чёрного ящика" относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого программного обеспечения, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.
При тестировании белого ящика, разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования, при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.
При тестировании чёрного ящика, специалист по тестированию имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идёт правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе. Как правило, в данном виде тестирования критерий покрытия складывается из покрытия структуры входных данных, покрытия требований и покрытия модели (в тестировании на основе моделей).
При тестировании серого ящика разработчик теста имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется.
Покрытие кода, по своей сути, является тестированием методом белого ящика. Тестируемое ПО собирается со специальными настройками или библиотеками и запускается в особом окружении, в результате чего для каждой используемой (выполняемой) функции программы определяется местонахождение этой функции в исходном коде. Этот процесс позволяет разработчикам и специалистам по обеспечению качества определить части системы, которые, при нормальной работе, используются очень редко или никогда не используются (такие как код обработки ошибок и т.п.). Это позволяет сориентировать специалистам по тестированию на тестирование наиболее важных режимов.