- •Семестр 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
P4. Лекция № 14. Возможности uiAutomation
Библиотека классов UIAutomation. Исследование структуры пользовательского интерфейса приложений. Реализация надстроек для создания инструментов тестирования пользовательского интерфейса. Специфика в тестировании интерфейса пользователя на примере CoDeSys.
UI Automation (далее UIA) был разработан как преемник Microsoft Active Accessibility. Active Accessibility — это существующая среда, разработанная для обеспечения решения для создания элементов управления и специальных возможностей приложений. Active Accessibility не была разработана с автоматизацией тестирования несмотря на то, что он развился в эту роль из-за очень схожих требований специальных возможностей и автоматизации.
Основная проблема которую решает UIA - это поиск в окне всех дочерних элементов управления. Первые разработки библиотеки начались, дабы упростить разработку специализированных приложений. Специализированные приложения - это те программы и комплекс программ, которые разрабатываются для людей с нарушением зрения, моторики и т.д. Но позже выяснилось, что UIA также замечательно подходит для создания "пользовательского тестирования интерфейса". С помощью методов предлагаемых UIA можно в короткие сроки создать автоматизированное средство для тестирования интерфейса приложений созданных на основе Windows Forms. Дело в том что стандартные средства UIA могут справится только с стандартными элементами управления тестируемого приложения, коммерческие или самописные элементы интерфейса не поддаются распознаванию и для них нужно писать свои методы взаимодействия.
Очень интересна часть интерфейса API Microsoft UI Automation — отличная поддержка событий. Хотя можно установить обработчик ведения журнала для записи использования клавиатуры и мыши, нет ясного интерфейса API для получения уведомлений о том, на каком элементе управления находится фокус, когда окна открываются и закрываются и так далее.
Ключевой момент интерфейса API Microsoft UI Automation — все основано на типе элемента управления. Элементы класса AutomationElement «обертывают» каждый элемент управления, что дает возможность быстро определить, чем является конкретный каждый элемент управления на экране и каковы его функции. Раньше для такого уровня детализации требовалось коммерческое приложение. Одна из возможностей тестирования интерфейса пользователя, исчезнувшая из интерфейса API UI Automation — поддержка мыши. Ее нет совсем. Для большинства приложений это не является проблемой, поскольку шаблоны элементов управления обеспечивают аналогичную функциональность. В то же время при работе с приложением для рисования вы не получите никакой помощи в рисовании улыбающихся рожиц с помощью мыши.
Модель тестирования строится по следующему принципу - поставщику и клиенту требуется UIA, чтобы использоваться в качестве средства автоматизированной проверки. Поставщиками Автоматизации Пользовательского Интерфейса являются приложения, как, например, Microsoft Word, Excel, и другими приложения сторонних разработчиков или элементов управления, основанными на операционной системе Microsoft Windows. Клиентами Автоматизированного Пользовательского Интерфейса являются сценарии автоматизированной проверки и вспомогательные технологические приложения.
Для того, чтобы автоматизировать Пользовательский интерфейс (User Interface - UI), разработчик приложения или элемента управления должен посмотреть, какие действия конечного пользователя могут выполняться над объектом UI при использовании взаимодействия со стандартной клавиатурой и мышью. Как только эти ключевые действия были определены, соответствующие Модель автоматизации пользовательского интерфейса шаблоны управления (т. е. шаблоны управления, отражающие функциональные возможности и поведение элемента UI) должны быть реализованы в элементе управления. Например, взаимодействие пользователя с элементом управления combo box (таким, как окна выполнения) обычно включает развертывание и свертывание поля со списком для скрытия или отображения списка элементов, выбор элемента из этого списка или добавление нового значения с помощью ввода с клавиатуры.
Технология специальных возможностей продуктов и сценариев тестирования использует дерево UIA для сбора сведений о UI и его элементах. В дереве UIA имеются корневые элементы (RootElement), которые представляют текущий рабочий стол, а дочерние элементы представляют окна приложений. Каждый из этих дочерних элементов может содержать элементы, представляющие части UI, таки как меню, кнопки, панели инструментов и поля со списком. В свою очередь, эти элементы могут содержать элементы, такие как элементы списка.
Пример кода на С# // взятие корневого элемента
AutomationElementCollection desktopChildren =
AutomationElement.RootElement.FindAll(
TreeScope.Children, Condition.TrueCondition);
Дерево UIA не является фиксированной структурой и редко отображается полностью, так как оно может содержать тысячи элементов. Его части создаются по необходимости, и дерево может претерпевать изменения при добавлении, перемещении или удалении элементов. Дерево UIA может быть отфильтровано для создания представлений, содержащих только те объекты AutomationElement, которые соответствуют конкретному клиенту. Этот подход позволяет клиентам настроить структуру, представленную с помощью UIA , для их конкретных нужд. Клиент может настроить представление двумя способами: определением области и фильтрацией. Определение области — это определение пространства представления, начиная от базового элемента: например, приложению может требоваться найти только дочерний элемент рабочего стола или всех потомков окна приложения. Фильтрацией является определение типов элементов, которые должны быть включены в это представление. Поставщики модели автоматизации пользовательского интерфейса поддерживают фильтрацию с помощью определения свойств элементов, включая свойства IsControlElementProperty и IsContentElementProperty.
UIA предоставляет три представления по умолчанию. Эти представления определяются типом выполняемой фильтрации; область любого представления определяется приложением. Кроме того, приложение может применить другие фильтры к свойствам; например, чтобы включить только включенные элементы управления в представление элемента управления.
