Подходы к юнит-тестированию больших данных

Question

Представьте, что вы разрабатываете систему и хотите начать писать тесты, которые определяют функциональность, а также производительность и масштабируемость. Есть ли какие-то методы, которыми вы можете поделиться для обработки больших наборов данных в разных средах?

Answer 1

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

Answer 2

Я столкнулся с двумя ситуациями:

1. большие наборы данных HDFS, которые служат хранилищем данных или приемником данных для других приложений

2. Приложения с HBASE или другими распределенными базами данных

Советы по модульному тестированию в обоих случаях: -

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

б. В частности, если есть HBASE или любая другая распределенная база данных, пожалуйста, проверьте, что требуется от БД. Например, распределенные базы данных часто не поддерживают свойства ACID, такие как традиционные базы данных, и вместо этого ограничиваются так называемой теоремой CAP (согласованность, доступность, допуск на разделы); обычно 2 из 3 гарантированы. Для большинства RDBMS это CA, обычно для HBASE это CP и Cassandra AP. Как разработчик или специалист по планированию тестов, вы должны знать, в зависимости от функций ваших приложений, что является ограничением CAP для вашей распределенной базы данных, и, соответственно, создавать план тестирования для проверки реальной ситуации

3. Относительно производительности. Опять же, многое зависит от инфраструктуры и дизайна приложения. Также иногда некоторые программные реализации более обременительны, чем другие. Вы можете проверить количество разделов, например, все регистры

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

Answer 3

Разделяйте разные виды испытаний.

1. Сначала должно быть функциональное тестирование, начиная модульные тесты с небольшим количеством фиктивных данных.
2. Далее выполняются интеграционные тесты с небольшими объемами данных в хранилище данных, хотя, очевидно, это не тот же экземпляр, что и в хранилище с большими наборами данных.
3. Возможно, вы сможете сократить свои усилия по разработкевыполняя совместные тесты производительности и масштабируемости.

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

Дляболее конкретный совет, мне нужно знать технологию, которую вы используете.В Hadoop посмотрите на MRUnit.Для RDB, DBUnit.Apache Bigtop может дать вдохновение, хотя он нацелен на основные проекты в Hadoop, а не на конкретные проекты на уровне приложений.

Answer 4

Проведите тест функциональности.Рассмотрим несколько методов управления рисками, см. Этот пост Как обращаться с управлением рисками в больших данных Это поможет вам.

Answer 5

для тестирования и измерения производительности вы можете использовать статические источники данных и входные данные (это может быть огромный файл дампа или sqlite DB).

вы можете создать тест и включить его в интеграционную сборку, чтобы вызов конкретной функции занимал более X секунд, выдает ошибку.

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

вы можете потратить 20% своего времени, чтобы получить 80% функциональности, остальные 80% - на производительность и масштабируемостьмежду ними может быть балансировщик нагрузки, и вы можете увеличить свое состояние / обработку, просто добавив новое оборудование / службу в вашу систему