Файл: Тестирование производительности программ : подходы в зависимости от категорий приложений.pdf

3.Транзакции в секунду. Пользовательские транзакции – это последовательность действий пользователя в интерфейсе. Сравнивая реальное время прохождения транзакции с ожидаемой (или количество транзакций в секунду), вы сможете сделать вывод о том, насколько успешной системой было пройдено нагрузочное тестирование.

4. Число виртуальных пользователей в единицу времени также позволяет выяснить, отвечает ли производительность приложения заявленным требованиям. Если вы все делаете правильно и ваши сценарии максимально приближены к поведению пользователя, то один виртуальный пользователь будет равен одному реальному пользователю.

5. Процент ошибок рассчитывается как отношение невалидных ответов к валидным за промежуток времени.

Желаемые показатели данных метрик указываются в требованиях к программному обеспечению. Но это в идеале. Если эти данные не прописаны, руководитель команды по тестированию должен прояснить этот момент с заказчиком. .[5,c.384]

1.3 Особенности процесса

Основные особенности процесса тестирования по:

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

На начальных этапах процессы разработки и тестирования часто практически смыкаются, однако целесообразно, по возможности, разделять их методически, инструментально и организационно (по исполняющим специалистам). Для сложного ПО систематическому тестированию программ приходится уделять столько же времени и сил, сколько непосредственно разработке. Недооценка необходимости планомерного тестирования в процессе разработки приводит к резкому возрастанию затрат на выявление и исправление ошибок в процессе завершающих испытаний и эксплуатации, а также к снижению надежности использования такого ПО.[1,c.36]

Модели внешней среды и совокупные наборы тестов по своей сложности сопоставимы с самими тестируемыми объектами и также не гарантированы от ошибок. В результате в программах и данных всегда остаются ошибки, часть из которых проявляется позже, в процессе эксплуатации ПО в реальных условиях.[11,c.527]

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

Для удостоверения качества, надежности и безопасности применения сложных, критических информационных систем, используемое в них ПО следует подвергать обязательной сертификации аттестованными, проблемно-ориентированными испытательными лабораториями.[3,c.544]

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

Специалисты – сертификаторы имеют право на расширение условий испытаний и на создание различных критических и стрессовых ситуаций в пределах нормативной документации, описывающей условия, в которых должны обеспечиваться качество и надежность решения предписанных задач. Если все испытания проходят успешно, то на соответствующую версию ПО оформляется специальный документ – сертификат соответствия. Данный документ официально подтверждает соответствие функций и характеристик испытанных средств стандартам, нормативным и эксплуатационным документам, а также подтверждает допустимость их применения в определенной области.[1,c.29]

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

Сложность программ, а также доступные для сертификации ресурсы становятся косвенными факторами, влияющими на выбор методов испытаний, а также на достигаемое качество и надежность ПО.

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

Стандартизация процессов отражается не только на их технико-экономических показателях, но и на качестве создаваемого ПО и его компонентов.

Наиболее полно проблемы качества ПО раскрыты в стандарте ISO 9000-3:1991 – Общее руководство качеством и стандарты по обеспечению качества. Ч. 3. Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживанию программного обеспечения.[16]

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

Руководящие указания предназначены для унификации методов разработки и поставки ПО, а также способов обеспечения и контроля их качества, отвечающих требованиям заказчика.[17]

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

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

Руководство компании-поставщика должно документально оформить цели, технологию и свои обязательства по обеспечению качества ПО. Должны быть определены ответственность, полномочия и взаимодействие всего руководящего, исполняющего работы и контролирующего персонала, который влияет на качество создаваемого комплекса программ.[11,c.527]

Действия по обеспечению и проверке качества программ должны производиться персоналом поставщика, независимым от специалистов, непосредственно ответственных за выполнение работ по созданию изделий.[13,c.70]

В состав действий по обеспечению и проверке качества программ входят:

• • • Анализ проекта.
    • Проверка системы обеспечения качества.
    • Тестирование.
    • Контроль и испытания ПО (под управлением ответственного представителя заказчика) при:
    • проектировании,
    • производстве,
    • монтаже и обслуживании.

2. Направления тестирования производительности программ

2.1 Нагрузочное тестирование

В тестировании производительности различают следующие направления:

• нагрузочное (load)
• стресс (stress)
• тестирование стабильности (endurance or soak or stability)
• конфигурационное (configuration)

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

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

В данном исследовании я основываюсь на 3 направления тестирования производительности программ, а именно:

• нагрузочное тестирование;
• тестирование стабильности;
• конфигурационное тестирование.

Нагрузочное тестирование (load testing) — подвид тестирования производительности, сбор показателей и определение производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству). Наиболее популярные инструменты для нагрузочного тестирования : OpenSTA, IBM Rational Performance Tester, JMeter, Visual Studio Load Test.(Приложение 1)

Для исследования времени отклика системы на высоких или пиковых нагрузках производится стресс-тестирование, при котором создаваемая на систему нагрузка превышает нормальные сценарии её использования. Не существует чёткой границы между нагрузочным и стресс-тестированием, однако эти понятия не стоит смешивать, так как эти виды тестирования отвечают на разные бизнес-вопросы и используют различную методологию.[1,c.33]

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

1. Уникальность запросов

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

2. Время отклика системы

В общем случае время отклика системы подчиняется функции  нормального распределения.[15]

В частности это означает, что имея достаточное количество измерений, можно определить вероятность скоторой отклик системы на запрос попадёт в тот или иной интервал времени.

3. Зависимость времени отклика системы от степени распределённости этой системы.

Дисперсия нормального распределения времени отклика системы на  запрос пропорциональна отношениюбколичества узлов системы,параллельно обрабатывающих такие запросы и количеству запросов, приходящихся на каждый узел.[13,c.67]

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

4. Разброс времени отклика системы

Из утверждений 1, 2 и 3 можно также сделать следующий вывод, что при достаточно большом количестве измерений величины времени обработки запроса в любой системе всегда найдутся  запросы, время обработкиикоторых превышает определённые в требованиях максимумы; причем, чем больше суммарное времяпроведения эксперимента, тем выше окажутся новые максимумы.

Этот факт необходимо учитывать при формировании требований к  производительности системы, а также припроведении регулярного  нагрузочного тестирования.[7,c.432]

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

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

Часто невозможно учесть все аспекты профиля нагрузки для сложных  систем, так как чем сложнее система, тем больше времени будет затрачено напроектирование, программирование и поддержку адекватного профиля нагрузки для неё, что не всегда является необходимостью. Оптимальный подход в данном случаелзаключается в балансировании между стоимостью  разработки теста и покрытием функциональности системы, в результате  которого появляются допущения о влиянии на общую производительность  той или иной части тестируемой системы.[9,c.508]

2.2 Тестирование стабильности

Тестирование стабильности или надежности (Stability / Reliability Testing) — один из видов автоматизированного тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.[1,c.31]

Перед тем как подвергать ПО экстремальным нагрузкам стоит провести проверку стабильности в предполагаемых условиях работы, то есть погрузить продукт в полную рабочую атмосферу. При тестировании, длительность его проведения не имеет первостепенного значения, основная задача — наблюдая за потреблением ресурсов, выявить утечки памяти и проследить чтобы скорость обработки данных и (или) время отклика приложения в начале теста и с течением времени не уменьшалась. В противном случае вероятны сбои в работе продукта и перезагрузки системы.[2,c.310]