Что такое lsp тестирование
Как протокол языкового сервера LSP влияет на будущее IDE
В 2016 году компания Microsoft сделала две очень важные для разработчиков вещи — выпустила редактор Visual Studio Code, который разом изменил всю экосистему для программистов, а также представила протокол языкового сервера LSP. Мы перевели статью сервиса FreeCodeCamp — о том, как LSP меняет будущее IDE, в том числе и Visual Studio Code, и почему этого никто не замечает.
Что такое LSP?
Протокол языкового сервера (LSP) — это способ (или протокол) общения с языковыми серверами, такой же как HTTP или FTP. Языковые серверы — это специальные программы, которые работают на обычных серверах. Они принимают мета-состояние редактора, в котором пишется код: например, где находится курсор в редакторе и на что он наведён прямо сейчас. После анализа они возвращают набор инструкций, какое действие можно выполнить на текущем токене, если пользователь использует специальные сочетания клавиш.
Эта связь происходит с использованием набора правил, определенных протоколом. Протокол языкового сервера можно рассматривать как урезанную версию HTTP, который обменивается данными только через JSON-RPC.
Зачем нужен LSP?
Вы постоянно видите сообщения об ошибках и автопредложения для изменения кода, которые появляются в VSCode? Как так получается, что просто добавив расширение из магазина VSCode, вы получите всю мощь технологии автодополнения IntelliSense для совершенно другого языка, такого как C, Python, Java? Как раз это и происходит из-за LSP.
Поддержка автозаполнения и IntelliSense для HTML/CSS/JavaScript поставляется с VSCode (так же, как PyCharm поставляется с поддержкой Python). Однако такая же поддержка других языков может быть реализована с использованием протокола языкового сервера для этих языков.
Что такое JSON-RPC?
JSON-RPC означает удаленный вызов процедуры JSON. Эта архитектура аналогична архитектуре REST, в которой основной единицей является вызов процедуры, а не конечная точка API, как в случае с REST.
В этом примере мы отправляем полезные данные в кодировке JSON в соответствии со спецификацией RPC. Если сервер корректно настроен для обработки JSON-RPC, он выполнит метод runThisFunction с переданными параметрами, после чего вернет результат, как показано в примере выше.
LSP + JSON-RPC
LSP использует JSON-RPC для связи с удаленным сервером. Это должно соответствовать такому формату:
Почему это вообще важно?
С введением протокола LSP компания Microsoft свела знаменитую M*N проблему к M+N проблеме.
M — это разные языки (C, C ++, PHP, Python, Node, Swift, Go и т. д.)
N — разные редакторы (VSCode, Eclipse, Notepad ++, Sublime Text и т. д.)
Раньше, чтобы редакторы M поддерживали N-языки, нужно было реализовать M*N решений. При этом поддержка языков должна была быть нативной. Сделав это однажды, кто угодно сможет интегрировать поддержку своего языка в редактор кода, даже если тот его «не знает». При этом во время работы с LSP редактор даже не будет знать, с каким языком сейчас работает пользователь.
Будущее IDE
По мере того, как все больше и больше языков переходят на свои языковые серверы, люди получат большое количество редакторов и смогут выбрать наилучший для себя
В будущем пользователям больше не придется использовать только XCode для разработки на Swift, или PyCharm для Python. И не только это, ведь LSP может быть реализован на JavaScript для поддержки прямо в браузере! Прекрасное будущее уже почти наступило!
Влияние протокола языкового сервера (LSP) на будущее IDE
С момента своего появления Visual Studio Code в одиночку так сильно повлиял на экосистему разработчиков, что возврата назад уже не будет. Это общедоступный бесплатный инструмент с открытым исходным кодом и это очень мощный инструмент.
Что такое Протокол языкового сервера?
Это взаимодействие происходит с помощью набора правил, заданных протоколом. Протокол языкового сервера можно рассматривать как урезанную модификацию HTTP взаимодействующую только по JSON-RPC протоколу.
Зачем нужен LSP?
Вы заметили, что в VSCode постоянно появляются изобретательные сообщения об ошибках и предложения автоподстановок? И как же легко, просто установив расширение из магазина VSCode, вы получаете всю мощь IntelliSense для совершенно разных языков, таких как C, Python, Java и т.д.? Все это происходит благодаря LSP.
Поддержка автозавершения и IntelliSense для HTML/CSS/JavaScript идет сразу вместе с VSCode (так же, как PyCharm идет сразу с поддержкой Python). Однако такая же поддержка других языков может быть реализована с помощью протокола LSP для этих языков.
Что такое JSON-RPC?
Это простой пример для JSON-RPC:
В этом примере мы посылаем запрос в кодировке JSON в соответствии со спецификацией RPC. Если сервер настроен на корректную работу с JSON-RPC, то он выполнит метод runThisFunction с переданными параметрами и вернет результат в том виде, как показано выше.
LSP + JSON-RPC
LSP использует JSON-RPC для связи с удаленным сервером. Для этого используется следующий формат:
Почему все это так важно?
С введением формального протокола LSP, Microsoft свела знаменитую проблему M x N к проблеме M + N.
M = Различные языки (C, C++, PHP, Python, Node, Swift, Go и т.д.).
N = Различные редакторы кода (VSCode, Eclipse, Notepad++, Sublime Text и т.д.).
Раньше для того, чтобы M редакторов поддерживали N языков, вам нужно было иметь M*N решений. То есть каждый редактор кода должен был реализовать поддержку каждого языка самостоятельно.
С появлением LSP в редактор оставалось лишь внедрить поддержку протокола языкового сервера. После этого любой, кто делает языковой сервер (следуя стандартам LSP), может легко интегрироваться в редактор кода, при этом редактор никогда не будет «знать», с каким языком он работает!
Будущее IDE
По мере того, как языковые сервера реализуются для различных языков программирования, у разработчиков появляется возможность выбирать редактор на свой вкус. Без привязки к конкретному языку. Нет больше необходимости ограничивать себя, например только XCode для разработки на Swift или PyCharm для Python. И не только это, LSP можно внедрить прямо в JavaScript для поддержки IntelliSense в браузере! Настало потрясающее время для программистов!
Как тестировать сайты
Допустим, вы сделали сайт, но у вас нет тестировщика, который может всё проверить. Вот короткая инструкция, на что смотреть, чтобы с большой вероятностью после запуска всё было в порядке.
Когда тестирование полезно
В больших компаниях каждым пунктом из этой статьи могут заниматься целые отделы, сотрудники которых досконально проверяют каждую мелочь — руками или автоматически. Но представим, что сейчас под рукой нет IT-департамента. Что можно сделать самостоятельно и быстро, чтобы проверить, что всё работает как задумано.
Предупреждение: статья не претендует на академическую полноту, но точно поможет что-нибудь не упустить.
Всё посмотреть и прокликать
Сначала нужно проверить, что всё выглядит, как задумано заказчиком — сайт совпадает с макетом, кнопки работают и ссылки ведут, куда нужно.
Что проверять:
Иногда используют автоматические тесты, которые сравниваются отрендеренный результат кода аля интерфейс с рендер-версией приложения. Фактически, это сравнение скриншотов. Конечно, автотесты можно подготовить и для тестирования интерактивных элементов.
Фрагмент реального сайта о том, что тестирование полезно
Инструменты:
Ошибки JavaScript
Если в коде есть ошибки, их будет видно в консоли разработчика. Также там можно обратить внимание на запросы (время и коды ответов) и посмотреть размер загружаемых файлов. И если размер большой, обсудить с разработчиками оптимизацию кода на JavaScript, шрифтов и изображений.
Валидность кода
Нужно убедиться, что код удовлетворяет стандартам HTML/CSS, для этого есть специальные валидаторы. Узнайте, как проверить валидность HTML.
Веб-формы
Формы — кладезь пользовательских данных и одновременно потенциальный источник уязвимостей. Формы должны быть удобными для пользователя и безопасными для сайта.
Что проверять:
Неправильные ссылки
Проверьте, что все ссылки ведут на настоящие сайты и не ведут на 404. Для этого тоже есть несколько инструментов. На главной не должно быть ссылки на главную.
Уберите ссылку на главную с главной
Локализация
Если пользователи сайта говорят на разных языках, сайт локализуют — готовят тексты на разных языках и добавляют переключалку с флагами.
Но недостаточно проверить перевод текстов в интерфейсе, ошибок и документации — есть ещё ряд нюансов. Например, нужно проверить представление дат и времени, поддерживает ли шрифт локальные символы, и есть ли режим RTL для стран, где текст читается справа налево.
Производительность сайта
Пользователи уходят, если сайт грузится медленно. Поэтому нужно проверить, что ваш сайт не такой.
Что проверять
Иногда скорость загрузки зависит от контента, который используется на странице. Вот советы, как его оптимизировать.
Критерии качества
На курсах HTML Academy сайты верстают и готовят к публикации на основе критериев качества — длинного списка правил, который нужен, чтобы делать сразу хорошо. Критерии включают не только то, что написано в этой статье — там гораздо больше мелочей, которые должен знать хороший фронтенд-разработчик.
Делать сразу хорошие сайты
Всё, что нужно фронтендеру — на курсах HTML Academy. Научитесь всему, чтобы у тестировщиков закончилась работа.
Вкусный и здоровый гайд по юзабилити-тестированиям
В этой статье будет подробно рассказано о том, как проводить удаленное модерируемое юзабилити-тестирование на наглядном примере
Расскажу вам историю о том, как непродуманный интерфейс помешал мне сделать покупку.
Я ввел в поисковой строке “Шантрам” и получил коллекцию книг про “шатры”. Это меня озадачило.
Я открыл еще несколько книжных интернет-магазинов и попробовал ввести в каждом “Шантрам”. Бинго! Из трех магазинов, один нашел “Шантарам” Робертса, несмотря на то, что я переврал название. Как я был рад. Времени на поиски потратил много, но в итоге нашел желаемое и купил книгу.
А в Лабиринте, кстати, книга была, просто поиск у него работает так, что если ошибешься, то ничего не найдешь. Такое часто встречается в интернет-магазинах.
В целом интерфейс Лабиринта хорош, но казалось бы проблема в поисковом алгоритме привела к потере клиента и падению конверсии. Обидно, досадно! Этого можно было бы избежать, если провести юзабилити-тестирование на пользователях и исправить обнаруженные проблемы.
Юзабилити тестирование – это способ понять, удобен ли интерфейс. Обычных пользователей приглашают поработать с продуктом и наблюдают как они выполняют задания и с какими сложностями сталкиваются в процессе.
Тестирование организует юзабилити-специалист, который планирует исследование, проводит сессии тестирования, анализирует результаты и пишет отчет.
Мы в компании “Ю-эксперт” специализируемся на юзабилити-услугах и особое место среди них занимает юзабилити-тестирование. В этой статье мы познакомим вас ближе с этим методом и подробнее расскажем как он работает.
Что можно узнать благодаря юзабилити-тестированию
Увидеть точки снижения конверсии и узнать, почему клиенты уходят
Получить список проблем с приоритетами и рекомендации, как их устранить.
Узнать, почему пользователь уходят с сайта
Узнать, что мешает клиентам сделать покупку / зарегистрироваться / совершить конверсионное действие
Для каких продуктов подходит
Тестировать можно любые продукты, с которыми работают пользователи и это не только компьютерные интерфейсы:
Терминалы, банкоматы, кассы самообслуживания
В каких отраслях применяется
Юзабилити-тестирование применимо во многих отраслях, но чаще всего его используют интернет-магазины, банки и финансовые организации, сотовые компании, государственные структуры, онлайн-сервисы предоставляющие услуги, например: обучение английскому, продажа электронных билетов и тп.
Юзабилити-тестирование используется для:
Проверки прототипов нового продукта
Качественное тестирование проводят:
Если у компании есть бюджет только на один вид тестирования, то мы советуем начинать с качественного, так как оно найдет проблемы, а затем переходить к количественному, которое определит, насколько проблемы критичны.
Помимо перечисленных вариантов юзабилити тестирование можно комбинировать с другими типами исследований, например, с глубинным интервью, карточной сортировкой, наблюдением и тп.
Прежде чем начинать юзабилити-тестирование определитесь с целями и объектом тестирования. Этот этап нужен всегда, включая случай, когда тестирование проводится внутри компании без привлечения внешних специалистов.
На встрече с бизнесом обсуждаем:
Вопросы к пользователям
Примеры вопросов бизнесу
Какой продукт изучаем?
Пример: сервис доставки пиццы
Представьте, что нужно провести юзабилити-тестирование сервиса доставки пиццы и роллов. У компании есть сайт, мобильная версия сайта и мобильное приложение. Бюджет и время ограничены, поэтому нужно выбрать только один интерфейс для тестирования. Посмотрев аналитику сайта (yandex или google), специалист увидел, что наиболее востребован мобильный сайт, поэтому с него он будет начинать тестирование.
На встрече с бизнесом были обозначены три основные задачи для тестирования:
Состав участников тестирования зависит от задач бизнеса. На исследование можно приглашать как существующих клиентов, так и потенциальных пользователей.
Если цель бизнеса привлечь новых пользователей или заинтересовать клиентов конкурирующей компании, то на тестирование стоит приглашать респондентов, которые еще не работали с продуктом, но он может быть им интересен.
Сколько человек приглашать на юзабилити-тестирование
Якоб Нильсен, один из основоположников юзабилити, писал, что 5 пользователей находят 85% проблем в интерфейса. Мы склоняемся к тому, чтобы приглашать по 8 человек из каждой целевой группы, так как это позволит обнаружить 95% проблем.
Если тестирование проводится для двух и более сегментов целевой аудитории, то из каждого приглашают по 4-6 человек, в зависимости от того, насколько сильно они отличаются. Например, если группа 1 никогда не работала с продуктом, а группа 2 состоит из опытных пользователей, то из каждой нужно взять минимум по 5-6 человек.
Пример: каких пользователей пригласить на тестирование сервиса доставки пиццы
Теперь заказчику нужно определиться с целевой аудиторией. Если в компании есть специалисты, которые непосредственно общаются с пользователями, то они могут помочь с портретами клиентов. Также хорошим подспорьем будет статистика на сайте. Требования к участникам тестирования прописываются в “скринере”.
В случае с доставкой еды аудитория будет широкой, многие любят пиццу и роллы. Основной критерий для набора респондентов можно сформулировать так: пользователь заказывал роллы или пиццу с доставкой хотя бы раз в течение трех месяцев.
Можно пригласить 4 опытных пользователей, которые хотя бы 1-2 раза в месяц заказывают еду через мобильный сайт и 4 неопытных пользователей, которые делают заказы реже раза в месяц.
В случае с пиццерией достаточно 8 пользователей:
4 клиента данной пиццерии и 4 потенциальных клиента. В основу выборки можно заложить опыт работы с сервисом, так как он непосредственно влияет на то, с какими проблемами столкнутся пользователи. Если задача бизнеса привлечь новых клиентов, то можно пригласить только тех, кто не пользовался сайтом ранее.
Важно помнить, что участники тестирования не будут работать на чистом энтузиазме, их надо поощрять. В зависимости от проекта вознаграждение варьируется.
Самый лучший респондент тот, кому интересен продукт. Поэтому, если можно наградить участника непосредственно тем, что предлагает компания, на тестирование придут самые заинтересованные пользователи.
Например, если тестируется интернет-магазин для кошек и собак, то респонденту дают купон на определенную сумму для приобретения любых товаров на сайте. Если тестируются курсы английского языка, то пользователь получает несколько бесплатных уроков. Если важно привлечь пользователей, которые не являются фанатами продукта, то тогда предлагайте денежное вознаграждение.
Пример: какое вознаграждение использовать для респондентов, тестирующих сервис доставки пиццы
В случае с доставкой пиццы и роллов респондент во время исследования может заказать настоящую пиццу и роллы, которые съест после тестирования, плюс его наградят дополнительным купоном на будущий заказ.
Сценарий тестирования в чем-то похож на сценарий фильма. В нем прописываются все основные вопросы, который модератор задает пользователю, действия, которые в идеальной ситуации должен совершить пользователь и критерии, по которым мы считаем эти действия успешными или нет. Как и в случае с кино, без сценария тестирование не проводят.
Основные разделы сценария
Задания тестирования. Это основная часть сценария. В каждой задаче формулируется цель, которую пользователь должен достичь и описываются обстоятельства, которые влияют на процесс ее достижения. Желательно сформулировать задачу таким образом, чтобы она перекликалась с реальными потребностями респондента и его ответами на вводные вопросы.
Обычно в часовое тестирование укладывается 5-7 задач
Пример сценария для тестирования сервиса доставки пиццы
Вступительная часть сценария стандартная. Здесь модератор рассказывает респонденту, что тестировать будут не его способности, а интерфейс. В зависимости от целей исследования пользователя просят комментировать выполнение задач или хранить молчание. Второй метод используется, когда необходимо замерить время выполнения задания. Тогда комментарии респондент дает уже после выполнения задания.
Пользователя обязательно спрашивают не против ли он, если тестирование будет записываться на видео. А также просят хранить детали тестирования в тайне, если это важно для заказчика.
Опыт заказа пиццы и роллов: Любите ли вы пиццу и роллы? Где вы обычно их едите? Как часто? Вы заказывали когда-нибудь пиццу или роллы в сервисе доставки? С каких устройств вы это делали? Как часто вы заказываете пиццу и роллы? В каких ситуациях?
Сформулируем первую задачу сценария
Представьте, что к вам скоро придут ваши друзья. У вас будет компания из 4 человек. Закажите на компанию пиццу и напитки через этот сервис.
Зададим вопросы после выполнения задания
Далее замеряем метрики, после задания
Подробнее мы рассмотрим метрики далее, а в данном случае замерим следующие:
Кроме представленных в примере метрик, можно замерять и другие. Подробнее о них мы расскажем дальше в статье.
После тестирования сервиса доставки пиццы у пользователя можно спросить:
Далее можно измерить несколько метрик, если есть необходимость и завершить тестирование, выразив пользователю благодарность за участие.
Когда применяется объективное время и как оно измеряется:
Когда применяется субъективное время и как оно измеряется:
Сложность. Это субъективная метрика, которая определяет, насколько было сложно или легко выполнять задание. Пример вопроса:
В зависимости от продукта и целей исследования вопросы можно задавать тем или иным образом.
Кроме перечисленных можно измерять другие, такие как: семантический дифференциал, количество ошибок, критичность ошибок и тп. Это обширная тема для обсуждения, мы постараемся рассказать о ней в отдельной статье.
Пример: сервис доставки пиццы
Для тестирования мобильной версии сайта сервиса доставки пиццы мы выбрали следующие метрики.
После завершения всех сессий тестирования модератор считает среднее значение для каждой метрики по всем респондентам и обращает внимание на те, которые вышли из диапазона.
После того, как сценарий написан и утвержден бизнес-заказчиком важно провести пилотное тестирование. У него есть несколько целей:
К “пилоту” желательно привлекать пользователя из целевой аудитории, тогда оно будет наиболее приближено к реальному тестированию. Если такой возможности нет, то можно тестировать коллегу или знакомого, который наиболее близок к целевой аудитории.
Иногда во время пилота выясняется, что нужно:
После пилотного тестирования и рекрутирования нужно составить график тестирований. Для комфорта пользователя и качественных результатов каждая сессия тестирования должна длится не более часа. Однако, на каждое тестирование нужно закладывать 1,5-2 часа, так как пользователь может опоздать к началу или сессия тестирования затянуться.
В случае очного тестирования заказчик может наблюдать процесс из соседней комнаты, если тестирование удаленное, то он подключается к zoom или skype, а также может посмотреть тестирование в записи.
Пример: юзабилити тестирование сервиса доставки пиццы
Юзабилити тестирование сервиса доставки пиццы было решено проводить на мобильном телефоне, так как мобильной версией сайта пользуется больше половины клиентов. Тестирование проводится удаленно на мобильном телефоне респондента.
Программа, через которую проводится тестирование должна уметь расшаривать экран и вести видеозапись. В качестве инструментов мы выбрали Skype и Zoom. Предпочтительно иметь в распоряжении две программы, так как одна может не работать на устройстве респондента.
При звонке пользователю рекрутер предупреждает, что тестирование будет удаленным, оно будет длиться около часа и для этого нужно приложение Zoom или Skype, установленное на телефон.
Модератор созванивается с пользователем и просит его расшарить экран телефона через приложение, а также включает запись.
Во время тестирования важно, чтобы модератор не подсказывал пользователю и не помогал выполнять задания. Модератор может отвечать на вопросы пользователя и помочь разобраться с продуктом только после окончания тестирования или в отдельных случаях после выполнения задания.
После завершения сессий юзабилити-тестирования специалист работает с данными, полученными на тестировании, и пишет отчет. Для этого он:
Пример: усредненные метрики после тестирования сервиса доставки пиццы (8 участников тестирования)
В этом тестировании измерялись:
Примеры цитат пользователей из тестирования:
“Я бы никогда здесь не стала заказывать пиццу. Вот как заказать сет? Я не понимаю. Тут просто название пиццы “Деревенская”. А что в нее входит? Не понятно. И главное не нажать никуда и не посмотреть. Честно говоря у меня нет времени искать ее в каталоге и смотреть состав. Я бы уже на другой сайт ушла”
“Ой, я нажала на сеты роллов и суши, а он мне тут игральные карты и туалетную бумагу предлагает. Вот умора. Я бы уже ушла с сайта, честное слово”
После анализа видеозаписей и метрик специалист пишет отчет о тестировании, который состоит обычно из следующих разделов:
Рассмотрим подробнее разделы отчета на примере тестирования сервиса заказа пиццы.
Пример: отчет о юзабилити-тестировании сервиса заказа пиццы
Сначала идет описание методологии тестирования. Здесь кратко описывается метод тестирования и процедура, а также используемые метрики.
Кратко описывается сценарий тестирования: вводные вопросы, на которые пользователь отвечал до начала тестирования, а также перечисляются задачи.
Далее отдельным слайдом идет описание участников тестирования без указания их персональных данных. Можно указывать только основные параметры, например: город проживания, возраст, опыт заказа пиццы и тп.
Затем слайд с общими выводами о юзабилити-тестировании сервиса. Здесь вкратце описываются наиболее критичные проблемы и приводится таблица с метриками.
Юзабилити-тестирование помогает найти проблемы в интерфейсе, “побывать в голове пользователя” и понять, как он работает с продуктом. Нужно иметь в виду, что по результатам исследования юзабилити-специалист не сможет перепроектировать интерфейс, он даст советы, как это сделать, а дальше нужно привлекать проектировщиков, дизайнеров и программистов.
К юзабилити-тестированию стоит относиться как диагнозу, который дает врач, а дальше начинать “лечение продукта” в соответствии с рекомендациями.
Юзабилити-тестирование процедура многоразовая. Его нужно повторять регулярно, особенно после таких важных этапов, как проектирование, редизайн и тп.
Для большего погружения в юзабилити-тестирования советую почитать книгу Стива Круга “Не заставляйте меня думать”, пройти курс по юзабилити на одном из порталов онлайн-обучения или обратиться в юзабилити-агентство, которое проведет тестирование за вас.
В случае, когда нет возможности провести юзабилити-тестирование (например, нет времени или не хватает бюджета), мы советуем заказать юзабилити-экспертизу интерфейса. Она поможет найти основные проблемы в продукте и получить рекомендации, как их устранить.