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

Разбить на страницы

Показывать лекцию целиком

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

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

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

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

Во втором подходе основой для построения тестов служит представление о способах использования продукта и о задачах, которые он решает. На основе более или менее формальной модели пользователя создаются случаи использования системы, по которым затем строятся собственно тестовые случаи. Случай использования (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).

Пошаговое описание случая использования

Пошаговое описание приведено на рис. 4.2.

(рис 4.2) Пример use case

Список альтернативных путей

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

3, 11 - анализ статуса склада:

3.a, 11.a - подшипник в манипуляторе.

3.b, 11.b - склад свободен.

3.c, 11.c - ошибочное состояние.

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

8, 16, 22, 24, 26 - получение сообщения о выполнении команды:

8.a, 16.a, 22.a, 24.a, 26.a - нет склада.

8.b, 16.b, 22.b, 24.b, 26.b - нет сообщения.

8.с, 16.c, 22.c, 24.c, 26.c - команда выполнена с ошибкой.

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

Спецификация тестового случая №1

Состояние окружения (входные данные):

Статус склада ( StoreStat=32 ). Пришел подшипник.

Статус обмена с терминалом подшипника ( 0 - есть подшипник) и его параметры ( RollerPar="0 NewUser Depot1 123456 1 12 1 1" ).

Статус обмена с терминалом оси ( 1 - нет оси) и ее параметры ( AxlePar="1 NewUser Depot1 123456 1 0 12 12" ).

Статус команды ( CommandStatus=0 ). Команда успешно принята.

Сообщение от склада ( StoreMessage=1 ). Команда успешно выполнена.

Ожидаемая последовательность событий (выходные данные):

Система запрашивает статус склада (вызов функции GetStoreStat ) и получает 32.

Система запрашивает параметры подшипника (вызов функции GetRollerPar ) и получает 0 NewUser Depot1 123456 1 12 1 1.

Система запрашивает параметры оси (вызов функции GetAxlePar ) и получает 1 NewUser Depot1 123456 1 0 12 12.

Система добавляет в очередь команд склада на последнее место команду SendR (получить из приемника в ячейку) (вызов функции SendStoreCom ) и получает сообщение о том, что команда успешно принята - 0.

Система запрашивает склад о результатах выполнения команды (вызов функции GetStoreMessage ) и получает сообщение о том, что команда успешно выполнена - 1.

Система запрашивает статус склада (вызов функции GetStoreStat ) и получает 32.

Система запрашивает параметры подшипника (вызов функции GetRollerPar ) и получает 0 NewUser Depot1 123456 1 12 1 1.

Система запрашивает параметры оси (вызов функции GetAxlePar ) и получает 1 NewUser Depot1 123456 1 0 12 12.

Система добавляет в очередь команд склада на первое место команду GetR (получить из приемника в ячейку) (вызов функции SendStoreCom ) и получает сообщение о том, что команда успешно принята - 0.

Изменяем состояние окружения (входные данные):

Статус обмена с терминалом подшипника ( 1 - нет подшипника) и его параметры ( RollerPar="1 NewUser Depot1 123456 1 12 1 1" ).

Статус обмена с терминалом оси ( 0 - есть ось) и ее параметры ( AxlePar="0 NewUser Depot1 123456 1 0 12 12" ).

Ожидаемая последовательность событий (выходные данные):

Система запрашивает статус склада (вызов функции GetStoreStat ) и получает 32.

Система запрашивает параметры подшипника (вызов функции GetRollerPar ) и получает 1 NewUser Depot1 123456 1 12 1 1.

Система запрашивает параметры оси (вызов функции GetAxlePar ) и получает 0 NewUser Depot1 123456 1 0 12 12.

Система добавляет в очередь команд склада на последнее место команду SendR (вызов функции SendStoreCom ) и получает сообщение о том, что команда успешно принята - 0.

Система добавляет в очередь команд склада на последнее место команду Term (вызов функции SendStoreCom ) и получает сообщение о том, что команда успешно принята - 0.

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

Описание процесса системного тестирования

Рассмотрим процесс системного тестирования:

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

Построение. Выбранные на стадии анализа тестовые случаи переводятся на язык программирования.

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

Процесс запуска тестовых случаев и анализа полученных результатов должен быть подробно описан в тестовых процедурах.

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

Ручное тестирование.

Автоматизация выполнения и проверки результатов тестирования с помощью скриптов.

Автоматическая генерация тестов на основе формального описания.

Страницы: