Сообщений в теме: 13

[Sadnes]

Суть в том, что проект на котором будут работать авто тесты, очень большой. Для каждого набора тестов, необходимы практически всегда, разные наборы данных в БД. Если запускать тесты по одному пакету(набор тестов для определенного раздела), то в принципе действия с БД ясны. Очищаем БД, наполняем ее всеми необходимыми значениями для тестового стенда и запускаем собственно сам пакет тестов. И тут встал вопрос, что если таких пакетов тестов несколько десятков? И все их необходимо запустить за один раз, но для каждого набор тестов, нужна своя тестовая БД. Подскажите, каким образом это можно реализовать? За ранее спасибо.

[Vasiliy]

Мы работаем через снапшоты виртуальной машины с БД.

[Petrov.Sergey]

Суть в том, что проект на котором будут работать авто тесты, очень большой. Для каждого набора тестов, необходимы практически всегда, разные наборы данных в БД. Если запускать тесты по одному пакету(набор тестов для определенного раздела), то в принципе действия с БД ясны. Очищаем БД, наполняем ее всеми необходимыми значениями для тестового стенда и запускаем собственно сам пакет тестов. И тут встал вопрос, что если таких пакетов тестов несколько десятков? И все их необходимо запустить за один раз, но для каждого набор тестов, нужна своя тестовая БД. Подскажите, каким образом это можно реализовать? За ранее спасибо.

Есть несколько вариантов:
1) в каждом тесте БД восстанавливается из дампа. Это быстро, но неэффективно, т.к. если архитектура БД меняется, то дамп восстановит предыдущую архитектуру - можно получить по шапке от того, кто менял архитектуру БД.
2) иметь какой-то пул тестовых данных, который заливать на чистую БД в начале каждого теста.
3) каждый тест генерит для себя свой собственный пул данных.

Я пользуюсь третьим способом, так как в этом случае я не очищаю БД. Следовательно, могу запускать свои тесты даже на чужой БД.
Во-вторых, я не завишу от текущего состояния базы, а это очень ценно!
Производительность при этом, кстати, падает процентов на 10-20. То есть чуть-чуть.

[ch_ip]

Сергей хорошо написал.
У нас БД фактически создается каждый арз при запуске тестов, при этом каждый тест имеет необходимый набор данных для формирования необходимого состояния БД, после прохождения теста таблички очищаются и следующий етст уже заполняет их нужным ему образом.

[Petrov.Sergey]

Сергей хорошо написал.
У нас БД фактически создается каждый арз при запуске тестов, при этом каждый тест имеет необходимый набор данных для формирования необходимого состояния БД, после прохождения теста таблички очищаются и следующий етст уже заполняет их нужным ему образом.

Единственное, что резануло глаз: "после прохождения теста таблички очищаются".
Это хорошо, если Вы запускаете тесты только на своей тестовой БД. А если нужно будет прогнать эти тесты на БД коллеги? Я думаю, он будет очень рад, если ему очистят его наработки ;)

Из личной практики: у нас 4 БД с одинаковой архитектурой, но разным контентом. 3 БД используют тестеры (один из них - я), и одну аналитик.
Иногда приходится свои тесты прогонять на чужой БД. Если бы после прохождения теста БД очищалась, можно было бы услышать от владельца БД далеко не благодарности!

[ch_ip]

Сергей хорошо написал.
У нас БД фактически создается каждый арз при запуске тестов, при этом каждый тест имеет необходимый набор данных для формирования необходимого состояния БД, после прохождения теста таблички очищаются и следующий етст уже заполняет их нужным ему образом.

Единственное, что резануло глаз: "после прохождения теста таблички очищаются".
Это хорошо, если Вы запускаете тесты только на своей тестовой БД. А если нужно будет прогнать эти тесты на БД коллеги? Я думаю, он будет очень рад, если ему очистят его наработки ;)

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

[Petrov.Sergey]

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

А можно поинтересоваться: по времени как?
Как я понял, у Вас при запуске происходит создание новой схемы с чистыми табличками. Каждый тест перед выполнением наполняет таблицы своим контентом, а после выполнения транкейтит их всех.
А со схемой что происходит?

Плюс, у Вас, очевидно, есть права на создание новой схемы.
Кстати, а насколько большая схема?
У меня 214 таблиц. Практически все (возможно несколько - исключение) имеют референсы на другие таблицы.
В моём случае, думаю, было бы нецелесообразно при каждом прогоне генерить новую схему со всем этим монстром из таблиц. Как Вы считаете?

[SALar]

Существует множество хороших вариантов, применимых для разных систем.

Для маленьких приложений мне нравится следующая схема:
* Есть типизация стендов. В частности выделены тестовые стенды. К тестовым стендам имеют доступ тестировщики и администраторы. Но не программисты.
* Есть шаблон стенда (как вариант - потушенная виртуальная машина) версии N. Имя пусть будет tpl_test-A_v-N. Возможно, несколько с разными наборами данных и/ или прав доступа.
* Операция изменения шаблона (в части данных, прав доступа и т.д.) - весьма деликатная и в общем случае доступ к шаблону открыт только на чтение.

1. С шаблона делается копия тестового стенда. tpl_test-A_v-N -> test_test-A_v-N
2. На копию накатывается апгрейд test_test-A_v-N -> test_test-A_v-N+1
3. при необходимости правятся данные, ...
4. Гоняются тесты.
5. test_test-A_v-N+1 уничтожается
Если все нормально, то
1. С шаблона делается копия шаблона. tpl_test-A_v-N -> tpl_test-A_v-N'
2. На копию шаблона накатывается апгрейд tpl_test-A_v-N' -> tpl_test-A_v-N+1 и получается шаблон следующей версии.

Все это хорошо, пока приложение маленькое. А вот если:
* у вас сотня клиентов и у каждого своя версия.
* пустая БД (без данных) весит 10 гигов
* минимально работоспособная тестовая база 1 терабайт
То все совсем не так хорошо.

[SALar]

И да, для энтерпрайз приложений вполне возможна ситуация, когда создать схему БД скриптами невозможно. Потому что этих скриптов нет, а их создание - это многолетняя задача.

[Jay]

Подниму тему. Возникла аналогичная проблема.

Есть кейсы, которые зависят друг от друга, например: Registration -> Send message

 

Нужно чтобы эти тесты были как независимы.

 

Варианты:

1. Прогонять все подряд (и не зацикливаться над независимостью тестами :) )

2. Перед каждым кейсом выполнять необходимые ему API.

Первый тест: Registration

Второй тест: Registration and Send message

3. Перед каждым кейсом вставлять в базу необходимые данные

Хотя второй вариант не сильно отличается от первого на самом деле...

 

Проект небольшой, таблиц в базе немного. Пока остановились на 3 варианте.

Интересует, насколько так делать верно, и как делают другие. И как надо :)

[Petrov.Sergey]

Подниму тему. Возникла аналогичная проблема.

Есть кейсы, которые зависят друг от друга, например: Registration -> Send message

 

Нужно чтобы эти тесты были как независимы.

 

Варианты:

1. Прогонять все подряд (и не зацикливаться над независимостью тестами :) )

2. Перед каждым кейсом выполнять необходимые ему API.

Первый тест: Registration

Второй тест: Registration and Send message

3. Перед каждым кейсом вставлять в базу необходимые данные

Хотя второй вариант не сильно отличается от первого на самом деле...

 

Проект небольшой, таблиц в базе немного. Пока остановились на 3 варианте.

Интересует, насколько так делать верно, и как делают другие. И как надо :)

Похожая ситуация иногда бывает.

И всё же я пользуюсь вторым вариантом.

Причина: тесты на регистрацию (у меня не регистрация, но применительно к Вашему случаю использую это понятие) содержат не только позитивные тесты, но и негативные. В результате после прохождения первого "сьюта" по регистрации данные в БД настолько исковерканы, что использовать их корректно в дальнейшем очень затруднительно. Гораздо проще для второго сьюта (по отсылке сообщений) создать заново корректную/хорошую/чистую регистрацию и дальше играться с тестами из второго сьюта.

Говоря языком тестировщика, этап регистрации во втором сьюте является прекондишеном.

В силу того, что кейсы, по-хорошему, должны быть независимы друг от друга, прекондишен-регистрацию использовать "не мона, а нуна!"

[Jay]

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

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

[vmaximv]

Ненужно абсолютизировать независимость тестов - это в разы снижает КПД. Новая "регистрация" на каждый "чих" - это бред.

[Petrov.Sergey]

Ненужно абсолютизировать независимость тестов - это в разы снижает КПД. Новая "регистрация" на каждый "чих" - это бред.

на набор тестов.

Есть у тебя сьют, требующий наличие зарегистрированного юзера.

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

 

На каждый "чих" - действительно, бред!