Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
4 6 3 сообщения, меню, рекомендации и т.п. зависят от ситуации. Это замеча тельная способность программы, если только она работает правильно. Неправильное определение источника ошибки Как минимум в сообщении об ошибке должно быть сказано, что имен но произошло не так. Если необходимо, должны быть приведены ошибоч ные данные. В хорошем сообщении об ошибке указываются также ее причина и способ выхода из ситуации. Шестнадцатиричный код - это не сообщение об ошибке Сообщения вроде Error 010 в обычных прикладных программах не допустимы. Исключения могут составлять только особые ситуации, когда распечатка полного сообщения об ошибке слишком велика или неуместна, когда этот текст — все, что компьютер успевает вывести перед сбоем или когда программой не пользуется никто, кроме ее автора. Отказ в предоставлении ресурсов без объяснения причины Если программе не удается использовать принтер, модем, дополнитель ную память или другие ресурсы, она должна не только сообщить пользо вателю о неудаче, но и объяснить ее причины. Сообщения "Принтер уже используется" и "Принтер не подключен" требуют от пользователя разных действий. Сообщения об ошибках, которые не являются таковыми Сообщения об ошибках должны выдаваться программой в стандартной форме, и только тогда, когда ошибка действительно имеет место. Если же программа в форме сообщений об ошибках будет информировать пользо вателя о рядовых событиях, он перестанет читать все подобные сообщения. Ошибки отображения Ошибки отображения информации на экране — это то, что может дис кредитировать программу при первом же знакомстве с ней пользователя. К сожалению, программисты часто считают их незначительными, полагая, что, если с данными и их обработкой все в порядке, не страшно, если на экране что-то немного не так. А зря, потому что ошибки на экране часто являются признаками более серьезных проблем. Два курсора Плохо, когда, перемещая фокус ввода из одной точки экрана в другую, программист забывает стереть старый курсор. Но еще хуже, если два кур сора на экране являются отражением путаницы в программном коде, ког да неизвестно, какой из них активен. Тут могут скрываться очень серьезные программные ошибки. 4 6 4 Часть III: Управление проектами и группами Исчезновение курсора Обычно курсор исчезает, когда программист отображает что-то поверх него или, изменив его координаты, забывает его перерисовать. Возможны и другие причины, например, курсор нарисован в той области памяти, которая не отображается на экране. Это плохо, поскольку так ничего не стоит запортить нужные данные. Курсор отображается не в том месте Курсор находится в одном месте экрана, а вводимые пользователем данные отображаются в другом. Эта ошибка очень неприятна для пользо вателя. Кроме того, она может быть симптомом более серьезной проблемы, когда неправильно интерпретируется ввод или не так сохраняются данные. Курсор вне области ввода данных Такого не должно быть никогда. Обычно это ошибка кодирования, хотя некоторые программисты намеренно позволяют пользователю перемещать курсор в любую точку экрана, что является ошибкой проектирования. Отображение ввода не в том месте экрана Курсор отображается правильно, а вот вводимые данные — где-то в другом месте. Недоочищена часть экрана После ответа пользователя на сообщение окно не исчезает с экрана или удаляется лишь частично. Это неприятно и часто мешает дальнейшей ра боте. Не выделены активные элементы экрана Если программа обычно выделяет определенные элементы экрана, на пример активное окно или поле ввода, она должна делать это всегда. Не снято выделение Данные и параметры области их отображения обычно хранятся про граммой отдельно. Поэтому после удаления выделенных данных занимае мая ими область экрана может остаться выделенной, причем это может быть незаметно до тех пор, пока в этой области не появятся новые данные. Отображена неверная или неполная строка Отображаемое на экране сообщение может содержать "мусор", фраг мент другого, более длинного сообщения или, наоборот, быть урезанным. Такая ситуация может быть следствием как незначительной ошибки в программе (программист забыл очистить переменную, выделил под нее мало памяти и т.п.), так и очень серьезной. Приложение: Распространенные программные ошибки 4 6 5 Сообщение остается на экране слишком долго или исчезает слишком быстро Многие сообщения остаются на экране некоторое время, а затем исче зают, не требуя реакции пользователя. Это время должно быть достаточ ным, чтобы пользователь успел заметить и прочесть сообщение, и зависит от его важности, длины и от того, как часто оно появляется на экране. Если одно и то же сообщение в одних случаях остается на экране доль ше, чем в других, это должно вызвать у вас подозрение. Причиной может быть ситуация гонок. Постарайтесь определить, в каких случаях получается какая задержка, а затем предложите программисту внимательно проанали зировать код. Организация экрана Экран должен выглядеть организованным. Информация не должна быть фрагментирована и разбросана где попало. Различные классы объектов следует располагать отдельно друг от друга, их местоположение должно быть логичным. Существует множество теорий о том, как располагать информацию на экране, но все они сводятся к одному: пользователь дол жен легко находить нужные элементы. Неэстетическое оформление экрана Это субъективная, но все же достаточно четко распознаваемая характе ристика. Пользуйтесь собственным чувством гармонии, а в случае неуве ренности обращайтесь к мнению других. Распространенными эстетическими недоработками являются: неудачное сочетание цветов, не равномерное расположение элементов, их непропорциональные размеры, невыровненные строки и столбцы данных. Неудачная организация меню Этот вопрос обстоятельно рассматривается такими авторами, как Шней дерман (Schneiderman, 1987) и Смит и Мойзер (Smith & Moiser, 1984). Его обсуждение заняло бы множество страниц, но здесь приводится лишь не сколько наиболее важных моментов. • Подобные или концептуально связанные команды меню должны быть объединены в группы. Группы должны четко отделяться одна от другой. • Способ выбора элемента меню должен быть очевидным или указан ным на экране. • По возможности команды меню должны быть независимыми. Для достижения определенного результата пользователь не должен выби рать по очереди несколько команд. 4 6 6 Часть III: Управление проектами и группами • Выбор элемента меню путем ввода его первой (или другой выделен ной) буквы предпочтительнее выбора по номеру. (Если для выбора из меню всегда используются первые буквы команд, проследите, чтобы командам не присваивались странные имена.) Ошибки организации диалоговых окон Для изучения этого вопроса мы рекомендуем выпущенные компанией IBM учебные пособия SAA Advanced Interface Design Guide (1989) и SAA Basic Interface Design Guide, а также пособие компании Apple Human Interface Guidelines (1987). • Диалоговые окна должны иметь стандартизированный интерфейс. Например, они должны выводиться в одном и том же месте экрана, их текст должен отображаться одним и тем же шрифтом и одинаково выравниваться, заголовок окна должен отражать название открыв шей его команды. Если для выхода из окон и подтверждения запро сов используются клавиши (обычно • Элементы диалогового окна должны быть организованы логично. Связанные элементы должны располагаться рядом, а их группы четко отделяться друг от друга. • Поля ввода и выбора должны быть выровнены вертикально и гори зонтально, чтобы пользователь мог перемещаться между ними с помощью клавиш управления курсором. • Зависимости между диалоговыми окнами должны быть очевидными. Иначе, если действия пользователя в одном диалоговом окне отра зятся на доступности опций другого, логически не связанного с ним окна, пользователя это может смутить. Труднонаходимые инструкции Пользователь всегда должен знать, куда посмотреть, чтобы выяснить, что делать дальше. Если экран загроможден информацией, определенная область всегда должна быть зарезервирована для команд и сообщений. Кроме того, хорошим правилом является размещение критической инфор мации в центре экрана. Неуместное использование мигания Мигающее изображение или текст мгновенно привлекает внимание пользователя. Однако ни в коем случае не следует злоупотреблять этим эффектом, поскольку он утомляет и раздражает. Приложение: Распространенные программные ошибки 4 6 7 Пестрые цветовые сочетания Умелый подбор цветов может сделать программу привлекательной и облегчить ее использование, а неумелый — сделать все наоборот. Цвета должны быть ненавязчивыми, спокойными, их не должно быть много. Задача более ярких элементов — привлекать внимание при необходимос ти, а не отвлекать его от основной работы. Обратите внимание на гармо ничность цветовых сочетаний. По возможности следует предоставлять пользователю альтернативу. Использование цветов в качестве смыслового элемента интерфейса Конструктор программы не должен использовать цвета в качестве ин дикаторов, если рассчитывает, что она будет эксплуатироваться широким кругом пользователей. Среди них могут быть дальтоники, а кроме того, у некоторых пользователей могут быть монохромные мониторы. Несогласованность со стилем операционной среды Если в операционной среде программы существуют определенные стан дарты пользовательского интерфейса, лучше всего их придерживаться. Например, в современных графических средах интерфейс командной стро ки выглядит анахронизмом. Даже если конструкторам программы кажется, что они могут предло жить лучшее решение, не каждый пользователь захочет обучаться новым соглашениям. Помните, что пользователь работает не с одной, а с целым комплексом программ, и он будет чувствовать себя гораздо комфортнее, если все они будут оформлены в едином стиле, выводить одинаковые ди алоговые окна в одних и тех же местах и по возможности управляться одинаковыми командами. Невозможность избавиться от избыточной информации на экране Прекрасно, когда на экране отображается меню программы и панели инструментов, но еще лучше, если опытный пользователь может убрать их с экрана и отображать только в случае необходимости, освободив себе тем самым рабочее пространство. Организация команд и способы их ввода В этом разделе речь идет о том, как организованы команды программы и как они представлены пользователю. Все возможные варианты стилей ввода команд рассматривает в своей работе Шнейдерман (Schneiderman, 1987). Мы же предполагаем, что конструктором программы сделан правиль ный выбор, и рассматриваем только ошибки его реализации. 4 6 8 Часть III: Управление проектами и группами Несоответствия Чем большему количеству универсальных соглашений подчиняется программа, тем легче ее изучить и тем более профессионально она выгля дит. Однако выработать такие универсальные соглашения нелегко, и имен но поэтому в программах обычно много несоответствий. Так соблазнительно воплотить каждую идею независимо от других. Однако множество мелких несоответствий, таких незначительных, если рассматри вать их по отдельности, могут сделать программу абсолютно непригодной к использованию. Неуместная оптимизация Часто программисты допускают несоответствия в поведении программы ради повышения ее производительности. Однако каждое несоответствие делает программу более сложной. Постарайтесь убедить в этом программи ста. Стоит ли ради того, чтобы исключить одно-два нажатия клавиш, делать изучение программы более сложным и рисковать доверием к ней пользо вателей? Как правило, нет. Непоследовательный синтаксис Синтаксис команд должен быть простым в изучении, таким, чтобы через некоторое время пользователь просто перестал о нем думать. К син таксису относится, например, следующее: • порядок указания источника и места назначения копируемой или перемещаемой информации; • тип используемых разделителей (пробелы, запятые и т.п.); • порядок следования операторов и операндов (инфиксный (А+В), префиксный (+АВ), постфиксный (АВ+)). Неодинаковый стиль ввода команд Команду можно выбрать из меню с помощью мыши или клавиш управ ления курсором, можно ввести ее первую букву, аббревиатуру, номер или воспользоваться функциональной клавишей. В программе должен исполь зоваться единый командный стиль. Если программа предлагает альтерна тивные способы ввода команд, они должны быть доступны во всех ее меню и режимах. Если же по объективным причинам способ ввода команд в разных частях программы должен быть различным, это должно быть оче видно пользователю. Нелогичные сокращения Если в программе используется командный язык, правила сокращений команд должны быть логичными и легко запоминающимися. Если для Приложение: Распространенные программные ошибки 4 6 9 команды delete используется сокращение del, а для команды list — Is, как пользователю это запомнить? Непоследовательные правила завершения ввода Правила, по которым пользователь сообщает программе, что ввод дан ных в поле завершен, должны быть удобными и логичными. Предположим, что в определенное поле можно ввести имя длиной максимум 8 символов. Если введенное пользователем имя состоит из 5 символов, он нажимает 8 символов, некоторые программы автоматически предполагают, что ввод завершен, и переходят к следующему действию. Это может смутить пользо вателя, а иногда и быть неправильным, если пользователь ошибся и хочет что-то исправить или просто еще думает. Несоответствие опций Если определенная опция имеет смысл для нескольких команд, она должна быть доступна для них всех. При этом она должна одинаково на зываться и задаваться одним и тем же способом. Похожие названия команд Если названия двух команд похожи, их легко спутать. Непоследовательная интерпретация регистра Если интерпретатор команд чувствителен к регистру символов, все названия команд должны соответствовать одним и тем же соглашениям (либо начинаться с большой буквы, либо состоять только из маленьких букв или только из больших). Неодинаковое положение команды в меню Если одна и та же команда встречается в нескольких меню или подме ню, ее трудно располагать всегда в одной и той же позиции. Все же, если постараться, этого можно добиться. Неодинаковое использование функциональных клавиш Везде в программе функциональные клавиши должны быть связаны с одними и теми же командами. Перестановки (когда в одном месте Непоследовательные правила обработки ошибок Встретив ошибку, программа может сообщить о ней пользователю, а может попытаться ее исправить. После этого программа может прекратить работу, перезапуститься или вернуться в предыдущее состояние. Обработ- 470 Часть III: Управление проектами и группами чик ошибок может сохранить информацию о произошедшей ошибке на диске, дописав ее в имеющийся файл, или записав поверх предыдущей информации. Вариантов множество, но поведение конкретной программы должно быть последовательным и предсказуемым. Непоследовательные правила редактирования Для изменения любых введенных ранее данных должны применяться одни и те же клавиши и команды. Непоследовательные правила сохранения данных Программа должна всегда и везде сохранять данные одинаково, с одни ми и теми же интервалами времени и по одним и тем же командам. Нельзя допускать, чтобы в одних случаях данные сохранялись по мере ввода, в других — по достижении конца записи или при выходе из окна, а в тре тьих — вообще только по команде пользователя. Потери времени Программа не должна тратить зря ни одной секунды времени пользо вателя. Прогулки по меню Если программа заставляет пользователя выполнять выбор за выбором, и в конце длинного пути выясняется, что необходимая ему команда нахо дится в другом месте, не реализована или для ее выполнения необходимо вначале сделать что-то еще, едва ли пользователь останется доволен. Про анализируйте сложные деревья меню на предмет таких ситуаций. Выбор, который не может быть сделан В меню не должно быть команд, которые невозможно выполнить. Как можно просмотреть или удалить данные, которых нет? Как можно распе чатать документ при отсутствии принтера? Как почувствует себя пользова тель, если на экране будет написано "Для получения справки нажмите Вы совершенно, совершенно уверены? Программа обязана запрашивать у пользователя подтверждение крити чески важных или деструктивных команд. Прежде чем программа перефор матирует заполненный данными диск, пользователь должен дважды подтвердить свое намерение. Однако не следует заставлять пользователя подтверждать каждую мелочь. Такая навязчивая предупредительность од нажды приведет к тому, что пользователь автоматически нажмет Да для серьезной и разрушительной команды. Приложение: Распространенные програмные ошибки 471 Непонятные названия команд Названия команд должны быть информативными. Не следует заставлять пользователя постоянно справляться в руководстве, что делает та или иная команда. |