какое другое название для monkey testing
Инструменты функционального тестирования — Monkey и MonkeyRunner
Monkey
Начнём с самого простого инструмента — с Monkey. Monkey является не столько инструментом функционального тестирования, сколько т.н. стресс-тестирования, либо, как говорится на официальной странице документации проекта — UI/Application Exerciser. Грубо говоря, Monkey эмулирует попадание телефона с запущенным приложением в лапки к обезьянке (ну или в руки к маленькому ребенку), с последующими хаотичными действиями «пользователя». Впрочем, Monkey позволяет достаточно гибко настроить «хаотичность», интервал между событиями, их тип и т.п. Для подобного тестирования исходный код приложения не требуется — оно просто должно быть установлено на устройство либо эмулятор, а запуск в простейшем случае осуществляется следующим образом из консоли:
Указывается имя пакета вашего приложения и количество генерируемых событий. В случае возникновения исключения (Exception), соответствующий stack trace будет выведен в консоль:
Вот и все о Monkey — тестируйте свое приложение, и возможно, это сделает его более надежным — кто знает.
MonkeyRunner
Несмотря на схожее с Monkey название, MonkeyRunner совершенно другой инструмент, который позволяет выполнять функциональное тестирование приложения («прокликивающие» тесты), предоставляя API для управления устройством. MonkeyRunner является более низкоуровневым по сравнению с Robotium, и не требует исходного кода приложения в сравнении с Robolectric. Но только лишь тестированием область применения MonkeyRunner не ограничивается — с его помощью можно строить системы, контролирующие android-устройства через UI (и не только). MonkeyRunner использует Jython и скрипты или сценарии тестов могут быть написаны на Python, или записать действия пользователя с помощью рекордера.
Запись и проигрывание сценария
Из состава SDK нам понадобятся два python-скрипта: для рекордера и плеера. Запускать их нужно соответственно с помощью monkeyrunner :
Рекордер выглядит примерно так: 
С помощью кнопки «Export actions» сценарий может быть записан в файл, после чего его можно будет воспроизвести плеером:
Конечно же, эмулятор должен быть запущен при всех вышеперечисленных действиях.
Как видно из скриншота, MonkeyRunner оперирует координатами для выбора элемента управления, что конечно же не столь удобно, как выбор элемента в Robotium или Robolectric и будет зависеть от размеров экрана, но может быть, что такое поведение будет востребовано для создания сценариев тестирования приложений, не обладающих привычными элементами интерфейса — например, игр.
Написание сценария
MonkeyRunner позволяет описывать собственные сценарии с использованием Python. В дополнение к управлению интерфейсом возможны удаление и установка приложения, сохранение скриншотов и прочее. Пример такого скрипта:
Более подробно о возможностях, предоставляемых API можно узнать в официальной документации к MonkeyRunner.
Интеграция с Eclipse
Можно конечно создать для сценариев отдельный Python-проект.
Вот собственно и все, о чем хотелось вкратце рассказать. Возможно, описанные инструменты тестирования будут вам полезны.
вторник, 3 ноября 2020 г.
Что такое monkey testing
Самый известный тип тестирования, ведь все начинают с него )))
Просто берем. И тестируем! Без цели, без плана. Просто тыкаемся везде с намерением что-то сломать. Как обезьянка.
Между прочим, метод работает! Мы можем влететь на такую ошибку, которую сами бы никогда не нашли. Просто не догадались бы, что это другой класс эквивалетности. Всякое бывает.
А еще бывает такое, что приложение тупо падает от манки-тестирования. То есть после хаотичного тыкания во все подряд (особенно актуально для мобильных приложений). Или памяти не хватает, или вы случайно задействуете комбинацию, которая все разваливает, или еще что.
Есть даже автоматизация манки-тестинга! Да-да, создается робот, который просто тыкает во все подряд. Генерирует кучу случайных значений и пихает во все доступные поля. И снова ходит и тыкает, тыкает, тыкает.
Вот почему я вспомнила про мобильные — именно для них и пишутся такие роботы. Можно и для простого ПО написать, но в мобилках это популярнее и профита больше. Написал робота, ушел домой. А он всю ночь тыкает, тыкает. Пришел утром — все зависло / упало. Дальше локализуем.
Вот тут и возникает проблема — как понять причину ошибки, если ты бессистемно тыкал во все подряд?
Когда я работала на первой работе и тестировала игры на мобильных, у меня было несколько таких случаев. Когда баг воспроизводился «по наитию». Тогда то я еще не знала о существовании классов эквивалентности и всякого такого. Очень тяжело было воспроизводить!
Сделали игрушку — бильярд. Сижу, тестирую. Дело было поздним вечером, я проверяла уже N-ный телефон. Проверив основные идеи, просто стала тыкать туда-сюда, отключив мозг и думая о чем-то своем.
И тут я бью по мячу, а он ударяется об один борт, потом о другой, третий. И не останавливается! Обычно же бьешь сильно, но инерция проходит и он катится все медленнее и медленнее. А тут нет! Что-то где-то не сработало и мячик не снижал скорости. И в лунку так и не влетел, катался по квадрату между стенками. 5 минут, 10.
Сначала я завороженно смотрела на это. Потом мимо прохошел генеральный директор — зашел к нам в настольный теннис поиграть. Показала ему, похвастаться, что нашла. Похвалил, ушел играть)))
А я остановила игру и стала пытаться воспроизвести ошибку. Вся раслабленность и «мысли о своем» испарились, теперь я была сосредоточена на игре. Но. Воспроизвести почти случайную последовательность силы и направления удара?
Мне так и не удалось. Если бы были средства записи экрана, возможно, разработчик даже смог бы исправить баг. Правда, как такое проверять, я не представляю. Только на уровне кода или автотеста!
Тем не менее тот найденный манки-тестингом баг до сих пор помню. 10 лет прошло, но засело в голове, ведь так и не смогла локализовать ошибку.
Игрушка, в которой ты рисуешь линии, а потом по ним катится человечек на санках. Задача — чтобы он катился как можно дольше.
Там тоже однажды нашла баг чисто случайно. Мозги отключились и я просто тыкала игрушку. Тык-тык-тык, о, баг! Сразу оживилась, круто же, там картинки накладываются друг на друга. Сейчааааас как покажу разработчику!
Пытаюсь воспроизвести — не получается! Оооо, как я мучилась тогда с этим багом, весь вечер корячила. И все пыталась вспомнить, что же я делала, ну что?! Вот бы мне тогда видео-запись моих действий.
Баг, кстати, воспроизвела. И если бы знала про классы эквивалентности, тестовые туры и прочее, могла бы и раньше воспроизвести. Насколько я помню, там надо было выйти в меню и отменить какое-то действие, и вот тогдаааа!
Если вы оставляете манки-робота на ночь, обязательно включите запись видео действий. Иначе единственная надежда будет на то, что разработчик по стеку ошибки поймет, где косяк в коде. А если не поймет — воспроизводите как хотите.
Перезапуск робота тут не поможет, ведь вся его фишка — в рандомности. Запустили один раз, он тыкался в одни места, вводил одни значения. Запустили второй — он не повторит тот же маршрут. А, значит, если он случайно попал на комбинацию, приводящую к багу — ее надо или самим искать, или надеяться, что робот сможет ее повторить за ночь.
Gremlins.js — monkey testing библиотека для веб приложений
Это первая из двух статей, рассказывающая о тестировании с помощью gremlins.js и grunt-gremlins. Первая статья — перевод официальной документации gremlins.js. Вторая — опыт внедрения gremlins.js в реальный проект при помощи grunt-gremlins.
Gremlins.js это monkey testing библиотека написанная на JavaScript, для Node.js и браузеров. С ее помощью проверяется надежность веб-приложений под полчищем гремлинов.
Kate: What are they, Billy?
Billy Peltzer: They’re gremlins, Kate, just like Mr. Futterman said.
Предвидите ли вы все необычные пользовательские сценарии при разработке HTML5 приложений? Можете ли вы обнаружить и устранить возможные утечки памяти? Если нет, ваше приложение рано или поздно может дать сбой. Если случайные действия могут положить ваше приложений, лучше узнать о проблемах на стадии тестирования, вместо того, чтобы позволить пользователю обнаружить их самостоятельно.
Gremlins.js эмулирует случайные действия пользователя: гремлины кликают везде, куда могут добраться, вводят случайные данные в формы, или перемещают мышь над элементами, которые этого не ожидают. Их цель: вызвать JavaScript ошибку или заставить приложение выйти из строя. Если им это не удалось, поздравляю! Приложение достаточно пуленепробиваемо для того, чтобы показать его реальным пользователям.
Эта практика так же известна как Monkey testing или Fuzz testing, она широко распространенна в мире мобильной разработки (посмотрите на Android Monkey program). Сегодня, когда интерфейс (MV*, d3.js, Backbone.js, Angular.js, etc.) и бекенд (Node.js) разрабатывается полностью на JavaScript, эта технология становится применима и для веб приложений.
Базовое использование
Полчище гремлинов ( horde ) — это армия из специализированных гремлинов, готовых встряхнуть ваше приложение. Выпустите ( unleash ) их для начала стресс тестов:
Gremlins.js предоставляет несколько типов гремлинов: некоторые кликают во всевозможных местах, другие заполняют формы данными, кто то скролит окно браузера, и т.д.
Вы можете наблюдать за их поведением в окне браузера (они оставляют за собой следы) или отслеживать логи в консоли:
Кроме того, существуют безвредные могваи ( mogwais ). Могваи только наблюдают за активностью приложения и записывают дынне в лог. Для примера, «fps» могвай каждые 500ms показывает количеcтво кадров в секнду (FPS).
Иногда могваи сообщают, когда гремлинам все же удалось навредить приложению. К примеру, если fps опустится ниже отметки в 10, fps могвай выведет ошибку в лог:
После 10 ошибок специальный могвай Gizmo остановит тестирование и всех выпущенных гремлинов. В конце концов, после первых 10 ошибок, вы уже знаете, что вам нужно сделать, чтобы сделать ваше приложение более устойчивым.
Гремлины, как и могваи — это простые JavaScript функции. Если gremlins.js не предоставляет необходимых вам гремлинов, вы довольно просто можете реализовать их самостоятельно:
Загляните в папку с примерами, чтобы лучше понять как работает gremlins.js.
Вы можете сконфигурировать любой компонент в gremlins.js; расширяйте функциональность и адаптируйте ее для своих сценариев.
Установка
В браузере, файл gremlins.min.js может быть добавлен как сторонняя библиотека, после чего gremlins будет доступен в глобальном пространстве имен:
Есть возможность подключить gremlins.min.js как RequireJS модуль, не засоряя глобальное пространство имен:
Продвинутое использование
Настройка гремлинов и могваев для использования в тестах
Изначально все гремлины и могваи уже добавлены в полк ( horde ).
Вы так же можете выбирать и добавлять только необходимых вам гремлинов с помощью метода gremlin() у объекта horde :
Для того, чтобы добавить ваших собственных гремлинов к стандартным, воспользуйтесь методом allGremlins() :
Чтобы добавить могваев, используйте методы mogwai() и allMogwais() таким же образом.
На данный момент gremlins.js поставляет несколько гремлинов и могваев:
Конфигурация гремлинов
Все гремлины и могваи поставляемые в gremlins.js являются настраиваемыми функциями ( configurable functions ), то есть вы можете изменить логику работы их методов.
Для примера, гремлин clicker — это функция, возвращающая объект, который вы можете вызвать напрямую:
Гремлин clicker имеет следующие методы для кастомизации:
Каждый гремлин или могвай имеет собственные методы для настройки, советую изучить исходный код каждого из них.
Больше информации о конфигурируемых функциях ищите в статье о service closures.
Поддержка Random Seed
Если вы хотите, чтобы ваши атаки можно было повторить, вам необходимо инициализировать генератор случайных чисел. Gremlins.js использует Chance.js для генерации случайных данных, таким образом его можно инициализировать:
Выполнение кода до или после атак
Вы можете исполнять произвольный код до начала тестирования. Обычно бывает полезно:
Для очистки тестового окружения, объект horde так же предоставляет метод after() :
Оба метода поддерживают асинхронный вызов callback’a:
Стратегия
По умолчанию гремлины будут атаковать ваше приложение в произвольном порядке разделенные промежутком в 10ms. Эта стратегия атаки называется distribution. Изменить ее можно используя метод horde.strategy() :
Существует возможность использовать и другие стратегии. Стратегия — это просто callback ожидающий три параметра: массив гремлинов, объект (возвращенный в результате unleash() ) и финальный callback. В комплекте идут еще две встроенных стратегии (allTogether и bySpecies) и реализовать собственную стратегию для более специфичных сценариев атак должно быть предельно просто.
Остановка тестирования
Модификация логирования
По умолчанию, gremlins.js выводит в консоль все действия гремлинов и наблюдения могваев. Если для вас предпочтительней использовать альтернативный метод журналирования (к примеру, хранить активность гремлинов в localStorage и отправка их каждые 10 секунду c помощью AJAX), просто передайте объект logger с четырьмя методами (log, info, warn, и error) в метод logger() :
Вместо создания собственного логгера, посмотрите в сторону Minilog
Что такое тестирование на обезьянах и гориллах? Примеры, Разница
Обезьяна Тестирование
Что такое тестирование гориллы?
Модуль можно протестировать более ста раз и таким же образом. Итак, Gorilla Testing также называют «разочаровывающим тестированием».
Преимущества тестирования на обезьянах:
Недостатки тестирования на обезьянах:
Можно считать, что тестирование на обезьянах, тестирование горилл и специальное тестирование одинаковы, поскольку во всех них присутствуют некоторые похожие факты, но на самом деле они отличаются друг от друга.
Сначала мы увидим разницу между тестированием на обезьянах и гориллах. Сначала будьте ясны с этим, чтобы избежать путаницы.
Тестирование на обезьянах V / s Тестирование горилл:
Как только вы очиститесь от этой разницы, посмотрите дальше;
Тестирование на обезьянах против специального тестирования:
Типы тестирования на обезьянах:
Обезьянье тестирование далее делится на несколько категорий в зависимости от способа его реализации. См. Следующую схему, чтобы получить быстрое представление о нем;
Monkey Testing также можно выполнить для Android. Обезьянье тестирование может стать эффективным с использованием инструментов. Даже его можно использовать для поиска ошибок, как и другие типы тестирования. Если мы будем использовать инструмент для тестирования на обезьянах, каков будет общий процесс для этого? Просто взгляните быстро;
Процесс Monkey Testing можно автоматизировать даже с использованием инструментов, но, поскольку это какой-то новый вид тестирования, представленный и еще не установленный на отраслевом уровне, эти инструменты менее идентичны, в отличие от других. Эта ситуация может измениться с наступлением эры процесса тестирования, тогда мы рассмотрим предстоящее влияние тестирования Monkey и его значительное влияние на отраслевые стандарты. Это вводное руководство по тестированию на обезьянах, в котором рассказывается об основных его представлениях.
Резюме:
Эта статья предоставлена Дханшри Салви
Мысли о тестировании вслух
четверг, 8 апреля 2010 г.
Про обезьянок в тестировании
28 комментариев:
Как вы всё замечательно написали! Когда я мельком прочитал ту заметку, которую вы упомянули вначале, мне это тоже резануло глаз и я в очередной раз решил этот блог не читать, всё-равно дребедень полная. Жду когда Алексей Баранцев проапдейтит агрегатор, чтобы была подпись с какого блога заметка, чтобы не тратить время а сразу пропускать мимо глаз и ушей.
Кстати, возможно вам понравится книга (если вы её еще не читали) «Дизайн пользовательского интерфейса 2. Искусство мыть слона» (http://uibook2.usethics.ru/) Там, в частности говорится «Еще хуже дело со словом «юзверь». Скажу искренно — если вы его употребляете, вы никогда не сможете сделать хорошего интерфейса. С вами уже всё кончено; ваше сознание безнадежно ущербно. Если на этом месте вы почувствовали горячее
желание меня переубедить и доказать мне, что слово «юзверь» вполне приемлемо, воздержитесь.»
LeshaL, спасибо за ваш комментарий, а то я уж приготовилась отбиваться от людей, которые начнут виртуально пинать меня ногами за написанное 🙂 Хотя может ещё и такие будут. 🙂
Сначала подумал что что-то пропустил, потом оказалось что это автор, которого я не читаю и не воспринимаю серьезно. Смотрю автора по ссылке заголовка.
Вообще, есть такое понятие, monkey test http://en.wikipedia.org/wiki/Monkey_test
Но в упомянутой заметке явно не это имелось ввиду. Сам использую в обиходе понятие манки тестинг, но в правильном контексте.
Если честно, то приходилось общаться с людьми, которые кроме прогона и актуализации тест-кейсов больше ничего не могут. Ну нет желания у людей развиваться видимо, да и работа неинтересная как им кажется. В общем, их и тестировщиками даже не назовешь.
Кстати, что касается блога, статья из которого послужила для меня «вдохновением», то я как-то не делю для себя блоги на плохие и хорошие. Люди пишут, что думают, и никогда не знаешь, где почерпнёшь для себя что-то полезное. Но может я чего-то не понимаю. %)
Печально, когда такой инструмент становится образом жизни.
Радует, что по запросу в гугле «тестер обезьянка», первый линк на блог Лены. Ударим мыслью вслух по невежеству айтишных и околоайтишных кругов.
Ну откровенно говоря, если тебе говорят, что ты хреновый специалист, то что тут обижаться?
Ну да, все люди способны на большее, но это ведь не сразу. по моему логично начинающий = неопытный = манки. что тут плохого?
Давайте я попробую сделать выводы из того, что вы сказали:
Итак, я спросила, какова была бы ваша реакция, если бы вас так назвали, т.е. назвали «манки»; и вы мне ответили, что нечего обижаться, если тебе говорят, что ты «хреновый специалист».
Отсюда я понимаю, что для вас «манки» = «хреновый специалист». Я не ошиблась?
Далее вы сами пишите, что «начинающий = неопытный = манки». Исходя из предыдущего вывода, можно продолжить:
«начинающий = неопытный = манки» = «хреновый специалист». Надеюсь, я снова не ошиблась.
Вы серьёзно так думаете? Пришёл новый человек, ещё ничего не знает, ничего не умеет, но он хочет всё узнать и всему научиться, а вы его обзываете «хреновым специалистом» по умолчанию, только потому, что он новичок? Думаете, это правильно?
Кстати, я что-то не совсем понимаю ещё одну вашу мысль: плохо кого-то _называть_ обезьяной, но нормального кого-то _считать_ обезьяной. А в чём принципиальная разница? В том, что человек, когда вы его таковым считаете, но не называете, не побьёт вам лицо?
А сколько у вас длится это «не сразу»?
Для меня, называя человека «манки», вы отрицаете его способность самостоятельно мыслить. Относясь же к человеку как к «манки» и давая ему задания «уровня манки», вы сами способствуете тому, чтобы человек не думал.
А считать и думать вы можете, безусловно, всё, что угодно. Но лично мне, придя новичком, мягко говоря, не понравилось бы, если бы меня считали «манки» (а это не может не чувствоваться или не стать рано или поздно известным).
И весь мой опыт говорит о том, что гораздо лучшие результаты человек выдаёт тогда, когда в него верят, и когда к нему как к личности изначально относятся с уважением.
Ну как, убедились в адекватности суждений? Человек, который так лихо решает кто какой специалист навряд ли сам является стоящим специалистом. Например, хороший специалист Джеймс Бах считает, что можно начинать приносить пользу в проекте примерно через 15 минут. Сравнив 15 минут и месяц можно примерно представить себе насколько Сергуня сам манки.
Пожалуй, я воздержусь от комментариев. 🙁
человек произошел от обезьяны в природе, так почему же и в тестировании не может быть подобной эволюции? хотя согласен, звучит нехорошо.
Всё думала, что бы ответить, чтоб не повторить свою исходную тираду.
Проблема-то как раз в навешивании ярлыков. И думаю, что это навешивание гораздо больше говорит именно о тех, кто эти самые ярлыки навешивает.
Лена, вы молодец, что подняли этот вопрос. Я просто в шоке, что есть такое понятие. Как корабль назовешь, так он и поплывет. Если бы я три года назад, когда пришла на должность тестировщика, узнала, что я, человек с высшим образованием, опытом работы и да и просто человек, для кого-то в команде просто обезьянка, кликающая мышкой, ноги бы моей не было и секунды в этой организации. Но мне повезло, что вокруг меня были не такие профи, как Сергуня.
Это конечно а-ля некропостинг уже, но все же.
Как правило, такие люди очень редко развиваются в профессионального тестировщика, и работают долгие годы за копейки, или же вовсе уходят из тестирования в будущем. Очень многих таких товарищей отсеивал лично на собеседованиях, т.к. это абсолютно бесперспективная личность для любой компании.
Чтобы назваться «манки-тестером», совершенно не нужно быть новичком. И наоборот, начинающий тестировщик может оказаться очень ценным сотрудником, т.к. имеет желание профессионально расти и изучать то, в чем он пока не компетентен.
Ой, сколько я, оказывается, комментариев каким-то образом пропустила. Но, наверное, лучше поздно. чем никогда 🙂