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

Лекция №3 Методы подготовки и использования тестовых наборов данных Тесты, тест-кейсы При организации динамического тестирования, т.е. тестирования с активацией разрабатываемой программы, одним из ключевых вопросов оказывается определение перечня входных воздействий на программу (или её часть), с указанием желаемой реакции. Или иными словами — подготовка тесткейсов. Тест-кейс — набор входных данных, условий выполнения и ожидаемых результатов, разработанный с целью проверки того или иного свойства или поведения программного средства. Под тест-кейсом также может пониматься соответствующий документ, представляющий формальную запись тест-кейса. Сам термин представляет собой фактически заимствование из английского языка и вместо него может быть использован перевод: тестовый вариант или тестовый случай. Спецификацией тест-кейса является документ, описывающий его, и содержащий:  цель;  входные данные и/или условия;  выходные данные/ожидаемые результаты. Конкретным тестом оказывается набор из одного или нескольких тест-кейсов. Приведённые выше термины применимы как для тестов, выполняемых вручную, так и для автоматизированных. Цель написания тест-кейсов Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, эффективность такого подхода варьируется в очень широком диапазоне в зависимости от множества факторов). Наличие же тест-кейсов позволяет:  Структурировать и систематизировать подход к тестированию (без чего крупный проект почти гарантированно обречён на провал).  Вычислять метрики тестового покрытия и принимать меры по его увеличению (тест-кейсы здесь являются главным источником информации, без которого существование подобных метрик теряет смысл).  Отслеживать соответствие текущей ситуации плану (сколько примерно понадобится тест-кейсов, сколько уже есть, сколько выполнено из запланированного на данном этапе количества и т.д.).  Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками (тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем это отражено в требованиях).  Хранить информацию для длительного использования и обмена опытом между сотрудниками и командами (или как минимум — не пытаться удержать в голове сотни страниц текста).  Проводить регрессионное тестирование и повторное тестирование (которые без тест-кейсов было бы вообще невозможно выполнить).  Повышать качество требований (ведь по сути написание тест-кейса являет собой одну из техник тестирования требований к программному продукту).  Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту. Жизненный цикл тест-кейса Период существования тест-кейса представляет собой набор состояний, в которых он может находится.  Создан (new) — типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания.  Запланирован (planned, ready for testing) — в этом состоянии тест-кейс находится, когда он или явно включён в план ближайшей итерации тестирования, или как минимум готов для выполнения.  Не выполнен (not tested) — в некоторых системах управления тесткейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.  Выполняется (work in progress) — если тест-кейс требует длительного времени на выполнение, он может быть переведён в это состояние для подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний — «провален», «пройден успешно» или «заблокирован».  Пропущен (skipped) — бывают ситуации, когда выполнение тест-кейса отменяется по соображениям нехватки времени или изменения логики тестирования.  Провален (failed) — данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одному шагу тест-кейса не совпадает с фактическим результатом. Если в процессе выполнения тесткейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидаемыми результатами, тест-кейс считается пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся отчёт о дефекте).  Пройден успешно (passed) — данное состояние означает, что в процессе выполнения тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и фактических результатов его шагов.  Заблокирован (blocked) — данное состояние означает, что по какой-то причине выполнение тест-кейса невозможно (как правило, такой причиной является наличие дефекта, не позволяющего реализовать некий пользовательский сценарий).  Закрыт (closed) — очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В данное состояние в некоторых системах управления тест-кейс переводят, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия с ним завершены.  Требует доработки (not ready) — как видно из схемы, в это состояние (и из него) тест-кейс может быть переведён в любой момент времени, если в нём будет обнаружена ошибка, если изменятся требования, по которым он был написан, или наступит иная ситуация, не позволяющая считать тест-кейс пригодным для выполнения и перевода в иные состояния. Рисунок 1 – Жизненный цикл (набор состояний) тест-кейса Стоит отметить, что для тест-кейса описанное выше носит общий рекомендательный характер, рассматривается скорее как разрозненный набор со- стояний (а не строгий жизненный цикл) и может сильно отличаться в разных компаниях (в связи с имеющимися традициями и/или возможностями систем управления тест-кейсами). Атрибуты тест-кейса Как уже было сказано выше, существует спецификация тест-кейса которая представляет собой к формальную запись тест-кейса в виде технического документа. Эта запись имеет общепринятую структуру, компоненты которой называются атрибутами (полями) тест-кейса. В зависимости от инструмента управления тест-кейсами внешний вид их записи может немного отличаться, могут быть добавлены или убраны отдельные поля, но концепция остаётся неизменной. Рассмотрим данные атрибуты. Идентификатор (identifi er) представляет собой уникальное значение, позволяющее однозначно отличить один тест-кейс от другого и используемое во всевозможных ссылках. Приоритет (priority) показывает важность тест-кейса. Основная задача этого атрибута — упрощение распределения внимания и усилий команды (более высокоприоритетные тест-кейсы получают их больше), а также упрощение планирования и принятия решения о том, чем можно пожертвовать в некоей форс-мажорной ситуации, не позволяющей выполнить все запланированные тест-кейсы. Связанное с тест-кейсом требование (requirement) показывает то основное требование, проверке выполнения которого посвящён тест-кейс (основное — потому, что один тест-кейс может затрагивать несколько требований). Модуль и подмодуль приложения (module and submodule) указывают на части приложения, к которым относится тест-кейс, и позволяют лучше понять его цель. Большие и сложные проекты чаще всего оказывается невозможно «охватить» целиком. В таком случае они делятся командой на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули). Как правило, иерархия модулей и подмодулей создаётся как единый набор для всей проектной команды, чтобы исключить путаницу из-за того, что разные люди будут использовать разные подходы к такому разделению или даже просто разные названия одних и тех же частей приложения. Заглавие (суть) тест-кейса (title) призвано упростить и ускорить понимание основной идеи (цели) тест-кейса без обращения к его остальным атрибутам. Именно это поле является наиболее информативным при просмотре списка тест-кейсов. Исходные данные, необходимые для выполнения тест-кейса (precondition, preparation, initial data, setup), позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса. Шаги тест-кейса (steps) описывают последовательность действий, которые необходимо реализовать в процессе выполнения тест-кейса. Ожидаемые результаты (expected results) по каждому шагу тест-кейса описывают реакцию приложения на действия, описанные в поле «шаги тесткейса». Номер шага соответствует номеру результата. Создание тест-кейса Как уже было сказано в более ранних лекциях: тестирование является одним из основных методов измерения качества программ. Но при этом, за счёт обратной связи, процесс тестирования (или иначе – процесс обнаружения ошибок) оказывается так же методом изменения качества программ. С одной стороны факт обнаружения ошибки снижает показатель качества, с другой – активирует процессы изменения продукта для устранения ошибки и (возможно) повышения качества. Качество продукта представляет собой некую ценность для конечного пользователя. При создании тест-кейса для тестирования очередного объекта в программном продукте тестировщик фактически отвечает на следующие вопросы (помня при этом о качестве как ценности): 1) Что это за объект? 2) Кому и зачем он важен (и насколько важен)? 3) Как он обычно используется? 4) Как он может сломаться, т.е. начать работать неверно? Ответы на первый и второй вопросы представляют собой описание цели тест-кейса. Ответы на третий вопрос позволяют создать позитивные тесты. Ответы на четвёртый вопрос позволяют создать негативные тесты. Позитивное и негативное тестирование Позитивное тестирование (positive testing) направлено на исследование приложения в ситуации, когда все действия выполняются строго по инструкции без каких бы то ни было ошибок, отклонений, ввода неверных данных и т.д. Если позитивные тест-кейсы завершаются ошибками, это тревожный признак — приложение работает неверно даже в идеальных условиях (и можно предположить, что в неидеальных условиях оно работает ещё хуже). Для ускорения тестирования несколько позитивных тест-кейсов можно объединять (например, перед отправкой заполнить все поля формы верными значениями) — иногда это может усложнить диагностику ошибки, но существенная экономия времени компенсирует этот риск. Негативное тестирование (negative testing, invalid testing) — направлено на исследование работы приложения в ситуациях, когда с ним выполняются (некорректные) операции и/или используются данные, потенциально приводящие к ошибкам (классика жанра — деление на ноль). Поскольку в реальной жизни таких ситуаций значительно больше (пользователи допускают ошибки, злоумышленники осознанно «ломают» приложение, в среде работы приложения возникают проблемы и т. д.), негативных тест-кейсов оказывается значительно больше, чем позитивных (иногда — в разы или даже на порядки). В отличие от позитивных негативные тест-кейсы не стоит объединять, т. к. подобное решение может привести к неверной трактовке поведения приложения и пропуску (необнаружению) дефектов. Классы эквивалентности и граничные условия Как для позитивного, так и для негативного тестирования необходимо подготовить тестовые наборы (тестовые множества) – это множество тестовых вариантов. Тестовый вариант – это пара вида: (набор входных значений/воздействий; набор корректных выходных значений/реакций). Одной из максим тестирования ПО является невозможность получения гарантий отсутствия ошибок в программе. Следствием этого оказывается невозможность исчерпывающего тестирования программы в смысле построения исчерпывающего тестового набора. В общем случае он оказывается либо бесконечным, либо конечным, но настолько большим, что строить и выпол- нять тестирование на его основе неэффективно по экономическим и временным соображениям. Как следствие, для построение эффективного тестового множества, которое позволяет максимизировать вероятность обнаружения ошибок, сопровождается анализом как структуры программы, так и требований программных спецификаций. Тестирование может осуществляться как методом «чёрного ящика», так и методом «белого ящика». При тестировании методом «чёрного ящика» выполняется подготовка следующих групп тестов.  Для тестирования классов эквивалентностей. Классы эквивалентности позволяют вместо большого числа тестов использовать их небольшое подмножество. Каждый тест представляет собой набор тестов, на которых программа ведёт себя одинаково. Существует два основных типа классов эквивалентностей: o класс корректных тестовых случаев, отражающих типичную «нормальную» ситуацию; o класс тестов, содержащих ненормальную ситуацию, т.е. описывающих ситуацию, которой быть не должно.  Для тестирования граничных значений.  Для анализа причинно-следственных связей. Эти тесты применяются для программ, в которых взаимодействуют объекты.  Для тестирования тех утверждений, которые приводятся в спецификациях. Для получения эталонных значений, с которыми сравнивается поведение/результаты работы программы могут быть использованы следующие способы:  использование справочников;  вычисление вручную;  использование результатов другой, доверенной программы. Рассмотрим более подробно построение тестового набора для классов эквивалентности и граничных условий. Пусть есть функция проверки корректности ввода имени пользователя. Требования к входной строке следующие:  длина строки от 3 до 21 символа;  строка может состоять из: цифр, знаков нижнего подчёркивания, символов латинского алфавита в нижнем и верхнем регистрах. Начнём с длины строки. Из условий мы можем описать три класса эквивалентности. 1. Длина от 0 до 3 символов – недопустимое значение. 2. Длина от 3 до 21 символа включительно – допустимое значение. 3. Длина более 21 символа – недопустимое значение. Несмотря на то, что классы эквивалентности №1 и №3 описывают недопустимые значения длины, они разделены, т.к. на уровне кода проверка принадлежности длины к этим классам осуществляется различными операторами. При этом мы получаем следующие граничные значения:  ноль – минимально возможное значение длины строки вообще;  2 – максимальная недопустимая длина строки, для проверки которой используется оператор “<” (нижняя граница).  3 – минимальная допустимая длина строки;  21 – максимальная допустимая длина строки;  22 – минимальная допустимая длина строки, для проверки которой используется оператор “>” (верхняя граница). В итоге получим следующий тестовый набор для проверки длины: Строка Результат Пояснение тестирования Пустая строка Негативный Строка недопустимой длины – специальное значение AB Негативный Строка недопустимой длины по нижней границе ABC Позитивный Строка допустимой длины по нижней границе 1234567890_1234567890 Позитивный Строка допустимой длины по верхней границе 1234567890_1234567890A Негативный Строка недопустимой длины по верхней границе Для проверки на наличие недопустимых символов проще сформировать буквальный перечень допустимых символов: [«0»...«9»; «_»; «a»…«z»; «A»…«Z»]. Если символ строки не будет содержаться в этом массиве, то он будет считаться недопустимым. Выбранный способ определения классов эквивалентности не даёт нам граничных значений. Поэтому число тестов для проверки принадлежности к каждому из классов определяется требованиями к критичности приложения. Конечно, если у нас нет никакой дополнительной информации, которая позволяет выделить определённые значения в качестве граничных. Таким образом, к тестовому набору, описанному выше можно добавить следующую пару: Строка Результат Пояснение тестирования @#$ Негативный Строка допустимой длины, но с недопустимыми символами Использование классов эквивалентности и граничных условий позволяет уменьшить число тестовых вариантов в случае, если идёт тестирование по единственному критерию. Однако в ситуации, когда входные условия/значения описываются некоторым перечнем параметров (критериев), возникает задача учёта различных сочетаний значений параметров из этого перечня. Доменное тестирование Доменное тестирование (domain analysis, domain testing) — техника тестирования на основе классов эквивалентности и граничных условий, позволяющая эффективно создавать тест-кейсы, затрагивающие несколько параметров (переменных) одновременно (в том числе с учётом взаимозависимости этих параметров). Данная техника также описывает подходы к выбору минимального множества показательных тест-кейсов из всего набора возможных тест-кейсов. Одним их эффективных вариантов представления комбинаций параметров является использование таблицы. Рассмотрим одну из методик составления таблицы комбинаций. Пусть число параметров, комбинации которых нужно учесть, равно четырём. Так же для краткости изложения пусть каждый параметр характеризуется лишь двумя значениями. 1) В начале учтём комбинации значений первых двух параметров. Получим таблицу следующего вида: Таблица 1. Комбинации значений первых двух параметров Параметр2. Значение1 Параметр2. Значение2 Параметр1. Значение1 + + Параметр1. Значение2 + + На пересечении строк и столбцов можно отмечать необходимость выполнения проверки (здесь – «+») или её отсутствие, приоритет проверки, отдельные значения параметров, ссылки и т. д. Далее добавим третий параметр: Таблица 2. Комбинации значений первых трёх параметров Пар#2 – Зн#1 Пар#3 – Зн#1 Пар#3 – Зн#2 Пар#2 – Зн#2 Пар#1 – Зн#1 + + Пар#1 – Зн#2 – – Пар#1 – Зн#1 + + Пар#1 – Зн#2 + + И наконец, четвёртый параметр. Чтобы таблица равномерно увеличивалась по высоте и ширине, удобно добавлять каждый последующий параметр попеременно — то как столбец, то как строку. Третий параметр мы добавили как столбец, четвёртый добавим как строку. Таблица 3. Комбинации значений четырёх параметров Пар#4 – Зн#1 Пар#4 – Зн#2 Пар#2 – Зн#1 Пар#2 – Зн#2 Пар#2 – Зн#1 Пар#2 – Зн#2 Пар#3 – Зн#1 Пар#1 – Зн#1 Пар#1 – Зн#2 Пар#3 – Зн#2 Пар#1 – Зн#1 Пар#1 – Зн#2 Такое представление позволяет очень легко увидеть комбинации значений параметров, которые необходимо подвергнуть тестированию. Вместо знаков «+» в ячейки можно поставить ссылки на другие таблицы (хотя иногда все данные совмещают в одной таблице), в которых будут представлены классы эквивалентности и граничные условия для каждого выбранного случая. Комбинаторные техники или комбинаторное тестирование Видно, что при большом числе параметров и их значений подобная таблица может иметь сотни строк и столбцов. И число комбинаций может оказаться слишком большим. В таких случаях можно прибегнуть к одной из комбинаторных техник тестирования, которые позволяют выбрать подходящий набор комбинаций тестовых данных для достижения установленного уровня тестового покрытия в случае, когда проверка всех возможных наборов значений тестовых данных невозможна за имеющееся время. Попарное тестирование (pairwise testing) — техника тестирования, в которой тест-кейсы строятся по принципу проверки пар значений параметров (переменных) вместо того, чтобы пытаться проверить все возможные комбинации всех значений всех параметров. Эта техника является частным случаем N-комбинационного тестирования (n-wise testing) и позволяет существенно сократить трудозатраты на тестирование (а иногда и вовсе сделать возможным тестирование в случае, когда количество «всех комбинаций всех значений всех параметров» измеряется миллиардами). Тестирование с выбором значений-представителей (each choice testing) — тестирование, при котором по одному значению из каждого набора тестовых данных должно быть использовано хотя бы в одном тест-кейсе. Тестирование с выбором базового набора значений (base choice testing) — тестирование, при котором выделяется набор значений (базовый набор), который используется для проведения тестирования в первую очередь, а далее тест-кейсы строятся на основе выбора всех базовых значений, кроме одного, которое заменяется значением, не входящим в базовый набор. Литература 1) Тестирование программного обеспечения. Базовый курс / С. С. Куликов. — Минск: Четыре четверти, 2017. — 312 с.