Какие тесты наиболее эффективны с точки зрения автоматизации

Home

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

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

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

«Когда начинать автоматизировать тесты?»

Мой краткий ответ на этот вопрос зачастую звучит так – «Найдите время на запуск процессов тест-автоматизации прямо сейчас». Ранее я бы сказал «как можно раньше», но теперь понял, что этот ответ открыт для интерпретаций. Значит ли это, что команде нужно бросить все и заняться тестированием? Или это значит, что нужно подождать, пока не появится возможность для работы над ним? Когда есть недопонимания, вопрос откладывается, и рано или поздно о нем забывают.

Однако «прямо сейчас» также не означает прямо сию секунду – поэтому ответ все еще туманен. Конечно, предпочтительно заниматься тестированием со старта разработки продукта (или максимально близко к старту), но для большинства компаний этот вариант не подходит. Как упомянуто ранее, у стартапа, как правило, есть вещи куда важнее, отъедающие тонны ресурсов. Разработка и запуск тест-автоматизации в начале требует времени и сил – в стартапе, пытающемся вырасти в компанию, нет ни того, ни другого.

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

Итак, когда же начинать тест-автоматизацию?

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

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

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

Не все автоматизированные тесты равноценны

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

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

Юнит-тестирование

Когда внедрять: как только началась разработка

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

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

API-тестирование

Когда внедрять: как только у тестировщиков появляется доступ к API в тест/стейдж-окружении

Большинство современных приложений включают в свою экосистему какую-либо разновидность API. Иногда это внутренний API для взаимодействия с другими приложениями, а иногда – публичный API, доступный для клиентов извне организации. Вне зависимости от типа доступа, у API, как правило, высокая бизнес-ценность, и они требуют долгосрочной стабильности. Любой API выиграет от автоматизированного тестирование, которое внедряется, как только команда тестирования получает доступ к API в тест/стейдж-окружении.

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

End-to-end тестирование

Когда внедрять: как только приложение достаточно стабильно для деплоя на прод, или уже находится на проде

В то время как такие формы тестирования, как юнит, функциональное и API, выигрывают от раннего внедрения, end-to-end тесты – их полная противоположность. Эти тесты обширнее и значительно медленнее при прогоне, чем большинство API-тестов. Это означает, что end-to-end тесты дорого обновлять и поддерживать – не говоря о нагрузке на команду тестирования, когда что-то идет не так. Когда ваше приложение часто меняется, что норма для компаний на ранних этапах, вы сведете себя с ума, пытаясь угнаться за ним со своими end-to-end тестами.

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

Нагрузочное тестирование / тестирование производительности

Когда внедрять: только в том случае, если компании это необходимо

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

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

Ручное тестирование

Когда внедрять: до начала разработки

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

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

Заключение

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

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

Автоматизированные тесты принимают множество форм, и у каждой есть определенные достоинства. К примеру, юнит-тесты быстры в исполнении и передаче обратной связи в ходе разработки, а end-to-end тесты лучше работают на выявление регрессий в полностью готовом продукте. Типами тестирования, освещенными в статье, тестирование в небольших компаниях не ограничивается. Однако идея тут в том, что не все тесты равноценны. Работа над правильными для текущего момента тестами эффективнее повысит качество вашего приложения, если сравнивать с попытками сделать все и сразу.

Автоматизированное тестирование back-end функционала с помощью программы jMeter Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Моисеев Д.А., Моисеев А.В.

Актуальность и цели. Обеспечение качества любого продукта в настоящее время невозможно переоценить. Для того, чтобы продукт полностью соответствовал всем ожиданиям пользователя, необходимо автоматизировать не только front-end продукта, но и его внутреннюю часть back-enda. Материалы и методы. Для качественного тестирования программного обеспечения необходимо использовать все накопленные знания и методологии тестирования, в том числе тестирование back-enda любого продукта. Для автоматизации такого тестирования успешно используется программа jMeter . Результаты. Предложенный процесс автоматизации тестирования back-enda программного обеспечения является удобным во многих смыслах. Благодаря автоматизации с помощью программы jMeter тестирование нового функционала или исправление старых кейсов удобно и не времязатратно. Адекватность данной схемы тестирования программного обеспечения проверена экспериментально. Выводы. Автоматизация тестирования back-enda любого продукта является гарантией того, что пользователь или покупатель останутся им довольны. Повышение качество продукции и качественного тестирования является одной из важнейших задач, которая сейчас стоит перед любым производителем.

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Моисеев Д.А., Моисеев А.В.

Компьютерная реализация методов современной неравновесной термодинамики в виде программного модуля
Кавитационные технологии в инженерии поверхности деталей машин
Методология и процесс ручного тестирования

Аналитический обзор средств автоматизации тестирования производительности применительно к системам мониторинга

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

Текст научной работы на тему «Автоматизированное тестирование back-end функционала с помощью программы jMeter»

Рисунок 4 — Зависимость величины эффективного радиуса устья МТ частот ультразвуковых колебаний Ю :

для разных 1 — 3-104 с-

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

1. Мухин, В. С. Инженерия поверхности деталей машин / В. С. Мухин, А. М. Смыслов //Вестник УГАТУ. — 2009. — Т. 12, №4 (33). — С. 106-112.

2. Bin Shen, Ajay P. Malshe, Parash Kalita, Albert J. Shih. Performance of novel Mo S2 nanopar-ticles based grinding fluids in minimum quantity lubrication grinding — 2008 — V. 36 — p. p. 357364.

3. Долматов, В. Ю. Детонационные наноалмазы: синтез, строение, свойства и применение / В. Ю. Долматов // Успехи химии. — 2007. — Т. 76, №4. — С. 375-397.

4. Андриевский, Р. А. Размерные эффекты в нанокристаллических материалах / Р. А. Андриевский, А. М. Глезер // Механические и физические свойства // Физика металлов и металловедение. — 2000. -Т. 89, № 1. — С. 91-112.

Моисеев Д.А., Моисеев А.В.

ФГБОУ ВО «Пензенский государственный университет», Пенза, Россия

АВТОМАТИЗИРОВАННОЕ ТЕСТИРОВАНИЕ BACK-END ФУНКЦИОНАЛА С ПОМОЩЬЮ ПРОГРАММЫ JMETER

Актуальность и цели.

Обеспечение качества любого продукта в настоящее время невозможно переоценить. Для того, чтобы продукт полностью соответствовал всем ожиданиям пользователя, необходимо автоматизировать не только front-end продукта, но и его внутреннюю часть — back-enda.

Материалы и методы.

Для качественного тестирования программного обеспечения необходимо использовать все накопленные знания и методологии тестирования, в том числе тестирование back-enda любого продукта. Для автоматизации такого тестирования успешно используется программа jMeter. Результаты.

Предложенный процесс автоматизации тестирования back-enda программного обеспечения является удобным во многих смыслах. Благодаря автоматизации с помощью программы^ jMeter тестирование нового функционала или исправление старых кейсов удобно и не времязатратно. Адекватность данной схемы тестирования программного обеспечения проверена экспериментально. Выводы.

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

АВТОМАТИЗИРОВАННОЕ ТЕСТИРОВАНИЕ, BACK-END, JMETER, РЕГУЛЯРНЫЕ ВЫРАЖЕНИЯ

Почти все современные web-сайты разрабатываются, используя подход «клиент-сервер» [1]. Суть подхода заключается в том, что есть как бы 2 части сайта. Первая часть — клиентская. Это то, что видит конкретный пользователь у себя в браузере после того, как перешел по адресу сайта. Эту часть можно назвать так же пользовательской. В большинстве случаев эта часть только отображает те данные, которые приходят ей с сервера, отображая их в нужном месте, нужном стиле и в нужном формате. Вторая часть — серверная. По названию можно понять, что эта часть приложения находиться на сервере, единая для всего сайта. В серверную часть поступают все запросы от клиентской части и сервер должен по этому запросу вернуть нужные данные, в нужном формате. Общая схема работы данного подхода приведена на рисунке 1.

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

без дополнительных усилий увидеть какие данные на сервер пришли, и какие он отдал.

Рисунок 1 — Архитектура «Клиент-сервер»

Именно поэтому для тестирования серверной части (или back-endа[4], как мы будем называть ее дальше) периодически используются внешние программы или утилиты. Наиболее удобной программой для себя я считаю программу jMeter. Именно о тестировании с помощью этой программы я и хочу рассказать. Так как взаимодействие двух приложений меду собой всегда происходит через back-

end, то и интеграционные тесты весьма эффективны с помощью программы jMeter.

Работа серверной части (back-and части приложения)

Общение между front-end[4] (клиентской части) и back-and (серверной части) происходит с помощью запросов. В момент, когда пользователь вызывает какой-либо функционал, которые требует обработки на сервере, на сервер уходит запрос с нужными данными. Пример такого запроса: http:///auth/login

Этот запрос обрабатывается сервером и возвращает на front ответ с нужными данными. Пример ответа от сервера:

Соответственно для корректного тестирования back-enda[4] надо проверять и запросы, которые туда уходят и ответы, которые сервер возвращает.

Взаимодействие компонентов front-end и backend может осуществляться с помощью нескольких архитектур[4]. Самые популярные архитектуры это: REST[2] SOAP[3]

Так как именно первый сейчас используется в большей степени, то тестирование web-сайта именно с этой архитектурой мы и рассмотрим.

Архитектура REST позволяет передавать не только запрос и тело запроса, но и идентификатор запроса. Идентификаторы запроса бывают следующими:

GET — получение ресурса POST — создание ресурса PUT — обновление ресурса DELETE — удаление ресурса

Таким образом полный запрос будет выглядеть так:

POST http:///auth/login Программа jMeter

Для тестирования back-enda любого сайта существует огромное множество различных программ.

Самые популярные из них это программы, которые позволяют отправлять нужный запрос с необходимыми данными на проверяемый сайт. Это такие программы как Postman, Fiddler, Rested (плагин для Google Chrome) и другие. Они все обладают достаточно мощным инструментарием для отправки запросов, однако у них есть существенный минус. В них нельзя выстроить последовательные вызовы запросов. Таким образом в них не получиться написать полноценный сценарий тестирования back-enda, который, например, можно просто запустить раз в регресс. Именно из-за этого минуса я и решил для этих целей использовать программу jMeter.

Программа jMeter изначально была разработана для проведения нагрузочных тестов. Ее смысл в том, что она по заданному сценарию и параметрам с помощью запросов генерирует необходимую для проверки пользовательскую активность на сайт. Однако, для проверки именно сервисных тестов достаточно сгенерировать нагрузку одного пользователя, который будет проверять всю функциональность сайта. Именно возможность выстраивания последовательных тестов и последовательного вызова разных запросов друг за другом является ключевым параметром при выборе jMeter именно для проверки back-end кода сайта.

Примеры проверки back-enda с помощью программы jMeter

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

В первом примере рассмотрим проверку запроса на поиск информации в цифровой системе google.

Для этого я в программе jMeter создал группу тестов с помощью компонента thread group с названием «Гугл тест», и в нем создал http request «Запрос на поиск». Так же я добавил инструмент, с помощью которого можно следить за успешностью/не успешностью пройденных тестов view result tree. В программе это выглядит так

Рисунок 2 — Интерфейс программы jMeter с добавленными компонентам thread group, http request,

view result tree

Стоит остановиться на параметрах компонента http request. Основные параметры, которые нам понадобятся:

Server Name or IP

Server Name or IP — сюда надо вставить непосредственно IP или адрес сайта, который мы собираемся тестировать. В нашем случае это «www.google.com»

Method — этот параметр отвечает за идентификатор запроса, который мы хотим отправить

(GET/POST/PUT/DELETE). В нашем случае это Get запрос.

Path — дополнительная часть запроса, которая в основном используется для указания параметров запроса. В нашем случае это

«search?newwindow=1&hl=ru&source=hp&ei=9ubpWpyU NaGy6ATTwaCYAg&q=%D1%82%D0%B5%D1%81%D1%82%D0%B8 %D1%8 0%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5&oq=% D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%8 0%D0%BE%D0%B2 %D0%B0%D0%BD%D0%B8%D0%B5» ( Параметры взяты из реального запроса в google).

Name — Имя http request. В нашем случае «Запрос на поиск»

Рисунок 3 Интерфейс компонента http request c заполненными параметрами

Теперь, когда запрос написан надо добавить проверки, через которые мы убедимся, что наш запрос отобразился корректно. Для этого в компонент http request добавим так называемые Listeners, то есть слушателей. Допустим, что для этой проверки нам надо, что бы в ответе на запрос было слово «тестирование», потому что именно по этому слову мы и выполняем запрос и сам он выполнялся не дольше 1 секунды. Добавим компоненты Response Assertion (сравнение ответа) и Duration Assertion (сравнение длительности). В Response Assertion добавим слово тестирование, а в Duration Assertion добавим 1000 мс.

Теперь необходимо запустить наш тест. Зайдем в меню Run и нажмем там Start. Что бы проследить за процессом выполнения тестов необходимо нажать на компонент view result tree. Там мы увидим наши тесты и там же можно проверить прошли они или нет. Если мы запустим с теми параметрами, которые мы указали выше, то тест должен быть пройден.

Если же мы допустим в response assertion введем, например, слово «суп» или в duration assertion 10 мс, то мы увидим, что наш тест будет отображаться как не пройденный.

Еще одним замечательный свойством jMeter является то, что из ответа любого запроса с помощью переменных можно вытащить любую информацию. Это бывает очень полезно для того, чтобы выстроить тест план, в котором для проверки подставляются не стандартные данные, а либо случайные данные, либо данные, которые пришли с предыдущих запросах. В следующем примере мы проверим, что в ответе на запрос в google по слову «Тестирование» будет ссылка на сайт www.protesting.ru. Для этого в запрос мы добавим компонент Regular Expression Extractor, который с помощью регулярного выражения запишет в нужную нам переменную из ответа нужный сайт.

Рисунок 4 — Интерфейс компонента Response Assertion c заполненными параметрами

Рисунок 5 — Интерфейс компонента Duration Assertion c заполненными параметрами

Рисунок 6 — Интерфейс компонента Regular Expression Extractor c заполненными параметрами

/ Apache JMeter (3.3 MB0B647) — U

Рисунок 6 -. Интерфейс компонента http request для перехода на protesting c заполненными

Теперь добавим еще один http request, где в нашу переменную, в которой будет содержаться свойстве server name напишем оставшаяся часть адреса на нужную страницу.

«www.protesting.ru», а в свойство path добавим

Теперь нажнем на Run-Start и перейдя в компонент view result tree убедимся, что запрос корректно отработал, отобразив нужный сайт.

В данной статье мы рассмотрели, что такое back-end и front-end web — сайтов. Рассказали про наиболее популярные архитектуры для написания back-enda проекта. Выяснили для чего именно тестировать back-end и почему это является очень

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

Валерий Коржов. Многоуровневые системы клиент-сервер. Издательство «Открытые системы», 1997,

Джон Фландерс. Введение в службы RESTful с использованием WCF. MSDN Magazine, 2009, 105 с. Бенот Маршал, «Soapbox: почему я использую SOAP», IBM, 2001, 13 с.

Бин Мухаммад, Рашид. «Примечание операционных систем», Kent State University, 2016, 239 с.

Старостин1 И.Е. , Степанкин2 А. Г.

1ООО «Экспериментальная мастерская «НаукаСофт», Москва, Россия

2Федеральное государственное унитарное предприятие «Научно-исследовательский институт стандартизации и унификации», Москва, Россия

КОМПЬЮТЕРНАЯ РЕАЛИЗАЦИЯ МЕТОДОВ СОВРЕМЕННОЙ НЕРАВНОВЕСНОЙ ТЕРМОДИНАМИКИ В ВИДЕ ПРОГРАММНОГО МОДУЛЯ

Моделирование и анализ реальных физико-химических систем является важнейшей задачей, имеющей практическое применение. Однако ввиду большого количества реальных физико-химических процессов в реальных технических системах очевидна сложность задач моделирования реальных физико-химических систем. Этим и обусловлена необходимость компьютерной реализации методов современной неравновесной термодинамики, являющимся макроскопическим подходом анализа и моделирования динамики реальных физико-химических систем. Этот подход имеет практическое применение. Ранее авторами в рамках современной неравновесной термодинамики был разработан потенциально-потоковый формализм построения системы уравнений, описывающий физико-химические процессы в произвольной заданной физико-химической системе. Этот формализм применим в общем случае макроскопических физико-химических систем, в том числе и технических объектов, характеризующихся протеканием в них физико-химических процессов, живых клеток, процессов в природе. Поэтому в настоящей работе речь пойдет о компьютерной реализации методов современной неравновесной термодинамики, в том числе и потенциально-потокового формализма. Эта реализация представляет собой библиотеку, которая может быть расширена до модулей расширения моделирующих пакетов (MatLab, Comcol Multiphysics, LabView, и т. д.).

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

ФИЗИКО-ХИМИЧЕСКИЕ ПРОЦЕССЫ, СОВРЕМЕННАЯ НЕРАВНОВЕСНАЯ ТЕРМОДИНАМИКА, ПОТЕНЦИАЛЬНО-ПОТОКОВЫЙ МЕТОД, ПРОГРАММНАЯ РЕАЛИЗАЦИЯ, БИБЛИОТЕКА РАСШИРЕНИЯ

Моделирование и анализ динамики реальных физико-химических процессов является важнейшей задачей, имеющей практическое значение для проектирования, управления, диагностики технических систем, анализе физико-химических процессов в природе и в живых организмах. Для описания и математического моделирования этих подходов в общем случае может быть использована современная неравновесная термодинамика (макроскопический подход описания реальных физико-химических процессов) [1 — 5], которая имеет широкое практическое применение [1 — 4].

В работе [5] разработан в рамках современной неравновесной термодинамики формализм описания в общем случае реальных физико-химических процессов. В соответствие с этим формализмом формируется список этих процессов, записываются уравнения баланса этих процессов, определяются через потенциалы взаимодействия термодинамические силы, движущие эти процессы, а также кинетическая матрица — шкала кинетических свойств неравновесных систем [5]. Зная термодинамические силы и кинетические свойства, определяются скорости протекания физико-химических процессов, а затем скорости изменения координат состояния [5]. Так получается система дифференциальных уравнений, описывающая реальные процессы. Эта система решается методами, описанными в [6, 7].

Однако реальные системы (технические системы, живые клетки, природные системы, и т.д.) являются сложными системами. Поэтому компьютерная реализация формализма описания физико-химических процессов, изложенного в [5], является актуальной задачей. В настоящее время существует множество информационных систем, позволяющих выполнять математические расчеты по заданным уравнениям (например, MatLab, Scilab, Python) [8, 9], имитировать системы (например, Simulink, Scicos, Xcos) [10]. К этим системам можно подключать модули расширения, позволяющие решать те или иные задачи [8 — 10]. Однако среди этих модулей расширения отсутствуют модули, реализующие формализм, описанный в [5]. Поэтому целью этой статьи — разработка архитектуры модуля, реализующего этот формализм.

Система классов, реализующая формализм современной неравновесной термодинамики

Рассматриваемая в настоящей работе библиотека, реализующая формализм современной неравновесной термодинамики, описанный в [5], представляет собой библиотеку классов. Каждый класс библиотеки представляет собой реализацию сущностей современной неравновесной термодинамики [1 — 5].

С точки зрения программирования структура расчетной схемы произвольной физико-химической представляет собой соответствующий структурный тип данных (на языке программирования С (Си) это структура, на С++ — это класс), показанный на рисунке 1.

Структурные типы данных координат состояния и энергетических степеней свободы, входящие в структурный тип данных физико-химической системы (рисунок 1), показаны на рисунке 2. Структурный тип данных энергетических степеней свободы имеет массив ссылок на скорости изменения соответствующих координат состояния (рисунок 2б), входящих в структурный тип данных координат состояния (рисунок 2а). Структурные типы данных процессов (кроме процессов теплообмена), входящие в структурный тип данных физико-химических систем (рисунок 1), имеют массивы ссылок (рисунок 3в) на: термодинамические силы перекрестных процессов;

скорости изменения сопряженных координат состояния и суммарные потенциалы взаимодействия, обусловленные энергетическим взаимодействием между подфазами [5], сопряженные этим координатам состояния;

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

В типе данных процессов ссылки на сопряженные процессу потенциалы взаимодействия и координаты состояния входят в структурный тип данных сопряженных координат состояния (рисунок 3а).

Какие виды тестирования лучше автоматизировать?

Иногда ручного тестирования недостаточно, чтобы обеспечить качество, особенно когда речь идет о сложных программных продуктах и многокомпонентном ПО. К тому же, современные IT-компании, адаптируясь к динамичным потребностям рынка, ускоряют разработку, поэтому и на тестирование отводится все меньше и меньше времени. В результате автоматизация играет все большую роль, ведь она позволяет ускорить QA-процессы. Давайте посмотрим, какие виды тестирования следует автоматизировать в первую очередь.

Регрессионное тестирование

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

Автоматизация хорошо себя зарекомендовала и в том случае, когда тестировщику надо выполнять одинаковые действия, но каждый раз с разными данными. Все данные можно собрать в одной базе, а скрипты станут автоматически использовать эту информацию при проведении тестов. Кстати, это уже не что иное, как DDT-подход к тестированию (data-driven testing).

Кроссбраузерное и кроссплатформенное тестирование

Автоматизация способна повысить эффективность и таких видов тестирования, как кроссплатформенное и кроссбраузерное. Тут все просто: одинаковые сценарии автоматизированных тестов используют на разных платформах.

Тестирование локализации

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

Исследование производительности, нагрузочное и стресс-тестирование

В наше время performance testing (исследование производительности), а также нагрузочное тестирование и стресс-тестирование почти всегда автоматизируются. Существует ряд инструментов для автоматизации (JMeter, Gatling, Tsung), позволяющих воспроизводить разные условия, в том числе и «на грани фола», то есть условия, которые могут вызвать проблемы с производительностью программного приложения. Используя автоматизированные тесты, вы смоделируете нехватку оперативной памяти и другие ситуации, ну и, что немаловажно, сможете зафиксировать реакцию программного обеспечения на эти ситуации.

Когда A/B-тесты не подходят: 6 альтернативных способов тестирования продуктовых гипотез

Что делать, когда хорошо известный A/B-тест использовать нельзя, а принять решение Go/No-Go все же надо? Правильно — тестировать альтернативы. В тексте собрали несколько способов, а также примеры из практики.

Привет! Я Аля — продакт-менеджер выделенных серверов Selectel. Люблю быстрое тестирование гипотез (и да, верю, что в B2B это возможно), общаться с целевой аудиторией и чистить бэклог.

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

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

Ухудшающий A/B тест

Что? A/B-тест, когда я обещала обойтись без A/B-тестов?

Дело в том, что я хочу выделить именно ухудшающий A/B-тест. Он менее понятен и не так распространен. Хотя для ряда кейсов это, пожалуй, лучший метод тестирования продуктовой гипотезы.

В чем суть?

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

Когда стоит использовать?

В случае, если хотим оценить важность определенного свойства продукта. При этом для классического A/B-теста разработка будет слишком долгой и дорогой, а для принятия решения без эксперимента недостаточно данных. Иными словами: уверенность базируется на «это же логично»‎.

Например, если нужно оценить:

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

Примеры использования

Из личного опыта:

Однажды неумышленно (не знала еще тогда, что метод так называется) с командой провели ухудшающий эксперимент в API-first приложении для биотеха. Думали, что пользователи чувствительны к скорости загрузки данных и ее обязательно нужно повышать. Оказалось, что скорость, которую увеличить было бы не самой тривиальной задачей, не так важна. Куда важней прозрачный процесс загрузки и понятные сообщения ошибок с инструкцией о том, что делать дальше.

Ухудшающий A/B-тест помог сфокусироваться на вещах, которые действительно важны пользователям, и не потратить много ресурсов на масштабный рефакторинг.

• Текст на Хабре об опыте Ozon Tech.
• Еще больше примеров в тексте от GoPractice. Кстати, рекомендую этот ресурс к изучению.

Заметки на полях для тех, кто решит протестировать этот способ

На мой взгляд, при всей своей простоте и дешевизне — это один из самых недооцененных методов проверки гипотезы.

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

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

Снижаем цены на выделенные серверы в реальном времени

Арендуйте готовые конфигурации или предложите свой вариант.

MVP: несколько видов

Прежде чем я дам определение MVP, сделаю небольшое лирическое отступление.

Часто вижу, что в текстах и видео по продакт-менеджменту говорят про MVP примерно одно и то же: это первая версия работающего продукта. В итоге складывается впечатление, что обязательно нужно потратить ресурсы на разработку и создать хорошую архитектуру решения — ведь на базе первой версии будут построены вторая, третья и все последующие. Также важно не забыть про автоматизации — иначе опыт пользователей будет испорчен, и мы потеряем его навсегда.И тут я хочу обратиться к источнику: MVP (Minimum Viable Product) — это версия нового продукта, которая позволяет команде собрать максимальное количество проверенных знаний о клиентах с наименьшими усилиями.

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

Еще один подводный камень, который ожидает продакта — метод не дает четкого определения слову minimal. Поэтому дать оценить его вам нужно будет самостоятельно.

Итак, несколько методов из семейства MVP.

Concierge MVP

В чем суть?

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

Когда стоит использовать?

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

Примеры использования

Мы в Selectel любим этот метод и часто его используем. Вот один из свежих примеров.

Прежде чем ввести новый тариф для аренды выделенного сервера — резервирование на 12 месяцев с помесячной оплатой и скидкой 10% — мы показывали пользователям такую возможность в секции с тарифами. Однако получение этого бенефита было доступно только через менеджера.

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

Еще один пример — в ближайшее время мы планируем запуск аренды LUN СХД (это одно из решений для хранения данных). И в первой версии процесс будет максимально ручным — клиент оставит нам заявку, а инженеры обрабатывают ее вручную, внося изменения в ряд систем. Вполне возможно, что в будущем у нас появится автоматизация. Ранее мы успешно использовали такой подход при запуске файлового хранилища.

Другие примеры использования:

• Airbnb — пожалуй, самый известный пример использования Concierge MVP.
• Food on the Table — сервис доставки готовой еды, который начинал как Concierge MVP. С небольшой презентацией от основателя сервиса можно ознакомиться по ссылке.

Заметки на полях для тех, кто решит протестировать этот способ

Concierge MVP в большинстве случаев требует разработки. Ее объем зависит от продукта, но в большинстве случаев это срок от 2 недель до 3-4 месяцев. Поэтому советую на старте почаще задавать себе вопрос: «А только ли это must have?»

Fake door

В чем суть?

В этом методе делаем вид, что функциональность уже доступна в продукте за счет добавления различных элементов — например, кнопок, форм и ссылок.

Fake Door — это не темный паттерн (dark pattern), когда обманным путем пользователя склоняют к покупке или совершению другого целевого действия.

Fake Door имеет довольно простой механизм работы:

1. Пользователь видит новую фичу в интерфейсе. Например, раздел, кнопку или баннер в продукте. При этом саму фичу мы не разрабатываем.
2. Пользователь пробует воспользоваться новой фичей. Для этого он нажимает на кнопку или совершает другое действие. Оно обязательно должно быть целевым и позволить нам оценить потребность. В процессе взаимодействия с фичей пользователь понимает, что функциональность недоступна. Например, предлагаем клиенту собрать кастомный скейт в конструкторе, но не даем сделать заказ.
3. После благодарим пользователя за интерес. Сообщаем, что функциональность еще в разработке и пока недоступна. Также можем предложить стать бета-пользователем или поучаствовать в интервью, чтобы рассказать про свою потребность подробнее.

Когда стоит использовать?

Fake Door позволяет проверить потребность в фиче в рабочих условиях, а также узнать о предпочтения аудитории.

Примеры использования

В Selectel мы запускали Fake Door для тестирования спроса на почасовую оплату выделенных серверов. Для этого мы добавили на сайт и в панель управления новый тариф при заказе. Когда пользователь пытался оформить заказ с новыми условиями, сообщали, что такой тариф еще недоступен и приглашали на интервью.

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

Другие примеры

• История из далекого 2011 года про запуск компании Buffer (решение для менеджмента социальных сетей для малого бизнеса), которая по сути началась с Fake door.
• Пример от Financial Times — по ссылке ищите секцию «6. Use fake doors where possible and appropriate»).

Заметки на полях для тех, кто решит протестировать этот способ

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

Landing Page MVP

В чем суть?

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

Когда стоит использовать?

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

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

Примеры использования

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

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

Заметки на полях для тех, кто решит протестировать этот способ

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

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

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

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

Специальное предложение

Для работы с этим методом нужно сформировать специальное предложение, которое должно иметь ограничения (как минимум по времени). Например, в рамках акции снижаем цены на 30% с декабря по январь.

Механика работы может быть следующая:

• Выгружаем исторические данные по нужным нам метрикам и строим прогноз — что бы было, если бы мы не запустили спецпредложение.
• Строим прогноз с учетом запуска спецпредложения и прогноза изменения без спецпредложения (берем из шага 1).
• Запускаем спецпредложение.
• Анализируем результаты: если результаты выше прогноза с акцией — вносим изменение, если ниже — отказываемся от него.

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

Когда стоит использовать?

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

Пример использования

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

1. Мы не можем показывать разные цены разным посетителям сайта, поэтому отмели вариант с A/B-тестом.
2. Не хотели снижать стрит-прайс, чтобы снизить негатив в случае неудачного эксперимента и отката цен.
3. Планировали запустить в сжатые сроки, поэтому рассматривали варианты с минимальным количеством разработки или еще лучше — ее отсутствием.

Заметки на полях для тех, кто решит протестировать этот способ

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

Конечно, если бы у меня была возможность запустить A/B-тест, то не использовала бы спецпредложения, акции и другие похожие механики для теста гипотез.

Прототип

В чем суть?

Для теста этого метода нужно создать прототип работающего продукта или фичи. Примеры прототипов — бумажные, кликабельные прототипы в Figma, таблички с расчетами в Excel и другие.

Когда стоит использовать?

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

Примеры использования
Мы в Selectel обычно готовим несколько вариантов пользовательских интерфейсов в виде прототипов Figma, а потом тестируем в рамках usability-тестирований. Из недавнего — проверяли несколько вариантов слития вкладок «Собрать сервер» и «Собрать сервер с GPU» конфигуратора серверов в одну (о том, что пользователи испытывают неудобство, мы узнали из другого исследования). По итогу получилось выявить решение-победитель, которое в ближайшее время планируем реализовать.

Заметки на полях для тех, кто решит протестировать этот способ

Несмотря на простоту и максимальную дешевизну, этот метод не позволяет предсказать влияние на продуктовые метрики. Если такая связь все же важна, советую использовать прототип как отбор пользователей. Цель — найти наиболее перспективных кандидатов для дальнейшего A/B-теста.

Резюме

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

Присоединяйтесь к команде Selectel

Ищем единомышленников, чтобы делать команды и процессы еще круче.