Тестирование программного обеспечения в РТИ

Программное обеспечение RTI лежит в основе многих критически важных программ системы. Наши клиенты, конечно же, глубоко заботятся о надежности и качестве своих систем. Итак, когда я встречаюсь с клиентами и представляю процесс разработки RTI, мы обсуждаем методы разработки, инструменты, которые мы используем, и лабораторию RTI IIoT. Многих особенно интересует тестирование программного обеспечения, которое мы проводим в RTI, и используемые нами тестовые среды. Мне всегда нравятся эти разговоры; мы гордимся своим вниманием к тестированию. В этом сообщении блога кратко излагается проведенное нами тестирование.

Наш процесс разработки и тестирования является общим для всего набора продуктов RTI Connext. Исключением является RTI Connext DDS CERT, предназначенный для приложений, требующих сертификации безопасности, и использующий другой процесс разработки. Во время разработки и до того, как RTI выпустит какое-либо новое программное обеспечение, мы проводим большую серию тестов, чтобы проверить правильность работы и убедиться, что программное обеспечение работает и хорошо масштабируется.

Модульные тесты убедитесь, что отдельные функции работают должным образом. Модульные тесты используются в качестве ключевого механизма регрессионного тестирования при каждом выпуске продукта. Фреймворк модульного тестирования делает больше, чем просто тестирует отдельные функции. Это также позволяет проводить тестирование функций одного узла. В более поздних выпусках мы даже включали предоставляемые заказчиком параметры качества обслуживания (QoS) как часть нашей тестовой конфигурации. Наши процессы предназначены для обеспечения правильного функционирования в максимально реалистичной среде.

В рамках разработки новой функции мы создаем план тестирования функций и реализуем набор сквозных тестов функций . . Эти тесты реализуются с помощью специального набора тестов или, в случае Connext DDS Micro, в новой среде распределенного тестирования. В этой тестовой среде используются несколько «участников тестирования», которые выполняют тесты на разных машинах, и «диспетчер тестов», который синхронизирует выполнение тестов между участниками тестирования. Для описания тестов был разработан простой тестовый язык DDS, и каждый исполнитель тестов выполняет сценарий, публикует результаты (PASS / FAIL) и ожидает выполнения следующего сценария. Основное внимание в функциональных тестах уделяется:

• Тестирование API уровня приложения и политик QoS DDS (крайний срок, работоспособность и т. д.)
• Проверить ограничения ресурсов
• Проверить обратный порядок байтов.
• Тестовое открытие
• Производительность теста
• Обеспечьте стабильность

Мы проводим различные уровни тестирования совместимости:

• Мы тестируем совместимость с другими продуктами RTI . во время разработки и во время тестирования установки. Мы разработали набор автоматических тестов на совместимость. Например, Connext 6 представил ряд новых функций, общих для библиотек Connext DDS Micro 3.0 и Connext DDS core 6.0. Мы автоматически сгенерировали тысячи комбинаций конфигурации и проверили правильное поведение. Совместимость со старыми версиями RTI проверяется, когда мы после анализа определяем, что существует риск нарушения совместимости.
• Совместимость языков делается косвенно, поскольку некоторые из наших инструментов написаны на Java или других языках. Например, мы тестируем совместимость с Java-приложением при использовании Java-инструментов RTI, таких как RTI Admin Console, в сочетании с приложениями на других языках.
• Базовый уровень взаимодействия с другими поставщиками DDS регулярно проводится на собраниях DDS Object Management Group (OMG). Поставщики координируют более подробный набор тестов для проверки безопасности DDS, расширяемых типов и проводного протокола DDS-RTPS (https://github.com/omg-dds).

Установить тесты захватить тестирование интеграции и взаимодействия нескольких продуктов. Эти тесты запускаются как вручную, так и с помощью набора тестов автоматической установки. Тестирование установки охватывает широкий спектр вопросов интеграции и взаимодействия:

• Установка - Все ли файлы правильно установлены?
• Графический интерфейс пользователя (GUI) - В настоящее время нет автоматизированного тестирования графического интерфейса. Во время тестирования установки вручную мы проверяем правильность работы интеграции:например, между RTI Launcher и rtiddsgen , или rtiprototyper .
• Документация - Правильная ли документация отправлена?
• Тестирование базовой функциональности для всех продуктов с использованием поставляемых примеров. Для некоторых продуктов мы просматриваем все Руководство по началу работы. Это тестирование повторяется на разных платформах.
• Базовое тестирование совместимости продуктов и языков .

Чтобы ускорить и расширить эти тесты, у нас есть автоматическое тестирование установки . для многих функций. Текущие тесты охватывают:

• Установка - проверьте файлы, чтобы убедиться, что файлы установлены правильно.
• Запуск утилит, включая rtiddsping , rtiddsspy и rtiprototyper.
• Запуск сгенерированных rtiddsgen примеров на C, C ++, C ++ 03, C ++ 11, C ++ CLI, C # и Java с использованием комбинации статических / динамических библиотек и библиотек DDS выпуска / отладки.
• Запуск поставляемых примеров с использованием комбинации статических / динамических библиотек и библиотек DDS для выпуска / отладки.
• Примеры производительности на C ++ и Java.
• Примеры TCP-доставки на C.

Эти тесты выполняются на 80 различных архитектурах, включая платформы Windows, Linux, Solaris, Lynx, QNX, Darwin и VxWorks.

У нас есть множество тестов производительности и профилирования памяти. Создание достоверного и содержательного распределенного теста производительности является чрезвычайно сложной задачей. Простые подходы не могут обрабатывать или даже грубо измерить компромиссы между буферами, пропускной способностью, задержкой, доставкой в ​​реальном времени, стеками и операционной системой. RTI имеет обширный опыт в оценке показателей производительности, наиболее важных для реальных систем.

• Модульные тесты собирают информацию о производительности и памяти для определенных функций.
• Мы используем наш тест производительности (perfTest) для характеристики производительности Connext DDS. У нас большие инвестиции в perfTest, поэтому он может делать реалистичные измерения. Его можно использовать вместе с другими продуктами, такими как Routing Service. Мы используем PerfTest для сбора общедоступных данных о задержке и пропускной способности. Результаты производительности доступны по адресу https://www.rti.com/products/dds/benchmarks.html.
• memTest был создан для отслеживания использования памяти Connext DDS Core. Connext DDS Micro собирает подробную информацию об объеме памяти в рамках модульных тестов.
• Другие приложения, такие как RTI Admin Console и RTI Recording Service, имеют встроенные возможности мониторинга производительности.

Непрерывная интеграция PerfTest и MemTest гарантирует, что мы не регрессируем (сверх установленного процента) по мере добавления новых функций в продукт Connext DDS.

Тесты на выносливость имитируйте длительные сценарии. Тесты на долговечность отслеживают динамическую память в различных сценариях динамического использования, таких как создание и удаление удаленных участников или создание и удаление удаленных конечных точек. Платформа тестирования на выносливость также работает с подключаемыми модулями безопасности RTI в случае использования нечеткого теста, когда пакеты RTPS изменяются случайным образом. Тесты выполняются с самой последней общедоступной версией (GAR).

Масштабное и стресс-тестирование специально создан как часть разработки новых функций. Например, когда мы представили транспортную мобильность (также известную как IP-мобильность), мы создали набор тестов для имитации подключения и отключения от различных точек беспроводного доступа. Когда мы улучшили реализацию обнаружения, мы создали специальную тестовую среду, чтобы моделировать тысячи конечных точек и автоматически проверять, что они были обнаружены каждым приложением. Как правило, эти тесты не повторяются с каждым выпуском, отчасти из-за требований к оборудованию и сети. Некоторые тесты (например, крупномасштабный тест обнаружения) повторно запускаются, когда мы вносим изменения в реализацию обнаружения.

Наш продукт мощный и сложный, он должен работать в удивительном множестве еще более сложных приложений. Поэтому, конечно, мы не можем протестировать каждый сценарий или найти все возможные проблемы. Но мы уверены, что у нас есть одна из самых обширных программ тестирования в отрасли.

[1] [2] 下一页