Содержание


Тестирование производительности WebSphere Commerce с помощью Rational Performance Tester

Часть 2. Сценарий тестирования WebSphere Commerce – произвольный просмотр

Comments

Серия контента:

Этот контент является частью # из серии # статей: Тестирование производительности WebSphere Commerce с помощью Rational Performance Tester

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Тестирование производительности WebSphere Commerce с помощью Rational Performance Tester

Следите за выходом новых статей этой серии.

Цель произвольного просмотра – пройти по иерархии каталога и попасть на страницу товара. Каталог WebSphere Commerce содержит категории верхнего уровня, подкатегории и товары. Просмотр начинается с категорий верхнего уровня и продолжается в подкатегориях, пока не будет загружена страница товара.

Не так давно в WebSphere Commerce появилась новая функциональность (многоаспектная навигация), которая позволяет пользователю попадать непосредственно на страницы товаров. Задачей многоаспектной навигации является фильтрация товаров по атрибутам (таким как цвет, размер и тип) и отображение только тех товаров, которые соответствуют выбранным атрибутам.

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

На рисунке 1 показаны структура используемого в статье каталога и правило 80/20. Это правило гарантирует, что категория topCat1 будет просматриваться 80% времени, т.е. 80% времени пользователи будут просматривать товары с Prod1 по Prod6.

Рисунок 1. Каталог и правило 80/20
Каталог и правило 80/20
Каталог и правило 80/20

В Rational Performance Tester существует два способа реализации произвольного просмотра:

  • Статический просмотр, управляемый данными.
  • Динамический просмотр, являющийся сканированием Web-страниц.

Рассмотрим на примере эти способы просмотра.

Статический просмотр

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

В параметрах запроса должны быть указаны реальные идентификаторы категорий или товаров. Это означает, что идентификаторы категорий и товаров должны быть известны до выполнения теста. В Rational Performance Tester для хранения идентификаторов, подставляемых в параметры запросов, используются пулы данных. На рисунке 2 показано, что для категорий верхнего уровня, подкатегорий и товаров используются отдельные пулы данных. В данном примере вместо числовых идентификаторов используются имена категорий и товаров.

Рисунок 2. Пулы данных
Пулы данных
Пулы данных

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

Рисунок 3. Пулы данных для URL-адресов
Пулы данных для URL-адресов
Пулы данных для URL-адресов

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

Для реализации подобного поведения используется случайный селектор (Random Selector). Внутри этого селектора находятся четыре HTTP-страницы, каждая из которых находится внутри взвешенного блока (Weighted Block). Предполагается, что 20% пользователей просматривают только главную страницу, 20% переходят в категорию верхнего уровня, 20% переходят в подкатегории, а 40% – на страницы товаров. На рисунке 4 показан этот тест.

Рисунок 4. Случайные селекторы
Случайные селекторы
Случайные селекторы

При воспроизведении теста, показанного на рисунке 4, пользователи выбирают главную страницу, страницу категории верхнего уровня, страницу подкатегории ИЛИ страницу товара напрямую. Если такой просмотр соответствует требованиям, никаких изменений в тест вносить не нужно. Однако если пользователи должны выполнять просмотр сверху вниз и не могут попасть на страницу товара напрямую (а только через страницы категории верхнего уровня и подкатегории), тест необходимо модифицировать.

Чтобы пользователь сначала попадал в одну из категорий, затем в одну из подкатегорий и только затем на страницу товара, блок ProductDisplay должен содержать все предшествующие запросы. Другие блоки тоже должны содержать все предшествующие запросы. На рисунке 5 показан модифицированный тест.

Рисунок 5. Случайные селекторы для просмотра сверху вниз
Случайные селекторы для просмотра сверху вниз
Случайные селекторы для просмотра сверху вниз

В первой части упоминалось, что каждую группу страниц в каждом селекторе можно поместить в блок транзакции (см. рисунок 6).

Рисунок 6. Случайные селекторы и транзакции
Случайные селекторы и транзакции
Случайные селекторы и транзакции

Теперь пойдем дальше и применим правило 80/20.

При использовании этого правила 20% категорий верхнего уровня выбираются 80% времени. Подкатегории и товары выбираются случайным образом.

Из трех категорий верхнего уровня (topCat1, topCat2 и topCat3) первая категория topCat1 выбирается 80% времени. Для остальных 20% времени из двух оставшихся категорий верхнего уровня (topCat2 и topCat3) случайным образом выбирается одна (при трех категориях верхнего уровня 66% времени выбирается topCat1, а остальные 33% времени – одна из оставшихся категорий).

При таком подходе пул данных категорий верхнего уровня делится на два пула данных. Первый пул данных содержит только topCat1 и выбирается 80% времени. Второй пул данных содержит topCat2 и topCat3. Здесь опять пригодятся случайные селекторы. Используются два блока: первый имеет вес 80 и обеспечивает просмотр первой категории, а второй имеет вес 20 и обеспечивает просмотр двух оставшихся категорий.

HTTP-запросы в этих блоках одинаковы, но первый блок ссылается на первый (из только что созданных) пул данных, а второй блок ссылается на второй пул данных. На рисунке 7 показано разделение одного пула данных на два (80 и 20).

Рисунок 7. Разделение пула данных
Разделение пула данных
Разделение пула данных

На рисунке 8 показан итоговый тест.

Рисунок 8. Применение правила 80/20
Применение правила 80/20
Применение правила 80/20
Рисунок 9. Ссылки на новые пулы данных
Graphic showing links to the new datapools
Graphic showing links to the new datapools

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

Чтобы это правило соблюдалось для вышеописанного каталога, 80% времени должна просматриваться категория верхнего уровня topCat1 и все, что в нее входит.

Для реализации такого поведения и соблюдения правила 80/20 необходимо разделить пулы данных подкатегорий и товаров, а также добавить в план случайные селекторы тем же способом, который был применен для категорий верхнего уровня (см. рисунок 9). Разделение пулов данных показано на рисунке 10.

Рисунок 10. Пулы данных категорий верхнего уровня, подкатегорий и товаров
Пулы данных категорий верхнего уровня, подкатегорий и товаров
Пулы данных категорий верхнего уровня, подкатегорий и товаров

На рисунке 11 показан итоговый тест.

Рисунок 11. Итоговый тест
Итоговый тест
Итоговый тест

Существенным преимуществом статического просмотра является простота реализации. У тестировщика отсутствует необходимость создавать регулярные выражения (например, для получения идентификаторов категории или товара) и пользовательский код. Это простой способ определения времени отклика при просмотре категорий и товаров.

Однако статический просмотр имеет и недостатки:

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

Эти недостатки нарушают переносимость теста, так что его нельзя использовать без изменений для другого каталога Commerce.

Динамический просмотр

Чтобы создать тест динамического просмотра, не нужно знать структуру каталога и идентификаторы товаров или категорий. Этот способ просмотра соблюдает отношение родитель-потомок и потому лишен недостатков статического просмотра.

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

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

Перед обсуждением динамического просмотра рассмотрим реализацию правила 80/20 для этого случая.

Одним из способов (обратите внимание, что существуют и другие способы) реализации правила 80/20 является следующая формула:

       f(x) = floor(N*x^7)

Здесь:

  • x – случайно сгенерированное число с равномерным распределением 0<=x<1.
  • N – число просматриваемых элементов.

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

Если в пользовательском коде категории верхнего уровня принадлежат массиву topCategoryList, формула выбора случайной категории с соблюдением правила 80/20 выглядит следующим образом:

	i = ( int )( Math.floor( topCategoryList.size() * Math.pow( Math.random(), 7 ) ) );

Здесь:

  • topCategoryList.size() = N.
  • Math.random() = x.
  • i – начинающийся с нуля индекс массива topCategoryList.

В Rational Performance Tester создание тестов обычно начинается с записи. Ниже приведен путь записи:

Home page (Главная страница) > Sitemap (Карта сайта) > topCat3 > subCat6 > Prod17

После записи добавляется переменная INPUT и сохраняются только главные URL-адреса.

Рисунок 12. Запись случайного просмотра
Запись случайного просмотра
Запись случайного просмотра

При повторном выполнении этот тест всегда проходит один и тот же путь.

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

Ниже показан псевдокод преобразования записи простого просмотра в тест динамического просмотра.

Псевдокод записи показан для следующих шагов (R означает запись):

  • R1 – Перейти на Home page.
  • R2 – Перейти на Sitemap.
  • R3 – Перейти в категорию верхнего уровня topCat3.
  • R4 – Перейти в подкатегорию subCat6.
  • R5 – Перейти на страницу товара Prod17.

В записи общего теста просмотра каталога Commerce шаги R1 и R2 должны быть сохранены. Они показаны в правом столбце таблицы 1 как T1 и T2 (T означает Test). На Sitemap на шаге T2 выбирается одна случайная категория верхнего уровня. Шаги R3 и R4 в левом столбце таблицы преобразуются в цикл. Этот цикл переходит в подкатегорию, получает одну случайную подкатегорию из содержимого ответа и переходит в нее. Он делает это, пока в содержимом ответа есть подкатегории. Этот цикл показан в шаге Т4 в правом столбце таблицы.

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

Таблица 1. Преобразование псевдокода записи в псевдокод теста
Псевдокод записиПсевдокод теста
R1 - Перейти на Home page.
R2 - Перейти на Sitemap.

R3 - Перейти в категорию верхнего уровня topCat3.
R4 - Перейти в подкатегорию subCat6.







R5 - Перейти на страницу товара Prod17.
T1 - Перейти на Home page.
T2 - Перейти на Sitemap.
T3 - Выбрать одну категорию верхнего уровня на Sitemap в CategoryLink.
T4 - Цикл.
         T5 - Если CategoryLink != нет.
         T6 - То.
             T7 - Перейти в CategoryLink.
             T8 - Выбрать категорию в CategoryLink или установить ее в "нет".
             T9 - Выбрать товар в ProductLink или установить ее в "нет".
         T10 - Иначе.
             T11 - Прервать цикл.
T12 - Конец цикла.
T13 - Если ProductLink != нет.
             T14 - Перейти в ProductLink.

Псевдокод в листинге 1 аналогичен псевдокоду в правом столбце таблицы 1. Однако есть несколько дополнений, описанных ниже. Этот псевдокод аналогичен тестам Rational Performance.

Листинг 1. Псевдокод динамического просмотра
			1  - Перйти на страницу Sitemap или на страницу всех подкатегорий.
			2  - Пользовательский код: SiteMapParseTopCategories().
			3  - Установить CategoryLink = SiteMapParseTopCategories().
			4  - Цикл  (бесконечный).
			5  -  Если   CategoryLink != "нет".
			6  -  То  // Найдена другая категория. Перейти в нее.
			7  -    Перейти на URL=http://hostname/CategoryLink.
			8  -    Найти CategoryLink в ответе предыдущего URL или установить CategoryLink в "нет".
			9  -    Найти ProductLink в ответе предыдущего URL или установить ProductLink в "нет".
			10 –  Иначе // Это страница товара. Выйти из цикла и попытаться отобразить товар позже.
			11 –    Пользовательский код: BreakLoop().
			12 – Конец цикла.
			13 – Если ProductLink != "нет".
			14 –   Перейти на URL=http://hostname/ProductLink.

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

  1. Добавление цикла

    В редакторе Rational Performance Tester создайте бесконечный цикл и поместите в него две страницы из Sitemap::

    Выбрать две страницы > Щелкнуть правой кнопкой > Insert > Loop.

    Эту процедуру демонстрирует снимок экрана на рисунке 13.

    Рисунок 13. Добавление цикла
    Добавление цикла
    Добавление цикла

    Сделайте цикл бесконечным, как показано на рисунке 14.

    Рисунок 14. Бесконечный цикл
    Бесконечный цикл

    После добавления двух переменных, CategoryLink и ProductLink, из строк 7 и 14 листинга 1 тест будет выглядеть так, как показано на рисунке 15.

    Рисунок 15. Тест после добавления цикла
    Тест после добавления цикла
    Тест после добавления цикла
  2. Пользовательский код

    В псевдокоде динамического просмотра (см. листинг 1) есть два пользовательских кода: SiteMapParseTopCategories и BreakLoop. SiteMapParseTopCategories в строке 2 анализирует содержимое ответа Sitemap, извлекает все ссылки на категории верхнего уровня и случайным образом выбирает одну из этих ссылок с применением правила 80/20. BreakLoop в строке 11 прерывает цикл.

    На рисунке 16 демонстрируется получение всех категорий верхнего уровня из исходного кода страницы Sitemap.

    Рисунок 16. Просмотр исходного кода страницы
    Просмотр исходного кода страницы
    Просмотр исходного кода страницы

    Для topCat1:

    			<li id="SiteMap_1_1" class="h2"><a role="heading" aria-level="2" href="http://hostname.domain.com/webapp/wcs/stores/servlet/en/auroraesite/topcat1">topCat1</a>

    Для subCat1:

    			<li id="SiteMap_1_1_1" class="h3"><a href="http://hostname.domain.com/webapp/wcs/stores/servlet/en/auroraesite/topcat1/subcat1"> subCat1</a>

    Для subCat1: В этих ссылках за SiteMap следует два числа для категорий верхнего уровня (_1_1) и три числа для подкатегорий (_1_1_1). Используя это отличие, следующее регулярное выражение извлекает ссылки только на категории верхнего уровня:

    			SiteMap_[0-9]+_[0-9]\ ".*?href=\"http://[^/]+([^\"]+)\"

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

    Результаты использования этого класса с Sitemap выводятся на консоль (см. рисунок 17).

    Рисунок 17. Вывод на консоль
    Вывод на консоль
    Вывод на консоль

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

    Добавление регулярного выражения в записанный тест показано на рисунке 18.

    Рисунок 18. Добавление в тест пользовательского кода
    Добавление в тест пользовательского кода
    Добавление в тест пользовательского кода

    Ниже показан код SiteMapParseTopCategories:

    package custom;
    
    import com.ibm.rational.test.lt.kernel.services.ITestExecutionServices;
    import java.util.ArrayList;
    import java.util.regex.Matcher;
    import java.util.regex.Pattern;
    
    public class SiteMapParseTopCategories implements 
    		com.ibm.rational.test.lt.kernel.custom.ICustomCode2 {
      public final static String 
                       regex="SiteMap_[0-9]_+[0-9]\".*?href=\"http://[^/]+([^\"]+)\"";
      public final static Pattern pattern = Pattern.compile(regex,Pattern.DOTALL);
      public SiteMapParseTopCategories() {}
    
      public String exec(ITestExecutionServices tes, String[] args) {
         // Аргументы INPUT
         String text=args[0];
    
         // Переменные LOCAL
         String result="none";
         ArrayList<String> topCategoryList=new ArrayList<String>();
         Matcher matcher = pattern.matcher(text);
    
         while (matcher.find()) {
            result=matcher.group(1);
            result=result.replaceAll("&amp;", "&");
            if (!topCategoryList.contains(result)) {
               topCategoryList.add(result);
            }
         }
    	
         if (topCategoryList.size()>0) {
            int i = (int)(Math.floor(topCategoryList.size()*Math.pow(Math.random(),7)));
            result=(String)topCategoryList.get(i);
         }
    
         tes.getTestLogManager().reportMessage("ParseTopCategories: "+result);
         return result;
      }
    }

    Содержимое ответа Sitemap необходимо передать в качестве аргумента в пользовательский код iteMapParseTopCategories. Для определения этого аргумента создайте поле-ссылку для содержимого ответа Sitemap (см. рисунок 19). Выберите содержимое ответа Sitemap.

    Рисунок 19. Выбор содержимое ответа
    Выбор содержимое ответа
    Выбор содержимое ответа

    Щелкните правой кнопкой мыши на поле Content и выберите команду Create Field Reference (см. рисунок 20).

    Рисунок 20. Создание поля-ссылки
    Создание поля-ссылки
    Создание поля-ссылки

    Укажите имя ссылки (см. рисунок 21).

    Рисунок 21. Указание имени ссылки
    Указание имени ссылки
    Указание имени ссылки

    Наконец, выберите пользовательский код и добавьте аргумент (см. рисунок 22).

    Рисунок 22. Добавление аргументов
    Добавление аргументов
    Добавление аргументов

    По сравнению с предыдущим кодом пользовательский код BreakLoop является совсем небольшим. Он содержит единственный вызов следующей функции:

     
    			tes.getLoopControl().breakLoop()

    Он будет добавлен в тест позднее.

  3. Установка CategoryLink

    В псевдокоде динамического просмотра (см. листинг 1) CategoryLink устанавливается в строке 3 из пользовательского кода и в строке 8 из содержимого ответа. Можно написать пользовательский код извлечения случайной подкатегории из содержимого ответа, аналогичный извлечению случайной категории верхнего уровня из Sitemap, однако эту переменную можно установить и без пользовательского кода. Пользовательский код извлечения из Sitemap нужен только для использования в нем формулы, учитывающей правило 80/20.

    Первый шаг: написание регулярного выражения.

    Имя подкатегории в содержимом ответа ищется с помощью регулярного выражения.

    Рисунок 23. Ссылка на подкатегорию
    Ссылка на подкатегорию
    Ссылка на подкатегорию

    Регулярное выражение должно соответствовать всем ссылкам на подкатегории, т.е. тому, что выделено на рисунке 23.

    Следующее регулярное выражение находит все ссылки на подкатегории в содержимом ответа:

         
    			<a id=\"SBN_[^\"].*?\" href=\"http://[^/]+(/[^\"]+)

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

    Рисунок 24. Вывод на консоль
    Вывод на консоль
    Вывод на консоль

    Это именно то, что нужно.

    Второй шаг: изменение содержимого ответа.

    Удалите все содержимое ответа, оставив только одну строку:

     
    			<a id="SBN_Link" href="http://hostname/CategoryLink
    Третий шаг: создание ссылки.

    Создайте ссылку для /CategoryLink, как показано на рисунке 25.

    Рисунок 25. Создание ссылки
    Создание ссылки
    Создание ссылки

    Последний шаг: установка свойств ссылки

    Выберите ссылку, щелкните на ней правой кнопкой мыши и выберите Properties в контекстном меню. Во всплывающем окне Properties for замените регулярное выражение созданным ранее и отметьте переключатель Random occurrence (см. рисунок 26).

    Рисунок 26. Установка свойств ссылки
    Установка свойств ссылки
    Установка свойств ссылки

    Если подкатегория не будет найдена, цикл должен прерваться. Такое поведение определяется на вкладке Error Handling этого же окна (см. рисунок 27).

    Рисунок 27. Вкладка Error Handling
    Вкладка Error Handling
    Вкладка Error Handling

    Нажмите кнопку Change и выберите соответствующий вариант (см. рисунок 28).

    Рисунок 28. Действие при возникновении ошибки
    Действие при возникновении ошибки
    Действие при возникновении ошибки
  4. Установка ProductLink

    ProductLink устанавливается в строке 9 в псевдокоде динамического просмотра (см. листинг 1). Процедура аналогична CategoryLink и показана на рисунке 29.

    Рисунок 29. Ссылка на товар
    Ссылка на товар
    Ссылка на товар

    Следующее регулярное выражение соответствует всем ссылкам на товары:

         
    			<a id=\"WC_CatalogEntryDBThumbnailDisplayJSPF.*?[^\"]\".*?href=\"http://[^/]+(/[^\"]+)"

    Результаты его тестирования с помощью класса CheckRegex, описанного в разделе Проверка регулярных выражений, показаны на рисунке 30

    Рисунок 30. Вывод на консоль
    Вывод на консоль
    Вывод на консоль

    Содержимое ответа меняется так же, как это делалось раньше, и в нем сохраняется только одна строка:

         
    			<a id="WC_CatalogEntryDBThumbnailDisplayJSPF_link" href="http://hostname/ProductLink.

    Поместите эту строку в обновленное содержимое ответа, т.е. в содержимое ответа страницы topCat3 (см. рисунок 15).

    После обновления содержимого ответа создайте ссылку и измените ее свойства (Regular Expression и Occurrence) способом, описанным ранее.

    Рисунок 31. Обновление содержимого ответа
    Обновление содержимого ответа
    Обновление содержимого ответа
  5. Удалите ненужные страницы.

    Страница subCat6 | AuroraESite не нужна, поскольку все подкатегории извлекаются в цикле на странице topCat3 | AuroraESite. Обратитесь к рисунку 15.

    После этого удаления в цикле останется только одна страница.

  6. Измените имена некоторых страниц.

    Присвойте странице topCat3 | AuroraESite более естественное имя, например Category Display. Аналогичным образом замените имя страницы Prod17 | AuroraESite более естественным именем Product Display. Это облегчит чтение отчета о производительности страниц после выполнения теста.

  7. Добавьте ЕСЛИ-ТО-ИНАЧЕ.

    Для реализации ветвления ЕСЛИ в строке 5 листинга 1 выберите все страницы в цикле и вставьте условие, как показано на рисунке 32. Условием является проверка на продолжение или прерывание бесконечного цикла подкатегорий.

    Рисунок 32. Добавление условия
    Добавление условия
    Добавление условия

    Установите свойства условия в соответствии с рисунком 33.

    Рисунок 33. Параметры условия
    Параметры условия
    Параметры условия

    Добавьте блок ИНАЧЕ (строка 10 листинга 1) в соответствии с рисунком 34.

    Рисунок 34. Добавление блока ИНАЧЕ
    Добавление блока ИНАЧЕ
    Добавление блока ИНАЧЕ

    Добавьте пользовательский код BreakLoop в блок ИНАЧЕ.

  8. Присвойте значения переменным CategoryLink и ProductLink

    Добавьте назначение переменной для CategoryLink в соответствии с рисунком 35.

    Рисунок 35. Добавление назначения переменной
    Добавление назначения переменной
    Добавление назначения переменной

    Выберите значение из источника данных (см. рисунок 36).

    Рисунок 36. Выбор источника данных для переменной
    Выбор источника данных для переменной
    Выбор источника данных для переменной

    Выберите ссылку CategoryLink (см. рисунок 37).

    Рисунок 37. Выбор ссылки
    Выбор ссылки
    Выбор ссылки

    Повторите те же шаги для переменной ProductLink.

  9. Замените ссылки на категории и товары соответствующими переменными.

    Замените URL-адрес страницы Category Display для CategoryURL переменной CategoryLink (см. рисунок 38).

    Рисунок 38. Замена переменной
    Замена переменной
    Замена переменной

    Повторите те же действия для страницы Product Display, заменив URL-адрес товара переменной ProductLink.

  10. Добавьте проверку перед отображением товара.

    В соответствии со строкой 13 листинга 1 проверьте значение ProductLink перед отображением товара.

  11. Окончательный сценарий выглядит так, как показано на рисунке 39.

    Рисунок 39. Окончательный сценарий
    Окончательный сценарий
    Окончательный сценарий

Ниже перечислены основные моменты преобразования записи в тест динамического просмотра:

  1. На основании записи создается общий псевдокод для просмотра каталога.
  2. Чтобы сделать тест общим, запись модифицируется (добавляется цикл для замены перехода по категориям к странице товара).
  3. Применяемые в пользовательском коде и свойствах ссылки регулярные выражения проверяются и применяются для извлечения случайного содержимого.
  4. В пользовательском коде, добавляемом в тест, реализуется правило 80/20.

Примечание.

Мы реализуем только просмотр. Если необходимо реализовать процесс покупки, следует создать раздел заказа. Для этого для просматриваемых продуктов необходимо извлекать значения параметров товара (такие как catEntryId), необходимые для добавления товара в корзину.

Проверка регулярных выражений

В этом разделе представлены два способа проверки регулярных выражений:

  • Встроенная проверка регулярных выражений.
  • Создание Java-класса для проверки регулярных выражений.

Встроенная проверка регулярных выражений

Встроенная проверка регулярных выражений выполняется при создании ссылки. Щелкните правой кнопкой мыши на любой ссылке и выберите Properties. Чтобы выполнить проверку, в окне Properties нажмите кнопку, расположенную справа от регулярного выражения (см. рисунок 40).

Рисунок 40. Встроенная проверка регулярных выражений
Встроенная проверка регулярных выражений
Встроенная проверка регулярных выражений

Создание Java-класса для проверки регулярных выражений

Для создания Java-класса в Rational Performance Tester выполните следующие действия:

  1. File > New > Other … > Развернуть папку Java > Выбрать Class (см. рисунок 41).
    Рисунок 41. Создание Java-класса
    Создание Java-класса
    Создание Java-класса
  2. Нажмите Next. Откроется окно New Java Class.
  3. Введите имя класса в поле Name и отметьте флажок public static void main(String[] args), как показано на рисунке 42.
    Рисунок 42. Установка свойств Java-класса
    Установка свойств Java-класса
    Установка свойств Java-класса
  4. Нажмите Finish. Rational Performance Tester создаст пустой класс (см. рисунок 43).
    Рисунок 43. Создание пустого Java-класса
    Создание пустого Java-класса
    Создание пустого Java-класса
  5. Добавьте в main класса следующий код:
    FileInputStream fis = new FileInputStream("c:\\temp\\sitemap.htm");  
    int x= fis.available();
    byte b[]= new byte[x];
    fis.read(b);
    String content = new String(b);
    fis.close();
    String regex = "SiteMap_[0-9]_+[0-9]\ ".*?href=\"http://[^/]+([^\"]+)\"";
    Pattern pattern = Pattern.compile(regex,Pattern.DOTALL); 
    Matcher matcher = pattern.matcher(content);
    while (matcher.find()) 
    {
    	System.out.println(matcher.group(1));
    }
    System.out.println("Done");
  6. При добавлении этого кода редактор отобразит несколько ошибок используемых типов. Необходимо добавить следующие операторы import:  
    	import java.io.FileInputStream;
    	import java.util.regex.Matcher;
    	import java.util.regex.Pattern;

    Также необходимо добавить throws Exception:

    	public static void main(String[] args) throws Exception {

    На рисунке 44 показан весь класс.

    Рисунок 44. Готовый класс
    Готовый класс
    Готовый класс

    Перед каждым использованием этого класса для проверки регулярного выражения сделайте следующее:

    • Измените формулу регулярного выражения в переменной regex класса.
    • Сохраните в файл страницу, для которой применяется переменная regex, и укажите в переменной fis полный путь к этому файлу (отмечено стрелками на рисунке 44).
    • Обратите внимание на управляющие символы "\". Их использование вызвано тем, что регулярное выражение содержит символы двойных кавычек.

Заключение

В этой статье, являющейся второй частью серии, посвященной созданию тестов с помощью Rational Performance Tester, реализован реальный сценарий просмотра каталога WebSphere Commerce. Представлены два способа просмотра: статический и динамический. Для обоих способов описано применение правила 80/20.

В третьей части будут рассмотрены передовые методики отладки в Rational Performance Tester.

Благодарности

Значительный вклад в написание и рецензирование статьи внесли сотрудники групп Rational Performance Tester и WebSphere Commerce Performance:

  • Кент Сифкес (Kent Siefkes) – ведущий архитектор Rational Performance Tester.
  • Дон Питерс (Dawn Peters) – разработчик ПО Rational Quality and Requirements Management.
  • Андрей Мораро (Andrei Moraro) – студент-стажер из Торонтского университета.
  • Алехандро Октубре (Alejandro Octubre) – студент-стажер из Университета Макмастера.

Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational, WebSphere
ArticleID=986803
ArticleTitle=Тестирование производительности WebSphere Commerce с помощью Rational Performance Tester: Часть 2. Сценарий тестирования WebSphere Commerce – произвольный просмотр
publish-date=10222014