Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
выявления каждой из включенных в список ошибок. Если вы сомневаетесь, возможны ли в программе ошибки какого-либо типа, спросите об этом программиста. Приведенный список поможет и т е м , у кого нет времени на разработку документации. Он м о ж е т служить заменой плана тестирования, позволяя организовать и упорядочить работу и гарантировать, что ничего не будет упущено, хотя тесты, разумеется, придется придумывать самостоятельно. 3. Невоспроизводимые ошибки. Ошибку м о ж е т быть трудно воспроизвести из-за того, что вы не знаете ее причины или не знаете, какую функцию выполняла программа в мо мент ее возникновения. Однако не стоит отчаиваться — обратитесь за помощью к этому приложению. Попытайтесь соотнести зарегистрированные симптомы с описаниями оши бок из этого списка. Постарайтесь проявить максимальную гибкость, поскольку ваш отчет об ошибке м о ж е т быть неполным или неточным. Приложение. Распространенные программные ошибки 4 5 5 4. Неожиданные ошибки. Если выявленная ошибка оказывается для вас совершенно неожиданной (например, продукт у ж е готов к выпуску, и вдруг такая неприятность), проверьте, нет ли в программе и других подобных ошибок. Скорее всего дело в том, что вы пропустили определенную группу тестов. Для исправ ления ситуации вам пригодится приведенный здесь список. Ошибки пользовательского интерфейса Понятие пользовательского интерфейса объединяет все аспекты продук та, с которыми имеет дело его пользователь. Разработчики пользовательс кого интерфейса пытаются достичь компромисса между такими факторами, как: • функциональность; • быстрота изучения программы новым пользователем; • легкость запоминания необходимых приемов работы; • производительность; • вероятность возникновения ошибок пользователя; • удовлетворенность пользователя программой. Проектируя пользовательский интерфейс, конструктор программы учи тывает опыт и нужды ее будущих пользователей, а также возможности аппаратного обеспечения и доступных программных технологий. Для достижения разумного баланса между всеми перечисленными ха рактеристиками программы конструктору так или иначе приходится чем- то жертвовать. Поэтому, если в программе встретится одна из перечисленных ниже ошибок пользовательского интерфейса, она вполне может оказаться не случайной ошибкой, а намеренной уступкой, сделан ной конструктором ради улучшения другой составляющей качества продук та. Прежде чем составлять отчет об ошибке пользовательского интерфейса, спросите у конструктора, почему программа спроектирована именно так. Возможно, окажется, что он принял в данном вопросе самое оптимальное решение. Подробное обсуждение вопросов, связанных с разработкой Пользовательского интерфейса, можно найти у таких авторов, как Бейкер и Бакстон (Ваескег & Buxton, 1987), Хеландер (Helander, 1991), Лорел (Laurel, 1990, 1991), Рубенштейн и Херш (Rubenstein & Hersh, 1984), Шнейдерман (Schneiderman, 1987), Смит и Мойзер (Smith & Moiser, 1984). Это приложение написано так, чтобы его мог понять не только тести- ровщик программы, но и ее пользователь. Обязательно учитывайте, что с программой могут работать самые разные люди и их проблемы будут от- 4 5 6 Часть III. Управление проектами и группами личаться от ваших. Поэтому постарайтесь проявить как можно большую гибкость. Функциональность Если с помощью программы трудно, неудобно или невозможно выпол нить что-то, чего может обоснованно ожидать от нее пользователь, значит, в ней имеется функциональная ошибка. Избыточная функциональность Это ошибка, в которой очень трудно убедить разработчиков (Брукс (Brooks, 1975)). Универсальная система, предназначенная для выполнения слишком большого количества разнообразных задач, сложна и в изучении, и в эксплуатации. Ее пользователи постоянно забывают, как выполнить то или иное действие. К тому же таким системам обычно недостает концеп туального единства. Они сопровождаются огромным количеством докумен тации, обширной справочной системой, в которой легко заблудиться, разделы руководств чересчур объемны. Кроме того, многофункциональные системы обычно не отличаются высокой производительностью. Пользова тели часто совершают ошибки, а получаемые ими сообщения об этих ошибках бывают расплывчаты и носят чересчур общий характер. Основным критерием оценки функциональности продукта может быть следующий: если редко используемые функции программы усложняют использование ее базовых возможностей, значит, уровень функционально сти программы выходит из-под контроля. Ложное впечатление о наборе функций продукта Руководства и маркетинговая литература ни в коем случае не должны создавать у пользователя впечатление, что программа может больше, чем на самом деле. Неадекватность реализации базовых функций Если к одной из ключевых функций программы невозможно обратиться и если она реализована слишком узко или слишком медленно работает, такая программа не годится для реальной эксплуатации. Например, если система управления базами данных 8 часов сортирует 1000 записей, ник то не захочет ею пользоваться. Пропущенная функция В программе отсутствует описанная в спецификации или очевидно необходимая функция. Приложение: Распространенные программные ошибки 4 5 7 Неверно работающая функция Функция программы должна выполнять одно (как правило, в соответ ствии со спецификацией), а делает нечто другое. Функция должна быть реализована пользователем "Если система обладает всеми необходимыми пользователю возможно стями, но при этом компоненты, реализующие некоторые из этих возмож ностей, пользователь должен "собрать" сам, то можно сказать, что она является инструментальным набором, а не завершенной программой". (Рубенштейн и Херш (Rubenstein & Hersh, 1984).) Программа не делает того, что ожидает от нее пользователь Например, если программа должна сортировать список имен, едва ли кто-то станет ожидать что имена будут сортироваться в порядке ASCII. Кроме того, пользователи предположат, что программа не будет учитывать ведущих пробелов и регистра букв. Если же программист хочет убедить, что программа должна работать таким неожиданным образом, он должен отра зить это в ее названии и документации, и желательно еще и внести в нее возможность альтернативного способа работы. Взаимодействие программы и пользователя В этом разделе описываются ошибки взаимодействия программы и пользователя. Соответственно предполагается, что речь идет об интерактив ной программе, пользователь которой сидит за компьютером или термина лом. Отдельные ошибки могут относиться и к пакетным программам, которые тоже выдают некоторую информацию, например, сообщения об ошибках. Пропущенная информация Все, о чем пользователю необходимо знать, должно отображаться на экране. Желательно также, чтобы на экране отображалась информация, которую среднестатистический пользователь найдет полезной. Отсутствие инструкций на экране Как определить название программы, как из нее выйти, какую клави шу нажать, чтобы получить справочную информацию? Если в программе используется командный язык, как узнать перечень ее команд? Програм ма может отображать всю эту информацию при запуске, однако в любом 4 5 8 Часть III: Управление проектами и группами случае пользователь не должен обращаться за ответами на все эти вопро сы к руководству. Программа рассчитана на то, что у пользователя всегда под рукой печатная документация Можно ли использовать программу, потеряв руководство? Неопытный пользователь не должен полностью зависеть от печатной документации. Недокументированные возможности Если большинство функций или команд уже перечислены на экране, то позаботьтесь, чтобы были перечислены и все остальные. Пропуск несколь ких из них может смутить пользователя, или же он просто никогда о них не узнает, решив, что на экране есть все, что нужно, и не догадавшись заглянуть в документацию. Аналогичным образом, если для некоторых команд программы описа но их применение в особых случаях, необходимо позаботиться о таких описаниях и для всех остальных. СОСТОЯНИЯ, ИЗ которых сложно найти выход Если пользователю сложно определить, как выйти из нежелательного состояния программы или прервать нежелательный процесс, это так же плохо, как если бы выход не был предусмотрен вообще. Отсутствие курсора Курсор — один из основных инструментов пользователя. Он указыва ет на активную точку экрана, а также подтверждает, что программа рабо тает и ждет указаний. Поэтому курсор (текстовый или указатель мыши) должен обязательно постоянно присутствовать в любой интерактивной программе. Программа не распознает ввод Интерактивная программа должна реагировать на ввод информации пользователем. В частности, если пользователь вводит текст, вводимые символы должны немедленно отображаться на экране. Следующие исклю чения не являются ошибками: • программа находится в процессе перехода из одного состояния в другое; • программа игнорирует определенные действия пользователя; • пользователем дана команда не отображать ввод; • вводится пароль или другая секретная информация. Приложение: Распространенные программные ошибки 4 5 9 Длительное отсутствие активности Выполняя длительное задание (занимающее более двух секунд), про грамма должна показывать пользователю, что она работает, а не зацикли лась или остановилась. Иначе пользователь не будет знать, нужно ли ему перезапустить компьютер или просто немного подождать. Желательно ото бражать еще и индикатор, показывающий, какая часть задания выполнена и сколько времени еще осталось. Невозможность определить, выполнена ли данная программе команда Программа может выполнить команду не тогда, когда этого ожидает пользователь, или не отобразить на экране внесенные изменения. Напри мер, удаленные данные могут оставаться на экране до тех пор, пока пользо ватель не выйдет из текущего режима. Подобные ситуации человек воспринимает как ошибки программы и сам может реагировать на них неправильно, допуская много ошибок. Невозможность определить, что один и тот же документ открыт несколько раз Программы, позволяющие одновременно открывать несколько докумен тов, должны проверять каждый открываемый документ и сообщать пользо вателю, если он открывается повторно. Иначе пользователь может запутаться во вносимых в документ изменениях. Кроме того, версии доку мента должны иметь на экране разные имена. Например, если пользователь дважды открыл файл My_Doc, в одном окне этот файл должен иметь имя My_Doc:l, а в другом — My_Doc:2 (или что-то в этом роде). В качестве альтернативы можно вообще не разрешать дважды открывать один доку мент. Неверная или смущающая пользователя информация Любая встреченная пользователем ошибка тут же подрывает его дове рие ко всей программе. Незначительные на первый взгляд ошибки или недостаточно подробные сообщения программы, из-за которых пользова тель может сделать неверные обобщения или выводы, — обычно наиболее трудная часть работы тестировщиков, поскольку добиться их исправления сложнее всего. Простая фактическая ошибка Обычная последовательность переходов по программе — от общего к частному. Поэтому после выбора пользователем определенного режима или 4 6 0 Часть III: Управление проектами и группами команды на экране нередко остается информация предыдущего режима, большая часть которой излишня или не относится к делу. После каждого видимого изменения состояния программы обязательно проверяйте всю информацию на экране на предмет ее оптимального соответствия новому состоянию. Синтаксические ошибки Программисты не особенно заботятся об ошибках правописания, а вот на пользователя они производят самое неприятное впечатление. Все их необходимо исправлять. Неаккуратное упрощение Пытаясь описать ситуацию или функцию программы как можно проще, автор сообщения может упомянуть только ее важнейший аспект, опустив важные подробности. Не желая пользоваться сленгом, он может переста раться и заменить необходимые профессиональные термины неэквивален тными им и неуклюже звучащими описаниями, что только затруднит понимание сообщения. Обращайте внимание на такие ошибки. Помните, что вы являетесь единственным технически грамотным человеком, анали зирующим выводимый программой текст. Неудачные метафоры Метафоры используются для сравнения компьютерных систем с чем-то знакомым пользователю. Они помогают лучше понять систему и предска зывать ее поведение. Однако, если предположения пользователя окажутся неверны, значит, метафора никуда не годится. Например, метафорой явля ется пиктограмма с изображением корзины для бумаг, используемая во многих программах для команды удаления файлов. Если удаленный файл можно вытащить из корзины, метафора верна. Однако, если файл исчеза ет в корзине навсегда, в качестве метафоры лучше подошел бы измельчи тель бумаги. Неточные названия команд и функций Команда СОХРАНИТЬ не должна использоваться для удаления файла или сортировки его содержимого. Если в русском (английском) языке за словом закрепилось определенное значение, названная этим словом коман да должна ему соответствовать. Несколько названий одной функции Одна и та же функция не должна иметь в программе несколько назва ний. Пользователь не должен ломать голову над тем, чем отличаются ко манды Тень и Наложить тень. Приложение: Распространенные программные ошибки 4 6 1 Избыточность информации Некоторые разделы печатной или интерактивной документации содер жат столько технических подробностей, что интересующая пользователя информация среди них просто теряется. Если, на ваш взгляд, все эти тех нические подробности могут быть полезны пользователю, подумайте о том, чтобы поместить их в отдельный раздел или приложение. В некоторых случаях чересчур подробное руководство является просто попыткой компенсировать неудачное конструкторское решение. Действи тельно ли пользователю нужна вся приведенная информация? И нет ли способа все же решить проблему, которую программист считает неразреши мой? Когда сохраняются данные? Предположим, что вы вводите информацию, которую программа должна сохранить. Сохраняются ли данные по мере ввода, при выходе, по отдель ной команде пользователя, каждые 15 минут или как-то еще? У пользова теля должен быть простой способ, позволяющий это выяснить, причем ответ должен быть совершенно однозначным. Если же вы столкнулись с неоднозначностью, ищите ошибки. Возможно, два модуля программы ра ботают в этом вопросе несогласованно. Неудачная внешняя структура Продукт, предоставляемый пользователю, обычно состоит из ряда ком понентов. Насколько легко разобраться в назначении каждого из них? Неудачная внешняя структура продукта увеличивает время его изучения и отпугивает новичков. Чем меньше необходимо знать пользователю для выполнения определенной задачи, тем лучше. Справочная система и сообщения об ошибках Их текст часто рассматривается как незначительная составляющая про дукта и пишется неопытными программистами или неопытными техничес кими писателями. Изменения этого текста выполняются в последнюю очередь. Следует помнить, что пользователь обращается к справочной системе тогда, когда у него возникают проблемы. О сообщениях об ошибках и говорить не приходится. Пользователь расстроен, нервничает, и ему нуж на помощь, а не дополнительный повод для раздражения. Высокий уровень сложности С экрана читать труднее, чем с бумаги (Шнейдерман (Schneiderman, 1987)). Исследования показали, что максимально допустимым уровнем сложности текста на экране является уровень 5. И уж во всяком случае 4 6 2 Часть III: Управление проектами и группами текст интерактивной справочной системы и сообщений об ошибках не должен быть сложнее, чем текст печатного руководства. Сообщения про граммы должны быть простыми, краткими, предложения должны состав ляться в утвердительной форме и содержать минимум технических терминов, даже если пользователь программы является компьютерным специалистом. МНОГОСЛОВНОСТЬ Сообщения программы должны быть простыми и краткими. Как прави ло, у пользователя программы нет времени на чтение чьих-то многослов ных излияний. Если пользователю потребуется получить дополнительную информацию, лучше предоставить к ней отдельный быстрый доступ. Не стоит заставлять его читать полстраницы ради единственной фразы. Неуместная эмоциональность Сообщения программы должны быть эмоционально нейтральными и предельно корректными. Пользователю едва ли понравится, если програм ма будет тыкать его носом в его промахи. Проверьте, нет ли в программе сообщений, которые могут вызвать у пользователя психологический дис комфорт. В сообщениях об ошибках не должно быть восклицательных знаков — в одних случаях они могут быть восприняты как насмешка или "недоволь ство" программы, а в других — как сигнал опасности. Тщательно подбирай те выражения — учтите, что само по себе появление окна с сообщением об ошибке уже заставляет пользователя напрячься. Поэтому тон сообщения должен быть спокойным, деловым и конструктивным. Слова "авария", "сбой", "разрушение", "потеря данных" крайне нежелательны на экране, и даже слово "ошибка" следует употреблять как можно реже. Тем более, что множество так называемых ошибок носят совершенно рабочий харак тер — это просто ситуации, требующие от пользователя определенных поправок или дополнительных указаний. А многих из них можно было бы избежать, если бы программа была чуточку интеллектуальнее (а програм мист — предусмотрительнее). Фактические ошибки Нередко в документации и сообщениях программы приводятся невер ные примеры того, как правильно выполнить то или иное действие. Одни из них устарели, другие неверны с "рождения". На одном из последних циклов тестирования все они должны быть тщательно проверены. Контекстные ошибки Контекстно-зависимые справочные системы и подсистемы обработки ошибок должны проверять, что делает программа в момент их вызова. Их Приложение: Распространенные программные ошибки |