Что делает знак вопроса в URL

Что проверяют

Знаете ли вы структуру URL и, главное, видите ли в строке запроса поверхность для тестирования. Вопрос простой на входе, но по ответу понятно, тестировали ли вы что-то кроме кнопок в интерфейсе.

Как отвечать

Знак вопроса отделяет путь от строки запроса. Всё после него и до решётки это параметры в виде пар ключ=значение, разделённых амперсандом:

https://example.com/search?q=тест&page=2&sort=asc

Дальше говорите то, что отличает тестировщика от пользователя:

• фрагмент после решётки на сервер не уходит вовсе, он обрабатывается только в браузере;
• значения кодируются процентной кодировкой, поэтому амперсанд, знак равенства, пробел и кириллица внутри значения экранируются, иначе параметр разорвётся пополам;
• стандарт не описывает, что делать с повторяющимся ключом: один фреймворк возьмёт первое значение, другой последнее, третий соберёт список. Готовый тест-кейс;
• строка запроса участвует в кэшировании и попадает в логи, историю браузера и заголовок Referer.

Отсюда прямо выводятся проверки: пустое значение, отсутствующий параметр, лишний неизвестный параметр, значение не того типа, очень длинное значение, спецсимволы, повторы, порядок параметров, регистр ключа. Отдельно проверяйте, что токены и пароли в строке запроса не передаются.

Где спотыкаются

Останавливаются на определении. «Отделяет параметры» это половина ответа, дальше ждут, какие дефекты вы этим найдёте.

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

Третье: путают строку запроса с телом запроса. Параметры в URL кэшируются, логируются и ограничены по длине, тело запроса нет, и вывод «параметры это всегда query» приводит к пропущенным проверкам на сервере.