неділя, 20 травня 2012 р.

Page mapping + Yaml + PHP

Добрый день читатель.
Сегодня хочу с вами поделится интересным подходом для мапинга елементов UI интерфейса Web страниц.

Нам с вами понадобятся всего три вещи: небольшое знание языка программирования PHP, YAML и принципов наследования классов в Java.


неділя, 13 травня 2012 р.

Архитектура тестового фреймворка для Behat/Mink

Добрый день, читатель.

В текущее время, у меня на проекте внедряется подход Behavior Driven Development
Хочу с вами поделится архитектурным решениям для тестирования с помощью Behat

В архитектуре тестового фреймворка используется стандартный подход. Вот такой:


но с небольшим вкраплением - связью с Behat и утилитой PageHelper
Собственно архитектура состоит из двух компонент. Первой что связывает нас с Behat, которая выглядит следующим образом:

Этот компонент всегда должен содержать клас FeatureContext и загрузает все класы как суб-контексты из второй компоненты.
Вторая компонента, состоит из контекстов для определений шагов тестирования приложения. Она выглядит следующим образом

Как видно с рисунка, то базовый клас имеет несколько зависимостей - зависимость на модель вашего приложения и на утилитный клас PageHelper. Последний будет расматриватся в следующем посте.  Зависимость на модель призвана облегчить Given шаги.

Вас наверное интересует, почему именно такая архитектура? Обоснования следующие:

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

субота, 12 травня 2012 р.

Тестирование скорости загрузки полной страницы на JMeter

Добрый день, читатель.

Последнее время меня просят проверить производетельность приложения и учитывать все внутрение ресурсы страницы.

Есть несколько способов добится своей цели: простой и сложный.

Простой способ состоит в том, что в JMeter подобная возможность уже встроена. При добавлении HttpRequestSampler к вашему тест плану, нужно выбрать чекбокс "Retreive all Embedded  recources from html files".



Сложный способ состоит в том, чтобы в ручную выбирать внутрение ресурсы с помощью средств XPath Extractor и формировать запросы следующим способом: Сначала нужная странца, и отдельные запросы по картинкам, CSS, JS



Отличия первого и второго способом состоят в том как выполняются запросы и как они сохраняются.

В первом случае загрузка "внутреностей" страницы происходит как подзапросы текущего.  При этом JMeter запишет результат в таком виде

<httpSampler lb="mypage" url="page.html" t="546">
    ...
   <httpSampler url="myimg.png" t="24"/>
</httpSampler>

Во втором случае все внутрености загружаются как отдельные запросы, что создает дополнительную нагрузку на сервер. Здесь JMeter запишет результат в таком виде

<httpSampler lb="mypage" url="page.html" />
<httpSampler lb="mypage - myimg.png" url="myimg.png"/>

Последние результаты нужно будет еще дополнительно обрабатывать и группировать, чтобы получить значение полной загрузки странцы, когда в первом мы получаем эго в готовом виде (об этом побеспокоится сам JMeter)