Тестирования миргации данных
#1
Отправлено 12 октября 2013 - 16:48
Меня очень интересует теоритическая база тестирования миграции больших объемов даных условно из таблиц с одой структурой, в таблицы с другой структурой, с применением различных трансформаций.
Нпаример, как протестировать сей процесс; как определить степень качества(допустим согласовано, что 95% данных будет перенесено верно - то как определить, что 95% всетаки перенесено и перенесено верно); вохможно существуют специальные методологии\приемы при тестированиии большиъ объемов данных?
Возможно удастся указать книгу или линку, буду очень благодарен.
Заранее спасибо!
#2
Отправлено 12 ноября 2013 - 09:24
Не следует заставлять тестировщиков тестировать быстрее. Что может быть хуже испуганных, усталых, цинично настроенных тестировщиков?
-----------------
Хорошо, когда человек заводит баги. Плохо, когда баги заводят человека (с)
-----------------
Проект для начинающих тестировщиков Хомячки
#3
Отправлено 12 ноября 2013 - 11:01
Техники есть. Но вот описанные... Такого вроде еще нет. Может стоит оформить этот материал?Привет.
Меня очень интересует теоритическая база тестирования миграции больших объемов даных условно из таблиц с одой структурой, в таблицы с другой структурой, с применением различных трансформаций.
Нпаример, как протестировать сей процесс; как определить степень качества(допустим согласовано, что 95% данных будет перенесено верно - то как определить, что 95% всетаки перенесено и перенесено верно); вохможно существуют специальные методологии\приемы при тестированиии большиъ объемов данных?
Возможно удастся указать книгу или линку, буду очень благодарен.
Заранее спасибо!
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#4
Отправлено 13 ноября 2013 - 06:01
У нас на проекте написана утилитка миграции данных из базы одной структуры в базу другой, с настраиваемым маппингом полей. Она была написана в связи с переходом с одной версии приложения на преписанную
Мы создавали по одному объекту (подвергающемуся миграции) каждого типа со всем заполненными свойствами и мигрировали сначала их.
Далее мы все свойства объектов разделяли по типам: текстовые, числовые, кодовые и т.д и создавали базы, в которых эти свойства принимали различные значения(валидные, невалидные, граничные и т.п.)
Потом мигрировали полностью реальные базы заказчиков, на которых проверялся основной функционал приложения.
Вкратце как-то так мы справлялись)
#5
Отправлено 18 ноября 2013 - 17:36
Техники есть. Но вот описанные... Такого вроде еще нет. Может стоит оформить этот материал?
Мой скромный голос ЗА, вкупе с большим пожаааааалуйста!!! Я сейчас как раз занимаюсь изобретением велосипедов для тестирования последствий глобальной миграции. Было бы очень интересно сравнить мои решения с чьими-нибудь еще best practices.
@Артем Б.:
"перенесено верно" есть по сути своей нетестируемое требование, может быть поэтому у вас и возникают проблемы с его тестированием? ;-)
Тестируемый критерий был бы сформулирован примерно так: "На каждое правило миграции определен как минимум один тест. Как минимум 95% из запланированных тестов выполнены и пройдены успешно". Объекты тестирования и глубину их покрытия уточнять по мере необходимости :-)
А если уточнения требований получить не удастся, то выборка методом научного тыка и сравнение 100 объектов вполне адекватная методика тестирования. Если в 95 случаях все мигрированные данные в старой и новой системе совпадают с учетом применяемых правил трансформации, то вы требование по качеству выполнили. Главное, чтобы заказчик подписался, что он согласен с такой методикой проверки.
#6
Отправлено 16 октября 2014 - 08:49
@EEV
@Артем Б.:
"перенесено верно" есть по сути своей нетестируемое требование, может быть поэтому у вас и возникают проблемы с его тестированием? ;-)
Тестируемый критерий был бы сформулирован примерно так: "На каждое правило миграции определен как минимум один тест. Как минимум 95% из запланированных тестов выполнены и пройдены успешно". Объекты тестирования и глубину их покрытия уточнять по мере необходимости :-)
А если уточнения требований получить не удастся, то выборка методом научного тыка и сравнение 100 объектов вполне адекватная методика тестирования. Если в 95 случаях все мигрированные данные в старой и новой системе совпадают с учетом применяемых правил трансформации, то вы требование по качеству выполнили. Главное, чтобы заказчик подписался, что он согласен с такой методикой проверки.
Перенесено верно - это самое первое требование. К примеру, мы работаем с базой данных билинговой системы. Тут нельзя ошибиться.
про рандомные выборки все очень туманно. Допустим у вас в таблице 1тыс записей. можно используя классы эквивалентности, к примеру, разбить записи на группы и проверить по несколько из кажой. Но это тривиальная БД. Представьте БД состоящую из 100+ таблиц по 100тыс+ записей в 50% таблиц, все таблицы связаны между собой ключами. Тут мы встречаемся с проблемой уже на фазе разбиения на группы, я уже не говорю о том, что мы не можем себе позвонить протестировать менее одного процента даных, чтобы скзаать, что остальные 99 работают.
Я имел в виду именно большие объемы данных, с маленькими то понятно, что можно "затрайхардить" :)
У нас есть уже подход общепринятый, но я не знаю из какой книги его взяли и есть ли более новые методологии, бест практис и тд и тп. В общем хотелось обсудить этот вопрос с коллегами не из компании :)
Спасибо всем за ответы.
#7
Отправлено 14 февраля 2016 - 20:49
Сначала нужно определиться с критериями на сколько Вам важно, точно знать что сейчас скажем 95% соответствие?
Если имеете дело с деньгами, то потеря даже одной записи критично!!! Таким образом критерий для Вас не количественный, а качественный - верно / неверно перенесены счета.
Если же перенесены данные о температуре за прошлый год и допустимо что-то потерять, то идете по исходной базе (считаете количество записей) и сверяетесь с результатом (при не соответствии увеличиваете счетчик отказов).
На случай больших объемов вероятно задачу следует разделить на несколько подзадач (смотрите в сторону распределенных вычислений). Работает примерно так же, но следует в конце суммировать результаты. Тут больше вероятность допустить ошибку.
Подскажите, а чего Вы хотите достигнуть этим обсуждением? Сократить время работы теста? Или что вообще нужно?
#8
Отправлено 15 февраля 2016 - 08:13
Сначала нужно определиться с критериями на сколько Вам важно, точно знать что сейчас скажем 95% соответствие?
Если имеете дело с деньгами, то потеря даже одной записи критично!!! Таким образом критерий для Вас не количественный, а качественный - верно / неверно перенесены счета.
Если же перенесены данные о температуре за прошлый год и допустимо что-то потерять, то идете по исходной базе (считаете количество записей) и сверяетесь с результатом (при не соответствии увеличиваете счетчик отказов).
На случай больших объемов вероятно задачу следует разделить на несколько подзадач (смотрите в сторону распределенных вычислений). Работает примерно так же, но следует в конце суммировать результаты. Тут больше вероятность допустить ошибку.
Подскажите, а чего Вы хотите достигнуть этим обсуждением? Сократить время работы теста? Или что вообще нужно?
Вопрос 13-го года...вы думаете он еще актуален? :)
Не следует заставлять тестировщиков тестировать быстрее. Что может быть хуже испуганных, усталых, цинично настроенных тестировщиков?
-----------------
Хорошо, когда человек заводит баги. Плохо, когда баги заводят человека (с)
-----------------
Проект для начинающих тестировщиков Хомячки
#9
Отправлено 15 февраля 2016 - 08:49
Некропостинг, как назвал это дело Алексей Баранцев))
Но тему затронули интересную.
Если имеете дело с деньгами, то потеря даже одной записи критично!!! Таким образом критерий для Вас не количественный, а качественный - верно / неверно перенесены счета.
С чего вы взяли, что именно имея дело с деньгами потеря одной записи критична?
Допуск в 5% может подразумевать, что остаток проще сделать руками, чем пытаться справиться автоматизацией.
#10
Отправлено 15 февраля 2016 - 14:11
Некропостинг, как назвал это дело Алексей Баранцев))
Но тему затронули интересную.
Если имеете дело с деньгами, то потеря даже одной записи критично!!! Таким образом критерий для Вас не количественный, а качественный - верно / неверно перенесены счета.
С чего вы взяли, что именно имея дело с деньгами потеря одной записи критична?
Допуск в 5% может подразумевать, что остаток проще сделать руками, чем пытаться справиться автоматизацией.
Моя мысль заключалась в том, что даже для корректировки руками нужно будет перебрать все записи в хранилище.
Для подсчета тех самых "95%" процентов.
P.S. Можно более подробно объяснить, что имелось в виду "пытаться справиться автоматизацией"?
#11
Отправлено 15 февраля 2016 - 15:30
екропостинг, как назвал это дело Алексей Баранцев))
Но тему затронули интересную.
Если имеете дело с деньгами, то потеря даже одной записи критично!!! Таким образом критерий для Вас не количественный, а качественный - верно / неверно перенесены счета.
С чего вы взяли, что именно имея дело с деньгами потеря одной записи критична?
Допуск в 5% может подразумевать, что остаток проще сделать руками, чем пытаться справиться автоматизацией.
Я это взял из условий задачи, а именно "миграции больших объемов данных" (это как неопределенность из мат. анализа, бесконечно большое), тогда даже 5% от бесконечно большого это бесконечно много записей и это противоречит утверждению "может подразумевать, что остаток проще сделать руками". Тут для меня очевиден перенос технической сложности разработки/тестирования на плечи "оператора", который из-за технических "сложностей" будет вбивать бесконечно большое число записей руками.
Теперь когда немного разобрались надо понять что для заказчика важно и значимо: стоимость, время и задача вообщем дальше в этом направлении не очень интересна и формально решена.
А мне интересно было поразмыслить над экономии на условии в 95%, что можно "выиграть" за счет этого требования? Я вижу только возможность не получать из базы 5% записей и как результат менее точную метрику "как минимум 5% может быть неверными".
Все остальные техники уже инженерные и построены на увеличении производительности (всякие техники вроде деление задачи на подзадачи и выполнение в параллель), что есть просто увеличение скорости процессинга записей.
#12
Отправлено 16 февраля 2016 - 07:43
Может быть автор темы поделится в итоге сакральными знаниями? Очень было бы интересно!
"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс
#13
Отправлено 16 февраля 2016 - 15:48
Я это взял из условий задачи, а именно "миграции больших объемов данных" (это как неопределенность из мат. анализа, бесконечно большое),
Вот это вы зря. Мы живем в реальном мире и большинство наших задач конечно. Да, база может быть большая или очень большая, но она физически где-то расположена и вполне конечна. И автор даже ничего не указал про время:) Значит ему нужен инструмент, а не быстрый инструмент))
Расскажу с чем сталкивался.
У Заказчика есть N филиалов, там суммарно стоит M АИСок.
M<N.
АИС работаю в одном ключе и занимаются примерно одной и той же задачей, но каждая со своими нюансами.
Задача - разработать единую АИС, в которую потом будут вливаться старые данные.
Была найдена самая распространенная Система и по ее подобию сделана новая. Формат данных в БД согласован и перенесен.
Далее для каждого нового типа АИС делался маппинг данных и конвертация в новый формат. Трудоемкая задача для разработчика.
Правильность переноса данных была узаконена как 95% от старой БД.
Проверка выполнялось так:
- В БД есть данные и алгоритмы. Алгоритмы проверялись руками.
- В старой БД и в новой запускался механизм пересчета (условное название операции) и шла сверка результатов. <95% - корректируем скрипты и конвертим еще раз. 95+ - все ок, некорректные записи в отдельный лог и на ручную обработку.
#14
Отправлено 18 февраля 2016 - 17:48
Трудоемкая задача для разработчика.
Ну трудоемкость для разработчика это очень сомнительная единица измерения, а вот "стоимость" в деньгах этих самых 5% совсем другое дело.
И тут как я уже раньше говорил, нужно вообразить весы и понять сколько "золота" нужно отдать разработчику за систему с 100% отображением (то есть убрать эти самые самые 5%),
а на другие весы стоимость работы персонала и работы в ручную по этим 5%. Если данных много, то работы в ручную будет много, а это значит, что это перенос ответственности за
некачественный/недоделанный/дешёвый/ленивый/недоделанный код на плечи других сотрудников, что в их договоре изначально не было прописано - проверять в ручную
записи, которые ленивый программист не отобразил в базу. Как черт возьми это вообще возможно пропустить 5% записей? Вообщем тут задача очень подозрительная. Чувствую,
что где-то "собак зарыта", но вот так сразу не совсем очевижно.
#15
Отправлено 19 февраля 2016 - 14:39
Ну конечно, разработчики ленивые, тестировщики плохие и только сотрудники Заказчика все в белом и на конях)
Трудоемкая задача означает, что у разработчика уходило до нескольких месяцев на одну базу.
Точность в 5% была согласована и утверждена на уровне договора, так что ваши подозрения излишни.
Отобразить в базе можно все! А вот учесть это все в расчетах дело другое.
Количество аттрибутов в БД идет на сотни. И в нашей БД и в той, которую конвертим к нам.
Понятно, что количество в точной степени никогда не совпадает. Что-то мапится легко, что-то после долгого изучения, а что-то в итоге оказывается вообще не требуется конвертировать в новый формат.
#16
Отправлено 20 февраля 2016 - 15:57
Ну конечно, разработчики ленивые, тестировщики плохие и только сотрудники Заказчика все в белом и на конях)
Я этого не говорил, а только обратил внимание, на то что "технический долг" был "узаконен" и перенесен на "заказчика".
Прошу заметить только разобрался с ситуацией, а этические аспекты вопроса меня в этой ситуации меня мало заботят.
Трудоемкая задача означает, что у разработчика уходило до нескольких месяцев на одну базу.
Видимо это очень дорого оказалось для заказчика ))) А как нашли значенеи в 5%? На основе каких-то вычислений или взяли число с "потолка"?
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных