fez
Понятно. На данный момент я использую аналогичный подход.

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

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

Ну и самое главное. Сформировать базовые данные - не проблема. Достаточной одной общей процедуры. Все, что было сказано мной выше о трудоемкости подготовки данных, относится именно к этапу подготовки данных для каждого теста. Частично спасают конструкторы и макроконсрукторы, которые генерят "среднестатистические" данные вместе с подчиненными данными. Однако, много видов данных . Много нужно искать и вспоминать. Много писанины.

Может, я, просто, слишком ленив?

Прошу высказываться.

fez
Интересно было бы узнать подробности. Как собираешься использовать XML? Или уже не собираешься?

fez
Та-а-ак... Крайне любопытно
Насколько я понял, речь идет  о SnowTest. Так?
Какие данные ты планируешь хранить в базе-хранилище? Только базовые или более специальные?
Что содержит один хмл-файл? Один объект или целую пачку?

зы: и вобще вопросов еще масса...

fez писал(а) 02. Июня 2010 :: 07:05:

Правильный способ накатывания бэкапа в такой конструкции должен выглядеть так.
1. Накатывать бэкап только с той же конфигурацией, что и есть сейчас. Чтобы гарантированно изменились только данные.
2. После накатывания бэкапа - запустить тесты. Тогда мы сможем тут же увидеть, какие тесты поломались из-за накатанного бэкапа.

fez писал(а) 02. Июня 2010 :: 07:05:

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

artbear
В каком аспекте?
И я бы не рассматривал отчет как характерный пример для применения тестирования. Или тебя интересует именно отчет?

слегка OffTopic может быть:

сценарное тестирование я видел, на днях получу доступ к легальному центру управления полетами производительностью..

но тут напоролся на описание: http://v8.1c.ru/expert/tc/tc_overview.htm

и возникла у меня очередная бредовая идея:

а нельзя ли этот тест-центр поиспользовать в качестве средства подготовки тестовых данных.

PS. Я все таки перебрался с семьей в Москву несмотря ни на что.

lustin писал(а) 10. Июня 2010 :: 07:24:


Когда я его смотрел, это было, наверно, с год назад, "сценарное тестирование" от 1С не производило впечатления инструмента для повседневного использования.
Ты уже посмотрел? Нашел что-то полезное?