В своей книге "Методы тестирования программного обеспечения" Борис Бейзер описывает парадокс пестицидов. В контексте тестирования программного обеспечения - независимо от того, какой метод тестирования вы выберете, вы все равно пропустите более незаметных “вредителей”, то есть баги.
Объяснение Бейзера заключается в том, что вредители больше не будут находиться в тех местах, где был применен пестицид; они будут только там, где его не применяли. Аналогия с тестированием заключается в том, что со временем все меньше и меньше ошибок будут находиться в тех частях кода, которые были тщательно протестированы, а ошибки, которые обнаружат пользователи, будут в областях, которые были протестированы менее тщательно.
Как же с этим справиться? Расширить охват тестирования, добавив в свой процесс фаззинг.
Что такое фаззинг?
Грубо говоря, фаззинг - это тестирование без знания того, каким должен быть конкретный результат. При фаззинге вы не обязательно знаете, что должно произойти, но у вас есть хорошее представление о том, что не должно происходить, например, ошибки 404, сбои сервера или приложения.
Как тестировщик, вы можете использовать фаззинг, чтобы помочь выявить такого рода ошибки при тестировании виджетов текстовых полей в графическом интерфейсе или на веб-странице. Тестировщики берут блоки потенциально проблемного текста и вводят их в текстовые поля, чтобы посмотреть, не произойдет ли каких-либо сбоев. Иногда блоки представляют собой произвольно сгенерированные символы, что добавляет тестированию элемент случайности. Однако зачем останавливаться на одних текстовых полях?
Современные веб-сайты представляют собой плотно взаимосвязанные многосерверные приложения от нескольких поставщиков, которые подключены к серверам вне сети, которые не контролируются ни приложениями, ни командой. Такая ситуация затрудняет как выявление, так и контроль всех возможных путей через вашу систему.
Даже если бы можно было определить все возможные пути, у большинства организаций не было бы времени на тестирование и оценку результатов всех этих сценариев, независимо от того, применяют ли они автоматизацию для помощи в этом тестировании. Фаззинг, основанный на случайности на уровне пользовательского интерфейса, в частности, с помощью кликов в браузере, может дать представление о дополнительных путях, особенно о не очевидных.
Создайте собственный случайный кликер
Случайный кликер - это программа, которая нажимает на случайные доступные для клика элементы (кнопки, гиперссылки и т.д.), применяя различные методы для выявления необычного поведения системы. Таким образом, вы применяете фаззинг при кликах браузера.
Приведенное выше описание может показаться расплывчатым или сложным, но это не так. Вы можете сделать кликер самостоятельно, без особых усилий. Для типичного веб-сайта основными шагами фаззинга браузера являются:
Перейдите на начальную страницу.
Случайным образом щелкните по тегу <a>.
Произошло ли что-то необычное?
Если да, сохраните эту информацию, а затем перейдите к шагу 1.
Если нет, сохраните информацию о том, где вы находитесь в данный момент, затем перейдите к шагу 2.
Из этого базового алгоритма вы можете видеть, что для создания элементарной версии кликера не требуется много кода или усилий.
Возможно, вы даже найдете места, где можно изменить алгоритм и сделать его еще более полезным для ваших конкретных нужд. В этом и есть привлекательность подобного инструмента; его относительно дешево создавать и запускать, и он может выявить проблемы, которые, возможно, не были замечены при существующем тестировании.
Что следует учитывать перед использованием рандомизации
Одной из причин, по которой тестировщики неохотно применяют рандомизацию, является беспокойство по поводу воспроизводимости. Ваша автоматизация не имеет большой ценности, если вы не можете воспроизвести ситуацию, которая вызвала неожиданное поведение. Без воспроизводимости сложнее отладить потенциальную проблему и оценить, устранена ли проблема.
Чтобы повысить воспроизводимость, случайный кликер оставляет след из хлебных крошек. То есть он регистрирует данные, которые, вероятно, будут полезны тому, кто пытается определить, следует ли рассматривать что-то необычное как проблему. Эти логи также интересны тем, кто занимается отладкой проблемы, или тем, кто проверяет, устранена ли проблема.
След из хлебных крошек может включать:
Логи каждой посещенной страницы
Скриншоты каждой посещенной страницы или каждого необычного состояния
Какая эвристика привела к тому, что о состоянии сообщили как о необычном
Это помощь, а не тестирование
Это не традиционная автоматизация, основанная на тест-кейсах. Традиционная автоматизация обычно фокусируется на выполнении компьютером тест-кейсов, которые чаще всего выполняют люди. Желаемое поведение такой автоматизации заключается в выдаче результатов pass/fail или green/red.
Вместо этого описанный здесь тип фаззинга браузера помогает каждому действующему лицу работать в полную силу: компьютеры выполняют тяжелую, повторяющуюся работу, в то время как люди выполняют когнитивную работу, решая, является ли определенная странность проблемой.
Более конкретно, случайный кликер выдает две “стопки” результатов: одну стопку кликов, в которых не было обнаружено никаких проблем, и меньшую стопку, состоящую из кликов, при которых произошло что-то необычное. Затем тестировщик проверяет результаты, фокусируясь на стопке необычных кликов, решая, какие результаты указывают на проблему, а какие являются ложноположительными.
Если у вас большое количество ложноположительных результатов, вам следует сообщить об этом разработчикам кликера, чтобы они могли скорректировать нарушающую эвристику. К сожалению, поскольку здесь мы имеем дело с эвристикой, может оказаться невозможным внести коррективы, которые уменьшат количество ложноположительных результатов, не вызывая при этом ложноотрицательных результатов — то есть результатов, указывающих на что-то не странное, что на самом деле должно быть помечено как странное.
В подобных случаях удаление проблемной эвристики может быть лучшим вариантом, особенно если усилия, необходимые для расследования ложных срабатываний, перевешивают ценность, получаемую от поиска реальных проблем.
Не пугайтесь
Добавление рандомизации к вашему тестированию может показаться сложной задачей, но это не обязательно так. Если ваша компания и ваши пользователи довольны качеством вашего продукта, возможно, сейчас рандомизация не имеет достаточной ценности.
Аналогично, если ваша команда изо всех сил пытается решить проблемы, выявленные вашим текущим подходом к тестированию, у вас может не хватить пропускной способности для обработки рандомизации.
Однако, если нанесение “пестицида” на дополнительные участки собственности может оказаться полезным для вас, рассмотрите возможность использования рандомизации, чтобы помочь выявить ошибки в этих областях. Просто имейте в виду приведенную выше информацию, чтобы, при обнаружении необычной ситуации, у вас были данные, необходимые для того, чтобы классифицировать ее как проблему или отсутствие проблемы.
