Home

Оригинальная публикация

Я Михаил Бибик, работаю в СберТехе QA‑automation‑инженером, пишу автотесты для СУБД Pangolin — это целевая СУБД в Сбере и не только. В прошлом году наша команда искала и нанимала QA‑инженеров с различным опытом, в том числе совсем начинающих. Когда я провёл штук 15–20 собеседований, то понял, что могу обобщить некоторые наблюдения и составить простые советы по поводу составления сценариев тестирования для начинающих (скорее, очень начинающих) тестировщиков. В этой статье я покажу, как применить теорию тестирования на техническом собеседовании. Для этого разберу реальную задачу с нашего собеседования.

Условие задачи 

Необходимо протестировать веб‑интерфейс и связанный с ним сервер. Веб‑интерфейс состоит из поля для ввода и кнопки «Отправить». При нажатии на неё выполняется GET‑запрос к серверу, который ответит 200, если будет получена строка длиной 8 символов и состоящая из цифр; в остальных случаях ответит 503.

С чего мы можем начать? Обратимся к теории тестирования, которая гласит, что тестирование можно разделить на функциональное и нефункциональное.

Функциональное тестирование

Оно поможет нам проверить корректность работы сервера. Разделим наши сценарии на позитивные и негативные.

Из позитивных первое, что приходит на ум — отправить набор из 8 цифр:

Сценарий 1: Строка 12345678 → ответ 200

Примечание: здесь и ниже варианты тестовых сценариев будут выделены жирным.

Мы получили ответ 200. Какие ещё позитивные сценарии можно проверить? Давайте проверим корректность обработки минимального и максимального числа с 8 цифрами:

Сценарий 2: Строка 10000000 → ответ 200

Сценарий 3: Строка 99999999 → ответ 200

Можно было бы сказать, что позитивные сценарии закончились, но нет: мы не проверили один из важных сценариев — обработку чисел с нулями, а конкретнее — первым и последним нулевым символом в отправляемой строке:

Сценарий 4: Строка 01 111 111 → ответ 200

Сценарий 5: Строка 99 999 990 → ответ 200

Чем этот сценарий так важен? Допустим, что на стороне сервера некорректно обрабатывается 0. Только когда этот символ обрезается, проблема становится заметна.

С позитивными сценариями разобрались. Начинаем ломать тестовый сервер. Посмотрим, сломается ли он под натиском наших идей: будем отправлять строки длиной 1, 2, 3, 5, 9, 10, 100 и так далее, и ожидать, что наш «испытуемый» будет возвращать нам 503. Но когда нам остановиться, и почему мы пропустили 7, 4, 99, 11 и строки другой длины? И вообще, нет ли способов попроще? Ответ, как всегда, лежит в теории тестирования. Взглянем на методики проектирования тестов, а именно на методику граничных значений, которая предназначена для проверки поведения продукта при крайних (граничных) значениях входных данных. То, что нам нужно. Граничным значением для сервера, который находится под капотом нашего веб‑интерфейса, является 8. Поэтому вместо перебора кучи значений мы можем отправить строку длиной 7 и 9 цифр, а точнее:

Сценарий 6: Строка 1 234 567 → ответ 503

Сценарий 7: Строка 12 3456 789 → ответ 503

Границы проверены, что дальше? Проверим на пустое значение и максимально длинную строку для того, чтобы определить:

• есть ли на стороне веб‑интерфейса проверка максимального и минимального значений;

• есть ли на стороне сервера обработка максимального и минимального значений.

Сценарий 8: Пустая строка → ответ 503

Сценарий 9: Строка {1, N}, где N ~ 100к → ответ 503

Теперь применим методики предугадывания ошибок и попробуем поломать наш сервер, используя различные входные параметры.

• Отправим не заявленные к поддержке символы:

  • Сценарий 10: Строка из 8 латинских букв (abcdefgh) → ответ 503

  • Сценарий 11: Строка из 8 букв кириллицы (абвгдежз) → ответ 503

  • Сценарий 12: Строка из произвольного числа латинских букв (aefgh) → ответ 503

  • Сценарий 13: Строка из произвольного числа букв кириллицы (абвгдежзиклман) → ответ 503

  • Сценарий 14: Строка из букв и цифр длиной 8 (abcd8726) → ответ 503

  • Сценарий 15: Строка из спецсимволов (±!@#$%^_$%)→ ответ 503

• Отправим комбинацию чисел и пробелов в строке для проверки корректной обработки пробельных символов:

  • Сценарий 16: Строка 12 345 678[символ пробела] → ответ 503

  • Сценарий 17: [символ пробела]12 345 678 → ответ 503

  • Сценарий 18: 1234[символ пробела]5678 → ответ 503

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

Нефункциональное тестирование

Нефункциональное тестирование — это вид тестирования, при котором проверяются нефункциональные аспекты программного обеспечения, такие как производительность, безопасность, совместимость, надёжность, удобство использования и так далее.

Рассмотрим на примерах различные виды нефункционального тестирования, и начнём с пользовательского интерфейса. В задаче сказано, что наш интерфейс состоит из поля ввода и кнопки «Отправить». Проверим эту функциональность несколькими способами.

• Попробуем ввести корректные данные из 8 цифр и понажимать кнопку «Отправить» в разные её области. Если мы обнаружим что при нажатии на какую‑либо область заявленная функциональность не работает, то можем смело говорить, что это баг интерфейса.

• Попробуем ввести корректные данные из 8 цифр и понажимать область вокруг кнопки «Отправить». Если обнаружим что строка отправляется, то можно считать, что мы нашли ещё один баг интерфейса.

• Попробуем ввести корректные данные из 8 цифр и проверить корректность отображения нашего интерфейса при увеличении или уменьшении масштаба. В данном случае мы предполагаем, что базовые функции интерфейса (поле ввода и кнопка «Отправить») будут доступны для нажатия при любых размерах.

• Попробуем проверить корректность отображения при изменении размера окна. В этом случае мы тоже ожидаем, что поле ввода и кнопка «Отправить» будут доступны для нажатия при любых размерах.

Теперь протестируем удобство использования. Здесь мы можем предложить несколько вариантов проверок, а именно:

• Попробуем не набирать корректную строку из 8 цифр в поле ввода, а вставить её из буфера обмена. В этом случае мы должны однозначно получить ответ 200.

• Попробуем ввести корректные данные из 8 цифр и не нажимать кнопку «Отправить», а нажать Enter. Если такой способ взаимодействия поддерживается, то ожидаемо мы тоже должны отправить корректные 8 цифр и получить ответ. Иначе можем обратить на это внимание, так как пользователю может быть удобнее отправлять значение без взаимодействия с кнопкой.

Используя сторонние утилиты для взаимодействия с сервером, мы можем попробовать отправить запросы других типов, а именно PUT и POST. В этом случае мы должны ожидать некорректный ответ (503). Так мы проверим, насколько правильно сконфигурирован наш сервер. Такой вид проверок мы можем отнести к тестированию на соответствие требованиям.

Ещё один вид нефункционального тестирования — нагрузочное тестирование. Попробуем проверить наш сервер на способность корректно работать в более сложных ситуациях. Для этого мы можем воспользоваться двумя способами:

• Попробовать понажимать несколько раз кнопку «Отправить» с корректным результатом. Во всех случаях наш сервер должен отвечать 200 и не иметь задержек. В случае зависаний или отправки некорректного ответа (503) при корректном сценарии, можем считать, что снова обнаружили баг.

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

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

SELECT * FROM users WHERE username=”a” OR “1”='1”;

Если на стороне сервера присутствует база данных с таблицей users, то отправка такого запроса может привести к извлечению списка всех пользователей, так как условие всегда будет положительно. Если для нашего веб‑интерфейса настроена защита от таких атак, то потери данных не произойдёт.

Вместо заключения

Конечно, я рассмотрел в этой статье не все методики проектирования тестов и не все остальные аспекты, но, надеюсь, это будет полезно новичкам в тестировании.

Спасибо за внимание! С удовольствием отвечу на дополнительные вопросы про задачи на собеседованиях. И буду рад, если дополните мои примеры в комментариях.

P. S. А здесь — наше сообщество, где мы в том числе анонсируем новые вакансии и в целом рассказываем про разработку, общаемся с пользователями и чате и так далее.

Обсудить в форуме