Фреймворк интеграционного тестирования?

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

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

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

и

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

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

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


person Rob McCready    schedule 23.04.2009    source источник


Ответы (1)


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

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

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

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

Так что ты мог...

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

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

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

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

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

С уважением,

--хойссер

person Matthew Heusser    schedule 13.05.2009
comment
Больше, чем просто набор параметров командной строки. Не на веб-сайте. Я пошел с половинчатым внутренним инструментом №1. XML-файлы определений, простые свойства и списки тестов с несколькими типами контейнеров (все, ни один, любой должен пройти). Клиент в вашем # 2/3 — это наша команда QA. У меня нет времени, чтобы снова освоить perl/ruby или научить этому кого-то еще, не говоря уже о развертывании инструментов для них. Я хотел бы переместить их в сторону тестирования на основе кода, но прямо сейчас мне нужен инструмент-мост. Принимаю, поскольку других ответов нет, и это подтверждает, что других инструментов нет. - person Rob McCready; 21.05.2009