В первой части перевода статьи мы говорили про отличия тестирования БД от тестирования UI, рассмотрели виды тестирования БД и чуть подробнее остановились на тестировании структуры БД.

В этой части мы рассмотрим следующие темы:

• Функциональное тестирование БД:
  • Проверка единообразия данных,
  • Безопасность и доступ пользователей.
• Нефункциональное тестирование БД:
  • Нагрузочное тестирование,
  • Стресс-тестирование.
• Мифы о тестировании БД и их развенчивание.

Функциональное тестирование

Функциональное тестирование БД подразумевает проверку того, что операции и транзакции, производимые конечными пользователями, удовлетворяют функциональным требованиям, описанным в спецификации.

Что можно проверить в рамках этого вида тестирования БД:

• что обязательные поля не принимают значения NULL;
• что длина каждого поля достаточна, чтобы вместить возможные данные;
• что поля, хранящие одни и те же данные, имеют одинаковые названия в таблицах;
• что если в БД есть поля, значения в которые вводятся не напрямую, а подсчитываются из уже существующих, эти подсчеты производятся корректно.

Это похоже на тестирование маппинга БД, но разница в том, что здесь операции производятся с точки зрения конечного пользователя.

Можно делать это двумя способами: или тестировщик выполняет действия как пользователь, а потом проверяет, что поля и значения в БД соответственно обновились, или, наоборот, тестировщик меняет значения полей БД и убеждается, что изменения отображаются в пользовательском интерфейсе.

Проверка единообразия данных

1. Проверить, что организация данных в БД не противоречит логике и здравому смыслу;
2. Проверить, что в таблицах хранятся верные данные (например, в колонке name — имя, а не фамилия, age — возраст, а не дата рождения, и т.д.);
3. Проверить, не хранятся ли в приложении «лишние», т.е. неиспользуемые, данные;
4. Проверить, корректно ли отображаются данные в таблицах после изменений, проведенных через UI приложения;
5. Проверить, что данные проходят валидацию перед тем, как помещаются в БД приложения;
6. Проверить, что все транзакции в БД происходят согласно функциональным требованиям и что результаты транзакций корректны;
7. Проверить, что данные, измененные в результате транзакции, помещены в правильные таблицы;
8. Проверить, что данные остаются неизменными при прерывании транзакции пользователем;
9. Проверить, что данные остаются неизменными при прерывании транзакции системой;
10. Проверить, что транзакции выполняются согласно функциональным требованиям.

Безопасность и доступ пользователей

1. Проверить, что приложение не позволяет пользователю продолжить работу в случае:
   1. Некорректного логина,
   2. Некорректного пароля,
   3. Некорректной пары логин-пароль,
   4. Несуществующей пары логин-пароль и т.д.
2. Проверить, что пользователь может выполнять операции только в рамках своих прав и доступов;
3. Проверить, что доступы и права пользователей соответствуют требованиям/спецификации;
4. Проверить, что у неавторизованного пользователя нет возможности получить скрытую информацию;
5. Проверить, что sensitive-данные, такие как пароль, номера кредитных карт и т.д., зашифрованы и не хранятся в БД как простой текст.

Нефункциональное тестирование

Нефункциональное тестирование БД можно условно разделить на такие виды, как нагрузочное тестирование, стресс-тестирование, тестирование юзабилити и т.д. Иногда к ним относят также тестирование безопасности и тестирование совместимости. Нагрузочное и стресс-тестирование можно объединить как виды тестирования производительности. Почему же эти виды нужны?

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

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

Нагрузочное тестирование

1. Необходимо помнить, что наиболее часто проводимые транзакции могут повлиять на производительность всех остальных транзакций.
2. В итоговый тест-комплект должна быть включена по меньшей мере одна транзакция, не изменяющая данные, чтобы была возможность проверить производительность таких операций отдельно от более сложных действий.
3. Необходимо включать в итоговый тест-комплект максимум транзакций, которые служат основным целям приложения (т.н. киллер-фичам), т.к. падение таких операций из-за слишком большой нагрузки может оказаться слишком критичным для системы.
4. Нужно проверять оптимальное время ответа системы под нагрузкой из большого количества операций, пользователей, данных и т.д.

Тестирование нагрузки можно проводить с помощью таких инструментов, как LoadRunner, WinRunner, JMeter, Gatling и т.д.

Стресс-тестирование

Стресс-тестированием обычно называют вид нагрузочного тестирования, когда приложение подвергается чрезмерной нагрузке (пользователями, данными, транзакциями…), которая приводит к его падению. Это необходимо для определения максимальной «выносливости» продукта. Инструменты для стресс-тестирования те же, что и для нагрузочного тестирования: LoadRunner, WinRunner, JMeter, Gatling и т.д.

Мифы о тестировании БД

Миф: Тестирование БД — очень специфическая работа, требующая огромной технической экспертизы.

Реальность: эффективное тестирование БД обеспечивает в перспективе стабильность всего приложения, поэтому основное, чего оно требует, — это время и усердие.

Миф: Тестирование БД добавляет узкое место в процессе разработки.

Реальность: наоборот, тестирование БД помогает найти скрытые проблемы и заблаговременно улучшить качество приложения, избавляя команду от будущих боттлнеков.

Миф: Тестирование БД замедляет весь процесс разработки.

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

Миф: Тестирование БД — это дорого.

Реальность: вклад в тестирование БД на ранних этапах — это инвестиция в качество приложения в будущем. Кроме того, исправление проблем, найденных на ранних этапах, всегда дешевле, чем исправление проблем на финальных стадиях тестирования.

В заключение

Как и любое тестирование на ранних стадиях жизни приложения, тестирование БД может быть крайне полезным, т.к. позволяет обнаружить фундаментальные проблемы проектирования и логики системы. Разумеется, чем больше опыт специалиста, который тестирует БД, тем эффективнее и быстрее будет этот процесс, однако не стоит пренебрегать этим видом тестирования только из-за недостатка опыта: во-первых, практика — лучший учитель, во-вторых, даже начинающий специалист может заметить важные проблемы, которые в перспективе могли бы привести к серьезным багам.

Всем отличного настроения и качественных приложений от базы данных до пользовательского интерфейса :)

Оригинал: https://www.guru99.com/data-testing.html