Подходы к Monkey Testing для повышения качества ПО. Разбираемся, как случайное тестирование помогает выявить неочевидные ошибки и улучшить производительность.

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

Monkey testing или тестирование «обезьяной» – метод проверки ПО, сайта или приложения, который направлен на поиск ошибок при случайных обстоятельствах. Для этого тестировщик вводит данные таким образом, чтобы это не напоминало реальный сценарий действий пользователя.

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

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

Иногда Monkey testing используют в тех случаях, когда требуется провести модульное тестирование или GUI. В основе всего — попытка сломать систему.

Существует три вида «обезьяны», которая проводит проверку программного продукта:

1. Dumb Monkey – «глупая обезьяна», не имеющая представления о системе и том, как она работает. Тестировщик не может грамотно воспроизвести ошибки, он действительно совершает их случайно и не имеет достаточно глубоких познаний, чтобы их предусматривать.

2. Smart Monkey – «умная обезьяна», которая уже знает систему, какие она имеет цели и какие выполняет функции. Таким образом, тестировщик более осознанно собирает данные и они получаются достоверными. Кроме того, перед умной обезьяной стоит задача создать не случайные ошибки, а воспроизвести их и сломать систему или приложение.

3. Brilliant Monkey – «выдающаяся обезьяна» с высшей степенью развития, которая обладает глубокими познаниями и обширным опытом, поэтому может наиболее точно имитировать поведение пользователя. Этот тестировщик настолько преисполнился, что может предугадывать появление ошибок и предотвращать их.

Кроме того, существует такое понятие, как Gorilla testing. В этом случае проверка проводится в соответствии с методом ручного тестирования. Задачей тестировщика является многократная проверка модуля на прочность. В определенных пределах он вводит допустимые недопустимые входные данные. Они определяются случайно. После чего «буйная горилла» проводит проверку второстепенного кода. Это продолжается до его развала или до достижения ожидаемых результатов.

• Gorilla testing позволяет обнаруживать проблемы на ранних стадиях, поскольку данный вид проверки фокусируется на отдельно взятых модулях. Тем самым снижаются затраты при высоком покрытии.

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

• Помимо этого, с помощью Gorilla testing команда может определить уровень толерантности системы.

Процесс обезьяньего тестирования можно условно разделить на несколько этапов:

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

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

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

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

• По характеру сценариев: позитивные и негативные.

• По определенным критериям кода или запуска программы: статистические и динамические.

• Автоматизированное и ручное.

• По объектам тестирования: функциональное и нефункциональное.

• По уровню знания системы: «черный ящик», «белый ящик, «серый ящик».

• По времени: альфа-, дымовое, регрессионное, приемочное, бета-.

Monkey testing относят к типу «черный ящик» из–за своей непредсказуемости. Нередко этот тип проверки сравнивают с Ad hoc testing и специальным тестированием. Ниже разберемся в отличительных особенностях каждого из них.

Для начала тезисно выделим отличительные черты обезьяньего тестирования:

• Ключевой целью является стремление сломать систему.

• «Обезьяны» могут не иметь представления о системе, которую они проверяют, какими она обладает функциями и назначениями.

• Ошибки обнаруживаются после ввода случайных входных данных.

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

• Действия тестировщиков не прописаны в тест–сценарии и максимально хаотичны, потому что они направлены на поиск случайных ошибок.

• Для проверки могут привлекаться стейкхолдеры.

• В основном выполняется в ручном режиме, но есть инструменты автоматизации, которые также можно применять.

Теперь перейдем к отличительным чертам Ad hoc testing.

• Метод не подразумевает применение тест–кейса, все действия тестировщика хаотичные, все ошибки находятся как бы «случайно». То есть это снова имитация поведения пользователя, который был не очень осторожен.

• Тестировщик пытается уронить приложение или программу своими «незапланированными» действиями.

• В данном методе тестировщик ищет ошибки, которые не удалось обнаружить существующими кейсами.

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

• Поскольку каждый раз тестирование проходит «случайным» образом, то вести документацию по проверке достаточно сложно. То есть она может не пригодиться в будущем при работе над другим проектом.

• Ad hoc testing, так же как и Monkey testing, не дает гарантии, что все баги и ошибки будут найдены, так как некоторые области могут остаться неисследованными.

Специальное тестирование.

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

• Как и в случае с Ad hoc testing, тестировщик должен обладать глубокими познаниями в своей области и понимать тот программный продукт, с которым имеет дело. То есть для чего он создан или создается, и как он работает.

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

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

Считается, что «обезьяний» метод относительно молодой, подход к тестированию и получил недостаточное распространение в практиках компаний–разработчиков. Вероятно, это ещё потому, что оно в основном проводится вручную, что сильно тормозит процесс тестирования продукта. Какие ещё отрицательные и положительные стороны имеет «обезьяний» метод, расскажем ниже.

Положительные стороны обезьяньего подхода к тестированию.

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

• Суть метода в том, что он основан на случайных входных данных, а это значит, его проще организовать, чем тестирование по определенным сценариям, так как они требуют специальные условия.

• Для того, чтобы стать «обезьяной», не обязательно иметь глубокие познания в тестировании вообще или в какой–то конкретной его области в частности. Поэтому и есть разделение на разные типы «обезьян». Они совершенно по–разному исследуют продукт, а значит, могут рассмотреть его под разным углом. По сути, это имитация пользователей с разной степенью погруженности в ИТ–среду. То есть есть те, кто мало пользуется мобильными приложениями, поэтому будут использовать их скорее интуитивно. Есть те, кто пользовался подобным веб–приложением, но оно его по каким–то причинам не устраивало, поэтому они выбрали другое аналогичное. «Обезьяны» из высшей касты могут предвидеть модели поведения людей и имитировать их, как шерстяные собратья из зоопарка или цирка.

• Несмотря на «случайность» действий, тестировщики все–таки воспроизводят обычные бытовые ситуации, которые возникают ежедневно с разными пользователями, просто в меньшей степени. Мы привыкли, что программа должна работать определенным образом, выполнять определенные функции, то есть действовать по какому–то или каким–то заранее продуманным сценариям. Но всегда есть внештатные ситуации, которые могут привести к дестабилизации программного продукта. Monkey testing, по сути, моделирует такие ситуации.

• Чтобы осуществить настройку и реализацию тестовых примеров требуется меньше затрат.

Отрицательные стороны обезьяньего подхода к тестированию.

• Нельзя рассматривать в качестве основного вида тестирования продукта. Из–за того, что все действия выполняются хаотично, некоторые из ошибок и багов могут быть не обнаружены. А значит, при использовании программы или приложения, пользователь все равно столкнется с какой–то нестабильностью или сбоем.

• Нет возможности воспроизвести ошибку. Даже если «обезьяна» умная или выдающаяся, она все–равно выполняет свои действия «случайным» образом. Нет гарантии, что в будущем в новом продукте разработки, пусть даже аналогичном, получится повторить ту же самую ошибку, чтобы ее обнаружить и устранить.

• Данный метод тестирования менее точный и занимает больше времени. Опять же, по причине того, что отсутствует сценарий. Каждый раз тестировщик наобум выполняет действия в надежде "побуянить" от души и разрушить систему. Он действительно может найти скрытые лазейки, но также оставить новые.

• Несмотря на то, что данный вид тестирования может выполнять даже неопытный тестировщик, который только начинает свою карьеру, все–таки требуются технические знания. В разработке ценятся достоверные знания, которые в Monkey testing обычно ставятся под сомнение.

Каждый вид тестирования имеет большое значение в разработке. Разные методы позволяют обнаружить как можно больше ошибок и багов, которые могут возникнуть в тот момент, когда программой и приложением пользуется конечный пользователь. Если все проблемы удается обнаружить и устранить заранее, то команда имеет возможность выпустить на рынок качественный и конкурентоспособный продукт. Это, в свою очередь, позволит клиентам компании получить положительный пользовательский опыт.

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

И это вовсе не бананы и палки. Хотя, возможно, во время проверки продукта какой–нибудь тестировщик восполняет потерю калорий от мыслительной деятельности, поедая фрукты.

Monkey testing чаще всего выполняется вручную, так как требует хаотичности действий. Но несмотря на это, «обезьяны» все–таки используют доступные и простые инструменты, которые упрощают им работу. Среди них такие, как:

Система управления проектами.

Она предоставляет доступ к продукту разработки и содержит некоторую информацию о нем. Это подходит для Smart Monkey и Brilliant Monkey, потому что они должны иметь представление о программе или приложении, которое проверяют.

Система управления проектами.

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

Система управления проектами позволяет избежать дублирования задач и помогает координироваться с другими членами команды во время работы по интересующим вопросам.

Редактор документов.

Используется для того, чтобы фиксировать данные о результатах тестирования. Даже если все действия выполнялись «случайно», то все–равно каждый тестировщик ведет записи, так как в дальнейшем они пригодятся для составления отчетности по проекту. Кроме того, информация может быть по–настоящему уникальной и ею можно будет поделиться с коллегами для обмена опытом или для разрешения проблемы.

Инструменты автоматизации. Разберем два примера.

UI Exerciser Monkey – встроенное средство Android SDK – дает возможность проверять мобильные приложения. Командная строка запускается на любом устройстве или эмуляторе, после чего в систему посылается «случайный» поток пользовательских событий, имитирующих их действия. Это выступает своеобразным стресс–тестом для программного продукта или приложения.

Gremlins.js от команды Marmelab – является JavaScript–библиотекой для осуществления стресс–теста и производительности веб–интерфейсов. То есть она эмулирует действия пользователя в случайном порядке, чтобы сломать веб–приложение.

Вероятно, что в ближайшем будущем будет создано большее количество инструментов автоматизации «обезьяньего» тестирования, чтобы ускорить процесс и решить один из минусов метода.