Home

Автор: Алексей Мишуловин

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

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

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

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

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

• «Легкие». Подсистемы нагружаются потоком входных данных (предварительно заполненная таблица, набор файлов и т.д.). В этом случае, зачастую, сохраняется преемственность тестов (один раз подготовил входные данные, и далее их можно использовать, просто меняя версии приложения на более новые). Разумеется, если формат входных данных меняется (расширяется), это ведет к переделке сценария. Но такое, как правило, происходит не так часто. Чаще всего, под категорию «легких» попадают пакетные задания и фоновые процессы биллинговых систем, запускаемые непосредственно на серверах (либо БД, либо серверах приложений).
• «Средние». Подсистемы имеют пользовательский интерфейс. При этом, клиентское приложение написано «правильно» — таким образом, что никакой логики внутри клиентского приложения не сосредоточено — «легкий» клиент. В этом случае первоначальная подготовка к нагрузочному тестированию может быть очень серьезной. Для имитации массовой работы клиентов, используя специальные программные средства, такие, например, как Rational Perfomance Tester или Mercury LoadRunner, требуется создавать сценарии из контекстно-связанных скриптов, написанных на специальном языке. Но при этом, сами скрипты являются достаточно простыми, т.к. содержат исключительно вызовы серверной логики. Кроме того, в дальнейшем, один и тот же сценарий может быть использован вновь, поскольку поменялась лишь серверная логика (или произошло расширение функционала, никак не затронув существующий).
• «Тяжелые». Как правило, это те приложения, которые содержат логику на клиентском месте. Имитировать массовую работу клиентов с таким приложением (в особенности, если тесты претендуют на точность) либо очень сложно, либо просто невозможно. К примеру, в используемом Rational Perfomance Tester языке VU Language попросту не предусмотрено операций с плавающей точкой. Т.е., любой подобный «клиентский» расчет влечет за собой, как минимум, создание специальных библиотек ( DLL), позволяющих производить соответствующие расчеты над числами с плавающей точкой, передаваемыми строками. Таким образом, тестировщик должен быть в известном смысле еще и неплохим программистом! Не говоря уже о том, что без анализа исходного кода симуляция работы такого приложения просто не возможна.

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

В-третьих, отдельной задачей стоит профилирование нагрузки. Не секрет, что каждое приложение может хорошо работать по отдельности. Однако, в силу «межпроцессной» корреляции, результаты групповой работы приложений могут быть самыми непредсказуемыми. Отсюда - чем точнее сделано профилирование нагрузки на каждое из приложений, тем точнее будут нагрузочные испытания, и, как следствие, сделанные выводы. Здесь также приложения можно разделить на «легкие» и «тяжелые». К легким, с точки зрения профилирования, можно отнести те, чей входной поток измеряем (например, по количеству обрабатываемых записей за некоторый период), или, если речь идет о клиентских рабочих местах, набор операций, приводящих к появлению определенного количества информации за единицу времени. К «тяжелым», с точки зрения профилирования, относятся те приложения, работа которых создает серьезную нагрузку и, при этом, не оставляет никаких «следов» своей «жизнедеятельности» (к примеру, работа «Call Center» — группы пользователей, дающих справки по телефону и, соответственно, только просматривающих информацию). Другим примером может служить пакетное задание (или их совокупность), занимающееся обработкой данных сгенерированных другими процессами. Здесь, например, может иметь место лавинообразный эффект, когда из-за диспропорции по каким-либо признакам, подсистема ведет себя не так, как в условиях реальной эксплуатации.

В настоящий момент, группа нагрузочного тестирования «Петер-Сервис», на основе разработанных методик тестирования биллинговой системы «PETER-SERVICE BIS», занимается поисками ответов на достаточно узкий круг вопросов. Среди задач, которые нам поставлены, например такие, как ответ на вопрос о повышении/снижении производительности работы основных бизнес-потоков биллинга при апгрейде версии ORACLE с существующей (9 Release 2) на новую (10 Release 2) или сравнение аппаратного обеспечения различных производителей при одних и тех же сценариях нагрузки. И на такие вопросы сегодня ответить уже достаточно просто. Вместе с тем, полностью влиться в бизнес-процесс выпуска ПО пока не удается из-за сложности решения озвученных выше проблем. Тем не менее, мы смотрим вперед с оптимизмом.