Привет, Вы узнаете о том , что такое тест дизайн test design тестовое покрытие test coverage техники дест дизайна test design technics , Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое тест дизайн test design тестовое покрытие test coverage техники дест дизайна test design technics , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..

Тест дизайн (тестдизайн)– это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определенными ранее критериями качества и целями тестирования.

Test design [ISTQB Glossary of terms]: The process of transforming general testing objectives into tangible test conditions and test cases.

План работы над тест дизайном

• анализ имеющихся проектных артефактов: документация (спецификации, требования, планы), модели, исполняемый код и т.д.
• написание спецификации по тест дизайну (Test Design Specification)
• проектирование и создание тестовых случаев (Test Cases)

Роли, ответственные за тест дизайн

• Тест аналитик - определяет "ЧТО тестировать?"
• Тест дизайнер - определяет "КАК тестировать?"

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

Тестовое Покрытие (Test Coverage)

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

Если рассматривать тестирование как "проверку соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов", то именно этот конечный набор тестов и будет определять тестовое покрытие:

Чем выше требуемый уровень тестового покрытия, тем больше тестов будет выбрано, для проверки тестируемых требований или исполняемого кода.

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

Существуют следущие подходы к оценке и измерению тестового покрытия:

1. Покрытие требований (Requirements Coverage) - оценка покрытия тестами функциональных и нефункциональных требований к продукту путем построения матриц трассировки (traceability matrix).
2. Покрытие кода (Code Coverage) - оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей программного обеспечения.
3. Тестовое покрытие на базе анализа потока управления - оценка покрытия основанная на определении путей выполнения кода программного модуля и создания выполняемых тест кейсов для покрытия этих путей.

Различия:
Метод покрытия требований сосредоточен на проверке соответствия набора проводимых тестов требованиям к продукту, в то время как анализ покрытия кода - на полноте проверки тестами, разработанной части продукта (исходного кода), а анализ потока управления - на прохождении путей в графе или модели выполнения тестируемых функций (Control Flow Graph).

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

Покрытие требований (Requirements Coverage)

Расчет тестового покрытия относительно требований проводится по формуле:

Tcov = (Lcov/Ltotal) * 100%

где:
Tcov - тестовое покрытие
Lcov - количество требований, проверяемых тест кейсами
Ltotal - общее количество требований

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

Тесты не связанные с требованиями не имеют смысла. Требования, не связанные с тестами - это "белые пятна", т.е. выполнив все созданные тест кейсы, нельзя дать ответ реализовано данное требование в продукте или нет.

Для оптимизации тестового покрытия при тестировании на основании требований, наилучшим способом будет использование стандартных техник тест дизайна. Пример разработки тестовых случаев по имеющимся требованиям рассмотрен в разделе: "Практическое применение техник тест дизайна при разработке тест кейсов"

Покрытие кода (Code Coverage)

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

Tcov = (Ltc/Lcode) * 100%

где:
Tcov - тестовое покрытие
Ltc - кол-ва строк кода, покрытых тестами
Lcode - общее кол-во строк кода.

В настоящее время существует инструментарий (например: Clover), позволяющий проанализировать в какие строки были вхождения во время проведения тестирования, благодаря чему можно значительно увеличить покрытие, добавив новые тесты для конкретных случаев, а также избавиться от дублирующих тестов. Проведение такого анализа кода и последующая оптимизация покрытия достаточно легко реализуется в рамках тестирования белого ящика (white-box testing) при модульном, интеграционном и системном тестировании; при тестировании же черного ящика (black-box testing) задача становится довольно дорогостоящей, так как требует много времени и ресурсов на установку, конфигурацию и анализ результатов работы, как со стороны тестировщиков, так и разработчиков.

Тестовое покрытие на базе анализа потока управления

Тестирование потоков управления (Control Flow Testing) - это одна из техник тестирования белого ящика, основанная на определении путей выполнения кода программного модуля и создания выполняемых тест кейсов для покрытия этих путей. [1]

Фундаментом для тестирования потоков управления является построение графов потоков управления (Control Flow Graph), основными блоками которых являются:

• блок процесса - одна точка входа и одна точка выхода
• точка альтернативы - одна точка входа, две и более точки выхода
• точка соединения - две и более точек входа, одна точка выхода

Для тестирования потоков управления определены разные уровни тестового покрытия:

Уровень	Название	Краткое описание
Уровень 0	--	“Тестируй все что протестируешь, пользователи протестируют остальное” На английском языке это звучит намного элегантнее: “Test whatever you test, users will test the rest”
Уровень 1	Покрытие операторов	Каждый оператор должен быть выполнен как минимум один раз.
Уровень 2	Покрытие альтернатив [2] / Покрытие ветвей	Каждый узел с ветвлением (альтернатива) выполнен как минимум один раз.
Уровень 3	Покрытие условий	Каждое условие, имеющее TRUE и FALSE на выходе, выполнено как минимум один раз.
Уровень 4	Покрытие условий альтернатив	Тестовые случаи создаются для каждого условия и альтернативы
Уровень 5	Покрытие множественных условий	Достигается покрытие альтернатив, условий и условий альтернатив (Уровни 2, 3 и 4)
Уровень 6	“Покрытие бесконечного числа путей”	Если, в случае зацикливания, количество путей становится бесконечным, допускается существенное их сокращение, ограничивая количество циклов выполнения, для уменьшения числа тестовых случаев.
Уровень 7	Покрытие путей	Все пути должны быть проверены

Таблица 1. Уровни тестового покрытия

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

Литература

[1] A practitioner’s Guide to Software Test Design. Lee Copeland

[2] Стандартный глоссарий терминов, используемых в тестировании программного обеспечения Версия 2.0 (от 4 декабря 2008), Подготовлен ‘Glossary Working Party’ International Software Testing Qualifications Board

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

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

• Эквивалентное Разделение (Equivalence Partitioning - EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала - 0.
  
• Анализ Граничных Значений (Boundary Value Analysis - BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
  
• Причина / Следствие (Cause/Effect - CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как "Имя", "Адрес", "Номер Телефона" а затем, нажать кнопку "Добавить" - эта "Причина". Об этом говорит сайт https://intellect.icu . После нажатия кнопки "Добавить", система добавляет клиента в базу данных и показывает его номер на экране - это "Следствие".
  
• Предугадывание ошибки (Error Guessing - EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки.
  
• Исчерпывающее тестирование (Exhaustive Testing - ET) - это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.

Практическое применение техник тест дизайна (тестдизайна) при разработке тест кейсов

Многие знают что такое тест дизайн, но не все умеют его применять. Чтобы немного прояснить ситуацию, мы решили предложить Вашему вниманию последовательный подход к разработке тестовых случаев (тест кейсов), используя самые простейшие техники тест дизайна:

• Эквивалентное Разделение (Equivalence Partitioning), далее в тексте - EP

• Анализ Граничных Значений (Boundary Value Analysis), далее в тексте - BVA
• Предугадывание ошибки (Error Guessing), далее в тексте - EG
• Причина / Следствие (Cause/Effect), далее в тексте - CE

План разработки тест кейсов предлагается следующий:

1. Анализ требований.
2. Определение набора тестовых данных на основании EP, BVA, EG.
3. Разработка шаблона теста на основании CE.
4. Написание тест кейсов на основании первоначальных требований, тестовых данных и шагов теста.

Далее на примере, рассмотрим предложенный подход.

Пример:

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

Элемент	Тип элемента	Требования
Тип обращения	combobox	Набор данных: Консультация Проведение тестирования Размещение рекламы Ошибка на сайте * - на процесс выполнения операции приема заявок не влияет.
Контактное лицо	editbox	1. Обязательное для заполнения 2. Максимально 25 символов 3. Использование цифр и спец символов не допускается
Контактный телефон	editbox	Обязательное для заполнения Допустимые символы "+" и цифры "+" можно использовать только в начале номера Допустимые форматы: начинается с плюса - 11-15 цифр +31612361264 +375291438884 без плюса - 5-10 цифр, например: 0613261264 2925167
Сообщение	text area	1. Обязательное для заполнения 2. Максимальная длина 1024 символа
Отправить	button	Состояние: 1. По умолчанию - не активна (Disabled) 2. После заполнения обязательных полей становится активна (Enabled) Действия после нажатия 1. Если введенные данные корректны - отправка сообщения 2. Если введенные данные НЕ корректны - валидационное сообщение

Вариант использования (иногда его может и не быть):

1. Анализ требований

Читаем, анализируем требования и выделяем для себя следующие нюансы:

• какие из полей обязательные для заполнения?
• имеют ли поля ограничения по длине или по размерности (границы)?
• какие из полей имеют специальные форматы?

2.Определение набора тестовых данных

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

• в зависимости от того обязательное поле или нет, определим какие поля необходимо проверить на пустое значение, так как оно может вызывать ошибку (В результирующей таблице оранжевый цвет)
• т.к. исчерпывающее тестирование не представляется возможным из-за огромного числа всевозможных комбинаций значений, в первую очередь необходимо определить минимальный набор данных. Это можно сделать используя такие техники, как EP и BVA. (В результирующей таблице голубой цвет)
• На форме присутствует поле, имеющее составной тип (цифры используются совместно с символами), обладает специальным форматом данных и поэтому выделение тестовых данных для него - это достаточно трудоемкая задача. В пределах данной статьи ограничимся только простой проверкой форматов и основных требований описанных в форме приема заявок.
• По завершению генерации данных используя стандартные техники, можно добавить некоторое количество значений на основании личного опыта (техника EG) - это будет использование спец. символов, очень длинных строк, разных форматов данных, регистров в строках (Upper, Lowwer, Mixed cases), отрицательные и нулевые значения, кейворды Null - NaN - Infinity и т.д. Сюда можно включить все, что вы полагаете может вывести приложение из строя (В результирующей таблице фиолетовый цвет)

Примечание:

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

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

• Поле Тип обращения. Так как все данные входят в 1 класс эквивалентности, то есть не изменяют сам процесс выполнения приема заявки, берем любою (1-ю) позицию в листе с ожидаемым результатом ОК. Но т.к. реализовано поле как лист, имеет также смысл рассмотреть и граничные условия (техника BVA), т.е. берем первый и последний элементы. Итого: 1-я и последняя позиции в листе. Ожидаемый результат при использовании - ОК.
• Поле Контактное лицо. Это обязательное поле размером от 1 до 25 символов (включая границы). Проверка на обязательность добавляет к тестовым данным пустое значение. Проведем анализ граничных условий (BVA), получим набор: 0, 1, 2, 24, 25 и 26 символов. Пустое значение (0 символов) уже было добавлено при анализе обязательности поля для ввода, поэтому при BVA мы не будем добавлять его еще раз. (если его добавить второй раз, произойдет дублирование тестовых данных, которое не приведет к нахождению новых дефектов, а значит повторное добавление в домен не имеет смысла). В связи с тем, что значения 2 и 24 символа являются, с нашей точки зрения, некритичными, их можно не добавлять. В итоге получаем, что минимальный набор данных для тестирования поля - это строки 1 и 25 - ОК, и 0 (пустое значение), 26 символов - NOK.

• поле Контактный телефон состоит из нескольких частей: код страны, код оператора, номер телефон (который может быть составной и разделенный дефисами). Для определения правильного набора тестовых данных необходимо рассматривать каждую составную часть по-отдельности. Применяя BVA и EP, получим:

  • для номеров с плюсом
    По BVA получим номера с 10, 11, 12 и 14, 15, 16 цифрами, где 10 и 16 - NOK, а 11, 12, 14, 15 - OK
    Рассматривая полученные данные с позиции EP выделим, что 11, 12, 14, 15 входят в один класс эквивалентности. Поэтому при тестировании мы можем использовать любое из них, но так как 11 и 15 - это границы интервала, то на наш взгляд их пропускать нельзя. Следовательно мы можем уменьшить набор значений до двух, исключив 12 и 14, а оставив 11 и 15 для проверки граничных условий.
    Итого имеем:
    11 и 15 цифр - OK, (+12345678901, +987654321054321)
    10 и 16 цифр - NOK; (+1234567890, +9876543210654321)
  • для номеров без плюса:
    По BVA получим номера с 4, 5, 6 и 9, 10, 11 цифрами.
    Действуя аналогично примеру для номеров телефонов с плюсом, исключим значения 6 и 9, оставив 5 и 10.
    Итого имеем:
    5 и 10 цифр - OK, (54321, 0987654321)
    4 и 11 цифр - NOK; (4321, 98765432101)
• поле Сообщение. подбор данных проводим по аналогии с полем Контактное лицо. На выходе получаем значения: строки 1 и 1024 - ОК, и 1025 символов - NOK.

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

3. Разрабатываем шаблон теста

На основании техники CE и, по возможности, имеющихся вариантов использования (Use case) создадим шаблон планируемого теста. Данный документ будет представлять собой шаги и ожидаемые результаты теста, но без конкретных данных, которые подставляются на следующем этапе разработки тест кейсов.

Пример шаблона тест кейса

Действие	Ожидаемый результат
1. Открываем форму отправки сообщения	Форма открыта Все поля по умолчанию пусты Обязательные поля помечены - * Кнопка "Отправить" не активна
2. Заполняем поля формы: Тип обращения Контактное лицо Контактный телефон Сообщение	Поля заполнены Кнопка "Отправить" - активна (Enabled)
3. Нажимаем кнопку "Отправить"	Если введенные данные корректны - Сообщение "Заявка отправлена"выведено на экран. Новая заявка появилась в списке на странице "Заявки". Если введенные данные НЕ корректны -; Валидационное сообщение со всеми ошибками выведено на экран. Заявка НЕ появилась в списке на странице "Заявки".

4. Написание тест кейсов на основании первоначальных требований, тестовых данных и шаблона теста

После того, как тестовые данные и шаги теста готовы приступаем непосредственно к разработке тест кейсов. Здесь нам помогут такие методы комбинирования как:

• Последовательный перебор. Представляет собой перебор всех возможных комбинаций имеющихся значений. Таким образом получается, что количество тест кейсов будет равно произведению количества вариантов тестовых данных для каждого поля. Для нашего конкретного примера мы получим 1170 тест кейсов.
• Попарный перебор (Pairwise Testing). Зачастую, сбои вызывают не сложное сочетание всех параметров, а сочетание лишь пары параметров. Техника попарного перебора, позволяет создать тестовые наборы, комбинирующие данные из двух полей. Благодаря этому, количество полученных на выходе тест кейсов в разы меньше, чем при комбинировании того же набора данных припоследовательном переборе. Отметим также, что в данный момент существует несколько алгоритмов генерации комбинаций для попарного тестирования: Orthogonal Arrays Testing, All pairs, IPO (In-Parameter Order). Так например, при использовании техники All Pairs в нашем конкретном случае мы получим всего 118 тест кейса. (примеры сравнения эффективности разных алгоритмов генерации можно найти здесь)

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

Примечание:

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

Пример позитивного тест кейса (все поля OK):

Действие	Ожидаемый результат
1. Открываем форму отправки сообщения	Форма открыта Все поля по умолчанию пусты Обязательные поля помечены - * Кнопка "Отправить" не активна
2. Заполняем поля формы: Тип обращения = Консультация Контактное лицо = ываываываывсч Контактный телефон = +7-916-222-22-22 Сообщение	Поля заполнены Кнопка "Отправить" - активна (Enabled)
3. Нажимаем кнопку "Отправить"	Сообщение "Заявка отправлена"выведено на экран. Новая заявка появилась в списке на странице "Заявки".

Пример негативного тест кейса (поле Контактное лицо - NOK):

Действие	Ожидаемый результат
1. Открываем форму отправки сообщения	Форма открыта Все поля по умолчанию пусты Обязательные поля помечены - * Кнопка "Отправить" не активна
2. Заполняем поля формы: Тип обращения = Консультация Контактное лицо = @#$%^&;.?,>|\/№"!()_{}[<~ Контактный телефон = (222)333-33-33 Сообщение = ывапроеноен(...)кепк - 1024 символа	Поля заполнены Кнопка "Отправить" - активна (Enabled)
3. Нажимаем кнопку "Отправить"	Валидационное сообщение со всеми ошибками выведено на экран: "В поле "Контактное лицо" запрещено использование цифр и спец. символов." Заявка НЕ появилась в списке на странице "Заявки".

Тестовое Покрытие (Test Coverage)

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

Если рассматривать тестирование как "проверку соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов", то именно этот конечный набор тестов и будет определять тестовое покрытие:

Чем выше требуемый уровень тестового покрытия, тем больше тестов будет выбрано, для проверки тестируемых требований или исполняемого кода.

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

Существуют следущие подходы к оценке и измерению тестового покрытия:

1. Покрытие требований (Requirements Coverage) - оценка покрытия тестами функциональных и нефункциональных требований к продукту путем построения матриц трассировки (traceability matrix).
2. Покрытие кода (Code Coverage) - оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей программного обеспечения.
3. Тестовое покрытие на базе анализа потока управления - оценка покрытия основанная на определении путей выполнения кода программного модуля и создания выполняемых тест кейсов для покрытия этих путей.

Различия:
Метод покрытия требований сосредоточен на проверке соответствия набора проводимых тестов требованиям к продукту, в то время как анализ покрытия кода - на полноте проверки тестами, разработанной части продукта (исходного кода), а анализ потока управления - на прохождении путей в графе или модели выполнения тестируемых функций (Control Flow Graph).

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

Покрытие требований (Requirements Coverage)

Расчет тестового покрытия относительно требований проводится по формуле:

Tcov = (Lcov/Ltotal) * 100%

где:
Tcov - тестовое покрытие
Lcov - количество требований, проверяемых тест кейсами
Ltotal - общее количество требований

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

Тесты не связанные с требованиями не имеют смысла. Требования, не связанные с тестами - это "белые пятна", т.е. выполнив все созданные тест кейсы, нельзя дать ответ реализовано данное требование в продукте или нет.

Для оптимизации тестового покрытия при тестировании на основании требований, наилучшим способом будет использование стандартных техник тест дизайна. Пример разработки тестовых случаев по имеющимся требованиям рассмотрен в разделе: "Практическое применение техник тест дизайна при разработке тест кейсов"

Покрытие кода (Code Coverage)

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

Tcov = (Ltc/Lcode) * 100%

где:
Tcov - тестовое покрытие
Ltc - кол-ва строк кода, покрытых тестами
Lcode - общее кол-во строк кода.

В настоящее время существует инструментарий (например: Clover), позволяющий проанализировать в какие строки были вхождения во время проведения тестирования, благодаря чему можно значительно увеличить покрытие, добавив новые тесты для конкретных случаев, а также избавиться от дублирующих тестов. Проведение такого анализа кода и последующая оптимизация покрытия достаточно легко реализуется в рамках тестирования белого ящика (white-box testing) при модульном, интеграционном и системном тестировании; при тестировании же черного ящика (black-box testing) задача становится довольно дорогостоящей, так как требует много времени и ресурсов на установку, конфигурацию и анализ результатов работы, как со стороны тестировщиков, так и разработчиков.

Тестовое покрытие на базе анализа потока управления

Тестирование потоков управления (Control Flow Testing) - это одна из техник тестирования белого ящика, основанная на определении путей выполнения кода программного модуля и создания выполняемых тест кейсов для покрытия этих путей. [1]

Фундаментом для тестирования потоков управления является построение графов потоков управления (Control Flow Graph), основными блоками которых являются:

• блок процесса - одна точка входа и одна точка выхода
• точка альтернативы - одна точка входа, две и более точки выхода
• точка соединения - две и более точек входа, одна точка выхода

Для тестирования потоков управления определены разные уровни тестового покрытия:

Уровень	Название	Краткое описание
Уровень 0	--	“Тестируй все что протестируешь, пользователи протестируют остальное” На английском языке это звучит намного элегантнее: “Test whatever you test, users will test the rest”
Уровень 1	Покрытие операторов	Каждый оператор должен быть выполнен как минимум один раз.
Уровень 2	Покрытие альтернатив [2] / Покрытие ветвей	Каждый узел с ветвлением (альтернатива) выполнен как минимум один раз.
Уровень 3	Покрытие условий	Каждое условие, имеющее TRUE и FALSE на выходе, выполнено как минимум один раз.
Уровень 4	Покрытие условий альтернатив	Тестовые случаи создаются для каждого условия и альтернативы
Уровень 5	Покрытие множественных условий	Достигается покрытие альтернатив, условий и условий альтернатив (Уровни 2, 3 и 4)
Уровень 6	“Покрытие бесконечного числа путей”	Если, в случае зацикливания, количество путей становится бесконечным, допускается существенное их сокращение, ограничивая количество циклов выполнения, для уменьшения числа тестовых случаев.
Уровень 7	Покрытие путей	Все пути должны быть проверены

Таблица 1. Уровни тестового покрытия

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

Литература

[1] A practitioner’s Guide to Software Test Design. Lee Copeland

[2] Стандартный глоссарий терминов, используемых в тестировании программного обеспечения Версия 2.0 (от 4 декабря 2008), Подготовлен ‘Glossary Working Party’ International Software Testing Qualifications Board

Выводы из данной статьи про тест дизайн test design тестовое покрытие test coverage техники дест дизайна test design technics указывают на необходимость использования современных методов для оптимизации любых систем. Надеюсь, что теперь ты понял что такое тест дизайн test design тестовое покрытие test coverage техники дест дизайна test design technics и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.