Home

Автор: Екатерина Курач

Написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

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

Но, как известно, полностью протестировать программу невозможно по следующим причинам:

1. Количество всех возможных комбинаций входных данных слишком велико, чтоб его можно было проверить полностью.
2. Количество всех возможных последовательностей выполнения кода программы также слишком велико, чтобы его можно было протестировать полностью.
3. Пользовательский интерфейс программы (включающий все возможные комбинации действий пользователя и его перемещений по программе) обычно слишком сложен для полного тестирования.

Т.е. написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

Характеристики хорошего теста:

• Существует обоснованная вероятность выявления тестом ошибки
• Набор тестов не должен быть избыточным
• Тест должен быть наилучшим в своей категории
• Он не должен быть слишком простым или слишком сложным

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

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

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

Случай использования состоит из некоторого множества сценариев: нормальный случай, расширения и исключительные ситуации. Для разработки тест кейсов на основе одного случая использования разрабатываются несколько сценариев, соответственно: Сценарий использования представляет собой оптимистический сценарий, который выбирается чаще других. В раздел Альтернативные пути могут быть включены несколько сценариев, которые отличаются от сценария использования в различных аспектах, однако остаются полноценными путями исполнения. В раздел Исключительные пути попадают те сценарии, которые приводят к возникновению ошибок. Каждый сценарий предусматривает действия, предпринимаемые действующим субъектом, и требует от системы отклика, который соответствует основной части тестового случая. Тестовый случай состоит из некоторого набора предусловий, стимулирующего воздействия (входные данные) и ожидаемого отклика.

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

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

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

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

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

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

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

1. Идентификация всех значений, которые вводятся действующими субъектами, содержащимися в модели случая использования
2. Выделение классов эквивалентности значений каждого типа входных данных
3. Построение таблиц, в которые помещен список комбинаций значений из различных классов эквивалентности
4. Построение тестовых случаев, в которых сочетаются одна перестановка значений с необходимыми внешними ограничениями

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

В таблице 1 показаны классы эквивалентности этих трех переменных.

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

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

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

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

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

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

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

Второй подход заключается в разработке тестовых случаев большого цикла (grand tour test cases), в котором каждый тестовый случай генерирует данные, которые служат входом для следующего тестового случая. По условиям такого подхода каждый тест переносит тестовые данные через весь жизненный цикл. Полученное при этом состояние базы данных используется в качестве входного для следующего теста. Этот метод особенно эффективен при тестировании жизненного цикла после того, как тестирование нижнего уровня позволило выявить большую часть дефектов, вызывающих отказы. Если выстроить тестовые случаи в соответствующую последовательность, то после успешного выполнения тестового случая 1 устанавливается такое состояние программы, которое ожидается как входное для тестового случая 2. Очевидная проблема в условиях очерченного подхода заключается в том, что неудачное выполнение тестового случая 1 оставляет программу в состоянии, которого мы не ожидали, в результате чего мы не можем выполнять прогон тестового случая 2 или даже вернуть программу в рабочее состояние.

Итак, при разработке тест кейсов на основе случаев использования процедура в общем-то ясна. Однако возникает другой вопрос — что необходимо подвергнуть тестированию? Какие аспекты функционирования системы? Рекомендуется проводить следующие виды тестирования:

• Тестирование на соответствие функциональным требованиям
• Проверка качественных системных атрибутов. Добротная организация разработок программного обеспечения предусматривает методы подтверждения всех системных «требований», включая и претензии на придание программному продукту особых качеств. Существуют два вида претензий, с которыми может столкнуться программа при разработке продукта. Первый вид претензий представляет интерес только для организаций, занимающейся разработкой программных продуктов. Например, утверждение, что «программный код допускает многократное использование». Второй тип претензий представляет интерес для пользователей системы. Например, утверждение о том, что система является более полной, нежели другие системы подобного класса, предлагаемые на текущий момент на рынке программных продуктов. Вполне понятно, что не все эти претензии могут подвергаться проверке через тестирование. Однако на это следует обратить внимание.
• Тестирование механизма развертывания системы
• Тестирование после развертывания системы. Естественное расширение тестирования механизма развертывания системы заключается в добавлении в тестируемый программный продукт функциональных средств самопроверки. Считается, что система «изнашивается» во времени по причине изменений, имеющих место в ее взаимодействии с окружением, примерно так же, как со временем изнашивается механическая система из-за трений между ее компонентами. По мере того, как устанавливаются все более новые версии стандартных драйверов и библиотек, несоответствия возрастают вместе с ростом вероятности возникновения отказов. Каждая новая версия dll-библиотеки привносит возможность появления новых областей нестыковки стандартных интерфейсов или появления состояния гонок между этой библиотекой и приложением. Функциональные средства самотестирования должны обеспечивать выполнение тестов, которые исследуют работу интерфейсов между этими программными продуктами.
• Тестирование взаимодействий окружения
• Тестирование системы безопасности

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

Литература:

1. Сэм Канер, Джек Фолк, Енг Кек Нгуен. Тестирование программного обеспечения. — Киев: Издательство «Диа Софт», 2001.—544 с.
2. Макгрейгор Джон, Сайкс Девид. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие. — Киев: ООО "ТИД «ДС»", 2002.—432 с.