Тестирование графического пользовательского интерфейса
 | Эта статья нуждается в дополнительных цитатах для проверки . ( март 2023 г. ) |
В обеспечения разработке программного тестирование графического пользовательского интерфейса — это процесс тестирования (GUI) продукта графического пользовательского интерфейса на предмет его соответствия спецификациям. Обычно это делается с помощью различных тестовых примеров .
Генерация тестовых примеров
[ редактировать ]Чтобы создать набор тестовых примеров , дизайнеры тестов пытаются охватить все функциональные возможности системы и полностью реализовать сам графический интерфейс . Трудность в выполнении этой задачи двоякая: иметь дело с размером домена и последовательностями. Кроме того, тестировщик сталкивается с большими трудностями, когда ему приходится проводить регрессионное тестирование .
В отличие от системы CLI (интерфейс командной строки), графический интерфейс может содержать дополнительные операции, которые необходимо протестировать. Относительно небольшая программа, такая как Microsoft WordPad, имеет 325 возможных операций графического интерфейса. [1] В большой программе количество операций легко может быть на порядок больше.
Вторая проблема – это проблема последовательности. Некоторая функциональность системы может быть реализована только с помощью последовательности событий графического интерфейса. Например, чтобы открыть файл, пользователю может сначала потребоваться щелкнуть меню «Файл», затем выбрать операцию «Открыть», использовать диалоговое окно, чтобы указать имя файла, и сфокусировать приложение на вновь открытом окне. Увеличение количества возможных операций увеличивает проблему последовательности в геометрической прогрессии. Это может стать серьезной проблемой, если тестировщик создает тестовые примеры вручную.
Регрессионное тестирование часто является проблемой и для графических интерфейсов. Графический интерфейс может существенно измениться, даже если базовое приложение не изменится. Тест, предназначенный для прохождения определенного пути через графический интерфейс, может в этом случае завершиться неудачно, поскольку кнопка, пункт меню или диалоговое окно могут изменить местоположение или внешний вид.
Эти проблемы привели к автоматизации области тестирования графического пользовательского интерфейса. Было предложено множество различных методов автоматического создания наборов тестов полных , имитирующих поведение пользователя.
Большинство методов тестирования пытаются основываться на тех, которые ранее использовались для тестирования программ CLI, но они могут иметь проблемы с масштабированием при применении к графическим пользовательским интерфейсам. Например, конечных автоматов. моделирование на основе [2] [3] – где система моделируется как конечный автомат, а программа используется для создания тестовых примеров, проверяющих все состояния – может хорошо работать в системе с ограниченным числом состояний, но может оказаться слишком сложной и громоздкой для графического пользовательского интерфейса (см. также тестирование на основе моделей ).
Планирование и искусственный интеллект
[ редактировать ]Новый подход к созданию набора тестов, адаптированный на основе технологии CLI. [4] предполагает использование системы планирования. [5] Планирование — это хорошо изученный метод из области искусственного интеллекта (ИИ), который пытается решить проблемы, включающие четыре параметра:
- исходное состояние,
- целевое состояние,
- набор операторов и
- набор объектов, над которыми нужно работать.
Системы планирования
[ редактировать ]Системы планирования определяют путь от начального состояния к целевому состоянию с помощью операторов. В качестве простого примера задачи планирования, учитывая два слова и одну операцию, которая заменяет одну букву в слове на другую, целью может быть превращение одного слова в другое.
В [1] авторы использовали планировщик IPP [6] чтобы продемонстрировать эту технику. Пользовательский интерфейс системы сначала анализируется для определения возможных операций. Они становятся операторами, используемыми в задаче планирования. Затем определяется исходное состояние системы и указывается целевое состояние, которое, по мнению тестировщика, позволит протестировать систему. Система планирования определяет путь от исходного состояния к целевому состоянию, которое становится планом тестирования.
Использование планировщика для создания тестовых примеров имеет некоторые определенные преимущества по сравнению с созданием вручную. Система планирования по своей природе генерирует решения проблем планирования таким образом, что это очень выгодно для тестировщика:
- Планы всегда актуальны. Результатом работы системы является либо действительный и правильный план, в котором используются операторы для достижения целевого состояния, либо отсутствие плана вообще. Это выгодно, поскольку при создании набора тестов вручную можно потерять много времени из-за недопустимых тестовых примеров, которые, по мнению тестировщика, работали бы, но не сработали.
- Система планирования уделяет внимание порядку. Часто для тестирования определенной функции тестовый пример должен быть сложным и проходить через графический интерфейс, где операции выполняются в определенном порядке. Если это делается вручную, это может привести к ошибкам, а также может оказаться довольно сложным и трудоемким.
- Наконец, что наиболее важно, система планирования ориентирована на достижение цели. Тестировщик фокусирует создание набора тестов на самом важном — тестировании функциональности системы.
При создании набора тестов вручную тестер больше внимания уделяет тому, как протестировать функцию (т. е. конкретный путь через графический интерфейс). Благодаря использованию системы планирования путь контролируется, и тестировщик может сосредоточиться на том, какую функцию тестировать. Дополнительным преимуществом этого является то, что система планирования не имеет каких-либо ограничений при создании пути и часто может найти путь, который никогда не ожидался тестировщиком. Эта проблема очень важна для борьбы. [7]
Генетические алгоритмы
[ редактировать ]Другой метод создания тестовых примеров GUI имитирует работу начинающего пользователя. Опытный пользователь системы обычно следует прямым и предсказуемым путем через графический интерфейс, тогда как начинающий пользователь будет следовать более случайным путем. Тогда начинающий пользователь, скорее всего, исследует больше возможных состояний графического интерфейса, чем эксперт.
Трудность заключается в создании наборов тестов, которые имитируют использование системы «новичком». использовать генетические алгоритмы . Для решения этой проблемы было предложено [7] Пути новичков в системе не являются случайными путями. Во-первых, начинающий пользователь со временем научится и, как правило, не будет повторять одни и те же ошибки повторно, а во-вторых, начинающий пользователь следует плану и, вероятно, обладает некоторыми знаниями в предметной области или системе.
Генетические алгоритмы работают следующим образом: набор «генов» создается случайным образом, а затем подвергается некоторой задаче. Гены, которые лучше всего выполняют задачу, сохраняются, а те, которые не справляются, отбрасываются. Процесс снова повторяется, при этом выжившие гены реплицируются, а остальная часть набора заполняется более случайными генами. В конечном итоге один ген (или небольшой набор генов, если существует некоторый пороговый набор) станет единственным геном в наборе и, естественно, лучше всего подходит для данной проблемы.
В случае тестирования GUI метод работает следующим образом. Каждый ген, по сути, представляет собой список случайных целочисленных значений некоторой фиксированной длины. Каждый из этих генов представляет собой путь через графический интерфейс. Например, для данного дерева виджетов первое значение в гене (каждое значение называется аллелью) будет выбирать виджет для работы, следующие аллели затем будут заполнять входные данные виджета в зависимости от количества возможных входных данных. к виджету (например, раскрывающийся список будет иметь один ввод... выбранное значение списка). Успех генов оценивается по критерию, который вознаграждает лучшее поведение «новичка».
X-окно
[ редактировать ]Система для проведения такого тестирования для оконной системы X, но расширяемая для любой оконной системы, описана в разделе . [7] Система X Window предоставляет функциональные возможности (через XServer и протокол редактора) для динамической отправки входных данных графического интерфейса в программу и получения выходных данных графического интерфейса без непосредственного использования графического интерфейса. Например, можно вызвать XSendEvent() для имитации щелчка по раскрывающемуся меню и т. д. Эта система позволяет исследователям автоматизировать создание и тестирование генов, поэтому для любого тестируемого приложения можно создать набор тестовых сценариев для начинающих пользователей.
Запуск тестовых случаев
[ редактировать ]Сначала стратегии были перенесены и адаптированы из стратегий тестирования CLI.
Захват положения мыши
[ редактировать ]Популярный метод, используемый в среде CLI, — захват/воспроизведение. Воспроизведение с захватом — это система, в которой экран системы «захватывается» в виде растрового изображения в различные моменты тестирования системы. Этот захват позволил тестировщику «воспроизвести» процесс тестирования и сравнить экраны на этапе вывода теста с ожидаемыми экранами. Эту проверку можно автоматизировать, поскольку экраны будут идентичными, если кейс пройден успешно, и разными, если кейс не пройден.
Использование захвата/воспроизведения работает достаточно хорошо в мире CLI, но возникают серьезные проблемы при попытке реализовать его в системе с графическим интерфейсом. [8] Самая очевидная проблема, с которой можно столкнуться, заключается в том, что экран в системе с графическим интерфейсом может выглядеть по-разному, в то время как состояние базовой системы остается тем же, что чрезвычайно затрудняет автоматическую проверку. Это связано с тем, что графический интерфейс позволяет графическим объектам различаться по внешнему виду и расположению на экране. Шрифты могут быть разными, цвета и размеры окон могут различаться, но вывод системы в основном тот же. Это было бы очевидно для пользователя, но не очевидно для автоматизированной системы проверки.
Захват событий
[ редактировать ]Чтобы бороться с этой и другими проблемами, тестировщики залезли «под капот» и собрали данные взаимодействия с графическим интерфейсом из базовой оконной системы. [9] Записывая «события» окна в журналы, взаимодействие с системой теперь осуществляется в формате, который не связан с внешним видом графического пользовательского интерфейса. Теперь захватываются только потоки событий. Необходима некоторая фильтрация потоков событий, поскольку потоки событий обычно очень подробные и большинство событий не имеют прямого отношения к проблеме. Этот подход можно упростить, используя , например, архитектуру MVC и сделав представление (то есть графический интерфейс здесь) максимально простым, в то время как модель и контроллер содержат всю логику. программного обеспечения Другой подход заключается в использовании встроенной вспомогательной технологии , использовании интерфейса HTML или трехуровневой архитектуры , которая также позволяет лучше отделить пользовательский интерфейс от остальной части приложения.
Другой способ запуска тестов в графическом интерфейсе — встроить в графический интерфейс драйвер, чтобы команды или события можно было отправлять в программное обеспечение из другой программы. [7] Этот метод непосредственной отправки событий в систему и получения событий из системы весьма желателен при тестировании, поскольку тестирование ввода и вывода может быть полностью автоматизировано и исключены ошибки пользователя.
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ Jump up to: а б Атиф М. Мемон, Марта Э. Поллак и Мэри Лу Соффа. Использование целенаправленного подхода для создания тестовых примеров для графических интерфейсов. ICSE '99 Материалы 21-й международной конференции по программной инженерии.
- ^ Дж. М. Кларк. Автоматизированное создание тестов на основе поведенческой модели . В материалах Тихоокеанской северо-западной конференции по качеству программного обеспечения. IEEE Press, май 1998 г.
- ^ С. Эсмелиоглу и Л. Апфельбаум. Автоматизированное создание тестов, их выполнение и отчетность. В материалах Тихоокеанской северо-западной конференции по качеству программного обеспечения. IEEE Press, октябрь 1997 г.
- ^ А. Хоу, А. фон Майрхаузер и RT Мраз. Генерация тестовых примеров как проблема планирования ИИ . Автоматизированная разработка программного обеспечения, 4:77-106, 1997.
- ^ Атиф М. Мемон, Марта Э. Поллак и Мэри Лу Соффа. Генерация тестовых примеров иерархического графического пользовательского интерфейса с использованием автоматического планирования . IEEE Транс. Программное обеспечение англ., вып. 27, нет. 2, 2001, стр. 144–155, IEEE Press.
- ^ Дж. Келер, Б. Небель, Дж. Хоффман и Ю. Димопулос. Расширение графов планирования на подмножество ADL . Конспекты лекций по информатике, 1348:273, 1997.
- ^ Jump up to: а б с д DJ Касик и HG Джордж. На пути к автоматической генерации тестовых сценариев для начинающих пользователей. В М. Дж. Таубере, В. Беллотти, Р. Джеффрисе, Дж. Д. Маккинли и Дж. Нильсене, редакторах, Труды конференции по человеческому фактору в вычислительных системах: точки соприкосновения, страницы 244–251, Нью-Йорк, 13–18 апреля 1996 г., АКМ Пресс. [1]
- ^ Л. Р. Кеппл. Черное искусство тестирования графического интерфейса. Журнал программных инструментов доктора Добба, 19(2):40, февраль 1994 г.
- ^ ML Hammontree, JJ Hendrickson и BW Hensley. Интегрированные инструменты сбора и анализа данных для исследования и тестирования графических пользовательских интерфейсов . В П. Бауэрсфельде, Дж. Беннетте и Г. Линче, редакторах, Труды конференции по человеческому фактору в вычислительной системе, страницы 431–432, Нью-Йорк, штат Нью-Йорк, США, май 1992 г. ACM Press.