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

Как известно, процесс разработки программного продукта состоит из ряда этапов.

  1. Формулирование требований к продукту.
  2. Обсуждение и доводка дизайна на высоком, а затем, и на низком уровне.
  3. Создание прототипа, нередко превращающегося в альфа-версию, в которой реализуется базовая функциональность и проводится тщательное тестирование скелета будущего продукта.
  4. Доводка основной функциональности, постепенное наращивание остальных возможностей и активное тестирование новых элементов - выпуск бета-версии.
  5. Замораживание включения в продукт новых функциональных возможностей (code freeze), интенсивные проверка и отладка (рre-release), вывод продукта на рынок.
  6. Поддержка коммерческой версии (maintenance), выпуск дополнений (patch), включение и/или расширение отдельных функциональных возможностей и их интенсивная проверка.

Проверки сопровождают практически каждый этап разработки [1], поэтому совершенно естественно, что на рынке должны были появиться средства для автоматизации процесса тестирования — рутинного, а потому и не популярного среди профессионалов процесса [2, 3]. Среди наиболее популярных пакетов данной направленности — семейства коммерческих продуктов компаний Mercury Interactive, Segue, Rational, Compuware и Radview. Существуют также и свободно распространяемые инструменты, такие как OpenSTA и WAS от Microsoft.

Опустим обсуждение инструментария по созданию спецификаций и рассмотрим средства для управления процессом тестирования (Test Management Automation), взяв в качестве примера программу TestDirector (рис. 1). Идея этого и ему подобных продуктов заключается в создании централизованного репозитория для хранения, доступа и управления всеми составляющими компонентами процесса тестирования. Именно с использования такого инструментария, как правило, и начинается переход от тестирования вручную к внедрению автоматизированных средств. Одно из важных требований к инструменту подобного класса — возможность использования обычного браузера в качестве клиентской части, что упрощает установку, настройку и последующую поддержку продукта.

Рис. 1. TestDirector — инструмент управления процессом тестирования

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

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

В процессе прогонки тестов при помощи TestDirector можно осуществлять контроль за исполнением тестовых примеров, сформированных как вручную, так и автоматически.

Функциональное тестирование

Функциональное тестирование (functional testing) — процесс верификации соответствия функционирования продукта его начальным спецификациям. Характерным примером может быть проверка того, что программа подсчета выплат по банковской ссуде выдает корректные выкладки на любые введенные сумму ссуды и срок ее возврата. Обычно подобные проверки проводятся вручную, иногда к этому подключаются конечные пользователи в качестве бета-тестеров. Однако программные системы становятся все сложнее, а комбинации различных входных параметров и поддерживаемых операционных систем нередко исчисляются десятками и сотнями. В такой ситуации функциональное тестированиe потребует все больших ресурсов; естественным выходом становится автоматизация этого процесса. Рассмотрим инструментарий WinRunner, при помощи которого можно моделировать действия над объектами пользовательского интерфейса приложения.

Продукты типа WinRunner в первую очередь используются для регрессионного тестирования (regression testing), выполняемого на достаточно продвинутом этапе разработки, например, для бета-версии. Цель подобных тестов — выявить, не повредило ли добавление новых особенностей или исправление ошибок работе остальных модулей. Так, при каждом изменении механизма поддержки различных кодировок кириллицы в текстовом редакторе необходимо прогнать проверки на открытие файлов малого, среднего, большого и очень большого размеров. При этом надо предусмотреть проверки для каждой поддерживаемой кодировки и для разных платформ с установленной поддержкой различных языков. Количество комбинаций (и, соответственно, запусков рутинных тестов) здесь может исчисляться сотнями. Используя же инструментарий регрессионного тестирования, можно, к примеру, запустить набор тестов вечером, а утром проверить результаты. При этом WinRunner можно обучить реагировать на случайно появляющиеся интерактивные запросы наподобие «The file is unavailable. Cancel/Retry», требующие вмешательства человека.

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

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

Если среднее время на создание теста при ручном тестировании составляет 6 минут (Tcm = Test Creation, manual), то при автоматическом — 30 минут (Tca = Test Creation, automated). Среднее время на прогон теста вручную — 10 минут (Tem = Test Execution, manual), автоматически — 1 минута (Tea = Test Execution, automated). Сравнив величины Tcm + Tem Ё N и Tca + Tea Ё N, где N — количество итераций теста, можно увидеть, что при повторении теста более 10 раз уже уместна его автоматизация.

Стоит отметить, что применение WinRunner не ограничивается одним лишь регрессионным тестированием: этот продукт можно использовать как средство для проверки нагрузки, например, будет ли текстовый редактор вести себя стабильно если 15 раз подряд открыть, обновить и закрыть очень большой файл в китайской кодировке? И не выявятся ли при этом утечки памяти?

Тестирование на нагрузку

Еще одним примером классического средства автоматизации тестирования является LoadRunner — среда, при помощи которой можно моделировать нагрузку сотен и тысяч одновременно работающих пользователей. На самом деле, моделирование происходит на уровне прикладного протокола системы, т. е., в случае Web-приложений моделируется соответствующий трафик HTTP(S), в случае DCOM-среды — вызовы удаленных объектов, в случае баз данных Oracle — OCI-вызовы, и т.п.

Процесс тестирования клиент-серверной системы можно разбить на несколько этапов: планирование; создание скриптов или так называемых «виртуальных пользователей системы» (virtual user); создание и прогонка нагрузочного теста; обработка и анализ результатов теста.

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

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

Создание «виртуального пользователя» происходит полуавтоматически. Пользователь работает с клиентским приложением, в то время как LoadRunner анализирует создаваемый трафик и генерирует код скрипта, который является ни чем иным, как программой на языке ANSI C. В некоторых случаях возможна также генерация кода на Java или VBScript.

Рис. 2. LoadRunner Controller — создание и исполнение тестов на нагрузку

Тест на нагрузку (рис. 2) представляет собой комбинацию из набора скриптов, создающих одновременно работающих «виртуальных пользователей». Кроме этого, происходит имитация одной или нескольких платформ (Windows NT/Windows 2000/Windows XP/Unix), с которых и приходит нагрузка от десятков, сотен, а иногда и тысяч «виртуальных пользователей».

Но это далеко не все. Недостаточно лишь эмулировать проблематичную ситуацию — необходимо предоставить возможность диагностики системы во время прогона теста. Для этой цели в LoadRunner Controller имеются средства мониторинга, выполняемого как для различных компонентов системы, так и для ее разных уровней. Например, для контроля за загруженностью сети на всем пути прохождения трафика используется так называемый Network Delay Monitor. Для мониторинга таких элементов сетевой инфраструктуры: межсетевые экраны, системы балансировки и переключатели можно применить SNMP-монитор.

Производительность платформ Windows и Unix контролируется средствами Server Resources Monitor. А для дальнейшего анализа можно использовать встроенные в LoadRunner средства сбора информации на уровне приложений: баз данных (Oracle, Sybase, IBM DB/2, Microsoft SQL Server), серверов приложений (IBM WebSphere, BroadVision, BEA Weblogic и др.) и Web-серверов (Netscape, Apache и Microsoft IIS).

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

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

***

Внедрение средств автоматизации тестирования — непростой и зачастую длительный процесс. Залогом его успеха являются полная поддержка со стороны руководства, а также четкое представление всех участников проекта о современных подходах к тестированию программного обеспечения. Начинать внедрение средств автоматизации тестирования стоит как можно раньше, причем практика показывает, что в перспективе на несколько лет показатель возврата инвестиций в этот вид работ может достигать 400% [4, 5].

Литература

1. Илья Бромберг, «Система контроля этапов жизненного цикла ПО». «Открытые системы», 1998, № 6
2. Tilo Linz, Matthias Daigl, «How to Automate Testing of Graphical User Interfaces». http://www.imbus.de/ forschung/pie24306/gui/aquis-full_paper-1.3.html
3. Elfriede Dustin, Jeff Rashka, John Paul, «Automated Software Testing: Introduction, Management, and Performance». http://www.amazon.com/exec/obidos/ ASIN/0201432870/qid=1007369126/sr=8-2/ref=sr_8_19_2/002-8046926-8720815
4. http://www.isintegration.co.uk/Documents/ White_papers/ROI_for_Automated_Tools.pdf
5. http://www.newport-group-inc.com/PDF/!mercury.pdf

Илья Бромберг (ibromberg@mercury-eur.com) — консультант компании Mercury Interactive.

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

Крупный банк в одной из Скандинавских стран, в течение полутора лет силами группы из 15 разработчиков создавал систему на базе технологии CORBA. За три месяца до пуска системы было «неожиданно» принято решение о прогоне тестов на производительность, в высоких показателях которой ни у кого из разработчиков не возникало и тени сомнения. По спецификациям, система должна была обеспечивать работу до тысячи биржевых брокеров, одновременно торгующих акциями.

Первые же тесты показали, что при симуляции уже лишь 120 «виртуальных пользователей» один шаг аутентификации (login) занимал около 40 секунд. При более детальном анализе выявилось, что несколько базовых модулей системы совершенно не масштабируемы. Классический подход типа «а мы добавим еще два 4-процессорных сервера» дал прирост производительности всего лишь на 15%. Доводка системы неожиданно для руководства проекта потребовала тысячу дополнительных человек-часов. В результате проект был сдан на два месяца позже ожидаемого срока, так и не придя в соответствие с требованиями. Его окончательная доводка проводилась «на лету» в течение полугода после начала коммерческого использования.