Описание тестируемой системы и ее окружения. Планирование тестирования

Практикум базируется на тестировании модели реальной системы управления автоматизированным комплексом хранения подшипников. Она обеспечивает прием подшипников на склад, сохранение характеристик поступивших подшипников в базе данных (БД), а при поступлении заявки на подшипники вместе с параметрами оси - подбор подходящих подшипников и их выдачу. У каждого из элементов комплекса (склада, терминала подшипника и терминала оси) существует программа низкоуровневого управления, реализованная в виде динамически подключаемой библиотеки (dll), принимающая на вход высокоуровневые команды, и преобразующая их в управляющие воздействия на данный элемент тестируемой системы. Таким образом, есть реальное окружение - аппаратура и dll, которые осуществляют связь с аппаратурой. Система вызывает следующие функции из dll для своих элементов (см. рис. 1.1):

GetStoreStat, GetStoreMessage, SendStoreCom (Store.dll) для склада.

GetAxlePar (Axle.dll) для терминала оси.

GetRollerPar (Bearing.dll) для терминала подшипника.

Рис. 1.1. Система и ее окружение

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

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

При системном тестировании мы рассматриваем систему как черный ящик. Тестовый случай (test case) представляет собой пару (входные данные, ожидаемый результат), в которой входные данные - это описание данных, подаваемых на вход нашей системы, а ожидаемый результат - это описание выходных данных, которые система должна предъявить в ответ на соответствующий ввод. Выполнение (прогон) тестового случая - это сеанс работы системы, в рамках которого на вход системы подаются наборы данных, предусмотренные спецификацией тестового случая, и фиксируются результаты их обработки, которые затем сравниваются с ожидаемыми результатами, указанными в тестовом случае. Если фактический результат отличается от ожидаемого, значит, обнаружен отказ, т.е. тестируемая система не прошла испытание на заданном тестовом случае. Если полученный результат совпадает с ожидаемым, значит, тестируемая система прошла испытание на заданном тестовом случае. Из тестовых случаев формируются тестовые наборы (test suits). Тестовые наборы организованы в определенном порядке, отражающем свойства тестовых случаев. Если система успешно справилась со всеми тестовыми случаями из набора, то она успешно прошла испытания на тестовом наборе.

Для нашей системы входными данными является состояние окружения ее компонентов:

Склад. Состояние склада будет характеризоваться следующими параметрами:

Статус склада (StoreStat).

Сообщение от склада о результатах выполнения команды (StoreMessage).

Сообщение от склада о результатах получения команды - статус команды (CommandStatus).

Терминал подшипника. Состояние терминала подшипника задается следующими параметрами:

Статус обмена с терминалом подшипника.

Характеристики (параметры) подшипника (RollerPar):

ФИО мастера, производившего измерения.

Название депо.

Номер рабочей смены.

Номер подшипника.

Номер группы подшипника.

Тип сепаратора подшипника.

Терминал оси. Состояние терминала оси задается следующими параметрами:

Статус обмена с терминалом оси.

Характеристики (параметры) оси (AxlePar):

ФИО мастера, производившего измерения.

Название депо.

Номер оси.

Сторона оси: правая или левая.

Посадочный диаметр задний.

Посадочный диаметр передний.

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

В спецификации тестового случая должны быть заданы состояние окружения ( входные данные ) и ожидаемая последовательность событий в системе ( ожидаемый результат ). После прогона тестового случая мы получим реальную последовательность событий в системе ( выходные данные ) при заданном состоянии окружения. Сравнивая фактический результат и ожидаемый, можно сделать вывод о том, прошла ли тестируемая система испытание на заданном тестовом случае. В качестве ожидаемого результата будем использовать пошаговое описание случая использования (use case), так как оно определяет, как при заданном состоянии окружения система должна функционировать. Задавая ожидаемый результат, очень важно помнить о том, что при заданном состоянии окружения возможны различные варианты последовательности событий системы, которые все являются правильными.

В процессе работы последовательность событий (команд) системы, или история системы, записывается в журнал (log) системы. Вы можете использовать SystemLogAnimator (см. п.14 SysLog Animator Manual) для визуализации журнала системы. Выбирая различные log-файлы системы для визуализации, можно получить наглядное и достаточно полное представление о функционировании системы и о том, какие события и в каком порядке могут происходить в системе.