Otvety.docx

12. Тестирование интерфейса пользователя. Типы тестируемых интерфейсов, их особенности.

Интеграционные тесты обычно проводят на 2 уровнях:

1.Программный интерфейс API

2.Пользовательский интерфейс. Пользовательский ​интерфейс​­ часть программной системы. Соответственно, на пользовательский ​интерфейс​пишутся функциональные и низкоуровневые требования, по которым затем составляются тест­требования и тест­планы. При этом, как правило, требования определяют реакцию системы на каждый ввод пользователя (при помощи клавиатуры, мыши или иного устройства ввода) и вид информационных сообщений системы, выводимых на экран, ​печатающее устройство​или иное устройство вывода. При верификации таких требований речь идет о проверке функциональной полноты пользовательского интерфейса ­ насколько реализованные функции соответствуют требованиям, корректно ли выводится ​информация​на экран.

CLI(commandlineinterface)

Обычно в интеграционных тестах делают упор на программный интерфейс. Графический интерфейс можно тестировать 2 способами:

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

2)передача сообщений с использованием идентификаторов элементов интерфейса.

Веб­интерфейс. Тестирование веб­интерфейса заключается в эмуляции HTTP­протокола.

Тестирование графического интерфейса.

Цели:

1.Поиск ошибок функциональности.

2.Поиск необработанных исключений.

3.Потеря или искажение вводимых данных.

4.Несоответствие интерфейса и документации(отсутствие или искажение элементов).

Функциональное ​тестирование пользовательского интерфейса​состоит из пяти фаз:

●анализ требований к пользовательскому интерфейсу;

●разработка тест­требований и тест­планов для проверки пользовательского интерфейса;

●выполнение тестовых примеров и сбор информации о выполнении тестов;

●определение полноты покрытия пользовательского интерфейса требованиями;

●составление отчетов о проблемах в случае несовпадения поведения системы и требований либо в случае отсутствия требований на отдельные интерфейсные элементы.

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

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

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

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

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

13. Вопросы автоматизации процесса тестирования графического интерфейса.

Тестирование удобства использования пользовательских интерфейсов

Удобство использования​пользовательского интерфейса (usability) ­ показатель его качества, который определяет количество усилий, необходимых для изучения принципов работы с программной системой при помощи данного интерфейса, ее использования, подготовки входных данных и интерпретации выходных. Иначе говоря, ​удобство использования​определяет степень простоты доступа пользователя к функциям системы, предоставляемым через человеко­машинный (пользовательский) ​интерфейс​.

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

На ​удобство использования​пользовательского интерфейса влияют следующие факторы:

●легкость обучения​­ быстро ли человек учится использовать систему;

●эффективность обучения​­ быстро ли человек работает после обучения;

●запоминаемость обучения​­ легко ли запоминается все, чему человек научился;

●ошибки​­ часто ли человек допускает ошибки в работе;

●общая удовлетворенность​­ является ли общее впечатление от работы с системой положительным.

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

ошибок), а также им предлагается высказать собственные впечатления от системы при помощи заполнения опросных листов.

Перед usability­тестированием следует составлять сценарии. Сценарии должны:

1)максимально соответствовать действиям пользователя;

2)охватывать наиболее важные части интерфейса;

3)среднее время выполнения сценария должно варьироваться от 30 до 60 минут.

Выделяют следующие этапы ​тестирования удобства использования​пользовательского интерфейса.

1.Исследовательское​­ проводится после формулирования требований к системе и разработки прототипа интерфейса. Основная цель на этом этапе ­ провести высокоуровневое обследование интерфейса и выяснить, позволяет ли он с достаточной степенью эффективности решать задачи пользователя.

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

3.Валидационное​­ проводится ближе к этапу завершения разработки. На этом этапе проводится анализ соответствия интерфейса программной системы стандартам, регламентирующим вопросы удобства интерфейса (например ISO 13407, ISO 9126), проводится общее тестирование всех компонент пользовательского интерфейса с точки зрения конечного пользователя. Под компонентами интерфейса здесь понимается как его программная реализация, так и система помощи и руководство пользователя. Также на данном этапе проверяется отсутствие дефектов удобства использования интерфейса, выявленных на предыдущих этапах.

4.Сравнительное​­ данный вид тестирования может проводиться на любом этапе разработки интерфейса. В ходе сравнительного тестирования сравниваются два или более вариантов реализации пользовательского интерфейса.

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

14. Тестирование удобства использования.

Тестирование удобства пользования или Usability Testing

Иногда мы сталкиваемся с непонятными, нелогичными приложениями, многие функции и способы использования которых часто не очевидны. После такой работы редко возникает желание использовать приложение снова, и мы ищем более удобные аналоги. Для того чтобы приложение было популярным, ему мало быть функциональным – оно должно быть еще и удобным. Если задуматься, интуитивно понятные приложения экономят нервы пользователям и затраты работодателя на обучение. А значит они более конкурентоспособные! Поэтому тестирование удобства использования, о котором пойдет речь далее является неотъемлемой частью тестирования любых массовых продуктов.

Тестирование удобства пользования ­ это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. [​ISO 9126​]

Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:

●производительность, эффективность (​efficiency​) ­ сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.? (​меньше ­ лучше​)

●правильность (​accuracy​) ­ сколько ошибок сделал пользователь во время работы с приложением? (​меньше ­ лучше​)

●активизация в памяти (​recall​) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (​повторное выполнение операций после перерыва должно проходить быстрее чем у нового пользователя​)

●эмоциональная реакция (​emotional response​) – как пользователь себя чувствует после завершения задачи ­ растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (​положительная реакция ­ лучше​)

Уровни проведения

Проверка удобства использования может проводиться как по отношению к готовому продукту, посредством тестирования черного ящика (black box testing), так и к интерфейсам приложения (API), используемым при разработке ­ тестирование белого ящика (white box testing). В этом случае проверяется удобство использования внутренних

объектов, классов, методов и переменных, а также рассматривается удобство изменения, расширения системы и интеграции ее с другими модулями или системами. Использование удобных интерфейсов (API) может улучшить качество, увеличить скорость написания и поддержки разрабатываемого кода, и как следствие улучшить качество продукта в целом.

Отсюда становится очевидно, что тестирование удобства пользования может производиться на разных уровнях разработки программного обеспечения: ​модульном​, интеграционном​, ​системном и ​приемочном​. При этом оно целиком и полностью будет зависит от того, кто будет использовать приложение на выделенном конкретном уровне ­ разработчик, бизнес пользователь системы и т.д.

Советы по улучшению удобства пользования

Для дизайна удобных приложений полезно следовать ​принципам «пока­йока» или fail­safe​. У нас это более известно как «защита от дурака». Простой пример, если поле требует цифровое значение, логично ограничить пользователю диапазон ввода только цифрами – будет меньше случайных ошибок.

Для повышения юзабилити существующих приложений можно использовать ​цикл Демминга Plan­Do­Check­Act​, собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения.

Заблуждения о тестировании удобства пользования

1. Тестирование пользовательского интерфейса = Тестирование удобства пользования

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

2. Тестирование удобства пользования можно провести без участия эксперта

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