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

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

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

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

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

Во втором подходе основой для построения тестов служит представление о способах использования продукта и о задачах, которые он решает. На основе более или менее формальной модели пользователя создаются случаи использования системы, по которым затем строятся собственно тестовые случаи. Случай использования (use case) описывает, как субъект использует систему, чтобы выполнить ту или иную задачу. Субъекты или актеры (actors) могут исполнять различные роли при работе с системой. Случаи использования могут описываться с различной степенью абстракции. Случаи использования не обязательно охватывают каждое требование. Можно конкретизировать случаи использования и расширять их в наборы более специфических случаев использования (пошаговое описание случая использования). В контексте конкретного случая использования можно определить один или большее число сценариев. Сценарий представляет конкретный экземпляр случая использования - путь в пошаговом описании случая использования. Каждый путь (сценарий) в случае использования должен быть протестирован (рис. 4.1).

Рис. 4.1. Тестирование случаев использования

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

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

Далее при построении тестовых случаев применялись оба подхода и при выполнении заданий необходимо действовать следующим образом:

• На основе требований определить случаи использования (use case)
• На основе каждого случая использования (use case) построить сценарии.
• Для каждого сценария разработать тестовые случаи (набор тестов).

Случаи использования (use cases)

Описание случая использования (use case) "подбор подшипников для оси"

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

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

Далее приводится пошаговое описание этого случая использования:

Приняли на склад первый подшипник (1-10)

Приняли на склад второй подшипник (11-20)

Поступила ось (21-26)

Подбираем первый подшипник для оси (27-30)

Подбираем второй подшипник для оси (31-34)

Завершение выдачи команд (35-39).