Занятие 1 «Архитектура теста»
| Цель занятия: рассмотрение свойств CTesK, которыми будут владеть обучаемые в конце тренинга. |
| Работа с определениями тестирования из портфолио. Каждый должен выбрать определение или сформулировать свое и озвучить его. (Если не было предыдущей лекции.) Говоря о Тестировании как о проверке соответствия между реальным поведением программы и ее ожидаемым поведением. Мы подразумеваем, что кроме самой проверяемой программы (называемой далее ЦС) В нашем курсе мы будем рассматривать случаи, когда в процессе тестирования кроме тестируемой программы принимает участие другая программа (называемая далее ТС), |
Демонстрация работы теста (с трассой в консоли), разработанного при помощи CTesK, отчетов в HTML и динамических представлений трассы. | |
| Как и разработка других программ разработка тестовой программы заключается в o определении требований к тестам, то есть какие возможности и свойства ЦС д. б. нужно проверять, o проектировании программы, реализующей тесты, то есть определении способов тестирования o реализации тестов в коде o и его отладки вместе с тестируемой программой CTesK предназначен для поддержки разработки тестовых программ, в основном, на этапах проектирования, реализации и отладки. CTesK разрабатывался для поддержки технологии UniTesK, поэтому максимальная эффективность поддержки инструментом процесса разработки тестов достигается при использовании именно этой технологии: на этапе проектирования за счет использования унифицированной архитектуры тестовой программы, на этапе реализации за счет автоматизации кодирования тестов на основе требований к ЦС, на этапе отладки за счет использования различных сгенерированных представлений трасс тестов. Возможные применения CTesK вне рамках технологии UniTesK не рассматриваются в данном курсе. |
| Тесты, разработанные по технологии UniTesK, имеют унифицированную архитектуру. |
| Оракулы — функции, реализованные на языке C, которые проверяют правильность результатов работы целевой системы при воздействиях на нее. |
| Для придания тестам гибкости и возможности многократного использования, в архитектуре теста присутствуют медиаторы. Эти компоненты делают оракулы независимыми от деталей реализации, например, от ее интерфейса, то есть позволяют использовать одни и те же тесты для разных реализаций одной программы. Так же медиаторы позволяют реализовать удаленное тестирование, когда целевая и тестовая системы находятся на разных компьютерах. |
| Основная часть тестовой программы сосредоточена в генераторе тестовой последовательности, который определяет (генерирует) последовательность воздействий на систему (тестовую последовательность) в тесте. |
| Структура генератора тестовой последовательности определяется особенностями тестирования систем, поведение которых зависит от истории их взаимодействия с окружением, т. е. имеющих внутреннее состояние. |
| Обходчик является библиотечным компонентом и реализует алгоритм построения последовательности тестовых воздействий с тем, чтобы протестировать целевую систему в разных состояниях. |
| Итератор тестовых воздействий поставляет обходчику тестовые воздействия, допустимые в текущем состоянии системы. |
| В качестве примера рассмотрим тест для целевой системы, реализующей на языке C очередь ограниченного размера для хранения данных типа int, с поддержкой сервиса наблюдателей. Наблюдаемыми извне результатами работы системы являются значения, возвращаемые интерфейсными функциями помещения и удаления элемента, и вызовы функций наблюдателей |
| Первые являются непосредственными реакциями системы на воздействия, так как наблюдаются сразу после воздействия, |
| вторые — ее отложенными реакциями, так как происходят в отдельной нити управления и могут наблюдаться не сразу после воздействия, а спустя некоторое время. |
| Целевая система рассматриваемого примера. |
| Оракулы для очереди. Это обычные, довольно большие функции, с определенной структурой, обеспечивающие проверку правильности непосредственных и отложенных реакций системы на внешние воздействия, отслеживание покрытия и трассировку выполнения теста. Процентов на 80 оракулы состоят из технических деталей, которые можно генерировать автоматически. Оставшаяся часть описывает проверку требований к функциональности целевой системы. Используемая форма описания функциональности — формальные спецификации. (Индивидуальная работа с кластером «Формальные спецификации» в портфолио. Сводный кластер — на доске. ) В CTesK при разработке формальных спецификаций предлагается пользоваться специальной нотацией, которая позволяет записывать оракулы в краткой форме в виде пред - и постусловий на поведение целевой системы. |
| Сокращенная запись для функций и отложенных реакций рассматриваемого примера. |
| Нотация, используемая в CTesK, является спецификационным расширением языка C, называемым SeC. (Ссылка на список основных ключевых слов SeC в портфолио.) Поведение целевой системы описывается в спецификационных функциях и отложенных реакциях в виде пред‑ и постусловий. |
| Из этой сокращенной записи при помощи инструмента, предоставляемого CTesK, генерируются оракулы |
| Медиаторы разрабатываются вручную. |
| Так как для их корректной работы в составе тестовой системы необходимо выполнять множество рутинных и трудоемких операций, медиаторы пишутся на SeC. |
| после чего код на SeC подвергается автоматической доработке и становится реально используемым компонентом на C. |
| Так как в рассматриваемом примере целевая система обладает отложенными реакциями, необходимо обеспечить механизм перехвата отложенных реакций. Для этого разрабатываются сборщики реакций, которые поставляют все обнаруженные отложенные реакции в тестовую систему при помощи функций из библиотеки поддержки тестовой системы CTesK. |
| Генератор тестовой последовательности состоит из обходчика и итератора тестовых воздействий. |
| Обходчик является библиотечным компонентом. Итератор тестовых воздействий генерируется на основе тестового сценария. |
| Тестовый сценарий разрабатывается на SeC и представляет собой схему теста в виде набора воздействий, которые необходимо сделать по ходу тестирования. |
| При помощи инструмента CTesK тестовый сценарий транслируется в C. |
| Для того чтобы построить тест для рассматриваемого примера, соответствующий архитектуре, предлагаемой в UniTesK, нужно разработать на SeC спецификации, медиаторы и тестовый сценарий. |
| Из них генерируются компоненты теста на языке C. |
| Функция main тестовой программы. |
| Компиляция, сборка и запуск теста. Сгенерированная трасса. |
| Анализ трассы: отчеты в HTML и проигрывание трассы в различных представлениях (State diagram, MCS, Trace Structure, XML) |
| Наличие этого слайда и картинки в портфолио решается для каждого курса индивидуально. Ссылка на схему в портфолио. К каждому блоку будем обращаться по несколько раз по мере усложнения материала, поэтому на схеме нет никаких связей между блоками. Сначала будет рассмотрено создание тестов для систем, поведение которых не зависит от истории взаимодействия с окружением и определяется только входными параметрами воздействий (пример: вернуть длину строки, переданной через входной параметр). Потом будет рассмотрено создание тестов для систем, поведение которых зависит от истории взаимодействия с окружением (пример: вернуть длину очереди). Отдельное занятие будет полностью посвящено разработке тестовых сценариев с обобщением состояния. Последние занятия будут посвящены разработке спецификаций, медиаторов, перехватчиков и тестовых сценариев для систем с отложенными реакциями. |
В портфолио приведена полная архитектура теста. Предлагается расставить связи между её компонентами (кто кого вызывает) и выделить компоненты библиотечные, генерируемые и разрабатываемые вручную. (На доске заполняем таблицу: библ., генер., вручную. Каждый говорит свой вариант, где расхождение ставим «-» и обсуждаем.). Должно получиться см. последний слайд. | |
| Вернёмся к первому слайду |
| Так как тестирование подразумевает проверку того, что ЦС соответствует требованиям к ней, то существенной особенностью CTesK являетсято, что с его помощью можно реализовать подход, основанный на формализации функциональных требований к системе и критериев их покрытия в виде спецификаций на SeC. Формализация требований и критериев их покрытия делает возможным генерацию кода, проверяющего правильность работы ПО (оракулов) и автоматическую оценку процента формализованных требований, покрытых в процессе тестирования. |
| Таким образом, CTesK поддерживает автоматизированную разработку тестов на основе формализованных требований к системе. |
| На первом шаге неформальные требования записываются в виде спецификаций, в которых так же определяются критерии покрытия формализованных требований. |
| Далее спецификационные функции подразделяются на функционально связанные группы, для каждой из которых разрабатывается один или несколько тестовых сценариев. |
| На следующем шаге создаются медиаторы для всех спецификационных функций, связывающие спецификации с интерфейсом тестируемой реализации. |
| Код на C, сгенерированный из спецификаций, тестовых сценариев и медиаторов, компилируется и собирается вместе с тестируемой реализацией в исполняемые файлы. Тесты выполняются. |
| На основе трас тестов генерируются тестовые отчеты, которые помогают анализировать результаты тестирования и отлаживать тесты. Кроме обычных для программ ошибок ищутся и исправляются следующие специфические ошибки: o при обнаружении несоответствий в поведении целевой системы ее спецификациям, необходимо определить, где ошибка — в реализации или в спецификации; o ошибки в медиаторах, приводящие к рассогласованию реализации и спецификационной модели при работе тестовой программы, которые могут приводить к вынесению неправильных вердиктов о несоответствиях в поведении целевой программы ее спецификациям и к плохому тестовому покрытию; o ошибки в тестовых сценариях, которые приводят к плохому тестовому покрытию. |
В «Рабочих материалах» на стр. 13 приведена таблица соответствия между шагами технологии и компонентами тестов. Предлагается заполнить правый столбец: на каких шагах, какие компоненты разрабатываются. Далее в группе обсуждаем. Результат записываем на доске. Если нет единого мнения, то обсуждаем вместе. | |
На стр. 14 есть место для записи вопросов, которые появились после лекции. Запишите ваши вопросы. Потом обсудите их в группе, чтобы у вопросов были формулировки понятные всем. После этого мы рассмотрим вместе наиболее общие формулировки всех вопросов. Записываем общие вопросы. Под чертой – индивидуальные. Говорим, когда будем отвечать на них. |
есть нечто взаимодействующее с ней 
и оценивающее результаты ее работы. 
В разных случаях это м. б. человек, другая программа вместе с человеком или просто другая программа, или что-то еще.
которая взаимодействует с ЦС через ее интерфейс, получает от нее результаты ее работы, анализирует их и фиксирует в некотором виде
