Что такое oracle в тестировании

Обновлено: 04.07.2024

Запрос: Что означает тестовый оракул в разработке программного обеспечения?

Справочник статей

предисловие

Я искал тестового оракула на Baidu, но не нашел желаемого результата, поэтому я глубоко искал и разобрался с определением тестового оракула, запишите его здесь.

1. Введение

Критерии тестирования. Термин «оракул» в CSTQB представляет собой содержание ETM (экспертного управления ISTQB) в ISTQB. Китайский термин для оракула теста - [ссылка на результат теста] означает: определить источник ожидаемого результата, который будет сравниваться с фактическим результатом во время теста. Он может включать в себя существующие системы (в качестве эталона), руководства пользователя или личный опыт, но не код. [Так же, как Адрион]

Я чувствую, что этого определения недостаточно и нет достаточных доказательств в его поддержку, поэтому я решил изучить его сам.

2. Процесс расследования

2.1 Поиск по Baidu Academic с ключевым словом "test oracle"

На основе результатов поиска и сводки отображаемых статей я выбрал две статьи и загрузил их:

1）Xie T. Augmenting Automatically Generated Unit-Test Suites with Regression Oracle Checking[J]. 2006, 4067:380-403.
Эта статья является статьей профессора Се Тао, известного ученого в области мягкой промышленности (особенно в области автоматического тестирования программного обеспечения). Очень мощный

2）Tu D, Chen R, Du Z, et al. A Method of Log File Analysis for Test Oracle[C]// International Conference on Scalable Computing and Communications; Eighth International Conference on Embedded Computing, 2009. Scalcom-Embeddedcom. IEEE, 2009:351-354.
Это также относится к тестовому контенту, связанному с оракулом.

Среди них статья 1) далаОчень четкое определение：

A test case consists of two parts: a test input to exercise the program under test and a test oracle to check the correctness of the test execution. A test oracle is often in the form of executable assertions such as in the JUnit testing framework. Manually generated test cases are valuable in exposing program faults in the current program version or regression faults in future program versions.

Что здесь сказано: 1 тестовый случай = 1 тестовый вход + 1 тестовый оракул , Тестовый ввод используется для выполнения программы, а тестовый оракул используется для проверки правильности выполнения теста. иТестовый оракул - это обычно исполняемый оператор утверждения(Например, в тестовой среде JUnit).

Видя здесь, я думаю, что определение и форма теста оракула относительно ясна:
Во-первых, тестовый оракул является частью тестового примера и используется для проверки правильности результатов, полученных после выполнения тестового ввода;
Во-вторых, тестовый оракул часто появляется с исполняемыми утверждениями (такими как функции assertEquals и assertTrue в тестах JUnit, операция может относиться к[4]）

Кроме того,[5] Иметь дальнейшее понимание теста оракула:

Здесь также ясно. Концепция тестового оракула очень ясна (то есть: он используется для проверки правильности вывода программы), но его форма очень широка, что может сделать программу, это может быть документ или даже человек (шок ==).

Здесь также очень интересно сказать. Умное использование тестового оракула может снизить нагрузку на программистов.

[6]Также добавлены концепция и состав оракула:

An oracle is a mechanism for determining whether the program has passed or failed a test.

A complete oracle would have three capabilities and would carry them out perfectly:

1）A generator, to provide predicted or expected results for each test.
2）A comparator, to compare predicted and obtained results.
3）An evaluator, to determine whether the comparison results are sufficiently close to be a pass.

вики-энциклопедия[7]Есть также соответствующие определения.

Однако возникает вопрос: что именно говорит оракул на китайском? ?
Итак, я посмотрю дальше.

2.2 Найти китайское выражение тестового оракула

В гугл переводчике[8]Найдено в:

В итоге я склонен думать:
Китайское выражение тестового оракула:Тестовый прогноз。
(кажется, что некоторые учителя говорили об этом термине раньше, но я не помню его)

3. Резюме

Каждый раз для написания CSDN требуется полчаса. Это все еще тот случай, когда я нашел все материалы (внимательно прочитайте веб-страницу и поймите концепцию). Требуется время, чтобы преобразовать в текст.

Может быть, его навыка недостаточно.
жесткая .

Продолжайте усердно работать уткой.

ссылки

[2] Xie T. Augmenting Automatically Generated Unit-Test Suites with Regression Oracle Checking[J]. 2006, 4067:380-403.

[3] Tu D, Chen R, Du Z, et al. A Method of Log File Analysis for Test Oracle[C]// International Conference on Scalable Computing and Communications; Eighth International Conference on Embedded Computing, 2009. Scalcom-Embeddedcom. IEEE, 2009:351-354.

В вычислительный , программной инженерии и тестирование программного обеспечения , тест оракул (или просто оракулом ) представляет собой механизм для определения того, успешно или неуспешно прошел тест. Использование оракулов включает сравнение выходных данных тестируемой системы для заданных входных данных тестового примера с выходными данными, которые, по определению оракула, должен иметь продукт. Термин «тестовый оракул» впервые был введен в статье Уильяма Э. Хаудена. Дополнительная работа над различными видами оракулов была исследована Элейн Вейкер .

Оракулы часто работают отдельно от тестируемой системы. Однако постусловия метода являются частью тестируемой системы как автоматизированные оракулы при проектировании с помощью контрактных моделей. Определение правильного вывода для заданного входа (и набора состояний программы или системы) известно как проблема оракула или проблема тестового оракула, что намного сложнее, чем кажется, и включает работу с проблемами, связанными с управляемостью и наблюдаемостью.

СОДЕРЖАНИЕ

Категории

Обзор исследовательской литературы, охватывающий период с 1978 по 2012 год, выявил несколько потенциальных категорий тестовых оракулов.

Указано

Эти оракулы обычно связаны с формализованными подходами к моделированию программного обеспечения и построению программного кода. Они связаны с формальной спецификацией , дизайном на основе модели, который может использоваться для генерации тестовых оракулов, спецификацией перехода между состояниями, для которой могут быть получены оракулы, чтобы помочь основанному на модели тестированию и проверке соответствия протокола , и дизайну по контракту, для которого эквивалентный тестовый оракул это утверждение .

Указанные тестовые оракулы имеют ряд проблем. Формальная спецификация основана на абстракции, которая, в свою очередь, может иметь элемент неточности, поскольку все модели не могут уловить все поведение.

Полученный

Производный тестовый оракул различает правильное и неправильное поведение, используя информацию, полученную из артефактов системы. Они могут включать документацию, результаты работы системы и характеристики версий тестируемой системы. Наборы регрессионных тестов (или отчеты) являются примером производного тестового оракула - они построены на предположении, что результат предыдущей версии системы может быть использован в качестве вспомогательного средства (оракула) для будущей версии системы. Ранее измеренные характеристики производительности могут быть использованы в качестве оракула для будущих версий системы, например, чтобы задать вопрос о наблюдаемом потенциальном ухудшении производительности. Текстовая документация из предыдущих версий системы может использоваться в качестве основы для определения ожиданий в будущих версиях системы.

Псевдо-оракул попадает в категорию производного тестового оракула. Псевдо-оракул, по определению Вейукера, представляет собой отдельно написанную программу, которая может принимать те же входные данные, что и тестируемая программа или система, так что их выходные данные можно сравнивать, чтобы понять, есть ли проблема для исследования.

Частичный оракул - это гибрид указанного тестового оракула и производного тестового оракула. Он определяет важные (но не полные) свойства тестируемой системы. Например, при метаморфическом тестировании такие свойства, называемые метаморфическими отношениями, используются при нескольких запусках системы.

Скрытый

Неявный тестовый оракул полагается на подразумеваемую информацию и предположения. Например, может быть какой-то подразумеваемый вывод из сбоя программы, то есть нежелательное поведение - оракул, чтобы определить, что может быть проблема. Существует несколько способов поиска и тестирования нежелательного поведения, независимо от того, называют ли это отрицательным тестированием, где есть специализированные подмножества, такие как фаззинг .

У неявных тестовых оракулов есть ограничения, поскольку они полагаются на подразумеваемые выводы и предположения. Например, сбой программы или процесса может не быть приоритетной проблемой, если система является отказоустойчивой и поэтому работает в форме самовосстановления / самоуправления . Неявные тестовые оракулы могут быть подвержены ложным срабатываниям из-за зависимостей от среды.

Человек

Если указанные, производные или неявные тестовые оракулы не могут быть использованы, то для определения тестовых оракулов требуется участие человека. Их можно рассматривать как количественный и качественный подходы. Количественный подход направлен на поиск нужного количества информации, которую нужно собрать о тестируемой системе (например, результатов тестирования), чтобы заинтересованная сторона могла принять решение о соответствии или выпуске программного обеспечения. Качественный подход направлен на определение репрезентативности и пригодности входных тестовых данных и контекста выходных данных тестируемой системы. Примером может служить использование реалистичных и репрезентативных данных испытаний и понимание результатов (если они реалистичны). При этом можно руководствоваться эвристическими подходами, такими как интуиция, эмпирические правила, вспомогательные контрольные списки и опыт, чтобы помочь адаптировать конкретную комбинацию, выбранную для тестируемой программы / системы.

Примеры

Тестовые оракулы обычно основаны на спецификациях и документации . Формальная спецификация используется в качестве входных данных для модели на основе конструкции и модель на основе тестирования будет примером указанного тестового оракула . Модель на основе оракул использует ту же модель для генерации и проверки поведения системы. Документация, которая не является полной спецификацией продукта, такой как руководство по использованию или установке, или записью характеристик производительности или минимальных требований к машине для программного обеспечения, обычно является производным тестовым оракулом.

Оракул согласованности сравнивает результаты выполнения одного теста с другим на предмет сходства. Это еще один пример производного тестового оракула.

Оракул для программы может быть второй программой, которая использует другой алгоритм для вычисления того же математического выражения, что и тестируемый продукт. Это пример псевдо-оракула, который является производным тестовым оракулом.

Во время поиска Google у нас нет полного оракула, чтобы проверить правильность количества возвращенных результатов. Мы можем определить метаморфическое отношение таким образом, чтобы последующий суженный поиск давал меньше результатов. Это пример частичного оракула, который представляет собой гибрид указанного тестового оракула и производного тестового оракула.

Статистический оракул использует вероятностные характеристики, например, с анализом изображений, где определен диапазон достоверности и неопределенности для того, чтобы тестовый оракул произнес совпадение или иначе. Это был бы пример количественного подхода в человеческом тестовом оракуле.

Эвристический оракул предоставляет репрезентативные или приблизительные результаты по классу тестовых входных данных. Это был бы пример качественного подхода в человеческом тестовом оракуле.

В древние времена оракулом называли мудрого человека или старейшину, к которому шли за советом в случае необходимости принять важное решение. "Надо ли начинать войну на севере?" или "Должна ли дочь нашего правителя выйти замуж за Х для воцарения мира?", и так далее. Все эти вопросы касались критически важных проблем, и, как правило, слова оракула расценивались очень серьезно.

Это важная параллель, потому что в тестировании мы называем оракулом все, что может дать нам важную информацию, связанную с принятием решения или валидацией решений. Обычно решения связаны с качеством, риском или возможными проблемами.

Ответ на этот вопрос прост, но довольно глубок: оракулом может быть практически все содержащее важную информацию о продукте. Если вы хотите узнать больше об оракуле, рекомендую серию статей Майкла Болтона "Оракулы сверху донизу". Резюмируя информацию из статей Майкла, оракулами могут быть:

Ментальная модель или ощущение (Опыт) – это может показаться слегка абстрактным, но если вы хоть раз тестировали ПО и находили в нем проблемы, то знаете, что начинается это с ощущений. Что-то говорит вам – тут что-то не так, это нужно изучить. В любом случае этого недостаточно для создания баг-репорта, поэтому мы будем исследовать вопрос подробнее.

Артефакты (Справка) – любой вид знания, зафиксированного письменно, или документ, дизайн, черновик, любая форма коммуникации, которая несет знания. Все это можно использовать как оракул.

Обсуждения с важными носителями знания (Конференция) – один из самых важных и иногда недооцениваемых источников знания о ПО или проекте – это задействованные в нем люди, конечные пользователи, коллеги, руководители и все участники процесса. В ситуациях ограниченной или отсутствующей документации я неоднократно прикрывал себе зад только потому, что активно добивался ясности и информации от важных участников разработки.

Соответствие известным продуктам (Умозаключение) – применение знаний о сравнимых продуктах к тестируемому, и поиск:

Несоответствий: общественным стандартам для приложений, которые мы тестируем. Пример: у всех мобильных калькуляторов есть определенная опция, но у нас она реализована слегка иначе.
Соответствий: проблемам, с которыми мы сталкивались в том же классе приложений. Пример: каждый раз при тестировании загрузки файлов я ищу проблемы с валидацией ограничения размера файлов, потому что мой предыдущий опыт (один оракул) с другими схожими приложениями (другой оракул) гласит, что там часто кроются баги.

Оракулы – важная концепция, которую часто упускают во множестве материалов. Это плохо, потому что оракулы – краеугольный камень для понимания тестирования. Профессиональный тестировщик живет на грани неопределенности – меняющихся дедлайнов, меняющихся требований, сомнительного качества. Оракулы дают нам кусочки информации, на которые можно опираться как на истину.

Более того, они дают нам не только способ валидировать сомнительное поведение продукта – они могут также научить нас конструировать эксперименты, которые помогут выявить это сомнительное поведение.

К сожалению, несмотря на то, что каждый тестировщик использует оракулы, сам термин "оракул" и связанная с ним теория не особо известны среди тестировщиков, и это плохо.

Как я говорил ранее, оракулы – концепция, которую вы используете в тестировании, нравится вам это или нет. Вы можете не знать, что вы ими пользуетесь, или не называть это оракулом.

Примеры использования оракулов:

Тест-кейсы и тест-сценарии: я небольшой их фанат, но люди ими пользуются. Если вы знакомы с концепцией создания тест-кейса, то знаете, что там есть раздел "Ожидаемый результат". Это классический пример оракула, так как он сообщает всем о правильном поведении приложения. Аналогичное применимо к ожиданиям в баг-репортах и автоматизированных проверках.
Документация: документы и спецификации используются как оракулы. Это неплохо, но проблема в том, что они создаются и поддерживаются людьми и страдают от тех же проблем, что и код: они теряют актуальность, в них есть ошибки, они расплывчато сформулированы, чересчур техничны, чересчур поверхностны, слишком детализированны… Проблемы возникают, когда мы, как тестировщики, начинаем рассматривать документацию как единственный ценный источник знаний, в то время как в первую очередь нами должны руководить эксперименты и исследования.

Я не первый, кто пишет об оракулах, и я не сообщаю ничего нового. Я просто свожу воедино все то, что, по моему мнению, срабатывает для меня, и передаю эту информацию вам.

Если вас интересует концепция оракулов тестирования, то вот пара ресурсов, которые могут вам пригодиться:

Вот о каких оракулах я узнал из этих статей, и применяю их ежедневно:

FEWHICCUPPS – незаменимый оракул, если вы пользуетесь им для валидации, правильное ли поведение вы наблюдаете. Это именно то, для чего он был предназначен – для использования в качестве чек-листа. Каждый раз, сталкиваясь с неуверенностью, баг ли это, вы можете прибегнуть к FEW HICCUPPS и поразмышлять, можно ли валидировать это поведение стандартом, понимаете ли вы цель, соответствует ли она продукту, заявлениям о продукте, истории продукта, и так далее. Этот тип мышления, управляемого через вопросы – причина моей убежденности, что оракулы могут работать в обратном направлении, то есть не только как внешняя сущность для валидации истины о продукте, но и как провокация экспериментов, помогающих вскрыть несоответствия между ожиданиями и реальностью.
Оракул регресса – если вы рассматриваете регрессионное тестирование как возможный оракул, то, насколько я понимаю, вы освобождаетесь от большей части этой ноши – ожидания, что это неотъемлемая и всемогущая часть эффективного тестирования. Многие люди убеждены, что регрессионное тестирование означает, что нужно каждый раз прогонять набор тестов, или все ваши тесты, или все автоматические проверки. Я могу написать целую статью о всем том, что неверно в этом убеждении, но я ценю ваше время, поэтому просто поверьте мне на слово. Вместо этого попробуйте относиться к регрессу как к виду оракула. Как оракул и, соответственно, эвристика, он имеет ограниченную эффективность.
Ограничения как оракул – я убежден, что это самый очевидный, простой в использовании, и в то же самое время наиболее упускаемый оракул. При любом тестировании у вас есть список ограничений – максимальная длина строки, количество разрешенных спецсимволов, размер файла – и все это подсказки для вас. Как хороший тестировщик, вы в первую очередь должны думать, что будет, если вы нарушите правила? Что будет, если не вводить запрашиваемое количество символов? Что произойдет? Появится ли ошибка, будет ли исключение, предусмотрел ли разработчик подобный сценарий? Если вы один из тех, кто говорит "Без понятия, с чего начинать тестирования", то вот неплохой план действий – найдите все ограничения продукта, составьте список, постарайтесь нарушить их как минимум тремя различными способами, зафиксируйте результаты, и пусть собранная информация станет толчком для более глубокого тестирования. Это хороший старт тестирования, и он прямо у вас перед глазами.
Самоверифицируемые данные как оракул – я активно пользуюсь этим оракулом в автоматических проверках, в основном для имен тестов. Я также пытаюсь приучить к этому разработчиков. Здравый смысл гласит, как минимум мне, что имя автоматической проверки должно сообщать о проверяемом результате. Это также хороший способ убедиться, что ваши проверки фокусируются на одном действии и его результате, а не распыляются на разные возможности. Пример: если моя проверка называется testingValidAdminUserFlow и падает, я без понятия, где она упала и что с ней не так. Это значит, что мне придется изучать вопрос, и это увеличивает временные затраты. С другой стороны, если вы создаете небольшие, однозначные проверки, использующие самоверифицируемые данные как оракул, вы легко определите, в чем проблема. К примеру, если проверка называется loginAsAdmin200Test и падает, вы будете точно знать, что авторизация под администратором не вернула код ответа 200.

В качестве заключения: нравится вам это или нет, вы используете оракулы, и верьте мне, это хорошо. Чем больше вы о них знаете, тем больше вы знаете в принципе.

К чему я это веду – относитесь к оракулам, как к эвристикам, пожалуйста, не забывайте об их ненадежности, и не цепляйтесь за единственный оракул как источник незыблемых истин. Вместо этого владейте множеством дающих информацию оракулов, и смотрите, что из этой информации даст нам уверенность в принятии решений или в приходе к выводам – конечно, обдумав эти решения при помощи своего аналитического, критически мыслящего ума.

Всем нам нравится создавать что-то новое — собственно, это одна из причин, по которой мы занимаемся программированием. Мы берем интересную задачу и придумываем способ ее реализации на языке PL/SQL.

Однако никому не нравится возиться с тестированием своих программ (и писать документацию для них). Нам приходится это делать, но мы занимаемся этим без особого энтузиазма. На практике разработчики выполняют пару-тройку составленных на скорую руку тестов и решают, что если ошибки не найдены сразу, значит, их в программе нет. Почему это происходит?

Стремление к успеху. Мы настолько убеждены в том, что наш код будет работать правильно, что предпочитаем держаться подальше от плохих новостей — и даже от самой возможности их появления. Мы проводим поверхностное тестирование, убеждаемся, что в первом приближении все работает, и ждем, пока другие найдут ошибки, если они есть (а они есть, можете не сомневаться!).
Сроки. Сейчас время Интернета, время выхода на рынок определяет успех. Все должно быть готово немедленно — и мы выпускаем предварительную бета-версию как готовый продукт, а пользователи мучаются с тестированием наших разработок.
Некомпетентность руководства. Как правило, руководители информационных отделов ничего не смыслят в разработке ПО. И если у вас нет времени на создание полноценного проекта (включая проектирование, написание кода, тестирование, документирование и т. д.), то в результате получится убогая поделка с множеством ошибок.
Затраты на организацию тестирования. Создание тестовых программ обычно считается пустой тратой времени, ведь всегда найдется более важная работа. Одним из следствий такого подхода является то, что значительная часть обязанностей по тестированию перекладывается на отдел контроля качества (если он есть). Конечно, участие профессионалов в области контроля качества может оказать огромное влияние на результат, однако и разработчики не должны снимать с себя ответственность за модульное тестирование своего кода.

Таким образом, программы почти всегда нуждаются в дополнительном тестировании. Как повысить его эффективность в мире PL/SQL ?

Для начала мы рассмотрим типичный пример неудачного процесса тестирования. Затем будут представлены выводы относительно ключевых проблем ручного тестирования, и мы познакомимся со средствами автоматизированного тестирования кода PL/SQL.

Типичные неэффективные технологии тестирования

В ходе тестирования программы необходимо определить, какие изменения вносятся в ходе ее работы: возвращаемая функцией строка, обновленная процедурой таблица и т. д. Затем вы заранее формируете прогноз правильного поведения программы для заданного набора входных данных и конфигурации (тестового сценария). После выполнения программы фактические результаты (внесенные программой изменения) сравниваются с прогнозируемыми значениями. Если они совпадают — значит, программа работает. Если что-то отличается — значит, где-то произошел сбой.

Это очень хорошее общее описание процесса тестирования; остается выяснить, как определить все необходимые тестовые сценарии и реализовать тесты. Начнем с весьма типичного (и к сожалению, неэффективного) подхода к тестированию.

Допустим, мы пишем большое приложение, обрабатывающее большое количество строк. В PL/SQL имеется функция SUBSTR , которая возвращает заданную часть строки. Однако ее использование связано с некоторыми проблемами. Дело в том, что эту функцию удобно применять, когда вы знаете начальную позицию и длину строки. Однако очень часто известно лишь местоположение начального (start) и конечного (end) символов, а длину строки приходится вычислять. Но по какой формуле? Чтобы не мучиться с вычислениями (кстати говоря, правильный ответ end — start + 1), мы напишем функцию betwnstr, которая произведет все вычисления за нас:

К сожалению, объем работы весьма велик, а это всего лишь одна из множества написанных программ, которую необходимо протестировать. Мы пишем примитивный «тестовый сценарий» с использованием DBMS_OUTPUT.PUT_LINE и запускаем его:

Работает. надо же! Но одного теста недостаточно. Давайте зададим конечное значение за пределами строки — например, 500. Функция должна вернуть остаток строки, как бы это сделала функция SUBSTR :

Снова работает! Теперь нужно убедиться в том, что функция правильно работает со значениями NULL :

Три из трех! Функция работает правильно, скажете вы? Нет — скорее всего, вы покачаете головой и скажете себе: «Такое тестирование даже в первом приближении не проверяет все возможные сценарии. Оно даже не изменяет значение первого аргумента! К тому же при каждом изменении входных значений предыдущий тест терялся».

И это будет правильно. Вместо того чтобы наугад проверять разные значения аргументов, следует составить список тестовых сценариев, поведение которых мы хотим проверить.

На основании этой таблицы строится простой сценарий следующего вида:

Каждый раз, когда нам потребуется протестировать betwnstr , мы просто выполним этот сценарий и проверим результаты. Для исходной реализации они будут выглядеть так:

«Проверим результаты». Легко сказать, но как это сделать? Как узнать, прошли ли тесты? Нам придется просматривать результаты строку за строкой и проверять их по таблице. К тому же при действительно тщательном тестировании у нас будет более 30 тестовых сценариев (не забыли об отрицательных значениях начальной и конечной позиции?). На просмотр результатов уйдет несколько минут, и это для совершенно тривиального кода. Сама мысль о распространении этой методики на «реальный» код выглядит устрашающе. А теперь представьте, что программа изменяет две таблицы и возвращает два аргумента OUT . Счет тестовых сценариев пойдет на сотни, да еще добавьте к этому проблемы настройки конфигурации и проверку правильности содержимого таблиц.

И все же многие разработчики выбирают этот путь при «тестировании» своего кода. Почти все проводимое тестирование обладает рядом ключевых недостатков:

Тестовый код пишется вручную, что существенно ограничивает объем тестирования. У кого найдется время на написание всего необходимого кода?
Неполное тестирование. Будем откровенны: при тестировании мы обычно ограничиваемся несколькими очевидными случаями, чтобы убедиться в том, что программа не имеет очевидных изъянов. Вряд ли это можно назвать полноценным тестированием.
Одноразовые тесты. Было бы неплохо подумать о будущем и понять, что нам (или кому-то другому) еще неоднократно придется проводить те же тесты.
Ручная проверка. Если мы будем полагаться только на собственную наблюдательность при проверке результатов, это займет слишком много времени и, скорее всего, приведет к ошибкам.
Тестирование после разработки. Многие программисты говорят себе: «Вот допишу программу и займусь тестированием». Вроде бы вполне разумный подход, и все же он в корне неверен. Во-первых, наши программы никогда не «дописываются» — исправления вносятся до последней минуты, поэтому времени на тестирование вечно не хватает. Во-вторых, если вы начинаете думать о тестировании только после завершения работы над реализацией, вы подсознательно выбираете тесты, которые имеют наибольшую вероятность успеха, и избегаете тех, которые могут столкнуться с проблемами. Так уж устроено наше сознание.

Если вы хотите, чтобы тестирование было действительно эффективным и тщательным, необходимо действовать иначе. Тесты должны определяться так, чтобы они могли легко сопровождаться с течением времени. Мы должны иметь возможность легко проводить тестирование и, что еще важнее, — без продолжительного анализа определить результат: успех или неудача. При этом выполнение тестов не должно требовать написания больших объемов тестового кода.

Далее я сначала дам несколько советов относительно того, как организовать тестирование вашего кода. Затем будут рассмотрены средства автоматизации тестирования для разработчиков PL/SQL; особое внимание будет уделено utPLSQL и Quest Code Tester for Oracle .

Общие рекомендации по тестированию кода PL/SQL

Выбор инструмента тестирования зависит только от вас, но для повышения качества тестирования следует принять во внимание следующие факторы:

Осознанная необходимость тестирования. Самые важные изменения должны произойти у вас в голове. От позиции «Надеюсь, эта программа сработает» необходимо перейти к позиции «Я должен быть способен доказать, что моя программа работает». Осознав необходимость тестирования, вы начнете писать более модульный код, который проще тестируется. Также вам понадобятся инструменты, позволяющие более эффективно проводить процесс тестирования.
Продумайте тестовые сценарии до того, как возьметесь за написание программы, — сформулируйте их на листке бумаги или в программе, управляющей процессом тестирования. Очень важно, чтобы ваши представления о том, что же необходимо протестировать, нашли внешнее воплощение; в противном случае вы с большой вероятностью о чем-нибудь забудете. Приступая к работе над программой в понедельник, я легко могу представить 25 разных сценариев (требований), которые необходимо реализовать. Три дня спустя отведенное время заканчивается, я перехожу к тестированию — и как ни удивительно, могу вспомнить всего пять тестовых сценариев (да и то самых очевидных). Если вы составите список известных тестовых сценариев в начале работы, вам будет намного проще запомнить и проверить их.
Не беспокойтесь о стопроцентном тестовом покрытии. Вряд ли существует хоть одна нетривиальная программа, которая была полностью протестирована. Не ставьте себе цель обеспечить стопроцентное покрытие всех возможных тестовых сценариев. Скорее всего, это нереально, а результат только приведет вас в уныние. Самое важное в тестировании — взяться за него. И что с того, что в фазе 1 было реализовано всего 10% тестовых сценариев? Это на 10% больше, чем было прежде. А когда ваши тестовые сценарии (и связанный с ними код) окажутся на месте, дополнить их новыми возможностями станет проще.
Интеграция тестирования в разработку. Нельзя откладывать тестирование до того момента, когда вы «закончите» работу над программой. Чем раньше вы начнете думать над ним, тем лучше. Составьте перечень тестовых сценариев, спланируйте тестовый код и запускайте тесты в процессе реализации, отладки и совершенствования программы. При любой возможности снова выполняйте тесты и убеждайтесь в том, что программа действительно двигается вперед. Если вам нужно красивое название (методология), которое убедит вас в ценности такого подхода, изучите широко распространенную (в объектно-ориентированных кругах) методологию разработки через тестирование (TDD, Test-Driven Development).
Подготовьте регрессионные тесты. Все перечисленные предложения в сочетании с инструментами, о которых рассказано в следующем разделе, помогут вам организовать регрессионное тестирование. Такие тесты должны предотвратить регрессию, то есть нарушение работоспособности ранее работавшего кода при внесении изменений. Ужасно неприятно, когда при выпуске версии 2 продукта половина функций версии 1 вдруг перестает работать. «Как это могло произойти?» — вопрошают пользователи. И что им на это ответить? Честный ответ должен звучать так: «Извините, но у нас не было времени на регрессионные тесты. Когда мы вносим изменения в своем запутанном коде, на самом деле мы понятия не имеем, что при этом могло сломаться». Но после создания нормальных регрессионных тестов вы можете уверенно вносить изменения и выдавать новые версии.

Средства автоматизации тестирования программ PL/SQL

В наши дни разработчики PL/SQL могут использовать целый ряд автоматизированных инфраструктур и средств тестирования своего кода:

Читайте также: