Что не может быть использовано как тест oracle источник ожидаемого результата
Обновлено: 04.07.2024
В вычислительный , программной инженерии и тестирование программного обеспечения , тест оракул (или просто оракулом ) представляет собой механизм для определения того, успешно или неуспешно прошел тест. Использование оракулов включает сравнение выходных данных тестируемой системы для заданных входных данных тестового примера с выходными данными, которые, по определению оракула, должен иметь продукт. Термин «тестовый оракул» впервые был введен в статье Уильяма Э. Хаудена. Дополнительная работа над различными видами оракулов была исследована Элейн Вейкер .
Оракулы часто работают отдельно от тестируемой системы. Однако постусловия метода являются частью тестируемой системы как автоматизированные оракулы при проектировании с помощью контрактных моделей. Определение правильного вывода для заданного входа (и набора состояний программы или системы) известно как проблема оракула или проблема тестового оракула, что намного сложнее, чем кажется, и включает работу с проблемами, связанными с управляемостью и наблюдаемостью.
СОДЕРЖАНИЕ
Категории
Обзор исследовательской литературы, охватывающий период с 1978 по 2012 год, выявил несколько потенциальных категорий тестовых оракулов.
Указано
Эти оракулы обычно связаны с формализованными подходами к моделированию программного обеспечения и построению программного кода. Они связаны с формальной спецификацией , дизайном на основе модели, который может использоваться для генерации тестовых оракулов, спецификацией перехода между состояниями, для которой могут быть получены оракулы, чтобы помочь основанному на модели тестированию и проверке соответствия протокола , и дизайну по контракту, для которого эквивалентный тестовый оракул это утверждение .
Указанные тестовые оракулы имеют ряд проблем. Формальная спецификация основана на абстракции, которая, в свою очередь, может иметь элемент неточности, поскольку все модели не могут уловить все поведение.
Полученный
Производный тестовый оракул различает правильное и неправильное поведение, используя информацию, полученную из артефактов системы. Они могут включать документацию, результаты работы системы и характеристики версий тестируемой системы. Наборы регрессионных тестов (или отчеты) являются примером производного тестового оракула - они построены на предположении, что результат предыдущей версии системы может быть использован в качестве вспомогательного средства (оракула) для будущей версии системы. Ранее измеренные характеристики производительности могут быть использованы в качестве оракула для будущих версий системы, например, чтобы задать вопрос о наблюдаемом потенциальном ухудшении производительности. Текстовая документация из предыдущих версий системы может использоваться в качестве основы для определения ожиданий в будущих версиях системы.
Псевдо-оракул попадает в категорию производного тестового оракула. Псевдо-оракул, по определению Вейукера, представляет собой отдельно написанную программу, которая может принимать те же входные данные, что и тестируемая программа или система, так что их выходные данные можно сравнивать, чтобы понять, есть ли проблема для исследования.
Частичный оракул - это гибрид указанного тестового оракула и производного тестового оракула. Он определяет важные (но не полные) свойства тестируемой системы. Например, при метаморфическом тестировании такие свойства, называемые метаморфическими отношениями, используются при нескольких запусках системы.
Скрытый
Неявный тестовый оракул полагается на подразумеваемую информацию и предположения. Например, может быть какой-то подразумеваемый вывод из сбоя программы, то есть нежелательное поведение - оракул, чтобы определить, что может быть проблема. Существует несколько способов поиска и тестирования нежелательного поведения, независимо от того, называют ли это отрицательным тестированием, где есть специализированные подмножества, такие как фаззинг .
У неявных тестовых оракулов есть ограничения, поскольку они полагаются на подразумеваемые выводы и предположения. Например, сбой программы или процесса может не быть приоритетной проблемой, если система является отказоустойчивой и поэтому работает в форме самовосстановления / самоуправления . Неявные тестовые оракулы могут быть подвержены ложным срабатываниям из-за зависимостей от среды.
Человек
Если указанные, производные или неявные тестовые оракулы не могут быть использованы, то для определения тестовых оракулов требуется участие человека. Их можно рассматривать как количественный и качественный подходы. Количественный подход направлен на поиск нужного количества информации, которую нужно собрать о тестируемой системе (например, результатов тестирования), чтобы заинтересованная сторона могла принять решение о соответствии или выпуске программного обеспечения. Качественный подход направлен на определение репрезентативности и пригодности входных тестовых данных и контекста выходных данных тестируемой системы. Примером может служить использование реалистичных и репрезентативных данных испытаний и понимание результатов (если они реалистичны). При этом можно руководствоваться эвристическими подходами, такими как интуиция, эмпирические правила, вспомогательные контрольные списки и опыт, чтобы помочь адаптировать конкретную комбинацию, выбранную для тестируемой программы / системы.
Примеры
Тестовые оракулы обычно основаны на спецификациях и документации . Формальная спецификация используется в качестве входных данных для модели на основе конструкции и модель на основе тестирования будет примером указанного тестового оракула . Модель на основе оракул использует ту же модель для генерации и проверки поведения системы. Документация, которая не является полной спецификацией продукта, такой как руководство по использованию или установке, или записью характеристик производительности или минимальных требований к машине для программного обеспечения, обычно является производным тестовым оракулом.
Оракул согласованности сравнивает результаты выполнения одного теста с другим на предмет сходства. Это еще один пример производного тестового оракула.
Оракул для программы может быть второй программой, которая использует другой алгоритм для вычисления того же математического выражения, что и тестируемый продукт. Это пример псевдо-оракула, который является производным тестовым оракулом.
Во время поиска Google у нас нет полного оракула, чтобы проверить правильность количества возвращенных результатов. Мы можем определить метаморфическое отношение таким образом, чтобы последующий суженный поиск давал меньше результатов. Это пример частичного оракула, который представляет собой гибрид указанного тестового оракула и производного тестового оракула.
Статистический оракул использует вероятностные характеристики, например, с анализом изображений, где определен диапазон достоверности и неопределенности для того, чтобы тестовый оракул произнес совпадение или иначе. Это был бы пример количественного подхода в человеческом тестовом оракуле.
Эвристический оракул предоставляет репрезентативные или приблизительные результаты по классу тестовых входных данных. Это был бы пример качественного подхода в человеческом тестовом оракуле.
При сдаче сертификации нужны две вещи: собственно, знания предметной области и второе — умение сдавать конкретную сертификацию. ISTQB — не исключение. Тут мало знать тестирование и SDLC — нужно уметь думать, как те, кто составлял эти тесты.
Тесты не так просты, как кажется на первый взгляд: тут обычный вопрос, не вызывающий бурю возмущений, — скорее исключение. Чаще или два правильных ответа сразу, или все не подходят. Есть еще одна категория «Мы решили спросить то, о чем не говорили вообще нигде» — чтобы вы не расслаблялись :)
Но обо всём по порядку.
На что обращать внимание при подготовке
Чтобы подготовиться к тестированию нужно следующее:
— выучить Cиллабус (78 стр);
— прочитать, понять (и простить) книгу Foundations of Software Testing ISTQB Certification (207 стр). Даже для меня, гуманитария, в книге много водянисто-водяной воды;
— прочитать (частично выучить) словарь к ISTQB;
— прорешать «500 Sample questions». Sample, к сожалению, не Simple;
— прочитать дополнительные ресурсы, решить прочие тесты, установить приложение на телефон (почти все дублируют «500 Sample questions», так что малоинформативны, но всё же);
— и так как побороть весь этот scope и победить всех и вся сложно в одиночку, то я бы очень рекомендовала пойти на курсы. Там люди, уже прожившие этот ужас опыт, подскажут и пояснят теоретические и практические моменты, а также собственным примером покажут, что сдать эту сертификацию всё же реально и не нужно всё бросать (даже если временами хочется).
В процессе подготовки накапливается свой собственный словарь — словарь синонимов. Те, кто сдавал, понимают, о чем я. Иногда создается впечатление, что все эти термины (полностью дублирующие друг друга) вводятся специально, чтобы запутать. К примеру, всем понятное Black-box тестирование (или техники тест дизайна) имеет такие синонимы, как Specification-based, Input/output driven, Behavioral. А White-box — то же самое, что Structural, Structure-based, Clear-box и Glass-box. Это отнимает много сил — запоминать разные названия одного и того же явления.
Другая история — это очень похожие по написанию, но совершенно разные по смыслу понятия. Например, Maintenance Testing и Maintainability testing — совсем разные вещи. При ограничении во времени такие слова вообще не читаются по буквам, а воспринимаются целиком, при этом спутать их становится проще простого. Или другой пример: Decision condition testing и Decision table testing — примеры совершенно разных подходов, где первый просматривает код на предмет всех возможных исходов условий, а второй — Black-box техника построения таблиц конкретных решений на основе разных (многочисленных) условий. В общем, тренировка внимания включена в курс молодого бойца.
Какие новые знания может дать сертификация
Из действительно полезного и интересного в процессе подготовки:
— структурирование информации (теории);
— подкрепление теории практическими задачами и заданиями;
— проработка всех аспектов тестирования — как в работе с самим ПО, так и аспекты работы менеджера, учет рисков, взаимодействие в команде, модели работы в целом;
— виды статического и динамического тестирования, виды Black-box и White-box техник тестирования;
— фундаментальный процесс тестирования в подробностях и с примерами;
— задачи (обязанности) тест лида и тестировщика;
— тест план — что, как, зачем;
— риск-менеджмент в разрезе тестирования.
При подготовке были обнаружены действительно полезные и интересные фразы (из «Foundations of software testing. ISTQB certification» и «Standard glossary of terms used in software testing»):
— «Мы должны понимать, что пользователь понимает под качеством и каковы его ожидания».
— «У нас есть выбор: протестировать всё, не тестировать ничего, протестировать часть функциональности (мы принимаем во внимание оценку рисков, чтобы определить, сколько тестирования потребуется)».
— «Тестирование — процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов».
— «Один из семи принципов „Заблуждение об отсутствии ошибок“ гласит: обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям».
— «Исчерпывающее тестирование недостижимо».
— «Основной процесс тестирования состоит из следующих направлений деятельности: планирование и управление; анализ и проектирование; внедрение и реализация; оценка критериев выхода и создание отчетов; действия по завершению тестов».
— «Тест „oracle“ — это источник ожидаемого результата (не код) для сравнения с фактическим результатом тестируемого функционала».
— «Необходимые навыки тестировщика: приложение или бизнес домен, технология, тестирование».
— «Риск — это фактор, который может привести к негативным последствиям в будущем, обычно выражается через вероятность и влияние».
— «Риск проекта — это риск, относящийся к управлению и контролю проектом или тестированием в проекте. Например: нехватка персонала, жесткие сроки окончания, изменения требований и т.д.».
— «Риск продукта — это вероятность, что система или программное обеспечение может не оправдать некоторых рациональных ожиданий заказчика, пользователя или стейкхолдера».
И после того, как выходишь с экзамена, получив из принтера лист А4 с надписью «pass», — понимаешь, что всё это было не зря.
А вы знаете разницу между error, mistake, bug, defect, fault, failure? Затрудняетесь? Тогда ISTQB ждет вас ;) И да пребудет с вами Сила!
От редакции: также советуем прочитать статью «Как я сдавал ISTQB Advanced Level».
Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.
Вопрос 1: Множественный ответ
Какими свойствами должна обладать транзакция?
* Атомарность
* Согласованность
* Изолированность
* Долговечность
Вопрос 2: Множественный выбор
Какие операции в Oracle приводят к принудительной фиксации транзакции?
* любые
* никакие
* DDL
* DML
Вопрос 3: Множественный выбор
Какой результат дает отсутствие раздела WHERE в команде DELETE
* команда удаляет все записи из таблицы
* команда не может выполниться из-за синтаксической ошибки
* команда предлагает пользователю указать критерии удаления
* команда не может выполниться, т.к. нет записей для удаления
Вопрос 4: Множественный выбор
Какой из приведенных способов остановки экземпляра базы данных будет выполняться дольше всего?
* SHUTDOWN
* SHUTDOWN IMMEDIATE
* SHUTDOWN ABORT
* SHUTDOWN TRANSACTIONAL
Вопрос 5: Множественный выбор
Предположим, что Вам нужно удалить таблицу SOME_TABLE, имеющую несколько индексов, относящихся к ней. Что из перечисленного удалит все индексы вместе с таблицей?
* ALTER TABLE SOME_TABLE DROP PRIMARY KEY CASCADE
* DROP TABLE SOME_TABLE
* ALTER TABLE SOME_TABLE DROP CONSTRAINT
* DROP INDEX FROM SOME_TABLE
Вопрос 6: Множественный выбор
Оператор IN осуществляет
* Логическую конъюнкцию выражений
* Проверку выражения на NULL
* Проверку наличия элемента в списке
* Логическую дизъюнкцию
Вопрос 7: Множественный ответ
С помощью каких операторов в выборке можно делать фильтрацию дубликатов?
* order by
* join
* distinct
* group by
* delete
Вопрос 8: Множественный выбор
Что такое “транзакция”?
* Группа выполняемых подряд операций, связанных с изменением данных
* Одна операция над данными
* Группа последовательных операций, которая представляет собой логическую единицу работы с данными
* Ничего из вышеперечисленного
Вопрос 9: Множественный выбор
Что такое экземпляр базы данных Оракл?
* Набор всех файлов данных, журналов повторного выполнения, контрольных файлов
* Бинарные файлы и библиотеки оракла
* SGA и фоновые процессы
* все вышеперечисленное
Вопрос 10: Множественный выбор
Из каких файлов состоит база данных Оракл?
* Файлы данных, управляющие файлы
* Файлы данных, сегменты отката, журналы повторного выполнения
* Файлы данных, управляющие файлы, журналы повторного управления
* Файлы данных, индексные файлы, управляющие файлы, сегменты отката
Вопрос 11: Множественный выбор
В чем заключается разница между ограничениями Primary Key и Unique
* ограничение UNIQUE, в отличие от Primary KEY , может быть применено только для одного поля
* ограничение Primary KEY, в отличие от UNIQUE, может быть применено только для одного поля
* данные понятия совершенно идентичны
* первичный ключ в таблице может быть только один, а ограничений UNIQUE более одного
Вопрос 12: Множественный выбор
Владелец Stud05 выполняет команду: Create Table student as select * From Stud.student. Каков результат выполнения
* таблица с именем STUDENT создается в схеме STUD05 с теми же данными, что и в таблице STUDENT, принадлежащей STUD
* таблица с именем STUD создается в схеме STUDENT с теми же данными, что и в таблице STUD05,принадлежащей STUDENT
* таблица с именем STUDENT создается в схеме STUD с теми же данными, что и в таблице STUDENT,принадлежащей STUD05
* таблица с именем STUD05 создается в схеме STUDENT с теми же данными, что и в таблице STUDENT,принадлежащей STUD
Вопрос 13: Множественный выбор
Какую команду необходимо использовать для возобновления работы деактивириванного первичного ключа (primary key constraint)?
Какими свойствами должна обладать транзакция?
Долговечность
Какие операции в Oracle приводят к принудительной фиксации транзакции?
любые
Какой результат дает отсутствие раздела WHERE в команде DELETE
команда не может выполниться из-за синтаксической ошибки
Какой из приведенных способов остановки экземпляра базы данных будет выполняться дольше всего?
SHUTDOWN ABORT
Предположим, что Вам нужно удалить таблицу SOME_TABLE, имеющую несколько индексов, относящихся к ней.
Что из перечисленного удалит все индексы вместе с таблицей?
DROP INDEX FROM SOME_TABLE
Оператор IN осуществляет
Проверку выражения на NULL
С помощью каких операторов в выборке можно делать фильтрацию дубликатов?
delete
Что такое “транзакция”?
Ничего из вышеперечисленного
Что такое экземпляр базы данных Оракл?
Бинарные файлы и библиотеки оракла
В чем заключается разница между ограничениями Primary Key и Unique
данные понятия совершенно идентичны
Владелец Stud05 выполняет команду: Create Table student as select * From Stud.student. Каков результат выполнения
таблица с именем STUDENT создается в схеме STUD с теми же данными, что и в таблице STUDENT,принадлежащей STUD05
Какой из приведенных способов остановки экземпляра базы данных будет выполняться дольше всего?
Какой из приведенных способов остановки экземпляра базы данных будет выполняться дольше всего?
Основная цель большинства разработчиков обычно заключается в достижении 100% покрытия кода, если они вообще пишут какие-либо модульные тесты. В этой статье с инструкциями по разработке тестов я собираюсь показать вам, как использовать основанные на спецификациях методы разработки тестов, чтобы покрыть больше требований в рамках ваших модульных тестов.
Я видел много юнит-тестов , и те, которые были разработаны программистами, большинство не покрывали требования полностью. Подумайте на секунду, как вы пишете свои тесты. Вы извлекаете тестовые данные из документов спецификации приложения? Если нет, то вы должны быть! В конце этой статьи вы узнаете, как обеспечить подход к разработке контрольных примеров на основе спецификаций с помощью двух конкретных методов: разделения по эквивалентности и анализа граничных значений .
Нестандартные тесты
Я написал простой класс, чтобы объяснить идеи статьи.
Основная цель этой статической утилиты — вернуть стоимость подписки на один месяц для транспортных линий Софии. В рамках утилиты клиент должен указать свой возраст. В результате цены варьируются в зависимости от возраста. 0 <Возраст <= 5 — Цена = 0 лв 5 <Возраст <= 18 — Цена = 20 лв 18 <Возраст <65 — Цена = 40 лв 65 <= Возраст <= 122 — Цена = 5 лв. По моему мнению, большинство разработчики, как правило, пишут тесты на основе своего кода. Сначала они читают спецификацию, пишут свой код, а затем разрабатывают свои тесты на основе самого кода. Они направлены на достижение покрытия коды 100% , а не 100% спецификация покрытия . Когда я думаю об этой тенденции, я спрашиваю себя: «Зачем писать тесты, которые не пройдут, если они основаны на коде, который уже может содержать ошибки?» Для достижения 100% покрытия кода требуется всего семь тестов. В качестве примеров тестов я собираюсь использовать NUnit из-за его удобных атрибутов (вы можете посмотреть обзор инструмента производительности Telerik’s Devcraft от Джона, если хотите больше поиграть с NUnit).
Случайные? В самом деле? Вы можете быть шокированы, но многие разработчики склонны использовать эту технику в своих тестах. В первый раз, когда я увидел что-то похожее на код выше, я нанес себе на лицо не менее 5 минут Использование случайных данных в ваших тестах приводит к ненадежным результатам теста. С некоторыми из сгенерированных значений тест может быть зеленым, а с другими — красным.
Тестовые примеры на основе кода
[Случайно (мин: 1, макс: 5, кол-во: 1)], затем цена = 0 , в первую очередь, если.
[Случайно (мин: 6, макс: 18, количество: 1)], затем цена = 20 , покрывает секунду, если.
[Случайно (мин .: 19, макс: 64, кол: 1)], затем цена = 40 , охватывает третий.
[Случайно (мин: 65, макс: 122, кол: 1)], затем цена = 5 , покрывает старшую цену.
AgeInput = «invalid» , проверяет сценарий первого исключения, когда пользователь передает нецелое значение.
AgeInput = «0» , охватывает вторую защитную проверку.
AgeInput = «1000» , заставьте тест пройти последнюю проверку достоверности на предмет максимального возраста.
Всего за семь тестовых случаев нам удалось достичь 100% покрытия кода. Тем не менее, весьма вероятно, что эти тестовые случаи не будут обнаруживать ошибки регрессии, если кто-то, например, изменит один из условных операторов «<«,> »,> =» или «<=». Кроме того, такой подход к написанию тестов не гарантирует правильность кода. Если тесты основаны на глючном коде, они не помогут нам предоставить более качественное и беспроблемное программное обеспечение. Именно здесь нам могут помочь методы разработки тестов на основе спецификаций .
Тесты на основе спецификаций: на основе разделения эквивалентности
Во-первых, позвольте мне рассказать, что означает тестирование на основе спецификаций.
Это подход к тестированию, в котором тестовые наборы разрабатываются на основе целей теста и условий теста, полученных из требований , например, тестов, которые выполняют определенные функции или проверяют нефункциональные атрибуты, такие как надежность или удобство использования.
Основными целями разделения эквивалентности являются сокращение количества тестовых случаев до необходимого минимума и выбор правильных тестовых случаев, чтобы охватить все возможные сценарии .
Эквивалентная гипотеза разбиения
Разделенные наборы называются разделами эквивалентности или классами эквивалентности. Затем мы выбираем только одно значение из каждого раздела для тестирования. Гипотеза, лежащая в основе этого метода, состоит в том, что если одно условие / значение в разделе проходит, все остальные также пройдут . Аналогичным образом, если одно условие в разделе не выполняется, все остальные условия в этом разделе также не будут выполнены .
Легко проверить небольшие входные диапазоны, например, 1-10, но сложно протестировать, например, 2-10000. Эквивалентность Partitioning помогает нам следовать один из принципов Семь тестирования :
Исчерпывающее тестирование невозможно : тестирование всего, включая все комбинации входов и предварительных условий, невозможно. Вместо того, чтобы проводить полное тестирование, мы можем использовать риски и приоритеты, чтобы сосредоточить наши усилия по тестированию. Например: в приложении на одном экране имеется 15 полей ввода, каждое из которых имеет 5 возможных значений. Чтобы протестировать все действительные комбинации, вам потребуется 30 517 578 125 (515) тестов. Это весьма маловероятно , что проект Сроки позволят этому количеству тестов. Оценка и управление рисками является одним из наиболее важных действий и причин для тестирования в любом проекте.
Иногда может быть дешевле написать от 1 до 10 тестов для охвата диапазонов наборов, таких как 1-10, но в большинстве случаев не так хорошо писать 100 000 или миллионы тестов для больших наборов. Таким образом, мы можем использовать основанные на спецификации методы проектирования тестов, чтобы сократить количество тестовых случаев до необходимого минимума . Если мне придется написать ранее упомянутый код для производства, а также протестировать его, я, вероятно, буду использовать Test Driven Development . Затем я спроектирую тестовые сценарии на основе требований спецификации.
Как вы можете видеть, в своих тестах я использую атрибут NUnit TestCase . Как только метод будет выполнен, будет выполнено семь тестов на основе значений, предоставленных через атрибуты. Первое значение представляет ageInput; вторая — ожидаемая цена.
Тестовые случаи выводятся с использованием разделов эквивалентности. Количество тестовых случаев не увеличивается. Однако основное отличие состоит в том, что тесты основаны на требованиях спецификации , а не на самом коде. Также они были написаны перед кодом .
Как видно из таблицы, существует семь разделов эквивалентности: четыре действительных и три неверных. Я покрываю их все значениями из последней строки таблицы.
Ошибки разделения эквивалентности, чтобы помнить
Хотя этот метод относительно прост, люди допускают некоторые распространенные ошибки при его применении.
1. Различные подмножества не могут иметь общего члена. Если значение присутствует в двух разделах, вы не можете определить, как оно должно вести себя в разных случаях.
Читайте также: