viagra super force

+7(495) 123-XXXX  г. Москва

Выпуски журналов

  • Серия
  • Серия
  • Серия
  • Серия
  • Журнал
  • Журнал
  • Журнал
  • Журнал

И.С. Скороходов,  (Магистрант, ФГАОУ ВО «Национальный исследовательский ядерный университет «МИФИ»)

А.Н. Тихомирова,  (К.т.н., доцент, ФГАОУ ВО «Национальный исследовательский ядерный университет «МИФИ»)

Серия «Естественные и Технические науки» # ИЮНЬ  2016

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

Ключевые слова: Интеграционное тестирование, непрерывная интеграция, непрерывное развертывание, экспериментальное развертывание.

 

Введение

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

Традиционно существует два основных подхода проведения тестирования системы:

  • ручное тестирование мануальными QA-специалистами [2];
  • автоматизированное тестирование с помощью интеграционных и юнит-тестов [3].

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

Поэтому в последнее время все популярнее становится подход, заключающийся в развертывание новой версии системы в экспериментальном режиме и последующем определении ее качества на основе анализа изменений различных пользовательских метрик [4]. Ключевыми вопросами при этом являются следующие:

  • выбор нужных метрик для отслеживания;
  • определение времени прекращения эксперимента.

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

Современные подходы к проведению экспериментального развертывания

Существует два типа проведения экспериментов: параллельные эксперименты (сплит-тесты) и последовательные (A/B-тестирование).

Параллельные эксперименты, которые также называют сплит-тестами, заключаются в развертывании двух версий системы одновременно: эталонной и экспериментальной. Как правило, их могут позволить себе только крупные компании, так как необходима достаточно большая база пользователей, чтобы выделить из них достаточно большую репрезентативную долю. Кроме того, инфраструктура для проведения сплит-тестов достаточно сложна: необходима специальная прослойка (например, L7-балансер [5]), который будет распределять пользователей по экспериментальным сплитам, а также возможность запуска нескольких версий системы одновременно.

Последовательные эксперименты, которые иногда называют A/B-тестированием, предполагает выкладку эксперимента на 100% пользователей и отслеживании на них изменений. Данная процедура является более рискованной, чем сплит-тесты: неудачные эксперименты повлияют сразу на всех пользователей сервиса. Инфраструктура для A/B-тестирования значительно проще, что дает возможность проводить его небольшим компаниям.

В настоящее время существуют предприятия, которые поставляют систему экспериментального развертывания (как параллельного, так и последовательного) на аутсорсинг, и все больше компаний прибегают к их услугам [6]. При этом данные аутсорс-организации оставляют на усмотрение клиента решение по определению критерия терминации эксперимента. Также они оставляют закрытой методологию распределения пользователей по экспериментальным сплитам.

Технические аспекты работы непрерывно развертываемых веб-систем

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

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

Для веб-систем существует два основных способа сохранять информацию на клиенте:

  • в клиентском хранилище localStorage [7];
  • в cookie-заголовках запросов [8].

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

Взаимодействие с существующими веб-системами осуществляется в основном по протоколу HTTP [9]. Он предполагает наличие на сервере определенных ресурсов, которые запрашивает клиент. Данные ресурсы могут быть как статическими, так и динамическими. В последнем случае сервер имеет возможность модифицировать ресурс в зависимости от различных параметров запроса, которые хранятся в заголовках, теле и адресе. Именно это и позволяет удобно делить пользователей по экспериментам в веб-системах.

Определение пользователя в экспериментальный сплит

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

Читать полный текст статьи …


СПИСОК ЛИТЕРАТУРЫ:
1. Джез Хамбл and Дэвид Фарли. Непрерывное развертывание ПО. Автомати- зация процессов сборки, тестирования и внедрения новых версий программ. Вильямс, 2011.
2. Rick David Craig and Stefan P. Jaskiel. Systematic Software Testing. Artech House, 2002.
3. Elfriede Dustin, Jeff Rashka, and John Paul. Automated Software Testing: Introduction, Management, and Performance. Addison-Wesley, 1999.
4. Dan Siroker and Pete Koomen. A/B Testing: The Most Powerful Way to Turn Clicks Into Customers. Wiley, 2013.
5. Tony Bourke. Server Load Balancing. O’Reilly Media, 2001.
6. Optimizely — главная страница. https://www.optimizely.com/, 2016.
7. Ian Hickson. Web storage. https://www.w3.org/TR/webstorage/, 2016.
8. Http state management mechanism. Technical report, Internet Engineering Task Force (IETF), 2011.
9. David Gourley, Brian Totty, Marjorie Sayer, Anshu Aggarwal, and Sailu Reddy. HTTP: The Definitive Guide. O’Reilly Media, 2002.
10. Севастьянов Борис Александрович. Курс теории вероятностей и математи- ческой статистики. Наука, 1982.
 



© 
И.С. Скороходов, А.Н. Тихомирова, Журнал "Современная наука: актуальные проблемы теории и практики".
 

 

 

 
SCROLL TO TOP

 Rambler's Top100 @Mail.ru