Автоматизация тестирования совместимости со многими программами

Краткая версия: как лучше всего автоматизировать тестирование совместимости с большим количеством сторонних программ?

Детали:

Я разрабатываю программу, основная функция которой - взаимодействие с различными программами музыкального проигрывателя через соответствующие интерфейсы RPC. . Сам RPC обычно выполняется либо через D-Bus, либо через некоторую клиентскую библиотеку, специфичную для конкретного игрока. Поскольку каждый музыкальный проигрыватель имеет свой собственный уникальный интерфейс RPC, моей программе требуется специальный код для обработки каждого из них.

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

Сами тестовые примеры не являются проблемой; это просто вопрос вызова последовательности функций в интерфейсе RPC игрока и проверки возвращаемых значений и / или асинхронных обратных вызовов для ожидаемого результата. Нет, проблема в наличии фреймворка для автоматического запуска тестов.

Вот проблемы, которые я вижу:

  • Каждый проигрыватель поддерживает постоянное состояние, обычно в виде файлов точек в домашнем каталоге пользователя. Состояние состоит из таких вещей, как музыкальная библиотека, списки воспроизведения и т. Д. Эти файлы необходимо вернуть в известное начальное состояние перед каждым тестом. (Удалить его полностью - не всегда вариант, поскольку в этом случае проигрыватели с графическим интерфейсом пользователя представят мастер настройки при следующем запуске вместо обычного запуска.)

  • Эти начальные состояния могут быть частично динамическими. Например, музыкальная библиотека будет содержать полные пути к музыкальным файлам внутри нее, но пути к фактическим «музыкальным» файлам, используемым для тестирования, будут различаться от машины к машине и не будут известны до времени выполнения.

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

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

Что я хотел бы сделать, так это настроить виртуальную машину с кучей разных игроков (и кучей разных версий каждого проигрывателя), а затем иметь возможность автоматически тестировать свою программу на каждом из них. В идеале, кто-то другой мог бы настроить свою собственную виртуальную машину для запуска тестов в себе, по-видимому, нужно только сообщить тестовой среде, какие плееры и где установлены.

Итак, как лучше всего автоматизировать тестирование совместимости с большим количеством (несколькими десятками) сторонних программ?

Если это влияет на рекомендации, моя программа написана на Python, и я использую автоинструменты GNU в качестве среды сборки.


person Paul Kuliniewicz    schedule 20.07.2010    source источник


Ответы (1)


Если это только среда Windows, есть один выход - использовать MS Hyper-V.

Ссылка (http://www.microsoft.com/virtualization/en/us/solution-application-development.aspx)

У них есть поддержка создания образа, например, установки Vista, а также создания сценария для его новой копии и вставки установки в новый образ, при этом базовая установка + добавленное программное обеспечение запускаются и запускаются в течение нескольких минут.

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

Большая проблема в том, что это стоит немалых денег, а Hyper-V - довольно сложный в настройке продукт.

В качестве альтернативы, возможно, можно было бы использовать Virtual Box (с открытым исходным кодом) и написать свой собственный сценарий для автоматизации установки образа с новыми версиями программного обеспечения для тестирования. Я сделал это с помощью стандартного сценария чтения изображений при запуске из сетевой папки, чтобы установить любое программное обеспечение для тестирования. Это не полностью автоматизированное решение, но сэкономило моей команде много времени.

person StefanE    schedule 10.09.2010
comment
Это Linux, поэтому Hyper-V не подходит. В итоге я настроил виртуальную машину (с использованием kvm) с моими различными целями, установленными параллельно, с настраиваемым тестовым набором для сброса их конфигураций для каждого теста. Я надеялся, что для этого есть какой-нибудь существующий инструмент, так как создание ремня безопасности было нетривиальной задачей. - person Paul Kuliniewicz; 11.09.2010