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

REST-assured: полезные советы
Все примеры жизненные, они собраны из моей практики проведения code-review в более чем 50 проектах с автотестами.
Как я нашёл баг в системе Avios Travel и получил тысячи валидных баллов для авиамиль

Если вы похожи на меня, то наверняка размышляли над идеей путешествовать по миру первым классом на халяву, смотрели YouTube и знаете о таких людях.
Это история о том, как я нашел ошибку в программе вознаграждений Avios Travel, который позволяет исполнить эту мечту*.
Нагрузочное тестирование «не-HTTP». Ч.1 JMeter
В монолите вызовы методов делались внутри одного приложения — теперь, в микросервисной архитектуре, всё взаимодействие осуществляется через сеть. Соответственно, скорость обмена информации между приложениями падает вне зависимости от используемого протокола обмена.
В этой статье мы расскажем, как писать код для нагрузочного тестирования «не-HTTP» протоколов на примере Apache Thrift с помощью таких инструментов, как JMeter и Gatling (часть 2). Тестировать будем микросервис, который должен справляться с 50K RPS. С одной нагрузочной машины постараемся достичь производительности, заявленной в этом твите:
Successfully tested #thrift protocol based service with #JMeter, got 14K responses per second. Thrift API is very nice to use in TCPClient
— JMeter-Plugins.org (@jmeter_plugins) November 1, 2011
Автоматизируй мне тестирование полностью, дёшево, навсегда: анонс QA-митапа в Avito 26 августа
Митап в Москве, участие бесплатное, регистрация обязательна. И для затравки — небольшой рассказ по мотивам докладов. Ссылка на таймпад и расписание в конце поста.

Дело было вечером. Автомасштабируемый веб-сервис с балансировкой нагрузки на примере Bitrix в Google Cloud Platform
На самом деле материал применим ко многим веб-проектам. Точнее это простенький гайд по построению отказоустойчивых и распределенных приложений на базе виртуальных машин Google Compute Engine, баз Google Cloud SQL и балансировщика нагрузки Google.
Автоматизированное тестирование ботов для Telegram

Боты становятся всё сложнее, они берут на себя многие функции других каналов. Например, вместо того, чтобы звонить по телефону и слушать по полчаса записанную девушку, которая говорит тебе перейти в тоновый режим и набрать волшебную последовательность символов, всё то же самое можно сделать при помощи бота. И это будет быстрее, удобнее, гибче и дешевле.
Для некоего личного проекта мне захотелось написать бота с довольно сложной ветвящейся логикой (например, это может быть система поддержки или диагностики с глубокой вложенностью). При этом граф данной логики имеет огромное количество разветвлений. В общем, быстро стало очевидно, что без автоматизированного тестирования не обойтись — иначе что-то точно упущу из внимания. И насколько же сильно я удивился, когда узнал, что способа тестировать логику ботов просто нет!
Конечно, можно зарегистрировать дополнительного бота для тестирования, но это вариант кривой и некрасивый. Обращение ко внешнему апи во время тестов, заглушка, которая не даст общаться с ботом кому попало, ограничение на скорость отправки сообщений раз в секунду… Если слать сообщение раз в секунду, то граф из каких-то 60 вершин будет тестироваться уже больше минуты! И я уже не говорю о том, что у нас нет никакой возможности смоделировать возросшую нагрузку на бота, при которой он упрётся в ограничение в 30 сообщений в секунду… В общем, я понял, что опять придётся делать что-то своё.
Документирование #микросервисов

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

Обзор современных систем веб-рабочих столов
В виртуальном пространстве Интернета, на мой взгляд, всегда удобно иметь в своем распоряжении привычный рабочий стол, который сосредоточил бы в себе все необходимые для пользователя приложения и позволил работать с данными непосредственно в браузере. На сегодня Интернет – это одна из бурно развивающихся отраслей IT-сферы и в последнее время особую популярность приобрели облачные технологии, в частности все больший интерес получают так называемые «онлайн операционные системы».
Система веб-рабочих стола организует для пользователя набор приложений и сервисов прямо в Интернете, доступный в любом месте и на любом устройстве. Основой каждого такого рабочего стола является интерфейс — аналог проводника и рабочего стола обычной операционной системы (Windows, Mac OS, Linux).
TailSampler — паралельная отправка GET-запросов в Apache.JMeter

1. Назначение плагина «HTTP Request Tail»
Плагин упрощает загрузку встроенных ресурсов, позволяет параллельно выполнять указанные GET-запросы. Делая тест максимально близким к работе браузера по составу загружаемых ресурсов и по способу загрузки этих ресурсов.
TailSampler выручает если нужно:
- выполнить группу GET-запросов паралельно;
- выполнить 1000 GET-запросов, не создавая 1000 компонентов HTTP Request;
- протестировать сайт, активно использующий AJAX, Adobe Flash, Adobe AIR, SilverLigth, ...
Первый митап RamQA

На встрече мы услышим 3 доклада.
Ближайшие события
Создаем заглушки сервисов для интеграционного тестирования на Apache Camel (с использованием Scala DSL)

Это третья статья об использовании Scala в тестировании. Сегодня будут рассмотрены примеры использования Apache Camel для создания тестовых заглушек, а также компонентов информационной системы.
Часто возникает необходимость эмулировать работу какой-либо части системы для интеграционного тестирования, сделать заглушку или написать простой компонент интеграции. Это может быть веб-сервис, возвращающий нужные ответы, тест, наполняющий базу данных, приложение, которое считывает сообщение из очереди и возвращает результат обработки, генератор файлов и другие компоненты.
Для разовой проверки интеграции мы бы использовали простое Java или Scala приложение, сценарий Apache JMeter или SoapUI. Но нам нужна система, которая постоянно работает, отвечает на запросы и не требует действий со стороны тестировщика — запустил и забыл. Для решения такой задачи мы можем создать приложение, основанное на фреймворке Apache Сamel.
Server-less API на AWS за 15 минут

6 впечатляющих веб-технологий 2015 года
1. Electron;
2. React Native;
3. Прогрессивные веб-приложения;
4. Visual Studio Code;
5. Rollup;
6. WebAssembly.

Производительное юнит-тестирование веб-приложений на примере yii2 и codeception
Здесь и дальше под термином тесты будут подразумеваться юнит-тесты.
Разработка веб-приложений сопровождается постоянным использованием в коде базы данных. Если код работы с базой данных и код работы с результатом взаимодействия с базой данных не разделен, нам потребуется база данных в подавляющем большинстве тестов проекта. Также, если код использует методы фреймворка, нам для тестов потребуется подключить фреймворк. Пока тестов мало, всё отлично. Когда тестов становится больше, замечается проблема: скорость выполнения тестов немного напрягает. Когда время выполнения всех юнит-тестов становится больше чем минута, становится невозможным постоянно запускать все тесты. Разработчик начинает запускать только часть тестов, пытаясь уменьшить негативное влияние длительного времени работы тестов, но проблема снижения эффективности тестирования со временем будет только возрастать.
Источник проблемы находится в отсутствии четкого разделения кода работы с базой данных, кода, которому необходим фреймворк, и кода, для работы которого не нужна ни база данных, ни фреймворк.
Наша цель будет разобраться, каким образом необходимо писать тесты и код для обеспечения максимальной скорости выполнения тестов.
Google Developers Launchpad — всё что нужно для успешного старта

В рамках этой программы мы предоставляем различные возможности: как бизнес-услуги, PR-продвижение, так и технические вещи. Например, доступ к сервису Firebase, расширенный доступ к Google Maps API, к инструментам тестирования и тому подобное. Мы также даём возможность командам один на один пообщаться с экспертами Google, которые могут оценить дизайн и инфраструктуру приложения, посоветовать, как лучше реализовывать те или иные функции или оптимизировать приложение.
Программа перспективная и ряд российских проектов уже прошел или сейчас проходит через неё. Вместе с проектом AppTractor.ru мы отобрали шесть участников Launchpad и поговорили с ними об их работе.
Альтернативная классификация багов
Как в Postman использовать данные из файла

В Postman есть возможность загружать данные из файла — указал в запросе «возьми имя из файла», сделал файл на 100 имен, и вуаля! Запускаешь 1 запрос, а он выполняется 100 раз с разными данными.
Так удобно готовить тестовые данные. Заранее прикинул классы эквивалентности, и создал всё одним махом. Нужно исправить? Вот он, файлик, в формате csv или json — легко читается, легко исправляется.
А вот что с этим файликом делать дальше? Как сказать постману, что мы хотим подставить эти данные в запрос или в автотест? Где какой синтаксис использовать? Об этом и поговорим в статье на примере системы Users.
Вклад авторов
phillennium 746.0olegchir 471.0Molechka 429.0w9w 389.0sound_right 388.0Gorodnya 374.0moskowsky 337.0nizkopal 309.0kmoseenk 282.0rikki_tikki 268.0