Вступление

Вступление

[ [

Заметки.

Я ответил на Ваш Вопрос? Не совсем – записать. Да – проехали.

]

Описание целевой системы

В качестве целевой системы, к которой мы будем обращаться в течении всей лекции, будет выступать “Монитор событий”. “Монитор событий” - это модуль, с достаточно простой функциональностью, который входит в состав… скажем, системы управления атомным реактором на атомной электростанции.

Для начала рассмотрим функциональность модуля на одном примере использования.

По ходу сегодняшней лекции мы будем использовать нотацию диаграмм взаимодействия UML. Все знакомы с ней? Нет Þ вкраце объяснить.

[Слайд “Пример использования Монитора событий”]

[…]

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

[Слайд “Внутренний интерфейс Монитора событий”]

void event( const char* event_description );

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

[Слайд “Внешний интерфейс Монитора событий ”]

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

“R|host:port” – запрос на регистрацию.

“U|host:port” – запрос на разрегистрацию.

“N|event_desc” – уведомление о наступлении события.

Здесь host – идентификатор, а port – десячная запись порта, на котором работает слушатель (число от 1024 до 65535).

Вместе с монитором событий поставляется библиотека для слушателей событий. [Слайд “Библиотека поддержки Монитора событий”]. Она содержит две функции, которые получают в качестве параметра адрес слушателя, формируют запрос о регистрации или разрегистрации [указываю] и посылают его Монитору событий. [Если возникнет вопрос: Как они узнают его адрес? – читают из конфигурации системы]

Требования к Монитору событий:

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

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

3. Все входящие сообщения в некорректном формате должны игнорироваться.

4. Число одновременно зарегистрированных слушателей должно быть не менее 8.

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

Описание Монитора событий также представлено в Ваших рабочих материалах на странице XXX.

Если у Вас на данном этапе есть какие-либо вопросы по функционированию Монитора событий, то давайте их рассмотрим.

Если вопросов не осталось, то я попрошу Вас выполнить задания, которые даны на странице XXX Ваших рабочих материалов. [Распределить задания между слушателями (по одному)]

[Проверить задания всем вместе. Обсудить как тестовой системе необходимо оценивать поведение в таких ситуациях.] [По результатам обсуждения заданий, м. б. слушатели захотят добавить требование к Монитору событий, чтобы по истечении времени T(например, 2 сек.) после посылки(прихода) сообщения о разрегистрации никаких уведомлений по разрегистрированному адресу приходить не должно. ]

По ходу выполнения заданий не возникло ли у Вас дополнительных вопросов?

Разработка теста для целевой системы

Задание.

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

Регламент.

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

На первой этапе, Ведущим разработчиком у нас будет [Слушатель1]. С чего мы начнем разработку теста согласно технологии UniTesK?

[…]

[Что будет далее зависит от результата разработки теста]

Неуспешный тест.

[Натолкнулись на проблему Þ постараться вывести их из тупика. Все проблемы записывать на доске. В худшем случае, мы разрабатываем тест усилиями лектора] [Если они сразу не хотят писать тест с Ограничением, то перейти к разработки теста без ограничения.]

Успешный тест без Ограничения.

Хороший тест мы разработали? – Хороший. – А сейчас я покажу Вам как разработать тест еще лучше. Лучше, в смысле, разработать с меньшими усилиями, переложив еще большую часть работы на тестовую систему.

[Далее рассказ "Технология разработки тестов для систем с отложенными реакциями"]

Успешный тест с Ограничением.

[Переходим к "Анализу недостатков разработанного теста"]

Анализ недостатков разработанного теста

Рисуем последовательную диаграмму взаимодействий для компонентов тестовой системы. [event_event(нарушения в порядке сообщений) или unregister_event(пропущена тестовая ситуация).] Я начинаю с TestEngine и сценарной функции, а затем подключаю слушателей рисовать следующие сообщения. [Ожидаемый вариант на слайде “Синхронный тест для Монитора событий”, слайд не показываем – рисуем на доске. Слушатели рисуют у себя в рабочих материалах.]

[…]

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

В реальной жизни, приложение не будет ждать пока Монитор событий доставит все сообщения. Оно может взять и объявить два события, одно за другим, а Монитор событий, в таком случае, может взять и отработать некорректно. Помните, требование сохранения порядка сообщений? Монитор возьмет и перепутает порядок. А наш тест такую ситуацию, не проверял, и не может проверить в принципе. Чтобы избавиться от этого недостатка, нам необходимо отказаться от блокировки тестовой системы до получения всех ответных сообщений. Какие будут предложения?

Разработка теста без ограничения

[Дальше мы обсуждаем предложения слушателей.]

[От варианта с дублированием спецификаций-медиаторов необходимо сразу отказаться, как от плохо масштабируемых, но годных для написания подобных тестов для частных случаев.]

[Если удается остановиться на единой концепции, то пишем вместе, как ранее. Иначе каждый слушатель пишет самостоятельно.]

[…]

[Что будет далее зависит от результата разработки теста]

Успешный тест без Ограничения.

Хороший тест мы разработали? – Хороший. – А сейчас я покажу Вам как разработать тест еще лучше. Лучше, в смысле, разработать с меньшими усилиями, переложив еще большую часть работы на тестовую систему.

[Далее рассказ "Технология разработки тестов для систем с отложенными реакциями"]

Успешный тест без Ограничения не доведенный до конца (поняли рутинность).

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

[Далее рассказ "Технология разработки тестов для систем с отложенными реакциями", остановиться на моментах рутинности (как они упрощаются в нашем подходе)]

Неуспешный тест.

[Натолкнулись на проблему Þ постараться вывести их из тупика. Все проблемы записывать на доске.]

[Решили, что нет никаких мыслей как это можно сделать и путь предлагаемый лектором не нравится]

[Далее рассказ "Технология разработки тестов для систем с отложенными реакциями", остановиться на проблемных моментах (как они разрешаются в нашем подходе)]

Технология разработки тестов для систем с отложенными реакциями

[Возвращаемся к диаграмме взаимодействий.]

Для тестирование систем с такими [указать их на диаграмме] “отложенными” реакциями технология UniTesK предалагает следующий подход. Рассмотрим его на примере с практически одновременной посылкой сообщения о разрегистрации и уведомлением о наступлении события.

[Открываем слайд “Асинхронный тест для Монитора событий”.]

[Или рисуем диаграмму на доске, чтобы впоследствии постоянно к ней возвращаться, начинаем с синхронного теста и показываем как переделать в асинхронный]

[Дальше текст может отличаться в зависимости от предыдущих событий]

[Слушатели рисуют диаграмму в своих рабочих материалах]

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

Оракул, не проверяя постусловия, сразу возвращает управление сценарной функции.

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

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

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

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

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

Терминология

Воздействие – блок информации, передаваемый от тестовой системы к целевой системе.

Реакция – блок информации, передаваемый от целевой системы к тестовой системе.

Непосредственная реакция – блок информации, посылаемый целевой системой и получаемый медиатором спецификационной функции после посылки стимула и до завершения своей работы.

Отложенная реакция – блок информации, посылаемый целевой системой и не являющийся непосредственной реакцией.

Сборщик реакций – компонент тестовой системы, ответственный за сбор всех отложенных реакций целевой системы.

Взаимодействие – обмен информацией между целевой системой и тестовой системой. Мы будем рассматривать два вида взаимодействий:

·  1-го вида – взаимодействие между медиатором спецификационной функции и целевой системой, состоящее из воздействия и, возможно, непосредственной реакции;

·  2-го вида – взаимодействие между целевой системой и сборщиком реакций, состоящее из одной отложенной реакции.

 

Попросить слушателей указать данные понятия на диаграмме.

[Если у нас есть подходящая в рабочих материалах, то на ней

Иначе выдать запасные матерниалы со следующей диаграммой]

[В завершении обсуждения записать вопросы]

Реакции

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

Содержание.

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

- наличие нового вида функций (функции-отложенные реакции)

- декларация функций-отложенных реакций

- тело функций-отложенных реакций

[Для осознания проблемы можно спросить: Как изменится спецификация event_spec() при данной схеме работы тестовой системы? Помощник лектора – записывает.]

Как проверить, что целевая система ведет себя корректно?

Как это было ранее?

В постусловии спецификационной функции event_spec() было … [Показываем, что у нас было в синхронном тесте.]

В постусловии спецификационной функции event_spec() необходимо описать требования к отложенным реакциям целевой системы после уведомления ее о наступлении некоторого события.

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

[Показываем на примере]

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

Для описания отложенных реакций, в спецификационное расширение языка C добавлен специальный вид функций, так и называющийся – отложенные реакции (или, иногда, просто реакции). Каждая функция-отложенная реакция описывает определенный вид сообщений-отложенных реакций целевой системы. В нашем примере, имеется только один вид таких сообщений: уведомления о наступлении некоторого события. В этом сообщении содержится строка с описанием события.

[Пишется и показывается в коде.] Сейчас [Помощник лектора] продемонстрирует пример декларации функции-отложенной реакции, предназначенной для описания сообщений, уведомляющих о наступлении события. Сигнатура функции-отложенной реакции включает в себя ключевое слово reaction, идентификатор отложенной реакции и тип возвращаемого значения. Функция-отложенная реакция параметров иметь не может, поэтому всегда в качестве параметров функции-отложенной реакции указывается ключевое слово void. Тип возвращаемого значения обязан быть ссылкой на спецификационный тип. Возвращаемое значение функции-отложенной реакции рассматривается как модельное представление данных, посылаемых целевой системой в сообщении-отложенной реакции. Описание доступа функции-отложенной реакции осуществляется по тем же принципам, что и в спецификационной функции.

reaction NotifyMessage* notify_react(void)
updates expected_messages;

Тело функции-отложенной реакции может содержать в себе два специальных блока: предусловие – блок, помеченный ключевым словом pre, и послусловие – блок, помеченный ключевым словом post. Пост-блок является обязательным, а пре-блок может быть опущен.

В предусловии функции-отложенной реакции описывается ограничение на состояние системы, в котором целевая система может послать сообщения данного вида. Как будет выглядеть предусловие для notify_react(void)?

[Пишем предусловие.]

В постусловии функции-отложенной реакции проверяются 2 условия:

1.  Является ли посылка данного сообщения-отложенной реакции допустимым в данном пресостоянии?

2.  Является ли постсостояние системы после посылки данного сообщения-отложенной реакции корректным для данного пресостояния системы.

Для доступа к значению реакции в постусловии функции-отложенной реакции используется идентификатор реакции. Давайте теперь запишем постусловие для notify_react(void).

[Пишем постусловие.]

Закрепление материала.

Блиц опрос №1.

Сериализация

Проблема. Неизвестно в каком порядке были получены реакции и как они соотносились с тестовыми воздействиями, а также в каком поряде были оказаны тестовые воздействия. А ведь это влияет на корректность. [event-unregister – что дошло раньше?]

{Про сборщик реакций слушатели вспоминают во время блиц-опроса №2, который незаметно перетекает из первого.}

{Если возниктнет вопрос почему бы не проверять реакцию сразу при получении – или ответить на примере, или записать на доске.}

Рассмотрим наш пример с последовательной посылкой unregister и event. Мы оказали тестовые воздействия подряд и предположим, что в связи с характеристиками среды передачи тестовых воздействий, мы не знаем в каком порядке они дошли до тестируемой системы. То есть целевая система могла сначала разрегистрировать одного слушателя и затем послать уведомление второму, а могла сначала послать уведомления обоим слушателям, и только потом разрегистрировать одного из них.

Предположим, что мы получили e1, e2, n1_1, n1_2 и n2_2. Как нам определить, корректно вела себя целевая система или нет?

[Обсуждение или было ранее, или надо завязать здесь]

! Основной акцент сделать на то, что все взаимодействия известны, а их порядок между собой – нет. А чтобы оценить корректность надо что-то делать!

[!Подаем как одно из возможных решений!]

Чтобы понять правильно или нет вела себя целевая система, разработчику теста необходимо рассмотреть различные варианты последовательностей взаимодействий и найти подходящий. Если таковой найден, то поведение целевой системы корректно – иначе нет.

Для облегчения этой задачи, в CTesK реализован механизм сериализации. Этот механизм автоматически перебирает все возможные последовательности, в которых могли происходить взаимодействия и находит среди них корректные.

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

{

Если спросят.

Проблема. Как вычислять модельное состояния, когда несколько порядков являются допустимыми?

Требуем, чтобы ровно в одно.

}

{

Если спросят. Надо дать на практике.

Проблема. А если слишком много возможных сериализаций?

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

}

{

Проблема. (Следствие) Необходимо уметь сохранять текущее модельное состояние.

Будет рассмотрена позднее в Тестовых сценариях.

}

Регистрация

Необходимые условия. Было рассказано про реакции.

Проблема. Как тестовая система получает информацию об отложенных реакциях?

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

Для этого тестовая система предоставляет интерфейс регистрации отложенных реакций. [Слайд “Интерфейс регистрации отложенных реакций”].

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

Что такое модельное представление отложенной реакции? Это третий и четвертый параметры функции registerReaction. Третий параметр – это идентификатор функции-отложенной реакции, которая описывает требования к отложенной реакции данного вида, а четвертый параметр – это значение, тип которого совпадает с типом возвращаемого значения функции-отложенной реакции, указанной в качестве третьего параметра.

Что означают оставшиеся параметры?

·  к первому мы вернемся немного позднее;

·  а второй всегда должен принимать значение NULL.

Запишем поведение сборщика реакций при получении реакции:

[Помощник лектора демонстрирует регистрацию реакция на сопроводительном примере (модифицируя функцию gatherReactions)]

[Здесь демонстрируется сигнатура отложенной реакции notify_react]

Создаем значение типа возвращаемого значения (это и есть преобразование в модельное представление):

notify_message =

create_NotifyMessage( create_String( desc->requestor ),

create_String( buff+2 ),

create_String( buff+i+1 )

)

и вызываем функцию registerReaction:

registerReaction( chid, NULL, notify_react, notify_message );

Если же сообщение не удалось преобразовать в модельное представление, мы должны воспользоваться второй функцией: registerWrongReaction.

Параметром функции registerWrongReaction является текстовая строка, описывающая ошибочную ситуацию. Эта строка используется при анализе результатов теста для понимания “В чем заключалась некорректность поведения целевой системы?”.

[Помощник лектора демонстрирует это на сопроводительном примере]

Закрепление материала. Блиц опрос №3.

--

Проблема получения всех отложенных реакций целевой системы не может быть решена в общем виде, потому что механизм передачи является полностью реализационно зависимым. Это могут быть сообщения по одному из протоколов (TCP/UDP/IP), это могут быть вызовы callback функций, сигналы и т. д. и т. п. Поэтому технология UniTesK ничего не говорит о том, как надо получать отложенные реакции.

{ Только в ответ на вопрос слушателей:

Проблема. Как получить и зарегистрировать сообщения из основного потока тестовой системы?

Ответ: Есть “Cервис регистрации функций-сборщиков реакций”, который будет рассмотрен на практических занятиях.}

Каналы взаимодействий

Проблема. Как сохранять и использовать имеющуюся информацию о последовательности взаимодействий?

Содержание.

- понятие каналов

- идентификаторы каналов и регистрация реакций

- UniqueChannelID

- канал стимулов

[При обсуждении утверждения «Тестовая система имеет некоторую информацию о порядке, в котором происходили отложенные реакции» необходимо объяснить, что тестовая система получает реакции на одном сокете и знает, что одна была раньше, а другая позже (пример с notify_msg), но эта информация теряется при регистрации. А она нужна, чтобы правильно оценить корректность поведения целевой системы.]

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

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

Рассмотрим на примере. Предположим, что мы получаем отложенные реакции по соединениям TCP/IP. Тогда все реакции полученные на одном сокете относятся к одному каналу, т. к. мы точно знаем порядок их получение. В то же время, реакции полученные на разных сокетах, должны относиться к разным каналам, т. к. их взаимный порядок нам не известен.

Чтобы указать к какому каналу относится та или иная реакция, при ее регистрации необходимо в качестве первого параметра функции registerReaction передать идентификатор канала. Идентификатор канала имеет тип ChannelID. [Слайд “Идентификаторы каналов”].

Для получения свободного идентификатора канала используется функция getChannelID. Кроме того, существует специальная константа этого типа UniqueChannel.

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

Реакции, при регистрации которых была указана константа UniqueChannel, относятся к каналу, состоящему из одного единственного взаимодействия. Другими словами, для таких реакций нет никакой информации об их расположении во времени относительно других реакций.

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

[Помощник лектора демонстрирует идентификаторы реакций на сопроводительном примере (модифицируя CatcherDesc).]

Для этого, мы к описанию каждого requestor'а добавим идентификатор канала [показываем], который инициализируется во время начала работы тестового сценария. И затем будем передавать его в функцию registerReaction.

Закрепление материала. Блиц опрос №4.

[Рассказ о канале стимулов можно опустить в зависимости от имеющегося времени.]

Проблема. А как указать порядок подачи стимулов?

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

Но это предположение можно изменить посредством установки так называемого канала стимулов. [Слайд “Канал стимулов”].

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

Если при инициализации тестового сценария установить в качестве идентификатора канала стимулов какой-нибудь фиксированный идентификатор, то все взаимодействия 1‑го вида будут относиться к одному каналу и, таким образом, тестовая система будет считать, что порядок стимулов соответствует порядку вызова медиаторов спецификационных функций.

Какой вариант нам выбрать для нашего примера?

[Слушатели должны понять, что ни тот, ни другой вариант нам не подходит.]

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

[Помощник лектора демонстрирует это на сопроводительном примере (модифицируя медиаторы и вводя дополнительную переменную для хранения идентификатора канала).]

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

Относительно остальных стимулов у нас нет никакой информации, поэтому мы будем помечать их константой UniqueChannel.

{

Только в ответ на вопрос слушателей:

Проблема. С помощью модели каналов можно описать не все возможные частичные порядки?

Ответ: Такая возможность предусмотрена (временные метки), но она находится за рамками тренинга.

}

Стационарность

Проблема. А что если сообщения пойдут нескончаемым потоком? А что если все сообщения получены, они корректны, но не хватает еще одного?

Далее мы остановимся на одном важном параметре тестовой системы.

[Возвращаемся к диаграмме последовательности взаимодействий]

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

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

Это время называется ”временем ожидания стабилизации целевой системы”.

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

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

Давайте посмотрим на наш пример. В каких состояниях от целевой системы не ожидается отложенных реакций? Какое время ожидания установить?

[Небольшое обсуждение]

[Помощник лектора показывает установку времени ожидания в инициализации сценария]

[Далее, в зависимости от времени, или только, если в ходе лекции возникал этот вопрос.]

Проблема. А что если все сообщения получены, они корректны, но не хватает еще одного?

Тестовая система CTesK использует стационарные состояния еще для одной важной цели. [Рассматриваем ситуацию на сопроводительном примере.]

Для выявления такого рода ошибок в поведении целевой системы в CTesK используется следующий подход. Тестовая система проверяет после получения всех сообщений, является ли текущее состояние стационарным. Если да, то все в порядке: ЦС послала все, что должна была послать. Если нет, значит в целевой системе присутствует ошибка: она не выдала одну из требуемых отложенных реакций.

Закрепление материала. Блиц опрос №5.

Сценарии тестирования

Необходимые условия. Слушатели знают про сериализацию и стационарность.

Проблема. А что изменилось в тестовых сценариях?

Какие дополнительные поля появились в сценарии тестирования, предназаначенном для отложенных реакций? Давайте вспомним как происходит процесс сериализации.

[Пытаемся натолкнуть слушателей на эту мысль]

Для осуществления процесса сериализации тестовой системе необходимо уметь сохранять и восстанавливать текущее модельное состояние.

Поэтому [Слайд “Сценарий тестирования”] в сценарии тестирования присутствуют дополнительные поля, которые обязательно должны быть проинициализированы при тестировании систем с отложенными реакциями.

Как будут выглядеть функции сохранения и восстановления модельного состония в нашем тесте?

[ Саша записывает эти функции и инициализацию теста ]

Переехало из стационарности:

Давайте опишем функцию, проверяющую стационарность текущего модельного состояния.

[ Помощник лектора записывает эту функцию ]

Для того, чтобы функция проверки стационарности текущего модельного состояния указывается при определении тестового сценария, инициализируя поле isStationaryState.

Изменение состояния при получении реакции

Необходимые условия. Слушатели знают про реакции.

Проблема. Как описать изменение состояния при получении реакции?

[ Слайд «Медиатор реакции» ]

Для каждой спецификационной функции необходимо определить ее медиатор и установить связь с ним посредством вызова функции set_mediator_<specification_func_name>.

Так же и для каждой функции-отложенной реакции, необходимо определить ее медиатор и установить связь с ним посредством вызова функции set_mediator_<reaction_name>.

Сигнатура

Тело – блоки call и state.

Обобщающий слайд

Необходимые условия. Слушатели знают почти все.

Проблема. Как организована работа тестовой системы в случае тестирования систем с отложенными реакциями?

[Рисуем диаграмму]

Какие остались вопросы по работе тестовой системы в режиме поддержки отложенных реакций?

Выделяем характеристики отложенных реакций. Даем обобщенное определение.

Взаимодействием с целевой системой мы будем называть любой обмен информацией между целевой системой и ее окружением (тестовой системой).

Как Вы видите, при отказе от блокировки тестовой системы до получения всех ответных сообщений от целевой системы, у нас появились взаимодействия с целевой системой нового вида. (До этого они были частью взаимодействия, инициированного вызовом спецификационной функции) [Можно задать вопрос: Чем характеризуются эти взаимодействия?] Эти взаимодействия характеризуются тем, что они инициируются целевой системой и данные в них передаются только в направлении от целевой системы к тестовой. Такие взаимодействия мы будем называть отложенными реакциями. [Четко повторить определение]. [Это говорить не надо: Действительно, если первоначально реакции включались в качестве возвращаемого результата, т. е. рассматривались как непосредственная реакция на оказание тестового воздействия. То сейчас реакция не привязана ни к какому тестовому воздействия, а рассматривается как отдельное взаимодействие].

Отложенные реакции являются частью функциональности целевой системы, поэтому, согласно технологии UniTesK, требования к ним должны быть описаны в спецификации системы. [Вопрос: Какие могут требования к отложенным реакциям? Ответ: Ограничения на состояние системы в котором эта реакция может появиться, ограничение на изменения состояния в результате получения этой реакции ][ВАЖНО! Достичь понимания, что связь со стмулами обеспечивается через состояние модели].

Технические вопросы рассматриваем на обобщающем слайде:

Проблема. (Следствие) Вызов спецификационной функции извне сценарной в режиме поддержки отложенных реакций.

Ограничение на место вызова + возможность отключить режим

Проблема. (Следствие) Изменилась семантика вызова спецификационной функции.