В преддверии конференции Heisenbug мы поговорили о тонкостях нагрузочного тестирования с Владимиром vladimirsitnikov Ситниковым (уже 10 лет работает над производительностью и масштабируемостью Netсracker OSS — ПО, используемого операторами связи для автоматизации процессов управления сетью и сетевым оборудованием, увлекается вопросами производительности Java и Oracle Database) и Андреем real_ales Дмитриевым (java-программист, разрабатывал JDK в компании Sun и Oracle, руководил командой разработки под Android в QuickOffice. В компании Netcracker создавал и затем руководил подразделением, занимающимся нагрузочным тестированием OSS-платформы (Java, OracleDB, JMeter, etc.)).
JUG.ru: Расскажите, пожалуйста, о своей работе и той роли, которую играет в ней нагрузочное тестирование.
Андрей Дмитриев: До недавнего времени я обеспечивал качество решений компании Netcracker с точки зрения производительности, выносливости и масштабируемости.
Netcracker — внедренная у многих телеком-операторов платформа, почти на 100% написанная на Java. Создана она давно и работает с огромным количеством сторонних железок и софта. Поэтому есть возможность экспериментировать с совершенно разными кейсами — производительностью сети, фронтэндом, SQL-запросами и тому подобное. То есть у нас не просто есть один кейс, который мы все время решаем. Кейсы все время новые, поэтому интересные.
Моей задачей был поиск проблем в решениях Netcracker. При обнаружении проблемы я проводил поверхностный анализ, снабжал ее дополнительными деталями, снимал необходимые метрики (делал дампы) и, условно говоря, передавал задачу перформанс-инженеру.
Владимир Ситников: Я — перформанс-архитектор. Моя задача — как раз анализ результатов замеров, а также выработка рекомендаций, какие замеры лучше провести, чтобы увидеть проблемы того или иного класса. Для решения проблем обычно надо не только провести эти замеры, но и понять результаты. Поэтому я изо дня в день занимаюсь тем, что смотрю в облако цифр и пытаюсь выудить из него какую-то полезную информацию.
Стоит отметить, что не всегда проблема и задача приходят с тестов. Иногда приходится разбираться с инцидентами, возникающими в реальных боевых системах. В этом случае, имея взгляд на проблему с двух ракурсов (из тестового окружения и production), необходимо ее быстро воспроизводить и исправлять.
JUG.ru: С каких вопросов, на ваш взгляд, должно начинаться нагрузочное тестирование? Можно ли выделить несколько самых важных?
Андрей: На мой взгляд, неважных вопросов здесь не бывает. Каждый вопрос может ключевым образом повлиять на процесс тестирования и разработки.
Однако всегда надо начинать с того, что заказчик ожидает от разрабатываемой системы. Для этого проводится анализ существующей системы или модели, которая есть у заказчика: какие данные он будет мигрировать, какие сценарии выполнять, какие данные использовать, на каком железе все это будет работать.
Но реальность наша такова, что мы начинаем тестирование, как только получаем первую информацию о проекте. Естественно, если у нас нет бинарников, мы ничего тестировать не можем. Но мы можем проводить анализ и подготовку данных, строить планы. Информацию о железе, на котором решение будет работать, об архитектуре и задействованных данных, о сценариях собирается инкрементально, и с каждой новой порцией информации мы корректируем свою работу по подготовке и проведению тестирования.
Никогда не бывает так, что мы собрали все данные и следующие 3 месяца тестировали без каких-либо отклонений от разработанного на старте плана. Всегда вносятся какие-то комментарии.
Например, мы взяли решение, начали его тестировать, для чего попросили ИТ-команду развернуть дефолтный проект (как мы обычно разворачиваем). После развертывания провели первую итерацию тестирования, и вдруг оказывается, что подход был совершенно неправильный, потому что вместо двух нод нам надо было построить кластер. В итоге мы полностью снесли все тестовое окружение и переконфигурировали железку в соответствии с новой информацией, которую получили.
Сложности тестирования enterprise-приложений
JUG.ru: Подводные камни при тестировании enterprise-приложений — назовите, пожалуйста, пару наиболее очевидных.
Андрей: Это не подводные камни, это целое минное поле.
Я уже сказал, что каждый элемент в тесте может иметь ключевое значение, он может в корне перевернуть наше представление о процессе тестирования, поменять или полностью перечеркнуть результаты. Соответственно, грабли есть на каждом шагу.
Первое и наиболее частое — ошибка в цифрах. К примеру, заказчик может не понимать, какая у него есть нагрузка. Он делает некую базовую модель, которую мы получаем на вход, чтобы составить план тестирования. Но в какой-то момент оказывается, что цифры были подсчитаны не совсем точно или мы эти цифры неправильно трактовали. Например, есть кейс какого-то сервиса, а у него есть подкейс этого же сервиса с дополнением.
Заказчик посчитал, что все это — один кейс, а по факту пользователь запускает эти кейсы по-разному (т.е. кейсы попадают в разную статистику). Получается, заказчик может считать, что кейс исполняется 100 тыс. раз, а по факту пользователи создают его 200 тыс. раз.
Второй момент: очень часто мы сталкиваемся с отсутствием всех необходимых прав для тестирования на оборудовании заказчика. И тут начинается… Нам требуется поставить фреймворк для тестирования, для этого нужно получить 100500 согласований, потом нужно получить доступ к базе данных и т.п. и т.д. Без необходимых прав приходится изворачиваться.
Например, мы пошли к заказчику и провели нагрузочный тест, который использовал 500 тыс. некоторых юнитов из базы данных. В рамках теста мы подключились прямо к базе данных заказчика, и включили юнитам флажок, что они использованы. Допустим, всего в базе 600 тыс., а 500 тыс. мы уже «сожгли». И нам приходится придумывать способ, как 500 тыс. этих объектов вернуть в изначальное состояние. Если мы об этом не подумаем заранее, то у нас будет только один шанс провести это нагрузочное тестирование.
Когда мы работали в офсайте у себя на машинах — мы запускали SQL-ник, который просто возвращал эти данные в изначальное состояние. К сожалению, этот SQL-ник в онсайте у заказчика уже не работал, и нам пришлось придумывать иной способ.
Владимир: Хочу отметить, что проблема трактовок цифр, о которой упоминал Андрей, очень сильно связана с правильностью данных, на которых мы тестируем, с их полнотой и самой сущностью. Когда мы тестируем какой-то узкий функционал и создаем недостаточную нагрузку (или вообще подаем нагрузку слева и неправильно), результатам нашего замера можно верить с большими оговорками. Я бы сказал, что одна из ключевых проблем тестирования — это создание правильного объема данных для правильного управления нагрузками.
JUG.ru: Какие действия необходимо выполнить еще до начала нагрузочного тестирования?
Андрей: Совсем простой ответ — это функциональные тесты.
Второе — я бы отметил, что нужно удостовериться, что железка и решение готовы к тестированию: все интерфейсы настроены правильно, нет паразитной нагрузки и никто ничего не делает на этой машине. Кстати, у нас для этого есть специальные скрипты, которые запускаются перед тестами и сообщают, все ли ок или нужно что-то подправить.
Вместо примера: какое-то время назад мы откатывали базу данных Oracle к определенному чекпоинту. Мы проводили тест, снимали характеристики и возвращали БД в изначальное состояние с помощью rollback-а. Ну и в какой-то момент мы забыли выполнить последний шаг. Когда мы потом запустили тесты, они начали валиться. И до истинной причины докопаться было очень тяжело, потому что информация, что мы не откатились, очень тяжело отслеживается.
JUG.ru: Насколько детальную информацию о приложении необходимо иметь перед тем, как планировать тестирование?
Андрей: Действительно, требования собирать можно бесконечно долго. Финальную версию требований мы получим, как только конечный пользователь перейдет к эксплуатации. Но к этому времени уже поздно проводить какие-то замеры — все уже в production. Таким образом, наша задача — на основании данных, которые не точно известны, сделать вывод о том, что определенное тестирование будет полезно.
При этом если мы говорим не про продуктовую работу, а про проектную, никто никого не будет ждать. У тебя есть 2 недели на то, чтобы собрать требования — эти 2 недели необходимо использовать, чтобы стартануть хотя бы написание тестов. Впоследствии по мере появления новой информации требования будут обновляться, а тесты — переписываться.
Есть такой пример. Представьте себе, что заказчик говорит: «У нас будет 3 тыс. кейсов, но самые популярные из них — 10 — 20». Мы начинаем их тестировать: пишем тесты, чтобы эти кейсы генерировались 100 — 200 тыс. раз за сутки. После запуска теста оказывается, что эти топовые кейсы большой нагрузки не вызывают: мы видим, что CPU на нуле, жесткий диск почти не загружен. А потом выясняется, что среди этих 3 тыс. кейсов на самом деле есть сценарии, которые вызываются всего 300 раз за сутки (и мы их, конечно же, проигнорировали), но это какие-нибудь тяжелые поиски, которые могут генерировать львиную долю нагрузки, например, на жесткий диск.
Этот пример хорошо иллюстрирует, что важна не только количественная, но и качественная оценка кейсов, т.е. большая информация о проекте.
Владимир: Андрей коснулся очень интересных подводных граблей — как правильно оценить сложность операции. Должна быть какая-то экспертиза (чутье разработчика или аналитика), которая будет подсказывать, где потенциально проблемные сценарии, а где — нет.
Можно максимально детализировать информацию о проекте, но никто с этим не станет работать. У нагрузочного тестирования, по крайней мере в enterprise-приложениях, есть ограничения, поэтому надо каким-то образом вычленить наиболее важные детали для тестирования. Как это мы можем делать? Мы можем либо следовать тому, что говорит заказчик («очень важно, чтобы эта кнопка у нас нажималась за 2 десятых секунды, потому что ее будет нажимать вице-президент на демке»), либо следовать какому-то чутью разработчика или аналитика, которое должно подсказывать, что такая-то функциональность тяжело реализуется, поэтому ее необходимо лучше протестировать.
Соответственно, в реальных проектах мы сталкиваемся не только с цифрами в отношении кейсов, но с какими-то экспертными оценками по сложности этих кейсов.
JUG.ru: Какую роль «глюки оборудования» играют в нагрузочном тестировании?
Владимир: На мой взгляд, ситуации, когда оборудование работает не так, как от него ожидалось, у нас бывают довольно редко. Можно много говорить о том, что память и жесткие диски периодически ломаются, но у нас это случается нечасто. И, как правило, если у сервера ломается жесткий диск, мы теряем стенд и, соответственно, время на восстановление или построение сервера с нуля.
Андрей: Помимо потери времени может быть и потеря результатов. Хуже всего, когда посередине теста поменялась конфигурация. Провели первый замер, а тут хоп — поменялся конфиг. А следующий замер дает другой результат, и неясно — то ли это железка, то ли решение поменялось.
Однако гораздо чаще случается, что мы сталкиваемся не с поломками, а с ограничениями оборудования — с тем, что железка не справляется с нагрузкой. Мне кажется, бороться с этим можно, используя два основных подхода. Первый — распределение нагрузки на жесткий диск по времени (например, мы не днем выполняем какую-то операцию, а перекладываем ее в ночной режим, когда пользователь ничего не делает с системой). Второй — тупая оптимизация запросов.
JUG.ru: Какой «перезаклад» по объемам данных, по вашему опыту, необходимо закладывать при нагрузочном тестировании?
Андрей: Обычно мы закладываем 120-150% от базовой нагрузки. Но если мы ожидаем, что какие-то компоненты слабые, т.е. не готовы к такого рода нагрузкам, или если у нас есть основания полагать, что оценки заказчика врут, можем повышать «перезаклад».
И еще мы иногда проверяем на 400%. Обычно мы не делаем тестирование всей системы на 400%. Мы выделяем и тестируем компоненты, чтобы проверить, насколько стабильно они работают. Гораздо проще потюнить (потестировать, а потом потюнить) один маленький компонент, если мы считаем, что он будет потенциально слабым звеном.
JUG.ru: Часто ли такой перезаклад по нагрузке спасает?
Владимир: Часто или нет — сложно измерить. Часто ли вам нужен запасной парашют?
Но я скажу по-другому. Часто бывает, что в «боевой» системе происходит какая-то нештатная ситуация, например, одна из компонент зависла, в ней застряли данные. Потом ее разблокировало, все эти данные полезли дальше. В идеальном мире, конечно, везде есть ограничители, но в реальности случается, что такое залипание запросто приводит к шквалу каких-нибудь сообщений — повышенной нагрузке на все остальные части нашего стека. Мы конечно можем сказать, что такое не поддерживаем, поэтому система и упала. Но выглядит это не очень профессионально. Будет лучше, если система будет хоть как-то отрабатывать или, по крайней мере, не уходить в несознанку.
Выбирая между скоростью и качеством
JUG.ru: Более качественное тестирование требует большего времени, но время обычно ограничено. Как правильно найти баланс скорости и качества? Как повысить скорость тестирования?
Владимир: Тестировать надо «отсюда до обеда».
По поводу повышения скорости тестирования. На мой взгляд, есть достаточно простой ответ: надо разбивать сложную систему на кусочки и тестировать сначала все по компонентам. Это дает ускорение. Когда есть какая-то система, у нас есть много-много сценариев, но они никогда не подходят к тестированию в один момент. Как правило, мы получаем кусочки, поэтому сначала тестируем эти кусочки независимо, потом, когда все более или менее откатано, строим тесты, которые вовлекают в себя одновременно много компонент.
Андрей: В продолжение разговора о компонентах…
Есть такое понятие, как заглушки сторонних систем — стабы. Когда мы тестируем решение вне окружения заказчика, у нас нет реального железа и реальных сервисов, которые выдают телефонные номера, имена, IMEI и т.п. Все это мы синтетически эмулируем с помощью «заглушек», которые называем либо эмуляторами, либо стабами. Обычно мы начинаем тестирование с этих стабов. Стабы — это ведь тоже часть проекта, они тоже должны выдерживать определенную нагрузку. Пусть они отвечают односложно, но они тоже пишутся с использованием нашего внутреннего фреймворка. И у этого фреймворка тоже могут быть какие-то перформанс-проблемы. Поэтому мы начинаем тестирование со стабов, нагружая их в 40-50 раз больше, чем они будут нагружены на тестах. Потом нам это помогает не заморачиваться этим вопросом на end-to-end тестах.
JUG.ru: Существуют ли типичные проблемы анализа полученных результатов (грубо говоря, неправильно посмотрели в «хорошие» данные)?
Владимир: Все проблемы с анализом сводятся либо к тому, что данные недособраны, либо к тому, что их не так собрали (т.е. нагрузку подали не так, как исходно надо было). К примеру, так происходит, когда не смотрят на процент ошибочных сценариев. Т.е. когда замеряют время работы, не обращая внимание на ошибки (а у ошибки может быть совершенно другое время работы и другая нагрузка).
Андрей: Наверное, я соглашусь с Володей. Скорее, это вопрос не анализа, а подготовки данных. Обычно данные все-таки либо неправильно собраны, либо их недостаточно.
Например, мы провели какую-то миграцию, получили в отчете success. Условно было промигрировано 60 тыс. объектов. Не зная специфики этого бизнес-процесса, мы взяли и нарисовали в отчете: «Все ок». А по факту оказалось, что эти 60 тыс. объектов выдали какие-то ошибки. Все, что нужно было сделать, это посмотреть в нужную табличку или в более простом случае зайти на особенную табу и посмотреть, была ли операция выполнена успешно. Но этого сделано не было, в итоге замер не считается валидным, его нельзя использовать, чтобы анализировать скорость работы апликейшн.
JUG.ru: Синтетические данные против натуральных для нагрузочного тестирования: давайте определимся с терминологией, что считать синтетическими данными, а что — натуральными?
Андрей: Мне кажется, тут уместна аналогия с автомобилем. Бывают полные натуральные данные (минеральное масло), бывает 100% синтетическое, а бывает какой-то микс. На тестировании так же — очень часто делается какой-то микс синтетических и натуральных данных, т.е. за основу берутся данные, которые предоставляет заказчик (он, естественно, маскирует данные, которые считаются приватными и угрожающими его интеллектуальной собственности), а на их основе мы можем генерировать дополнительные объекты или увеличивать вложенность существующих. В зависимости от того, насколько много мы сгенерировали, будет выше или ниже процент синтетики.
Когда никаких вводных от заказчика нет, мы действительно генерим полностью синтетические данные. Чаще такое происходит, когда решение пишется с нуля и нам приходится придумывать, как эти данные могут выглядеть.
О важности натуральных данных
JUG.ru: Можно ли выделить ситуации, когда важны именно натуральные данные?
Владимир: Я с таким не сталкивался. Но если расширить синтетику до внешних систем, то здесь могут быть сложности. Не всегда можно правильно сэмулировать внешнюю систему (какую-то железку и т.п.). Выдержать все особенности — задержки по времени, количеству одновременных подключений и т.п. — бывает тяжело. Наверное, можно сделать какой-то эмулятор, но зачастую взять готовую внешнюю систему на порядок проще, чем пытаться оценить эти моменты.
Андрей: Действительно, мы пишем стабы, они возвращают очень примитивный ответ. Но бывают системы, которые возвращают такие огромные XML, что там черт ногу сломит. И вместо того, чтобы синтетически генерить такую простыню, бывает проще взять реальные данные.
Владимир: Можно привести пример: когда мы интегрируемся с мейнфрейм-системой, проще взять реально работающий мейнфрейм (не production, а тестовый — его копию) и работать с ним, чем создавать кучу стабов, какие-то данные в них загонять и т.д. Систему, написанную, условно говоря, 20 лет назад и более, сейчас уже никто не понимает.
Переводя вопрос в другую плоскость — заменить синтетикой натуральные данные можно всегда, но есть реальные ограничения, например, сроки разработки и ресурсы, которые на это потребуются (деньги и время). И бывают случаи, когда взять готовую систему и ее откопировать проще, чем пытаться описать ее логику.
JUG.ru: Встречаются ли «неподобающие» натуральные данные?
Владимир: Да. Есть простой пример, связанный с поиском.
Поиск — это одна из типичных проблемных областей. Иметь сами данные — это полбеды, надо знать, какие варианты поиска будут использоваться. В частности, если мы будем постоянно искать одно и то же (например, Джона Смита), то у нас система к этому привыкнет, закеширует, и все будет нормально. Если мы будем постоянно рандомить, искать вообще разное, то у нас система будет немного не в себе (мы можем подать более сложную нагрузку, чем в боевой системе). Все эти тонкости очень влияют на результаты замера.
Надо отметить, тот факт, что мы скопировали те же самые данные, совершенно не означает, что у нас нагрузочный тест выдаст тот же самый ответ, что и production-система.
А все потому, что данные даже после экспорта-импорта какими-то средствами базы или еще чего-то по-другому лягут на наше железо.
Если у нас реальная система работала годами, данные там постепенно создавались и удалялись, исторические записи в ней будут лежать вперемешку с новыми. После экспорта-импорта этого сервера может оказаться, что все данные лягут рядом плотно и компактно. В результате все сценарии будут работать намного лучше, чем они реально работают на production. Наиболее этому подвержены, опять же, сценарии поиска, но эффект наблюдается и на других сценариях. Чтобы избавиться от этого несоответствия, надо идти в сторону повторения самого окружения: не просто копировать сами данные, а повторять байт в байт.
Если мы говорим про базу данных Oracle, надо снимать клон файлов, а не самих данных. И у нас есть случаи, когда тестовое окружение у заказчика развертывалось из клона базы данных — не на уровне самих данных, а на уровне базы — именно для того, чтобы повторять эти сценарии по нагрузочному тестированию.
JUG.ru: Как проверить «качество» натуральных данных? Тут необходимо какое-то чутье?
Владимир: Чутье всегда должно быть. Но есть еще такой способ — сравнить тесты с результатами работы на production. Если у нас есть на production сценарий, который работает медленно, мы можем его повторить на нашем тестовом окружении и увидеть, сколько он выполняется там. Так вот банально.
Андрей: От себя хочу добавить, что натуральные данные — это данные, которые взяты в определенный момент времени. И они могут протухать.
Есть известный проект, в котором я проработал почти 2 года. И мы натуральные данные брали от 2008 или 2007 года. За это время эти данные стали совсем не актуальными. Но т.к. другого способа не было, и нет до сих пор, мы эти натуральные данные используем, чтобы генерировать более актуальную синтетику.
JUG.ru: С какими проблемами приходится сталкиваться при использовании копии корпоративных данных в качестве основы для «натуральных» тестов?
Андрей: В первую очередь, эти данные как-то привязываются к существующим пользователям. А эти пользователи имеют ID в других системах, не совпадающие с ID в нашей «синтетике».
Владимир: Первый момент — когда реальному пользователю приходит email-уведомление о тестовом действии. Мы берем копию реальных данных с production, на ней проводим тесты — допустим, подключение и отключение интернета. И в этот момент пользователю уходит оповещение о том, что у вас подключился / отключился интернет.
Второй момент — при использовании реальных данных остается слишком много завязок на внешние системы. К примеру, чтобы правильно выполнить подключение / отключение интернета, нужно иметь информацию о том, какой тарифный план был у пользователя и т.п. Вся эта информация может храниться в других системах. Т.е. может оказаться, что придется долго готовить стабы, которые будут уметь разумно отвечать на наши запросы, чтобы правильно протестировать функционал.
JUG.ru: Часть подобных проблем решается деперсонализацией. Сталкивались ли вы с влиянием на результат тестирования преобразований в ходе деперсонализации натуральных данных? Важна и нужна ли деперсонализация вообще?
Владимир: От нее, наверное, никуда не деться. Как в любом случае с данными, которые нельзя показывать — здесь просто нужно аккуратно подходить к вопросу. Что это значит? Если мы просто возьмем и заменим все имена на Джон Смит, у нас отвалится сценарий поиска. Система будет постоянно выдавать вместо одной найденной строки миллионы. Если же мы хотим заменить все имена на рандомные, это придется делать аккуратно — нельзя одно и то же имя заменить по-разному в разных местах. Если у нас имя фигурирует в комментарии к договору, где-то в полях first name / full name, надо делать так, чтобы эти изменения оказались синхронными. В реальных системах дублирования данных довольно много, соответственно, когда мы делаем деперсонализацию, их надо аккуратно подменять, иначе у нас какие-то сценарии просто не будут работать.
О сложностях совмещения натуральных и синтетических данных
JUG.ru: С какими сложностями можно столкнуться при совмещении натуральных и синтетических данных? Существует ли какой-то общий подход для их решения?
Андрей: Я бы выделил вот какие моменты.
Что такое генерация в простом случае? У нас есть некоторые данные, которые мы просто клонируем. Условно говоря, у нас есть один объект, и мы, меняя какой-то идентификатор (например, адрес электронной почты пользователя в этом объекте), генерим еще 100500 миллионов таких же объектов.
Но такая ситуация у нас довольно редка. Как правило, объекты имеют очень сложные завязки и вложенность. Представим себе какой-нибудь регион (например, Северо-Западный). В этом регионе есть натуральные данные, например, есть 500 компаний. А нам нужно для теста 5 миллионов компаний. И мы клонируем эти компании или просто генерим новые на основе нашего понимания, как это должно быть. К сожалению, мы не можем генерить их с той же степенью вложенности, с какой они есть. Эти 500 компаний реально тяжелые — у них есть контракты, какие-то проводки, офисы, клиенты и документооборот. А мы генерируем только, условно говоря, идентификаторы — базовые объекты, которые нужны для тех кейсов, где это будет использоваться. Но черт его знает, какие там кейсы? Т.е. мы можем сгенерить синтетику, которая не очень помогает нам для тестов.
Владимир: Я бы сказал, что плавно разбавлять имеющиеся данные синтетикой — это не то, чтобы лучший подход, но это то, что реально работает. Была бы наша воля, мы бы каждую неделю обновляли дамп с реально работающей системы. Но такого не происходит.
Если говорить подход к решению этой проблемы — то надо контактировать с заказчиком и запрашивать базу, если не целиком, то хотя бы частично.
JUG.ru: С какими распространенными ошибками вам приходилось сталкиваться при генерации синтетических данных?
Андрей: Мне кажется, самая большая проблема — сгенерировать данные, которые будут подходить не только под функциональные тесты, но и под тесты производительности, чтобы они генерировали сходную нагрузку и имели похожую сложность.
Владимир: Хочу дополнить, что в нашем случае одни и те же данные подходили под большое количество сценариев.
Если у нас для системы например требуется миллион клиентов. И нам требуется подключать интернет / отключать интернет. Мы не можем сделать миллион клиентов для подключения интернета и миллион для отключения (а потом на одних тестировать подключение, а на других подключение). Если мы так сделаем, у нас база данных по своим объемам сразу уйдет в небеса, и тестировать мы будем совершенно не то. Поэтому когда мы готовим какую-то синтетику, она должна пройти не просто один сценарий, а столько сценариев, сколько потребуется, т.е. объекты там должны быть каким-то образом правильно взаимосвязаны. Это первый момент.
И второе — тот порядок, в котором мы генерируем данные, как правило, сказывается на производительности конечного решения. Когда данные ложатся плотно рядом последовательно на диск, в сценариях типа отчетов и поиска тесты будут не показательны. Отчеты генерятся быстро, база занимает мало место — все потому что мы взяли и одномоментно ее сгенерировали. Если бы мы генерировали базу наподобие того, как у нас работают системы (когда данные удаляются, добавляются, заменяются), мы бы получили базу уже с другими совершенно характеристиками.
JUG.ru: Это отсылка к тому, что можно использовать клон?
Владимир: Использовать клон — это всегда хорошо. Но есть подход, что с этим делать. Например, неплохой вариант — это использовать имеющийся функционал для создания самих данных. Если у нас есть в системе функционал для создания заказчиков и их изменения/ удаления, то можно записи через этот функционал создавать (чтобы они не одним SQL-запросом в базу помещались).
Если вам интересна тематика тестирования, приглашаем вас посетить кнференцию Гейзенбаг, которая пройдет 10 декабря в гостинице «Radisson Славянская». Зарегистрироваться можно уже сейчас.
Темы докладов:
- No Such Thing as Manual Testing and Other Confusions
- Appium: Automation for Apps
- Как научить роботов играть в игры?
- Hero’s Journey to Perfect System Tests — Eight Assessment Criteria for Tests’ Architecture Design
- Page Objects — лучше меньше, да лучше
- Тестирование распределенных систем
- Тестирование Android–приложения Juno с ️: CI, Unit, Integration и Functional (UI) тесты. 100% Kotlin, 90%+ RxJava, Spek, JUnit, DSL для UI тестов
- Combining manual and automated testing: process and tools
- Список покупок: что нужно не забыть при запуске JMeter-тестов
- Статический вынос мозга: что скрывают анализаторы кода?
Автор: JUG.ru Group
