Реферат: Тестирование пользовательского интерфейса

РЕФЕРАТ

Тема:«Тестированиепользовательского интерфейса”

По курсу: „Качествопрограммного обеспечения, тестирование на надежность“

Содержание

Введение1       Функциональноетестирование пользовательских интерфейсов 2       Проверкатребований к пользовательскому интерфейсу2.1    Типытребований к пользовательскому интерфейсу2.2    Тестопригодностьтребований к пользовательскому интерфейсу2.3    Полнотапокрытия пользовательского интерфейса2.4    Методыпроведения тестирования пользовательского интерфейса, повторяемостьтестирования пользовательского интерфейса3       Тестированиеудобства использования пользовательских интерфейсов ВыводыСписокиспользованных источников

Введение

Часть программной системы, обеспечивающая работу интерфейсас пользователем — один из наиболее нетривиальных объектов для верификации.Нетривиальность заключается в двояком восприятии термина „пользовательскийинтерфейс“.С одной стороны, пользовательский интерфейс — частьпрограммной системы. Соответственно, на пользовательский интерфейс пишутсяфункциональные и низкоуровневые требования, по которым затем составляютсятест-требования и тест-планы. При этом, как правило, требования определяютреакцию системы на каждый ввод пользователя (при помощи клавиатуры, мыши илииного устройства ввода) и вид информационных сообщений системы, выводимых наэкран, печатающее устройство или иное устройство вывода. При верификации такихтребований речь идет о проверке функциональной полноты пользовательскогоинтерфейса — насколько реализованные функции соответствуют требованиям,корректно ли выводится информация на экран.С другой стороны, пользовательский интерфейс — »лицо" системы, и от его продуманности зависит эффективность работыпользователя с системой. Факторы, влияющие на эффективность работы, слабоподдаются формализации в виде конкретных требований к отдельным элементам,однако должны быть учтены в виде общих рекомендаций и принципов построенияпользовательского интерфейса программной системы. Проверка интерфейса наэффективность человеко-машинного взаимодействия получила название проверкиудобства использования (usability verification; в русскоязычной литературе вкачестве перевода терминаusability часто используют слово«практичность»).
1. Функциональное тестированиепользовательских интерфейсовФункциональное тестирование пользовательского интерфейсасостоит из пяти фаз:а)        анализтребований к пользовательскому интерфейсу;б)        разработкатест-требований и тест-планов для проверки пользовательского интерфейса;в)        выполнениетестовых примеров и сбор информации о выполнении тестов;г)        определениеполноты покрытия пользовательского интерфейса требованиями;д)        составлениеотчетов о проблемах в случае несовпадения поведения системы и требований либо вслучае отсутствия требований на отдельные интерфейсные элементы.Все эти фазы точно такие же, как и в случае тестированиялюбого другого компонента программной системы. Отличия заключаются в трактовкенекоторых терминов в применении к пользовательскому интерфейсу и в особенностяхавтоматизированного сбора информации на каждой фазе.Так, тест-планы для проверки пользовательского интерфейса,как правило, представляют собой сценарии, описывающие действия пользователя приработе с системой. Сценарии могут быть записаны либо на естественном языке,либо на формальном языке какой-либо системы автоматизации пользовательскогоинтерфейса. Выполнение тестов при этом производится либо оператором в ручномрежиме, либо системой, которая эмулирует поведение оператора.При сборе информации о выполнении тестовых примеров обычноприменяются технологии анализа выводимых на экран форм и их элементов (в случаеграфического интерфейса) или выводимого на экран текста (в случае текстового),а не проверка значений тех или иных переменных, устанавливаемых программнойсистемой.Под полнотой покрытия пользовательского интерфейсапонимается то, что в результате выполнения всех тестовых примеров каждыйинтерфейсный элемент был использован хотя бы один раз во всех доступныхрежимах.Отчеты о проблемах в пользовательском интерфейсе могутвключать в себя как описания несоответствий требований и реального поведениясистемы, так и описания проблем в требованиях к пользовательскому интерфейсу.Основной источник проблем в этих требованиях — их тестонепригодность, вызваннаярасплывчатостью формулировок и неконкретностью.
2. Проверка требований к пользовательскому интерфейсу2.1    Типы требований кпользовательскому интерфейсуТребования к пользовательскому интерфейсу могут бытьразбиты на две группы:-         требованияк внешнему виду пользовательского интерфейса и формам взаимодействия спользователем;-         требованияпо доступу к внутренней функциональности системы при помощи пользовательскогоинтерфейса.Другими словами, первая группа требований описываетвзаимодействие подсистемы интерфейса с пользователем, а вторая — с внутреннейлогикой системы.К первой группе можно отнести следующие типы требований.•        Требования к размещению элементов управления наэкранных формахДанные требования могут определять общие принципыразмещения элементов пользовательского интерфейса или требования к размещениюконкретных элементов. Например, общие требования по размещению элементов награфической экранной форме могут выглядеть следующим образом:Каждое окно приложения должно быть разбито на три части:строка меню, рабочая область и статусная строка. Строка меню должна бытьгоризонтальной и прижатой к верхней части окна, статусная строка должна бытьгоризонтальной и прижатой к нижней части окна, рабочая область должнанаходиться между строкой меню и статусной строкой и занимать всю оставшуюсяплощадь окна.При тестировании данного требования достаточно определить,что в каждом окне системы действительно присутствуют три части, которые расположеныи прижаты согласно требованиям даже при изменении размеров окна, егосворачивании/разворачивании, перемещении по экрану, при перекрытии его другимиокнами.Примером требований по размещению конкретного элементаможет служить следующее:Кнопка «Начать передачу» должна находитьсянепосредственно под строкой меню в левой части рабочей области окна.При тестировании такого требования также необходимоопределить, сохраняется ли расположение элемента при изменении размера окна, атакже при использовании элемента (в данном случае — при нажатии).•        Требования к содержанию и оформлению выводимыхсообщенийТребования к содержанию и оформлению выводимых сообщенийопределяют текст сообщений, выводимых системой, его шрифтовое и цветовоеоформление. Также часто в таких требованиях определяется, в каких случаяхвыводится то или иное сообщение.Так, например, для тестирования требованияСообщение «Невозможно открыть файл» должновыводиться в статусную строку прижатым к левому краю, красным цветом,полужирным шрифтом в случае недоступности открываемого файла по чтению.Необходимо проверить, что при возникновении указаннойситуации сообщение действительно выводится согласно требованиям.Однако в случае тестирования требования видаСообщения об ошибках должны выводиться в статусную строкуприжатыми к левому краю красным цветом полужирным шрифтом.Необходимо проверять форматы всех возможных сообщений обошибках программы во всех возможных ошибочных ситуациях. Таким образом,очевидно, что при тестировании пользовательского интерфейса не всегда можнооднозначно определить количество тестовых примеров, которые понадобятся длятестирования требования. Эта проблема вызвана тем, что требования кпользовательскому интерфейсу зачастую кажутся слишком очевидными для их точнойформулировки. Эта неконкретность требований и вызывает большое количествотестов для каждого требования.•        Требования к форматам вводаДанная группа требований определяет, в каком видеинформация поступает от пользователя в систему. При этом кроме собственно требований,определяющих корректный формат, к этой группе относятся требования,определяющие реакцию системы на некорректный ввод. Для проверки такихтребований необходимо проверять как корректный ввод, так и некорректный.Желательно при этом разбивать различные варианты ввода на классыэквивалентности (как минимум на два — корректные и некорректные).Ко второй группе относятся следующие типы требований.•        Требования к реакции системы на ввод пользователяДанный тип требований определяет связь внутренней логикисистемы и интерфейсных элементов. Например,При нажатии кнопки «Сброс» значение таймерасинхронизации передачи должно сбрасываться в 0.Для проверки такого требования в тестовом примере должнобыть сымитировано нажатие на кнопку «Сброс», после чего должнапроводиться проверка значения таймера. Однако некоторые требования определяют вкачестве реакции системы не то, как меняется ее внутреннее состояние, а реакциюпользовательского интерфейса. Например, в требованииПри нажатии кнопки «Отложенный сброс» должновыводиться окно «Ввод значения времени для отложенного сброса».В качестве реакции на использование одного интерфейсногоэлемента определяется появление другого интерфейсного элемента. Такиетребования проверяются при помощи имитации ввода пользователя и анализапоявляющихся интерфейсных элементов.•        Требования к времени отклика на командыпользователяВ качестве отдельного типа требований можно выделитьтребования к времени отклика системы на различные пользовательские операции.Это связано с тем, что подсознательно пользователь воспринимает операциипродолжительностью более 1 секунды как длительные. Если в этот момент системане сообщает пользователю о том, что она выполняет какую-либо операцию,пользователь начнет считать, что система зависла или работает в неверномрежиме. В связи с этим либо каждое предельное время отклика должно быть указанов требованиях и пользовательской документации, либо во время длительныхопераций должны выводиться информационные сообщения (например, индикаторпрогресса). Значения предельного времени и равномерность увеличения значенийиндикатора прогресса должны проверяться соответствующими тестами.2.2    Тестопригодность требований кпользовательскому интерфейсуНекоторые требования к пользовательскому интерфейсу могутоказаться тестонепригодными, либо их тестирование будет значительно затруднено.К таким требованиям в первую очередь относятся требования, описывающиесубъективные характеристики интерфейса, которые не могут быть точно определеныили измерены при выполнении тестовых примеров. При анализе требований кпользовательскому интерфейсу необходимо четко представлять, какой элементинтерфейса и каким образом будет проверяться, какая его характеристика будетизмеряться в ходе тестирования.Примером тестонепригодного требования может служитьклассическое требованиеПользовательский интерфейс должен быть интуитивно понятным.Без определения четких критериев интуитивной понятностипроверка такого требования невозможна. При этом необходимо понимать, чтокритерий в данном случае может быть двух видов: детерминированным иливероятностным. Примером детерминированного критерия может быть дополнение ктребованию видаПод интуитивной понятностью интерфейса понимаетсядоступность любой функции системы при помощи не более чем 5 щелчков мыши поинтерфейсным элементам.Требование с таким уточнением поддается как ручному, так иавтоматизированному тестированию, более того, результат такого тестирования небудет зависеть от субъективного мнения тестировщика (понятия об интуитивнойпонятности у всех разные).Примером вероятностного критерия может служить следующеедополнение:Под интуитивной понятностью интерфейса понимается, чтопользователь обращается к руководству пользователя не чаще, чем раз в пятьминут на этапе обучения и не чаще, чем раз в 2 часа на этапе активногоиспользования системы. Значения должны быть получены на репрезентативнойвыборке пользователей не менее 1000 человек.Проверка требования с таким дополнением не является задачейклассической верификации и относится уже скорее к проверке удобства примененияпользовательского интерфейса. Однако здесь также вводится четкий критерий, прииспользовании которого результаты тестирования могут быть воспроизведены.2.3    Полнота покрытия пользовательского интерфейсаПри определении понятия покрытия пользовательскогоинтерфейса можно ввести следующие его уровни:-         функциональноепокрытие — покрытие требований к пользовательскому интерфейсу;-         структурноепокрытие — для обеспечения полного структурного покрытия каждый интерфейсныйэлемент должен быть использован в тестовых примерах хотя бы один раз;-         структурноепокрытие с учетом состояния элементов интерфейса — для обеспечения этого уровняпокрытия необходимо не только использовать каждый элемент интерфейса, но ипривести его во все возможные состояния (например, для чек-боксов — отмечен/неотмечен, для полей ввода — пустое/заполненное не целиком/заполненное полностьюи т.п.)-         структурноепокрытие с учетом состояния элементов интерфейса и внутреннего состояниясистемы — поведение некоторых интерфейсных элементов может изменяться взависимости от внутреннего состояния системы. Каждое такое различимое поведениеинтерфейсного элемента должно быть проверено. Например, система может иметь дварежима работы — нормальный и для начинающего пользователя, в котором нажатиекаждого элемента сопровождается появлением всплывающей подсказки. В этом случаенужно проверить оба режима и при этом проверить, что подсказки появляютсятолько в режиме для начинающих.При определении степени покрытия необходимо учитывать, чтореакция на некоторые интерфейсные элементы определяется не программнойсистемой, а на уровне операционной системы или среды выполнения. Так, например,реакция на использование многих интерфейсных элементов стандартного диалоговогоокна открытия файла определяется операционной системой и может нетестироваться.Если уровень покрытия интерфейсных элементов тестаминедостаточен, это является сигналом либо к уточнению требований кпользовательскому интерфейсу, либо к снижению степени подробности тестирования.
2.4    Методы проведения тестированияпользовательского интерфейса, повторяемость тестирования пользовательскогоинтерфейсаФункциональное тестирование пользовательского интерфейсаможет проводиться различными методами — как вручную при непосредственномучастии оператора, так и при помощи различного инструментария,автоматизирующего выполнение тестовых примеров. Рассмотрим эти методы болееподробно.Ручное тестирование пользовательского интерфейса проводитсятестировщиком-оператором, который руководствуется в своей работе описаниемтестовых примеров в виде набора сценариев. Каждый сценарий включает в себяперечисление последовательности действий, которые должен выполнить оператор, иописание важных для анализа результатов тестирования ответных реакций системы,отражаемых в пользовательском интерфейсе. Типичная форма записи сценария дляпроведения ручного тестирования — таблица, в которой в одной колонке описаныдействия (шаги сценария), в другой — ожидаемая реакция системы, а третьяпредназначена для записи того, совпала ли ожидаемая реакция системы с реальнойи перечисления несовпадений.Ручное тестирование пользовательского интерфейса удобнотем, что контроль корректности интерфейса проводится человеком, т.е. основным«потребителем» данной части программной системы. К тому же при чистокосметических изменениях в интерфейсах системы, не отраженных в требованиях(например, при перемещении кнопок управления на 10 пикселей влево), анализуспешности прохождения теста будет выполняться не по формальным признакам, асогласно человеческому восприятию.При этом ручное тестирование имеет и существенныйнедостаток — для его проведения требуются значительные человеческие и временныересурсы. Особенно сильно этот недостаток проявляется при проведении регрессионноготестирования и вообще любого повторного тестирования — на каждой итерацииповторного тестирования пользовательского интерфейса требуется участиетестировщика-оператора. В связи с этим в последнее десятилетие получилираспространение средства автоматизации тестирования пользовательскогоинтерфейса, снижающие нагрузку на тестировщика-оператора.Естественный способ автоматизации тестированияпользовательского интерфейса — использование программных инструментов,эмулирующих поведение тестировщика-оператора при ручном тестированиипользовательского интерфейса.Такие инструменты используют в качестве входной информациисценарии тестовых примеров, записанные на некотором формальном языке, операторыкоторого соответствуют действиям пользователя — вводу команд, перемещениюкурсора, активизации пунктов меню и других интерфейсных элементов.При выполнении автоматизированного теста инструменттестирования имитирует действия пользователя, описанные в сценарии, ианализирует интерфейсную реакцию системы. Для определения ожидаемого состоянияпользовательского интерфейса здесь могут применяться различные методы — либоанализ снимков экрана и сравнение их с эталонными, либо доступ к данныминтерфейсных элементов средствами операционной системы (например, доступ ковсем кнопкам окна по их дескрипторам и получение значений текста).И при передаче информации в тестируемый интерфейс, и приполучении информации для анализа могут использоваться два способа доступа кэлементам интерфейса:-         позиционный,при котором доступ к элементу осуществляется при помощи задания его абсолютных(относительно экрана) или относительных (относительно окна) координат иразмеров;-         поидентификатору, при котором доступ к элементу осуществляется при помощиполучения интерфейсного элемента при помощи его уникального идентификатора впределах окна.При внесении изменений в пользовательский интерфейс прииспользовании первого метода в результате проведения регрессионноготестирования будет выявлено большое количество не прошедших тестов — достаточноизменения местоположения одного ключевого интерфейсного элемента, как всесценарии начнут работать неверно. Соответственно при таком методе автоматизациитестирования необходимо менять значительную часть сценариев в системе тестовпри каждом изменении интерфейса системы. Такой метод автоматизации тестированияподходит для систем с устоявшимся и редко изменяемым интерфейсом.Второй метод автоматизации тестирования более устойчив кизменению расположения интерфейсных элементов, но изменения тестовых примеровмогут потребоваться и здесь в случае изменения логики работы интерфейсныхэлементов. Например, пусть в первой версии системы при нажатии на кнопку«Передать данные» передача данных начиналась сразу и выводилось окнос индикатором прогресса. Сценарий тестового примера в этом случае включает всебя имитацию нажатия на кнопку и обращение к индикатору прогресса дляполучения значения прогресса в процентах.Если во второй версии системы после нажатия на кнопку«Передать данные» вначале выводится окно «Вы уверены?» скнопками «Да» и «Нет», то для проверки работы индикаторапрогресса в тестовый сценарий необходимо добавить имитацию нажатия кнопки«Да».Даже при обращении при помощи идентификаторов безмодификации тестового примера тест не будет корректно выполняться. Тем неменее, этот способ обращения к интерфейсным элементам хорошо подходит длятестирования программных систем, в т.ч. с не устоявшимся пользовательскиминтерфейсом.
3. Тестирование удобстваиспользования пользовательских интерфейсовУдобство использования пользовательского интерфейса(usability) — показатель его качества, который определяет количество усилий,необходимых для изучения принципов работы с программной системой при помощиданного интерфейса, ее использования, подготовки входных данных и интерпретациивыходных. Иначе говоря, удобство использования определяет степень простотыдоступа пользователя к функциям системы, предоставляемым черезчеловеко-машинный (пользовательский) интерфейс.Тестирование удобства использования пользовательского интерфейса,вообще говоря, не относится к классическим методам тестирования программныхсистем. Специалист по тестированию пользовательского интерфейса должен сочетатьв себе знания как в области программной инженерии, так и в физиологии,психологии и эргономике. На удобство использования пользовательского интерфейсавлияют следующие факторы:-         легкостьобучения — быстро ли человек учится использовать систему;-         эффективностьобучения — быстро ли человек работает после обучения;-         запоминаемостьобучения — легко ли запоминается все, чему человек научился;-         ошибки- часто ли человек допускает ошибки в работе;-         общаяудовлетворенность — является ли общее впечатление от работы с системойположительным.Все эти факторы, несмотря на свою неформальность, могутбыть измерены. Для таких измерений выбирается группа типичных пользователейсистемы, и в процессе их работы измеряются показатели их работы с системой(например, количество допущенных ошибок), а также им предлагается высказатьсобственные впечатления от системы при помощи заполнения опросных листов.Выделяют следующие этапы тестирования удобстваиспользования пользовательского интерфейса [1].а)        Исследовательское- проводится после формулирования требований к системе и разработки прототипаинтерфейса. Основная цель на этом этапе — провести высокоуровневое обследованиеинтерфейса и выяснить, позволяет ли он с достаточной степенью эффективностирешать задачи пользователя.б)        Оценочное- проводится после разработки низкоуровневых требований и детализированногопрототипа пользовательского интерфейса. Оценочное тестирование углубляетисследовательское и имеет ту же цель. На данном этапе уже проводятсяколичественные измерения характеристик пользовательского интерфейса: измеряютсяколичество обращений к системе помощи по отношению к количеству совершенныхопераций, количество ошибочных операций, время устранения последствий ошибочныхопераций и т.п.в)        Валидационное- проводится ближе к этапу завершения разработки. На этом этапе проводитсяанализ соответствия интерфейса программной системы стандартам, регламентирующимвопросы удобства интерфейса (например ISO 13407 [2], ISO 9126 [3]), проводитсяобщее тестирование всех компонентов пользовательского интерфейса с точки зренияконечного пользователя. Под компонентами интерфейса здесь понимается как егопрограммная реализация, так и система помощи и руководство пользователя. Такжена данном этапе проверяется отсутствие дефектов удобства использованияинтерфейса, выявленных на предыдущих этапах.г)        Сравнительное- данный вид тестирования может проводиться на любом этапе разработкиинтерфейса. В ходе сравнительного тестирования сравниваются два или болеевариантов реализации пользовательского интерфейса.Как правило, при тестировании удобства использованияпользовательского интерфейса используются некоторые эвристические критерии ихарактеристики, которые заменяют точные оценки в классическом тестированиипрограммных систем.Например, Якоб Нильсен в своей работе [4] выделил 10эвристических характеристик удобного пользовательского интерфейса, которые сего точки зрения должны проверяться при тестировании удобства использованияинтерфейса.-         Наблюдаемостьсостояния системы. Система всегда должна оповещать пользователя о том, что онав данный момент делает, причем через разумные промежутки времени.-         Соотнесениес реальным миром. Терминология, использованная в интерфейсе системы должнасоотноситься с пользовательским миром, т.е. это должна быть терминологияпроблемной области пользователя, а не техническая терминология.-         Пользовательскоеуправление и свобода действий. Пользователи часто выбирают отдельныеинтерфейсные элементы и используют функции системы по ошибке. В этом случаенеобходимо предоставлять четко определенный «аварийный выход», припомощи которого можно вернуться к предыдущему нормальному состоянию. К таким«аварийным выходам» относятся, например, функции отката и обратногоотката.-         Целостностьи стандарты. Для обозначения одних и тех же объектов, ситуаций и действийдолжны использоваться одинаковые слова во всех частях интерфейса. Более того,терминология сообщений в пользовательском интерфейсе должна учитыватьсоглашения конкретной платформы.-         Помощьпользователям в распознавании, диагностике и устранении ошибок. Сообщения обошибках должны быть написаны на естественном языке, а не заменяться кодамиошибок. Сообщения об ошибках должны четко определять суть возникшей проблемы ипредлагать ее конструктивное решение.-         Предотвращениеошибок. Продуманный дизайн пользовательского интерфейса, предотвращающийпоявление ошибок пользователя, всегда лучше хорошо продуманных сообщений обошибках. При проектировании интерфейса необходимо либо полностью устранитьэлементы, в которых могут возникать ошибки пользователя, либо проверять вводпользователя в этих элементах и сообщать ему о потенциально возможномвозникновении проблемы.-         Распознавание,а не вспоминание. При создании интерфейса необходимо минимизировать нагрузку напамять пользователя, делая объекты, действия и опции ясными, доступными и явновидимыми. Пользователь не должен запоминать информацию при переходе от одногодиалогового окна к другому. Во всех необходимых местах должны быть доступныконтекстные инструкции по использованию интерфейса.-         Гибкостьи эффективность использования. В интерфейсе должны быть предусмотрены горячиеклавиши (не обязательные к использованию начинающим пользователем) — они частозначительно ускоряют работу опытного пользователя. Иными словами, системадолжна предоставлять два способа работы — для новичков и для опытныхпользователей. Желательно при этом давать возможность пользователюавтоматизировать часто повторяющиеся действия.-         Эстетичныйи минимально необходимый дизайн. Окна не должны содержать не относящуюся к делуили редко используемую информацию. Каждый интерфейсный элемент, содержащий бесполезнуюинформацию, играет роль информационного шума и отвлекает пользователя отдействительно полезных интерфейсных элементов.-         Помощьи документация. Несмотря на то, что в идеальном случае лучше, когда системойможно пользоваться без документации, таковая все равно необходима — как в видесистемы помощи, так и, возможно, в виде печатного руководства. Информация вдокументации должна быть структурирована таким образом, чтобы пользователь моглегко найти нужный раздел, посвященный решаемой им задаче. Каждый такойориентированный на конкретную задачу раздел должен помимо общей информациисодержать пошаговые руководства по выполнению задачи и не должен быть слишкомдлинным.Все эти эвристики могут использоваться при тестированииудобства использования пользовательского интерфейса. Достаточно очевидно, чтопри тестировании удобства слабо применимы способы автоматизации тестированияпри помощи сценариев и подобные методы. Один из наиболее эффективных методовпроверки интерфейса на удобство — использование формальной инспекции. Вопросы вбланке инспекции могут быть как общего характера (так, например, можноиспользовать в качестве вопросов перечисленные выше 10 эвристик), так и вполнеконкретными. Например, в работе [5] приводится список контрольных вопросов, которыежелательно проверять при тестировании удобства использования web-сайтов. Снекоторыми изменениями эти вопросы применимы и для обычных оконных интерфейсов.
ВыводыПри создании программного обеспечения проводятся различныетестирования, к которым относиться и тестирование пользовательского интерфейса,чтобы можно было выявить ошибки, которые были не замечены при разработке.Тест-планы для проверки пользовательского интерфейса, какправило, представляют собой сценарии, описывающие действия пользователя приработе с системой. Сценарии могут быть записаны либо на естественном языке,либо на формальном языке какой-либо системы автоматизации пользовательскогоинтерфейса. Выполнение тестов при этом производится либо оператором в ручномрежиме, либо системой, которая эмулирует поведение оператора.Отчеты о проблемах в пользовательском интерфейсе могутвключать в себя как описания несоответствий требований и реального поведениясистемы, так и описания проблем в требованиях к пользовательскому интерфейсу.Основной источник проблем в этих требованиях — их тестонепригодность, вызваннаярасплывчатостью формулировок и неконкретностью.Как правило, при тестировании удобства использованияпользовательского интерфейса используются некоторые эвристические критерии и характеристики,которые заменяют точные оценки в классическом тестировании программных систем.
Список использованных источников1.        Burnstein I Practical Software Testing. A process-orientedapproach Springer-Verlag,New York, 2003, — 732 p2.        ISO 13407:1999.Human-centred design processes for interactive systems International Organization for Standardization.01-Jun-1999, 26 p.3.        SO/IEC9126-1:2001. Software engineering — Product quality — Part 1: Quality model International Organization for Standardization/InternationalElectrotechnical Commission. 01-Jun-2001, 25 p4.        Nielsen J Ten Usability Heuristics5.        Общий оценочный лист тестированияusability web-сайта6.        http://www.intuit.ru