FSM coverage (Finite State Machine Coverage)

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

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

Basis Path testing

Цель тестирования базового пути - в отличии от D-D Path (Decision-to-decision path) получить полное покрытие тех путей, которые находятся между точками принятия решений (decisions points) с высоким бизнес-риском и высокой бизнес-ценностью, т.к. проверять все возможные пути обходится слишком дорого. Это гибрид branch testing и path testing

LCSAJ coverage

LCSAJ (linear code sequence and jump) «линейная последовательность кода и переход». Каждый LCSAJ представляет собой сегмент кода, который выполняется последовательно от начальной точки до конечной точки, а затем прерывает последовательный поток для передачи потока управления. Каждая строка кода имеет плотность (density), то есть количество раз, когда номер строки появляется в LCSAJ.

Один LCSAJ состоит из трех компонентов:

● Начало сегмента, который может быть ветвью или началом программы;

● Конец сегмента, который может быть концом ветви или концом программы;

● Конкретная целевая линия;

Его основное применение при динамическом анализе программного обеспечения, чтобы помочь ответить на вопрос «Сколько тестирования достаточно?». Динамический анализ программного обеспечения используются для измерения качества и эффективности тестовых данных программного обеспечения, где количественное определение выполняются в терминах структурных единиц кода при тестировании. В более узком смысле, LCSAJ является хорошо определенным линейным участком кода программы. При использовании в этом смысле, LCSAJ также называют JJ-путь (jump-to-jump path). 100% LCSAJ означает 100% Statement Coverage, 100% Branch Coverage, 100% procedure или Function call Coverage, 100% Multiple condition Coverage (в ISTQB говорится только о 100% Decision coverage).

Определенные метрики используются для проверки покрытия кода. Эти показатели могут помочь нам определить, достаточно ли тестирования или нет. Эти показатели называются коэффициентом эффективности тестирования (TER - Test Effectiveness Ratio):

● TER-1: количество операторов, выполненных с помощью тестовых данных, деленное на общее количество операторов;

● TER-2: количество ветвей потока управления, выполненных тестовыми данными, деленное на общее количество ветвей потока управления;

● TER-3: количество LCSAJ, выполненных тестовыми данными, деленное на общее количество LCSAJ;

Исследователи ссылаются на коэффициент покрытия путей длиной n LCSAJ как на коэффициент эффективности теста (TER) n + 2.

1. Data Flow Testing

Тестирование потока данных - это еще один набор методов / стратегий белого ящика, который связан с анализом потока управления, но с точки зрения жизненного цикла переменной. Переменные определяются, используются и уничтожаются, когда в них больше нет необходимости. Аномалии в этом процессе, такие как использование переменной без ее определения или после ее уничтожения, могут привести к ошибке. Рапс и Вьюкер, популяризаторы данного метода, писали: "Мы уверены, что, как нельзя чувствовать себя уверенным в программе без выполнения каждого ее оператора в рамках какого-то тестирования, так же не следует быть уверенным в программе без видения результатов использования значений, полученных от любого и каждого из вычислений".

Когда «поток данных» через информационную систему представлен графически, он известен как диаграмма потока данных (Data Flow Diagram). Она также используется для визуализации обработки данных. Но не нужно путать это с графом потока данных (Data Flow Graph), который используется в Data Flow Testing. Граф потока данных похож на граф потока управления тем, что показывает поток обработки через модуль. Дополнительно к этому, он детализирует определение, использование и уничтожение каждой из переменных модуля. Мы построим эти диаграммы и убедимся, что шаблоны определение-использование-уничтожение являются подходящими. Сначала мы проведем статический анализ. Под "статическим" мы имеем в виду, что мы исследуем диаграмму (формально через проверки или неформально беглыми просмотрами). Потом мы проведем динамические тесты модуля. Под "динамическими" мы понимаем, что мы создаем и исполняем тестовые сценарии.

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

● каждое "определение" прослеживается для каждого его "использования";

● каждое "использование" прослеживается из соответствующего ему "определения";

Чтобы сделать это, перечислим маршруты в модуле. Порядок выполнения такой же, как и в случае с тестированием потока управления: начинаем с точки входа в модуль, строим самый левый маршрут через весь модуль и заканчиваем на выходе из него. Возвращаемся в начало и идём по другому направлению в первом разветвлении. Прокладываем этот путь до конца. Возвращаемся в начало и идём по другому направлению во втором разветвлении, потом в третьем и т.д., пока не пройдем все возможные пути. Затем создадим хотя бы один тест для каждой переменной, чтобы покрыть каждую пару определение-использование.

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

● ~ - переменная еще не существует или предыдущий этап был последним

● d - определено, создано, инициализировано

● k - не определено, убито

● u - используется (c - использование вычислений; p - использование предикатов)

Таким образом, ~ d, du, kd, ud, uk, uu, k ~, u ~ являются вполне допустимыми комбинациями, когда ~ u, ~ k, dd, dk, kk, ku, d ~ являются аномалиями, потенциальными или явными ошибками. В настоящее время практически все они эффективно обнаруживаются компиляторами или, по крайней мере, IDE, и нам редко требуется выполнять статический анализ для обнаружения этих аномалий. То же самое относится и к динамическому анализу, который сфокусирован на исследовании / выполнении du пар - современные языки программирования снижают вероятность возникновения проблем, связанных с du. Так что в настоящее время такая проверка в основном не стоит усилий.

Источники:

● Software Testing Techniques

● Ли Копланд - “A Practitioner's Guide to Software Test Design”, Главы 10 и 11

● НОУ Интуит - Лекция 4: Тестирование программного кода (покрытия)

● Code Coverage Tutorial: Branch, Statement, Decision, FSM

● Statement, Branch, and Path Coverage Testing

● What is the difference between dd-path testing and basis path testing (both aims branch coverage)?

● Linear code sequence and jump

● What is LCSAJ Testing?

Доп. материал:

● dynamic analysis tools

● НОУ Интуит - Лекция 4: Метод MC/DC для уменьшения количества тестовых примеров при 3-м уровне покрытия кода + Анализ покрытия

Dynamic -> Black box

Все specification-based или Black Box testing techniques могут быть удобно описаны и систематизированы с помощью следующей таблицы:

Группа	Техника	Когда используется
Элементарные техники: ● сосредоточены на анализе входных / выходных параметров; ● можно комбинировать для лучшего покрытия; ● обычно не используют и не зависят от других методик;	Equivalence Partitioning	Входные и выходные параметры имеют большое количество возможных значений
	Boundary Value Analysis	Значения параметров имеют явные (например, четко определенные в документации) границы и диапазоны или неявные (например, известные технические ограничения) границы
Комбинаторные стратегии: ● объединяют возможные значения нескольких параметров ввода / вывода; ● могут использовать элементарные приемы для уменьшения количества возможных значений;	All Combinations	Количество возможных комбинаций входных значений достаточно мало, или каждая отдельная комбинация входных значений приводит к определенному выходному значению
	Pairwise Testing	Количество входных комбинаций чрезвычайно велико и должно быть сокращено до приемлемого набора кейсов
	Each Choice Testing	У вас есть функции, при которых скорее конкретное значение параметра вызывает ошибку, нежели комбинация значений
	Base Choice Testing	Вы можете выделить набор значений параметров, который имеет наибольшую вероятность использования
Продвинутые техники: ● помогают проанализировать Систему с точки зрения бизнес-логики, иерархических отношений, сценариев и т. д.; ● анализ основан на данных, организованных в таблицы, диаграммы и шаблоны; ● может полагаться на элементарные и комбинаторные методы для разработки тестовых примеров;	Decision Table Testing	Существует набор комбинаций параметров и их выходных данных, описываемых бизнес-логикой или другими правилами
	Classification Tree Method	У вас есть иерархически структурированные данные, или данные могут быть представлены в виде иерархического дерева
	State Transition Testing	В функциональности есть очевидные состояния, переходы которых регулируются правилами (например, потоки)
	Cause-Effect Graphing	Причины (входы) и следствия (выходы) связаны большим количеством сложных логических зависимостей
	Scenario Testing	В функционале есть четкие сценарии
Другие техники	Random Testing	Вам необходимо имитировать непредсказуемость реальных вводных данных, или функциональность имеет несистематические дефекты
	Syntax Testing	Функциональность имеет сложный синтаксический формат для входных данных (например, коды, сложные имена электронной почты и т. д.)

 

Эквивалентное разделение (Equivalence Partitioning (ISTQB/Myers 1979) / Equivalence Class Testing (Lee Copeland))

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

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

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

Правила нашей организации таковы:

● от 0 до 16​ - не принимаются;

● от 16 до 18​ - могут быть приняты только на неполный рабочий день;

● от 18 до 55​ - могут быть приняты как сотрудники на полный рабочий день;

● от 55 до 99​ - не принимаются;

Что в коде выглядит как:

● If (applicantAge >= 0 && applicantAge <=16)

○ hireStatus="NO";

● If (applicantAge >= 16 && applicantAge <=18)

○ hireStatus="PART";

● If (applicantAge >= 18 && applicantAge <=55)

○ hireStatus="FULL";

● If (applicantAge >= 55 && applicantAge <=90)

○ hireStatus="NO";

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

Теперь мы готовы начать тестирование? Вероятно, нет. Что насчет таких входных данных как 969, -42, FRED или &$#!? Должны ли мы создавать тестовые сценарии для некорректных входных данных? Для того, чтобы понять ответ, мы должны проверить подход, который пришел из объектно-ориентированного мира, названный "проектирование-по-контракту".

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

Например, если у нас есть модуль "openFile", что он обещает сделать? Открыть файл. Какие будут разумные предусловия для этого модуля?

● файл должен существовать,

● мы должны предоставить имя (или другую идентифицирующую информацию),

● файл должен быть "открываемым", т.е. он не может быть открытым в другом процессе,

● у нас должны быть права доступа к файлу и т.д.

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

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

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

Нужно ли нам делать проверку с такими входными значениями, как -42, FRED и &$#! @? Если мы используем проектирование-по-контракту и тестирование-по-контракту, то ответ "Нет". Если мы используем оборонительное проектирование и, поэтому, оборонительное тестирование, то ответ "Да". Спросите ваших проектировщиков, какой подход они используют. Если их ответом будет «контрактный» либо «оборонительный», то вы знаете, какой стиль тестирования использовать. Если они ответят "Хм?", то это значит, что они не думают о том, как взаимодействуют модули. Они не думают о предусловиях и постусловиях контрактов. Вам стоит ожидать, что интеграционное тестирование будет главным источником дефектов, будет более сложным и потребует больше времени, чем ожидалось.

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