Статья публикуется от имени Ахальцева Иоанна, Jiga

Tinkoff.ru сегодня — это не просто банк, это IT-компания. Она предоставляет не только банковские услуги, но ещё выстраивает экосистему вокруг них.

Мы в Tinkoff.ru заключаем партнерство с различными сервисами для повышения качества обслуживания своих клиентов, и помогаем становиться этим сервисам лучше. Например, мы проводили нагрузочное тестирование и анализ производительности одного из таких сервисов, которые помогли найти узкие места в системе — включенные Transparent Huge Pages в конфигах ОС.

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

Статья публикуется от имени Иванова Андрея и Батеевой Екатерины, neifmetus

Автоматизация мобильных приложений довольно молодая сфера: фреймворков много и многие проекты сталкиваются с проблемой выбора самого «быстрого, стабильного, простого в использовании». Также и мы около двух лет назад стояли перед выбором нового инструмента автоматизации тестирования Android приложений.
Все популярные инструменты так или иначе базировались на UIAutomator и Espresso, поэтому мы решили затестить их в чистом виде и сравнить с теми же Appium (самый популярный) и seeTest (использовался до этого, лучший среди платных на тот момент).

Из достоинств Appium можно выделить привычный многим WebDriver API, возможность использования большинства популярных языков и библиотек. Кроме этого, он широко используется во многих компаниях и позволяет писать тесты сразу под платформы iOS и Android. И, наконец, это бесплатное коробочное решение — что может быть лучше?

Так думали мы, пока не обнаружили следующие недостатки:

• низкая стабильность Appium Server
• нельзя взаимодействовать с публичными методами Activity (в 2018 году про создание backdoor в Appium рассказал в своей статье Николай Абалов из Badoo, прочитать можно здесь)
• сильно уступает по скорости выполнения тестов Espresso

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

Итак, фреймворк был выбран, оставалось найти остальные компоненты:

1. Runner — должен позволять запускать тесты параллельно и конфигурировать пулы устройств
2. Reporter — должен предоставлять удобочитаемый отчет, которым мог бы пользоваться любой член команды

Статья публикуется от имени Кочеткова Александра и Красс Снежаны

Сколько отличий вы найдете за 10 секунд?



Наш тестировщик найдет ВСЕ отличия. И даже те, которые не видны. Ниже я расскажу о том, как он это сделает, но для начала немного введу вас в курс дела.

Статья публикуется от имени Масленникова Сергея, sergeymasle

UPD. Добавлен раздел "Реализация расширения для Gatling"

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

Статья публикуется от имени Батеевой Екатерины, Neifmetus



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

В нашем банке мы тоже наблюдаем эту тенденцию: мобильное приложение по сравнению с интернет-банком используют на порядок больше пользователей. Поэтому остро встал вопрос автоматизации тестирования мобильного приложения. Несмотря на повсеместное использование мобильных приложений, средства для их автоматизированного тестирования далеко не идеальны. Кроме того, мы предъявляем к ним высокие требования. Например, самый популярный фреймворк Appium — open-source решение, поддерживающее платформы Android и iOS, — нам не подошел. Наши разработчики использовали много модных библиотек, и взаимодествовать с приложением иногда приходилось на более низком уровне. UI Automator и UI Automation оказались более сложными в развертывании, каждое приложение использовало свой язык для написания тестов, из-за чего возникали проблемы при перераспределении между платформами в команде автотестирования.

Статья публикуется от имени Перфильева Алексея, akaaxel

Gatling – это framework для проведения нагрузочного тестирования. Он основан на трех технологиях: Scala, Akka и Netty.
В этой статье мы:

1. Посмотрим, как установить и начать использовать Gatling.
2. Разберем синтаксис скриптов Gatling на языке Scala.
3. Напишем небольшой тест, где используем основные функции Gatling. Запустим тестовый скрипт при помощи sbt и сохраним отчет.

Статья публикуется от имени Трубанова Вадима, @vonaburt

Методология BDD все чаще завоевывает внимание IT-индустрии как логически верная ступень развития традиционных подходов к тестированию проектов, в том числе подходов к автоматизации тестирования. Текущая эпоха информационных технологий диктует свои правила, и в этой гонке технологий выигрывает тот, кто умеет реагировать на любые изменения быстро и качественно. Особенно это касается компаний связанных с банковской деятельностью, например таких, как наш банк, где каждый отложенный час до релиза может повлиять на общую картину качества сервисов, составляемую нашими клиентами. При правильном использовании методология BDD позволяет сократить время, затрачиваемое на тестирование выпускаемых продуктов, повышать качество проводимого тестирования и делать сам процесс прозрачным и понятным для всех, что и подтолкнуло нас к её использованию. На данный момент методология BDD внедряется на двух наших web-продуктах, активно развивается и уже приносит свои плоды. Хочется поделиться нашим опытом внедрения BDD со стороны автоматизации тестирования и рассказать об основных принципах, которые позволят вам внедрить эту методологию безболезненно, быстро и, самое главное, сделать её использование эффективным.