восстановление базы данных в определенное состояние для тестирования

Мы используем базу данных Oracle (или postgres) и сервер приложений для выполнения интеграционных тестов. Чтобы изолировать каждый тест от другого, схема базы данных удаляется и создается заново перед каждым тестом.

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

(Похоже, что DBUnit может это сделать, я еще не пробовал.)

Одно испытание включает в себя:

  • создать схему базы данных.
  • Запустите сервер приложений.
  • Запустите несколько клиентских приложений.
  • Выполнить и проверить.

У нас есть 5000 нечетных тестов, занимающих 700 часов или около того. (мы делаем это в сетке, заканчиваем за ночь)

В большинстве тестов используются небольшие размеры данных, скажем, до 10 МБ.


postgresql integration-testing oracle dbunit
person Jayan    schedule 18.02.2011    source источник

Ответы (6)


arrow_upward
4
arrow_downward

Oracle Flashback позволяет восстановить таблицу в указанный момент времени с помощью простого SQL-запроса. Документация доступна здесь.

Я не знаю, есть ли у Postgre аналогичная функция.

person Benoit    schedule 18.02.2011
comment
Какую производительность вы увидели при использовании ретроспективного кадра Oracle? - person Piran; 03.12.2013

arrow_upward
4
arrow_downward

Какая версия Oracle (предприятие 10g+ или стандартная)? Предполагая, что вы используете Enterprise, вы можете использовать базу данных Flashback. Вы создаете свою базовую БД. Затем

create a guaranteed restore point
run your test
capture results somewhere outside the database
flashback database to restore point
start over

Этого должно быть достаточно, чтобы вы начали. Если вам нужны дополнительные подробности, дайте мне знать.

person erbsock    schedule 18.02.2011

arrow_upward
2
arrow_downward

Я думаю, что для PostgreSQL использование шаблонной базы данных быстрее, чем повторное создание всех таблиц по отдельности.

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

При выполнении теста отбросьте базу данных, которую вы хотите протестировать. Затем заново создайте тест, используя шаблон.

DROP DATABASE my_test_db;
CREATE DATABASE my_test_db WITH TEMPLATE my_template_db;

В 9.0 были некоторые оптимизации, которые ускорили бы это. Так что, возможно, этот подход быстрее, чем повторное создание всех таблиц через SQL.

person a_horse_with_no_name    schedule 18.02.2011

arrow_upward
2
arrow_downward

Для Oracle вы можете использовать этот пакет pl/sql: snapshot.sql

У нас 500 таблиц, 30 из которых восстанавливаются после каждого теста, и в среднем это занимает ~500мс.

Использование предельно простое:

EXECUTE SNAPSHOT.TAKE_SNAPSHOT('snapshot name');
EXECUTE SNAPSHOT.RESTORE_SCHEMA('snapshot name');
person Amir Hadadi    schedule 07.04.2015

arrow_upward
1
arrow_downward

Если каждый тест умещается в одну транзакцию, можно просто откатиться. Это вариант?

person Konrad Garus    schedule 18.02.2011
comment
Ну это зависит. В общем, я бы не советовал. Некоторые действия происходят только при попытке зафиксировать транзакцию. Выполнение автоматического отката может контролировать возникающие тогда проблемы. - person Grzegorz Oledzki; 18.02.2011
comment
мы используем такие функции, как отложенные ограничения, что делает важным вызов фиксации. Да, тестирование могло быть с вашим подходом - person Jayan; 05.03.2011

arrow_upward
1
arrow_downward

Вопросы

  • О какой базе данных идет речь?
  • Это размер Multi-T или всего несколько G?
  • Сколько данных в нем?
  • Как определяются ограничения?
  • Как быстро это нужно сделать?
  • Сколько времени длятся ваши тесты? (несколько дней или несколько недель)
  • Сколько памяти доступно?
  • Сколько обновлений делается во время теста?
  • Какая версия базы данных у вас есть?

Предложения

  • Если у вас достаточно места для хранения и не так много обновлений, попробуйте базу данных ретроспективного обзора.
  • Если вы тестируете копии базы данных prod, используйте клонирование (и, конечно же, маскирование данных) (также хороший тест для резервной копии prod).
  • Если у вас есть хорошая тестовая база данных с ценными тестовыми данными, используйте резервное копирование/восстановление.
  • Если у вас есть база данных версии 11g, сконфигурированная с физической резервной базой данных, вы можете попробовать протестировать базу данных моментальных снимков.
person ik_zelf    schedule 18.02.2011