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