Лекция
Привет, Вы узнаете о том , что такое обезьянье тестирование, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое обезьянье тестирование, monkey testing , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..
В тестировании программного обеспечения , обезъянье тестирование представляет собой метод , в котором пользователь тестирует приложения или системы, обеспечивая случайные входы и проверять поведение, или увидеть , будет ли сбой приложения или системы. обезьянье тестирование обычно реализуется в виде случайных автоматических модульных тестов . Обезьяний тест ( англ. Monkey Test ) - в компьютерной науке автоматизированный тест , который выполняется без специфического, четко определенного тестового сценария . Название является метафорическим, имеется в виду, что операции ввода данных является случайные и бессмысленные, как будто их выполняет обезьяна. Например, обезьяний тест может вводить произвольные строки в поля ввода, чтобы проверить корректность работы системы в случае введения любых возможных данных. Данные введения могут быть заданы заранее, случайными генерируемыми, генерируемыми с учетом статистики пользователя
В то время как источник названия «обезьяны» является неопределенным, то , как полагают некоторые , что название связано с теоремой бесконечной обезьяны , который утверждает , что обезьяна , поражающие ключи в случайных на клавиатуре пишущей машинки для бесконечного количества time почти наверняка напечатает данный текст, такой как полное собрание сочинений Уильяма Шекспира . Некоторые считают, что это название происходит от классического приложения Mac OS «Обезьяна», разработанного Стивом Кэппсом до 1983 года. Оно использовало ловушки журналирования для подачи случайных событий в программы Mac и использовалось для тестирования ошибок в MacPaint .
Monkey Testing также включен в Android Studio как часть стандартных инструментов тестирования для стресс-тестирования .
Тестирование обезьян можно разделить на интеллектуальные тесты обезьяны или тупые тесты на обезьянах .
Умных обезьян обычно идентифицируют по следующим характеристикам:
Некоторые умные обезьяна также называют гениальными обезьянами , , которые выполняют тестирование в соответствии с поведением пользователя и указать некоторые вероятности ошибок , чтобы быть повреждено.
Глупые обезьяны, также известные как «невежественные обезьяны», обычно идентифицируются по следующим характеристикам
Тестирование на обезьянах - эффективный способ выявления некоторых нестандартных ошибок. Поскольку тестируемые сценарии обычно являются специальными , тестирование на обезьянах также может быть хорошим способом выполнения нагрузочного и стресс-тестирования. Внутренняя случайность обезьяньего тестирования также делает его хорошим способом поиска серьезных ошибок, которые могут нарушить работу всей системы. Настройка тестирования на обезьянах проста, поэтому подходит для любого приложения. Умные обезьяны, если их правильно настроить с использованием точной модели состояния, могут действительно хорошо находить различные виды ошибок.
Случайность тестирования на обезьянах часто делает обнаруженные ошибки трудными или невозможными для воспроизведения. Неожиданные ошибки, обнаруженные при тестировании на обезьянах, также могут потребовать много времени и времени для анализа. В некоторых системах тестирование на обезьянах может продолжаться долгое время, прежде чем будет обнаружена ошибка. Для умных обезьян способность сильно зависит от предоставленной модели состояния, а разработка модели хорошего состояния может быть дорогостоящей.
Хотя тестирование на обезьянах иногда трактуется так же, как тестирование с использованием нечеткого алгоритма , и эти два термина обычно используются вместе, некоторые полагают, что они различаются, утверждая, что тестирование на обезьянах больше касается случайных действий, в то время как тестирование с помощью нечеткого алгоритма больше касается случайного ввода данных . Об этом говорит сайт https://intellect.icu . Обезьянье тестирование также отличается от специального тестирования тем, что специальное тестирование выполняется без планирования и документации, а цель специального тестирования состоит в том, чтобы случайным образом разделить систему на части и проверить их функциональность, что не является случай в испытании обезьяны.
В этой статье утверждается, что обычные среды модульного тестирования не предлагают
надлежащая поддержка для систематического тестирования объектно-ориентированных модулей. Основанная на модели конечного автомата и более структурированная система представлена как предлагаемая
улучшение.
1 Что плохого в традиционном подходе?
При рассмотрении того, как тестировать, важны два аспекта OO-unit 3.
это: состояние и поведение. Поэтому исчерпывающее тестирование объектно-ориентированного
По сути, единица означает, что для всех возможных состояний единицы поведение
объекта утверждается, гарантируя, что блок обрабатывает все возможные входные данные
правильно. Конечно, исчерпывающее тестирование любого нетривиального модуля в большинстве случаев
потребовалось бы слишком много времени, чтобы быть практичным. Поэтому тестеру следует выбрать
ряд важных состояний и ряд важных входных последовательностей,
используя, например, анализ предметной области или разделение классов эквивалентности .
Обычно автоматизированное модульное тестирование проводится путем написания скриптов,
где тестируемая реализация (IUT) приводится в определенное состояние,
при этом функциональность IUT проверяется на соответствие техническим условиям.
К сожалению, обычные тестовые сценарии часто пишутся на специальной основе.
способом, не анализируя истинную природу IUT. Таким образом, легко
пропустить состояние, функциональность которого необходимо протестировать, или не проверить какой-либо аспект
функциональности в определенном состоянии.
Кроме того, обычный способ модульного тестирования относительно статичен,
это означает, что компьютер не участвует в тестировании в других
1 http://www.xprogramming.com
2 http://www.junit.org
3 В объектно-ориентированной области единица - это, по сути, объект.
1 способ, чем проверка вывода устройства на соответствие некоторому набору предопределенных
значения.
2 Конечный автомат - модульное тестирование на основе модели
Подход к модульному тестированию на основе модели конечного автомата требует, чтобы тестировщик
разрабатывает модель конечного автомата подразделения. Модель должна содержать
состояния, важные для тестирования, и переходы между этими состояниями.
Переходы должны эффективно проверять все сообщения, которые можно использовать для получения
из одного состояния в другое.
2.1 Пример тестовой модели
Рассмотрим простой пример: стек с ограниченной максимальной емкостью.
(предположим, что стек может содержать не более десяти объектов). Простая модель
для этого случая будет включать три состояния: пустой (стек не содержит объектов),
полный (стек содержит максимальное количество объектов) и загружен (стек равен
ни пустой, ни полный). Пустые и полные категории содержат только одно состояние,
но есть ряд реальных состояний, которые попадают в категорию загруженных. За
простота, одно реальное состояние выбрано для представления всех загруженных категорий-состояний.
В этом примере стек в загруженном состоянии будет содержать четыре объекта.
В этом примере в стеке есть три метода, которые изменяют состояние
стек: push (добавляет объект поверх стека), pop (удаляет самый верхний
объект стека) и очистить (удаляет все объекты из стека). Данный
эти методы и набор состояний, идентифицированных ранее, шесть переходов
идентифицировано:
1. От пустого к загруженному: четыре push-вызова.
2. От загрузки до полной: шесть push-вызовов.
3. От загруженного к пустому: четыре звонка.
4. От загруженного к пустому: один сигнал сброса.
5. От полной к загрузке: шесть push-вызовов.
6. От полного к пустому: один вызов.
2.2 Соответствующие Oracle
Оракул дает ожидаемые результаты для тестового примера (Binder, 2000). Этот
раздел описывает несколько шаблонов оракула, относящихся к модели конечного автомата.
тестирование.
2.2.1 Решенный пример Oracle
Решенный пример оракула полагается на набор предопределенных утверждений, обычно
выбирается с помощью разделения на эквивалентность и анализа граничных значений. в
в случае тестирования на основе модели конечного автомата это означает, что для каждого моделируемого
В государстве существует набор тестов, которые гарантируют правильную работу IUT. В
По сути, эти тесты гарантируют, что состояние инвариантно для каждого состояния hodlds. К
Избегайте избыточного тестового кода, также следует написать инвариантный тест класса. В
инвариант класса будет утверждаться после каждого перехода.
2.2.2 Другой, но эквивалентный Oracle
Другой, но эквивалентный оракул использует характеристики государства.
модель машины. Когда два отдельных экземпляра IUT вводятся в
одного и того же состояния, они должны быть логически равны, даже если состояние достигается через
разные пути перехода.
Поскольку обычно IUT очень быстро переводится из одного состояния в другое,
легко изучить огромное количество переходов и посмотреть,
последовательности нарушают реализацию.
2.2.3 Дымовое испытание
Несколько тривиальный, но, тем не менее, важный аспект модельно-ориентированного тестирования - это дымка.
ул. Дымовой тест означает, что IUT тренируется с
количество предположительно законных последовательностей сообщений, чтобы увидеть, действительно ли происходит аварийное завершение в какой-то момент Дымовой тест пройден просто, когда нет
обнаружено ненормальное состояние.
Опять же, дымовой тест, сделанный с помощью тестера на основе модели конечного автомата, требует только указания того, как IUT переводится из одного состояния в другое.
(хотя и применяя методы, не участвующие в создании государства
переходы конечно помогает)
Если стек, который использовался в качестве примера, использует массив для хранения своих
содержания, дымовой тест может, например, выявить логические ошибки при обращении к
индексы таблицы (при условии, что реализация используемого языка программирования может определить, когда индекс массива выходит за границы), или если
3
последняя возможная операция push не добавляет элемент в стек (последняя
pop-операция, вероятно, потерпит неудачу).
Этот вид дымового тестирования может также обнаружить утечки памяти, если очень долго
последовательность переходов выполняется для одного экземпляра системы под
тест.
2.2.4 Встроенные Oracle
Некоторые языки, такие как Ei el и Java (начиная с версии 1.4), имеют прямую поддержку.
для средства утверждения, которое можно использовать для записи встроенных утверждений в код
чтобы убедиться, что инварианты верны.
Однако использование встроенных утверждений не гарантирует, что ошибки действительно
найдено - код должен быть сначала выполнен с входом (ами), который раскрывает
ошибки. Хорошо написанный тестер на основе модели конечного автомата дает коду хорошее
тренировки, давая возможность встроенным утверждениям выявить возможные ошибки.
2.3 Выбор путей перехода
Есть несколько способов выбрать пути перехода для выполнения.
тестов на основе моделей конечных автоматов. В этом разделе описывается несколько вариантов.
2.3.1 Все переходы
Компьютер выбирает пути так, чтобы все переходы выполнялись как минимум
один раз. Если все переходы не могут быть выполнены с одним экземпляром юнита
при тестировании компьютер создает столько экземпляров, сколько необходимо.
Этот метод можно использовать в ситуациях, когда другие методы потребуют
излишне долгое время для выполнения.
2.3.2 Случайные пути
Учитывая начальное число для случайного генератора, максимальную длину пути и
количество повторений, компьютер случайным образом переключает экземпляр
тестируемый блок в соответствии с моделью конечного автомата. Когда тупик
состояние или достигнута максимальная длина пути, компьютер создает новый
экземпляр экземпляра и запускается снова.
2.3.3 Дерево перехода
Учитывая максимальную глубину, компьютер генерирует дерево переходов и
выполняет все переходы до конечных узлов этого дерева. В другом
4
словами, компьютер выполняет все различные пути, которые максимально
заданная длина (глубина дерева).
2.3.4 Циклический тест
При просмотре модели конечного автомата компьютер выбирает (если возможно)
переходы, не ведущие в тупик. Другими словами, компьютер
выполняет только циклические подпути. Цель состоит в том, чтобы заработать очень большую сумму
переходов с одним экземпляром тестируемого модуля. Это эффективно
для дымовых испытаний.
3 обезьяны
Monkey4 Unit - это фреймворк для модульного тестирования на основе модели конечного автомата для Java.
в настоящее время в стадии строительства. Это будет расширение популярного JUnitframework.
Чтобы определить набор тестов Monkey Unit, автор тестов делает следующее:
шаги:
1. Для каждого перехода написан метод, выполняющий вызовы методов.
тестируемого устройства, чтобы довести его до конечного состояния перехода
2. Модель конечного автомата описывается путем определения источника и
target- состояния для каждого из переходов
3. Шаблон Factory Method используется для определения того, как создать новый
экземпляр тестируемого устройства. Фабрика привязана к своему целевому состоянию,
то есть состояние, в котором будет находиться тестируемый модуль после того, как он был
созданный. Заводов может быть несколько.
4. Как правило, инвариантные к классу и состоянию решаемые примеры тестов пишутся
и привязаны к своим состояниям.
Чтобы собрать все вместе, пользователь предоставляет ссылку на конечный автомат.
модель, которая используется для тестирования. Пользователь также предоставляет информацию о том, какие
типы оракулов (первоначальная версия Monkey Unit будет
минимум включать явную поддержку инвариантного тестирования состояния / класса и других
но эквивалент -oracle).
Набор Monkey Unit выполняется через один из стандартных JUnit.
TestRunners. В случае возникновения неисправности блок обезьяны должен сгенерировать тест
4
Обезьяна - это метафора алгоритмов, которые выбирают способ обхода модели и
проверено.
5
отчет с описанием (по крайней мере) того, какой путь перехода был выполнен, какой
Тест выявил неисправность и на какой линии.
Одно из возможных будущих применений Monkey Unit - использовать его для тестирования многопоточности.
единицы. Вероятно, это означало бы просто выполнить несколько тестов Monkey Unit в отдельные потоки.
Данная статья про обезьянье тестирование подтверждают значимость применения современных методик для изучения данных проблем. Надеюсь, что теперь ты понял что такое обезьянье тестирование, monkey testing и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.
Комментарии
Оставить комментарий
Качество и тестирование программного обеспечения. Quality Assurance.
Термины: Качество и тестирование программного обеспечения. Quality Assurance.