Опубликован: 15.05.2013 | Доступ: свободный | Студентов: 265 / 10 | Длительность: 24:25:00
Специальности: Системный архитектор
Лекция 16:

Специальные возможности

< Лекция 15 || Лекция 16: 12345678910

Тестирование с использованием псевдо-языка

Как бы интересен ни был процесс перевода приложения на многие языки, есть и задача всё это как следует протестировать, весьма трудозатратная задача, если вы используете много языков! Для уменьшения этой нагрузки лучший подход заключается в тестировании вашего приложения с использованием Псевдо-языка (Pseudo Language), шаг, который, в идеале, предшествует оценке стоимости перевода. Он поможет вам проверить, верно ли ваше приложение работает с разнообразными языками, так как вымышленный Псевдо-язык содержит некоторые из наиболее проблематичных характеристик локализованного текста.

Как упоминалось в предыдущем разделе, этот язык автоматически добавляется в проект посредством окна выбора языков средства для многоязычных приложений. Создаётся файл Pseudo Language (pseudo).xlf в папке MultilingualResources, рядом с файлами реально используемых языков. После этого нужно щелкнуть данный файл правой кнопкой мыши и выбрать команду Создать псевдопереводы (Generate Pseudo Translations). Эта команда заполнит XLF-файл переводами ваших ресурсов по умолчанию, где обычные символы будут часто конвертированы в расширенные символы и строки обычно завершаются множеством присоединенных "!!!!!", В итоге, строка наподобие "Recent pictures" будет переведена как "[62BD8][!!_????й? ????µ???_!!!!]" где шестнадцатеричный код в первых квадратных скобках [ ] это идентификатор ресурса, который помогает тестировщику определить реальный используемый ресурс. (Обратите внимание, что этот процесс "переведет" каждую строку, независимо от того, будете ли вы переводить эту строку для реальных целей, так как это полезно для тестирования.).

Для того, чтобы запустить приложение с таким переводом, вам нужно сделать Псевдо-язык языком системы по умолчанию. Перейдите в раздел Панель управления>Часы, язык и регион>Язык (Control Panel>Clock, Language, and Region>Language), нажмите на кнопку Добавить язык (Add Language) и введите qps-ploc в поле поиска. Это единственный способ, благодаря которому появится опция Псевдо-язык (Pseudo Language):


Выбрав этот язык, нажмите Добавить (Add) и переместите его в верхнюю часть списка:


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


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

Это время, когда вы должны быть внимательны, как никогда, так как, как только вы отправите приложение в Магазин Windows, выпуск следующего обновления займёт неделю-две, а в течение этого времени ваши пользователи могут обнаружить эти проблемы, что соответствующим образом отразится на рейтинге вашего приложения. Об этом всегда стоит помнить, особенно, если вы привыкли к мгновенному исправлению ошибок на веб-сайтах: для приложений требуется больше времени, поэтому лучше потратить больше времени на тестирование.

Чистовая отделка локализации

Итак, мы почти завершили работу над приложением и готовы отправляться в Магазин Windows! Осталось лишь упомянуть еще кое-о чем, касающемся локализации:

  • Тестирование с использованием псевдо-языка не позволяет проверить возможности по отображению данных для RTL-языков. Вам нужно запускать тесты для таких языков отдельно. Я счастлив сказать, что когда я запустил "Here My Am!" в подобных условиях (с ивритом, например), макет был автоматически отражен благодаря стилю direction , заданному в таблицах стилей WinJS.
  • Убедитесь, что протестировали абсолютно все варианты взаимодействия с онлайновыми службами, в том числе – периодические обновления плиток и индикаторов событий, которые поступают с помощью push-уведомлений.
  • Если вам нужно динамически обновлять приложение, когда пользователь меняет язык (вместо того, чтобы перезапускать приложение), прослушивайте событие WinJS.Resources.oncontextchanged и вызывайте WinJS.Resources.processAll. Этот код есть в "Here My Am!" и в Сценарии 6 примера "Ресурсы приложения и локализация" (http://code.msdn.microsoft.com/windowsapps/Application-resources-and-cd0c6eaa):
    WinJS.Resources.addEventListener("contextchanged", function () { WinJS.Resources.processAll();
    });
  • Вышеприведенный код обновит строковые ресурсы, но не графические ресурсы или содержимое, полученное из сетевых источников. Если вам нужно это сделать, выполните другие обновления с помощью дополнительного кода, такого, как реализация передачи Windows нового URI для периодических обновлений плиток или указание нового языка сервису, который отправляет push-уведомления. Для всего пользовательского интерфейса приложения, попытайтесь использовать команду document.location = document.location + "?reload", возьмите переданный в URI параметр в обработчике активации и выполните дополнительные шаги. Это очень похоже на перезапуск приложения.
  • Если хотите, вы можете позволить пользователю выбирать язык приложения независимо от системных языковых установок. Это выполняется с помощью установки свойства Windows.Globalization.ApplicationLanguages. primaryLanguageOverride, как показано в Сценарии 10 примера "Ресурсы приложения и локализация". В Сценарии 11, кроме того, показана загрузка специфических языковых ресурсов, а не ресурсов по умолчанию.
  • В Visual Studio, откройте манифест в XML-редакторе (щелкните правой кнопкой и выберите команду Перейти к коду (View Code)) и проверьте, видите ли вы эту строку в элементе Resources: <Resource Language="x-generate"/>. Если это так, замените её на индивидуальные записи, наподобие <Resource Language="en-US" />, первая из которых – это ваш язык по умолчанию, и у вас должны быть локализованные ресурсы для всех остальных. В дополнение, у вас может быть как минимум один "язык сертификации", как описано в материале "Сборка пакета приложения" (http://msdn.microsoft.com/library/windows/apps/hh694075.aspx), иначе приложение не пройдет сертификацию в Магазине Windows.
  • Для перевода "на лету" вы можете воспользоваться различными веб-сервисами, такими, как Microsoft Translator (http://www.microsofttranslator.com/dev/).

Выпуск приложения

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

Так как процесс отправки приложения хорошо документирован в материале "Продажа приложений" (http://msdn.microsoft.com/library/windows/apps/br230836), я не собираюсь тратить наше время, показывая вам кучу скриншотов Информационной панели (https://appdev.microsoft.com/StorePortals), где всё это выполняется. Я укажу вам на конкретные страницы соответствующих документов, если будет нужно, но это будут разделы документации, которые вам нужно будет просмотреть. В конце концов, Магазин Windows – это канал продажи для ваших приложений, в итоге, вам нужно будет понять этот канал так хорошо, как только возможно. Информационная панель Магазина Windows, кроме того, создана для того, чтобы провести вас через все этапы данного процесса.

То, на чем мы здесь сконцентрируемся, это те аспекты процесса, которые не всегда очевидны, основываясь на реальном опыте, который я и мои сослуживцы получили в Windows Ecosystem Team в ходе работы с первыми партнерами над отправкой приложений в Магазин Windows. Посредством этого я надеюсь повысить ваши знания о возможных проблемах, с которыми вы можете столкнуться, в итоге, вы лучше будете подготовлены к ним. Затем мы поговорим об обновлениях приложения и об увеличении вероятности обнаружения вашего приложения пользователями благодаря его связью с вашим веб-сайтом.

Врезка: установка целей построения

Когда вы создаете пакет вашего приложения для загрузки его в Магазин Windows, не забудьте установить конфигурацию приложения в значение Выпуск (Release) вместо значения Отладка (Debug), иначе оно не пройдёт сертификацию. Выбирая целевую платформу, установите её в значение "Any CPU", если только у вас нет WinRT-компонентов, написанных на C++. Таким образом, JavaScript и .NET-языки (C#/VisualBasic) архитектурно-нейтральны. С другой стороны, всё, аписанное на C++, должно компилироваться под конкретную платформу: x86, x64,и ARM. Чаще всего вам придется создавать три варианта построения для этих архитектур, которые вы будете загружать в Магазин Windows отдельно.

Рекламные скриншоты, изображения и тексты для Магазина Windows

Прежде чем вы сделаете что-то еще, связанное с вашим приложением и Магазином Windows, посмотрите материал "Представление приложения в Магазине Windows" (http://msdn.microsoft.com/library/windows/apps/hh694057.aspx) и дополнительные материалы: "Информация об описании приложения" (http://msdn.microsoft.com/library/windows/apps/hh694060.aspx), "Выбор изображений для вашего приложения" (http://msdn.microsoft.com/library/windows/apps/hh846296.aspx). Кроме того, обратитесь к материалу "Подготовка приложения для отправки в Магазин Windows" (http://msdn.microsoft.com/library/windows/apps/hh694079.aspx), который предоставляет множество ценных сведений о процессах, которые предшествуют отправке приложения, в частности, он содержит ссылки на такие материалы, как "Выбор названия приложения" (http://msdn.microsoft.com/library/windows/apps/hh694079.aspx) и "Что необходимо включить в описание приложения" (http://msdn.microsoft.com/ru-RU/library/windows/apps/hh694076.aspx).

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

Позвольте мне повторить снова: всю эту информацию потенциальный покупатель будет использовать для оценки вашего приложения до того, как он нажмёт кнопку для того, чтобы получить это приложение. Это маркетинговые материалы, простые и понятные, поэтому пусть они будут просто великолепными! Потратьте некоторое время на написание по-настоящему хорошего текста описания приложения – можете даже передать их профессиональному редактору или нанять профессионального технического писателя. Если вы чувствуете, что ваше приложение забавное и увлекательное, расскажите об этом через тексты и изображения. На самом деле, вы ведь хотите, чтобы первое впечатление пользователя о вашем приложении – после взгляда на страницу приложения – было бы в стиле "Ух ты!". И именно вышеупомянутое содержимое определяет подобную реакцию.

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

Сертификат с оценкой игры. Отправляя в Магазин Windows игру, вы должны получить сертификат с оценкой игры в форме GDF-файла. Для того чтобы узнать подробности, смотрите материал "Требования к публикации игр в Windows" (http://msdn.microsoft.com/library/windows/apps/hh452788.aspx).

Тестирование и комплект сертификации приложений для Windows

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

На самом деле, для многих разработчиков, особенно тех, которые сконцентрированы на веб, как я ожидаю, и для мноогих читателей, строгое тестирование не является одним из их ключевых занятий. Я думаю так из-за природы веб-разработки, когда вы можете загрузить на сайт исправление, которое мгновенно возымеет действие, что не требует особой дисциплины в тестировании. Часто ли вы видите, как ваши любимые веб-сайты просто не доступны весь день, или плохо работают несколько часов, а затем снова возвращаются к жизни? Это, возможно, потому что какой-нибудь разработчик допустил неприятную ошибку, которая была обнаружена и исправлена в течение этих часов. Для некоторых сайтов это подобно катастрофе, но для многих других это нежелательно, хотя и не смертельно.

Говоря другими словами, стоимость ошибок в веб-приложениях обычно очень мала, так как время обновления так же очень мало. Но это не так для приложений. Время с момента, когда вы отправляете приложение в Магазин Windows, до того момента, когда оно будет доступно потребителям, это, как минимум, неделя, если не больше, в зависимости от загруженности Магазина Windows. Это означает, что каждая отправка весьма важна.

Посмотрим на это с точки зрения затраченного времени. Скажем, для того, чтобы загрузить исправление для веб-приложения, нужно пять минут. Сравните это с количеством минут в неделе, которых в ней 10800. Каково соотношение? 1 к 2016. Другими словами, это, как минимум в 2000 раз дороже с точки зрения времени и усилий, потраченных на обновление приложения в Магазине Windows. Говоря с практической точки зрения, это значит, что вам придется потратить гораздо больше усилий на тестирование приложений, чем на тестирование веб-сайтов. И не так уж и мало! (И не возражайте, говоря, что вы тратите нулевое время на тестирование веб-приложений, а значит и цена обновления при таком подходе так же равна нулю)

Если у вас нет методологии тестирования, тогда начните её создавать, даже с нуля. Например, не забудьте всегда тестировать ваше приложение на чистой установке Windows 8, на компьютере без лицензии разработчика, а так же на маломощных компьютерах, производительность которых похожа на производительность многих ARM-устройств. У одного из разработчиков, с которым я работал, было приложение, которое было отвергнуто Магазином Windows, так как оно просто было пустым при первом запуске – он никогда не видел, как это происходит из-за кэшированных данных, которые были на его компьютере!

Вам так же нужно построить хороший список того, что нужно делать с вашим приложением, чтобы исполнить все ветви его кода. Это должно включать и учет тех условий, которые являются внешними по отношению к приложению: изменение режимов просмотра и ориентации устройства; активация различных чудо-кнопок; изменение состояния соединения с сетью; работа с медленными каналами передачи данных; удаление временных файлов приложения с помощью средства очистки диска; вход с различными учетными записями; приостановка, возобновление работы и запуск после остановки; работа в высококонтрастных режимах и с другими специальными возможностями; работа в системах с разными языками. Чем лучше ваше приложение ведет себя во всех этих условиях, тем более целостным будут видеть его пользователи, которые пишут отзывы и ставят оценки. Я рассказал об этом в видео, которое называется "Beyond Just Beautiful", которое вы можете найти на странице "Принципы работы и архитектура" (http://msdn.microsoft.com/library/windows/apps/br211361.aspx) в Центре разработчиков.

Помимо этого есть некоторые отличные материалы в документации, которые помогут вам выполнить данные шаги:

Другая очень важная часть тестирования – это испытание приолжения с помощью Комплекта сертификации приложений для Windows (Windows App Certification Kit, WACK). Данный инструмент подвергает ваше приложение всем автоматизированным тестам, которые оно проходит после отправки в Магазин Windows, таким образом, позволяя вам исправить найденные проблемы. Прохождение тестов WACK не гарантирует, что ваше приложение будет принято, но, определенно, сохраняет вам много времени на ожидание результатов отправки и избавляет от необходимости повторно отправлять приложение снова и снова. Вам следует, на самом деле, запускать WACK практически ежедневно в процессе разработки. Вам не обязательно исправлять всё, что он обнаружит, сразу же, но текущие данные будут весьма полезными.

Для того, чтобы узнать подробности об этом инструменте и о работе с ним, смотрите материал "Тестирование приложения с помощью комплекта сертификации приложений для Windows" (http://msdn.microsoft.com/library/windows/apps/hh694081.aspx) и "Тестирование приложений с помощью комплекта сертификации приложений для Windows" (http://msdn.microsoft.com/library/windows/apps/jj657973.aspx).

Совет. Если вы обнаружили, что WACK не отображает приложения для тестирования, попытайтесь деинсталлировать примеры SDK, которые вы могли запускать из Visual Studio. Такое ощущение, что иногда этот инструмент испытывает перегрузки.

< Лекция 15 || Лекция 16: 12345678910