При тестировании методом серого ящика мы имеем некоторое представление о внутренней структуре приложения, но, как и в случае с тестированием методом чёрного ящика, опираемся в основном на спецификацию.
Например, мы можем получить доступ к схеме базы данных, чтобы провести дополнительные проверки или обнаружить несоответствия требованиям ещё на этапе изучения документации.
Базы данных будут рассмотрены позже тут.
При наличии доступа к схеме базы данных тестировщик может не приступая к фактическим проверкам функциональности, провести анализ соответствия описанных в требованиях ограничений и ограничений, установленных в базе данных.
Рассмотрим примеры, при которых анализ поможет выявить баги.
| Требования | База данных |
|---|---|
| Поле может быть заполнено любыми символами | Поле имеет числовой типINTEGER |
| Поле должно хранить текст длиной до 200 символов | Поле ограничено длиной в 100 символов VARCHAR(100) |
| Требования | База данных |
|---|---|
| Поле может быть пустым | Поле с ограничением NOT NULL |
NOT NULL в базе данных приводит к ошибке при записи
данных с пустым значением в поле.
| Требования | База данных |
|---|---|
| Значения поля не уникальны | Поле с ограничением UNIQUE |
UNIQUE приводит к ошибке при добавлении записи с
одинаковым значением в поле.
Изучите «Требования к API» и схему базы данных. Проведите тестирование методом серого ящика. Известно, что сервер при получении запроса обновляет в базе данных значение поля name сущности cat.
Требования к API:
| Ключ | Тип | Обязательность | Ограничения |
|---|---|---|---|
| name | строка | + | от 1 до 30 символов |
Схема данных в базе данных:
Таблица cat в базе данных содержит столбцы:
На поля наложены ограничения:
Что-то подобное мы уже делали в задаче из раздела про API. На этот раз наша цель — найти баг, опираясь на требования и дополнительные знания о схеме базы данных.
Уровень повышен!