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

Graphical user interface testing

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

Генерация тестовых примеров

Для создания набора контрольные примеры, дизайнеры тестов попытаться охватить все функциональные возможности системы и полностью использовать GUI сам. Сложность выполнения этой задачи двоякая: иметь дело с размером домена и с последовательностями. Кроме того, тестировщики сталкиваются с большими трудностями, когда им приходится делать регрессионное тестирование.

В отличие от CLI (интерфейс командной строки), графический интерфейс может содержать дополнительные операции, которые необходимо протестировать. Относительно небольшая программа, такая как Microsoft Word Pad имеет 325 возможных операций с графическим интерфейсом.[1] В большой программе количество операций легко может быть порядок величины больше.

Вторая проблема - это проблема последовательности. Некоторые функции системы могут быть выполнены только с помощью последовательности событий графического интерфейса. Например, чтобы открыть файл, пользователю может потребоваться сначала щелкнуть меню «Файл», затем выбрать операцию «Открыть», указать имя файла в диалоговом окне и сфокусировать приложение на новом открытом окне. Увеличение количества возможных операций экспоненциально увеличивает проблему упорядочивания. Это может стать серьезной проблемой, когда тестировщик создает тестовые примеры вручную.

Регрессионное тестирование также часто возникает проблема с графическим интерфейсом. Графический интерфейс пользователя может значительно измениться, даже если базовое приложение этого не сделает. Затем тест, предназначенный для прохождения определенного пути через графический интерфейс, может завершиться неудачно, поскольку кнопка, пункт меню или диалоговое окно могли изменить расположение или внешний вид.

Эти проблемы привели к автоматизации проблемной области тестирования графического интерфейса. Было предложено множество различных методов для автоматического создания наборы тестов полные и имитирующие поведение пользователя.

Большинство методов тестирования пытаются основываться на тех, которые ранее использовались для тестирования программ CLI (интерфейса командной строки), но они могут иметь проблемы с масштабированием при применении к графическому интерфейсу пользователя. Например, Конечный автоматмоделирование на основе[2][3] - когда система моделируется как конечный автомат и программа используется для генерации тестовых примеров, которые проверяют все состояния - может хорошо работать в системе с ограниченным числом состояний, но может стать слишком сложной и громоздкой для графического интерфейса пользователя (см. также модельное тестирование).

Планирование и искусственный интеллект

Новый подход к созданию наборов тестов, адаптированный на основе технологии CLI.[4] предполагает использование системы планирования.[5] Планирование - это хорошо изученный метод от искусственный интеллект (AI) область, которая пытается решить проблемы, включающие четыре параметра:

  • начальное состояние,
  • состояние цели,
  • набор операторов, и
  • набор объектов для работы.

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

В [1] авторы использовали планировщик IPP[6] чтобы продемонстрировать эту технику. Пользовательский интерфейс системы сначала анализируется для определения возможных операций. Они становятся операторами, используемыми в задаче планирования. Затем определяется начальное состояние системы и указывается целевое состояние, которое, по мнению тестировщика, позволит провести тестирование системы. Система планирования определяет путь от начального состояния к целевому состоянию, которое становится планом тестирования.

Использование планировщика для создания тестовых примеров имеет некоторые преимущества перед созданием вручную. Система планирования по самой своей природе генерирует решения проблем планирования таким образом, что это очень выгодно для тестировщика:

  1. Планы всегда в силе. Результатом работы системы является либо действующий и правильный план, в котором используются операторы для достижения состояния цели, либо отсутствие плана вообще. Это полезно, поскольку при создании набора тестов вручную может быть потрачено много времени из-за недопустимых тестовых случаев, которые, по мнению тестировщика, будут работать, но не сработали.
  2. Система планирования обращает внимание на порядок. Часто для тестирования определенной функции тестовый пример должен быть сложным и проходить через графический интерфейс, где операции выполняются в определенном порядке. Когда это делается вручную, это может привести к ошибкам, а также может быть довольно сложным и трудоемким.
  3. Наконец, что наиболее важно, система планирования ориентирована на достижение цели. Тестировщик фокусирует создание набора тестов на самом важном - проверке функциональности системы.

При создании набора тестов вручную тестировщик больше сосредоточен на том, как протестировать функцию (то есть конкретный путь через графический интерфейс). При использовании системы планирования путь определяется, и тестировщик может сосредоточиться на том, какую функцию тестировать. Дополнительным преимуществом этого является то, что система планирования никоим образом не ограничивается при создании пути и часто может найти путь, который никогда не ожидался тестером. Это очень важная проблема, с которой нужно бороться.[7]

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

Сложность заключается в создании наборов тестов, имитирующих использование системы «новичком». С помощью Генетические алгоритмы были предложены для решения этой проблемы.[7] Пути новичков в системе - это не случайные пути. Во-первых, новичок со временем научится и, как правило, не будет повторять одни и те же ошибки повторно, а, во-вторых, новичок следует плану и, вероятно, имеет некоторые знания в области или системе.

Генетические алгоритмы работают следующим образом: набор «генов» создается случайным образом, а затем подвергается некоторой задаче. Гены, которые лучше всего выполняют задачу, сохраняются, а гены, которые не делают, отбрасываются. Процесс повторяется снова: выжившие гены реплицируются, а остальная часть набора заполняется более случайными генами. В конце концов, один ген (или небольшой набор генов, если есть некоторый пороговый набор) будет единственным геном в наборе и, естественно, лучше всего подходит для данной проблемы.

В случае тестирования GUI метод работает следующим образом. Каждый ген по сути представляет собой список случайных целочисленных значений некоторой фиксированной длины. Каждый из этих генов представляет собой путь через графический интерфейс. Например, для данного дерева виджетов первое значение в гене (каждое значение называется аллелем) будет выбирать виджет для работы, следующие аллели затем будут заполнять ввод в виджет в зависимости от количества возможных вводов к виджету (например, в раскрывающемся списке будет один вход… выбранное значение списка). Успешность генов оценивается по критерию, который награждает лучших «новичков» в поведении.

Система, выполняющая это тестирование для оконной системы X, но расширяемая до любой оконной системы, описана в.[7] В X Window система обеспечивает функциональность (через XServer и протокол редакторов), чтобы динамически отправлять ввод графического интерфейса и получать вывод графического интерфейса из программы без прямого использования графического интерфейса. Например, можно вызвать XSendEvent (), чтобы имитировать щелчок по раскрывающемуся меню и так далее. Эта система позволяет исследователям автоматизировать создание и тестирование генов, поэтому для любого тестируемого приложения можно создать набор тестовых примеров для начинающих пользователей.

Запуск тестовых случаев

Сначала стратегии были перенесены и адаптированы из стратегий тестирования CLI.

Захват позиции мыши

Популярным методом, используемым в среде CLI, является захват / воспроизведение. Воспроизведение захвата - это система, в которой экран системы «захватывается» как растровое изображение в разное время во время тестирования системы. Этот захват позволил тестеру «воспроизвести» процесс тестирования и сравнить экраны на этапе вывода теста с ожидаемыми экранами. Эту проверку можно автоматизировать, поскольку экраны будут идентичными, если дело пройдено, и разными, если дело не удастся.

Использование захвата / воспроизведения работало довольно хорошо в мире CLI, но возникают значительные проблемы, когда кто-то пытается реализовать его в системе на основе графического интерфейса.[8] Наиболее очевидная проблема заключается в том, что экран в системе с графическим пользовательским интерфейсом может выглядеть иначе, в то время как состояние базовой системы остается прежним, что делает автоматическую проверку чрезвычайно сложной. Это связано с тем, что графический интерфейс позволяет графическим объектам различаться по внешнему виду и размещению на экране. Шрифты могут отличаться, цвета и размеры окон могут отличаться, но вывод системы в основном тот же. Это было бы очевидно для пользователя, но не для автоматизированной системы проверки.

Запись событий

Чтобы справиться с этой и другими проблемами, тестировщики пошли «под капот» и собрали данные взаимодействия с графическим интерфейсом пользователя из базовой оконной системы.[9] Благодаря фиксации оконных «событий» в журналах взаимодействия с системой теперь имеют формат, не связанный с внешним видом графического интерфейса. Теперь фиксируются только потоки событий. Необходима некоторая фильтрация потоков событий, поскольку потоки событий обычно очень подробны и большинство событий не имеют прямого отношения к проблеме. Этот подход можно упростить, если использовать MVC архитектура, например, и сделать представление (то есть GUI здесь) максимально простым, в то время как модель и контроллер содержат всю логику. Другой подход - использовать программное обеспечение встроенный вспомогательные технологии, чтобы использовать HTML интерфейс или трехуровневая архитектура это также позволяет лучше отделить пользовательский интерфейс от остальной части приложения.

Другой способ запустить тесты в графическом интерфейсе - встроить драйвер в графический интерфейс, чтобы команды или события можно было отправлять в программное обеспечение из другой программы.[7] Этот метод прямой отправки событий и получения событий от системы очень желателен при тестировании, поскольку тестирование ввода и вывода может быть полностью автоматизировано, а ошибки пользователя исключены.

Смотрите также

Рекомендации

  1. ^ а б Атиф М. Мемон, Марта Э. Поллак и Мэри Лу Соффа. Использование подхода, ориентированного на достижение цели, для создания тестовых примеров для графического интерфейса пользователя. ICSE '99 Материалы 21-й международной конференции по программной инженерии.
  2. ^ Дж. М. Кларк. Автоматическая генерация тестов на основе поведенческой модели. В материалах конференции по качеству программного обеспечения Тихоокеанского Северо-Запада. IEEE Press, май 1998 г.
  3. ^ С. Эсмелиоглу и Л. Апфельбаум. Автоматизированная генерация, выполнение и отчетность тестов. В материалах конференции по качеству программного обеспечения Тихоокеанского Северо-Запада. IEEE Press, октябрь 1997 г.
  4. ^ A. Howe, A. von Mayrhauser и R. T. Mraz. Генерация тестовых примеров как проблема планирования ИИ. Автоматизированная разработка программного обеспечения, 4: 77-106, 1997.
  5. ^ Атиф М. Мемон, Марта Э. Поллак, и Мэри Лу Соффа. Создание тестовых случаев с иерархическим графическим интерфейсом пользователя с использованием автоматизированного планирования. IEEE Trans. Софтв. Англ., Т. 27, нет. 2, 2001, стр. 144-155, IEEE Press.
  6. ^ Дж. Келер, Б. Небель, Дж. Хоффман и Ю. Димопулос. Расширение графиков планирования до подмножества ADL. Конспект лекций по информатике, 1348: 273, 1997.
  7. ^ а б c d Д. Дж. Касик и Х. Г. Джордж. К автоматической генерации тестовых скриптов для начинающих пользователей. В MJ Tauber, V. Bellotti, R. Jeffries, JD Mackinlay и J. Nielsen, редакторах, Proceedings of the Conference on Human Factors in Computing Systems: Common Ground, pages 244-251, New York, 13-18 апреля 1996 г., ACM Press. [1]
  8. ^ L.R. Кеппле. Черное искусство тестирования графического интерфейса. Журнал д-ра Добба программных средств, 19 (2): 40, февраль 1994 г.
  9. ^ М. Л. Хэммонтри, Дж. Дж. Хендриксон и Б. В. Хенсли. Интегрированные инструменты сбора и анализа данных для исследования и тестирования в графических пользовательских интерфейсах. В P. Bauersfeld, J. Bennett и G. Lynch, редакторах, Proceedings of the Conference on Human Factors in Computing System, pages 431-432, New York, NY, USA, May 1992. ACM Press.