Ответы и подробный разбор всех кейсов к Testing Challenge №1 - web testing.
Наверное, каждый второй тестировщик уже видел этот замечательный челлендж-тренажер! Он на наглядных примерах демонстрирует отличное покрытие кейсами текстового поля имени пользователя в форме регистрации. Да, здесь есть заковыристые кейсы, которыми обычно занимаются скорее пентестеры, чем обычные тестировщики, но тем интереснее!
Пользователь должен заполнить стандартную форму, чтобы получить доступ к какой-то информации. По условию мы должны проверить только поле First name, максимальная длина которого - 30 символов.
От автора челленджа:
Не нужно тестировать кросс-браузерность, супер-большие запросы, мат, масштаб страницы. Нельзя использовать инструменты автотестирования.
Если Вы ещё не успели попробовать решить его самостоятельно, то скорее переходите по ссылке (только с компьютера): http://testingchallenges.thetestingmap.org/index.php
ВНИМАНИЕ! НИЖЕ СОДЕРЖАТСЯ ОТВЕТЫ!
Ниже Вы найдёте ответы с подробным разбором каждого кейса.
Попробуйте сначала решить найти максимальное количество кейсов самостоятельно, а потом - скролльте ниже :)
Базовые кейсы
Кейсы из данного раздела обязательно должны быть проверены при тестировании подобного функционала на вашем проекте.
Обычное значение (Average value)
Какой кейс тестировщик должен проверять в первую очередь?
Правильно: позитивный кейс! Форма должна работать корректно, если пользователь ввёл в него обычное имя, например, Kate.
Граничные значения (Minimum value/Maximum values/More than maximum values)
Одной из самых распространённых техник тест-дизайна является анализ граничных значений. В спецификации указано, что максимальное количество символов в поле [30]. Проверим значения на границе (30, 31), а также минимально возможное [1] символ.
Пустое значение (Empty value)
В данной форме поле имени отмечено, как обязательное. Первый из негативных тестов, который стоит проверить - это отправка пустого значения.
Кейсы с "небуквами"
Не ASCII символы (Non ASCII)
Форма представлена на английском языке, и она подразумевает ввод имени в английской раскладке. Но что будет, если ввести, например, кириллические символы (Иван/Пётр...)?
Небуквенные символы (Other chars then alphabetic)
В имени может содержаться дефис. Поэтому кейс Masha-Sasha можно считать позитивным. Но также пользователь может попытаться ввести в поле знаки препинания, числовые значения и тому подобные символы.
Кейсы с пробелами
Пробел внутри (Space in the middle)
Имя может быть составным, поэтому нужно проверить проверить, что корректно обрабатывается случай, при котором введено несколько слов через пробел (Ина бин Хатаб).
Тримминг пробелов (обрезание пробелов) (Space values at the end/Space values at the begining)
Пользователь может скопировать своё имя из документа или другой страницы и, вместе с тем, пробелы тоже могут попасть случайно в буфер обмена. Поэтому важна проверка обрезания пробелов перед и после имени.
Пробел (Space)
Что если пользователь будет достаточно ленив, чтобы вводить своё имя, и поставит в поле только пробел? Это тоже важный кейс, потому что пробелы по-разному обрабатываются в БД, и такое значение может повлечь за собой непредвиденные ошибки.
Кейсы тестирования безопасности
Следующие кейсы обычно проверяются при тестировании продукта на безопасность (например, пентестерами) и чаще всего не нужны junior/middle тестировщикам.
Использование HTML тегов внутри поля (You used html tags)
Данный кейс проверяет, можно ли встроить и выполнить свой код через форму ввода. Используйте любой HTML тег. Например, <p> (или <script>, но об этом ниже).
Базовая SQL инъекция (Basic Sql injection)
Используйте завершение SQL выражения с любым последующим запросом, чтобы проверить, экранировано ли поле ввода. (Например: '); SELECT * FROM users; )
Базовая XSS инъекция (Basic XSS)
Для проверки возможности запуска сторонних скриптов через поле ввода можно использовать такую базовую XSS-инъекцию, как <script>alert('xss');</script> Или просто <script>.
Кейсы пасхалки с исходным кодом
Эти кейсы спрятаны немного глубже и позволяют протестировать не только поле ввода имени, но и некоторые особенности страницы. Такие кейсы не так часто встречаются в реальной работе тестировщика, но не менее интересны.
Залезть в куки (You looked at the cookie)
При тестировании веба так или иначе придется периодически "лезть в куки". Нужно открыть консоль разработчика (клавиша F12) и перейти в cookies:
- Chrome/Yandex/Edge: вкладка Application - Cookies
- Firefox: вкладка Хранилище - Куки
В списке сайтов выберете сайт челленджа, ну а дальше Вы просто не сможете пройти мимо :)
Залезть в исходный код (You looked at the page source)
Редко используется на практике, но я рекомендую всё же проверять, что разработчики убрали все внутренние комментарии и код страницы выглядит аккуратно. Открываем консоль разработчика (см. выше), затем вкладку с ресурсами страницы:
- Chrome/Yandex/Edge: вкладка Sourses
- Firefox: вкладка Отладчик
В списке нужно найти самый главный файл - index.php Пролистываем файл в конец и читаем комментарий.
Сделать пользователя админом (You made the user admin)
На практике такой кейс может произойти в том случае, когда после тестирования какого-то функционала включение/выключение забыли убрать из "продовской" версии, и теперь фактически любой пользователь сможет функционал активировать.
Нажимаем на поле ввода имени и выбираем "исследовать элемент". Откроется консоль разработчика и код из index.php Пролистываем код чуть вниз (ниже first name поля) и видим список скрытых input полей. Находим среди них name="user_right_as_admin" и убираем атрибут hidden. Дальше увидите, что изменится в форме.
Потерявшийся CSS (Missing css)
Не закрывайте консоль разработчика, она всё ещё нужна. Никто не любит неиспользуемые переменные, файлы и прочий мусор. Это действительно засоряет проект и вводит всех в заблуждение. Поэтому в index.php есть подсказка:
Если тут есть потерявшийся файл ресурсов, то добавьте его имя и расширение в поле ввода имени.
Ищем пустой файл. Далее просто копируем его название вместе с "хвостиком" после точки и отправляем форму.
