Особенности тестирования различных приложений. Лекция Особенности тестирования различных приложений. Автоматиз. Тестирование Вебприложений
 Скачать 0.61 Mb.
|
|
тест на безопасность [ 12 ]. Это очень важный тип тестов, так как от безопасности сервера зависит практически все – и сам бизнес, и доверие пользователей, и сохранность информации. Правда, в отличие от других тестов, тестирование безопасности следует проводить регулярно. Кроме того, тестированию подвергается не только сам конкретный сайт или веб-приложение, а весь сервер полностью – и веб-сервер, и операционная система, и все сетевые сервисы. Как и в случае других тестов, программа "прикидывается" реальным пользователем-взломщиком и пытается применить к серверу все известные ей методы атаки и проверяет все уязвимости. Результатом работы будет отчет о найденных уязвимостях и рекомендации по их устранению. Ошибки, связанные с проверкой корректности ввода, часто довольно сложно обнаружить в большом объеме кода, взаимодействующего с пользователем. Это является основной причиной того, что разработчики используют методологию тестирования приложений на проникновение для их обнаружения. Веб-приложения, однако, не имеют иммунитета и к более традиционным способам атаки. Весьма распространены плохие механизмы аутентификации, логические ошибки, непреднамеренное раскрытие информации, а также такие традиционные ошибки для обычных приложений как переполнение буфера. Приступая к тестированию Веб -приложений, необходимо учитывать все перечисленное, и должен применяться методический процесс тестирования ввода/вывода по схеме "черного ящика" в сочетании (если возможно) с аудитом исходного кода [ 13 ]. Существуют различные инструменты позволяющие производить автоматическое тестирование безопасности, выполняя такие задачи как cross site scripting, SQL injection, включая переполнение буфера, подделка параметра, несанкционированный доступ, манипуляции с HTTP запросами и т.д. [ 14 ] Нагрузочное тестирование Следующим видом тестирования является тест на устойчивость к большим нагрузкам – Load-testing, stress-test или performance test [ 15 ]. Такой тест имитирует одновременную работу нескольких сотен или тысяч посетителей (каждый из которых может "ходить" по сайту в соответствии со своим сценарием ), проверяя, будет ли устойчивой работа сайта под большой нагрузкой. Кроме этого, можно имитировать кратковременные пики нагрузки, когда количество посетителей скачкообразно увеличивается – это очень актуально для новостных ресурсов и других сайтов с неравномерной аудиторией. В таком тесте проверяется не только и не столько сам сайт, сколько совместная слаженная работа всего комплекса – аппаратной части сервера, веб-сервера, программного ядра (engine) и других компонентов сайта. Основными целями нагрузочного тестирования являются [ 15 ]: • оценка производительности и работоспособности приложения на этапе разработки и передачи в эксплуатацию; • оценка производительности и работоспособности приложения на этапе выпуска новых релизов, патч-сетов; • оптимизация производительности приложения, включая настройки серверов и оптимизацию кода; • подбор соответствующей для данного приложения аппаратной (программной платформы) и конфигурации сервера. В нагрузочное тестирование входят следующие тесты: Тестирование производительности (Performance testing) Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит [ 15 ]: • измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций; • определение количества пользователей, одновременно работающих с приложением; • определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций); • исследование производительности на высоких, предельных, стрессовых нагрузках. Стрессовое тестирование (Stress Testing) Стрессовое тестирование позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса [ 16 ]. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом, цели стрессового тестирования могут пересекаться с целями тестирования производительности. Объемное тестирование (Volume Testing) Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит [ 15 ]: • измерение времени выполнения выбранных операций при определенных интенсивности выполнения этих операций; • может производиться определение количества пользователей, одновременно работающих с приложением. Тестирование стабильности или надежности (Stability / Reliability Testing) Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Времена выполнения операций могут играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты, влияющие именно на стабильность работы. Моделирование Транзакций (Transaction Simulation, TS) Этот метод используется в большом числе различных продуктов, в частности, в пакетах AppManager и Vivinet Manager компании NetlQ. Метод TS основан на использовании программных GUI-роботов (GUI - Graphical User Interface) [ 17 ]. GUI-робот – это специальная программа, которая "заставляет" реальное пользовательское приложение работать в автоматическом режиме, без участия самого пользователя (человека). Примерами средств, предназначенных для создания GUI-роботов, являются пакеты Rational Visual Test и Rational Robot компании Rational Software, а также пакет WinRunner компании Mercury Interactive. Программный GUI-робот, как и реальный пользователь приложения, анализирует содержимое экрана и вводит данные с клавиатуры. Другими словами, он взаимодействует с пользовательским приложением через тот же интерфейс, что и человек. При этом GUI-робот работает по программе (скрипту), к коду которой всегда есть доступ (в отличие от кода самого пользовательского приложения). Поэтому, если в скрипт GUI-робота встроить специальные вызовы, например, перед началом и после окончания транзакции, то можно измерить время выполнения этой транзакции. Основное достоинство метода TS заключается в том, что он позволяет измерять производительность работы приложения "с точки зрения пользователя" и, при этом, не требует доступа к коду пользовательского приложения [ 18 ]. Недостаток же метода в том, что он позволяет измерять время выполнения только рабочих транзакций и не может использоваться для измерения времени выполнения системных транзакций. Метод "Анализ данных на стороне клиента" (Client Capture, CC) Данный метод реализован, например, в программном пакете Vital Suite компании Lucent [ 17 ]. Метод основан на извлечении данных о работе приложения из операционной системы компьютера, где установлено пользовательское приложение. Для этого на компьютере пользователя устанавливается специальный Агент, который отслеживает взаимодействие приложения и ОС и, таким образом, получает информацию о доступности и времени реакции пользовательского приложения. Достоинство данного метода в том, что при его использовании нет необходимости модернизировать код приложения. Недостаток – дополнительные накладные расходы на компьютере пользователя (клиента) и ограниченный набор поддерживаемых приложений. Метод "Анализ Сетевого Трафика" (Network Sniffing, NS) Примером такого устройства является NetScout WAN Probes, компании NetScout [ 17 ].Он основан на извлечении информации о производительности приложений из сетевого трафика. Для этого в сети устанавливаются специальные Зонды (как правило, аппаратные), которые в режиме реального времени захватывают сетевой трафик, анализируют его и "извлекают" данные о времени реакции приложений, доступности приложения и т.п. АРМ- средства на базе метода "Network Sniffing" выпускаются, в основном, производителями аппаратных анализаторов сетевых протоколов. Он имеет следующие недостатки. Во-первых, для того, чтобы в режиме реального времени из сетевого трафика извлекать информацию о времени реакции приложений, компьютеры, где установлены Зонды, должны иметь очень высокую производительность. Второй недостаток метода NS заключается в том, что Зонд может "понимать" только заранее заданный набор пользовательских приложений, что также ограничивает использование данного метода. Поскольку применение для целей тестирования большого числа клиентских машин с практической точки зрения нецелесообразно, встает задача обеспечения независимости пользовательских запросов, генерируемых одной или несколькими клиентскими машинами. В настоящее время применяются два способа обеспечения независимости запросов: использование многопоточности и создание распределенных систем [ 19 ]. Многопоточность в той или иной форме применяется во всех рассмотренных средствах тестирования. Данный метод не позволяет воспроизводить и в явной форме задавать характер потока запросов (равномерный, пульсирующий и т.д.) и его статистические характеристики (средняя величина интервала времени между последовательными запросами, дисперсия и др.). Величина выделяемого нити кванта времени (а, следовательно, и величина интервала между запросами) зависит от производительности вычислительной системы и ее загруженности, а также от алгоритмов разделения времени, применяемых операционной системой. Непредсказуемые колебания интенсивности генерируемого потока запросов не позволяют достоверно оценить стабильность работы сервера. Увеличение числа нитей повышает уровень независимости запросов, однако конкуренция между нитями снижает ур овень нагрузки, что делает данный подход неприменимым для тестирования высокопроизводительных серверов. Применение распределенных вычислений позволяет добиться большей реалистичности тестирования, так как статистические характеристики генерируемого потока запросов приближаются к характеристикам, наблюдаемым в условиях эксплуатации сервера. Кроме того, становится возможным увеличение интенсивности нагрузки. Однако применение данного подхода предъявляет значительно более высокие требования к архитектуре системы и планированию тестов. Проверка HTML-кода Еще одним типом тестирования является проверка верности HTML- кода страниц сайта [ 23 ]. Для такого рода тестирования написано множество утилит – от простых скриптов на Perl до мощных валидаторов, проверяющих весь сайт на соответствие стандартам (а некоторые валидаторы могут в автоматическом режиме исправлять найденные недочеты, например, пропущенные закрывающие теги и т.д.). Часто такие средства встраивают в Веб-редакторы, существуют браузеры с встроенными валидаторами. Например, FireBug интегрируется с браузером Firefox, чтобы обогатить инструментарий разработчика [ 24 ]. Вы сможете редактировать, отлаживать и исследовать CSS, HTML и JavaScript вживую, на любой веб-странице. Firebug предоставляет возможность делать экспериментальные изменения в HTML и смотреть, как они тут же отображаются на странице, производить мониторинг сетевых запросов. В комплекте с IE8 поставляется инструмент "средства разработчика", который, по сути, является аналогом FireBug [ 25 ]. Обзор автоматизации тестирования В процессе создания информационных систем нередки ошибки и дефекты – это вполне ожидаемое и нормальное явление, а в условиях ограниченных временных ресурсов и высоких требований к качеству программных продуктов неизбежно возникает необходимость в организации эффективного контроля и управления всем процессом тестирования. Контроль качества ПО невозможен сегодня без автоматизации всех задач тестирования [ 20 ]. Ручное тестирование является затратным по времени, трудоемким и часто монотонным процессом. Оно приводит к возникновению проблем, особенно при ограниченных ресурсах и жестких сроках. Если вам нужно улучшить тестирование приложений для проверки корректности их работы, важно двигаться в сторону автоматизации всех ручных задач тестирования. В современных условиях, когда циклы разработки сокращаются, автоматизированное тестирование позволяет как профессионалам, так и новичкам быстро достичь высококачественных результатов тестирования приложений. Инструментальные средства автоматизации записывают взаимодействие пользователей с приложением, а сформированные на этой основе сценарии используются для последующих тестов. В двух словах, автоматизация тестирования позволяет оптимизировать качество сложных приложений эффективным по стоимости способом за приемлемое время. Это помогает быстрее выпустить программное обеспечение более высокого качества. Процесс автоматизации тестирования делится на три этапа [ 20 ]: • Запись. Сценарий тестирования записывается "на лету" по мере работы пользователя с приложением. Можно также вставить точки верификации (verification points) для проверки ответа системы и сделать сценарии тестирования зависящими от данных, чтобы выполнять один и тот же сценарий с различными наборами входных данных. • Улучшение. Добавление кода, выполняющего разнообразные функции. Типичные изменения сценариев тестирования – условное ветвление, рефакторинг и обработка исключительных ситуаций. • Воспроизведение. Выполнение сценариев, эмулирующих действия, которые выполнял пользователь приложения при записи теста. Расхождения регистрируются, и тестировщик может сделать вывод о том, хорошо ли функционирует приложение или регрессионное тестирование выявило проблемы. Для автоматизации тестирования существует большое количество приложений. Наиболее популярные из них: • HP LoadRunner, HP QuickTest Professional, HP Quality Center; • Segue SilkPerformer; • IBM Rational FunctionalTester, IBM Rational PerformanceTester, IBM Rational TestStudio; • AutomatedQA TestComplete. HP LoadRunner – программный продукт для автоматизации нагрузочного тестирования широкого набора программных сред и протоколов [ 21 ]. Поддерживает SOA, работу с Web-сервисами, Ajax, RDP, SQL, продуктами Citrix, платформы Java, .Net, а также все основные ERP- и CRM-приложения от PeopleSoft, Oracle, SAP и Siebel. Пакет HP LoadRunner включает в себя более 60 мониторов сбора данных о тестируемой инфраструктуре и предоставляет детальную диагностику по работе приложений. HP LoadRunner состоит из следующих приложений [ 22 ]: • Virtual User Generator (VuGen) – служит для разработки нагрузочных скриптов; • Load Generator – служит для генерации нагрузки (генерации виртуальных пользователей); • Controller – служит для разработки и запуска сценариев нагрузки; • Analysis – служит для анализа результатов нагрузочного тестирования. Средства от IBM Rational [ 21 ]: • IBM Rational Robot – универсальное средство автоматизации тестирования общего назначения для команд разработчиков, выполняющих функциональное тестирование клиент-серверных приложений. Дает возможность обнаруживать неполадки в ПО благодаря расширению сценариев тестирования средствами условной логики, позволяющей целиком охватить тестируемое приложение. Robot позволяет создавать сценарии тестирования с вызовом внешних библиотек DLL или исполняемых модулей. • IBM Rational Performance Tester – инструмент нагрузочного и стрессового тестирования, с помощью которого можно выявлять проблемы системной производительности и их причины. Позволяет создавать тесты без написания кода и, не требуя навыков программирования. Обеспечивает гибкие возможности моделирования и эмуляции различных пользовательских нагрузок. Выполняет сбор и интеграцию данных о серверных ресурсах с данными о производительности приложений, получаемыми в режиме реального времени. • IBM Rational Functional Tester – набор средств автоматизированного тестирования, позволяющих выполнять функциональное и регрессионное тестирование, тестирование пользовательского интерфейса и тестирование, управляемое данными. Инструмент применяет технологию ScriptAssure (бесшовная проверка достоверности динамических данных) и функции поиска соответствия по шаблону, позволяющие повысить устойчивость сценариев тестирования в условиях частых изменений пользовательских интерфейсов приложений. Тестировщики могут выбрать язык сценариев для разработки и настройки тестов: Java в среде Eclipse или Microsoft Visual Basic .Net в среде Visual Studio .Net. • IBM Rational Quality Manager – решение для реализации процессов управления тестированием и качеством, поддерживает сотрудничество участников групп по разработке программных продуктов, предоставляя им возможность обмениваться информацией, применять средства автоматизации для сокращения графиков выполнения проектов, а также составлять отчеты по проектным показателям для принятия обоснованных решений. Rational Quality Manager может быть дополнен средством управления ресурсами тестирования Rational Test Lab, обеспечивающим учет ресурсов тестирования (серверов), их бронирование, автоматизацию развертывания тестовой среды на сервере и запуск скриптов тестирования, а также отчетность по использованию ресурсов тестирования. • Rational Quality Manager и Rational Test Lab созданы на базе открытой платформы Jazz, которая предоставляет стандартные интерфейсы и удобные возможности для интеграции с решениями партнеров и других производителей. Ключевые термины Функциональное тестирование, Тестирование пользовательского интерфейса, Ручное тестирование, Сценарии, Тестирования удобства использования, Проверка ссылок, Тестирование безопасности, Нагрузочное тестирование, Тестирование производительности, Стрессовое тестирование, Объемное тестирование, Тестирование стабильности, Моделирование Транзакций, Метод "Анализ данных на стороне клиента", Метод "Анализ Сетевого Трафика", Автоматизации тестирования, Проверка HTML-кода. |