ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 10.01.2024
Просмотров: 86
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
операторы которого соответствуют действиям пользователя – вводу команд,
перемещению курсора, активизации пунктов меню и других интерфейсных элементов.
При выполнении автоматизированного теста инструмент тестирования имитирует действия пользователя, описанные в сценарии, и анализирует интерфейсную реакцию системы. При этом для определения ожидаемого состояния пользовательского интерфейса могут использоваться различные методы – либо анализ снимков экрана и сравнение их с эталонными, либо доступ к данным интерфейсных элементов средствами операционной системы
(например, доступ ко всем кнопкам окна по их дескрипторам и получение значений текста).
И при передаче информации в тестируемый интерфейс и при получении информации для анализа могут использоваться два способа доступа к элементам интерфейса [
7
]:
• позиционный, при котором доступ к элементу осуществляется при помощи задания его абсолютных (относительно экрана) или относительных
(относительно окна) координат и размеров;
• по идентификатору, при котором доступ к элементу осуществляется при помощи получения интерфейсного элемента при помощи его уникального идентификатора в пределах окна.
При внесении изменений в пользовательский интерфейс при использовании первого метода в результате проведения регрессионного
тестирования будет выявлено большое количество не прошедших тестов – достаточно изменения местоположения одного ключевого интерфейсного элемента, как все сценарии начнут работать неверно. Соответственно при таком методе автоматизации тестирования необходимо менять значительную часть сценариев в системе тестов при каждом изменении интерфейса системы. Такой метод автоматизации тестирования подходит для систем с устоявшимся и редко изменяемым интерфейсом.
Второй метод автоматизации тестирования более устойчив к изменению расположения интерфейсных элементов, но изменения тестовых примеров могут потребоваться и здесь в случае изменения логики работы интерфейсных элементов. Например, пусть в первой версии системы при нажатии на кнопку "Передать данные" передача данных начиналась сразу, и выводилось окно с индикатором прогресса. Сценарий тестового примера в этом случае включает в себя имитацию нажатия на кнопку и обращение к индикатору прогресса для получения значения прогресса в процентах.
Тестирование удобства пользования
Тестирование удобства пользования – тест, который можно назвать практически главным для всех интерактивных сервисов, взаимодействующих с пользователем – это тест на "usability" или на удобство использования. Такое тестирование одно из самых дорогих, потому что наиболее ценную информацию можно получить только от реальных пользователей, наблюдая за их работой с вашим сайтом – а такие исследования требуют дорогостоящей инфраструктуры и времени, их сложно автоматизировать. Это метод
перемещению курсора, активизации пунктов меню и других интерфейсных элементов.
При выполнении автоматизированного теста инструмент тестирования имитирует действия пользователя, описанные в сценарии, и анализирует интерфейсную реакцию системы. При этом для определения ожидаемого состояния пользовательского интерфейса могут использоваться различные методы – либо анализ снимков экрана и сравнение их с эталонными, либо доступ к данным интерфейсных элементов средствами операционной системы
(например, доступ ко всем кнопкам окна по их дескрипторам и получение значений текста).
И при передаче информации в тестируемый интерфейс и при получении информации для анализа могут использоваться два способа доступа к элементам интерфейса [
7
]:
• позиционный, при котором доступ к элементу осуществляется при помощи задания его абсолютных (относительно экрана) или относительных
(относительно окна) координат и размеров;
• по идентификатору, при котором доступ к элементу осуществляется при помощи получения интерфейсного элемента при помощи его уникального идентификатора в пределах окна.
При внесении изменений в пользовательский интерфейс при использовании первого метода в результате проведения регрессионного
тестирования будет выявлено большое количество не прошедших тестов – достаточно изменения местоположения одного ключевого интерфейсного элемента, как все сценарии начнут работать неверно. Соответственно при таком методе автоматизации тестирования необходимо менять значительную часть сценариев в системе тестов при каждом изменении интерфейса системы. Такой метод автоматизации тестирования подходит для систем с устоявшимся и редко изменяемым интерфейсом.
Второй метод автоматизации тестирования более устойчив к изменению расположения интерфейсных элементов, но изменения тестовых примеров могут потребоваться и здесь в случае изменения логики работы интерфейсных элементов. Например, пусть в первой версии системы при нажатии на кнопку "Передать данные" передача данных начиналась сразу, и выводилось окно с индикатором прогресса. Сценарий тестового примера в этом случае включает в себя имитацию нажатия на кнопку и обращение к индикатору прогресса для получения значения прогресса в процентах.
Тестирование удобства пользования
Тестирование удобства пользования – тест, который можно назвать практически главным для всех интерактивных сервисов, взаимодействующих с пользователем – это тест на "usability" или на удобство использования. Такое тестирование одно из самых дорогих, потому что наиболее ценную информацию можно получить только от реальных пользователей, наблюдая за их работой с вашим сайтом – а такие исследования требуют дорогостоящей инфраструктуры и времени, их сложно автоматизировать. Это метод
тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
Выделяют следующие этапы тестирования удобства использования пользовательского интерфейса [
7
]:
•
Исследовательское – проводится после формулирования требований к системе и разработки прототипа интерфейса. Основная цель на этом этапе – провести высокоуровневое обследование интерфейса и выяснить, позволяет ли он с достаточной степенью эффективности решать задачи пользователя.
•
Оценочное – проводится после разработки низкоуровневых требований и детализированного прототипа пользовательского интерфейса. Оценочное тестирование углубляет исследовательское и имеет ту же цель. На данном этапе уже проводятся количественные измерения характеристик пользовательского интерфейса: измеряются количество обращений к системе помощи по отношению к количеству совершенных операций, количество ошибочных операций, время устранения последствий ошибочных операций и т.п.
•
Валидационное – проводится ближе к этапу завершения разработки. На этом этапе проводится анализ соответствия интерфейса программной системы стандартам, регламентирующим вопросы удобства интерфейса, проводится общее тестирование всех компонент пользовательского интерфейса с точки зрения конечного пользователя. Под компонентами интерфейса здесь понимается как его программная реализация, так и система помощи и руководство пользователя. Также на данном этапе проверяется отсутствие дефектов удобства использования интерфейса, выявленных на предыдущих этапах.
•
Сравнительное – данный вид тестирования может проводиться на любом этапе разработки интерфейса. В ходе сравнительного тестирования сравниваются два или более вариантов реализации пользовательского интерфейса.
Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам [
7
]:
• производительность, эффективность (efficiency) – сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например размещение новости, регистрации, покупка и т.д.
• правильность (accuracy) – сколько ошибок сделал пользователь во время работы с приложением
• активизация в памяти (recall) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя)
• эмоциональная реакция (emotional response) – как пользователь себя чувствует после завершения задачи – растерян, испытал стресс.
Порекомендует ли пользователь систему своим друзьям.
Выделяют следующие этапы тестирования удобства использования пользовательского интерфейса [
7
]:
•
Исследовательское – проводится после формулирования требований к системе и разработки прототипа интерфейса. Основная цель на этом этапе – провести высокоуровневое обследование интерфейса и выяснить, позволяет ли он с достаточной степенью эффективности решать задачи пользователя.
•
Оценочное – проводится после разработки низкоуровневых требований и детализированного прототипа пользовательского интерфейса. Оценочное тестирование углубляет исследовательское и имеет ту же цель. На данном этапе уже проводятся количественные измерения характеристик пользовательского интерфейса: измеряются количество обращений к системе помощи по отношению к количеству совершенных операций, количество ошибочных операций, время устранения последствий ошибочных операций и т.п.
•
Валидационное – проводится ближе к этапу завершения разработки. На этом этапе проводится анализ соответствия интерфейса программной системы стандартам, регламентирующим вопросы удобства интерфейса, проводится общее тестирование всех компонент пользовательского интерфейса с точки зрения конечного пользователя. Под компонентами интерфейса здесь понимается как его программная реализация, так и система помощи и руководство пользователя. Также на данном этапе проверяется отсутствие дефектов удобства использования интерфейса, выявленных на предыдущих этапах.
•
Сравнительное – данный вид тестирования может проводиться на любом этапе разработки интерфейса. В ходе сравнительного тестирования сравниваются два или более вариантов реализации пользовательского интерфейса.
Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам [
7
]:
• производительность, эффективность (efficiency) – сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например размещение новости, регистрации, покупка и т.д.
• правильность (accuracy) – сколько ошибок сделал пользователь во время работы с приложением
• активизация в памяти (recall) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя)
• эмоциональная реакция (emotional response) – как пользователь себя чувствует после завершения задачи – растерян, испытал стресс.
Порекомендует ли пользователь систему своим друзьям.
Исследование и оценка сайтов может проводиться разными методами, разработанными экспертами по юзабилити. Общим для всех методов является постановка реальных задач перед пользователями, а также фиксирование результатов тестирования для дальнейшего анализа. Для участия в юзабилити- тестировании отбираются пользователи, соответствующие целевой аудитории, они также не должны быть слишком знакомы с разработкой. Для того чтобы выявить и оценить наибольшее количество присутствующих на сайте проблем, необходимо привлекать реальных пользователей [
8
].
На удобство использования пользовательского интерфейса влияют следующие факторы [
7
]:
• легкость обучения – быстро ли человек учится использовать систему;
• эффективность обучения – быстро ли человек работает после обучения;
• запоминаемость обучения – легко ли запоминается все, чему человек научился;
• ошибки – часто ли человек допускает ошибки в работе;
• общая удовлетворенность – является ли общее впечатление от работы с системой положительным.
Все эти факторы, несмотря на свою неформальность, могут быть измерены. Для таких измерений выбирается группа типичных пользователей системы, в процессе их работы с системой измеряются показатели их работы с системой (например, количество допущенных ошибок), а также им предлагается высказать собственные впечатления от работы с системой при помощи заполнения опросных листов.
Как правило, при
тестировании
удобства
использования пользовательского интерфейса используются некоторые эвристические критерии и характеристики, которые заменяют точные оценки в классическом тестировании программных систем.
Например, Якоб Нильсен в своей работе [
9
] выделил 10 эвристических характеристик удобного пользовательского интерфейса, которые с его точки зрения должны проверяться при тестировании удобства использования интерфейса:
1.
Наблюдаемость состояния системы – система всегда должна оповещать пользователя о том, что она в данный момент делает, причем через разумные промежутки времени;
2.
Соотнесение с реальным миром – терминология, использованная в интерфейсе системы должна соотноситься с пользовательским миром, т.е. это должна быть терминология проблемной области пользователя, а не техническая терминология.
3.
Пользовательское управление и свобода действий – пользователи часто выбирают отдельные интерфейсные элементы и используют функции системы по ошибке. В этом случае необходимо предоставлять четко определенный "аварийный выход", при помощи которого можно вернуться к предыдущему нормальному состоянию. К таким "аварийным выходам" относятся, например, функции отката и обратного отката.
4.
Целостность и стандарты – для обозначения одних и тех же объектов, ситуаций и действий должны использоваться одинаковые слова во всех частях интерфейса. Более того, терминология сообщений в пользовательском интерфейсе должна учитывать соглашения конкретной платформы.
5.
Помощь пользователям в распознавании, диагностике и устранении ошибок – Сообщения об ошибках должны быть написаны на естественном языке, а не заменяться кодами ошибок. Сообщения об ошибках должны четко определять суть возникшей проблемы и предлагать ее конструктивное решение.
6.
Предотвращение ошибок
– продуманный дизайн пользовательского интерфейса, предотвращающий появление ошибок пользователя всегда лучше хорошо продуманных сообщений об ошибках. При проектировании интерфейса необходимо либо полностью устранить элементы, в которых могут возникать ошибки пользователя, либо проверять ввод пользователя в этих элементах и сообщать ему о потенциально возможном возникновении проблемы.
7.
Распознавание, а не вспоминание – при создании интерфейса необходимо минимизировать нагрузку на память пользователя, делая объекты, действия и опции ясными, доступными и явно видимыми. Пользователь не должен запоминать информацию при переходе от одного диалогового окна к другому. Во всех необходимых местах должны быть доступны контекстные инструкции по использованию интерфейса.
8.
Гибкость и эффективность использования – в интерфейсе должны быть предусмотрены горячие клавиши (не обязательные к использованию начинающим пользователем) – они часто значительно ускоряют работу опытного пользователя. Иными словами, система должна предоставлять два способа работы – для новичков и для опытных пользователей. Желательно при этом давать возможность пользователю автоматизировать часто повторяющиеся действия.
9.
Эстетичный и минимально необходимый дизайн – Окна не должны содержать не относящуюся к делу или редко используемую информацию.
Каждый интерфейсный элемент, содержащий бесполезную информацию, играет роль информационного шума и отвлекает пользователя от действительно полезных интерфейсных элементов.
10.
Помощь и документация – Несмотря на то, что в идеальном случае лучше, когда системой можно пользоваться без документации, она все равно необходима – как в виде системы помощи, так и, возможно, в виде печатного руководства. Информация в документации должна быть структурирована таким образом, чтобы пользователь мог легко найти нужный раздел, посвященный решаемой им задаче. Каждый такой ориентированный на конкретную задачу раздел должен помимо общей информации содержать пошаговые руководства по выполнению задачи и не должен быть слишком длинным.
Все эти эвристики могут использоваться при тестировании удобства
использования пользовательского интерфейса. Достаточно очевидно, что при тестировании удобства слабо применимы способы автоматизации
тестирования при помощи сценариев и подобные методы. Один из наиболее эффективных методов проверки интерфейса на удобство – использование формальной инспекции. Вопросы в бланке инспекции могут быть как общего характера (так, например, можно использовать в качестве вопросов перечисленные выше 10 эвристик), так и вполне конкретными. Например, в работе [
10
] приводится список контрольных вопросов, которые желательно проверять при тестировании удобства использования Веб-сайтов. С некоторыми изменениями эти вопросы применимы и для обычных оконных интерфейсов.
Тестирование безопасности
Отдельно следует отметить