А как проводят автоматизированное тестирование когда надо комплексно протестировать приложение работающее с базой данных.
Конечно, без слоя работы с базой данных протестировать можно.
Но инетересует именно комплексное тестирование.
1) База сложная, и нагенерировать туда данные каждий раз для каждого теста сложно и долго, а потом еще и убирать за собой. Для некоторых тестов надо иметь очень много данных в базе.
2) если база уже заполнена, то непонятно, как делать проверки, ведь база живет , данные постоянно меняются.
и прочее и прочее.

Есть какие-то материалы на эту тему?

С уважением
Кочмин Александр

Здравствуйте, kochmin_alexandr, Вы писали:

_>А как проводят автоматизированное тестирование когда надо комплексно протестировать приложение работающее с базой данных.
_>Конечно, без слоя работы с базой данных протестировать можно.
_>Но инетересует именно комплексное тестирование.
_>1) База сложная, и нагенерировать туда данные каждий раз для каждого теста сложно и долго, а потом еще и убирать за собой. Для некоторых тестов надо иметь очень много данных в базе.
_>2) если база уже заполнена, то непонятно, как делать проверки, ведь база живет , данные постоянно меняются.
_>и прочее и прочее.

Никуда без тестовых данных не деться.
Подготовка и проведение тестирования в общем случае ничуть не легче,
чем проектирование и кодирование.
Так что если хочешь нормально все протестировать,
то простого пути нету. Оптимизировать кое-что конечно можно,
например генерить данные для группы тестов, а не для каждого.
Но в целом работа эта трудоемкая.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, kochmin_alexandr, Вы писали:

_>>А как проводят автоматизированное тестирование когда надо комплексно протестировать приложение работающее с базой данных.
_>>Конечно, без слоя работы с базой данных протестировать можно.
_>>Но инетересует именно комплексное тестирование.
_>>1) База сложная, и нагенерировать туда данные каждий раз для каждого теста сложно и долго, а потом еще и убирать за собой. Для некоторых тестов надо иметь очень много данных в базе.
_>>2) если база уже заполнена, то непонятно, как делать проверки, ведь база живет , данные постоянно меняются.
_>>и прочее и прочее.


Я тестирую MS SQL базу и встроенные процедуры на ней по методике Unit-тестирования.
Делаю это так
Есть процедура, которая смотрит какие в базе есть процедуры и если они начинаются на Тест_, то запускает их все по очереди. Написаны процедуры — эквиваленты assert, что проверяют равенство чисел, дат, строк, таблиц и складывают результат в таблицу. На основании данных этоой таблицы делается вывод — успешно ли прошли тесты или нет.
Перед исполенением каждого теста выполняется иниуиализцаия базы (удаление инфы и заливка insert'ами новой).
Инициализаия при количестве записей > 10000 работает медленно, подумываю о заливке bulk insert'ом, но пока обхожусь — большие таблицы как правило нет нужды заливать полностью. Если есть желание пообщаться поподробнее, пиши
sshur@mail.ru

Шурыгин Сергей

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, kochmin_alexandr, Вы писали:

_>>А как проводят автоматизированное тестирование когда надо комплексно протестировать приложение работающее с базой данных.
_>>Конечно, без слоя работы с базой данных протестировать можно.
_>>Но инетересует именно комплексное тестирование.
_>>1) База сложная, и нагенерировать туда данные каждий раз для каждого теста сложно и долго, а потом еще и убирать за собой. Для некоторых тестов надо иметь очень много данных в базе.
_>>2) если база уже заполнена, то непонятно, как делать проверки, ведь база живет , данные постоянно меняются.
_>>и прочее и прочее.

А>Никуда без тестовых данных не деться.
А>Подготовка и проведение тестирования в общем случае ничуть не легче,
А>чем проектирование и кодирование.
А>Так что если хочешь нормально все протестировать,
А>то простого пути нету. Оптимизировать кое-что конечно можно,
А>например генерить данные для группы тестов, а не для каждого.
А>Но в целом работа эта трудоемкая.

Мне тоже интересен этот вопрос. А может быть кто-нибудь пробовал сделать несколько баз данных для тестов? Сделать специальные тестовые базы данных. Написать в них пару хранимых процедур на проверку наличия необходимых данных (или юнит тесты на SQL) и при тестировании перестраивать приложение на использование той или иной базы данных? В случае если один из тестов не пройдет (и соответственно не уберет за собой) можно другой хранимой процедурой восттановить данные и продолжить остальные тесты.
Кто-нибудь пробовал такой подход? Хочется узнать работает ли он или нет.

> Я тестирую MS SQL базу и встроенные процедуры на ней по методике
> Unit-тестирования. Делаю это так
> Есть процедура, которая смотрит какие в базе есть процедуры и если они
> начинаются на Тест_, то запускает их все по очереди. Написаны процедуры -
> эквиваленты assert, что проверяют равенство чисел, дат, строк, таблиц и
> складывают результат в таблицу. На основании данных этоой таблицы
> делается вывод — успешно ли прошли тесты или нет.

тут все понятно. И тестирующие процедуры в базе это нормально.

> Перед исполенением каждого теста выполняется иниуиализцаия базы (удаление инфы и заливка
> insert'ами новой). Инициализаия при количестве записей > 10000 работает
> медленно, подумываю о заливке bulk insert'ом, но пока обхожусь — большие
> таблицы как правило нет нужды заливать полностью.

А вот заливка это не есть гуд. Заливать надо очень много, в разных вариантах и это всеравно может отличаться от реальных данных и реального порядка заливки.


С уважением
Кочмин Александр

OS> Мне тоже интересен этот вопрос. А может быть кто-нибудь пробовал
OS> сделать несколько баз данных для тестов? Сделать специальные тестовые
OS> базы данных. Написать в них пару хранимых процедур на проверку наличия
OS> необходимых данных (или юнит тесты на SQL) и при тестировании
OS> перестраивать приложение на использование той или иной базы данных?

Я думал над этим. Тут своих недостатков много.


С уважением
Кочмин Александр

А>Я тестирую MS SQL базу и встроенные процедуры на ней по методике Unit-тестирования.
А>Делаю это так
А>Есть процедура, которая смотрит какие в базе есть процедуры и если они начинаются на Тест_, то запускает их все по очереди. Написаны процедуры — эквиваленты assert, что проверяют равенство чисел, дат, строк, таблиц и складывают результат в таблицу. На основании данных этоой таблицы делается вывод — успешно ли прошли тесты или нет.
А>Перед исполенением каждого теста выполняется иниуиализцаия базы (удаление инфы и заливка insert'ами новой).

А как тестируются XP возвращающие наборы данных? Получается, необходимо создавать эталонную таблицу с данными и с которой сравнивать возвращенный из ХП результат. Покрайней мере у меня это вызывало большую проблему.

s> А как тестируются XP возвращающие наборы данных? Получается, необходимо
s> создавать эталонную таблицу с данными и с которой сравнивать
s> возвращенный из ХП результат. Покрайней мере у меня это вызывало большую
s> проблему.

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

С уважением
Кочмин Александр

Здравствуйте, kochmin_alexandr, Вы писали:

_>А как проводят автоматизированное тестирование когда надо комплексно протестировать приложение работающее с базой данных.
_>Конечно, без слоя работы с базой данных протестировать можно.
_>Но инетересует именно комплексное тестирование.
_>1) База сложная, и нагенерировать туда данные каждий раз для каждого теста сложно и долго, а потом еще и убирать за собой. Для некоторых тестов надо иметь очень много данных в базе.
_>2) если база уже заполнена, то непонятно, как делать проверки, ведь база живет , данные постоянно меняются.
_>и прочее и прочее.

_>Есть какие-то материалы на эту тему?

Можно пользоваться mock-ами. Объектами, которые только делают вид, что работают с базой, а на самом деле просто возвращают предопрелененные данные. Для этого есть специальные фреймворки. Еще можно попробовать сериализовать граф загруженный из базы, а потом десериализовать.

Здравствуйте, shev, Вы писали:

А>>Я тестирую MS SQL базу и встроенные процедуры на ней по методике Unit-тестирования.
А>>Делаю это так
А>>Есть процедура, которая смотрит какие в базе есть процедуры и если они начинаются на Тест_, то запускает их все по очереди. Написаны процедуры — эквиваленты assert, что проверяют равенство чисел, дат, строк, таблиц и складывают результат в таблицу. На основании данных этоой таблицы делается вывод — успешно ли прошли тесты или нет.
А>>Перед исполенением каждого теста выполняется иниуиализцаия базы (удаление инфы и заливка insert'ами новой).

S>А как тестируются XP возвращающие наборы данных? Получается, необходимо создавать эталонную таблицу с данными и с которой сравнивать возвращенный из ХП результат. Покрайней мере у меня это вызывало большую проблему.

Делаешь временную таблицу в которую сохраняется результат работы процедуры. Потом сравнивается с эталонной.
Могу дать пример.

Конечно, это все трудоемко, но при длительной жизни проекта окупается. Как говорится в XP — тестирование — это инвестирование в будущее.

Здравствуйте, kochmin_alexandr, Вы писали:

s>> А как тестируются XP возвращающие наборы данных? Получается, необходимо
s>> создавать эталонную таблицу с данными и с которой сравнивать
s>> возвращенный из ХП результат. Покрайней мере у меня это вызывало большую
s>> проблему.

_>а я вот думаю что это надо проверять не в базе, а в коде у себя в приложении.
_>И для проверки использовать другой способ расчета.
_>Например XP в базе вычисляет сама.
_>А у себя в программе вычисляем именно в программе, вручную собирая информацию из тех же таблиц.
_>Получается 2 независимых способа расчета.

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

S>Делаешь временную таблицу в которую сохраняется результат работы процедуры. Потом сравнивается с эталонной.
S>Могу дать пример.

С удовольствием приму пример в виде ХП (ну или как получится), как сравнивать 2 произвольных набора данных. У самого руки не дошли из-за перехода на другой проект.

Ну и коли всех понесло, то еще интересна следующая тема. Кто как готовит тестовые БД и заносит туда тестовые данные. Расскажу как делал я (на MSSQL).

Копия с разрабатываемой БД делается на автомате по ночам при помощи DTS (там можно выбрать вариант копирования объектов БД без данных, т.е. создастся пустая тестовая БД). Далее запускаются ХП заливающие данные.

Так вот, с вноской данных возникли проблемы. Слишком уж муторно готовить данные (в виде команд insert) для закачки данных (куча таблиц и все такое). Для решения проблемы поступал следующим образом: запускал клиента, подключенного к тестовой БД с уже вкаченными тестовыми данными, вводил новые данные при помощи клиенского интерфейса. А потом при помощи самодельной простенькой программы сливал данные из нужных таблиц в виде команд insert. Программа была примитивной и при увеличении числа ХП и тестовых данных собрался было создать чуть более продвинутый вариант: на входе имя сервера+бд и xml файл, описывающий процедуру выгрузки данных (нужные SQL команды перемежающие со списком таблиц и команд вставляющихся перед и после каждой строки таблицы). Сделать такое можно за пару вечеров. Но т.к. ушел на другой проект, то руки сделать утилитку не дошли. Но вскоре с текущим проектом меня опять ждет данная участь.

Вопрос. Как облегчить внос тестовых данных?

Здравствуйте, shev, Вы писали:


S>Вопрос. Как облегчить внос тестовых данных?

Я пользовался утилитой SQLInsert от lockwoodtech — генерит инсерты для таблиц(ы). Только на больших объемах это долго, как я уже говорил.
Данные берутся с работающей базы. Тут я немного от unit тестирования отступаю — тесты, сравнивающие наборы данных, пишу после написания процедур. Так тесты проще писать Чем вручную многостраничный отчет считать После того, как отчет (например) заработал, вручную проверяю его правильность, исходные данные и результаты для него загоняю в тест, и все Тест предназначен в первую очередб для того, чтобы не испортить потом этот отчет.

А сравнение двух таблиц легко через full join

----------------------------------
create table #tt (Код int, ФИО varchar(200), Пароль varchar(200), Права int)
create table #tt1(Код int, ФИО varchar(200), Пароль varchar(200), Права int)

insert into #tt1 values(1,'иванов','aa',1) --данные для сравнения

insert into #tt
exec Получить_список_пользователей

select * from #tt full join #tt1
on #tt1.Код = #tt.Код and #tt1.ФИО = #tt.ФИО and #tt1.#tt1.Код = #tt.Код = #tt.Пароль
and #tt1.Права = #tt.Права
where #tt1.Код is null or #tt.Код is null

--------------------------------------

S> Это не очень зхоорошо, поскольку при изменениях в базе требуется
S> переписывание клиентского приложения. Смысл встроенных процедур
S> теряется.

не клиентского приложения, а unit -теста.

С уважением
Кочмин Александр

S> Можно пользоваться mock-ами. Объектами, которые только делают вид, что
S> работают с базой, а на самом деле просто возвращают предопрелененные
S> данные. Для этого есть специальные фреймворки. Еще можно попробовать
S> сериализовать граф загруженный из базы, а потом десериализовать.

это понятно. Но инетересует именно тестирование с реальной базой.
Далеко не все можно выявить, поставив заглушку вместо базы.
Как саму базу тестировать?

С уважением
Кочмин Александр

Здравствуйте, kochmin_alexandr, Вы писали:

_>это понятно. Но инетересует именно тестирование с реальной базой.
_>Далеко не все можно выявить, поставив заглушку вместо базы.
_>Как саму базу тестировать?

Что значит "тестировать базу"? Данные в ней?
Домен, как раз, не корректно тестировать на живой базе. Лучше на моках, т.к. они обеспечивают большую надежность данных.
Кстати, а что именно тебе надо такое выявить, чего нельзя проверить на тестовых данных?

S> Что значит "тестировать базу"? Данные в ней?
S> Домен, как раз, не корректно тестировать на живой базе. Лучше на моках,
S> т.к. они обеспечивают большую надежность данных. Кстати, а что именно
S> тебе надо такое выявить, чего нельзя проверить на тестовых данных?

Чтоб выявить надо ОЧЕНЬ много тестовых данных.
Хотя, надо мне хорошенько подумать..

С уважением
Кочмин Александр

А какой размер у базы?

У меня был проект с тестами на 3-х мегабайтной тестовой базе — вырезка из 4G продакшн. Готовилась эталонная база — дамп из продакшн базы, дополненный тестовыми данными. Тестовые данные — сгенерённые утилитами (Toad или Excel VBA macros) insert. Далее использовался дамп эталонной базы. Заливка (drop index, drop constraints, truncate, insert, create index, create constraints) эталонной базы на удалённый сервер занимала ~30 секунд. Собственно import ~10 секунд. Было примерно 500 тестов, из которых ~100 — update, из которых часть требовала полной заливки эталона. В случае небольших изменений генерился скрипт из insert и delete, который возвращал тестовую базу в исходное состояние. Если изменений много — полная заливка. Результаты выполнения тестов выполнялись программно.

Tесты выполняются на выделенной базе. Тест исполняется по следующему сценарию
1. подготовка (изменение эталонной базы или полная заливка + изменение эталонной базы)
2. исполнение теста
3. сравнение
4. возврат к эталонной

Ну и всё это работало на java, jdbc, JUnit. DBUnit не использовали, т.к. он очень сильно тормозит при больших обьёмах (> ~100..500 записей)

Здравствуйте, kochmin_alexandr, Вы писали:

S>> Что значит "тестировать базу"? Данные в ней?
S>> Домен, как раз, не корректно тестировать на живой базе. Лучше на моках,
S>> т.к. они обеспечивают большую надежность данных. Кстати, а что именно
S>> тебе надо такое выявить, чего нельзя проверить на тестовых данных?

_>Чтоб выявить надо ОЧЕНЬ много тестовых данных.
_>Хотя, надо мне хорошенько подумать..

_>С уважением
_>Кочмин Александр

Ну дык экспортните живую базу на другой (тестовый) сервер.

s> Ну дык экспортните живую базу на другой (тестовый) сервер.

А каждому тесту за собой убирать, чего он испортил в базе?
Но тогда заливать прийдется все больше и больше.
Проблема в том. что база растет, и цифры для проверки тостов постоянно меняются.
Вот откуда их брать?
пример.
есть таблица документов.
есть тест для проверки вычисления суммы всех документов в базе.
константа для теста была одна: мы знали что всего там сумма такая-то.
Потом в следующей версии добавили новый алгоритм вычисления суммы этот алгоритм работает после определенной даты документа. Т.е. до этой даты был один алгоритм, после этой даты другой результат.
Для этого пишем новый тест, который создает еще несколько сотен документов.
И первый тест перестает проходить. Чтоб провести первый тест надо удалить новые документы, а чтоб провести второй тест, эти документы должны быть.
В результате тестовая база постоянно растет и константы для тестов постоянно меняются.
И что, переписывать все тесты каждые раз на новые константы, на новые данные в базе?

Уфф... Почти сформулировал основную проблему.


С уважением
Кочмин Александр