Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

304 Глава 7

7.2. Виды и уровни тестирования

Структурирование процесса тестирования ПС по уровням обычно связывает-

ся либо с видами тестируемых объектов (модуль, система или ее части), либо с

проверяемыми целями качества ПС (функциональность, безопасность, надежность

и др.) на разных стадиях ее создания и эксплуатации.

7.2.1. Уровни тестирования по видам объектов

Традиционно выделяется три уровня тестирования ПО: автономное

или мо-

дульное (unit testing), интеграционное

(integrating testing) и системное (system test-

ing). В стандарте ISO/IEC 12207 прослеживаются четыре уровня тестирования:

•

модульное (в процессе «Построение (Конструирование) ПО»),

•

интеграционное (в процессе «Интеграция ПО»),

•

тестирование ПО (как процесс) и

•

системное (в процессе «Системная интеграция»).

Модульное тестирование предполагает проверку функционирования объек-

тов в изоляции друг от друга. Оно обычно выполняется разработчиками с доступом

к коду и чередуется с отладкой. Объектами тестирования являются отдельные про-

цедуры (методы и классы при объектном подходе), программные модули и про-

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

Цели модульного тестирования – обнаружение дефектов в реализации функ-

ций объектов и подтверждение соответствия объекта спецификациям проекта (тех-

ническому проекту).

Наиболее полно вопросы систематического модульного тестирования осве-

щены в стандарте IEEE 1008-87 “Standard for Software Unit Testing” [14].

Интеграционное тестирование предназначено для проверки правильности

взаимодействия между программными объектами, протестированными автономно.

Современные систематические стратегии интеграции определяются архитек-

турой ПС и моделью разработки (обычно итерационной с приращениями).

Интеграционное тестирование выполняется при каждой сборке новой версии

ПС с целью выявления дефектов в интерфейсах между интегрируемыми компо-

нентами и подтверждения их соответствия проекту архитектуры ПС.

Тестирование программного обеспечения заключается в проверке функцио-

нирования интегрированной версии ПО системы в моделируемой среде. Цели тес-

тирования на этом уровне – выявление дефектов в реализации внешних функций ПО

и подтверждение его соответствия спецификации функциональных требований.

Выделение уровня системного тестирования обусловлено необходимостью

обеспечения и оценки качества сопряжения ПО с другими, в том числе, не про-

граммными компонентами современных систем.

На этом уровне тестирования производится проверка соответствия ПС целям

качества, установленным в требованиях к системе (с акцентом на нефункциональ-

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

носимость и др., а также внешним интерфейсам с другими системами, средой, ап-

паратным обеспечением. Большая часть функциональных отказов и дефектов

В ДСТУ 2941термин unit testing переведен как «блочное тестирование» [13].

В ДСТУ 2941термин integration testing переведен как «комплексные испытания»

Глава 7 305

должна быть идентифицирована и устранена на предыдущих уровнях тестирова-

ния. Цели тестирования на данном уровне– выявление дефектов, связанных с не-

удовлетворительными техническими характеристиками функционирования систе-

мы, и подтверждение ее соответствия проекту архитектуры системы.

Взаимосвязь уровней и целей тестирования можно представить в виде моди-

фицированной каскадной модели ЖЦ (так называемой V-образной модели) [15],

отражающей процессы декомпозиции и интеграции ПС и соответствующие уровни

тестирования (рисунок 7.2).

Автономное

тестирование

Сборка и

тестирование

компонентов

Комплексное

тестирование ПО

Системное

тестирование

Приемочное

тестирование

Уровень пользователя

Уровень системы

Уровень ПО

Требования

пользователя

Разработка

плана приемочного

тестирования

план, требования пользователя

Требования к

системе

Разработка

плана системного

тестирования

план, требования к системе

Требования к

ПО

(архитектура)

Разработка

плана комплексного

тестирования ПО

план, спецификация ПК

Требования к

проекту (функциям

и компонентам)

Разработка

плана тестирования

компонентов

Требования к

элементам

(модулям)

Разработка

планов автономного

тестирования

план,спецификация

функций ПК

Код, данные,

процедуры

продукт ПО,

шаг процесса

тестирования

Рис. 7.2. V-образная модель тестирования

В этой модели тестирование рассматривается как непрерывный процесс, ин-

тегрированный в процесс разработки ПС и включающий два взаимосвязанных под-

306 Глава 7

процесса – планирование тестирования в рамках процессов разработки системы

(левая ветвь на рисунке) и проведение тестирования соответствующих объектов

(правая ветвь).

Хотя на рисунке для наглядности уровни тестирования отображены в привяз-

ке к традиционной каскадной модели разработки, - на практике в зависимости от

архитектуры системы, а также принятой модели разработки, эти уровни могут объ-

единяться, а разные задачи тестирования - выполняться параллельно.

На практике задачи тестирования ПО и системного тестирования часто

объединяются в единый процесс, но для сложных ПС тестирование технических

характеристик должно выполняться отдельно.

7.2.2. Виды испытаний программной системы

Помимо рассмотренных выше уровней тестирования объектов ПС, сущест-

вуют виды тестирования ПС в целом, выполняемые на заключительных стадиях ее

разработки и в ходе эксплуатации.

К ним, прежде всего, относятся испытания ПС. В ДСТУ 2853-94 определены

следующие виды испытаний - предварительные, приемочные, установочные и экс-

плуатационные.

Предварительные испытания программной системы можно считать наи-

высшим уровнем ее «формального» тестирования, выполняемого в среде разра-

ботки с целью обнаружения возможных оставшихся дефектов и оценки достигну-

того уровня качества ПС. Здесь «формальный» означает, что тестирование выпол-

няется строго в соответствии с установленными документированными процедура-

ми и с участием представителей заказчика. Испытания осуществляются в два прие-

ма – тестирование ПО и тестирование системы. Следовательно, цель предваритель-

ных испытаний - обнаружение несоответствия ПС внешним спецификациям функ-

циональных и технических характеристик.

Приемочные и все последующие испытания непосредственно не связываются

с понятием тестирования, ибо их цель - подтвердить соответствие (или несоот-

ветствие) системы исходным требованиям пользователя. В соответствии со стан-

дартом ISO/IEC 12207 эти испытания выполняются в рамках разных процессов ЖЦ.

Цель приемочных испытаний (приемочного

, квалификационного тестиро-

вания) – определение степени соответствия разработанной ПС исходным требова-

ниям заказчика (пользователя). Эти испытания проводятся исключительно в кон-

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

как правило, в среде эксплуатации. В трактовке стандарта ISO/IEC 12207 приемоч-

ное тестирование, как вид тестирования, не включено в «Процесс тестирования», а

выполняется в рамках процессов «Поставка» и «Приемка заказчиком» (потребите-

лем) и связывается с процессом «Валидации».

Тестирование инсталляции (установочные испытания) выполняется в среде

эксплуатации (в рамках процесса «Инсталляция ПС») и относится к уровню сис-

темного тестирования. Включает тестирование процедур инсталляции ПС с внеш-

них носителей.

Иногда под приемочным тестированием (acceptance test) понимают предваритель-

ное тестирование объекта тестирования при его передаче от разработчика группе тестиро-

вания, выполняемое с целью определения пригодности объекта для тестирования [8].

Глава 7 307

Перед окончательным выпуском системы проводится Альфа и Бета тес-

тирование. Для этого система передается небольшой группе пользователей -

внутренних (Альфа) или внешних (Бета), которые эксплуатируют систему и ин-

формируют разработчика о выявленных проблемах. Обнаруженные отказы и де-

фекты свидетельствуют о качестве выполненного ранее тестирования.

Альфа и Бета тестирование подобны эксплуатационным испытаниям, вы-

полняемым на этапе опытной эксплуатации системы. Но, в отличие от них,

обычно проводятся для систем, разрабатываемых для широкого круга пользовате-

лей, а не для конкретного заказчика.

Эти виды тестирования не регламентируются планом тестирования и непо-

средственно не входят в процесс тестирования.

Регрессионное (regression test) и повторное (re-test) тестирование. Эти по-

нятия в литературе часто смешиваются, поскольку оба вида тестирования касаются

повторного выполнения тестов. Однако они имеют некоторые отличия. Повторное

тестирование выполняется на любом уровне тестирования для проверки внесенных

изменений, и не регламентируется планом тестирования. Регрессионное тестирова-

ние связано с развитием ПС и особенно широко применяется в итерационных мо-

делях разработки (для тестирования новых версий ПС). Оно заключается в повто-

рении подмножества ранее выполненных тестов (для того, чтобы убедиться в том,

что то, что ранее работало, еще работает), а также разработке новых тестов для

проверки правильности внесенных изменений. В отличие от повторного тестирова-

ния, регрессионное тестирование планируется. При его планировании решается

проблема отбора минимального набора регрессионных тестов [8].

7.2.3. Виды тестирования характеристик программной системы

По отношению к проверяемым характеристикам и целям качества любого

объекта системы можно выделить следующие виды тестирования.

Функциональное тестирование (называемое также тестированием на соот-

ветствие или тестирование корректности) направлено на проверку соответствия

наблюдаемого поведения системы (или отдельных элементов) спецификациям

(внешним и внутренним). Выполняется, как правило, в среде разработки по планам,

разработанным на основе спецификаций функциональных требований.

Цель функционального тестирования состоит в обнаружении несоответст-

вий между реальным поведением реализованных функций и исходными требова-

ниями, представленными в спецификации функций, и определении полноты функ-

ционального покрытия относительно спецификации функций. Выполняется на

уровнях модульного тестирования и тестирования ПО в целом. Функциональные

тесты могут быть получены по внешним спецификациям функций, проектной ин-

формации или прототипу ПО.

Тестирование безопасности (Security testing) заключается в проверке воз-

можности несанкционированного доступа к ПС. Выполняется путем моделирова-

ния возможных атак внешних пользователей (в том числе других ПС) с целью

«взломать» систему защиты.

Тестирование удобства применения (эргономичности) предназначено для

оценивания простоты применения и изучения системы конечными пользователями,

эффективности ее использования для решения задач пользователя и способности к

восстановлению при ошибках пользователя. Часто включает также тестирование

308 Глава 7

документации (on-line, справочной службы, подсистемы обучения).

Этот вид тестирования требует знания современных стандартов по эргономи-

ке, например, ISO 13407:1999 [16], а также согласованных с заказчиком требований

к пользовательскому интерфейсу. Применяется в рамках процесса анализа требова-

ний (тестирование прототипа), тестирования программных компонентов, реали-

зующих интерфейс, тестирования ПО и приемочных испытаний системы.

Тестирование технических характеристик. Это процесс поиска несоот-

ветствий программной системы целям качества (целевым требованиям), зафикси-

рованным во внешних спецификациях наряду с описанием ее функций.

Исходной посылкой для его выполнения является измеримость и принципи-

альная достижимость установленных целевых требований (к надежности, произво-

дительности, совместимости, конфигурации и др.). Эти виды тестирования получи-

ли названия, соответствующие целям тестирования, и обычно проводятся в рамках

тестирования системы в специально моделируемой среде, максимально прибли-

женной к среде эксплуатации, или в среде эксплуатации.

Тестирование на надежность. Этот вид тестирование рассматривают как

основное средство улучшения надежности, поскольку с ростом количества выяв-

ленных и устраненных дефектов надежность ПС растет. Тестирование на надеж-

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

пространства в соответствии с операционным профилем [17, 18]. Все отказы при

выполнении тестов регистрируются применительно к интервалам времени между

отказами (или моментам времени наступления отказов от начала тестирования).

Процесс возникновения отказов рассматривается как случайный (стохастический)

процесс (Марковский или Пуассоновский), а для количественной оценки достигну-

той надежности применяются модели роста надежности.

Тестирование производительности (Performance testing). Выполняется для

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

оптимизации производительности. Иногда подразделяется на следующие виды:

- нагрузочное тестирование (load testing) - проверка работоспособности ПС

при ожидаемых нормальных загрузках;

- тестирование на устойчивость (stress testing) - проверка работоспособно-

сти в нестандартных условиях (при чрезмерных и отсутствующих загрузках);

- тестирование объема (volume testing) - проверка внутрипрограммных или

системных ограничений, связанных, например, с большими массивами данных,

предельными объемами БД и другими характеристиками объема.

Тестирование конфигурации (Configuration testing). Выполняется для про-

верки работоспособности ПС в разных конфигурациях (операционных системах).

Сравнительное тестирование (Back-to-back testing). Вид тестирования, при

котором один и тот же набор тестов выполняется на двух реализованных версиях, а

результаты сравниваются. Особенно актуален в итерационных моделях разработки.

Тестирование восстановления (Recovery testing). Проводится для проверки

процедур восстановления системы после отказов.

Управляемая тестами разработка (Test-driven development) [19]. Подход к

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

Тесты исполняют роль некого прототипа модуля и заменителя спецификации тре-

бований. Подход применяется в экстремальном программировании (ХР) (глава 11).

Глава 7 309

7.3. Методы тестирования

7.3.1. Классификация и краткий обзор методов тестирования

Методы тестирования различаются подходами к проектированию тестов.

Традиционно методы тестирования разделяют на две категории - «черный

ящик» (без доступа к исходному коду) и «белый» ящик (с доступом к исходному

коду) [20, 21].

Более подробная классификация методов тестирования, основанная на под-

ходах к проектированию тестов, представлена на рисунке 7.3 и кратко описана ни-

же.

Классификация методов,

основанная на подходах к

проектированию тестов

Эвристи-

ческий

(Ad hoc)

Основанные

на

спецификации

Таблицы

решений

Тестирование

потока

управления

Предполо-

жение об

ошибках

Тестирование

по операцион-

ному профилю

Основанные

на коде

Методы

направленного

поиска ошибок

Основанные на

использовании

Основанные

на типе ПО

Основанные

на опыте и

интуиции

Функциональ-

ные

диаграммы

Эквивалент-

ное

разбиение

Анализ

граничных

значений

Разбиение

входного

пространства

на категории

Тестирование

переходов

между

состояниями

Тестирование

потоков

данных

Подсев

ошибок

Инженерия

надежности

Компонент-

ное

Тестирование

приложений

для Интернет

Тестирование

графического

интерфейса

Тестирование

объектно-

ориентиро-

ванных

программ

Тестирование

по формаль-

ным специ-

фикациям

Тестирование

по сценариям

Тестирование

согласован-

ности

протоколов

Тестирование

систем

реального

времени

Тестирование

критических

систем

Случайное

тестирование

Мутацион-

ное тести-

рование

Рис. 7.3. Классификация методов тестирования

310 Глава 7

1. Методы тестирования, основанные на опыте и интуиции.

Специализированное тестирование (Ad hoc). Это наиболее распространен-

ный (хотя и не считающийся систематическим) подход, при котором тесты разра-

батываются исходя из интуиции тестировщика и его опыта в тестировании подоб-

ных систем. Эффективность подхода полностью определяется мастерством тести-

ровщика. Подход не требует подробной спецификации функций ПО, но и не обес-

печивает оценивания полноты тестового покрытия. Развитием подхода можно счи-

тать «исследовательское тестирование» (exploratory testing), основные принципы

которого – совмещение изучения программного продукта с проектированием тес-

тов и их выполнением. Такое тестирование обычно осуществляется независимыми

тестировщиками применительно к завершенным программным продуктам. Пример

применения подхода рассмотрен в 7.3.2.

2. Методы, основанные на спецификации (или методы функционального

тестирования).

Эти методы широко известны и подробно описаны в литературе [2, 8, 9, 10,

22–29]. В традиционной классификации их относят к методам «черного ящика».

Они применяются для тестирования внешних и внутренних функций программы и

предполагают наличие спецификации (формальной или не формальной), исполь-

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

данных из множества входов (входного пространства) функций.

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

• таблицы решений;

• функциональные диаграммы;

• эквивалентное разбиение;

• анализ граничных значений;

• разбиение входного пространства на категории;

• тестирование переходов между состояниями;

• тестирование по формальным спецификациям.

Метод, использующий таблицы решений для проектирования тестов, был

предложен Дж.Гуденафом и С.Герхартом [22]. Каждая колонка такой таблицы

представляет комбинацию условий, которые могут существенно повлиять на вы-

полнение программы. Эти условия идентифицируются на основе анализа специфи-

каций. Затем определяется множество их возможных значений, и устанавливаются

ограничения относительно их совместимости. Таким образом, сокращается количе-

ство тестовых предикатов (например, ограничение может говорить о том, что, если

условие 1 выполняется, то ни условие 2, ни условие 3 не могут выполняться).

Второй метод, предложенный Б.Эльмендорфом и описанный Г.Майерсом, за-

ключается в преобразовании спецификации в функциональные диаграммы [21].

По этому методу вначале идентифицируется каждая отдельная функция, затем оп-

ределяются все причины, существенно влияющие на ее поведение, и все ответные

реакции (следствия). Следующий шаг состоит в построении графа (диаграммы),

связывающего комбинации причин с ожидаемыми реакциями на них. Далее для

каждого следствия, указанного на графе, определяются тестовые наборы путем пе-

ребора всех комбинаций причин, порождающих это следствие.

Хотя строгое соблюдение метода может обеспечить построение эффективных

тестов, он сложен в практическом применении для функционально сложных про-

Глава 7 311

грамм, поскольку с ростом числа причин усложняется граф причинно-

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

промежуточных узлов.

В методе эквивалентного разбиения [8, 23] множество значений входных

данных функции, образующих ее входное пространство, разбивается на набор под-

множеств таким образом, что в каждое подмножество попадают значения, эквива-

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

ошибок. Говорят, что все тесты, которые могут быть построены на основе эквива-

лентных значений, представляют один «класс эквивалентности», и для тестирова-

ния достаточно выбрать только самые эффективные из них. Более подробно метод

описан в п.7.3.3.

В методе анализа граничных значений, дополняющем предыдущий метод,

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

исходят из-за дефектов, связанных с обработкой предельных значений входов [23].

Подробнее метод описан в п.7.3.4.

Простое и ценное расширение этого метода – тестирование устойчивости,

когда тестовые данные выбираются также и вне области для тестирования отказо-

устойчивости программы к недопустимым входам.

Методы эквивалентного разбиения и анализа граничных значений считаются

базовыми методами функционального тестирования и должны применяться совме-

стно при проектировании набора тестов для каждого уровня тестирования.

В развитие этих методов был создан метод, основанный на спецификациях

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

входного пространства функций на определенные категории (category partition

method или CP-метод) [24]. Суть метода заключается в ряде последовательных де-

композиций функции, начиная с исходной функциональной спецификации, и кон-

чая отдельными деталями каждой тестируемой процедуры, и создании специфика-

ций тестов на основе выделения категорий информации о параметрах функции и

условий ее выполнения. Подробнее метод описан в п.7.3.5.

В методе тестирования переходов между состояниями программа (реали-

зующая функцию) представляется в виде модели, отражающей все возможные со-

стояния ее выполнения, переходы между этими состояниями, события, вызываю-

щие переходы, и дальнейшие действия по обработке данных, определяемые этими

переходами.

Описание спецификаций на формальном языке (имеющем точно определен-

ный синтаксис и семантику) позволяет автоматически строить по ним функцио-

нальные тесты и в то же время обеспечивает эталон для проверки результатов. Су-

ществует целый ряд методов генерации тестов по формальным спецификациям

[25-28].

Все упомянутые методы функционального тестирования относятся к «систе-

матическим» методам в отличие от случайных (стохастических) и статистических

методов.

При случайном тестировании входные данные для тестов выбираются слу-

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

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

случайную комбинацию действий с программой, пытаясь выявить области ее неус-

тойчивого функционирования.

312 Глава 7

3. Методы, основанные на анализе кода (или структурные).

В традиционной классификации структурные методы относят к методам «бе-

лого ящика». Согласно этим методам структура программы представляется в виде

направленного графа, в котором идентифицируются потоки управления или потоки

данных. Соответственно, методы делятся на две основные категории: тестирование

потока управления (путей) и тестирование потока данных. Методы этой категории

наиболее изучены и описаны в литературе [2, 20, 21, 29], поэтому рассматриваются

очень кратко.

В методах тестирования потока управления данные из входного простран-

ства выбираются таким образом, чтобы обеспечить максимальное покрытие кода.

Основные методы приведены ниже:

Тестирование строк. Выбираются данные, обеспечивающие выполнения

всех строк (операторов) программы. Этот метод дает самый слабый критерий по-

крытия, называемый «покрытие строк», и приемлем для программ, не содержащих

логических условий и циклов.

Тестирование ветвлений. Выбираются данные, обеспечивающие выполнение

путей, выделяемых в программе с помощью логических условий, принимающих

значения Истина и Ложь. В приведенном ниже примере для проверки ветвления

достаточно двух тестов (при A<B и при A ≥ B):

if (A<B) then

…

else

…

endif

Нужно заметить, что для удовлетворения критерия покрытия строк достаточ-

но было бы выполнить один (любой) из этих двух тестов.

Тестирование логических условий. Если ветвления в программе образуются в

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

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

ловий. Например, для полной проверки представленного ниже логического усло-

вия:

if (A<B and C = 1) then

…

else

…

endif

необходимо уже четыре теста (один - для случая, когда условие выполняется, и три

- для остальных случаев):

1) A < B C = 1

2) A < B C ≠ 1

3) A ≥ B C=1

4) A ≥ B C≠1

Этот метод дает наиболее полный критерий покрытия кода программы, кото-

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

критерия покрытия строк было бы достаточно одного теста, а для покрытия ветвле-

ний – двух.

Глава 7 313

Тестирование циклов. Тесты разрабатываются для проверки каждого цикла

при граничных значениях переменных цикла и внутри их границ (для тестирования

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

терий покрытия, называемый «все циклы».

В методе тестирования потока данных тестовые данные выбираются та-

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

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

метод требует большого количества тестов, поэтому на практике трассируются

только наиболее критичные значения переменных. Особый интерес, например,

представляют значения переменных, участвующих в операциях деления (необхо-

димо предотвращать возможность обращения делителя в 0!), условия и циклы,

выполнение которых зависит от значений переменных. Метод тестирования потока

данных может также применяться для поиска трудно обнаруживаемых ошибок

времени выполнения, связанных с использованием памяти.

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

обычно применяются на уровне модульного тестирования программы ее разработ-

чиком и чередуются с отладкой, хотя могут использоваться и в процессах V&V для

проверки критических программ.

Методы функционального и структурного тестирования должны рассматри-

ваться не как альтернативные, а как взаимодополняющие, поскольку используют

разные источники информации для построения тестов и предназначены для выяв-

ления разных типов ошибок.

4. Методы направленного поиска ошибок.

Эти методы используются для проектирования тестов, специально предна-

значенных для обнаружения ошибок определенных типов.

К основным методам этой категории относятся:

• предположение об ошибках (error guessing);

• подсев ошибок (error seeding) [30];

• мутационное тестирование (mutation testing) [30].

Согласно методу выдвижения предположений об ошибках на основании

«исторической» информации об ошибках, обнаруженных в подобных программах,

опыта тестировщика, а также каталогов известных ошибок, составляется список

возможных ошибок и ошибочных ситуаций. Примеры возможных типов ошибок

представлены в разных публикациях, в частности в [8]. Одним из «классических»

примеров применения метода является проверка деления на 0. В традиционной

классификации метод относится к категории методов «черного ящика».

В работе [31] рассмотрен подход к тестированию и отладке программ, напи-

санных на языке Java, основанный на анализе «шаблонов» (паттернов) типичных

ошибок. Основная его идея – учиться на чужих ошибках, чтобы не допускать соб-

ственных.

Методы подсева ошибок и мутационного тестирования предназначены для

проверки тщательности уже выполненного тестирования. В традиционной клас-

сификации они относятся к категории методов «белого ящика».

В методе подсева ошибок в код, протестированный на определенном наборе

тестов, специально вносится небольшое количество ошибок, а затем программа по-

вторно тестируется. Если при тестировании обнаруживаются не все внесенные