сайты с багами для тестирования
Noveo
Тестовые площадки для тренировок настоящих ниндзя
Начался новый год, и, как обычно случается, многие дали себе обещания или поставили цели на 2020. Одна из целей, которую мы регулярно ставим и выполняем, — расти, развиваться и прокачивать свои навыки 🙂
Разумеется, всё определяется не одной лишь теорией, но и практическим подкреплением знаний. Поэтому сегодня наши тестировщики делятся подборкой площадок, на которых можно потренироваться во всех направлениях — и в знании определений и техник тест-дизайна, и в применении этих техник для нахождения реальных багов.
Тренажеры для тестирования без применения автоматизации
Нацелены исключительно на развитие внимательности, аналитических скиллов и логического мышления. Возможно, протестировать что-то подобное вас попросят на начальном этапе собеседования.
🔹 http://testingchallenges.thetestingmap.org — подборка разного вида полей, в которых надо найти ошибки либо провести определенные проверки. Чтобы выполнить челлендж, необходимо набрать максимум баллов. Для тех, кто любит признание, есть доска почета: после выполнения челленджа вы можете оставить свое имя в специальной формочке, и спустя некоторое время оно появится в списке решивших.
🔹 https://playground.learnqa.ru/puzzle/triangle — тренировочная площадка, на которой необходимо протестировать простую программу, которая определяет тип треугольника по его сторонам.
🔹 http://qainterview.pythonanywhere.com/ — простейшая форма, в которую нужно вводить число, чтобы получить его факториал на выходе. Только вот незадача: в форме спрятались баги, поэтому не поленитесь найти их!
Тренажеры на знание теории тестирования
Для тех, кто готовится к сертификации или просто хочет знать больше.
🔹 https://skillotron.com/skills/qa-general — подборка тестовых вопросов, ответы на которые подскажет знание теории, практический опыт или просто логика.
🔹 http://istqb-training.ru/ — русскоязычный сайт для тренировки подготовки к экзамену ISTQB.
🔹 https://www.gasq.org/en/certification/sample-exam.html — официальный тестовый ISTQB-экзамен. Очень рекомендуем тренироваться на нем, если планируете проходить сертификацию 🙂
🔹 http://www.quizful.net/interview/qa — подборка вопросов, которые могут быть заданы на собеседовании на тестировщика. Будьте внимательны и не забывайте про критическое мышление: вопросы могут добавлять сами пользователи, значит, не всегда правильный ответ на сайте — истина в последней инстанции лично для вас!
🔹https://stepik.org/course/16478 — курс-теоретический ликбез по тестированию с практическими заданиями, основанный на силлабусе ISTQB.
🔹https://www.guru99.com/tests.html — подборка квизов как на теорию тестирования, так и на знание инструментов (например, Quality center, QTP или JMeter).
Тренажеры для практики тестирования API
Разумеется, тестирование не ограничивается лишь клиентской стороной, и в этих «песочницах» вы можете попрактиковаться в отправке запросов к серверу: как исключительно вручную, так и с помощью автоматизации — инструмент выбираете вы сами, а вот API, к которому будете обращаться, и документацию к нему предоставляют следующие ресурсы:
Итак, когда вы решили все задачки в тестах выше и хотите больше практики в новой для себя сфере, а проект не позволяет «поднять» автотесты, вы можете пробовать свои силы на демо-сайтах, созданных специально для тестового использования.
Сайты-песочницы, на которых можно практиковать написание автотестов
🔹 http://computer-database.gatling.io/ — простой сайт-база компьютеров. Подходит еще и для практики нагрузочного тестирования (изначально создавался как раз для демонстрации работы инструмента Gatling, который применяется для load-тестирования).
🔹http://demo.guru99.com/ — база с демо-проектами (банковская система, система страхования, система телекома, система оплаты онлайн-заказа и т.д.)
🔹 http://automationpractice.com/ — сайт, функциональностью немного похожий на LaModa 🙂 Проще говоря, интернет-магазин одежды с доставкой.
🔹 Самый интересный, на наш взгляд, вариант: https://phptravels.com/demo. Это не просто тестовый сайт — тут ещё и тестовая админка есть!
Бонус: сайт W3Schools можно оценить не только за полезные упражнения и возможность практики, но и за раздел https://www.w3schools.com/howto/.
Как использовать его для практики, если вы не разработчик, а тестировщик? Всё просто: достаточно скопировать код готовой формы и сохранить получившуюся веб-страничку, а потом играть с ней как захочется: добавлять ID и data-атрибуты, автоматизировать заполнение, тренироваться в подборе CSS-селекторов, применяя к формам разные стили, или просто на досуге разбираться в коде, ведь если мы работаем с вебом, никогда не будет лишним знать, что и как работает «под капотом».
Конечно, если дело доходит до автоматизации, то тут и говорить нечего: нужно не только знать сам инструмент (Selenium, Cypress, Puppeteer или что-то другое), но и хорошо ориентироваться в возможностях языка программирования, выбранного для написания автотестов. Здесь вам на помощь придут они — бесплатные интерактивные площадки с теорией и задачами на разные языки программирования!
🔹 https://www.hackerrank.com/ — платформа с задачками на разные языки. Довольно интересен раздел Interview Preparation Kit, там много вопросов и на теорию, и на практические навыки решения технических задач.
🔹 https://hyperskill.org/ — интерактивный тренажер, фишка которого — проектное обучение. Вы не просто изучаете абстрактную теорию, а сразу же применяете её для создания итоговой работающей программы (а проектов там много, от имитации кофемашины до игры против искусственного интеллекта).
🔹 https://skillotron.com/ — тут достаточно выбрать необходимую квалификацию, и можно тренировать знание теории того или иного языка.
🔹 https://www.codecademy.com/ — довольно известный ресурс. К сожалению, не все курсы бесплатные.
🔹 https://sqlzoo.net/ — это тренажер исключительно для SQL-запросов, однако довольно объемный! Если знаете, что на собеседовании будут спрашивать про JOINs, порешать задачки в нем в качестве подготовки будет самое то.
🔹 https://stepik.org/catalog?tag=22872 — самые разные курсы по программированию на разных языках, тестированию, алгоритмам. Большая часть бесплатные, а задания можно выполнять прямо на сайте в окошке с code editor.
🔹https://www.sololearn.com/ — забавная площадка. Из-за простого формата вопросов и отсутствия задач на написание кода «с нуля» она не дает основательных знаний по теории языков программирования, но поиграть, вспомнить забытые навыки и просто разнообразить процесс обучения геймификацией вполне можно.
🔹https://www.codewars.com/ — тренажер, похожий на Hackerrank. Одна из ключевых фишек — так называемые «дуэли», когда можно вызвать на решение задачи соперника и посоревноваться, кто быстрее справится 🙂
🔹https://www.w3schools.com/ — наш фаворит 🙂 Много туториалов, упражнений и практических заданий.
🔹https://www.katacoda.com/learn — платформа про DevOps-практики, такие как контейнеры, CI, Bash, облачные технологии. На некоторых проектах такие знания тестировщикам могут оказаться нужнее, чем языки программирования, так что настоятельно рекомендуем обратить внимание.
Разумеется, этот список можно и нужно дополнять. Помните, что какие бы тренажеры вы ни выбрали, главное — ваше усердие и желание узнать что-то новенькое. Надеемся, что эта подборка подкрепит ваш интерес к тестированию и поможет получить новые знания и умения в 2020 году 🙂
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Сайты с багами для тестирования
Ну да, ссылка есть, все стандартно. Битрикс в этом разделе генерировать понятные урлы не обучен. Разработчик говорит: «норм». А SEO и впечатление от просмотра страдают.
8. Не указываем личные мнения
Частая ошибка — пишем не то, что надо сделать, а личные мнения. Такие комментарии покрасят серым и проигнорят.
Переформулировали. Видите, что это можно поправить — отлично, возьмите с полки пирожок. Нормальная формулировка, почти идеальная. Но пошлют. Потому что кое-кто забывает ставить приоритеты.
9. Расставляем приоритеты
Наши разработчики идут по баглистам в порядке приоритетов:
0 — критические баги, сайт не работает вообще или работает не так, как ожидается;
1 — критичное юзабилити, забытые фичи;
2 — некритичные баги;
3 — некритичное юзабилити;
4 — ошибки в текстах;
8 — хотелки.
Написали «Ссылочку мне сделай красиво». Ок. Баг без приоритета. Разработчик начнет делать вперемешку, если не проигнорит. И будет злиться и посылать в далекое пешее путешествие.
При таком подходе программист исправит баг, и даже не особо перенервничает. Ну ладно, раз просит — сделаю.
10. Не подкидываем посуду
Новый сайт Сибирикса тестировали ежедневно. Каждый день создавался новый лист. Баги отлавливались сразу.
В чем минус постоянной работы над проектом?
Терминальная стадия такого багтрекера — чат разработчика и тестировщика в режиме гуглодока. Вместо того чтобы пройти три метра и голосом задать вопрос, начинаются милые беседы — переписка по полчаса, где все считают друг друга уродами. Ну или не уродами, в зависимости от темперамента. Но обида копится. Поэтому ни в коем случае тестировщик не должен работать в одной вкладке с программистом. Вы в своей делаете, он пишет в своей. Это нормально и не бесит.
Развиваем интуицию в тестировании или где искать баги
Опытный тестировщик, особенно если он со своим проектом знаком давно, накидывает список тест кейсов довольно ловко. Но если вы еще только формируете свой профессиональный стиль или пришли в новый продукт, или просто открыты обмену опытом то, вероятно, вы найдете что-то значимое для себя в списке моих профессиональных приемов работы.
Вступление
И когда вы принимаете решения, не опираясь на аргументы, вы опираетесь на интуицию, которую приобрели просто проживая жизнь.
Изучаем use cases пользователей
Дружим с командой техподдержки
Берем в тщательную работу баги клиентов
Изучаем белый ящик
Подмечаем слабые части продукта
Разработка не бывает одинаково ровной. Иногда что-то делается в режиме прессинга, быстрей-быстрей. Такие части продукта могут давать о себе знать багами довольно долго. Здесь хорошо не терять из виду этот функционал.
Наблюдаем за разработчиками
Знать, кто какой кусок кода сделал, а главной какой он разработчик, на самом деле, очень удобно. Встречаются те, которые откровенно не любят тесты, мало их пишут, ничего не перепроверяют (это не значит, что он «плохой», у него могут быть другие таланты). Если вы узнали, что этот кусок функционала работа такого человека, нужно быть дотошнее. А есть те, кто очень скрупулезно все сверяет и выверяет. Проверять такой функционал спокойнее. Можно создать внутренний рейтинг для себя (с кем нужно быть внимательнее, а кто делает работу чисто).
Погружаемся в тему продукта
Каждый продукт существует для какой-то сферы жизни. А там целый мир: свои термины, свои понятия “хорошо” и “плохо”, свой рынок. Бывает полезно понимать эту лексику, что-то знать/читать об индустрии, наблюдать за продуктами конкурентов. Когда ты “в теме”, мозг быстро прикидывает на что нужно обратить внимание. А продукты конкурентов иногда могут научить, как сделать лучше, например, если тестируемые изменения касаются интерфейса.
Изучаем теорию тестирования
И для черноящичного и для белоящичного уже есть разработанные приемы написания тестов, они всегда могут стать отправной точкой, когда не знаешь с чего начать. (Equivalence Partitioning, Boundary Value Analysis, Decision Table, State Transition, Use Cases VS Statements testing)
Как дополнение этому пункту напишу, что вдохновение для написания тест кейсов можно черпать еще из следующих областей:
каждый acceptance criteria;
области, которые будут отправлять свои данные в новый функционал;
области, которые будут отправлять свои данные в новый функционал;
вариации коммуникации функционала с остальными модулями: через ftp, через aws, конфиги и прочее;
Каноны, стандарты, общепринятые удобства;
информативность сообщений об ошибках; представьте, что вы впервые видите продукт и столкнулись с ошибкой; сообщение вам помогло предпринять следующий шаг для ее решения?
информативность успеха; пользователь понял, что достиг желаемой цели?
единый стиль с остальными частями продукта: списки, фильтры, таблицы;
Заключение
Конечно, простой ежедневный опыт тоже откладывается в интуицию. Чем больше времени ты на проекте, тем острее его чувствуешь. А еще бывает как с вождением автомобиля, чем дольше за рулем, тем больше притупляется осторожность. В такие времена меня спасает пробежаться по чеклисту выше и проверить саму себя на тему, а не упустила ли что-то важное в новом функционале.
Эти заметки не претендуют на какую-то научность, этакий обмен опытом с моей стороны, поэтому я буду рада вашим дополнениям на заявленную тему, делитесь, пожалуйста.
Охота за багами с помощью мутационного тестирования
В этой статье вы узнаете, что такое мутационное тестирование и как его использовать в Pitest. Затем я поделюсь своим опытом обнаружения ошибок в реальном проекте.
Введение
Доказано, что отсутствие тестирования приводит к чрезмерным расходам, задержке запуска продукта, недовольству пользователей и плохой репутации бренда продукта.
Пирамида тестов
Как инженер-программист, вы можете внести свой вклад в данный процесс для достижения высокого качества и изменить ситуацию, написав тесты — особенно это касается юнит-тестов.
Однако если вы хотите улучшить качество своего набора тестов, то сначала вам нужно их оценить. Одним из простых способов решения этой задачи является измерение покрытия кода. В этой статье описаны пять видов покрытия кода:
Покрытие FSM (Finite State Machine. Конечный автомат состояния)
Когда у вас есть метрика, можно установить цель. Например, в Sipios мы считаем, что по крайней мере 80% ветви должны быть покрыты, иначе вы не сможете объединить свой код. Но нужно быть осторожным при достижении этого предела: низкое покрытие кода означает недостаточное тестирование, а высокое покрытие не гарантирует высокого качества тестов.
Самый простой пример для наглядности — можно выполнить всю свою кодовую базу во время тестирования и при этом не сделать никакого утверждения. Если говорить о покрытии ветвей, то здесь всё объясняется тем, что менее сложные ветви, как правило, легче покрыть.
Одно из решений для повышения качества ваших тестов называется мутационным тестированием.
Что такое мутационное тестирование?
Мутационное тестирование было первоначально предложено Ричардом Липтоном в 1971 году. Согласно Википедии, оно основано на двух гипотезах:
Первая — это гипотеза компетентного программиста. Она утверждает, что большинство программных сбоев, вносимых опытными программистами, связано с небольшими синтаксическими ошибками.
Вторая гипотеза называется эффектом сцепления. Данный эффект утверждает, что простые неисправности могут каскадно или попарно формировать другие, появляющиеся при этом, неисправности.
Это двухэтапный процесс: сначала необходимо генерировать мутантов, а затем попытаться уничтожить их своими тестами.
Генерация мутантов
Первый шаг заключается в генерации другой версии вашего кода. Если вы знакомы с генетическим алгоритмом (ГА), используемым в задачах оптимизации и поиска, его можно рассматривать как шаг инициализации при генерации популяции.
Этому методу требуется только ваш код и набор операторов мутации. Затем необходимо по одному использовать эти операторы в исходном коде для каждого применяемого заявления программы. Результат применения одного оператора мутации к программе называется мутантом. Обычно используются следующие операторы мутации:
Удаление, дублирование или вставка заявлений.
Замена булевых подвыражений на true и false
Замена переменных на другие из той же области видимости (типы переменных должны быть совместимы).
Удаление тела метода, реализованное в Pitest (мы обсудим Pitest позже).
Например, если вы используете только оператор, заменяющий * на / в следующем методе:
Вы получите замечательный метод деления, который следует далее:
Мутанты, генерируемые с помощью двух или более операторов, называются мутантами высшего порядка (HOM). Мы не будем обсуждать тестирование HOM в этой статье, но можно найти интересные работы о том, как их можно эффективно генерировать.
Убейте их всех
Убийство мутанта — это простой процесс. Вам нужно только выполнить тесты на мутанте. Если один из тестов красный, вы его убили. В противном случае, если все ваши тесты будут зелеными, мутант выживет.
После того как вы провели тесты на всех мутантах, можно рассчитать оценку мутации. Показатель мутации ваших тестов можно определить по проценту убитых мутантов. Чем выше этот показатель, тем эффективнее ваш набор тестов.
Чтобы разобраться в этом, давайте представим, что мы протестировали наш метод умножения с помощью следующего теста:
Теперь, когда мы знаем основы, давайте посмотрим, как это работает на практике.
Как выполнить мутационное тестирование?
В этом разделе вы узнаете, что такое Pitest и как его использовать в java-проекте с помощью maven. Мы также рассмотрим альтернативные варианты.
Что такое Pitest?
PIT — это современная система мутационного тестирования, обеспечивающая золотой стандарт тестового покрытия для Java и jvm. Она быстра, масштабируема и интегрируется с современными инструментами тестирования и сборки.
Как ее использовать?
По сути, нужно только добавить плагин в build/plugins вашего pom.xml
На странице быстрого запуска доступно огромное количество параметров конфигурации, которые можно использовать для настройки анализа. Например, вы можете указать целевые классы и целевые тесты таким образом:
Затем вы можете сгенерировать полный HTML-отчет, используя цель mutationCoverage с помощью команды:
Будьте внимательны, Pitest требует, чтобы вы запустили анализ мутационного тестирования снова с зеленым набором тестов, поэтому вам может понадобиться провести тестирование, чтобы убедиться, что все работает правильно.
Результаты
В нашем примере мы получаем 100% покрытие линии, соответствующее 50% результату мутации.
Подробности можно узнать, если кликнуть по наименованию класса. Pitest покажет вам, какие именно мутанты выжили и какие операторы мутации были использованы в отчете. Это выглядит следующим образом.
Как и ожидалось в предыдущей части, мы можем значительно улучшить качество тестирования, добавив тест, который ловит первого мутанта.
Другие инструменты
Мой путь в мутационном тестировании
Давайте поговорим о моем опыте использования мутационного тестирования. Отсутствуют доказательства того, что написание тестов для мутантов улучшает качество тестирования. Вот почему моей целью было найти мутанта, который может быть багом.
Избегайте распространенных ошибок
Создание слишком большого количества мутантов
Генерация мутантов для каждого заявления вашего кода с использованием нескольких операторов мутации приведет к созданию целой армии мутантов. Затем вам нужно будет запустить тесты на каждом мутанте. Это процесс, требующий большого количества вычислений, и если не быть осторожным, то придется долго ждать окончания анализа.
Я работаю над проектом, в котором более 15 микросервисов, и добавил конфигурацию Pitest в родительский pom.xml. Начал, не ориентируясь на какой-то класс или пакет, потому что юнит-тесты могут быть размещены в различных подпроектах по-разному. Это сгенерировало более 5 000 мутантов на микросервисы.
Определение бесполезных мутантов
Включение интеграционных тестов
Интеграционные тесты занимают больше времени, чем юнит-тесты. По умолчанию Pitest использует таймаут в 4 с, чтобы избежать блокировки в бесконечном цикле. Если ваши интеграционные тесты медленные, то для каждого из них может потребоваться время ожидания 4 с, умноженное на количество сгенерированных мутантов. Другими словами, это может занять несколько дней. Не пытайтесь это сделать, пожалуйста.
Даже если он будет завершен, нужно иметь возможность прочитать отчет.
Вы можете попытаться сгенерировать отчет по всему коду, используя все тесты. Это займет слишком много времени, чтобы использовать его в автоматическом процессе (мне потребовалось 23 секунды на сервисе с 15 юнит-тестами), и у вас будет слишком много мутантов, которые выживут. Представьте, что у меня 90% результат мутации на моих 5000 мутантов, и в результате у меня останется еще 500 мутантов для анализа. Я думаю, что проще начать с малого, а затем попробовать сгенерировать способ анализа отчета. Процесс проведения мутационного тестирования и анализа отчета отнимает много времени.
Используйте мутационное тестирование с умом
Во-первых, вам нужно найти интересующий вас фрагмент. В моем случае это был сервис из API, который был «принадлежностью» моей команды. То есть, мы отвечаем за эту часть кода.
И последнее, но не менее важное, этот сервис имеет 96% покрытие строк и 93% покрытие ветвей при выполнении всех тестов.
Это типичный вид сервиса, где кто-нибудь скоро внесет изменения, и моя команда должна будет их просмотреть. Поэтому давайте сначала попробуем внести некоторые изменения и выясним, может ли это сломать код.
Давайте сломаем все
Анализ оценок
Первое, что я увидел после генерации отчета, это то, что у нас только 50% покрытие линии юнит-тестами и 34% по результатам мутаций.
Я был разочарован 50% покрытием, поскольку казалось, что в данном случае код плохо протестирован, однако это можно легко объяснить. Действительно, чаще всего мы добавляем методы в сервисы с целью создания новых маршрутов для контроллера. В этом случае многие склонны сначала проводить интеграционные тесты. Поскольку интеграционные тесты используют сервис и его методы, то у вас будет высокий показатель покрытия кода. Когда достигается стандарт 80% покрытия кода, вы уже не думаете о написании юнит-тестов, потому что метрики показывают, что вы хорошо выполнили свою работу.
Анализ выживших
Первое, что вы можете сделать, это сосредоточиться на некоторых операторах мутации. В своем сервисе я сосредоточился на операторах мутаций, которые выживают больше всего:
26 удаление заявлений
22 нулевые возвращаемые значения
19 условных отрицаний
Я предполагаю, что statement deletion — самый простой оператор для анализа. Действительно, достаточно удалить линию и посмотреть, сохраняется ли смысл кода. Чаще всего эти мутанты возникают в сеттер-методах объекта. Иногда они могут возникать в вызовах API, но их всегда отлавливают интеграционные тесты.
Возвращаемые значения null также легко поддаются анализу и могут нанести огромный ущерб. Интересно, что нулевые возвращаемые значения можно получить с помощью удаления заявления сеттера. Вы можете представить себе создание мутанта более высокого порядка в реальной жизни только путем удаления вызова сеттера? Я думаю, это может быть интересной темой для проверки, когда вы занимаетесь защитным программированием.
Чему я научился?
Я могу это сделать!
Проанализировав всего несколько операторов мутации, мне удалось создать свой первый баг с помощью мутационного тестирования. Это отняло у меня 30 минут и только лишь условное отрицание.
Такой результат вызывает тревогу, потому что при рефакторинге кода можно пропустить подобные ошибки. На практике у нас есть длительный процесс, который позволяет отловить практически любые из них до того, как баг попадет в продакшн. Действительно, перед созданием запроса на слияние вы должны локально протестировать свою функцию. Здесь я бы поймал баг. Затем мы делаем a code review, где мои коллеги должны были заметить ошибку. Затем функция тестируется PO (Product Owner) в the development среде и с помощью QA (Quality Assurance) в preproduction.
Делать все правильно с первого раза
Мутационное тестирование помогло мне понять, что наш процесс приводит к высокому качеству. У нас есть длительный процесс, который не позволяет разработчикам создавать ошибки в производстве. Настоятельно рекомендую вам создать свой процесс и быть в нем бескомпромиссным. Думаю, что мутационное тестирование должно проводиться для того, чтобы помочь вам улучшить ваш процесс, либо применяться, если вы работаете в сферах, связанных с безопасностью или охраной.
Я также понял, что мы можем улучшить тестирование, помогая разработчикам быть более точными, при написании теста. Разделение между интеграционными и юнит-тестами должно быть достаточно осознанным, и следует использовать оба этих вида тестов. Предполагаю, что TDD (Test Driven Development) поможет достичь этого, сосредоточившись сначала на юнит-тестах, а не на создании интеграционных тестов. Это увеличило бы мутационный результат.
Мутационное тестирование помогло мне понять, что тест не обязательно уместен. Именно поэтому я буду использовать его при следующем рефакторинге. К сожалению, ему не хватает инструментов, которые бы помогли автоматизировать фазу анализа. Следите за развитием этой технологии и за тем, что могут привнести мутанты более высокого порядка.
Материал подготовлен в рамках курса «Kotlin QA Engineer». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.