Тестирование бэкенда

• Что такое бэкенд
• И зачем его тестируют
• Виды тестирования backend
  • Структурное
  • Функциональное
  • Нефункциональное
• Процесс (этапы)
• Чек-лист
• Инструменты
• Полезности и сложности

Что такое бэкенд

Бэкенд (также варианты названия бекенд, backend) — это все, что относится к server-side. То есть всё в приложении, что делается на стороне сервера, а не у пользователя (на фронтэнде). Бекенд — это обработка данных, которая не видна пользователю, он видит только результаты, в виде обработанных и полученных с сервера данных. В каждом веб-приложении существует бекенд-слой, который нужно тестировать.

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

Зачем тестируют

Тестирование бэкенда в большинстве случаев сводится к тестированию баз данных (далее БД). Общее предназначение (цель) бекенд-тестирования с архитектурной точки зрения состоит в проверке business layer и database layer (то есть бизнес-слоя или уровня, и слоя баз данных):

То есть это поиск дефектов в базах данных и на сервере.

(Слою API посвящен отдельный гайд.)

QA-команда, которой поручили провести тестирование бэкенда на проекте, должна обладать довольно-таки крепкими знаниями SQL (здесь кое-что полезное), и, разумеется, общих принципов устройства и функционирования сервера.

Важность тестирования бэкенда состоит в том, что если в работе сервера и/или БД случатся ошибки, то приложение становится непригодным к использованию, иногда полностью; как минимум потеря данных, зависания, и подобные проблемы, они, как правило, более фундаментальны, чем на фронтенде.

Типы тестирования бекенда

Принято подразделять бекенд-тестирование на структурное, функциональное, и нефункциональное.

Структурное

Структурное тестирование бэкенда представляет собой валидацию всех элементов в репозитории данных (то есть в хранилище данных, в БД). 

Типы структурного тестирования:

Тестирование схем (Schema): тестировщик проверяет корректность сопоставления объектов в БД (маппинга, mapping). То есть то как объекты на фронтенде и объекты на бэкенде сопоставляются между собой. Тестирование схемы фокусируется на таких объектах: таблица, виды или представления (views), индексы, кластеры и подобные объекты. 

Тестирование таблиц и колонок: 

• Корректный ли маппинг имен таблиц и колонок объектов на фронтенде и в БД на сервере
• Валидация типов данных в колонках
• Валидация имен в ячейках
• Неиспользуемые таблицы и колонки
• Проверка возможности пользователям вводить данные 

Например, если колонка имеет неправильный тип данных — не согласующийся с типом данных на фронтенде, будет ошибка.

Тестирование ключей и индексов: валидация ключей и индексов колонок.

• Соблюдаются ли ограничения по ключам, например корректность ссылок на первичный ключ колонки
• Корректность ссылок на внешний ключ из родительской таблицы
• Проверка длины и размера индексов
• Создание кластерных и некластерных индексов
• Валидация имен и ключей

Тестирование триггеров: проверка исполняемых триггеров — что они соответствуют условиям для DML-транзакций.

• Валидация того, что триггеры корректно обновляют данные при исполнении
• Проверка правил написания кода (соблюдение нужного качества кода)
• Проверка функциональности триггеров — обновление, удаление, и вставка

Тестирование хранимых процедур: результат их выполнения

• Проверка, что хранимые процедуры содержат валидные условия циклов и условий
• Валидация обработки ошибок и сообщений о них
• Поиск неиспользованных хранимых процедур
• Валидация корректности TRIM-операций
• Проверка, что триггеры имплицитно вызываются при выполнении хранимых процедур

Тестирование сервера баз данных: проверка конфигурации на соответствие требованиям

• Валидация транзакций
• Валидация аутентификации и авторизации

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

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

Проверка на соответствие требованиям транзакций и операций, выполняемых конечными пользователями. 

Подтипы функционального тестирования бекенда:

Черного ящика

• Проверка функциональности и целостности базы данных
• На ранних стадиях разработки, чтобы не пропустить дефекты дальше
• Применяемые техники: анализ граничных значений, эквивалентная разбивка, и тестирование по принципу причина/следствие

Например, тестируется страница логина; если введенные юзернейм и пароль правильные, система должна впустить пользователя и перенаправить его на следующую страницу. 

Тестирование белого ящика

• Проверка внутренней структуры БД
• Триггеры, функции, представления, запросы, и подобное
• Валидация схемы БД и таблиц
• Поиск ошибок в триггерах
• И в запросах

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

Чаще всего это нагрузочное тестирование, как дополнение — стресс-тестирование, и проверка соблюдения уровня устойчивости/стабильности/масштабируемости бекенд-части приложения, и другие виды проверки производительности веб-приложения. Также и тестирование рисков, которым может подвергаться приложение. По итогам проводится оптимизация.

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

• Тестирование производительности и расширяемости БД
• Как система ведет себя при большой нагрузке, то есть при большом количестве одновременных пользователей
• Нагрузка должна обрабатываться нормально до каких-то пределов (прописанных в требованиях)
• Если не возникает особых проблем, нагрузочное тестирование успешное, переходят к другим проверкам

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

• Или как вариант тестирование на выносливость. Поиск «места поломки» системы
• Приложение «нагружают» до точки, когда система «упадет»
• Это точка называется точкой поломки (брейкпойнтом)
• Во время и после поломки тестировщик анализирует поведение системы; если возникают ошибки, система должна выдавать сообщения об ошибках

Процесс (этапы) тестирования бекенда

Создание и настройка тестового окружения

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

Генерация тест-кейсов

Когда собрана команда, подобрали инструменты, и готов план, пишутся тест-кейсы, направленные на проверку выполнения бизнес-требований. Хорошая новость с тест-кейсами в том, что существующие на рынке инструменты нагрузочного тестирования в очень большой степени автоматизированы, умеют анализировать систему, и могут генерировать практически все возможные тест-кейсы. 

Выполнение тест-кейсов

То есть, непосредственно тестирование. Процесс требует высокой квалификации и опыта; тестировщики БД/бэкенда считаются «высшей кастой» в QA.

Анализ результатов 

Ситуация несколько упрощается тем, что инструменты могут «подсвечивать», как бы подсказывать по результатам выполнения, как решить ту или иную проблему, обнаруженную в процессе.

Репорты

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

Чек-лист backend-тестирования

• Проверка производительности: отдельных модулей и системы в целом
• Валидация сервера БД: корректность обработки данных
• Тестирование функциональности: транзакции БД
• Ключи и индексы: соблюдение ограничений, общая корректность ключей и индексов
• Целостность баз данных: функционирование в соответствии с требованиями
• Таблицы: отдельно создание таблиц, запросы в них, результаты
• Триггеры: срабатывание триггеров
• Хранимые процедуры: функции, возвращаемые значения, вызов событий согласно требованиям
• Схемы: организация данных

Инструменты тестирования бэкенда

LoadRunner

• Профиль: стресс-тестирование
• Также автоматизированное тестирование производительности, анализ поведения системы под стандартной и стрессовой нагрузкой

Ссылка

Empirix-Test Suite

• Инструмент приобретен Oracle и теперь более надежный
• Хорошо получается тестирование масштабируемости
• Да и другое нагрузочное

Ссылка

LINQ

• Тестирование хранимых процедур
• ORM-вызовы и запросы из ORM
• Производительность запросов в БД

Ссылка 

Юнит-тестирование: инструменты SQLUnit, DBFit, NDbUnit

• SQLUnit — для юнит- и регрессионного тестирования хранимых процедур

Ссылка

• DBFit: часть FitNesse, для тестирования хранимых процедур и кастомных процедур. Для Java и .NET. Работает с командной строки

Ссылка

• NDbUnit: юнит-тесты системы до и после выполнения/компиляции других частей системы

Ссылка

Data Factory Tools

• Дата-менеджмент и генерация данных для тестирования БД в том числе
• Валидация больших объемов данных
• Нагрузочное и стрессовое тестирование

Ссылка

SQLMap

• С открытым кодом
• Для тестирование на проникновение
• Мощные функции определения ошибок и уязвимостей

Ссылка

phpMyadmin

• Тестирование БД — запросы и проверка результатов

Ссылка

HammerDB

• Нагрузочное
• Реплай активностей для БД Oracle
• Поддерживает бенчмарки TPC-C/TPC-H

Ссылка

SQLTest

• Базируется на открытом фреймворке tSQLt
• Сохраняет объект БД в отдельной схеме
• Юнит-тесты

Ссылка

Выгоды и недостатки тестирования бекенда

Плюсы:

• Выявление дефектов на ранней стадии
• Управление нагрузкой более гибкое после тестирования
• Предотвращает потерю данных
• Улучшает производительность
• Повышает безопасность

Минусы:

• Нужна очень высокая квалификация тестировщиков
• Ручные тест-кейсы бывают очень сложны
• Это дорогое тестирование
• Нужно много времени

***

Источники: 1,2