Автоматические тесты и множественные конфигурации

Я использую Microsoft Test Manager 2012 для создания и запуска как автоматических, так и ручных тестов. Я определил 2 конфигурации: одну для моих тестов, которые должны запускаться на SQL Server, и одну для тестов, которые должны выполняться на Oracle.

Когда я создаю тестовый пример, MSTM автоматически создает два теста: один для Sql Server и один для Oracle. У них одинаковый идентификатор, что означает, что это один и тот же тест. Все идет нормально. Вот что должно произойти.

Но я хочу автоматизировать оба теста. Когда я создаю свой код и связываю его с тестовым примером, оба теста получают автоматизированный код. Это плохо, потому что я хочу, чтобы тест 1 выполнялся на SQL, а тест 2 - на Oracle, и они используют один и тот же тестовый код.

Означает ли это, что я должен добавить некоторую логику в свои тесты, чтобы они знали, в какой базе данных им следует работать? Есть ли лучший способ избежать этого?


tfs coded-ui-tests microsoft-test-manager
person Rafael Colucci    schedule 22.10.2013    source источник
comment
Есть ли у вас разные среды для запуска автоматических тестов: одна для SQLServer, другая для Oracle? Вы хотите использовать один и тот же тестовый код для обоих (просто используя разные соединения с БД)? (Я не уверен, что вы имеете в виду, говоря, что тест 1 и тест 2 используют один и тот же код. Насколько эти тесты идентичны?)   -  person Elena    schedule 23.10.2013
comment
Другой вопрос, как вы собираетесь запускать автоматические тесты? Используете шаблон определения сборки DefaultLabTemplate11 или вызываете tcm.exe из командной строки (пакетный сценарий)?   -  person Elena    schedule 23.10.2013
comment
@Elena У меня только 1 среда для запуска моих тестов. Я хочу использовать один и тот же тестовый код для обоих, используя разные соединения с БД или другой метод. Я использую DefaultLabTemplate11, но могу его изменить.   -  person Rafael Colucci    schedule 23.10.2013

Ответы (1)


arrow_upward
1
arrow_downward

Вариант 1
Создайте два разных тестовых случая, один для SQLServer и один для Oracle, а затем сначала для автоматизации с помощью Test1 , а второй - Test2. Таким образом, вы можете запустить оба из них с помощью одного определения сборки, использующего DefaultLabTemplate11.

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

Вы сказали, что хотите использовать Test Case как для ручного, так и для автоматического тестирования, поэтому я полагаю, что Test Case, который у вас есть сегодня, состоит из нескольких шагов тестирования , описывающий, как запускать тесты вручную.
В этом случае вы можете клонировать существующий Test Case и использовать общие этапы тестирования, но вам все равно потребуется обновить оба < em> Test Cases, когда вы добавляете / удаляете некоторые Test Steps ... это будет единственным недостатком предлагаемого подхода.

Чтобы избавиться от этого недостатка, вы можете создать «Ручные тесты базы данных» Контрольный пример, назначить ему две Конфигурации, которые у вас уже есть, и использовать его только для ручных тестов. Этот тестовый набор будет содержать все шаги тестирования для тестировщика.
Затем создайте два тестовых набора, которые я описал выше, автоматизируйте их и используйте их только для автоматизированных тестов.

Вариант 2
Если ваша тестовая среда представляет собой виртуальную машину, вы можете избежать создания двух тестовых случаев:

  1. Сохраните строку подключения в файле в тестовой среде и позвольте тесту прочитать этот файл.
  2. Создайте два снимка: первый - с файлом, содержащим строку подключения SQLServer, второй - со строкой подключения Oracle.
  3. Создайте два определения сборки: одно возвращает среду к первому снимку, а второе - ко второму снимку.

Таким образом, вы можете сохранить свой единственный Test Case, но, с другой стороны, наличие двух определений сборки может стать неудобным, если определение сборки должно собирать исходный код перед развертыванием и запуском тестов.

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

(Надеюсь, мне удалось это хорошо описать, не стесняйтесь спрашивать, что-то все еще не ясно).

person Elena    schedule 24.10.2013