Оракулы в тестировании что это
Для корректной работы сайта требуется разрешить использование куки сайта и куки третьей стороны
Мой доклад посвящен использованию оракулов в тестировании. Кто-то при прочтении слова "оракул" вспомнит о Дельфийском оракуле, кто-то - о персонаже фильма Матрица, которая пекла печенье и предсказывала судьбу. А в тестировании это понятие означает механизм, с помощью которого мы определяем результат выполнения теста. В своем докладе я расскажу о том, какие классификации оракулов существуют, как можно использовать эти классификации на практике - для обнаружения ошибок, при разработке тестов, при заведении убедительных отчетов об ошибках. Оракулы - это одно из фундаментальных понятий мира тестирования, его знание пригодится любому тестировщику. Надеюсь своим докладом я мотивирую вас на изучение оракулов и на использование их в повседневной работе.
Оракулы в тестировании что это
Что пишут в блогах
Онлайн-тренинги
Конференции
Heisenbug 2021 Moscow
Большая техническая конференция для тестировщиков
5-7 октября 2021, онлайн
Что пишут в блогах (EN)
- Against Critical Thinking
- Testing Like It Was 1980
- Boa Constrictor is doing Hacktoberfest 2021!
- Contributing to Open Source – Getting Started
- Full circle of Test Automation
- Five for Friday – October 1, 2021
- “The waves of Agile” listed on the AgileAlliance site
- Pursuing an ADHD Diagnosis after 15+ Years
- The Six Things Facilitator Can Do To Improve Ensembling Session
- No, Really, What Is Automation?
Разделы портала
Про инструменты
Автор: Катрина Клоки (Katrina Clokie)
Перевод: Ольга Алифанова
Эвристики и оракулы кажутся новичкам очень сложными концепциями. Они крайне наукообразно звучат и непохожи на ту реальность, с которой тестировщик ежедневно сталкивается. Однако на самом деле они крайне полезны в качестве инструментов критического мышления.
Что же такое эвристики и оракулы, и почему вам нужно уметь в них разбираться?
Эвристики
Предположим, я хочу съесть соленый огурчик. Огурчики хранятся в стеклянной банке. Последним, кто ел огурчики в моей семье, был мой муж. Он накрепко закрыл банку, и я не смогла ее открыть с первой попытки.
Что же мне делать?
Я убеждаюсь, что я поворачиваю крышку влево, и пробую еще раз. Затем я беру полотенце, чтобы лучше ухватиться за крышку, и снова пытаюсь ее повернуть. Наконец, окончательно взбесившись, я иду призывать мужа на помощь. Он успешно открывает зловредную банку.
Если я сталкиваюсь с банкой, которую я не могу открыть, я знаю, какие способы откручивания крышки я могу применить. Это мои эвристики открытия банки. Если мне нужно протестировать приложение, я знаю, что мне имеет смысл испробовать – и это мои эвристики тестирования.
Эвристики – это основанные на опыте техники решения проблем и обучения (см. ссылку).
У каждого отдельно взятого тестировщика есть свой собственный набор эвристик, ежедневно применяемых в тестировании. Они вырабатываются с опытом, и чтобы узнать о эвристиках больше, нужно узнавать, как мыслят другие люди, и быть способным описывать свой собственный мыслительный процесс.
Когда мое вдохновение для тестирования иссякает, у меня всегда есть под рукой эвристики, которые подскажут мне, что еще можно сделать. Я не полагаюсь исключительно на собственный мозг – я использую опыт других тестировщиков. Вот два примера:
Понимание, как мыслят другие тестировщики, помогает мне варьировать мой собственный подход к тестированию. Вместо того, чтобы искать одни и те же баги, я расширяю горизонты своего мышления. Это похоже на поговорку "Одна голова хорошо, а две лучше". Джеймс Линдси визуализирует эту разницу в своей статье "Вот почему различия так важны".
Эвристики также помогают мне описывать процесс моего тестирования. Раньше при ответе на вопрос, как я нашла баг, я только пожимала плечами – "Ну, я тыкала там и сям и нашла его". Эвристики поменяли мой подход к коммуникации, и как только я смогла внятно описать, что именно я делала и почему, как мой авторитет возрос.
Оракулы
Предположим, я обедаю с приятелем. Я вошла в ресторан в 12 часов дня четверга. Спустя час, пообедав, я покинула ресторан – в час дня пятницы. С моей точки зрения, прошел всего лишь час, но мир вокруг меня сдвинулся на целые сутки.
Как я узнаю о существовании такой проблемы?
Если я внезапно упустила целые сутки жизни, я могу узнать об этом при помощи множества способов. Это мои оракулы путешествий во времени. Аналогично я могу определить, что я нашла баг в ПО, при помощи множества способов – и это мои оракулы тестирования.
Оракулы – это принципы или механизмы, благодаря которым мы распознаем проблему (см. ссылку).
Оракулы тестирования, которые я сознательно использую, описаны Майклом Болтоном в статье "Тестируй без карты". Эта статья описывает мнемонику HICCUPS (история, имидж, сравнимые продукты, заявления, ожидания пользователей, продукт, цель, законы). Этот список уже расширен, и Майкл пишет о расширенной версии в своей статье FEW HICCUPS.
Когда я нахожу баг, я всегда размышляю, почему именно я решила, что нашла баг. Уж очень мне не хочется обосновывать баг в духе "я чувствую, что это баг" или "это баг, потому что я так сказала!" Оракулы помогают определить истинную причину ощущения, что где-то тут кроется проблема.
Знание оракулов означает, что я могу внятно объяснить разработчикам и бизнесу, почему пользователи приложения согласятся с тем, что эта конкретная ситуация – баг. Следовательно, я куда более эффективно отстаиваю свои баги, и в результате они куда чаще исправляются.
Если я не могу ассоциировать проблему с оракулом, это заставляет меня задуматься. Действительно ли я нашла проблему? Оракулы, как лакмусовая бумажка, позволяют мне заводить меньше "не-багов".
Почему оракул так называется?
В древние времена оракулом называли мудрого человека или старейшину, к которому шли за советом в случае необходимости принять важное решение. "Надо ли начинать войну на севере?" или "Должна ли дочь нашего правителя выйти замуж за Х для воцарения мира?", и так далее. Все эти вопросы касались критически важных проблем, и, как правило, слова оракула расценивались очень серьезно.
Это важная параллель, потому что в тестировании мы называем оракулом все, что может дать нам важную информацию, связанную с принятием решения или валидацией решений. Обычно решения связаны с качеством, риском или возможными проблемами.
Примеры
Тестовые оракулы обычно основаны на спецификациях и документации . Формальная спецификация используется в качестве входных данных для модели на основе конструкции и модель на основе тестирования будет примером указанного тестового оракула . Модель на основе оракул использует ту же модель для генерации и проверки поведения системы. Документация, которая не является полной спецификацией продукта, такой как руководство по использованию или установке, или записью характеристик производительности или минимальных требований к машине для программного обеспечения, обычно является производным тестовым оракулом.
Оракул согласованности сравнивает результаты выполнения одного теста с другим на предмет сходства. Это еще один пример производного тестового оракула.
Оракул для программы может быть второй программой, которая использует другой алгоритм для вычисления того же математического выражения, что и тестируемый продукт. Это пример псевдо-оракула, который является производным тестовым оракулом.
Во время поиска Google у нас нет полного оракула, чтобы проверить правильность количества возвращенных результатов. Мы можем определить метаморфическое отношение таким образом, чтобы последующий суженный поиск давал меньше результатов. Это пример частичного оракула, который представляет собой гибрид указанного тестового оракула и производного тестового оракула.
Статистический оракул использует вероятностные характеристики, например, с анализом изображений, где определен диапазон достоверности и неопределенности для того, чтобы тестовый оракул произнес совпадение или иначе. Это был бы пример количественного подхода в человеческом тестовом оракуле.
Эвристический оракул предоставляет репрезентативные или приблизительные результаты по классу тестовых входных данных. Это был бы пример качественного подхода в человеческом тестовом оракуле.
Что может быть оракулом тестирования?
Ответ на этот вопрос прост, но довольно глубок: оракулом может быть практически все содержащее важную информацию о продукте. Если вы хотите узнать больше об оракуле, рекомендую серию статей Майкла Болтона "Оракулы сверху донизу". Резюмируя информацию из статей Майкла, оракулами могут быть:
Ментальная модель или ощущение (Опыт) – это может показаться слегка абстрактным, но если вы хоть раз тестировали ПО и находили в нем проблемы, то знаете, что начинается это с ощущений. Что-то говорит вам – тут что-то не так, это нужно изучить. В любом случае этого недостаточно для создания баг-репорта, поэтому мы будем исследовать вопрос подробнее.
Артефакты (Справка) – любой вид знания, зафиксированного письменно, или документ, дизайн, черновик, любая форма коммуникации, которая несет знания. Все это можно использовать как оракул.
Обсуждения с важными носителями знания (Конференция) – один из самых важных и иногда недооцениваемых источников знания о ПО или проекте – это задействованные в нем люди, конечные пользователи, коллеги, руководители и все участники процесса. В ситуациях ограниченной или отсутствующей документации я неоднократно прикрывал себе зад только потому, что активно добивался ясности и информации от важных участников разработки.
Соответствие известным продуктам (Умозаключение) – применение знаний о сравнимых продуктах к тестируемому, и поиск:
- Несоответствий: общественным стандартам для приложений, которые мы тестируем. Пример: у всех мобильных калькуляторов есть определенная опция, но у нас она реализована слегка иначе.
- Соответствий: проблемам, с которыми мы сталкивались в том же классе приложений. Пример: каждый раз при тестировании загрузки файлов я ищу проблемы с валидацией ограничения размера файлов, потому что мой предыдущий опыт (один оракул) с другими схожими приложениями (другой оракул) гласит, что там часто кроются баги.
Почему оракулы – это так важно?
Оракулы – важная концепция, которую часто упускают во множестве материалов. Это плохо, потому что оракулы – краеугольный камень для понимания тестирования. Профессиональный тестировщик живет на грани неопределенности – меняющихся дедлайнов, меняющихся требований, сомнительного качества. Оракулы дают нам кусочки информации, на которые можно опираться как на истину.
Более того, они дают нам не только способ валидировать сомнительное поведение продукта – они могут также научить нас конструировать эксперименты, которые помогут выявить это сомнительное поведение.
К сожалению, несмотря на то, что каждый тестировщик использует оракулы, сам термин "оракул" и связанная с ним теория не особо известны среди тестировщиков, и это плохо.
Категории
Обзор исследовательской литературы, охватывающий период с 1978 по 2012 год, выявил несколько потенциальных категорий тестовых оракулов.
Указано
Эти оракулы обычно связаны с формализованными подходами к моделированию программного обеспечения и построению программного кода. Они связаны с формальной спецификацией , дизайном на основе модели, который может использоваться для генерации тестовых оракулов, спецификацией перехода между состояниями, для которой могут быть получены оракулы, чтобы помочь основанному на модели тестированию и проверке соответствия протокола , и дизайну по контракту, для которого эквивалентный тестовый оракул это утверждение .
Указанные тестовые оракулы имеют ряд проблем. Формальная спецификация основана на абстракции, которая, в свою очередь, может иметь элемент неточности, поскольку все модели не могут уловить все поведение.
Полученный
Производный тестовый оракул различает правильное и неправильное поведение, используя информацию, полученную из артефактов системы. Они могут включать документацию, результаты работы системы и характеристики версий тестируемой системы. Наборы регрессионных тестов (или отчеты) являются примером производного тестового оракула - они построены на предположении, что результат предыдущей версии системы может быть использован в качестве вспомогательного средства (оракула) для будущей версии системы. Ранее измеренные характеристики производительности могут быть использованы в качестве оракула для будущих версий системы, например, чтобы задать вопрос о наблюдаемом потенциальном ухудшении производительности. Текстовая документация из предыдущих версий системы может использоваться в качестве основы для определения ожиданий в будущих версиях системы.
Псевдо-оракул попадает в категорию производного тестового оракула. Псевдо-оракул, по определению Вейукера, представляет собой отдельно написанную программу, которая может принимать те же входные данные, что и тестируемая программа или система, так что их выходные данные можно сравнивать, чтобы понять, есть ли проблема для исследования.
Частичный оракул - это гибрид указанного тестового оракула и производного тестового оракула. Он определяет важные (но не полные) свойства тестируемой системы. Например, при метаморфическом тестировании такие свойства, называемые метаморфическими отношениями, используются при нескольких запусках системы.
Скрытый
Неявный тестовый оракул полагается на подразумеваемую информацию и предположения. Например, может быть какой-то подразумеваемый вывод из сбоя программы, то есть нежелательное поведение - оракул, чтобы определить, что может быть проблема. Существует несколько способов поиска и тестирования нежелательного поведения, независимо от того, называют ли это отрицательным тестированием, где есть специализированные подмножества, такие как фаззинг .
У неявных тестовых оракулов есть ограничения, поскольку они полагаются на подразумеваемые выводы и предположения. Например, сбой программы или процесса может не быть приоритетной проблемой, если система является отказоустойчивой и поэтому работает в форме самовосстановления / самоуправления . Неявные тестовые оракулы могут быть подвержены ложным срабатываниям из-за зависимостей от среды.
Человек
Если указанные, производные или неявные тестовые оракулы не могут быть использованы, то для определения тестовых оракулов требуется участие человека. Их можно рассматривать как количественный и качественный подходы. Количественный подход направлен на поиск нужного количества информации, которую нужно собрать о тестируемой системе (например, результатов тестирования), чтобы заинтересованная сторона могла принять решение о соответствии или выпуске программного обеспечения. Качественный подход направлен на определение репрезентативности и пригодности входных тестовых данных и контекста выходных данных тестируемой системы. Примером может служить использование реалистичных и репрезентативных данных испытаний и понимание результатов (если они реалистичны). При этом можно руководствоваться эвристическими подходами, такими как интуиция, эмпирические правила, вспомогательные контрольные списки и опыт, чтобы помочь адаптировать конкретную комбинацию, выбранную для тестируемой программы / системы.
Где найти оракулы в живой природе?
Как я говорил ранее, оракулы – концепция, которую вы используете в тестировании, нравится вам это или нет. Вы можете не знать, что вы ими пользуетесь, или не называть это оракулом.
Примеры использования оракулов:
- Тест-кейсы и тест-сценарии: я небольшой их фанат, но люди ими пользуются. Если вы знакомы с концепцией создания тест-кейса, то знаете, что там есть раздел "Ожидаемый результат". Это классический пример оракула, так как он сообщает всем о правильном поведении приложения. Аналогичное применимо к ожиданиям в баг-репортах и автоматизированных проверках.
- Документация: документы и спецификации используются как оракулы. Это неплохо, но проблема в том, что они создаются и поддерживаются людьми и страдают от тех же проблем, что и код: они теряют актуальность, в них есть ошибки, они расплывчато сформулированы, чересчур техничны, чересчур поверхностны, слишком детализированны… Проблемы возникают, когда мы, как тестировщики, начинаем рассматривать документацию как единственный ценный источник знаний, в то время как в первую очередь нами должны руководить эксперименты и исследования.
Подробно об оракулах
Я не первый, кто пишет об оракулах, и я не сообщаю ничего нового. Я просто свожу воедино все то, что, по моему мнению, срабатывает для меня, и передаю эту информацию вам.
Если вас интересует концепция оракулов тестирования, то вот пара ресурсов, которые могут вам пригодиться:
Вот о каких оракулах я узнал из этих статей, и применяю их ежедневно:
- FEWHICCUPPS – незаменимый оракул, если вы пользуетесь им для валидации, правильное ли поведение вы наблюдаете. Это именно то, для чего он был предназначен – для использования в качестве чек-листа. Каждый раз, сталкиваясь с неуверенностью, баг ли это, вы можете прибегнуть к FEW HICCUPPS и поразмышлять, можно ли валидировать это поведение стандартом, понимаете ли вы цель, соответствует ли она продукту, заявлениям о продукте, истории продукта, и так далее. Этот тип мышления, управляемого через вопросы – причина моей убежденности, что оракулы могут работать в обратном направлении, то есть не только как внешняя сущность для валидации истины о продукте, но и как провокация экспериментов, помогающих вскрыть несоответствия между ожиданиями и реальностью.
- Оракул регресса – если вы рассматриваете регрессионное тестирование как возможный оракул, то, насколько я понимаю, вы освобождаетесь от большей части этой ноши – ожидания, что это неотъемлемая и всемогущая часть эффективного тестирования. Многие люди убеждены, что регрессионное тестирование означает, что нужно каждый раз прогонять набор тестов, или все ваши тесты, или все автоматические проверки. Я могу написать целую статью о всем том, что неверно в этом убеждении, но я ценю ваше время, поэтому просто поверьте мне на слово. Вместо этого попробуйте относиться к регрессу как к виду оракула. Как оракул и, соответственно, эвристика, он имеет ограниченную эффективность.
- Ограничения как оракул – я убежден, что это самый очевидный, простой в использовании, и в то же самое время наиболее упускаемый оракул. При любом тестировании у вас есть список ограничений – максимальная длина строки, количество разрешенных спецсимволов, размер файла – и все это подсказки для вас. Как хороший тестировщик, вы в первую очередь должны думать, что будет, если вы нарушите правила? Что будет, если не вводить запрашиваемое количество символов? Что произойдет? Появится ли ошибка, будет ли исключение, предусмотрел ли разработчик подобный сценарий? Если вы один из тех, кто говорит "Без понятия, с чего начинать тестирования", то вот неплохой план действий – найдите все ограничения продукта, составьте список, постарайтесь нарушить их как минимум тремя различными способами, зафиксируйте результаты, и пусть собранная информация станет толчком для более глубокого тестирования. Это хороший старт тестирования, и он прямо у вас перед глазами.
- Самоверифицируемые данные как оракул – я активно пользуюсь этим оракулом в автоматических проверках, в основном для имен тестов. Я также пытаюсь приучить к этому разработчиков. Здравый смысл гласит, как минимум мне, что имя автоматической проверки должно сообщать о проверяемом результате. Это также хороший способ убедиться, что ваши проверки фокусируются на одном действии и его результате, а не распыляются на разные возможности. Пример: если моя проверка называется testingValidAdminUserFlow и падает, я без понятия, где она упала и что с ней не так. Это значит, что мне придется изучать вопрос, и это увеличивает временные затраты. С другой стороны, если вы создаете небольшие, однозначные проверки, использующие самоверифицируемые данные как оракул, вы легко определите, в чем проблема. К примеру, если проверка называется loginAsAdmin200Test и падает, вы будете точно знать, что авторизация под администратором не вернула код ответа 200.
СОДЕРЖАНИЕ
Оракулы – это эвристики
В качестве заключения: нравится вам это или нет, вы используете оракулы, и верьте мне, это хорошо. Чем больше вы о них знаете, тем больше вы знаете в принципе.
К чему я это веду – относитесь к оракулам, как к эвристикам, пожалуйста, не забывайте об их ненадежности, и не цепляйтесь за единственный оракул как источник незыблемых истин. Вместо этого владейте множеством дающих информацию оракулов, и смотрите, что из этой информации даст нам уверенность в принятии решений или в приходе к выводам – конечно, обдумав эти решения при помощи своего аналитического, критически мыслящего ума.
Тестовый оракул - Test oracle
В вычислительный , программной инженерии и тестирование программного обеспечения , тест оракул (или просто оракулом ) представляет собой механизм для определения того, успешно или неуспешно прошел тест. Использование оракулов включает сравнение выходных данных тестируемой системы для заданных входных данных тестового примера с выходными данными, которые, по определению оракула, должен иметь продукт. Термин «тестовый оракул» впервые был введен в статье Уильяма Э. Хаудена. Дополнительная работа над различными видами оракулов была исследована Элейн Вейкер .
Оракулы часто работают отдельно от тестируемой системы. Однако постусловия метода являются частью тестируемой системы как автоматизированные оракулы при проектировании с помощью контрактных моделей. Определение правильного вывода для заданного входа (и набора состояний программы или системы) известно как проблема оракула или проблема тестового оракула, что намного сложнее, чем кажется, и включает работу с проблемами, связанными с управляемостью и наблюдаемостью.
Читайте также: