Какие форматы файлов можно загрузить и как проверить стандартные и нестандартные форматы?

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

Умеете ли вы превратить расплывчатое «загрузите файл» в набор проверок: от требований и классов эквивалентности до безопасности. Следом обычно просят назвать негативные сценарии или объяснить, почему проверки расширения недостаточно.

Как отвечать

Список допустимых форматов определяют требования, а не тестировщик. Если его нет, вы задаёте вопросы: какие типы, максимальный размер, сколько файлов за раз, что происходит с файлом после загрузки. Потом раскладываете проверки:

• позитивные: каждый разрешённый формат, расширение в разном регистре (.JPG, .jpeg), кириллица и пробелы в имени;
• граничные значения: пустой файл в 0 байт, лимит минус байт, ровно лимит, лимит плюс байт, очень длинное имя;
• подмена типа: .exe, переименованный в .pdf, текст с расширением .png. Сервер должен определять тип по сигнатуре в начале файла (магическим байтам), а не по расширению и не по заголовку Content-Type, который присылает клиент;
• повреждённые файлы: обрезанный PDF, архив с битым оглавлением. Ожидается понятное сообщение об ошибке, а не 500;
• безопасность: двойное расширение photo.php.jpg, SVG со встроенным <script>, ZIP-бомба, имя вида ../../file. Загруженный файл не должен исполняться и открываться с того же домена как HTML;
• обход интерфейса: атрибут accept у <input type="file"> только подсказывает системному диалогу, поэтому те же проверки повторяют запросом через Postman или curl.

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

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

Проверяют только фронтенд. Ограничение в accept снимается одной правкой в DevTools, а сервер без своей валидации принимает что угодно.

Путают хэш с проверкой формата. Контрольная сумма подтверждает, что файл не изменился при передаче, но ничего не говорит о том, валидный ли это PNG.

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