Тестирование графического интерфейса пользователя




Дата28.11.2016
Размер1.23 Mb.
Просмотров480
Скачиваний2

Тестирование графического интерфейса пользователя
Боциев А.Я., Виценко А.Ю., Крюков А.К., Моренов О.А., Пряхин И.В.,
Семенов Д.С., Чиликин Е.В. Intel
Тренинги Intel Delta Course
«Дополнительные главы по Software Engineering»

Графический интерфейс пользователя
Графический интерфейс пользователя (Graphical user
interface, GUI) –разновидность пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки, значки, списки и т. п.), представленные пользователю на дисплее, исполнены в виде графических изображений.


Задачи тестирования GUI
Задачей тестирования графического интерфейся пользователя
является обнаружение ошибок следующего характера:
• Ошибки в функциональности посредством интерфейса
• Необработанные исключения при взаимодействии с интерфейсом
• Потеря или искажение данных, передаваемых через элементы интерфейса
• Ошибки в интерфейсе (несоответствие проектной документации, отсутствие элементов интерфейса)


Особенности тестирования пользовательского интерфейса 1/2
Особенности тестирования пользовательского интерфейса:
• Тест-планы для проверки пользовательского интерфейса, как правило, представляют собой сценарии, описывающие действия пользователя при работе с системой
• Сценарии могут быть записаны либо на естественном языке, либо на формальном языке какой-либо системы автоматизации пользовательского интерфейса
• Выполнение тестов при этом производится либо оператором в ручном режиме, либо системой, которая эмулирует поведение оператора


Особенности тестирования пользовательского интерфейса 2/2
• При сборе информации о выполнении тестовых примеров обычно применяются технологии анализа выводимых на экран форм и их элементов (в случае графического интерфейса) или выводимого на экран текста (в случае текстового), а не проверка значений тех или иных переменных, устанавливаемых программной системой
• Под полнотой покрытия пользовательского интерфейса понимается то, что в результате выполнения всех тестовых примеров каждый интерфейсный элемент был использован хотя бы один раз во всех доступных режимах
• Отчеты о проблемах в пользовательском интерфейсе могут включать в себя как описания несоответствий требований и реального поведения системы, так и описания проблем в требованиях к пользовательскому интерфейсу. Основной источник проблем в этих требованиях - их тестонепригодность, вызванная расплывчатостью формулировок и неконкретностью

Функциональное тестирование пользовательского интерфейса
Функциональное тестирование GUI состоит из пяти фаз:
• Анализ требований к пользовательскому интерфейсу
• Разработка тест-требований и тест-планов для проверки пользовательского интерфейса
• Выполнение тестовых примеров и сбор информации о выполнении тестов
• Определение полноты покрытия пользовательского интерфейса требованиями
• Составление отчетов о проблемах в случае несовпадения поведения системы и требований либо в случае отсутствия требований на отдельные интерфейсные элементы


Типы требований к пользовательскому интерфейсу
Проверка требований к пользовательскому интерфейсу:
• Требования к внешнему виду пользовательского интерфейса и формам взаимодействия с пользователем
• Требования по доступу к внутренней функциональности системы при помощи пользовательского интерфейса


Полнота покрытие пользовательского интерфейса
При определении понятия покрытия пользовательского
интерфейса можно ввести следующие его уровни:
• Функциональное покрытие
• Структурное покрытие
• Структурное покрытие с учетом состояния элементов интерфейса и внутреннего состояния системы


Методы проведения тестирования пользовательского интерфейса
Функциональное тестирование пользовательского интерфейса
может проводиться различными методами:
• Ручное тестирование (контроль проводится человеком)
• Автоматическое тестирование (используются программные инструменты, эмулирующие поведение тестировщика)


Плюсы и минусы ручного тестирования
Плюсы:
• Контроль корректности проводится человеком
• Поиск «косметических» дефектов
Анализ успешности прохождения теста будет выполняться не по формальным признакам, а согласно человеческому восприятию
Минусы:
• Требуются значительные человеческие и временные ресурсы
• При проведении регрессионного тестирования и вообще любого повторного тестирования - на каждой итерации повторного тестирования пользовательского интерфейса требуется участие тестировщика-оператора


Плюсы и минусы автоматического тестирования
Плюсы:
• Снижение стоимости тестирования
• Высокая скорость выполнения
• Больший объем покрытия
• Не требуется участие оператора-тестировщика при проведении регрессионного тестирования или любого другого перетестирования продукта
Минусы:
• Анализ успешности прохождения теста будет выполняться по формальным признакам
• Невозможность поиска «косметических» дефектов
• Высокая стоимость поддержки по сравнению с «обычными» функциональными тестами


Автоматизация тестирования UI
Рассмотрим основные подходы к автоматизации тестирования
графического интерфейса пользователя:
• Координатный метод
• Распознавание образов
• Подход, использующий механизмы реализации специальных возможностей (accessibility) и особенности реализации некоторых
GUI фреймворков


Координатный метод 1/3
При использовании координатного метода каждый элемент
графического интерфейса пользователя ищется по
координатам, заданным относительно окна или экрана
Плюсы подхода:
• Быстрая разработка тестов
• Простота поиска элементов при неизменности условий
Минусы:
• Крайне дорогая поддержка тестов
• Зависимость тестов от настроек платформы (разрешение, шрифты,
DPI, ...)
• Невозможность отслеживания состояний объекта (активна кнопка или нет, установлен флажок у checkbox’a или не установлен, и т.д.)


Координатный метод 2/3
Кнопка
“Отправка данных”
Координаты верхнего левого угла и размер элемента (заданы относительно окна приложения)
Координаты элемента
(заданы относительно экрана или рабочего стола)

Координатный метод 3/3
Пример теста, использующего координатный метод:
def main():
waitForObject(":_QWidget")
sendEvent("QResizeEvent", ":_QWidget", 22, 22, 769, 474)
waitForObject(":_QGraphicsItem")
mouseClick(":_QGraphicsItem", 221, 193, 1, Qt.LeftButton)
waitForObject(":_QLineEdit")
dragItemBy(":_QLineEdit", 153, -191, 26, 198, 1, Qt.LeftButton)
waitForObject(":_QLineEdit")
sendEvent("QMouseEvent", ":_QLineEdit", QEvent.MouseButtonRelease, 179, 7,
Qt.LeftButton, 1)
waitForObject(":MDC: Авторизация_QGraphicsView")
type(":MDC: Авторизация_QGraphicsView", "")
waitForObject(":MDC: Авторизация_QGraphicsView")
type(":MDC: Авторизация_QGraphicsView", "
squish@mail.ru
")
waitForObject(":MDC: Авторизация_QGraphicsView")
type(":MDC: Авторизация_QGraphicsView", "")
waitForObject(":MDC: Авторизация_QGraphicsView")
type(":MDC: Авторизация_QGraphicsView", "1234")
waitForObject(":MDC: Авторизация_CStartUpWidget")
sendEvent("QMoveEvent", ":MDC: Авторизация_CStartUpWidget", 577, 70, 734, 62)
mouseClick(":MDC: Авторизация_QWidget", 66, 372, 1, Qt.LeftButton)
waitForObject(":MDC v1.0.3.1.nightly_CContactListWidget")

Доступ ко кногим UI элементам и (работа с ними) происходит через указание координат

Распознавание образов 1/2
В основу данного метода тестирования положен метод поиска
элементов UI с использованием распознавания образов и
(или) сравнение с образцом
Плюсы подхода:
• Быстрая разработка тестов
• Простота поиска элементов при неизменности условий
Минусы:
• Крайне дорогая поддержка тестов
• Зависимость тестов от настроек платформы (разрешение, шрифты,
DPI, ...)
• Низкая «интеллектуальность» тестов


Распознавание образов 2/2
Пример теста, построенного на системе распознавания
образов:
• Запустить приложение
• Найти главное окно приложения
• Найти требуемый элемент, сравнив с шаблоном
• Произвести действие

Главное окно приложения
Шаблон для поиска
UI элемента
Действие
Click ( )

Технология MSAA
Microsoft Active Accessibility (MSAA) – компонент Microsoft
Windows на основе технологии COM, предоставляющий интерфейс к вспомогательных технологиям.
• Версия 1.0 была разработана в 1997 году и поддерживается до сих пор во всех версиях Windows с периодическими исправлениями, улучшениями и расширениями.
• Преемник данной технологии – Microsoft UI Automation (поддержка введена в
Windows Vista и .NET Framework 3.0)

Архитектура MSAA
Как это применить для тестирования?

Практическое применение MSAA
Тестируемое приложение
Средство автоматизации
FindElement(), click(), pressButton(), select(), …

Атрибуты MSAA 1/2
Рассмотрим 4 критических аттрибута, ассоциированных с
элементами графического интерфейса в MSAA:
• Роль (Role) – информация о типе элемента графического интерфейса
• Имя (Name) –имя элемента графического интерфейса
• Значение (Value) – значение, хранящееся в элементе графического интерфейса
• Состояние (State) – аттрибут, характеризующий состояние объекта в некоторый момент времени

Атрибуты MSAA 2/2

Технология AT-SPI
Assistive Technologies Service Provider Interface (AT-SPI) – это технология для поддержки специальный возможностей (программы чтения с экрана, экранные лупы, и т.д.)
• Первоначально разрабатывался для GNOME, но на данный момент рассматривается как Linux стандарт
• Поддержка AT-SPI присутствует в большинстве GUI фреймворках (GTK+,
Java/Swing, Qt) и приложениях (Mozilla, OpenOffice)

Сравнение MSAA и AT-SPI
MSAA (Windows)
AT-SPI (Linux)

Выбранный framework и решение задачи автоматизации
Проблема:
• Не все GUI приложения можно легко автоматизировать. Интерфейс, написанный с использованием некоторых фреймворков, легко автоматизировать не получится.
Положительная сторона:
• Многие средства разработки GUI предоставляют большой объем динамической информации, ассоциированной с объектом, что позволяет решить проблему автоматизации с минимумом затрат

Сравнение разных фреймворков с точки зрения testability (Qt)

Сравнение разных фреймворков с точки зрения testability (SWT)

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

Примеры дефектов (ручное выполнение тестов)
Пример приложения
1 2
3

Материалы и источники

The Art of Software Testing. Glenford J. Myers

Материалы сайта http://softwaretestingfundamentals.com

Материалы сайта http://www.onestoptesting.com

Материалы сайта http://www.sqatester.com
• Материалы сайта http://www.software-testing.ru/
• Материалы сайта http://www.intuit.ru/
• Материалы сайта http://ru.wikipedia.org

http://en.wikipedia.org/wiki/Code_coverage

http://www.testingeducation.org/BBST/testdesign/BBSTTestDesign20 11pfinal.pdf

http://www.testandtry.com/2010/02/01/5-great-automation-tools- based-on-image-recognition

Домашнее задание - задача
Разработайте любым из способов, рассказанных на лекции, автоматизацию следующего процесса в windows:
• Запуск программы «Калькулятор»
• Вычисление значения «2^7+4»
• Проверка что получившийся результат равен 132 (если выбранный метод, позволяет проверить корректность результата)
В качестве ответа пришлите программу/скрипт

Дополнительные слайды

Тестирование удобства использования (Usability testing)
Юзабилити-тестирование (Usability testing):
• Исследование, выполняемое с целью определения, удобен ли некоторый искусственный объект для его предполагаемого применения
Цели юзабилити-тестирования:
• Выявление сильных и слабых мест в интерфейсе для дальнейшего улучшения его в ходе итерационного процесса разработки
• Оценка общего качества интерфейса – например, для выбора одного из двух возможных вариантов


Примеры «неюзабильных» пользовательских интерфейсов

Тестирование удобства использования – этапы тестирования
Этапы тестирования удобства использования
пользовательского интерфейса:
• Исследовательское – проводится после формулирования требований к системе и разработки прототипа интерфейса
• Оценочное – проводится после разработки низкоуровневых требований и детализированного прототипа пользовательского интерфейса. Оценочное тестирование углубляет исследовательское и имеет ту же цель
• Валидационное – проводится ближе к этапу завершения разработки. На этом этапе проводится анализ соответствия интерфейса программной системы стандартам, регламентирующим вопросы удобства интерфейса, проводится общее тестирование всех компонентов пользовательского интерфейса с точки зрения конечного пользователя
• Сравнительное – данный вид тестирования может проводиться на любом этапе разработки интерфейса.


Тестирование удобства использования - оценка
Тестирование удобства пользования дает оценку уровня
удобства использования приложения по следующим пунктам :
• Производительность, эффективность (efficiency) – сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д
• Правильность (accuracy) – сколько ошибок сделал пользователь во время работы с приложением
• Активизация в памяти (recall) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя)
• Эмоциональная реакция (emotional response) – как пользователь себя чувствует после завершения задачи – растерян, испытал стресс. Порекомендует ли пользователь систему своим друзьям


Тестирование удобства использования – стадии теста
Юзабилити-тестирование можно разбить на следующие этапы:
• Подготовка – подготовка и проверка оборудования и места тестирования, начального состояния системы, наличия всех необходимых материалов – задания, мануалов и т.п.
• Введение – приветствие участника, пояснение цели теста и процесса, предупреждение о записи действий и слов участника и т.д.
• Непосредственно тестирование – роль проводящего тестирование минимальна, говорить («думать вслух») и делать должен участник
• «Разбор полетов» – вопросы участнику на тему субъективного удовлетворения от работы, замечаний и предложений, пояснения каких-либо действий участника в ходе теста

Тестирование специальных возможностей
(Accessibility testing)
Тестирование специальных возможностей (Accessibility
testing) – проверка возможности использования
программного обеспечения людьми с ограниченными
возможностями, такими как:
• Нарушения зрения
• Нарушения подвижности
• Нарушения слуха
• Нарушения когнитивной функции

Тестирование специальных возможностей - инструменты
Компоненты специальных возможностей в операционной
системе Windows:
• Экранный диктор
• Экранная лупа
• Распознавание речи
• Экранная клавиатура


Тестирование специальных возможностей – примеры тестов
Поддержка специальных возможностей:
• Проверка правильной работы пользовательского интерфейса на дисплее с высоким DPI
• Проверка правильной работы пользовательского интерфейса в высококонтрастном режиме
• Проверка правильной работы пользовательского интерфейса при использовании экранной лупы
• Проверка доступности с клавиатуры элементов управления пользовательского интерфейса
• Проверка пользовательского интерфейса с использованием специализированного ПО


Тестирование специальных возможностей – примеры тестов

Проверку визуальных режимов, включая большие шрифты, высокие значения DPI, высококонтрастные темы, частоту мигания курсора и его ширину

Тестирование поддержки мультимодальности (доступно для восприятия различными органами чувств)

Тестирование доступности клавиатуры: вся функциональность приложения должна быть доступна с клавиатуры

Тестирование программного доступа. Проверка надлежащей поддержки модели UIA для пользования сторонними технологиями специальных возможностей

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

Тестирование других показателей системы. Тестирование должно определить, соответствует ли ожидаемому поведение в отношении системных параметров

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

Тестирование на соответствие требованиям, изложенных в Voluntary Product
Accessibility Template (Section 508 of Rehabilitation Act)

Тестирование специальных возможностей – юридический аспект
• Правительственные организации США должны учитывать поддержку специальных возможностей при исследовании рынка решений и приобретать технологии, которые максимально соответствуют требованиям к специальным возможностям (секция
508 закона США о реабилитации)
• Согласно разделу 508, все электронные и информационные технологии, поставляемые, разрабатываемые или эксплуатируемые федеральными органами, должны быть доступны для людей с ограниченными возможностями

Секция 508 закона США о реабилитации - пример
Criteria
Supporting
Features
Remarks and explanations
Section 1194.21 Software
Applications and Operating
Systems
Generally Supported Windows 7 includes multiple improvements in the assistive technology and accessibility feature. The on- screen keyboard and Magnifier have been extensively updated and the Windows Automation Application
Programming Interface (API), has been updated to facilitate assistive technology and information technology interoperability. The Windows Automation API includes improved performance and features of User Interface (UI) Automation, increased interoperability between the Microsoft Active Accessibility
(MSAA), and support for W3C Accessible Rich Internet Applications Specification (ARIA). Please refer to the
Microsoft Developer Network Windows Automation API: Overview for additional information.
Windows 7 follows standard conventions for keyboard navigation. For instances where the keyboard interface is not intuitive (for example, by using the Tab, Enter, Escape keys or the arrow keys), the keyboard interface is documented in the online help.
Minor exceptions in individual features are noted in the main VPAT.
Additional Windows accessibility features information can be found on the
Windows 7 features site
Section 1194.22 Web-based internet information and applications
Not applicable
Section 1194.23
Telecommunications Products
Supported
Closed-Captioning within Windows Media Player and Windows Media Center related areas are supported; all else are not applicable.
Section 1194.24 Video and Multi- media Products
Supported
Windows Media Player and Windows Media Center are applicable; all else are not applicable
Section 1194.25 Self-Contained,
Closed Products
Not applicable

Инструменты 1/2
Модульное тестирование:
• xUnit семейство (PHPUnit, NUnit, CPPUnit, и т.д.)
Тестирование графического интерфейса:

Window Tester Pro
– тестирование RCP и SWT приложений

LDTP
(Linux Desktop Testing Project) – тестирование GUI на Linux и
(уже) Windows

PyWinAuto
– модуль для Python, предназначенный для тестирования GUI на Windows

Sikuli
– средство автоматизации GUI приложений, использующее распознавание образов

Инструменты 2/2
Тестирование на соответствие стандартам (conformance
testing):

Khronos Conformance
(соответствие стандартам OpenCL, OpenGL,
WebGL и т.д.)
Тестирование поддержки специальных возможностей
(accessibility testing):

UI Automation Verify (UIA Verify)

UI Accessibility Checker (AccCheсker)

Inspect
Тестирование безопасности:

Microsoft SDL RegEx Fuzzer
– средство для Fuzz тестирования

Microsoft Attack Surface Analyzer
– средство для сравнивания состояний системы


Поделитесь с Вашими друзьями:


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал