Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Глава 9: Адаптационное тестирование 2 4 1 цифические символы, такие как ее, которых нет в наборе наиболее распро страненной в западной Европе кодовой страницы 850. На некоторых клавиатурах есть еще одна клавиша, играющая роль Кроме того, неамериканские клавиатуры поддерживают так называемые мертвые клавиши (dead key). Такие клавиши применяются при вводе акцен тированных символов. Они не производят никакого действия, пока пользо ватель не нажмет следующую клавишу, после чего на экране и появляется соответствующий акцентированный символ. И еще одно: программа должна предоставлять пользователю доступ к символам, которые отсутствуют на клавиатуре (иначе как итальянец смо жет адресовать письмо своему немецкому коллеге?) Убедитесь, что про грамма позволяет не только вставлять в текст такие символы (например, путем копирования их из другого приложения), но и правильно их отобра жает. Полноценно выполненное тестирование предполагает работу с програм мой на той клавиатуре и с тем системным программным обеспечением, с которым ее будут эксплуатировать пользователи. Фильтрация ввода Программа может, например, допускать ввод в определенное поле толь ко английских букв, отвергая все другие вводимые пользователем симво лы и управляющие коды. Таким образом она гарантирует, что англоязычный пользователь не сможет ввести в это поле ничего, кроме текста, однако для пользователей с другими национальными алфавитами такое ограничение совершенно неприемлемо. Поскольку подобные ограничения реализуются программным путем, придется как следует протестировать каждое текстовое поле, проверяя, как программа принимает и отображает все символы национального алфавита, разумеется там, где такие символы действительно должны допускаться. Загрузка, сохранение, импорт и экспорт символов основного и расширенного набора ASCII Создайте текстовые файлы со всеми 255 символами расширенного на бора ASCII или тем его подмножеством, которое поддерживается вашей программой. Сохраните их. Посмотрите, что получается при их загрузке с теми кодовыми страницами, которые могут быть установлены у пользова телей. 2 4 2 Часть II: Приемы и технологии тестирования Сохраните полный набор символов во всех поддерживаемых програм мой файловых форматах; попробуйте прочитать файлы всех этих форматов. Если их много, вполне вероятно, что с одним или двумя программа рабо тает плохо. Затем проверьте, как выполняется импорт и экспорт проблемных сим волов. Обратите особое внимание на символы с ASCII-кодами до 32, по скольку они нередко воспринимаются принтерами и различными программами типа текстовых редакторов, не как данные, а как управляю щие коды. Тестируя обмен данными между программами, обратите внимание, чтобы их версии были локализованными. Например, если хотите, чтобы экспортированные программой файлы читались в MS Word, берите его русскую, а не американскую версию. Язык и операционная система Тестировщик должен знать, различаются ли в операционной системе в зависимости от выбранного языка соглашения об именах файлов, их филь трах, имена команд и т.п. Клавиши вызова Подчеркнутые или иным способом выделенные буквы в названиях элементов меню, как, например Файл, означают, что они используются для быстрого вызова команд. При работе с клавиатурой пользоваться ими го раздо быстрее, чем переходить к нужному пункту меню и нажимать < Enter>. Поскольку в локализованной версии продукта все названия ко манд меняются, необходимо изменить и все клавиши их вызова. Кроме того, в программе могут использоваться и другие сочетания клавиш — для команд, которых в меню нет. Их тоже придется пересмотреть и протести ровать. Сборные сообщения Отображаемое программой сообщение может собираться из нескольких фрагментов. Например, часто используемые фразы и словосочетания могут храниться во внутреннем массиве и подставляться во многие сообщения. Очень часто в сообщения вставляются имена файлов, даты и другие данные. Однако если перевести фрагменты сообщения с одного языка на другой, а потом их объединить, результат может оказаться неприемлемым. Просмотрите все выдаваемые программой сообщения на предмет непра вильного порядка слов, несогласования падежей и бессмысленного текста. Глава 9: Адаптационное тестирование 2 4 3 Идентификаторы сообщений об ошибках Как бы хорошо ни была организована техническая поддержка в тех странах, куда экспортируется разрабатываемое вами программное обеспе чение, некоторые вопросы все равно будут переадресовываться в главный офис. При этом возникает ситуация "испорченного телефона" — пока информация о проблеме дойдет по назначению, она может быть несколь ко раз искажена. Немного помочь делу могут уникальные идентификато ры для каждого сообщения об ошибке и предупреждения, выдаваемого программой. Достаточно в конце сообщения просто указать в скобках его код, например, (23). Убедитесь, что при переводе программы на другой язык все номера сообщений остались прежними. Правила переноса В разных языках правила переноса слов отличаются, они могут быть различными даже для разных диалектов одного и того же языка, например, американского и британского английского. Существует несколько языков, в которых при написании некоторых слов через дефис меняется их произ ношение. При удалении переносов программа должна правильно распозна вать такие слова. Правописание Правила правописания для разных диалектов одного и того же языка, например американского и британского английского, могут отличаться. Если в программный продукт включена функция проверки правописания, убедитесь, что она работает правильно. Порядок сортировки Правила сортировки текста от страны к стране меняются. Например, во многих языках, и в том числе в русском, бессмысленна сортировка по значениям внутренних кодов символов (ASCII или ANSI). Хорошая подпрограмма сортировки группирует вместе одинаковые ак центированные символы, например, сначала все о, затем все п. В некото рых языках при сортировке два символа могут интерпретироваться как °дин, например, в испанском слове llama буквы 11 считаются за одну. Осо бые соглашения могут касаться сортировки фамилий. Например, d'Allesio может интерпретироваться как Allesio, van Essen как Essen, a del Zorro как Zorro. 2 4 4 Часть II: Приемы и технологии тестирования Преобразование текста к верхнему и нижнему регистру Только в английском языке для получения прописной буквы из строч ной к ее коду достаточно добавить 32. В других языках это не срабатыва ет. Обратите внимание на ошибки, связанные с преобразованием регистра, особенно распространенные во встроенных функциях поиска и замены текста. Правила подчеркивания В разных странах отличаются и правила подчеркивания. В некоторых из них считается неправильным подчеркивать знаки препинания, пробелы и некоторые другие символы. Принтеры Многие из продаваемых в Европе принтеров точно такие же, как в США. Однако эти рынки различаются, и модели, популярные в одном регионе, могут почти отсутствовать в другом. Существует и ряд принтеров, выпускаемых непосредственно в Европе. У каждого принтера имеется встроенный набор символов, и большин ство из них поддерживают также загружаемые символы. Лазерные и подоб ные им струйные принтеры в этом отношении являются более гибкими, чем матричные и струйные принтеры, подобные матричным. Если програм ма должна поддерживать определенный принтер, проверьте, с каким набо ром символов он продается в интересующем вас регионе. В ROM одной и той же модели устройства могут записываться разные наборы символов в зависимости от того, для какой страны предназначается конкретная партия. Если принтер не поддерживает необходимую кодовую страницу, как пользователь будет печатать данные? Разумеется, ответить на этот вопрос должны не вы, а руководитель проекта, но ваша обязанность, как тестиров- щика, поставить перед ним этот вопрос. Размеры бумаги В Европе обычно используют размеры стандарта DIN, особенно A3 и А4. Имейте в виду, что ширина отдельных листов и перфорированных по краям рулонов для этих размеров немного отличается. Поэтому проверьте оба типа бумаги. Процессоры и видео Каждому, кто разрабатывает программное обеспечение для рынка Microsoft в Европе, стоит протестировать его на оборудовании Olivetti и Amstrad. При этом, составляя календарный план работ по тестированию, не Глава 9: Адаптационное тестирование 2 4 5 рассчитывайте, что все пройдет гладко с первого раза. Обязательно проте стируйте те видеоплаты и видеорежимы, у которых нет хороших американ ских аналогов. Форматы данных и опции настройки У пользователя должна быть возможность выбрать язык (т.е. русский, а не Pascal) и форматы отображения таких базовых типов данных, как время, дата и денежные суммы. Если все эти установки (или некоторые из них) пользователь делает через операционную систему, программа должна их применять. • Формат времени может быть 12- и 24-часовым, с двоеточиями или иными разделителями. В датах могут использоваться как различные разделители (косые, пробелы, дефисы), так и различный порядок чисел, означающих день, месяц и год. • Десятинные и порядковые разделители в числах также меняются от страны к стране. Где одни используют запятые, другие ставят точ ки и наоборот. В частности, американцы используют в качестве де сятичного разделителя точку, а русские запятую. С запятыми связано особенно много ошибок в программном коде. Например, многие подпрограммы автоматически интерпретируют запятую как разделитель элементов списка. • Символ # обычно используется в США для обозначения номера, в то время как в других странах этой цели служат и другие символы, например, очень распространен символ №. • Отрицательные числа не во всех странах пишутся со знаком минус. Часто их заключают в скобки, причем на этот счет тоже существу ют различные соглашения. • Денежные символы могут записываться перед суммой или после нее, причем это может быть один графический символ или несколько букв (не больше трех). Единицы измерения Хотя американцы предпочитают все измерять в дюймах, в других стра нах иные правила. Особенна важна поддержка метрической системы (сан тиметров), неплохо также встроить в программу поддержку пунктов и пик. Это относится, в частности, к линейкам, диалоговым окнам для ввода линейных параметров, установке размеров сетки и т.п. Любые значения длины, ширины и высоты, которые вычисляются, вводятся или использу- тся для отображения объектов на экране, должны измеряться в удобных для пользователя единицах. И даже если операционная система предлага- 2 4 6 Часть II: Приемы и технологии тестирования ет выбор метрической системы, возможно, его стоит дополнить или про дублировать. Изображения, связанные с конкретной культурой Видеоролики, пиктограммы панелей инструментов, заставки, справоч ные окна, печатные руководства, упаковки и маркетинговая литература могут содержать изображения, специфические для конкретной культуры. К этому вопросу следует относиться внимательно, поскольку то, что выгля дит привлекательно для представителей одной культуры, может оказаться неприемлемым для другой. Кроме того, если смысл изображения связан с определенной культурой, то представителям других стран он может быть непонятен. Выходные данные, связанные с конкретной культурой Жителю другой части планеты вовсе необязательно понравится то, что нравится американцу. Жители разных стран по-разному записывают адреса. Для формата выходных данных, календаря, вида бланка заказа и других подобных вещей могут в каждой стране могут быть свои "стандарты". Если задуматься, культурой определяются очень многие вещи. И уж во всяком случае европейцу не понравится, если на выходном документе большими буквами будет написано: "Напечатано американской программой!" Совместимость с местными продуктами Не все программное обеспечение разрабатывается в Соединенных Штатах. Если программа импортирует данные из баз данных, электронных таблиц, текстовых процессоров или других систем обработки информации, стоит проверить, имеются ли на том рынке, для которого она предназна чается, собственные популярные продукты. Совместима ли с ними ваша локализованная версия? Не будьте наивными То, что программа предназначается для операционной системы Macintosh или Windows, еще не означает, что все проблемы локализации решатся сами собой. Разумеется, эти дружественные операционные систе мы многое облегчают и решают целый ряд поставленных в этой главе вопросов, но не все и не всегда полностью. Составьте собственный список локализационных требований, независимый от технической документации по конкретному пользовательскому интерфейсу и от спецификации проек- Глава 9: Адаптационное тестирование 2 4 7 та. Изложенный здесь материал и перечисленная в начале главы допол нительная литература послужат хорошей отправной точкой. Затем самым тщательным образом проверьте программу на соответствие требованиям это го списка. И если что-то не так, обязательно составляйте отчет о проблеме. Автоматизированное тестирование Функции и пользовательский интерфейс локализованной версии про граммы будут практически такими же, как у исходной версии. Поэтому для нее подойдет большая часть уже готовых тестов, разве что текстовые строки придется поменять. Поэтому у вас наверняка появится искушение с самого начала разработать большое количество автоматизированных регрессион ных тестов и применять их для работы со всеми локализованными верси ями. При определенных обстоятельствах такой подход вполне оправдан. Более того, благодаря ему можно гораздо более тщательно протестировать каждую новую версию продукта. Microsoft рекомендовала (1990) пользоваться программами перехвата и сравнения выходных данных, однако сравнивать только их значимые эле менты. Это очень важное ограничение, поскольку текст на экране при переводе программы на другой язык меняется, и если сравнивать его це ликом, то программы сравнения постоянно будут выдавать сообщения о расхождениях. Однако все, что не удастся протестировать автоматически, все равно должно быть проверено. Рекомендуя автоматизировать тестирование, Microsoft добавляет следу ющие замечания: • Разработчик тестов должен знать о тестировании и вопросах лока лизации гораздо больше, чем любой, кто тестирует программу вруч ную, он должен овладеть всеми тонкостями этого дела. • Тестовые сценарии сами могут быть источниками ошибок. Поэтому их следует исключительно тщательно отлаживать, прежде чем при менять для тестирования локализованной версии программного про дукта. Прежде всего, мы рекомендуем автоматизировать работу по тестирова нию тех аспектов программы, которые не связаны с пользовательским интерфейсом. Например, можно написать простенькую утилиту для преоб разования десятичных точек в десятичные запятые и проверять числовые выходные файлы. Можно автоматически сравнивать сохраняемые и экспор тируемые выходные файлы с различными наборами символов. Подумайте, автоматизация каких задач поможет вам значительно сократить время те стирования, особенно если планируется выход локализованных версий продукта для целого ряда стран. Глава Тестирование документации Назначение этой главы Программный продукт — это не только программа. В стоимость боль шинства продуктов входит документация, упаковка, примеры, а также техническая поддержка (и, возможно, некоторые другие услуги). Документация, в свою очередь, обычно состоит из руководства пользо вателя, инструкции по установке, обзорного буклета, README-файла на диске, интерактивной справки и других сведений о том, как пользовать ся продуктом. Все это — важные части программного продукта, и все они подлежат обстоятельному тестированию. Обзор В этой главе рассматриваются следующие темы. • Преимущества хорошей документации. • Цели тестировщика документации. • Как тестирование документации повышает надежность программного продукта. • Распределение персонала. • Руководство пользователя: стадии разработки. • Тестирование интерактивной справки. 10 Глава 10: Тестирование документации 2 4 9 Хорошая документация У хорошо документированного продукта существует ряд преимуществ. • Легкость использования. Если продукт хорошо документирован, им гораздо легче пользоваться. Пользователи его быстрее изучают, де лают меньше ошибок, а в результате быстрее и эффективнее выпол няют свою работу. • Снижение стоимости технической поддержки. Когда пользователь не может разобраться, как выполнить необходимые ему действия, он звонит производителю продукта. Служба технической поддержки обходится очень дорого. А хорошее руководство помогает пользова телям решать возникающие проблемы, и они меньше звонят произ водителю. • Повышение надежности. Непонятная или неаккуратная документа ция делает продукт менее надежным, поскольку его пользователи чаще допускают ошибки, а потом им еще и трудно разобраться, в чем причина и как справиться с их последствиями. Особенно важ на хорошая документация в тех случаях, когда продукт спроектиро ван неудачно и отдельные его функции реализованы не самым лучшим образом. • Облегчение сопровождения. Огромное количество денег и времени тратится на анализ проблем, которые оказываются ошибками пользователей. Изменения, вносимые в новые выпуски продуктов зачастую являются просто сменой интерфейса старых функций. Они вносятся для того, чтобы пользователи наконец разобрались, как ими пользоваться, и перестали звонить в службу технической под держки. Хорошее руководство в значительной степени решает эту проблему, плохое же, наоборот, усложняет ее еще больше. • Упрощение установки. После покупки программного продукта пользователь должен установить его на своем компьютере. Даже если этот процесс полностью автоматизирован, пользователю предстоит ответить на ряд вопросов и принять решения относительно набора и расположения компонентов продукта и настройки его функций. Обычно установочная утилита пишется в последнюю очередь, при чем разработчики относятся к ней менее серьезно, чем к остальным составляющим продукта. Они мотивируют это тем, что пользовате лю придется устанавливать продукт только однажды (ну, может быть, несколько раз, но уж во всяком случае не каждый день). 2 5 0 Часть II: Приемы и технологии тестирования Меньше внимания установочным программам уделяется и при их проектировании, и при тестировании. А ведь у пользователя не будет никакого опыта установки продукта, и некоторые вопросы програм мы могут поставить его в тупик. Для компании это опять же будет означать затраты на техническую поддержку. Поэтому четкие и понятные инструкции по установке продукта являются одной из наиболее важных составляющих его документации. Установка некоторых типов программного обеспечения (таких, например, как телефонные системы) настолько сложна, что пользо ватели нанимают для этого специалистов. Такие специалисты-уста- новщики работают с очень многими продуктами, и не следует ожидать, что они являются экспертами по каждому из них. Установ щик просто обращается к руководству, и при отсутствии четких инструкций ему может быть сложно принять верные решения. Не которые продавцы вообще отказываются принимать продукты, уста новка которых обходится им слишком дорого. Кроме инструкций по установке, программное обеспечение должно сопровождаться и инструкциями по его удалению из системы. В документации также должно поясняться, как изменить параметры настройки, добавить или удалить компоненты продукта и выполнить установку его новой версии поверх предыдущей. • Коммерческий успех. Качество документации является одним из факторов, определяющих коммерческий успех программного про дукта. Дилерам, вооруженным хорошей документацией, легче де монстрировать продукт покупателям и рассказывать о его возможностях. Во многих обзорах программного обеспечения, печа таемых в профессиональной прессе, документации уделяется значи тельное внимание. • Достоверность информации. В документации не должно быть не верной информации, вводящей пользователей в заблуждение и зас тавляющей их тратить лишнее время и усилия. Если в документации сказано, что в программе присутствует определенная функция и она работает определенным образом, то так и должно быть. Едва ли суд согласится с утверждением адвоката компании, что не следует принимать документацию всерьез, поскольку этого не делал никто из сотрудников. Те сотрудники, которые не понимают важности достоверной рекламы и документации, явно работают не на своем месте. |