Как организовать тестовые примеры для разных версий программного обеспечения?

Question

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

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

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

Вы знаете, что является лучшей практикой в ​​такой ситуации?

Answer 1

Я не знаю, о "лучшей практики", но вот 2 мысли:

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Он работает следующим образом: 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. Таким образом, вы создаете тестовый цикл с помощью v1 + v0 TC. И удалите дубликаты. 6. То же, что и на этапе 5 7. То же, что и на этапе 6

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

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