Ифт что это расшифровка в it
Автоматизация нагрузочного тестирования банковского ПО для терминалов
В этом посте речь пойдет о тестировании серверного ПО, которое обслуживает огромную сеть банковских терминалов в России и за рубежом. Название банка мы раскрыть не можем, некоторые строчки конфигов скрыты.
Итак, мы занимаемся разработкой данного ПО, используя современный CI/CD подход, чем обеспечивается высокая скорость поставки фич, хотфиксов и релизов в продакшн. В начале года нам была предложена задача обеспечить нагрузочным тестированием разрабатываемое решение и продемонстрировать заказчику способность встраивать в CI/CD любые подзадачи и шаги.
Помимо общих слов, хотелки сводились к следующему: необходимо обеспечить автоматический деплой ПО на нагрузочный стенд, придумать легкий способ генерации данных, внедрить автоматический и полуавтоматический способ запуска тестов, снабдить тесты автоматическим триггером старта и остановки по событию, подключить механику НТ к трекеру задач для короткого репортинга, подключить систему тестирования к доступной системе аналитики НТ, создать возможность “покраски” плохих и хороших релизов для дальнейших действий в workflow (выкатить или отправить репорт). Требования, надо признать, абсолютно адекватные и понятные.
Автоматизация
Начнем издалека. Мы постоянно слышим одно и то же: “Автоматизировать нагрузочное тестирование банковского и финансового ПО невозможно! У нас слишком много взаимосвязей! Мы очень сложные!”. Этот вызов только усиливал азарт решения задачи. Нам всегда хотелось проверить сложность на конкретном примере.
Помните замечательную картинку про тестирование в виде пирамидки и рожка с мороженым? Пирамидка – это когда у вас много дешевых автоматических Unit-тестов и мало дорогих UI. Рожок с мороженным – наоборот. Рожок – это дорого, неповоротливо и не масштабируется, пирамидка – дешево и гибко.
Вместо того, чтобы заниматься нагрузочным тестированием ПО на уровне взаимодействий систем, в секторе банковского ПО традиционно все тестируют через UI, как повелось со времен неразъемных систем и приложений. На это уходит много времени и сил, что делает разработку банковского ПО медленной, некачественной и нетехнологичной. Мы в компании “Инфосистемы Джет” были избавлены от этих стереотипов — разработчики сами писали юнит-тесты на свой код, функциональные тестировщики прекрасно программировали UI-тесты через Selenium+Cucumber. Осталось только встроить в процесс дополнительную стадию нагрузочного тестирования.
Проектирование инфраструктуры
В самом начале мы решили отказаться от взаимосвязей, которые усложняют и размывают ответ на вопрос, насколько производительный и надежный код мы разрабатываем. Например, авторизация и выдача токенов на проведение операций — это функциональность сторонней системы, исследовать производительность которой в рамках задачи было бы избыточно. Помимо этого мы сразу отказались от интеграции с несколькими back-office системами, сделав заглушку, отвечающую нашей системе с определенной задержкой (все мы знаем, как опасно тестировать систему на сверхбыстрых моках).
Но самое значительное изменение в парадигме тестирования ‒ это отказ от нагрузочного тестирования UI-терминала. До сих пор это кажется странным, но до нас данное серверное ПО нагрузочно тестировали именно через UI ATM. Происходило это следующим образом: эмулировался некоторый средний пользователь, который проходил какой-то пул сценариев с набором средних пауз (paсing, think time), а нагрузочный инструмент был вынужден создавать нагрузку, которая состоит из длительных и “холодных” сценариев с нескольких лоад-генераторов HP Loadrunner, в то время как результирующая нагрузка на одну ноду API-сервера составляла всего около сотни(!) транзакций в секунду. (Оставим за скобками безумную картину, когда тысячи граждан пытаются нажимать на контролы одного банковского терминала). В итоге из стенда было выброшено практически все, что не имело отношения к производительности бэкенда ATM.
После проектирования и осмотра оставшейся инфраструктуры стало примерно понятно, как будет выстроен процесс, какие бенефиты будут получены, и нужно было приступать к созданию самого процесса НТ.
CI/CD процесс и программное обеспечение
Код ПО выкладывается во внутреннем git-репозитории (GitLab). После коммита по специальному триггеру Jenkins вытаскивает код на сборочную машину и пытается собрать релиз с прогоном всех заведенных Unit-тестов. После успешной сборки с помощью скриптов собранный билд инсталлируется в два тестовых окружения ‒ НТ и ФТ ‒ и делает рестарт тестинга. После подъема бэкенда Jenkins прогоняет друг за другом ФТ, UI и ИФТ-тесты. Нагрузочное тестирование запускается отдельной задачей, но про это стоит рассказать отдельно.
Как всем известно, классический инструмент нагрузочного тестирования состоит из трех “столпов”: генератора тестовых данных, лоад-генератора и анализатора полученных результатов. Поэтому задачу мы решали в трех направлениях.
Чтобы собрать релевантный запрос к API и не переписывать каждый раз XML под изменяющуюся спецификацию, мы пошли другим путем ‒ мы “грабим” TOP-10 основных платежных сценариев в момент прогона UI-тестов. Для этого на тестовом стенде мы развернули tshark, из дампа которого и собираем XML (его впоследствии будем отправлять в API). Это позволяет экономить кучу времени и сил на подготовку тестовых данных.
В качестве лоад-генератора мы использовали самый популярный инструмент на Open Source рынке ‒ JMeter, но в качестве обвязки к нему использовали Yandex.Tank. Мощности JMeter для отправки 100 транзакций в секунду на одну ноду хватает с лихвой, а Tank дает нам удобство в автоматизации и несколько полезных фич ‒ автостопы, интерактивные графики, возможность использования других генераторов нагрузки без перекраивания процесса НТ и т.д.
Самое сложное на этапе конструирования НТ ‒ это аналитическая часть. Так как на рынке пока нет отдельных решений по созданию своей аналитики для тестирования производительности, мы решили использовать Overload от Яндекса. Overload – это сервис для хранения и анализа результатов нагрузочных тестов. Нагрузку вы создаете со своих лоад-генераторов, а результаты загружаете на сервис и наблюдаете их там в виде графиков. Сейчас сервис находится в публичной бете, а для “Инфосистемы Джет” Яндекс создал пилотный приватный инстанс.
Все данные с нашего JMeter поступают в Overload в агрегированном виде и не содержат никакой персональной информации о платежах и клиентах ‒ пользователь видит только графическое представление тестов производительности.
Самое интересное
После того как билд попадает на нагрузочный стенд, посредством скриптов в Jenkins запускается специальная задача для нагрузочного тестирования. Задача настроена классическим способом, через shell-скриптинг и параметризацию.
Например, так можно конфигурировать автостопы:
Так выглядит конфиг Yandex.Tank:
А так выглядит пример shell-script запуска всего процесса НТ:
Как видите, все настройки достаточно примитивны. При автоматическом запуске джоба дефолтные параметры применяются автоматически, при ручном же запуске вы можете конфигурировать стрелялку параметрами Jenkins, не разбираясь в документации и не копаясь на Linux-машинке и перебирая необходимые конфиги.
Режим “Запуск по кнопке” для разработчика выглядит так:
После запуска теста вы получаете ссылку в Console View Jenkins и Telegram, перейдя по которой можно наблюдать нагрузочный тест в реальном времени:
Если результаты теста вышли за пределы SLA, то тест автоматически останавливается и вы получаете репорт в Telegram, почту и JIRA о проблемах с релизом. Если же результат хороший, то после репорта релиз получает статус SUCCESS и готов для деплоя на нагруженную среду, в продакшн.
Скрин с экрана Telegram:
А так бот репортит результаты в JIRA:
В качестве корпоративной “плюшки” от Яндекса мы получили доступ к сравнению тестов:
и доступ к построению регрессионных отчетов по KPI-метрикам:
Проблемы и решения
Данный рассказ был бы неполным, если бы мы не описали несколько граблей, на которые наткнулись в процессе своей работы.
Мониторинг. Очевидно, что при нагрузочном тестировании вы обязаны использовать средства не только бизнес-мониторинга (валидация транзакций, размер очереди, скорость прохождения), но и системного мониторинга (потребление процессора, объем памяти, число дисковых операций, метрики, которые вы придумали сами и т.д.). Хорошо, когда у вас вся инфраструктура построена на Linux ‒ использование встроенного решения на telegraf поверх ssh решает эту задачу ‒ все данные автоматически заливаются в бэкенд статистики и строятся синхронно с агрегатами бизнес-метрик. Но что делать, если у вас часть тестового окружения построена на Windows-платформе?
Мы обсуждали разные варианты и пришли к такому:
В данном случае, все метрики с серверов и load-генераторов пишутся в InfluxDB локальными агентами telegraf, а мониторинг Яндекс.Танка уже извлекает данные из InfluxDB простейшим скриптом и пушит данные в Overload. Такой подход позволяет отказаться от поддержки всего зоопарка операционных систем со стороны Яндекс.Танка и избежать необходимости коннекта “от одного ко всем”.
Написав простейший скрипт, вроде:
Мы можем заставить Яндекс.Танк собирать Custom-метрики из InfluxDB таким конфигом мониторинга:
В результате получаем такие графики в Overload:
Репортинг. Мы использовали два вида репортинга результатов.
Краткий отчет ‒ небольшой объем метаинформации с распределением времен и сообщением от автостоп-плагина ‒ отправлялся в виде сообщения в Telegram-чат, на который были подписаны разработчики, архитектор, менеджер и тестировщики.
Регрессионный отчет ‒ расширенный отчет, где к краткой информации добавлялось сравнение с эталонными результатами ‒ отправлялся в виде комментария в JIRA.
Для этого мы использовали скрипт на Groovy для Telegram и простенькую либу (подробнее на https://pypi.python.org/pypi/jira/) для провязки c API JIRA.
Заключение
Как можно заметить, данная задача не из разряда Rocket Science, и вы могли читать подобные статьи здесь, здесь и даже смотреть видео здесь. Под капотом лежат обычные скрипты и сервисы ‒ мы всего лишь хотели продемонстрировать, что на самом деле к эре “Devops” и повальной автоматизации финансовый сектор готов уже давно, просто нужно иметь смелость и политическую волю внедрять современные и быстрые процессы.
Какие бенефиты мы можем получить от автоматизации?
Команда нагрузочного тестирования компании “Инфосистемы Джет”.
Как инженеры a1qa проводили приёмо-сдаточные испытания ПО: Часть 1. Теоретическая
Вот уже более двух лет команда a1qa работает на проекте по созданию платежной системы для одного крупного банка. Поначалу задачи нашей команды сводились только к тестированию системы, однако через некоторое время заказчик поручил нам подготовку и проведение приёмо-сдаточных испытаний.
Задача эта нетипичная для тестировщиков. Поэтому мы решили поделиться своим опытом и рассказать, как её грамотно выполнить, оправдав доверие заказчика.
Что такое приёмо-сдаточные испытания (ПСИ)?
Прежде чем выпускать продукт на рынок, заказчик должен убедиться в возможности использования разработанного решения, в его безопасности, надёжности, корректном функционировании и проверить другие характеристики, описанные в требованиях к продукту.
ПСИ особенно актуальны для проектов, на которых выпуск некачественного продукта может привести к значительным финансовым потерям (к слову, наш проект именно к таким и относится).
Итак, цели проведения ПСИ:
Избежать хаоса в подготовке и проведении ПСИ, развеять сомнения в методах убеждения и их эффективности помогают различные нормативно-правовые документы, которые стандартизируют процессы разработки и тестирования.
Один из таких документов, обязательный для любых приёмо-сдаточных испытаний, – это «Программа и методика испытаний».
Документ «Программа и методика испытаний»: что нужно знать тестировщику
Написанием и форматированием данного документа обычно занимаются специально обученные люди, например, технические писатели.
Однако знать, из чего состоит документ, тестировщику не помешает. Кроме того, подготовка одного из разделов может быть поручена именно тестировщикам.
Обратимся к официальной документации. Согласно межгосударственному стандарту ГОСТ 19.301-79, документ «Программа и методика испытаний» должен иметь следующую структуру:
Какой из разделов под силу подготовить функциональному тестировщику? Конечно же, «Методы испытаний». Об этом поговорим позже, а пока ещё немного теории.
Критерии успешности приёмо-сдаточных испытаний
Как правило, успешность ПСИ определяется на этапе заключения контракта. Одним из таких критериев может быть процент успешно пройденных во время демонстрации проверок. Например, если на проверку выносятся 100 тест-кейсов и критерий pass-rate составляет 80%, то 80 тест-кейсов должно быть успешно пройдено, иначе считается, что продукт приёмку не прошел, а значит, не может быть допущен к опытной и промышленной эксплуатации.
На практике же успешность приёмо-сдаточных испытаний чаще определяется не одним критерием, а совокупностью нескольких. Например, учитывается процент реализованных требований от общего числа и ограничение по количеству дефектов того или иного приоритета. Оперируя данными по этим критериям, принимается решение об успешности ПСИ.
На этом необходимая теория заканчивается. В следующей части расскажем, как приёмо-сдаточные испытания проводила команда a1qa и какие трудности ей пришлось преодолеть.
Ифт что это расшифровка в it
Правило 2. При публиковании поста ставим корректные теги, передающие смысл публикации.
Управление сообществом
Комментарий дня
А Козловский сыграет Плотву.
Рекомендуемое сообщество
Пикабу в мессенджерах
Активные сообщества
Тенденции
Каждый раз на ИФТ вспоминаю это место из творения Мела Брукса. Хоть бы раз с первого прогона все бы прошло иначе.
Лига программистов
384 поста 6.5K подписчиков
Правила сообщества
Правило 2. При публиковании поста ставим корректные теги, передающие смысл публикации.
Робин Гуд мужчины в трико
Это должно быть в переводе Володарского!
А надо ли учиться?
Я понимаю, что даже при покупке курса надо будет что-то почитывать дополнительно, но на сколько это реально, например, для того же, скажем, юриста со знанием английского на уровне Pre-Intermediate?
Так много вопросов, много желания начать учиться и изменить жизнь к лучшему, уйти из старой нелюбимой профессии, и столько же здорового реализма, который заставляет сомневаться в собственных возможностях и оценивает память уже не как свежую студенческую, а немного поношенную, что значительно затруднит процесс. И после работы и нервяков голова тупит уже слегонца. И здоровую прокрастинацию никто не отменял. Поделитесь опытом, пожалуйста.
Пы.Сы. Не бейте сильно, если эта тема уже обсуждалась, а я пропустила или мой вопрос кому-то покажется глуповатым.
Разработчик наблюдает работу тестировщика
Кто что забыл в IT
Хочу сакцентировать внимание, что пост этот призван в общих чертах рассказать людям извне о тех ролях, которые есть в процессе создания программного обеспечения. Многие детали упущены, многие особенности не отражены.
Коллегам из IT я хочу сказать, что вы, без сомнения, классные, умные ребята. Пожалейте, пожалуйста, бедного нервного аналитика, который писал этот пост.
Текст мой, фото из интернета.
Кто есть кто в процессе разработки
1. Приходит заказчик, у которого ферма по производству сферических коней в вакууме. С ним заключают договор «на автоматизацию производства сферических коней в вакууме». Эти услуги продают сейлзы.
— понимать предметную область, в которой работает компания (в нашем случае это автоматизация производства);
— понимать, что может сделать компания и примерно представлять, что нужно клиенту.
Кроме того, тут важны «софт скилы»:
— умение презентовать продукт;
— объяснять, как все работает;
— уточнять, что в общих чертах нужно клиенту.
2. Когда документы подписаны, начинается этап анализа. Бизнес-аналитик приходит к заказчику и начинает задавать каверзные вопросы:
— А как вы коней создаёте?
— А что вы при создании задаёте? Только радиус? Или ещё цвет?
— А кто вообще коней создать может?
— А кто должен знать, что коня создали?
Потом аналитик идёт, выписывает в деталях, что нужно сделать, и согласует это с заказчиком.
— уметь вгрызаться в заказчика и вытаскивать все детали того, как люди работают;
— хорошо структурировать мысли (хорошо бы знать про требования, критерии приемки и т.д.);
— уметь описывать процессы и согласовывать с заказчиком. Для этого есть разные нотации: UML, BPMN;
— для этапа дизайна (ниже) нужно уметь описывать модели данных, взаимодействие систем (для этого тоже есть диаграммы, например UML);
Рядом с бизнес-аналитиком на этапе анализа работает системный аналитик. Этот человек смотрит, что есть в системе сейчас (как устроены базы данных, с какими системами нужно настроить взаимодействие и т.д)
Системный аналитик должен:
— умеешь формулировать свои мысли;
— понимать, как устроены системы;
— понимать, как устроено взаимодействие систем (тут стоит почитать про API);
3. После анализа идёт этап дизайна. Здесь участвуют аналитики и архитектор. На данном этапе, после того как понятно, что есть, придумывают, как сделать заказчика счастливым.
В нашем примере команда решает, как будет в системе представлен сферический конь, какие будут механизмы создания, как будут уведомлять заинтересованных лиц.
Архитектор видит систему в целом и принимает глобальные решения. Деталями занимаются аналитики. В архитекторы часто уходят разработчики и аналитики, тестировщиков я пока не встречала (но это не значит, что их нет).
Кроме архитектора на этапе дизайна появляется дизайнер интерфейсов. Его задача сделать так, чтобы пользователю было удобно и понятно, как система работает. Обычно бизнес-аналитик доносит суть той или иной операции, а дизайнер придумывает кнопки, формы, поля.
— разбираться в том, как строятся пользовательские интерфейсы;
— иметь чувство прекрасного.
4. Как только все задизайнено, начинается разработка. Тут пишут код, создают базы данных и таблицы, настраивают интеграции. Все в соответствии с дизайном.
Разработчики бывают совершенно разные. Есть те, кто делают красивые формы (фронтенд), есть те, кто пишут логику (бэкенд), есть те, кто делает и то, и другое (фулстек). Кроме того, есть спецы по БД, по интеграциям (API). Если интересна работа разработчика, то нужно вначале понять, к чему именно душа лежит.
5. Когда весь код написан, надо тестировать. Тут у нас тестировщик. Он проверяет, что все соответствует дизайну, работает корректно. Если что-то пошло не так, тестировщик заставляет программиста переделать.
— понимать, как должна работать система
— иметь воображение, чтобы понять, что можно сломать
— понимать, как строятся тесткейсы и тестовые сценарии
— уметь воспроизводить найденные проблемы и описывать их для разработки.
Тестировать можно ручками либо при помощи автотестов. Во втором случае нужно уметь кодить.
6. Пока все тестировали и правили, документатор поговорил с аналитиками и описал поведение системы понятным пользователю языком.
Документатор молодец, если:
— понимает, как будет работать пользователь;
— умеет грамотно выражать свои мысли.
Не редки ситуации, когда документацию пишет бизнес-аналитик. Просто потому, что этот человек хорошо разбирается в процессах пользователя.
— процессы сборки (CI/CD);
— умеет писать конфиги (так что да, тут надо кодить);
— умеет настраивать интеграции;
— понимать, как устроена инфраструктура заказчика (какие системы, где, что и т.д.).
8. Когда все развёрнуто у заказчика, сотрудников заказчика учат. В богатых компаниях это отдельные тренеры. В бедных (или в сложных предметных областях) этим занимаются бизнес-аналитики. Сотрудникам заказчика показывают презентации, рассказывают, как они будут работать, дают задания что-то сделать самостоятельно.
9. Когда все обучены, начинается приемочное тестирование. Аналитики и руководители проектов сидят и с потными ладошками молятся, чтобы ничего у заказчика не отвалилось. Если что-то отвалится, что команда переделывает. Если все хорошо, новая система вместе с документацией переходит заказчику. Этап проекта (а то и весь проект) заканчивается.
— уметь выпытывать и понятно описывать, что пользователь сделал;
— помнить (хотя бы самые часто встречающиеся) проблемы, с которыми сталкивались пользователи, и их решения.
11. Над этим процессом стоят менеджеры. Самые стрессоустойчивые ребята. Они воюют за бюджет, следят за сроками, убеждают заказчика, что он сам на такое поведение согласился (вот подпись). Менеджеры разруливают конфликты и следят за тем, чтобы выполнялись условия контракта.
Как и архитекторы, часто менеджеры приходят из аналитиков, разрабов, тестировщиков. Они сами поварились в процессе и на своей шкуре прочувствовали боль команды.
Ситуация такова: сегодня 1 октября с утра, как всегда, решил зайти на Пикабу и меня встретила вот такая картинка:
Так же при обращении к другим, некоторым сайтам появляется она.
Пс картинку поправил
Вон в чем дело, ахренеть. (((
Вот ветка с решением, таким «чайникам» как я может пригодится:
Исчерпывающее тестирование
Сколько нашли «багов» на последней картинке?
Дотошный пользователь
Ещё 1 регистратор для видеонаблюдения
Хочу рассказать про видеорегистратор который мы с друзьями писали последние 2 года, почему мы это начали и куда движемся.
Для тех кому лень читать и он хочет сразу потыкаться ссылка на сайт
Там есть ссылки на документацию с инструкциями как установить, а так же демо видео обзор возможностей.
Я работаю инфраструктурным инженером, в быту DevOps. Начинал своё путешествие в мир IT из тех. поддержки интернет провайдера, затем работал в системным администратором на местном телеканале, в тот период очень активно изучал linux, писал скрипты на баше, в силу специфики предприятия(тв канал) познакомился с такой прекрасной утилитой, как ffmpeg. Я был поражён на сколько это крутой софт для работы с любым медиа контентом. Это можно считать точной отсчёта примерно 2016-год.
Примерно 2,5 года назад мой друг открыл магазин автозапчастей и встал вопрос организации видеонаблюдения. Хотелось что бы доступ к видео был с любого устройства, архив можно скачать любого промежутка, и естественно всё бесплатно. В общем то не очень много требований.
Так повелось, что все технические вопросы он задавал мне и я пошёл изучать этот рынок. Пошёл смотреть что там есть на алиэкспресс из готовых недорогих железок. Сначала обрадовался, железные решения были очень бюджетные, но поняв, что софт там на уровне 2003-го (а на дворе был уже 2017), обязательно нужен internet explorer и использование ActiveX вкладку с алиэкспресс я закрыл )
Интерфейс всё так же напоминал 2003-год. Даже я разбирался как добавить камеру минут 10 и без документации не обошлось. Из плюсов безусловно то, что проект старый и стабильный, есть куча фишек связанных с детекцией движения и прочее, но пользоваться этим обычному пользователю не очень удобно, нужно что то интуитивное как ютуб.
Дальше я пробовал и ставил всё, что нагуглил, все решения, опенсорсные, проприетарные, любые.
В итоге из всего, что я попробовал мне понравилось 2 решения это Flussonic Watcher и shinobi.
Я рассказал о своей идее сделать собственный видеорегистратор друзьям. Ребята приняли идею с энтузиазмом. Обсудили перспективы и возможности. Да и просто было интересно сделать что то своё и классное ) И мы начали работу.
Так как разработкой мы занимались в свободное время от основной работы, темпы были черепашьи.
Но время шло, код писался, и начало вырисовываться что то, что уже можно показывать людям.
Цель была почти та же, что и при запросе моего друга с автомагазином: «можно запарковать любую ip камеру, доступ к видео с любого устройства, архив можно скачать любого промежутка, и естественно всё бесплатно«.
К определённому моменту мы поняли, что достигли этой цели и тут я хочу показать несколько демо как это выглядит.
Вот так выглядит добавление новой камеры:
Так как для транспорта мы используем ffmpeg, на входе может быть почти любой протокол.
Единственное ограничение, видео должно быть в кодеке h264, в этом кодеке пишут 100% всех современных ip камер, так что не очень то и ограничение.
Вот так выглядит работа с архивом:
Тут всё просто вам нужен любой современный linux, где можно запустить docker, или MacOS.
Есть сборки под Raspberry pi.
Возможно в будущем появится поддержка windows, но сейчас с этим проблемы.
Есть платная версия.
К сожалению мы не придумали как зарабатывать на опенсорсе. Но есть чёткая позиция, что базовый функционал всегда должен быть бесплатным.
У есть 2 версии FREE и ENTRPRISE.
У нас есть чатик у телеграме, если кто заинтересовался и есть вопросы, то вот ссылка.