Тестирование веб-сервисов *

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

Материал подготовлен на основе выступления разработчика Positive Technologies Ивана Цыганова на конференции Moscow Python Conf (слайды, видео).

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

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

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

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

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

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

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

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

Специалисты по безопасности из Google обнаружили неприятный баг, чем-то похожий на приснопамятную уязвимость Heartbleed в OpenSSL. Она тоже выдаёт любому желающему криптографические ключи, а также куки, пароли, содержимое POST-запросов с личными данными, кредитные карты, ключи API и другое содержимое чужих сессий.

Здесь уязвимость ограничена всего одним сервис-провайдером, пусть и таким крупным как Cloudflare. Но в определённом смысле этот баг Cloudbleed хуже, чем Heartbleed, потому что утечка данных происходит спонтанно. Эти страницы рутинно скачиваются краулерами, индексируются поисковыми системами, до сих пор хранятся в архивах веб-страниц и в кэше Google.

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

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

В статье "Tarantool: Хороший, Плохой, Злой" был описан простой сервис голосования с действующим примером на PHP. Мы увидели, как легко подключить и использовать эту NoSQL базу данных в своих программах. Однако остался без внимания один важный вопрос – зачем это? Какой выигрыш в производительности дает использование NoSQL по сравнению с обычными базами данных?

Додо сказал:
— Правильность формы несущественна! А потом расставил всех без всякого порядка по кругу. Никто не подавал команды — все побежали, когда захотели.

Л.Кэрролл, «Приключения Алисы в стране чудес»

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



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

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

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

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

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

В последнее время появилось огромное количество фреймворков которые решают задачи тестирования: jest, mocha, sinon, chai, jasmine, список можно продолжать долго, но даже имея такую свободу выбора инструментов для написания тестов остаются кейсы которые сложно протестировать.

О том как протестировать то что в общем может быть untestable пойдет речь далее.

Что делать, когда нужно донести клиенту информацию? И нет, речь идет не о надоедливых рассылках об акциях и спецпредложениях. Если вот действительно суть услуг в том, чтобы клиент вовремя что-то узнал? Сервис мониторинга сайтов ХостТрекер, в чьи обязанности входит немедленное оповещение клиентов о возникших проблемах, делится опытом. Окунуться в возникающие проблемы и запросы можно ниже.

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

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

Пара слов о себе: я тестировщик, имела опыт работы в проектах разного масштаба, была единственным тестировщиком на проекте и работала в командах, в которых использовались разные подходы и методологии. По моему опыту, работать по Lean Startup — это круто, но тут есть и подводные камни для тестирования, о которых неплохо знать заранее.

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

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

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

Система веб-рабочих стола организует для пользователя набор приложений и сервисов прямо в Интернете, доступный в любом месте и на любом устройстве. Основой каждого такого рабочего стола является интерфейс — аналог проводника и рабочего стола обычной операционной системы (Windows, Mac OS, Linux).

В мире NodeJS творится полный хаос, каждый день появляются новые фреймворки, размеры зависимостей обычного package.json вырастают на сотни мегабайт, а библиотека, которую вы добавили в проект ещё вчера, сегодня уже морально устарела. И если в мире фронтенд фреймворков уже наметились явные фавориты: AngularJS, React, Vue, Ember, то что для приемочного тестирования совершенно непонятно. Каждый фреймворк предоставляет свой синтаксис и свои крутые фичи, а также у каждого есть свой характерный набор проблем. Например, каждый по-своему реализует взаимодействие с браузером, каждый по разному борется с асинхронностью.

Ох, эта пресловутая асинхронность...

Обычным подходом в .NET к тестированию приложений работающих с базой данных является внедрение зависимостей (Dependency Injection). Предлагается отделить код работающий с базой, от основной логики путем создания абстракции, которую в дальнейшем можно подменить в тестах. Это очень мощный и гибкий подход, который тем не менее имеет некоторые недостатки — увеличение сложности, разделение логики, взрывной рост количества типов. Подробнее в предыдущей статье Что-то не то с тестированием в .NET (Java и т.д.) или в Wiki/Dependency Injection.

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

Друзья, сегодня я расскажу вам историю о том, как просто и изящно решить проблему еnd-to-еnd тестирования web-сервиса доставки кофе с помощью нового open source тестового фреймворка. Мы проведем проверку не только работы сайта, но и менеджеров и даже службы доставки, к тому же потратим на это минимум усилий и времени. А в качестве бонуса за приложенные усилия получим кружечку горячего кофе прямо в руки. Всех любителей приключений прошу под кат…

Мы собрали форк MySQL от Facebook с движком RocksDB вместо InnoDB и потестировали его с реальными приложениями: Drupal, Wordpress, Redmine.

Это офигенная штука. При низкой нагрузке выигрыш маленький, десятки процентов. Зато при высокой нагрузке выигрыш в разы. Когда RocksDB добавят в стабильный релиз в MariaDB, я уверен, что в течение полугода половина народа перейдет с InnoDB на RocksDB. Особенно, небольшие сайты на cloud/VPS и выделенных серверах.

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

Я собрал в статью результаты тестирования реальных сценариев Redmine, добавил анализ результатов и выводы. Redmine на MySQL с RocksDB оказался быстрее, чем с InnoDB — от 20% при минимальной нагрузке до 3 раз при максимальной. Позже подготовлю материалы по Drupal и другим PHP-приложениям.

Вы сможете проверить работу MyRocks и самостоятельно — в конце статьи есть ссылки на инсталляторы и виртуальные машины с LAMP/LEMP/Ruby стеками, собранные с MyRocks вместо MySQL.