Интеграционные тестовые рамки?

Question

Я ищу тестовый фреймворк, чтобы покрыть наши тесты интеграции черного ящика. Нам нужно что-то, что может быть написано сценарием не разработчиками (иначе говоря, не модульным тестом типа C#).

Начальные сценарии, которые я имею в виду:

1. Восстановить известную БД
2. Выполнить задание агента sql (ETL)
3. Выполнить валидацию SQL-скриптов для выходной БД

а также

1. Запустите MSI установить
2. Проверьте наличие Папок / Файлов /RegKeys/ Сервисов / и т. Д.
3. запустить MSI удалить

Пока что я не нашел ничего подходящего. В основном тестирование пользовательского интерфейса (Project White/etc), которое мы будем использовать, но не охватывает эти случаи. Или интеграционное тестирование, основанное на модульном тестировании, которое мы пока не готовы подтолкнуть нашей командой по обеспечению качества.

В настоящее время я экспериментирую над созданием нашего собственного внутреннего инструмента для этой части тестирования, если я не могу найти ничего другого.

Answer 1

Похоже, вы хотите запустить кучу параметров командной строки, верно?

Ну, я вижу два способа сделать это:

1) вы можете изобрести свой собственный язык для конкретного домена. Это причудливый способ сказать, что вы пишете интерпретатор с некоторыми очень очень высокоуровневыми функциями. Нетехнические люди пишут что-то вроде командных файлов, а вы пишете некоторый C#, который читает файл, выполняет оператор switch, а затем запускает команды. FIT, пожалуй, самый распространенный способ сделать это - это фреймворк для интегрированных тестов. (Способ сделать это - разделить вещи запятыми: command,param1,param2. Представьте, что это невероятно простая программа на ассемблере. Тогда ваш оператор switch принимает param1..paramx и помещает их в массив строк и передает их функции. Функция обрабатывает массив.)

Проблема в том, что ваши клиенты будут хотеть переменные. Они захотят зацикливаться. И довольно скоро вы внедрили полный в Турине программный интерпретатор, который считывает данные в формате columner. Разит.

Так что вы могли бы...

2) Научите своих клиентов языку сценариев. Я бы посмотрел на perl и протестировал::more - или, возможно, некоторые из рубиновых тестов.

И если это не сработает, возможно, вы могли бы...

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

Если бы вы управляли браузером, я бы порекомендовал селен или watIR, но похоже, что вы из командной строки.

Напишите мне письмо ([e-mail]) или прочитайте о тестовых фреймворках в моем блоге (xndev.blogspot.com) для получения дополнительной информации. Мой блог - это результат поиска №2, по которому я спрашиваю Google, что такое тестовый фреймворк.:-)

С уважением,

--heusser