- •Семестр 9 р1. Принципы построения пользовательского интерфейса в приложениях систем управления р1: Лекция №1. Обобщенная архитектура прикладной составляющей программного обеспечения систем управления
- •Жизненный цикл изделия и программные средства его поддержки
- •Обобщенная архитектура систем управления электроавтоматикой
- •Характеристики современного процесса разработки прикладной составляющей электроавтоматики
- •Вопросы:
- •Р1: Лекция №2. Базовые элементы платформы приложений су для построения интерфейса пользователя
- •Компоненты каркаса
- •Компоненты конфигурирования
- •Компоненты средств интерфейса пользователя
- •Конфигурирование компонентов в составе системы
- •Вопросы
- •Р1: Лекция №3. Принципы классификации прикладных компонентов систем управления
- •Виртуальная структура прикладной области
- •Матрица компонентов
- •Анализ и систематизация набора прикладных компонентов с применением матрицы
- •Определение минимально необходимого набора прикладных компонентов системы
- •Вопросы
- •Семестр 9 р2. Технологии .Net в разработке приложений систем управления р2: Лекция №4. Основные понятия платформы .Net
- •Строительные блоки .Net (clr, cts, cls)
- •Преимущества с#
- •Промежуточный язык msil
- •Работа с пространствами имен
- •Память в приложениях .Net
- •Проверка наличия утечек
- •Получение дополнительной информации о пространстве имен и типах сборки
- •Вопросы
- •Р2: Лекция №5. Принципы взаимодействия .Net с разработанным кодом
- •Преобразование исходных кодов в новый формат языков .Net
- •Использование двоичных компонентов для организации взаимодействия с компонентами .Net
- •Вопросы
- •Р2: Лекция №6. Инструментарий процесса разработки
- •P2: Лекция №6. Инструменты отладки приложений в .Net Framework 2.0 и выше Утилиты
- •Загрузка расширения отладки sos
- •Примеры:
- •Базовые различия
- •Сборка мусора в .Net Framework
- •Причины смешивания управляемого и неуправляемого кодов
- •Концепция CoDeSys
- •Окно приложения Сodesys:
- •P3. Лекция № 9. Возможности CoDeSys как открытой системы
- •Архитектура приложений современных систем управления
- •Выявление открытых интерфейсов среды
- •Встраивание сцены трёхмерного моделирования объекта управления
- •P3. Лекция № 10. Взаимодействие с аппаратными средствами платформы CoDeSys
- •Основные характеристики и назначение
- •Построения средств диагностики и управления устройствами электроавтоматики на базе opc технологии
- •Особенности механизмов работы opc серверов
- •Реализация интерфейсов opc в сервере
- •Реализация opc компонентов диагностики для контроллеров CoDeSys sp
- •Вопросы
- •Семестр 9 р4. Тестирование приложений систем управления через интерфейс оператора p4. Лекция № 11. Базовые понятия процесса тестирования
- •Жизненный цикл разработки программного обеспечения
- •Модели жизненного цикла
- •Каскадный жизненный цикл
- •Спиральный жизненный цикл
- •Экстремальное программирование
- •Тестирование, верификация и валидация - различия в понятиях
- •Задачи и цели процесса верификации
- •P4. Лекция № 12. Использование пакетов автоматизации тестирования
- •Методы проведения тестирования пользовательского интерфейса, повторяемость тестирования пользовательского интерфейса
- •1) Ручное тестирование
- •2) Сценарии на формальных языках
- •Тестирование удобства использования пользовательских интерфейсов.
- •Принцип использования коммерческих приложений для тестирования пользовательского интерфейса
- •Обзор Quickt Test. Основные понятия
- •Использование Actions, Iterations
- •Использование объекта DataTable и параметризация
- •Распознавание объектов в qtp и уникальность их свойств
- •P4. Лекция № 13 Модульное тестирование
- •Цели и задачи и модульного тестирования
- •Понятие модуля и его границ. Тестирование классов
- •Подходы к проектированию тестового окружения
- •P4. Лекция № 14. Возможности uiAutomation
- •Начальное представление
- •Представление элемента управления
- •Представление содержимого
- •Шаблоны элементов управления uia
Использование Actions, Iterations
Action — это независимый скрипт в составе теста. Он имеет свой контекст имен переменных, свой локальный Object Repository (хранилище описаний объектов пользовательского интерфейса тестируемого приложения), свой Action Sheet (называемый, также Local Sheet — таблица для хранения значений параметров; его можно вызывать из других тестов. Кроме того, начиная с QTP 8.0 у Actions есть свои параметры (не путать с Data Table parameters: в данном случае имеются в виду значения переменных, передающихся в action извне, либо выходные параметры, аналогично параметрам функций).
В свойствах Action можно указать, сколько раз подряд его надо запустить (количество итераций) — это имеет смысл делать при активном использовании параметризации. При использовании параметризации, при каждой следующей итерации Action, все локальные параметры принимают новое значение — значение из ряда Action Sheet, совпадающего с номером итерации. Следует иметь в виду, что кроме Action Sheet, существует Global Sheet (один на весь тест) — значения параметров, описанные в нём, изменяются при переходе к следующей итерации теста, а не Action.
В Mercury считают, что один Action должен примерно соответствовать одной бизнес операции, или одному Use Case. То есть, использование Actions (по Mercury) — основной способ функциональной декомпозиции. В реальности, вместо Actions для этих целей часто бывает удобнее использовать функции. Впрочем, это зависит от стиля Ваших тестов, в частности, от того, используете ли Вы параметризацию.
Для вызова Action из другого теста (либо из другого Action) необходимо, чтобы в свойствах action (Action Properties) была выставлена галочка "Reusable action".
Каждый Action имеет свой контекст имён, поэтому переменные одного Action не видны из другого. Универсальный способ передачи переменных, начиная с версии QTP 6.0 — использование объекта Environment. Кроме того, начиная с версии 8.0 у Actions появились параметры (см. Help: Action properties, Action call properties, Action parameters). То есть, Action, — это в некотором смысле аналог функции с входными и выходными параметрами.
Использование объекта DataTable и параметризация
Для того, чтобы вместо фиксированных значений параметров функций (например, текста, вводимого в поле ввода) использовать (в цикле) значения из таблицы, используется подход, называемый Data-Driven тестирование. При параметризации, исполнение теста происходит в форме исполнения двух вложенных циклов — по всему тесту целиком и по отдельным Actions. Соответственно, есть 2 типа параметров: глобальные — для всего теста, и локальные — для отдельных Actions. В начале каждой итерации все параметры приобретают значения, хранящиеся в строчке соответствующей таблицы (Global Sheet/Action Sheet), номер которой равен номеру итерации (теста или Action соответственно).
Кроме использования Data Table для хранения входных тестовых данных (параметры), QTP позволяет использовать его для хранения выходных данных (Output Values). Во время выполнения теста, значения в Data Table можно менять, однако они не будут сохранены в тесте. Зато их можно будет увидеть в отчёте об исполнении теста (логе).
