Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 5433 сообщений
Cообщения с меткой

тестирование - Самое интересное в блогах

Следующие 30  »
Alek_YelGor

Чиновники будут сдавать экзамен на профпригодность.

Пятница, 22 Сентября 2017 г. 14:18 (ссылка)


Государственные служащие пройдут тестирование во всех субъектах федерации. Свою компетентность придётся доказывать даже губернаторам.



Региональных чиновников будут направлять на экзамен по проектному управлению. Это новшество коснётся лишь тех, кто занимается реализацией приоритетных для правительства проектов. Об этом рассказали в департаменте проектной деятельности правительства России, сообщают "Известия".


 


Директор Центра проектного менеджмента РАНХИГС Олег Билев объяснил, что экзамен будет проходить в виде письменного или электронного очного тестирования. На сдачу экзамена будут давать один час.


 


Экзамен зачтут, если госслужащий ответит правильно в 65% случаев. Однако необходимое количество баллов будет зависеть от роли чиновника в проекте. Несдавшим грозит пересдача.


 


- Система требований охватывает персональные и управленческие компетенции, включая лидерство, принятие управленческих решений, командное взаимодействие, гибкость и готовность к изменениям, стратегическое мышление и персональную эффективность, - разъяснил Олег Билев.


 


Первыми на экзамен пойдут чиновники из Белгородской области. В департаменте сказали, что оценивать будут даже губернаторов. Со временем экзамены сдадут во всех 85 субъектах.


 


 


В прошлом году в правительстве России решили перейти на проектный метод работы. На данное время функционирует 34 проекта. К этой работе привлечены штатные сотрудники и специалисты институтов развития.

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

С чего начать молодым разработчикам мобильных игр из России [Часть 3]

Вторник, 19 Сентября 2017 г. 14:49 (ссылка)




EgorHMG


сегодня в 14:49

Разработка





С чего начать молодым разработчикам мобильных игр из России [Часть 3]










    Всем доброго!





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







    Ранние публикации можно прочитать тут:

    Часть 1

    Часть 2



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



    За этот месяц мы вывели уровень игры на играбельный уровень. Всего было протестировано более ста билдов. И вот самая жестокая правда, которую нам удалось узнать: далеко не всё на физических устройствах работает не так, как в среде разработки.

    С этим были связаны основные проблемы. Чтобы их нивелировать мы вывели несколько основных правил (многие из них освещались и не раз, возможно для кого-то они станут новостью):



    1) Коммит в репозитории делается после каждого плюс – минус значительного изменения;

    2) Тестирование на «живых» устройствах проводится не менее трех раз в день, чтобы в случае чего можно было безболезненно откатить изменения;

    3) Разработка ведется небольшими итерациями и продолжается только после полного теста небольшого кусочка;

    4) Оптимизация – наше всё;

    5) Билд для внешних тестировщиков не заливается раньше, чем выполнен внутренний полный тест и не убраны «жесткие баги»;

    6) Глобальное обновление ни в коем случае не должно выходить перед праздниками и выходными.

    7) Чем больше внешних тестировщиков – тем лучше;



    Пойдем по пунктам:



    Коммиты





    Думаю, ни для кого не новость, что без контроля версии вести разработку категорически противопоказано. Если разработка ведется более, чем одним человеком – это смертельно опасно. После каждого изменения, которое влияет на механику или алгоритм игры необходимо сделать коллаборацию между всеми разработчиками. Я думаю каждый, кто вел разработку в таких условиях сталкивался с ситуацией, когда все разом залили изменения, что-то перестало работать, а в чем причина – неясно. Еще хуже – если понятно, что причиной нерабочей версии стали плоды целого рабочего дня разработчика и нужно откатывать все изменения назад. Менее неприятно, если причиной стал конфликт работы и просто нужно немного переделать. Идеально, если все видят изменения в режиме реального времени и знают, что в случае чего – максимальный откат назад будет минут в 10-15.



    Физические устройства





    То, что мы видим в среде разработки, бывает далеко от того, что мы увидим на устройствах. Если с ПК версией у всех всё плюс-минус одинаково, то с мобильными устройствами всё обстоит несколько иначе.

    Некоторые пункты нужно будет калибровать «на глаз», некоторые оптимизировать и даже делать даунгрейд (этого тоже бояться не нужно).



    Короткие задачи





    Задачи, которые связаны с добавлением нового функционала или контента должны быть максимально короткими. Например:



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



    Если вам хватило упорства на одном дыхании за пол дня что-то сконструировать, а потом вы увидели, что всё ок (в лучшем случае), но плохо работает только небольшая деталь, вы имеете большие шансы переделывать из-за мелкой недоработки очень большой и вполне работоспособный кусок уровня.



    Это можно отнести ко всему: интерфейс, туториал, магазины, скрипты, баланс, физика и т.д.

    Не ленитесь, это сэкономит вам кучу времени и сил.



    Оптимизация





    Я думаю, что объяснять зачем её делать не нужно. От себя хочу сказать, что оптимизировать всё и сразу тоже неправильно. В данном случае работает правило 20/80, когда 20% усилий приносят 80% пользы. Подходите к вопросу с умом.



    Внутреннее тестирование и выходные



    Нельзя отправлять непроверенный билд внешним тестировщикам. Это люди, зачастую, тестируют ваш продукт из любопытства. Порой случается так, что в билде отваливается очень важная мелочь.



    Кейс из жизни:



    После фикса UI мы не заменили скрипт на кнопке запуска уровня.



    Стандартная череда неправильных поступков (отмазка): Время было позднее, много чего было поправлено и добавлено, впереди выходные, да и вечер пятницы сказался на внимательности. В общем, как это всегда и происходит – кто-то не доделал, кто-то не проверил, имеем что имеем.



    Факт: Никто не смог увидеть нововведений так как билд оказался неиграбельным, запустить прохождение невозможно.



    Наша аудитория, подписавшаяся на закрытую альфу, скачала обновление и увидела нерабочую версию. Казалось бы, люди, которые тестируют альфу должны быть к этому готовы и ждать фиксов. Возможно так и было, но его мы смогли выпустит только в понедельник вечером и все выходные и понедельник в маркете была именно кривая версия. За это время игру удалило 20% аудитории так и не дождавшись обновления.



    В случае, когда у тебя аудитория в 100 человек, ты просто расстраиваешься и пытаешься восполнить потерю и это более чем реально. Если ты уже находишься в open access, то эти цифры могут исчисляться тысячами и вернуть такое количество тестеров назад будет сложно.



    Аудитория





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



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



    P.S.





    Сейчас у нас готов играбельный билд, в котором мы постарались передать суть, основные механики и атмосферу игры.

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

    Также активно работаем над левел дизайном, чтобы разнообразить геймплей и сделать его более динамичным. 

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



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



    В общем, кто решится на установку нашего творения — энжой и большая благодарность.



    Будем рады любому фидбеку.



    Ссылка на обновляемый билд бета тестирования в Google play 



    Всем спасибо!



    Продолжение следует.


    Original source: habrahabr.ru (comments, light).

    https://habrahabr.ru/post/338242/

    Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
    rss_rss_hh_new

    Управление фермой Android-устройств. Лекция в Яндексе

    Воскресенье, 17 Сентября 2017 г. 13:43 (ссылка)




    Leono


    сегодня в 13:43

    Разработка





    Управление фермой Android-устройств. Лекция в Яндексе










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



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







      — Меня зовут Новиков Павел, я работаю в компании «Новые облачные технологии». Мы работаем над продуктом «Мой офис», делаем Android-версию этого офисного комплекта. Само приложение очень большое. Начну с того, что расскажу, как все устроено в плане архитектуры, чтобы после этого перейти к причине, по которой ферма понадобилась. Вы сможете понять, есть у вас события, когда много кода и внешних зависимостей, или же таких событий нет и нужно ли оно вам. Сможете точнее принять решение о том, что ферма — это классно и нужно. Или нет.



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



      В центре приложения «Мой Офис Документы» стоит нативное ядро, CORE, которое делается внутри нашей компании, но делается целой командой. Оно написано на чистом С++, чтобы его потом можно было переиспользовать. Переиспользуется оно всеми командами, которые работают над линейкой наших продуктов.



      Это десктоп, веб, Android, iOS. Даже Tizen есть, его полноценно и весьма успешно делают.



      Самое важное — это что ребята, которые делают CORE, очень тесно завязаны на всех, кто использует этот CORE. Часто происходят ситуации, когда мы просим функционал, который был бы полезен, например, на мобильных клиентах, на iOS, на Android, но на десктопе он не так полезен. Есть такие вещи.



      Из этого весьма предсказуемо следует, что иногда появляются баги — вследствие того, что десктоп попросил эту функцию и она внутри себя немного изменила поведение другой функции, которую используют на Android. Это вполне обычная ситуация, и наша задача — побыстрее такие места найти, чтобы помочь ребятам, поработать вместе и побыстрее исправить баги, например, на всех мобильных платформах.







      Есть три компонента: нативный CORE, Android-библиотека, в которую этот CORE обернут, и наше Java-приложение. Нативный CORE — чистый С++. Дальше в виде source-кодов он идет в Android-модуль, где сделаны все биндинги для натива, добавлены небольшие прослойки, какая-то логика. Плюс вся отрисовка, которую использует SKI, тоже сделана в этом модуле. Затем модуль как стандартная AR-библиотека вставляется в наше приложение, мы ее используем.



      Всякое происходит — могут появляться баги в нативе, в CORE, в биндингах. Тот же unsatisfying link exception, когда неправильно забиндили Java-класс на нативный класс и получили ситуацию, при которой приложение падает во время обращения к нативному методу. И баги у нас в Java-коде.



      Самое важное: нам желательно как можно скорее понять, где проблема, чтобы проще было ее решить. Баги, которые вызваны в биндингах, хорошо бы отловить сразу, чтобы они не дошли до UI, ручного тестирования. Это время и довольно простые ошибки, которые несложно найти и исправить.



      Чтобы это делать, нужны тесты — самое лучшее, что может быть в данной ситуации. Наша задача — делать код, работающее приложение. Самый простой способ увидеть, что оно работает, — написать для него тесты. Тесты бывают абсолютно разные. Мы пишем все: unit, UI, интеграционные тесты.



      Помимо того, что тесты есть, нужно, чтобы они еще запускались. Тесты, которые вы написали, когда разрабатывали приложение, а потом забыли про них и не запускаете, — они лежат, толку от них никакого, а после этого еще код меняется. Прошло два месяца, и мы решили эти тесты запустить, а они даже не собрались. Это неправильно, тесты должны работать постоянно.



      Тесты должны регулярно запускаться на CI. Иначе они бессмысленны. Если у вас есть тесты, которые лежат, то у вас нет тестов.







      С unit-тестами все довольно просто. Запускаем grlu-тест, таску. Она запускается на CI — все хорошо, прогоняются unit-тесты в вашем приложении, вы видите репорты, отчеты.



      Android-тесты запускаются как тесты connect Android, там нужны те же unit-тесты, только они гоняются на девайсах. И тут возникает проблема: UI и интеграционные тесты должны запускаться на реальных устройствах. А CI — не реальное устройство. Можно эту проблему решить несколькими способами.



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



      Можно запускать эмулятор на CI. Это довольно рабочий вариант, тот же Jenkins поддерживает плагин, который позволяет запускать эмулятор, но проблема в том, что эмулятор — это, скорее всего, 86-й эмулятор. А если мы говорим про интеграционные тесты, под интеграцией я в нашем случае подразумеваю внешние зависимости, в частности — именно нативный код, потому что у нас очень много нативного кода. И под интеграционными тестами я понимаю тесты, которые проверяют логику «плюсов».



      Как итог — сделать это возможно, но не очень удобно. Вариант с подключением устройств напрямую не очень удобный, а эмулятор нам не поможет. Можно использовать древний «армовский», но это так себе идея.



      Тут на сцену выходит проект Open STF.



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



      Выглядит это примерно так. Картинка взята из самого проекта. Список устройств доступен, мы можем подключиться к каждому и работать с ним полноценно. То, что вы видите, — живое устройство, которое подключено к ферме и которым можно полностью управлять через веб-интерфейс, полноценно работать.



      Проект Open STF — опенсорсный, и у него есть несколько преимуществ. В первую очередь — работа с реальными устройствами. Как большинство Android-разработчиков, вы понимаете, что ваш код должен проверяться на устройствах. Эмулятор — это хорошо, но есть много вещей, которые нужно проверять на реальных устройствах: тот же натив, работа с SSL. Там много вещей, поведение которых может отличаться. Ферма эту проблему решает.







      Что приятно, для работы с этой фермой вам не нужен root на девайсах. Вы просто подключаете девайс к ферме, и он доступен для работы.



      Это удобный дебаг. Вам ничто не мешает подключиться по DB к устройству, видимому в сети по простому IP, работать с ним как с устройством, которое будто бы подключено к вашему рабочему компьютеру. Экран устройства вы всегда видите, можете с ним взаимодействовать — только не пальцем, а мышкой.



      Устройством могут пользоваться несколько команд. В нашем случае это интересный кейс. У нас обширный парк девайсов в компании и несколько команд, которые с ними работают. Мы — разработчики, тестировщики, все сидим рядом, и девайсы нам нужны для работы. Вторая команда — автоматизаторы, они сидят на другом этаже, но пишут автоматизированные тесты со своим стеком технологий для всех, в том числе для Android. Они тоже имеют доступ ко всем устройствам в компании. Третья — служба поддержки. Им тоже нужно как можно больше устройств. Когда пишут про проблемы в продукте, им нужно их воспроизводить. Проблемы могут быть разные. Преимущество в том, что они имеют доступ ко всем устройствам компании. Это плюс, на устройствах можно запускать приложения и быстрее оказывать поддержку.



      Удобно работать удаленно. Приятное следствие, QA так делают: если кто-то приболел или не может выйти в офис, это не значит, что они не смогут работать. Они заходят на ферму и работают как обычно, как если бы девайс лежал рядом с ними.



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



      Есть Rest API, можно подумать про автоматизацию.



      Все девайсы в порядке, в одном месте, всегда заряжены. Бывает, что нужно на одном устройстве что-то воспроизвести, а оно валяется фиг пойми где, разряжено… Приятный бонус.







      Как и у любого проекта, есть недостатки. Не все устройства поддерживаются. Не смогу назвать точных правил. Бывает, подключаете устройство к ферме и оно не определяется. Такое бывает очень редко, у нас был буквально один или два девайса. 95% всего парка работает отлично. Бывает исключение с какими-то китайцами — не определяется и все. Один девайс на 86-м процессоре, фиг знает почему.



      Не очень удобно обновлять. К вопросу об обновлении самого продукта STF: поскольку это open source, обновлением в нашей компании занимается команда девопсов. Это не просто нажать кнопку и обновить. Но нет ничего невозможного. Поскольку речь идет про open source, можно облегчить процесс, проблема не критическая.



      Выпускать за пределы внутренней сети нежелательно. У нас эта ферма крутится внутри сети, и желательно в интернет ей не светить, потому что ферма позволяет получать, по сути, полный доступ над девайсом, там нет ограничений, вы просто работаете с устройством — можете удалить все что угодно, добавить все что угодно. Если что-то можно сделать с реальным устройством у вас в руке — это можете сделать и с фермой. Так что лучше оставлять его для внутреннего пользования.







      Как это выглядит? Внешне есть сервер, где запущена сама ферма, веб-панель, к которой есть доступ.



      Эта веб-панель знает о нодах. Каждая нода — компьютер, к которому подключен девайс. Нод может быть несколько — к вопросу о масштабировании. Сами устройства подключаются не туда, где запущена веб-версия, а к нодам. В нашем случае это выглядит так, что две ноды стоят у нас в команде и еще одна — у саппорта, просто потому что им ближе. Физически не все устройства расположены в одном месте, но все доступны через единый интерфейс, который выглядит вот так.







      Ко всем устройствам написано, что это за продукт, какая версия ОС, SDK level, какие архитектуры у этого устройства. И его location — провайдер, о котором я говорил. Тут два провайдера. Это наши устройства и устройства саппорта. Последние мы стараемся не трогать, это их устройства, доступные через единый интерфейс.



      Сама ферма расположена на GitHub. Первая ссылка — больше рекламная штука.







      Там есть все инструкции, как его поднять, запустить, работать с ним. Описаны все плюсы и минусы, проект довольно хорошо документирован.



      Проблема была в том, что нужно было как-то подружить эти две вещи. Есть тесты и ферма.







      CI-сервер — это любой сервис, который вам больше нравится. Мы используем Jenkins, у меня примеры с интерфейсом про Jenkins, но вы ни к чему не привязаны.



      У вас есть STF сервер — сам сервер, провайдер, устройства.



      Как их объединять? Очевидно, самый простой способ — Gradle-плагин, который позволяет настроить подключение к ферме при запуске тестов.



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



      Что такое нужное устройство? Через плагин вы можете гибко настроить то, какие именно устройства вам нужны. Вы можете отфильтровать их по названию, взять одни Nexus или Samsung, выбрать количество, которое вы хотите отфильтровать. Это может быть один небольшой набор тестов — вы говорите, что хочу на двух девайсах прогнать и убедиться, что ничего не отломалось. Или nightly-прогон сделать, который все девайсы возьмет, проверит, все запустит, все будет отображаться.



      Архитектура. Бывает, нужно запускать тесты на определенной архитектуре. Случаи бывают, но это нужно нечасто.



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



      Еще полезно сортировать по API-уровню. Если вы хотите зачем-нибудь запустить тест на API 21 и выше — это можно.







      Подключается это довольно просто. Как любой Grandle плагин, он интегрируется через подобный синтаксис. Пишете apply plugin, он появится в доступном.







      Сейчас сделан следующий шаг. При запуске нужно привязаться к таске запуска тестов, которая будет запускаться на CI, чтобы плагин работал. Сейчас сделано таким образом. Может, и неудобно, но как есть. Улучшить — не проблема. Главное, что можно привязаться к таске connectToSmartphoneTestFarm. Это основная таска, отвечающая за то, чтобы подключиться к девайсам и отпустить девайсы.







      Ну и третье — настройка параметров фермы. baseUrl — путь, где ферма расположена. apiKey — ключ, чтобы подключаться по REST, это настраивается в консоли фермы. adbPath — чтобы выполнялась операция adbConnect ко всем устройствам, которые будут найдены. Timeout — системная настройка, по дефолту стоит минута. Она нужна, чтобы ферма сама отпускала девайсы, если они по каким-то причинам не используются.







      Так выглядит запуск тестов с использованием фермы. Мы говорим, что connectedDebugAndroidTest запустит все ваши тесты, и сюда передан параметр о том, чтобы не использовать саппорт. Тильда — в данном случае отрицание. Дальше сказать, что я хочу пять устройств, и чтобы они все были –DK21, то есть Lollypop и выше.







      Вот как это выглядит при настройке job внутри Jenkins. Тут эти параметры настраиваются и передаются. Это не часть плагина, job на Jenkins нужно сделать самому. Вы можете не указывать все эти параметры, а сделать одну job, в которой они будут заданы железно. И просто кнопка build, если вам не хочется заморачиваться. Может, мы сделаем так же в дальнейшем.







      Как итог — после прогона всех тестов вы видите самый стандартный HTML-репорт запуска GUnit, только с одним аспектом: вы будете видеть, что они запускались на разных устройствах. Вы будете видеть названия всех тестов, что вы пробежали, и поймете, что они запустились на каждом устройстве. Вы даже увидите, сколько они запускаются по времени, чтобы из этого в дальнейшем строить анализ, чтобы искать какую-то регрессию. Тут полет для фантазии — можно продумать тест, который один и тот же код запустит сто раз и померяет это. И вы увидите, как код на 86-м или на ARM работает: быстрее или медленнее. Ферма в этом поможет, чтобы можно было не руками подключать, а в автоматическом режиме.







      Сам плагин тоже доступен на GitHub, там простенькая документация, но хоть какая. Подключается просто. Весь фидбек приветствуется. Плагин мы написали для себя. Это единственная причина, почему мы не могли нормально ферму использовать. Наконец смогли, порадуемся этому.



      Стоит упомянуть, что Gradle есть не везде по объективным причинам. Например, это может быть Appium. Я упоминал ранее, что у нас есть команда автоматизаторов, которые пишут свои тесты на технологии Appium. Там и не пахло Gradle, но им тоже надо использовать ферму.



      Это может быть терминал. Есть ферма, на девайсе произошел какой-то краш, и хорошо бы получить log cut с него, скачать файл, что угодно. Что делать? Либо взять девайс и подключить к себе — но тогда теряется вся магия фермы, — либо использовать какой-то дополнительный клиент.







      Разработали тулзу простую, которая делает все то же самое, но работает через терминал. Вы так же можете подключаться к устройствам, отключаться, выводить их в список, подключаться, чтобы они были доступны в adb, и эта команда говорит: нужны пять Nexus, когда их найдешь — подключись ко всем. После выполнения команды у вас будут в adb доступны пять устройств. Можете что хотите делать из терминала, тоже удобно. Главное преимущество — это быстрее, нежели делать руками. И тоже доступно на GitHub.



      Чисто технически Gradle-плагин и клиент используют нашу библиотеку STL client вместе. Весь сервер написан на Java, есть дальнейшие планы дописать плагин для студии, чтобы девайсы можно было выбирать прямо из UI студии, когда вы работаете. По собственным ощущениям, последние полгода я устройства руками не трогал. Устройства лежат на ферме, я к ним подключаюсь через веб-интерфейс, подключаюсь к adb, копирую путь на ферме и руками девайс не трогаю — лениво. Просто подключился к другому устройству — работаешь с другим.



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







      Немного в сторону, но тоже про тесты. Я в основном ферму использую в контексте тестирования. UI-тесты — не интеграционные тесты. Кому-то это может показаться капитанством, но отсюда следуют выводы, что UI-тесты могут зависеть от устройств. Я говорю про экспресс-тесты, которые должны запускаться только на смартфонах, которые тестируют экран на смартфоне. На планшете он не имеет смысла, и наоборот. Есть специфичные тесты для планшета, для таблеток. На смартфоне они либо не должны запускаться, либо должны запускаться в каком-то видоизмененном месте. Если вы запустите, вы получите зафейленный тест, и на выходе будет ложноотрицательное срабатывание, что будет мешать. По идее, тесты должны либо проходить, и все хорошо, либо не проходить по объективным причинам. А если они выглядят так, будто прошли, но прошли по необъективным причинам, — это мешает процессу, теряется информативность.



      Задача — разделять их. Это то, с чем мы столкнулись, когда начали интегрировать весь процесс работы с фермой и всю описанную автоматизацию. У нас есть как интеграционный тест, так и UI-тесты.



      Есть несколько способов. Самые простые известны. И все рабочие, кому как удобнее.



      Можно написать свой test runner, который будет анализировать, например, названия классов. Рабочий вариант вполне. Договаривайтесь, что вы именуете классы, которые заканчиваются на TestIntegration или TestUI. Вполне рабочий вариант — test runner это разруливает.



      Можно немного пошаманить с Gradle. Складывать тесты в отдельные папки, настроить в Gradle, чтобы он эти папки видел как папки с кодом. На Stack Overflow есть хорошее описание, но я не пробовал.



      Можно использовать вариант с JUnit Suit — классом, который позволяет компоновать тесты. Мы остановились на этом варианте, только потому что он самый простой. У него есть недостатки, но с ним проще всего стартануть — не нужно с Gradle шаманить и писать test runner и переименовывать классы, которые у нас есть.



      Выглядит следующим образом. Просто обновляете класс — в нашем случае это IntegrationSuite — и перечисляете классы, которые должны запускаться. Сразу минус: их нужно явно указывать.







      Когда вы запускаете таску для теста, надо указать отдельным параметром, что я хочу запускать именно данный suite, чтобы запустился только он. Технически так любой тест можно передать, это удобно. Обычно все тесты запустили, они все прошли. В данном случае их можно фильтровать, если вы не используете синтаксис adb instrumentation frame. Все то, что вы видите в студии, когда нажимаете «запустить тесты». Еще это можно шаблонами делать. В данном случае это нужно указать. Тогда будет запускаться только один набор тестов, и он будет выполнять ту изначальную задачу, которую вы перед ним поставили.



      При работе Jenkins запустит набор тестов, и мы сможем узнать, сломалась у нас интеграция или нет. Например, пришла новая версия библиотеки от команды CORE. Команда, которая отвечает за то, чтобы интегрировать ее в наши биндинги, их пишет и выкатывает новую версию их библиотеки, которая в формате AR. И нам нужно как можно более простым способом убедиться, что ничего хотя бы не отломалось. Это уже приятно.



      Раньше то, что отломалось, падало вообще сходу, но если какой-то метод плохо забиндился или значение какого-то параметра поменялось, то мы узнавали только в самом конце цикла, когда проводилось ручное тестирование — например, в restore. И тут приходят тестировщики и говорят, что раньше работало одним образом, а сейчас немного по-другому — почему? А мы не знаем. Начинаем разбираться. Сначала виним одних ребят, потом других.



      В данном случае это делается гораздо быстрее, автоматически. Все артефакты собрались, на Jenkins запустился весь набор тестов. Он подключается к каждому устройству на ферме, и все — мы знаем, что, по крайней мере, все работает как раньше.



      Что можно подытожить? Первое — ферма удобна, когда есть несколько команд. Надо сразу понять, что если вы — один разработчик или работаете над продуктом вдвоем, то вам можно особо не запариваться на эту тему. Если у вас нет внешних зависимостей, если вы делаете простенькое приложение, может, оно вам и не нужно. Разбираться с этим, настраивать… Если вы делаете маленький продукт — скорее всего, у вас нет отдельной команды, ответственной за поддержание инфраструктуры, девопсов. Разруливать самостоятельно тоже можно, но удобнее, когда кто-то делает это за вас.



      Если у вас такого нет, может, оно вам и не надо. Вы живете, все с вами хорошо.



      Другое дело, если у вас появляются внешние зависимости — например, нативный код, причем тот, который постоянно меняется, развивается и дописывается, или у вас идет работа с какими-нибудь секьюрными вещами типа SSL, свои сертификаты, все такое, UI не проверить. Технически можно запустить тесты GUnity на CI или на машине, но в идеале хотелось бы, чтобы такие вещи гонялись на устройствах.



      Тесты полезны. Лютое капитанство: чтобы тесты приносили вам пользу, они должны запускаться и работать с наименьшей болью, чтобы не нужно было руками после какого-то действия брать устройство и подключать руками. Желательно, чтобы оно работало, в идеале само, чтобы можно по job запускать. Либо пусть оно хотя бы работает по нажатию одной кнопки «Проверить». Цель в этом.



      Все. Это доступно на GitHub, сама ферма с описаниями — как поднять, как настроить, что поддерживается. Плагины доступны, клиенты-плагины.



      Этим продуктом пользуемся не только мы — ребята из 2ГИС активно его используют, написали несколько интересных утилит на Python, что тоже позволяет по REST подключаться и выбирать устройство. Мы эту тулзу раньше использовали, но там все не так хорошо.



      Интересная фича, которая легко реализуема. Есть тулза, которая позволяет записывать видео с экрана. Поскольку весь экран гоняется по веб-сокетам, вам ничто не мешает по REST получить веб-сокет, узнать, куда подключиться, и получать все ивенты экрана, работать с ними. Мы для себя это не сделали, в отличие от ребят.


      Original source: habrahabr.ru (comments, light).

      https://habrahabr.ru/post/338038/

      Комментарии (0)КомментироватьВ цитатник или сообщество
      rss_rss_hh_new

      [Перевод] Моки и явные контракты

      Суббота, 16 Сентября 2017 г. 19:08 (ссылка)




      Telichkin


      сегодня в 19:08

      Разработка





      Моки и явные контракты







      • Перевод




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



      Ниже представлен вольный перевод статьи, в которой Jos'e Valim — создатель языка Elixir — высказал своё мнение на проблему использования моков, с которым я полностью согласен.






      Несколько дней назад я поделился своими мыслями по поводу моков в Twitter:





      Мок — полезный инструмент в тестировании, но имеющиеся тестовые библиотеки и фреймворки зачастую приводят к злоупотреблению этим инструментом. Ниже мы рассмотрим лучший способ использования моков.



      Что такое мок?



      Воспользуемся определением из англоязычной википедии: мок — настраиваемый объект, который имитирует поведение реального объекта. Я сделаю акцент на этом позже, но для меня мок — это всегда существительное, а не глагол [для наглядности, глагол mock везде будет переводиться как "замокать" — прим. перев.].



      На примере внешнего API



      Давайте рассмотрим стандартный пример из реальной жизни: внешнее API.



      Представьте, что вы хотите использовать Twitter API в веб-приложении на фреймворке Phoenix или Rails. В приложение приходит запрос, который перенаправляется в контроллер, который, в свою очередь, делает запрос к внешнему API. Вызов внешнего API происходит прямо в контроллере:



      defmodule MyApp.MyController do
      def show(conn, %{"username" => username}) do
      # ...
      MyApp.TwitterClient.get_username(username)
      # ...
      end
      end


      Стандартным подходом при тестирования такого кода будет замокать (опасно! замокать в данном случае является глаголом!) HTTPClient, которым пользуется MyApp.TwitterClien:



      mock(HTTPClient, :get, to_return: %{..., "username" => "josevalim", ...})


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



      Не так быстро. Основная проблема при моке HTTPClient заключается в создании сильной внешней зависимости [англ. coupling везде переведена как "зависимость" — прим. перев.] к конкретному HTTPClient. Например, если вы решите использовать новый более быстрый HTTP-клиент, не изменяя поведение приложения, большая часть ваших интеграционных тестов упадет, потому что все они зависят от конкретного замоканного HTTPClient. Другими словами, изменение реализации без изменения поведения системы все равно приводит к падению тестов. Это плохой знак.



      Кроме того, так как мок, показанный выше, изменяет модуль глобально, вы больше не сможете запустить эти тесты в Elixir параллельно.



      Решение



      Вместо того, чтобы мокать HTTPClient, мы можем заменить MyApp.TwitterClient чем-нибудь другим во время тестов. Давайте посмотрим, как решение может выглядеть на Elixir.



      В Elixir все приложения имеют конфигурационные файлы и механизм для их чтения. Используем этот механизм, чтобы настроить клиент Twitter'a для различных окружений. Код контроллера теперь будет выглядеть следующим образом:



      defmodule MyApp.MyController do
      @twitter_api Application.get_env(:my_app, :twitter_api)

      def show(conn, %{"username" => username}) do
      # ...
      @twitter_api.get_username(username)
      # ...
      end
      end


      Соответствующие настройки для различных окружений:



      # config/dev.exs
      config :my_app, :twitter_api, MyApp.Twitter.Sandbox

      # config/test.exs
      config :my_app, :twitter_api, MyApp.Twitter.InMemory

      # config/prod.exs
      config :my_app, :twitter_api, MyApp.Twitter.HTTPClient


      Сейчас мы можем выбрать лучшую стратегию получения данных из Twitter для каждого из окружений. Sandbox может быть полезен, если Twitter предоставляет какой-нибудь sandbox для разработки. Наша замоканная версия HTTPClient позволяла избежать реальных HTTP-запросов. Реализация этой же функциональности в данном случае:



      defmodule MyApp.Twitter.InMemory do
      def get_username("josevalim") do
      %MyApp.Twitter.User{
      username: "josevalim"
      }
      end
      end


      Код получился простым и чистым, а сильной внешней зависимости от HTTPClient больше нет. MyApp.Twitter.InMemory является моком, то есть существительным, и для его создания вам не нужны никакие библиотеки!



      Необходимость явных контрактов



      Мок предназначен для замены реального объекта, а значит будет эффективен только в том случае, когда поведение реального объекта определено явно. Иначе, вы можете оказаться в ситуации, когда мок начнет становиться все сложнее, увеличивая зависимость между тестируемыми компонентами. Без явного контракта заметить это будет сложно.



      Мы уже имеем три реализации Twitter API и лучше сделать их контракты явными. В Elixir описать явный контракт можно с помощью behaviour:



      defmodule MyApp.Twitter do
      @doc "..."
      @callback get_username(username :: String.t) :: %MyApp.Twitter.User{}

      @doc "..."
      @callback followers_for(username :: String.t) :: [%MyApp.Twitter.User{}]
      end


      Теперь добавьте @behaviour MyApp.Twitter в каждый модуль, который реализует этот контракт, и Elixir поможет вам создать ожидаемый API.



      В Elixir мы полагаемся на такие behaviours постоянно: когда используем Plug, когда работаем с базой данных в Ecto, когда тестируем Phoenix channels и так далее.



      Тестирование границ



      Сначала, когда явные контракты отсутствовали, границы приложения выглядели так:



      [MyApp] -> [HTTPClient] -> [Twitter API]



      Поэтому изменение HTTPClient могло приводить к падению интеграционных тестов. Сейчас приложение зависит от контракта и только одна реализация этого контракта работает с HTTP:



      [MyApp] -> [MyApp.Twitter (contract)]



      [MyApp.Twitter.HTTP (contract impl)] -> [HTTPClient] -> [Twitter API]



      Тесты такого приложения изолированы от HTTPClient и от Twitter API. Но как нам протестировать MyApp.Twitter.HTTP?



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



      Лично я бы протестировал MyApp.Twitter.HTTP на реальном Twitter API, запуская эти тесты по-необходимости во время разработки и каждый раз при сборке проекта. Система тегов в ExUnit — библиотеке для тестирования в Elixir — реализует такое поведение:



      defmodule MyApp.Twitter.HTTPTest do
      use ExUnit.Case, async: true

      # Эти тесты будут работать с Twitter API
      @moduletag :twitter_api

      # ...
      end


      Исключим тесты с Twitter API:



      ExUnit.configure exclude: [:twitter_api]


      При необходимости включим их в общий тестовый прогон:



      mix test --include twitter_api



      Также можно запустить их отдельно:



      mix test --only twitter_api



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




      1. Изменение в HTTPClient приводит только к падению тестов на MyApp.Twitter.HTTP

      2. Вы не мокаете (осторожно! мок в данном случае является глаголом!) HTTPClient. Вместо этого, вы передаете его как зависимость через файл конфигурации, подобно тому, как мы делали для Twitter API

      3. Вам все еще нужен способ протестировать работу вашего клиента до выкатки в production.



      Вместо создания мока HTTPClient можно поднять dummy-сервер, который будет эмулировать Twitter API. bypass — один из проектов, который может в этом помочь. Все возможные варианты вы должны обсудить со своей командой.



      Примечания



      Я бы хотел закончить эту статью разбором нескольких общих проблем, которые всплывают практически в каждом обсуждении моков.



      Создание "тестируемого" кода



      Цитата из elixir-talk mailing list:



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

      Я бы сказал, что речь идет не о создании "тестируемого" кода, а об улучшении дизайна [от англ. design of your code — прим. перев.].



      Тест — это пользователь вашего API, как и любой другой код, который вы пишите. Одна из идей TDD заключается в том, что тесты — это код и ничем не отличаются от кода. Если вы говорите: "Я не хочу делать мой код тестируемым", это означает "Я не хочу уменьшать зависимость между компонентами" или "Я не хочу думать о контракте (интерфейсе) этих компонентов".



      Нет ничего плохого в нежелании уменьшать зависимость между компонентами. Например, если речь идет о модуле работы с URI [имеется ввиду модуль URI для Elixir — прим. перев.]. Но если мы говорим о чем-то таком же сложном, как внешнее API, определение явного контракта и наличие возможности заменять реализацию этого контракта сделает ваш код удобным и простым в сопровождении.



      Кроме того, оверхэд минимален, так как конфигурация Elixir-приложения хранится в ETS, а значит вычитывается прямо из памяти.



      Локальные моки



      Хотя мы и использовали конфигурацию приложения для решения проблемы с внешним API, иногда проще передать зависимость как аргумент. Например, некоторая функция выполняет долгие вычисления, которые вы хотите изолировать в тестах:



      defmodule MyModule do
      def my_function do
      # ...
      SomeDependency.heavy_work(arg1, arg2)
      # ...
      end
      end


      Можно избавиться от зависимости, передав её как аргумент. В данном случае будет достаточно передачи анонимной функции:



      defmodule MyModule do
      def my_function(heavy_work \\ &SomeDependency.heavy_work/2) do
      # ...
      heavy_work.(arg1, arg2)
      # ...
      end
      end


      Тест будет выглядеть следующим образом:



      test "my function performs heavy work" do
      # Симулируем долгое вычисление с помощью отправки сообщения тесту
      heavy_work = fn(_, _) ->
      send(self(), :heavy_work)
      end

      MyModule.my_function(heavy_work)

      assert_received :heavy_work
      end


      Или, как было описано ранее, можно определить контракт и передать модуль целиком:



      defmodule MyModule do
      def my_function(dependency \\ SomeDependency)
      # ...
      dependency.heavy_work(arg1, arg2)
      # ...
      end
      end


      Изменим тест:



      test "my function performs heavy work" do
      # Симулируем долгое вычисление с помощью отправки сообщения тесту
      defmodule TestDependency do
      def heavy_work(_arg1, _arg2) do
      send self(), :heavy_work
      end
      end

      MyModule.my_function(TestDependency)

      assert_received :heavy_work
      end


      Вы также можете представить зависимость в виде data structure и определить контракт с помощью protocol.



      Передать зависимость как аргумент намного проще, поэтому, если возможно, такой способ должен быть предпочтительнее использования конфигурационного файла и Application.get_env/3.



      Мок — это существительное



      Лучше думать о моках как о существительных. Вместо того, чтобы мокать API (мокать — глагол), нужно создать мок (мок — существительное), который реализует необходимый API.



      Большинство проблем от использования моков возникают, когда они используются как глаголы. Если вы мокаете что-то, вы изменяете уже существующие объекты, и зачастую эти изменения являются глобальными. Например, когда мы мокаем модуль SomeDependency, он изменится глобально:



      mock(SomeDependency, :heavy_work, to_return: true)


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



      Библиотеки для создания моков



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



      Все зависит от ситуации. Если библиотека подталкивает вас на подмену глобальных объектов (или на использование моков в качестве глаголов), изменение статических методов в объектно-ориентированном или замену модулей в функциональном программировании, то есть на нарушение описанных выше правил создания моков, то вам лучше отказаться от неё.



      Однако, есть библиотеки для создания моков, которые не подталкивают вас на использование описанных выше анти-паттернов. Такие библиотеки предоставляют "мок-объекты" или "мок-модули", которые передаются в тестируемую систему в качестве аргумента и собирают информацию о количестве вызовов мока и о том, с какими аргументами он был вызван.



      Заключение



      Одна из задач тестирования системы — нахождение правильных контрактов и границ между компонентами. Использование моков только в случае наличия явного контракта позволит вам:




      1. Защититься от засилья моков, так как контракты будут создаваться только для необходимых частей системы. Как было упомянуто выше, вряд ли вы захотите прятать взаимодействие со стандартными модулями URI и Enum за контрактом.

      2. Упростить поддержку компонентов. При добавлении новой функциональности к зависимости, вам нужно обновить контракт (добавить новый @callback в Elixir). Бесконечный рост @callback укажет на зависимость, которая берет на себя слишком много ответственности, и вы сможете раньше расправиться с проблемой.

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



      Явные контракты позволяют увидеть сложность зависимостей в вашем приложении. Сложность присутствует в каждом приложении, поэтому всегда старайтесь делать её настолько явной, насколько это возможно.



      Original source: habrahabr.ru (comments, light).

      https://habrahabr.ru/post/338066/

      Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
      rss_rss_hh_new

      Обзор инструментария для нагрузочного и перформанс-тестирования

      Четверг, 14 Сентября 2017 г. 13:56 (ссылка)






      ValeriaKhokha


      сегодня в 13:56

      Разработка





      Обзор инструментария для нагрузочного и перформанс-тестирования










        Как говорят иные отважные люди: «От dev до prod — всего один шаг». Люди опытные добавляют, что шаг этот называется «тестирование», причём самое разнообразное, и нам просто нет смысла им не верить.







        Нагрузка имеет значение: водитель этого грузовика умудрился обрушить мост весом своего ТС, счёт за восстановление составил примерно 16m. К счастью, тестирование ПО обходится дешевле!



        Конечно, говоря о тестировании, нужно понять, с чем и за что мы боремся. Мы сознательно ограничили себя и решили сегодня поговорить исключительно про нагрузочное тестирование и тестирование производительности: темы, полярно удалённые друг от друга, крайне интересны в самом практическом выражении. Рассмотрим инструменты для того и другого, не привязываясь к какому-то конкретному стеку технологий, так что не удивляйтесь соседству Яндекс.Танк и BenchmarkDotNet!



        Нагрузочное тестирование



        Представим, что мы с вами написали некий сервис — теперь нужно понять, какую нагрузку он выдержит. Старая грустная шутка разработки качественного ПО гласит, что лучше иметь софт, который работает гарантированно плохо, чем софт, работающий хоть и хорошо, но негарантированно хорошо: в первом случае мы хотя бы будем знать, на что твёрдо можем рассчитывать. Далее, если наш сервис умеет масштабироваться тем или иным образом, то нужно понять, насколько с ростом нагрузки масштабирование оказывается полезным и выполняет ли оно возложенные на него проектом задачи.



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



        Давайте представим, что мы с вами написали некоторый сервис — для определённости скажем, что веб-сервис, но это не столь важно. Чтобы убедиться, на что мы с ним можем рассчитывать, мы начинаем «обстреливать» его запросами, наблюдая за поведением как самого сервиса, так и за нагрузкой на серверах, где он крутится. Хорошо, если заранее понятно, какие запросы нам нужно отправлять сервису (в этом случае мы можем подготовить массив запросов заранее, а после отправить его в наше приложение одним махом). Если же второй запрос зависит от результатов первого (простой пример — сначала происходит авторизация пользователя, и в следующие обращения к сервису включается информация об ID сессии), то генератор нагрузки должен быть способен генерировать тестовые запросы крайне быстро, в реальном времени.



        С учётом обстоятельств и нашего знания об объекте тестирования выбираем инструмент(ы):



        JMeter



        Да, старый добрый JMeter. Он вот уже без малого двадцать лет (!) является частым выбором для многих вариантов и типов нагрузочного тестирования: удобный GUI, независимость от платформы (спасибо Java!), поддержка многопоточности, расширяемость, отличные возможности по созданию отчётов, поддержка многих протоколов для запросов. Благодаря модульной архитектуре JMeter можно расширить в нужную пользователю сторону, реализуя даже весьма экзотические сценарии тестирования — причем, если ни один из написанных сообществом за прошедшее время плагинов нас не устроит, можно взять API и написать собственный. При необходимости с JMeter можно выстроить, хоть и ограниченное, но распределённое тестирование, когда нагрузка будет создаваться сразу несколькими машинами.



        Одной из удобных функций JMeter является работа в режиме прокси: указываем в настройках браузера в качестве прокси «127.0.0.1:8080» и посещаем браузером нужные нам страницы нужного сайта, тем временем JMeter сохраняет все наши действия и все сопутствующие запросы в виде скрипта, который позже можно будет отредактировать, как нужно — это делает процесс создания HTTP-тестов заметно проще.



        Кстати, последняя версия (3.2), вышедшая в апреле этого года, научилась отдавать результаты тестирования в InfluxDB при помощи асинхронных HTTP-запросов. Правда, начиная как раз с версии 3.2, JMeter стал требовать только Java 8, но это, наверное, не самая высокая цена за прогресс.



        Хранение тестовых сценариев у JMeter реализовано в XML-файлах, что, как оказалось, создаёт массу проблем: их совсем неудобно писать руками (читай — для создания текста необходим GUI), как неудобна и работа с такими файлами в системах управления версиями (особенно в момент, когда нужно сделать diff). Конкурирующие на поле нагрузочного тестирования продукты, такие, как Яндекс.Танк или Taurus, научились самостоятельно и на лету формировать файлы с тестами и передавать их в JMeter на исполнение, таким образом пользуясь мощью и опытом JMeter, но давая возможность пользователям создавать тесты в виде более читаемых и легче хранимых в CVS тестовых скриптов.



        LoadRunner



        Ещё один давно существующий на рынке и в определенных кругах очень известный продукт, большему распространению которого помешала принятая компанией-производителем политика лицензирования (кстати, сегодня, после слияния подразделения ПО компании Hewlett Packard Enterprise с Micro Focus International, привычное название HPE LoadRunner сменилось на Micro Focus LoadRunner). Интерес представляет логика создания теста, где несколько (наверное, правильно сказать — «много») виртуальных пользователей параллельно что-то делают с тестируемым приложением. Это даёт возможность не только оценить способность приложения обработать поток одновременных запросов, но и понять, как влияет работа одних пользователей, активно что-то делающих с сервисом, на работу других. При этом речь идёт о широком выборе протоколов взаимодействия с тестируемым приложением.



        HP в своё время создала очень хороший набор инструментов автоматизации функционального и нагрузочного тестирования, которые, при необходимости, интегрируются в процесс разработки ПО, и LoadRunner умеет интегрироваться с ними (в частности, с HP Quality Center, HP QuickTest Professional).



        Некоторое время назад производитель решил повернуться лицом к тем, кто не готов сразу платить за лицензию, и поставляет LoadRunner с бесплатной лицензией (где вписан лимит на 50 виртуальных пользователей, и запрещена небольшая часть всего набора поддерживаемых протоколов), а деньги берутся за дальнейшее расширение возможностей. Сложно сказать, насколько это будет способствовать повышению интереса к этому, без сомнения, занимательному инструменту, при наличии у него столь сильных конкурентов.



        Gatling



        Весьма мощный и серьёзный инструмент (не зря названный в честь скорострельного пулемета) — в первую очередь, по причине производительности и широты поддержки протоколов «из коробки». Например, там, где нагрузочное тестирование с JMeter будет медленным и мучительным (увы, плагин поддержки работы с веб-сокетами не особо быстр, что идейно конфликтует со скоростью работы самих веб-сокетов), Galting почти наверняка создаст нужную нагрузку без особых сложностей.



        Следует учесть, что, в отличие от JMeter, Gatling не использует GUI и вообще считается средством, ориентированным на опытную, «грамотную» аудиторию, способную создать тестовый скрипт в виде текстового файла.



        Есть у Gatling и минусы, за которые его критикуют. Во-первых, документация могла бы быть и получше, во-вторых, для работы с ним неплохо знать Scala: и сам Gatling, как инструмент тестирования, и тестовые сценарии пишутся именно на этом языке. В-третьих, разработчики «иногда» в прошлом кардинально меняли API, в результате можно было обнаружить, что тесты, написанные полугодом ранее, «не идут» на новой версии, либо требуют доработки/миграции. У Gatling также отсутствует возможность делать распределённое тестирование, что ограничивает возможные области применения.



        Яндекс.Танк



        Если коротко, Yandex Tank — это враппер над несколькими утилитами нагрузочного тестирования (включая JMeter), предоставляющий унифицированный интерфейс для их конфигурации, запуска и построения отчётов вне зависимости от того, какая утилита используется «под капотом».



        Он умеет следить за основными метриками тестируемого приложения (процессор, память, своп и пр.), за ресурсами системы (свободная память/место на диске), может остановить тест на основе разных понятных критериев («если время отклика превышает заданное значение», «если количество ошибок за единицу времени выше, чем х» и т.д). Кстати, умеет отображать в реальном времени основные статистические данные теста, что бывает очень полезно прямо в процессе теста.



        Танк используется и в самом Яндексе, и в других компаниях уже около 10 лет. Им обстреливают совершенно разные сервисы, с разными требованиями к сложности тестовых сценариев и к уровню нагрузки. Почти всегда для тестирования даже высоконагруженных сервисов хватает всего одного генератора нагрузки. Танк поддерживает разные генераторы нагрузки, как написанные специально для него (Phantom, BFG, Pandora), так и широко сторонние (JMeter). Модульная архитектура позволяет написать свой плагин под нужный генератор нагрузки и вообще прикрутить практически что угодно.



        Для чего использовать разные генераторы нагрузки? Phantom — это быстрая «пушка» на C++. Один такой генератор может выдать до сотни тысяч запросов в секунду. Но для достижения такой скорости приходится генерировать запросы заранее и нельзя (не получается) использовать получаемые от тестируемого сервиса данные для генерации очередного запроса. В случаях, когда нужно исполнять сложный сценарий или сервис использует нестандартный протокол, следует использовать JMeter, BFG, Pandora.



        В BFG, в отличие от Jmeter, нет GUI, тестовые сценарии пишутся на Python. Это позволяет использовать любые библиотеки (а их огромное количество). Часто бывает, что для сервиса написаны биндинги для Python, тогда их удобно использовать при написании нагрузочных сценариев. Pandora — это экспериментальная пушка на GoLang, достаточно быстрая и расширяемая, подходит для тестов по протоколу HTTP/2 и будет использоваться там, где нужны быстрые сценарии.



        Внутри Яндекса для хранения и отображения результатов нагрузочных тестов используется специальный сервис. Сейчас наружу открыт его упрощенный аналог под названием Overload — он полностью бесплатен, его используют, в том числе, для тестирования открытых библиотек (например) и проведения соревнований.



        Taurus



        Taurus — ещё один фреймворк над несколькими утилитами нагрузочного тестирования. Возможно, вам понравится этот продукт, использующий похожий на Яндекс.Танк подход, но имеющий несколько другой набор «фич», и, пожалуй, более адекватный формат конфигурационных файлов.



        Вообще, Taurus хорошо подойдёт в ситуации, когда мощность, скажем, Gatling важна для создания теста, но разбираться с Gatling (а также с написанием скриптов тестирования на Scala) нет желания или возможности: достаточно описать тест в куда более простом формате файла Taurus, настроить его на использование Gatling как инструмента создания нагрузки, и все Scala-файлы будут сгенерированы автоматически. Так сказать, «автоматизация автоматизации» в действии!



        Taurus можно настроить на отправку статистики теста на онлайн-сервис BlazeMeter.com, который отобразит данные в виде нарядных графиков и таблиц. Подход не очень обычный, но заслуживающий внимания: движок вывода отчётов, очевидно, совершенствуется со временем, и постепенно будет выводить информацию ещё более симпатично.



        Тестирование производительности



        Тестировать производительность сервиса или приложения можно и нужно не только после завершения процесса разработки, но и во время неё, буквально так же, как мы делаем регулярные юнит- или регрессионные тесты. Правильно организованные, регулярные тесты производительности позволяют ответить на очень «тонкий» вопрос: не привели ли последние изменения в коде приложения к ухудшению производительности получившегося ПО?



        Казалось бы, померить производительность — это так просто! Два раза взять timestamp (желательно с высокой точностью), посчитать разность, сложили-поделили, и всё — можно оптимизировать. Как бы не так! Хотя на словах этот вопрос звучит просто, на деле такого рода замеры довольно затруднительно производить, а сравнивать результаты разных замеров вообще не всегда разумно. Одна из причин: для сопоставления результатов тесты должны проходить над одними и теми же исходными данными, что, среди прочего, подразумевает воссоздание тестовой среды при каждом прогоне проверки, другая причина — сравнение субъективного восприятия времени работы тестового сценария может оказаться неточным.

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



        Один из подходов в такой ситуации состоит в тщательном создании полноценного тестового сценария, повторяющего работу с сервисом настоящего клиента, и прогоне его много раз, с параллельным анализом нагрузки на сервер, где проходит тестирование (таким образом, будет понятно, какая часть сценария создаёт нагрузку на отдельные ресурсы тестового сервера, что может дать дополнительную информацию по поиску мест, где следует подойти к производительности более серьёзно) — увы, не всегда можно такое позволить себе в реальной ситуации, просто потому, что объёмный тест, да ещё повторённый 10-20 раз, скорее всего будет слишком долгим, чтобы проводить его достаточно часто, а это полностью убьёт идею.



        Второй подход, более подходящий к процессу разработки, заключается в организации ограниченного по масштабу, «микро-» или даже «нано-» тестирования отдельных мест кода (скажем, запуске одного метода или одной функции, но большое число раз — т.е., скорее, бенчмаркингу). Планирование такого тестирования требует дополнительных усилий со стороны разработчика, но результат окупается и общим улучшением производительности кода, и пониманием, как ведут себя отдельные части проекта по мере работы как над ними, так и над другими частями. Вот, для примера, пара инструментов для перформанс-тестирования:



        JMH



        JMH (Java Microbenchmark Harness) — это оснастка Java для сборки, запуска и анализа нано/микро/милли/макро-бенчмарков, написанных на Java и других языках с целевой платформой JVM. Сравнительно молодой фреймворк, в котором разработчики постарались учесть все нюансы JVM. Один из удобнейших инструментов, из тех, которые приятно иметь под рукой. JMH поддерживает следующие типы замеров: Throughput (замер чистой производительности), AverageTime (замер среднего времени выполнения), SampleTime (перцентиль времени исполнения), SingleShotTime (время вызова одного метода — актуально для замера «холодного» запуска тестируемого кода).



        Поскольку речь идёт о Java, фреймворк учитывает в т.ч. и работу механизма кэширования JVM, и перед запуском бенчмарка несколько раз выполняет тестируемый код для «прогрева» кэша байт-кода Java-машины.



        BenchmarkDotNet



        BenchmarkDotNet берёт на себя рутинные действия при составлении бенчмарков для .NET-проектов и обеспечивает широкие возможности форматирования результатов ценой минимальных усилий. Как говорят авторы, фиче-реквестов хватает, поэтому BenchmarkDotNet есть куда развиваться.



        На сегодняшний день BenchmarkDotNet — библиотека, в первую очередь, для бенчмарков, а не для перфоманс-тестов. Ведётся серьёзная работа над тем, чтобы библиотеку можно было также использовать на CI-сервере для автоматического детектирования перфомансных регрессий, но пока эти разработки не завершены.



        Google Lighthouse



        Замеры производительности фронтенда всегда стояли несколько особняком: с одной стороны, часто задержки связаны со скоростью реакции бэкенда, с другой — именно по поведению фронтенда (точнее, по скорости его реакции) пользователи часто судят о всём приложении, особенно, если речь идёт про веб.



        В веб-фронтенде в отношении замеров производительности сейчас всё идёт в сторону использования Performance API и измерении именно тех параметров, которые имеют значение для конкретного проекта. Хорошим подспорьем окажется веб-сервис webpagetest.org с Performance API метками и замерами — он позволит увидеть картину не со своего компьютера, а с одной из многих точек тестирования, существующих в мире, и оценить влияние времени приёма-передачи данных через каналы интернет на работу фронтенда.



        Этот продукт больше подходил бы для проверки страниц сайта на соответствие рекомендациям Google (и вообще best practices) как для веб-сайтов, так и для Progressive Web Apps, если бы не одна из его функций: среди проверок есть и тест на поведение сайта при плохом качестве веб-соединения, а также при полном отсутствии связи. Это не очень соотносится с перформанс-тестированием как таковым, однако, если задуматься, в некоторых случаях веб-приложение воспринимается «медленным» не потому, что медленно готовит данные, а потому, что условия его работы на машине пользователя, в его браузере, с учётом его соединения с интернетом — увы, не идеальны. Google Lighthouse как раз и позволяет оценить это влияние.






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

        Поэтому с радостью приглашаем вас посетить конференцию Гейзенбаг 2017 Moscow, которая состоится 8-9 декабря 2017 года, где будут, в частности, представлены доклады:





        Подробности и условия участия можно узнать на сайте конференции.


        Original source: habrahabr.ru (comments, light).

        https://habrahabr.ru/post/337928/

        Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
        kiev2376393

        Google начинает бета-тестирование Google Attribution в России

        Четверг, 14 Сентября 2017 г. 14:21 (ссылка)

        Google анонсировал начало закрытого бета-тестирования аналитического инструмента Google Attribution в России. Как сообщил старший аналитик Google Росссия Станислав Видяев, в рамках проходящей сегодня конференции SEMconf 2017, тестирование начнется уже

        Читать далее...
        Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
        rss_rss_hh_new

        Приглашаем на конференцию Azov Developers Meetup — 23 сентября в Таганроге

        Четверг, 14 Сентября 2017 г. 08:43 (ссылка)






        akholyavkin


        сегодня в 08:43

        Маркетинг





        Приглашаем на конференцию Azov Developers Meetup — 23 сентября в Таганроге














          Приглашаем провести 23 сентября с нами в Таганроге на Azov Developers Meetup 2017.



          Приезжаем к 9 утра в конгресс-отель «Таганрог» на ул. Дзержинского, 161 попить кофе перед началом и до трёх часов дня послушать лекции о разработке. Мы расскажем о Vue.js и CQRS, попробуем найти точки соприкосновения SQL и NoSQL, поговорим о пределах совершенства кода и о настоящем Quality Assurance, развеем страхи перед интервью с заказчиком и ответим на дизайн-вопросы. Кроме того, мы пригласили на конференцию Михаила Скипского — игрока телеклуба «Что? Где? Когда?», обладателя двух «Хрустальных сов» (2010, 2016) — он расскажет о принятии решений и эффективности в малых группах.



          Как всегда, помимо лекций мы приготовили активности для участников, а все презентации и видеозаписи выступлений докладчиков будут доступны на сайте мероприятия.



          А в 17 часов в клубе Stage в ТРЦ «Мармелад» пройдет after party — Михаил проведет для участников конференции интеллектуальный батл, проверим на практике тезисы из его выступления!



          Более подробно о докладах:



          Как проходить интервью с заказчиком

          Андрей Холявкин, руководитель Таганрогского офиса Аркадии



          Любой разработчик или тестировщик сервисной ИТ-компании рано или поздно подходит к этому таинственному событию — чтобы попасть на новый, такой интересный и заманчивый, проект, нужно пройти интервью с представителями клиента. В первый раз это может даже пугать!



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



          Vue.js: новый фреймворк для front end

          Михаил Зотов, разработчик



          Среди множества фреймворков для front end наиболее популярными и известными являются Angular и React, однако хорошую конкуренцию им составляет новый фреймворк Vue.js. Михаил рассмотрит преимущества Vue.js перед его конкурентами и подробно опишет внутреннюю структуру компонентов Vue.js.



          Из Тестировщика erectus в QA sapiens

          Никита Белковский, QA инженер



          Никита занимался тестированием на проектах разной сложности, с разными командами и разными подходами к управлению. Но один проект ощутимо отличался от всех остальных. Эта история о том, как на «слабом» проекте ему удалось почувствовать, что такое Quality Assurance.



          Принцип CQRS в событийной веб архитектуре

          Михаил Черноруцкий, IT специалист



          Доклад посвящён рассмотрению одного из паттернов построения архитектуры web backend — CQRS (Command Query Request Segregation). Обсудим, что из себя представляет CQRS, и в каких случаях имеет смысл его использовать:


          • происхождение и назначение паттерна CQRS (Command Query Responsibility Segregation);

          • преимущества и недостатки;

          • применение паттерна CQRS в архитектурах веб систем;

          • сопутствующие понятия: Event Sourcing, Eventual Consistency, Materialized Views и т.д.





          Дизайн-вопросы

          Борис Винокуров, UX-UI дизайнер



          Кто такие UX/UI дизайнеры? Зачем они нужны в процессе проектирования веб-приложений? Можно ли обойтись без их помощи и помощь ли это? Чем они отличаются от других дизайнеров и можно ли их считать художниками? Как устроен их рабочий процесс? Что считается хорошим результатом и почему? Креатив и творчество или решение задач? А может у вас найдутся и свои вопросы? Рад буду ответить.



          Чистый код в коммерческой разработке. Есть ли предел совершенству?

          Юрий Ковалёв, разработчик



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




          • Рассмотрим знаменитое правило бойскаута на конкретных примерах из жизни.

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

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





          SQL или NoSQL?

          Владимир Кальсков, старший разработчик

          Олег Брагин, старший разработчик



          Два разных — на первый взгляд — подхода к организации хранения данных. Две разные вселенные, в которых живут и работают люди с разным типом мышления. Могут ли они объединиться? Будет ли какой-то из подходов доминировать в будущем? Попытаемся найти идеальный способ хранения данных.



          Что? Где? Когда? как модель командной работы

          Михаил Скипский



          Мы обычно воспринимаем телеигры как развлекательный контент, мало задумываясь над тем, что любая игра изначально является моделью. В случае с «Что? Где? Когда?» — социальной и технологической моделью принятия решения. Это означает, что поняв, как играть в «ЧГК» и подобные игры, мы поймём, как принимает решение группа, как она управляется и какие проблемы мешают малому коллективу быть эффективным.



          Для участия необходимо зарегистрироваться на сайте конференции. Приходите, будет интересно!


          Original source: habrahabr.ru (comments, light).

          https://habrahabr.ru/post/337908/

          Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

          Следующие 30  »

          <тестирование - Самое интересное в блогах

          Страницы: [1] 2 3 ..
          .. 10

          LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
          О проекте: помощь|контакты|разместить рекламу|версия для pda