Как организовать тестовые случаи для разных версий ПО?

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

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

  1. Создавайте новые наборы тестов для новых версий, но это приведет к дублированию тестовых примеров, а использование большого количества наборов тестов для большого количества версий создает огромную путаницу.
  2. Создайте новый проект для новой версии, скопируйте все наборы тестов и тестовые наборы и измените их. Это привело бы к огромному дублированию.
  3. В тестовых примерах используйте поле Milestone или Version. Но есть тестовые примеры, которые используются одновременно для нескольких версий.
  4. Используйте 2 поля для версий: От версии и До версии. Чтобы отметить этот тестовый пример, используется от версии 1 до версии 3. Это привело бы к огромному количеству тестовых примеров в каждом наборе, но фильтры можно было бы использовать.

Вы знаете, что лучше всего делать в такой ситуации?


testing testcase testrail qa
person Ferenc Papp    schedule 05.12.2014    source источник

Ответы (4)


arrow_upward
1
arrow_downward

Для этого вы можете использовать функцию Baseline в TestRail.

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

person testworks    schedule 03.08.2016

arrow_upward
0
arrow_downward

Я не знаю насчет «лучших практик», но вот две мысли:

  1. Я бы выбрал №2, продублирую все. Вы должны сосредоточить внимание на последней версии (стволе), в которой вы постоянно адаптируете / реорганизуете свои тесты. Вы также управляете своей старой версией, но вам придется так часто обновлять тесты, потому что можно ожидать, что продукт не будет сильно меняться. Я думаю, что попытка использовать один и тот же тест для разных версий продукта (с тегами, полями и т. Д.) Приведет к путанице.

  2. Когда QA использует тестовые примеры, написанные на языке программирования и сохраненные в SCM, то обычно создается столько веток, сколько продукта. Так что дублирование есть, но кого это волнует, слияниями вы управляете с помощью SCM. Вот почему я думаю, что вы могли бы каким-то образом следовать такой схеме.

person Laurent Bristiel    schedule 06.12.2014

arrow_upward
0
arrow_downward

Мое решение состоит в том, чтобы проверять тестовые примеры в том же репозитории, в котором находится код. Ваши тесты в любой данной ветке всегда должны работать для этой ветки. Когда вы вносите изменения в код, вы вносите изменения в тесты, и они навсегда остаются синхронизированными.

person Bryan Oakley    schedule 03.08.2016

arrow_upward
0
arrow_downward

Я предлагаю использовать тестовые экземпляры (тестовые прогоны / тестовые выполнения / тестовые циклы, каждый инструмент иногда имеет собственное имя) для выполнения.

Это работает так: 1. У вас есть TC для функциональных модулей 1, 2, 3. Все помечены как v0. 2. Вы получаете обновления для модуля 1, поэтому вам необходимо протестировать его вместе со старой функциональностью (модули 2, 3). Это будет ваш v1. 3. Вы получаете обновления для модуля 2, поэтому вам необходимо протестировать его вместе со старой функциональностью (модули 1, 3). Это будет ваш v2. 4. Общий тест сборки с модулями 1, 2, 3. Это будет ваш v3. 5. Вы обновляете процедуру тестирования для модуля 2 (или даже при необходимости пишете новый TC). Таким образом, обновленный TC будет иметь v0 / v1 (этапы тестирования должны содержать обе охватываемые версии). Новый будет иметь то же имя, но v1. Итак, вы строите свой тестовый цикл с TC v1 + v0. И удалите дубликаты. 6. То же, что и в шаге 5 7. То же, что и в шаге 6

В конце концов вы все проверили. Сохраненные результаты теста. Недостаток отмечен соответствующей версией. Дубликаты только для новых результатов (не нужно создавать новый тестовый костюм со ВСЕМИ TC для каждой версии). Устаревшие TC из v0 могут быть удалены вручную.

Чтобы быть более понятным с термином экземпляра теста, см. TestLab в ALM (HP QC), Циклы тестирования в Jira + Zephyr.

person Sergii M    schedule 29.09.2017