Тестируем самостоятельно. Лайфхаки для разработчиков

Михаил Шваркунов, ведущий инженер по тестированию «ВКонтакте», поделился с разработчиками лайфхаками самостоятельного тестирования продуктов.

Кому будет полезна статья?

• Разработчикам, у которых нет тестировщиков;
• разработчикам, которые передают ПО на тестирование;
• начинающим тестировщикам;
• продакт-менеджерам;
• интересующимся IT;
• участникам хакатонов.

Самые критичные баги и их причины

Полёт космического корабля Mariner 1

Это был 1961 год. Аппарат должен был направиться к Венере. После старта всё было хорошо ровно до 293 секунды. После аппарат потерял связь. Включилась дублирующая система, но из-за определённой ошибки в программном обеспечении ракета стала отклоняться от своего курса, и было принято решение уничтожить аппарат.

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

1983 год — возможная Третья мировая война

У Советского Союза была спутниковая система «Око», которая следила за пуском межконтинентальных баллистических ракет с континентальной части США. Было боевое дежурство Станислава Петрова. Вдруг на пульт приходит сообщение о запуске пяти ракет с территории США. По всем инструкциям должно быть около 100 ракет. Станислав подумал о возможной ошибке системы, взял ручное управление и отменил запуск ракет в ответ на запуск ракет США. Позже, как оказалось, система приняла блики в облаках от солнца за пусковые нити ракет.

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

Баги, которые стали фичами

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

Super Mario Bros.

Марио готов разбить кубик с вопросиком. Из кубика могут выпасть: монеточка, грибочек, цветочек. На бета-тестировании пользователи обнаружили баг. Из-за ошибки обнуления переменной пользователь мог получать гораздо больше монеток, чем одну. По спецификации можно было выбить одну единицу лута. Разработчики, заметив баг, решили, что это отличная идея. С тех пор баг стал частью игры.

Mortal Kombat: Ermac

В первой версии Mortal Kombat при определённых обстоятельствах жёлтый ниндзя-скорпион становился красным. Его цвет менялся из-за бага. Пользователи думали, что это пасхалка. В секретном меню можно было увидеть пункт Ermacs, который означал error macros. В последующих обновлениях этот вариант был добавлен.

Team Fortress

Если посмотреть на персонажа, который стоит перед игроком, то можно понять, враг это или союзник. Если это друг, то подсветка его ника будет в светлых тонах, но если это враг, то у него будет специальная подсветка. Однажды появился баг, который ошибочно определял персонажа как врага. Начали рождаться легенды, что при определённых условиях во время игры можно сменить расу, чтобы стать шпионом. Благодаря этим слухам разработчики в обновлении Team Fortress QuakeWorld добавили новый класс «Шпион».

Doom: rocket jump

В Doom не было возможности прыгать. Однако, если игрок подходил к стене и стрелял из ракетницы, то его отбрасывало на дальнее расстояние. Игроки стали пользоваться этим багом. Разработчики, увидев это, подумали: почему бы не изменить механику для введения новой возможности. В следующих версиях Doom появилась пасхалка. Достаточно было встать в определённое место на определённом уровне. Далее, выстрелив из ракетницы, игрок попадал на суперуровень, где его ждали супербонусы.

Streetfighter

Игра подарила игровой индустрии новую механику. В первой версии бета-тестировщики обнаружили, что если нажать два раза на кнопку удара, то удар становился неблокируемым для соперника, а для игрока — сильнее в несколько раз. Изменения были не очень критичными, и разработчики решили оставить этот баг на некоторое время. Пользователи же предлагали развивать эту механику. Во второй версии игры разработчики ввели «комбоудары».

Как протестировать быстро и качественно?

Все баги, скорее всего, не найти, но мы обязательно должны исправлять:

• блокеры — нерабочее состояние приложения;
• критикалы — когда ключевая часть работает неправильно;
• мажоры — важное отклонение, но при этом пользователь может как-то обойти его.

Как избежать блокеров, критикалов и мажоров средствами теории тестирования?

Все виды тестирования программного обеспечения в зависимости от преследуемых целей можно разделить на следующие группы:

• функциональные;
• нефункциональные;
• связанные с изменениями.

Давайте подробно рассмотрим различные методы и виды.

Функциональные виды

• Функциональное тестирование — проверка на реализуемость функциональных требований.
• Тестирование безопасности — оценка уязвимости программного обеспечения.
• Тестирование взаимодействия — проверка способности приложения взаимодействовать с одним и более компонентами или системами.

В чем плюсы и минусы функционального тестирования?

• Плюс: имитация фактического использования системы.
• Минус: вероятность избыточного тестирования.

Процесс тестирования — тест-дизайн

Например, есть форма ввода возраста, в которой можно ввести от одного до ста лет. Если вы вводите какие-то невалидные данные, то увидите тултип и подсвеченное красным цветом поле. Как доподлинно убедиться, что всё работает правильно? Нам нужно ввести все цифры от одного до ста и прокликать их. Взять какие-то цифры, не входящие в промежуток, чтобы убедиться, что тултип показывается. Это очень долго. Чтобы этого избежать, применяются методы тест-дизайна.

Методы тест-дизайна

• Эквивалентное разделение исключает набор входных данных, которые заставляют систему вести себя одинаково и давать одинаковый результат при тестировании программы.
• Анализ граничных значений — проверка значений, находящихся на границах классах эквивалентности. Например, поле принимает значение от 1 до 100. Нижние граничные значения могут быть, например, −5, а верхнее — 102.
• Предугадывание ошибки — техника тест-дизайна, для которой нужны определённые знания и способности.
• Исчерпывающее тестирование — используются все возможные комбинации данных.

Какие плюсы и минусы тест-дизайна?

• Плюс: быстрота и структурированность;
• Минус: неправильное использование.

Тестирование безопасности

Информационная безопасность держится на трёх столпах:

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

Основные угрозы с точки зрения безопасности для приложения

• XSS-угрозы — это выполнение кода злоумышленника на сгенерированной на сервере странице. Например, в пункте A выводится на экран куки. Если будет такая уязвимость, то может произойти что угодно.

url + <script>alert(document.cookie);</script>

• CSRF-угрозы — это выполнение определённых действий после перехода по ссылке на сайт, на котором пользователь авторизован, но не находится. Например, пользователь перешёл по ссылке, чтобы перевести деньги. Чтобы избежать уязвимости, используйте CSRF-токены или уникальные хеши.

<img src="http://hacker_site/?command">

• Authentication Bypass — доступ к закрытым разделам сайта в обход проверки подлинности пользователя.
• Проверка админки — некоторые разработчики забывают закрывать админкой свои сервера, или у них лёгкие пароли.
• Code injection — в поле поиска вводятся различные данные. Например, SQL-запрос, который всегда выполняется. Выведутся все данные из таблицы users, в которой пустой пароль или 1 = 1. Но пустой пароль в этом случае всегда игнорируется, потому что 1 всегда равно 1.

 SELECT *

   FROM users

  WHERE email = 'user'

    AND pass = '' or 1=1

Тестирование взаимодействия

Рассмотрим тестирование взаимодействия на примере изображения:

Здесь соединены два окна и две ручки. Всё работает, но не было интеграционных тестов. Без разбора одной из ручек окна превращаются в стены, которые к тому же не держат тепло. Таким образом, интеграционное тестирование проводить необходимо.

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

Эти виды тестирования проверяют, как работает система.

Существуют следующие виды нефункционального тестирования:

• тестирование производительности;
• тестирование установки;
• тестирование удобства использования;
• тестирование на отказ и восстановление;
• конфигурационное тестирование.

Разберём каждый вид подробнее.

Тестирование производительности

Этот вид тестирования различает:

• нагрузочное тестирование — определённый ожидаемый уровень нагрузки. Например, 1000 операций в секунду. С помощью каких-либо инструментов, например, JMeter, нагрузка эмулируется;
• стрессовое тестирование — это увеличение нагрузки. Смотрите, как ведёт себя система в стрессовой ситуации. Далее постепенно увеличивайте нагрузку, и рано или поздно произойдёт «точка отказа». Посмотрите, сможет ли сервис самостоятельно подняться после такой нагрузки;
• тестирование стабильности или надёжности — это длительное применение ожидаемой нагрузки к сервису;
• объёмное тестирование — это проверка устойчивости, например, базы данных при росте новых регистраций.

Тестирование установки

Этот вид тестирования направлен на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения. Тестирование инсталляции необходимо проводить при создании ПО после появления новой версии, а также при изменении конфигурации стенда.

Тестирование удобства использования

Этот вид тестирования даёт оценку уровня удобства использования приложения по следующим пунктам:

• производительность — сколько времени и шагов понадобится пользователю для завершения основных задач приложения;
• правильность — сколько ошибок сделал пользователь во время работы с приложением;
• активизация в памяти — повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя;
• эмоциональная реакция — как пользователь себя чувствует после завершения задачи — испытал ли стресс? Порекомендует ли своим друзьям?

Тестирование на отказ и восстановление

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

Некоторые варианты этого тестирования:

• отказ электричества;
• потеря связи с сетью;
• отказ носителей;
• неверные данные в системе.

Конфигурационное тестирование

Это проверка работы программного обеспечения при различных конфигурациях системы.

Какие проверки должны происходить?

• Кросс-платформенное тестирование;
• кросс-браузерное тестирование;
• разрешение экрана;
• серверные мощности.

Виды тестирования, связанные с изменениями

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

• smoke (с англ. «дым») — этот вид тестирования смотрит, не отвалилось ли что-то в общем. Например, есть станок. Поменяем в нём деталь и включим. Если не пошёл дым, то считаем, что тестирование пройдено.
• Sanity — определение работоспособности части приложения после изменений в коде;
• Regression позволяет убедиться, что после изменений вся функциональность работает, как и ожидалось.

Советы от Михаила Шваркунова

• Составляйте чек-листы.
• Не забывайте о них.
• Не ленитесь их проходить.
• Смотрите на продукт со стороны.
• Отдавайте код на ревью.

Полная запись выступления:

The Brown Room — независимое интернет-издание про социальные сети и современные технологии.

Автор: Артём Грачок
Редактор: Арсений Метелев
Ассистент редактора и корректор: Лена NL

Изображения и данные: VK Hackathon
Фото на превью: Лена NL / The Brown Room