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

[Артем Б.]

Привет.

Меня очень интересует теоритическая база тестирования миграции больших объемов даных условно из таблиц с одой структурой, в таблицы с другой структурой, с применением различных трансформаций.
Нпаример, как протестировать сей процесс; как определить степень качества(допустим согласовано, что 95% данных будет перенесено верно - то как определить, что 95% всетаки перенесено и перенесено верно); вохможно существуют специальные методологии\приемы при тестированиии большиъ объемов данных?

Возможно удастся указать книгу или линку, буду очень благодарен.

Заранее спасибо!

[clipsa]

Хороший вопрос. Не сталкивалась с такой необходимостью. На ум приходит только выборочная выборка (прошу прощения за тавтологию) данных из старой и новой структуры и их сравнение какой-нибудь авто-сравнивалкой.

[SALar]

Привет.

Меня очень интересует теоритическая база тестирования миграции больших объемов даных условно из таблиц с одой структурой, в таблицы с другой структурой, с применением различных трансформаций.
Нпаример, как протестировать сей процесс; как определить степень качества(допустим согласовано, что 95% данных будет перенесено верно - то как определить, что 95% всетаки перенесено и перенесено верно); вохможно существуют специальные методологии\приемы при тестированиии большиъ объемов данных?

Возможно удастся указать книгу или линку, буду очень благодарен.

Заранее спасибо!

Техники есть. Но вот описанные... Такого вроде еще нет. Может стоит оформить этот материал?

[ksyundelek]

Привет.

У нас на проекте написана утилитка миграции данных из базы одной структуры в базу другой, с настраиваемым маппингом полей. Она была написана в связи с переходом с одной версии приложения на преписанную более лучшую и как следствие необходимостью поддержки старых данных новым приложением.
Мы создавали по одному объекту (подвергающемуся миграции) каждого типа со всем заполненными свойствами и мигрировали сначала их.
Далее мы все свойства объектов разделяли по типам: текстовые, числовые, кодовые и т.д и создавали базы, в которых эти свойства принимали различные значения(валидные, невалидные, граничные и т.п.)
Потом мигрировали полностью реальные базы заказчиков, на которых проверялся основной функционал приложения.

Вкратце как-то так мы справлялись)

[EEV]

Техники есть. Но вот описанные... Такого вроде еще нет. Может стоит оформить этот материал?

Мой скромный голос ЗА, вкупе с большим пожаааааалуйста!!! Я сейчас как раз занимаюсь изобретением велосипедов для тестирования последствий глобальной миграции. Было бы очень интересно сравнить мои решения с чьими-нибудь еще best practices.

@Артем Б.:
"перенесено верно" есть по сути своей нетестируемое требование, может быть поэтому у вас и возникают проблемы с его тестированием? ;-)

Тестируемый критерий был бы сформулирован примерно так: "На каждое правило миграции определен как минимум один тест. Как минимум 95% из запланированных тестов выполнены и пройдены успешно". Объекты тестирования и глубину их покрытия уточнять по мере необходимости :-)

А если уточнения требований получить не удастся, то выборка методом научного тыка и сравнение 100 объектов вполне адекватная методика тестирования. Если в 95 случаях все мигрированные данные в старой и новой системе совпадают с учетом применяемых правил трансформации, то вы требование по качеству выполнили. Главное, чтобы заказчик подписался, что он согласен с такой методикой проверки.

[Артем Б.]

@EEV

 

@Артем Б.:
"перенесено верно" есть по сути своей нетестируемое требование, может быть поэтому у вас и возникают проблемы с его тестированием? ;-)

Тестируемый критерий был бы сформулирован примерно так: "На каждое правило миграции определен как минимум один тест. Как минимум 95% из запланированных тестов выполнены и пройдены успешно". Объекты тестирования и глубину их покрытия уточнять по мере необходимости :-)

А если уточнения требований получить не удастся, то выборка методом научного тыка и сравнение 100 объектов вполне адекватная методика тестирования. Если в 95 случаях все мигрированные данные в старой и новой системе совпадают с учетом применяемых правил трансформации, то вы требование по качеству выполнили. Главное, чтобы заказчик подписался, что он согласен с такой методикой проверки.

 

 

Перенесено верно - это самое первое требование. К примеру, мы работаем с базой данных билинговой системы. Тут нельзя ошибиться.

про рандомные выборки все очень туманно. Допустим у вас в таблице 1тыс записей. можно используя классы эквивалентности, к примеру, разбить записи на группы и проверить по несколько из кажой. Но это тривиальная БД. Представьте БД состоящую из 100+ таблиц по 100тыс+ записей в 50% таблиц, все таблицы связаны между собой ключами. Тут мы встречаемся с проблемой уже на фазе разбиения на группы, я уже не говорю о том, что мы не можем себе позвонить протестировать менее одного процента даных, чтобы скзаать, что остальные 99 работают.

Я имел в виду именно большие объемы данных, с маленькими то понятно, что можно "затрайхардить" :)

 

У нас есть уже подход общепринятый, но я не знаю из какой книги его взяли и есть ли более новые методологии, бест практис и тд и тп. В общем хотелось обсудить этот вопрос с коллегами не из компании :)

 

Спасибо всем за ответы.

[vit1251]

Сначала нужно определиться с критериями на сколько Вам важно, точно знать что сейчас скажем 95% соответствие?

 

Если имеете дело с деньгами, то потеря даже одной записи критично!!! Таким образом критерий для Вас не количественный, а качественный - верно / неверно перенесены счета.

 

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

 

На случай больших объемов вероятно задачу следует разделить на несколько подзадач (смотрите в сторону распределенных вычислений). Работает примерно так же, но следует в конце суммировать результаты. Тут больше вероятность допустить ошибку.

 

Подскажите, а чего Вы хотите достигнуть этим обсуждением? Сократить время работы теста?  Или что вообще нужно?

[clipsa]

Сначала нужно определиться с критериями на сколько Вам важно, точно знать что сейчас скажем 95% соответствие?

 

Если имеете дело с деньгами, то потеря даже одной записи критично!!! Таким образом критерий для Вас не количественный, а качественный - верно / неверно перенесены счета.

 

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

 

На случай больших объемов вероятно задачу следует разделить на несколько подзадач (смотрите в сторону распределенных вычислений). Работает примерно так же, но следует в конце суммировать результаты. Тут больше вероятность допустить ошибку.

 

Подскажите, а чего Вы хотите достигнуть этим обсуждением? Сократить время работы теста?  Или что вообще нужно?

Вопрос 13-го года...вы думаете он еще актуален? :)

[Vasiliy]

Некропостинг, как назвал это дело Алексей Баранцев))

Но тему затронули интересную.

 

 

Если имеете дело с деньгами, то потеря даже одной записи критично!!! Таким образом критерий для Вас не количественный, а качественный - верно / неверно перенесены счета.

 

С чего вы взяли, что именно имея дело с деньгами потеря одной записи критична?

Допуск в 5% может подразумевать, что остаток проще сделать руками, чем пытаться справиться автоматизацией.

[vit1251]

Некропостинг, как назвал это дело Алексей Баранцев))

Но тему затронули интересную.

 

 

Если имеете дело с деньгами, то потеря даже одной записи критично!!! Таким образом критерий для Вас не количественный, а качественный - верно / неверно перенесены счета.

 

С чего вы взяли, что именно имея дело с деньгами потеря одной записи критична?

Допуск в 5% может подразумевать, что остаток проще сделать руками, чем пытаться справиться автоматизацией.

 

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

Для подсчета тех самых "95%" процентов.

 

P.S. Можно более подробно объяснить, что имелось в виду "пытаться справиться автоматизацией"?

[vit1251]

екропостинг, как назвал это дело Алексей Баранцев))

Но тему затронули интересную.

 

 

Если имеете дело с деньгами, то потеря даже одной записи критично!!! Таким образом критерий для Вас не количественный, а качественный - верно / неверно перенесены счета.

 

С чего вы взяли, что именно имея дело с деньгами потеря одной записи критична?

Допуск в 5% может подразумевать, что остаток проще сделать руками, чем пытаться справиться автоматизацией.

 

Я это взял из условий задачи, а именно "миграции больших объемов данных" (это как неопределенность из мат. анализа, бесконечно большое), тогда даже 5% от бесконечно большого это бесконечно много записей и это противоречит утверждению "может подразумевать, что остаток проще сделать руками". Тут для меня очевиден перенос технической сложности разработки/тестирования на плечи "оператора", который из-за технических "сложностей" будет вбивать бесконечно большое число записей руками.

 

Теперь когда немного разобрались надо понять что для заказчика важно и значимо: стоимость, время и задача вообщем дальше в этом направлении не очень интересна и формально решена.

 

А мне интересно было поразмыслить над экономии на условии в 95%, что можно "выиграть" за счет этого требования? Я вижу только возможность не получать из базы 5% записей и как результат менее точную метрику "как минимум 5% может быть неверными".

 

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

[Сергей]

Может быть автор темы поделится в итоге сакральными знаниями? Очень было бы интересно!

[Vasiliy]

Я это взял из условий задачи, а именно "миграции больших объемов данных" (это как неопределенность из мат. анализа, бесконечно большое),

 

 

 

Вот это вы зря. Мы живем в реальном мире и большинство наших задач конечно. Да, база может быть большая или очень большая, но она физически где-то расположена и вполне конечна. И автор даже ничего не указал про время:) Значит ему нужен инструмент, а не быстрый инструмент))

 

Расскажу с чем сталкивался.

У Заказчика есть N филиалов, там суммарно стоит M АИСок.

M<N.

АИС работаю в одном ключе и занимаются примерно одной и той же задачей, но каждая со своими нюансами.

Задача - разработать единую АИС, в которую потом будут вливаться старые данные.

Была найдена самая распространенная Система и по ее подобию сделана новая. Формат данных в БД согласован и перенесен.

Далее для каждого нового типа АИС делался маппинг данных и конвертация в новый формат. Трудоемкая задача для разработчика.

Правильность переноса данных была узаконена как 95% от старой БД.

Проверка выполнялось так:

1.  В БД есть данные и алгоритмы. Алгоритмы проверялись руками.
2. В старой БД и в новой запускался механизм пересчета (условное название операции) и шла сверка результатов. <95% - корректируем скрипты и конвертим еще раз. 95+ - все ок, некорректные записи в отдельный лог и на ручную обработку.

[vit1251]

 

Трудоемкая задача для разработчика.

 

Ну трудоемкость для разработчика это очень сомнительная единица измерения, а вот "стоимость" в деньгах этих самых 5% совсем другое дело.

 

И тут как я уже раньше говорил, нужно вообразить весы и понять сколько "золота" нужно отдать разработчику за систему с 100% отображением (то есть убрать эти самые самые 5%),

а на другие весы стоимость работы персонала и работы в ручную по этим 5%. Если данных много, то работы в ручную будет много, а это значит, что это перенос ответственности за

некачественный/недоделанный/дешёвый/ленивый/недоделанный код на плечи других сотрудников, что в их договоре изначально не было прописано - проверять в ручную

записи, которые ленивый программист не отобразил в базу. Как черт возьми это вообще возможно пропустить 5% записей? Вообщем тут задача очень подозрительная. Чувствую,

что где-то "собак зарыта", но вот так сразу не совсем очевижно.

[Vasiliy]

Ну конечно, разработчики ленивые, тестировщики плохие и только сотрудники Заказчика все в белом и на конях)

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

Точность в 5% была согласована и утверждена на уровне договора, так что ваши подозрения излишни.

 

Отобразить в базе можно все! А вот учесть это все в расчетах дело другое.

 

Количество аттрибутов в БД идет на сотни. И в нашей БД и в той, которую конвертим к нам.

Понятно, что количество в точной степени никогда не совпадает. Что-то мапится легко, что-то после долгого изучения, а что-то в итоге оказывается вообще не требуется конвертировать в новый формат.

[vit1251]

 

 

Ну конечно, разработчики ленивые, тестировщики плохие и только сотрудники Заказчика все в белом и на конях)

Я этого не говорил, а только обратил внимание, на то что "технический долг" был "узаконен" и перенесен на "заказчика".

Прошу заметить только разобрался с ситуацией, а этические аспекты вопроса меня в этой ситуации меня мало заботят.

 

 

 

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

 

Видимо это очень дорого оказалось для заказчика ))) А как нашли значенеи в 5%? На основе каких-то вычислений или взяли число с "потолка"?