Вопрос, как работать с базой данных при реализации авто-тестов?
#1
Отправлено 28 мая 2013 - 12:58
#2
Отправлено 29 мая 2013 - 09:31
#3
Отправлено 11 июля 2013 - 11:52
Есть несколько вариантов:Суть в том, что проект на котором будут работать авто тесты, очень большой. Для каждого набора тестов, необходимы практически всегда, разные наборы данных в БД. Если запускать тесты по одному пакету(набор тестов для определенного раздела), то в принципе действия с БД ясны. Очищаем БД, наполняем ее всеми необходимыми значениями для тестового стенда и запускаем собственно сам пакет тестов. И тут встал вопрос, что если таких пакетов тестов несколько десятков? И все их необходимо запустить за один раз, но для каждого набор тестов, нужна своя тестовая БД. Подскажите, каким образом это можно реализовать? За ранее спасибо.
1) в каждом тесте БД восстанавливается из дампа. Это быстро, но неэффективно, т.к. если архитектура БД меняется, то дамп восстановит предыдущую архитектуру - можно получить по шапке от того, кто менял архитектуру БД.
2) иметь какой-то пул тестовых данных, который заливать на чистую БД в начале каждого теста.
3) каждый тест генерит для себя свой собственный пул данных.
Я пользуюсь третьим способом, так как в этом случае я не очищаю БД. Следовательно, могу запускать свои тесты даже на чужой БД.
Во-вторых, я не завишу от текущего состояния базы, а это очень ценно!
Производительность при этом, кстати, падает процентов на 10-20. То есть чуть-чуть.
#4
Отправлено 13 июля 2013 - 23:40
У нас БД фактически создается каждый арз при запуске тестов, при этом каждый тест имеет необходимый набор данных для формирования необходимого состояния БД, после прохождения теста таблички очищаются и следующий етст уже заполняет их нужным ему образом.
SQL для тестировщиков
Тренинги по HP QTP и автоматизации тестирования
Если минарет, значит выше всех (с)
#5
Отправлено 14 июля 2013 - 10:21
Единственное, что резануло глаз: "после прохождения теста таблички очищаются".Сергей хорошо написал.
У нас БД фактически создается каждый арз при запуске тестов, при этом каждый тест имеет необходимый набор данных для формирования необходимого состояния БД, после прохождения теста таблички очищаются и следующий етст уже заполняет их нужным ему образом.
Это хорошо, если Вы запускаете тесты только на своей тестовой БД. А если нужно будет прогнать эти тесты на БД коллеги? Я думаю, он будет очень рад, если ему очистят его наработки ;)
Из личной практики: у нас 4 БД с одинаковой архитектурой, но разным контентом. 3 БД используют тестеры (один из них - я), и одну аналитик.
Иногда приходится свои тесты прогонять на чужой БД. Если бы после прохождения теста БД очищалась, можно было бы услышать от владельца БД далеко не благодарности!
#6
Отправлено 14 июля 2013 - 13:46
Видимо, не очень точно выразился. При старте любого набора тестов создается с нуля схема в БД со всеми необходимыми табличками. Каждый тест-кейс заполняет таблички так, как ему надо, перед следующим тест-кейсом происходит truncate табличек.Единственное, что резануло глаз: "после прохождения теста таблички очищаются".
Сергей хорошо написал.
У нас БД фактически создается каждый арз при запуске тестов, при этом каждый тест имеет необходимый набор данных для формирования необходимого состояния БД, после прохождения теста таблички очищаются и следующий етст уже заполняет их нужным ему образом.
Это хорошо, если Вы запускаете тесты только на своей тестовой БД. А если нужно будет прогнать эти тесты на БД коллеги? Я думаю, он будет очень рад, если ему очистят его наработки ;)
Так что БД коллег, равно как и мою собственную это никоим образом не затрагивает.
SQL для тестировщиков
Тренинги по HP QTP и автоматизации тестирования
Если минарет, значит выше всех (с)
#7
Отправлено 15 июля 2013 - 05:14
А можно поинтересоваться: по времени как?Видимо, не очень точно выразился. При старте любого набора тестов создается с нуля схема в БД со всеми необходимыми табличками. Каждый тест-кейс заполняет таблички так, как ему надо, перед следующим тест-кейсом происходит truncate табличек.
Так что БД коллег, равно как и мою собственную это никоим образом не затрагивает.
Как я понял, у Вас при запуске происходит создание новой схемы с чистыми табличками. Каждый тест перед выполнением наполняет таблицы своим контентом, а после выполнения транкейтит их всех.
А со схемой что происходит?
Плюс, у Вас, очевидно, есть права на создание новой схемы.
Кстати, а насколько большая схема?
У меня 214 таблиц. Практически все (возможно несколько - исключение) имеют референсы на другие таблицы.
В моём случае, думаю, было бы нецелесообразно при каждом прогоне генерить новую схему со всем этим монстром из таблиц. Как Вы считаете?
#8
Отправлено 15 июля 2013 - 05:39
Для маленьких приложений мне нравится следующая схема:
* Есть типизация стендов. В частности выделены тестовые стенды. К тестовым стендам имеют доступ тестировщики и администраторы. Но не программисты.
* Есть шаблон стенда (как вариант - потушенная виртуальная машина) версии 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 терабайт
То все совсем не так хорошо.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#9
Отправлено 15 июля 2013 - 05:41
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#10
Отправлено 30 января 2014 - 11:47
Подниму тему. Возникла аналогичная проблема.
Есть кейсы, которые зависят друг от друга, например: Registration -> Send message
Нужно чтобы эти тесты были как независимы.
Варианты:
1. Прогонять все подряд (и не зацикливаться над независимостью тестами :) )
2. Перед каждым кейсом выполнять необходимые ему API.
Первый тест: Registration
Второй тест: Registration and Send message
3. Перед каждым кейсом вставлять в базу необходимые данные
Хотя второй вариант не сильно отличается от первого на самом деле...
Проект небольшой, таблиц в базе немного. Пока остановились на 3 варианте.
Интересует, насколько так делать верно, и как делают другие. И как надо :)
#11
Отправлено 30 января 2014 - 19:26
Подниму тему. Возникла аналогичная проблема.
Есть кейсы, которые зависят друг от друга, например: Registration -> Send message
Нужно чтобы эти тесты были как независимы.
Варианты:
1. Прогонять все подряд (и не зацикливаться над независимостью тестами :) )
2. Перед каждым кейсом выполнять необходимые ему API.
Первый тест: Registration
Второй тест: Registration and Send message
3. Перед каждым кейсом вставлять в базу необходимые данные
Хотя второй вариант не сильно отличается от первого на самом деле...
Проект небольшой, таблиц в базе немного. Пока остановились на 3 варианте.
Интересует, насколько так делать верно, и как делают другие. И как надо :)
Похожая ситуация иногда бывает.
И всё же я пользуюсь вторым вариантом.
Причина: тесты на регистрацию (у меня не регистрация, но применительно к Вашему случаю использую это понятие) содержат не только позитивные тесты, но и негативные. В результате после прохождения первого "сьюта" по регистрации данные в БД настолько исковерканы, что использовать их корректно в дальнейшем очень затруднительно. Гораздо проще для второго сьюта (по отсылке сообщений) создать заново корректную/хорошую/чистую регистрацию и дальше играться с тестами из второго сьюта.
Говоря языком тестировщика, этап регистрации во втором сьюте является прекондишеном.
В силу того, что кейсы, по-хорошему, должны быть независимы друг от друга, прекондишен-регистрацию использовать "не мона, а нуна!"
#12
Отправлено 31 января 2014 - 07:27
Спасибо за ответ. Я тоже начала сначала писать тесты именно по второму варианту. Но начали рефакторить Регистрацию (я тоже взяла абстрактные кейсы), все остальное работает. А тесты получается не функциональны вообще, т.к. для всех кейсов прекондишном была именно регистрация.
Нужно понять что подразумевается под независимыми тестами - независимые от предыдущего кейса, или независимые от всех других апи.
#13
Отправлено 31 января 2014 - 09:06
Ненужно абсолютизировать независимость тестов - это в разы снижает КПД. Новая "регистрация" на каждый "чих" - это бред.
#14
Отправлено 31 января 2014 - 09:15
Ненужно абсолютизировать независимость тестов - это в разы снижает КПД. Новая "регистрация" на каждый "чих" - это бред.
на набор тестов.
Есть у тебя сьют, требующий наличие зарегистрированного юзера.
Ты либо ищешь в БД существующую регистрацию и её используешь, что не совсем корректно, т.к. БД может быть пустой, либо для всего сьюта (или в т.ч. нескольких последующих) делаешь одну прекондишн-регистрацию (или несколько прекондишн-регистраций, если нужны разные параметры зарегистрированных).
На каждый "чих" - действительно, бред!
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных