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