Основы тестирования и отладки Веб-приложений

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

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

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

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

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

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

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

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

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

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

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

Например, Якоб Нильсен в своей работе [9] выделил 10 эвристических характеристик удобного пользовательского интерфейса, которые с его точки зрения должны проверяться при тестировании удобства использования интерфейса:

1. Наблюдаемость состояния системы – система всегда должна оповещать пользователя о том, что она в данный момент делает, причем через разумные промежутки времени;
2. Соотнесение с реальным миром – терминология, использованная в интерфейсе системы должна соотноситься с пользовательским миром, т.е. это должна быть терминология проблемной области пользователя, а не техническая терминология.
3. Пользовательское управление и свобода действий – пользователи часто выбирают отдельные интерфейсные элементы и используют функции системы по ошибке. В этом случае необходимо предоставлять четко определенный "аварийный выход", при помощи которого можно вернуться к предыдущему нормальному состоянию. К таким "аварийным выходам" относятся, например, функции отката и обратного отката.
4. Целостность и стандарты – для обозначения одних и тех же объектов, ситуаций и действий должны использоваться одинаковые слова во всех частях интерфейса. Более того, терминология сообщений в пользовательском интерфейсе должна учитывать соглашения конкретной платформы.
5. Помощь пользователям в распознавании, диагностике и устранении ошибок – Сообщения об ошибках должны быть написаны на естественном языке, а не заменяться кодами ошибок. Сообщения об ошибках должны четко определять суть возникшей проблемы и предлагать ее конструктивное решение.
6. Предотвращение ошибок – продуманный дизайн пользовательского интерфейса, предотвращающий появление ошибок пользователя всегда лучше хорошо продуманных сообщений об ошибках. При проектировании интерфейса необходимо либо полностью устранить элементы, в которых могут возникать ошибки пользователя, либо проверять ввод пользователя в этих элементах и сообщать ему о потенциально возможном возникновении проблемы.
7. Распознавание, а не вспоминание – при создании интерфейса необходимо минимизировать нагрузку на память пользователя, делая объекты, действия и опции ясными, доступными и явно видимыми. Пользователь не должен запоминать информацию при переходе от одного диалогового окна к другому. Во всех необходимых местах должны быть доступны контекстные инструкции по использованию интерфейса.
8. Гибкость и эффективность использования – в интерфейсе должны быть предусмотрены горячие клавиши (не обязательные к использованию начинающим пользователем) – они часто значительно ускоряют работу опытного пользователя. Иными словами, система должна предоставлять два способа работы – для новичков и для опытных пользователей. Желательно при этом давать возможность пользователю автоматизировать часто повторяющиеся действия.
9. Эстетичный и минимально необходимый дизайн – Окна не должны содержать не относящуюся к делу или редко используемую информацию. Каждый интерфейсный элемент, содержащий бесполезную информацию, играет роль информационного шума и отвлекает пользователя от действительно полезных интерфейсных элементов.
10. Помощь и документация – Несмотря на то, что в идеальном случае лучше, когда системой можно пользоваться без документации, она все равно необходима – как в виде системы помощи, так и, возможно, в виде печатного руководства. Информация в документации должна быть структурирована таким образом, чтобы пользователь мог легко найти нужный раздел, посвященный решаемой им задаче. Каждый такой ориентированный на конкретную задачу раздел должен помимо общей информации содержать пошаговые руководства по выполнению задачи и не должен быть слишком длинным.

Все эти эвристики могут использоваться при тестировании удобства использования пользовательского интерфейса. Достаточно очевидно, что при тестировании удобства слабо применимы способы автоматизации тестирования при помощи сценариев и подобные методы. Один из наиболее эффективных методов проверки интерфейса на удобство – использование формальной инспекции. Вопросы в бланке инспекции могут быть как общего характера (так, например, можно использовать в качестве вопросов перечисленные выше 10 эвристик), так и вполне конкретными. Например, в работе [10] приводится список контрольных вопросов, которые желательно проверять при тестировании удобства использования Веб-сайтов. С некоторыми изменениями эти вопросы применимы и для обычных оконных интерфейсов.

19.1.5. Проверка ссылок

Еще один вид тестирования – проверка ссылок [11]. В больших тестовых комплексах он интегрирован в проверку юзабилити, или же в проверку правильности HTML-кода, но существует и множество простеньких утилит для такого рода проверок. Такое тестирование актуально и для внутренних ссылок (в случае больших и разветвленных порталов), и для внешних – если это, к примеру, каталог сайтов, или просто обычная страница "Ссылки". Пожалуй, такой тест – это один из немногих тестов, специфический для веб-приложений и сайтов. Кроме того, такой тест можно и необходимо периодически проводить на работающем сайте – ведь со временем структура меняется, и некоторые ссылки могут стать неверными.

19.1.6. Тестирование безопасности

Отдельно следует отметить тест на безопасность [12]. Это очень важный тип тестов, так как от безопасности сервера зависит практически все – и сам бизнес, и доверие пользователей, и сохранность информации. Правда, в отличие от других тестов, тестирование безопасности следует проводить регулярно. Кроме того, тестированию подвергается не только сам конкретный сайт или веб-приложение, а весь сервер полностью – и веб-сервер, и операционная система, и все сетевые сервисы. Как и в случае других тестов, программа "прикидывается" реальным пользователем-взломщиком и пытается применить к серверу все известные ей методы атаки и проверяет все уязвимости. Результатом работы будет отчет о найденных уязвимостях и рекомендации по их устранению.

Ошибки, связанные с проверкой корректности ввода, часто довольно сложно обнаружить в большом объеме кода, взаимодействующего с пользователем. Это является основной причиной того, что разработчики используют методологию тестирования приложений на проникновение для их обнаружения. Веб-приложения, однако, не имеют иммунитета и к более традиционным способам атаки. Весьма распространены плохие механизмы аутентификации, логические ошибки, непреднамеренное раскрытие информации, а также такие традиционные ошибки для обычных приложений как переполнение буфера. Приступая к тестированию Веб -приложений, необходимо учитывать все перечисленное, и должен применяться методический процесс тестирования ввода/вывода по схеме "черного ящика" в сочетании (если возможно) с аудитом исходного кода [13].

Существуют различные инструменты позволяющие производить автоматическое тестирование безопасности, выполняя такие задачи как cross site scripting, SQL injection, включая переполнение буфера, подделка параметра, несанкционированный доступ, манипуляции с HTTP запросами и т.д. [14]

19.1.7. Нагрузочное тестирование

Следующим видом тестирования является тест на устойчивость к большим нагрузкам – Load-testing, stress-test или performance test [15]. Такой тест имитирует одновременную работу нескольких сотен или тысяч посетителей (каждый из которых может "ходить" по сайту в соответствии со своим сценарием ), проверяя, будет ли устойчивой работа сайта под большой нагрузкой. Кроме этого, можно имитировать кратковременные пики нагрузки, когда количество посетителей скачкообразно увеличивается – это очень актуально для новостных ресурсов и других сайтов с неравномерной аудиторией. В таком тесте проверяется не только и не столько сам сайт, сколько совместная слаженная работа всего комплекса – аппаратной части сервера, веб-сервера, программного ядра (engine) и других компонентов сайта.

Основными целями нагрузочного тестирования являются [15]:

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

В нагрузочное тестирование входят следующие тесты:

19.1.7.1. Тестирование производительности (Performance testing)

Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит [15]:

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

19.1.7.2. Стрессовое тестирование (Stress Testing)

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

19.1.7.3. Объемное тестирование (Volume Testing)

Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит [15]:

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

19.1.7.4. Тестирование стабильности или надежности (Stability / Reliability Testing)

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

19.1.7.5. Моделирование Транзакций (Transaction Simulation, TS)

Этот метод используется в большом числе различных продуктов, в частности, в пакетах AppManager и Vivinet Manager компании NetlQ.

Метод TS основан на использовании программных GUI-роботов (GUI -Graphical User Interface) [17]. GUI-робот – это специальная программа, которая "заставляет" реальное пользовательское приложение работать в автоматическом режиме, без участия самого пользователя (человека). Примерами средств, предназначенных для создания GUI-роботов, являются пакеты Rational Visual Test и Rational Robot компании Rational Software, а также пакет WinRunner компании Mercury Interactive.

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

Основное достоинство метода TS заключается в том, что он позволяет измерять производительность работы приложения "с точки зрения пользователя" и, при этом, не требует доступа к коду пользовательского приложения [18]. Недостаток же метода в том, что он позволяет измерять время выполнения только рабочих транзакций и не может использоваться для измерения времени выполнения системных транзакций.

19.1.7.6. Метод "Анализ данных на стороне клиента" (Client Capture, CC)

Данный метод реализован, например, в программном пакете Vital Suite компании Lucent [17]. Метод основан на извлечении данных о работе приложения из операционной системы компьютера, где установлено пользовательское приложение. Для этого на компьютере пользователя устанавливается специальный Агент, который отслеживает взаимодействие приложения и ОС и, таким образом, получает информацию о доступности и времени реакции пользовательского приложения. Достоинство данного метода в том, что при его использовании нет необходимости модернизировать код приложения. Недостаток – дополнительные накладные расходы на компьютере пользователя (клиента) и ограниченный набор поддерживаемых приложений.

19.1.7.7. Метод "Анализ Сетевого Трафика" (Network Sniffing, NS)

Примером такого устройства является NetScout WAN Probes, компании NetScout [17].Он основан на извлечении информации о производительности приложений из сетевого трафика. Для этого в сети устанавливаются специальные Зонды (как правило, аппаратные), которые в режиме реального времени захватывают сетевой трафик, анализируют его и "извлекают" данные о времени реакции приложений, доступности приложения и т.п. АРМ-средства на базе метода "Network Sniffing" выпускаются, в основном, производителями аппаратных анализаторов сетевых протоколов.

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

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

В настоящее время применяются два способа обеспечения независимости запросов: использование многопоточности и создание распределенных систем [19]. Многопоточность в той или иной форме применяется во всех рассмотренных средствах тестирования. Данный метод не позволяет воспроизводить и в явной форме задавать характер потока запросов (равномерный, пульсирующий и т.д.) и его статистические характеристики (средняя величина интервала времени между последовательными запросами, дисперсия и др.). Величина выделяемого нити кванта времени (а, следовательно, и величина интервала между запросами) зависит от производительности вычислительной системы и ее загруженности, а также от алгоритмов разделения времени, применяемых операционной системой. Непредсказуемые колебания интенсивности генерируемого потока запросов не позволяют достоверно оценить стабильность работы сервера. Увеличение числа нитей повышает уровень независимости запросов, однако конкуренция между нитями снижает ур овень нагрузки, что делает данный подход неприменимым для тестирования высокопроизводительных серверов.

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