В первой части перевода статьи мы говорили про отличия тестирования БД от тестирования UI, рассмотрели виды тестирования БД и чуть подробнее остановились на тестировании структуры БД.
В этой части мы рассмотрим следующие темы:
- Функциональное тестирование БД:
- Проверка единообразия данных,
- Безопасность и доступ пользователей.
- Нефункциональное тестирование БД:
- Нагрузочное тестирование,
- Стресс-тестирование.
- Мифы о тестировании БД и их развенчивание.
Функциональное тестирование
Функциональное тестирование БД подразумевает проверку того, что операции и транзакции, производимые конечными пользователями, удовлетворяют функциональным требованиям, описанным в спецификации.
Что можно проверить в рамках этого вида тестирования БД:
- что обязательные поля не принимают значения NULL;
- что длина каждого поля достаточна, чтобы вместить возможные данные;
- что поля, хранящие одни и те же данные, имеют одинаковые названия в таблицах;
- что если в БД есть поля, значения в которые вводятся не напрямую, а подсчитываются из уже существующих, эти подсчеты производятся корректно.
Это похоже на тестирование маппинга БД, но разница в том, что здесь операции производятся с точки зрения конечного пользователя.
Можно делать это двумя способами: или тестировщик выполняет действия как пользователь, а потом проверяет, что поля и значения в БД соответственно обновились, или, наоборот, тестировщик меняет значения полей БД и убеждается, что изменения отображаются в пользовательском интерфейсе.
Проверка единообразия данных
- Проверить, что организация данных в БД не противоречит логике и здравому смыслу;
- Проверить, что в таблицах хранятся верные данные (например, в колонке name — имя, а не фамилия, age — возраст, а не дата рождения, и т.д.);
- Проверить, не хранятся ли в приложении «лишние», т.е. неиспользуемые, данные;
- Проверить, корректно ли отображаются данные в таблицах после изменений, проведенных через UI приложения;
- Проверить, что данные проходят валидацию перед тем, как помещаются в БД приложения;
- Проверить, что все транзакции в БД происходят согласно функциональным требованиям и что результаты транзакций корректны;
- Проверить, что данные, измененные в результате транзакции, помещены в правильные таблицы;
- Проверить, что данные остаются неизменными при прерывании транзакции пользователем;
- Проверить, что данные остаются неизменными при прерывании транзакции системой;
- Проверить, что транзакции выполняются согласно функциональным требованиям.
Безопасность и доступ пользователей
- Проверить, что приложение не позволяет пользователю продолжить работу в случае:
- Некорректного логина,
- Некорректного пароля,
- Некорректной пары логин-пароль,
- Несуществующей пары логин-пароль и т.д.
- Проверить, что пользователь может выполнять операции только в рамках своих прав и доступов;
- Проверить, что доступы и права пользователей соответствуют требованиям/спецификации;
- Проверить, что у неавторизованного пользователя нет возможности получить скрытую информацию;
- Проверить, что sensitive-данные, такие как пароль, номера кредитных карт и т.д., зашифрованы и не хранятся в БД как простой текст.
Нефункциональное тестирование
Нефункциональное тестирование БД можно условно разделить на такие виды, как нагрузочное тестирование, стресс-тестирование, тестирование юзабилити и т.д. Иногда к ним относят также тестирование безопасности и тестирование совместимости. Нагрузочное и стресс-тестирование можно объединить как виды тестирования производительности. Почему же эти виды нужны?
Оценка рисков: нагрузочное тестирование помогает стейкхолдерам увидеть время ответа системы на разные уровни нагрузки. Это недалеко уходит от основной задачи QA — предоставлять информацию о работе системы. Нужно понимать, что нагрузочное тестирование не исключает риски напрямую, но через обозначение проблем и подсчет возможных рисков помогает увидеть и оценить возможности, которые снизят риск.
Понимание минимальных требований к системе: тестирование помогает определить минимальные технические требования, которые позволяют системе работать соответственно требованиям производительности. Таким образом, стоимость используемого железа может быть снижена, а производительность ПО оптимизирована.
Нагрузочное тестирование
- Необходимо помнить, что наиболее часто проводимые транзакции могут повлиять на производительность всех остальных транзакций.
- В итоговый тест-комплект должна быть включена по меньшей мере одна транзакция, не изменяющая данные, чтобы была возможность проверить производительность таких операций отдельно от более сложных действий.
- Необходимо включать в итоговый тест-комплект максимум транзакций, которые служат основным целям приложения (т.н. киллер-фичам), т.к. падение таких операций из-за слишком большой нагрузки может оказаться слишком критичным для системы.
- Нужно проверять оптимальное время ответа системы под нагрузкой из большого количества операций, пользователей, данных и т.д.
Тестирование нагрузки можно проводить с помощью таких инструментов, как LoadRunner, WinRunner, JMeter, Gatling и т.д.
Стресс-тестирование
Стресс-тестированием обычно называют вид нагрузочного тестирования, когда приложение подвергается чрезмерной нагрузке (пользователями, данными, транзакциями…), которая приводит к его падению. Это необходимо для определения максимальной «выносливости» продукта. Инструменты для стресс-тестирования те же, что и для нагрузочного тестирования: LoadRunner, WinRunner, JMeter, Gatling и т.д.
Мифы о тестировании БД
Миф: Тестирование БД — очень специфическая работа, требующая огромной технической экспертизы.
Реальность: эффективное тестирование БД обеспечивает в перспективе стабильность всего приложения, поэтому основное, чего оно требует, — это время и усердие.
Миф: Тестирование БД добавляет узкое место в процессе разработки.
Реальность: наоборот, тестирование БД помогает найти скрытые проблемы и заблаговременно улучшить качество приложения, избавляя команду от будущих боттлнеков.
Миф: Тестирование БД замедляет весь процесс разработки.
Реальность: за счет тестирования на ранних этапах скорость разработки в будущем будет больше, т.к. возникнет меньше возможных проблем.
Миф: Тестирование БД — это дорого.
Реальность: вклад в тестирование БД на ранних этапах — это инвестиция в качество приложения в будущем. Кроме того, исправление проблем, найденных на ранних этапах, всегда дешевле, чем исправление проблем на финальных стадиях тестирования.
В заключение
Как и любое тестирование на ранних стадиях жизни приложения, тестирование БД может быть крайне полезным, т.к. позволяет обнаружить фундаментальные проблемы проектирования и логики системы. Разумеется, чем больше опыт специалиста, который тестирует БД, тем эффективнее и быстрее будет этот процесс, однако не стоит пренебрегать этим видом тестирования только из-за недостатка опыта: во-первых, практика — лучший учитель, во-вторых, даже начинающий специалист может заметить важные проблемы, которые в перспективе могли бы привести к серьезным багам.
Всем отличного настроения и качественных приложений от базы данных до пользовательского интерфейса :)
Оригинал: https://www.guru99.com/data-testing.html
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: