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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

Объектом данного исследования являются подходы тестирования в зависимости от критерий приложения.

Из всего выше сказанного можно выделить цель данной работы: анализ фаз и технологий тестирования, подходы тестирования в зависимости от критерий приложения.

На основании определенной цели исследования, а также выявленного объекта и предмета исследования можно определить следующие задачи данной работы:

• Проанализировать теоритическую основу тестирования;
• Изучить направления тестирования производительности программ;
• Определить цели тестирования производительности;
• Рассмотреть подходы в зависимости от критерий приложения.

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

1. Теоритическая основа тестирования

1.1 Фазы и методы тестирования

При тестировании как правило выделяют три фазы:

• модульное,
• интеграционное
• системное тестирование.

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

Модульное тестирование – это тестирование программы на уровне отдельно взятых модулей, функций или классов. Цель модульного тестирования состоит в выявлении локализованных в модуле ошибок в реализации алгоритмов, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. Модульное тестирование проводится по принципу "белого ящика", то есть основывается на знании внутренней структуры программы, и часто включает те или иные методы анализа покрытия кода.[3,с.544]

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

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

Системное тестирование производится над проектом в целом с помощью метода "черного ящика". Структура программы не имеет никакого значения, для проверки доступны только входы и выходы, видимые пользователю. Тестированию подлежат коды и пользовательская документация.[5,с.384]

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

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

• Тестирование методом черного ящика;
• Тестирование методом белого ящика;
• Тестирование методом серого ящика.

Эти тесты обычно считаются самодостаточными в поиске ошибок и багов во всей системе.

Тестирование методом черного ящика осуществляется без каких-либо знаний внутренней работы системы. Тестер будет стимулировать программное обеспечение для пользовательской среды, предоставляя различные входы и тестируя сгенерированные выходы. Этот тест также известен как Black-box, closed-box тестирование или функциональное тестирование.[13,c.61]

В стратегии White Box (белый ящик) тестирования рассматривается внутренняя логика и структура кода. Его также называют стеклянным, структурным, открытым или прозрачным ящиком тестирования. Тесты, написанные на основе стратегии White Box тестирования включают покрытие написанного кода, ответвлений, путей, отчетности, внутренней логики кода и др. [13,c.67]

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

Серый ящик (gray/grey box) –это подход, сочетающий элементы двух предыдущих подходов, это

• с одной стороны, тестирование, ориентированное на пользователя, а значит, мы используем паттерны поведения пользователя, т.е. применяем методику "Черного ящика";
• с другой — информированное тестирование, т.е. мы знаем, как устроена хотя бы часть тестируемого бэк-энда, и активно используем это знание.[13,c.71]

Допустим, мы тестируем функциональность "регистрация":

• • заполняем все поля (имя, адрес, е-мейл и т.д.) и
  • нажимаем кнопку "Зарегистрироваться".

Следующая страница — подтверждение, дорогой Иванов Иван, поздравляем, вы зарегистрированы.

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

• страницы с подтверждением и
• новой записи в базе данных.

Откуда мы почерпнем знание о логике создания записей в базе данных при регистрации? Например, из технической документации (документ о дизайне/архитектуре системы, документ о дизайне кода), общения с программистом, самого кода. [13,c.72]

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

1.2 Критерии и метрики тестов

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

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

Еще одним важным понятием в теории тестирования является понятие критериев покрытия тестирования. Не следует путать метрики тестирования и критерии покрытия тестирования. Последние позволяют определить степень покрытия разрабатываемого продукта тестами. Поэтому часто критерии покрытия используются для определения метрик тестирования.

Приведем примеры самых распространенных критериев покрытия при тестировании функциональных требований в соответствии с методологией RUP.

При тестировании функциональных требований могут быть выделены, по крайней мере, два типа покрытия: покрытие, основанное на спецификации, и покрытие, основанное на коде.[6,c.296]

Покрытие, основанное на спецификации или на требованиях (Specification-Based Coverage or Requirements-based Test Coverage).

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

Таким образом, данный критерий показывает в процентном отношении количество покрытых тестами требований. Чаще всего данный критерий используется при тестировании методом «черного ящика».[1,c.31]

Покрытие, основанное на коде (Code-Based Coverage) имеет отношение к потоку управления и потоку данных программы. Чаще всего данный критерий используется при тестировании методом «белого ящика». Основные критерии покрытия тестирования кода следующие:

• Покрытие строк (Line Coverage) – мера измерения покрытия кода, указывающая процентное отношение строк программы, затронутых тестами, к общему числу строк. Это очень неточная метрика, потому что даже стопроцентное покрытие по ней пропускает много ошибок.
• Покрытие ветвей (Branch Coverage). Это мера измерения покрытия кода указывает в процентном отношении, сколько ветвей потока управления было протестировано во время теста. Она надежнее предыдущей метрики, но снова стопроцентное покрытие не гарантирует отсутствие ошибок.[1,c.34]
• Покрытие путей (Path Coverage). Эта единица измерения характеризует процент всевозможных путей (и/или комбинаций ветвей), которые покрываются тестами. Однако, даже не смотря на 100-процентное покрытие (достичь которого практически нереально в коммерческих системах) все еще могут присутствовать скрытые ошибки. .[5,c.384]

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

Какие же метрики собираются во время тестирования производительности?

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

2. Запросы в секунду. Клиентское приложение формирует HTTP-запрос и отправляет его на сервер. Серверное ПО данный запрос обрабатывает, формирует ответ и передает его обратно клиенту. Общее число запросов в секунду и есть интересующая нас метрика.[10,c.412]

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]

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

Часто в «домашних» условиях тестирование стабильности совмещают со стресс-тестированием, то есть проверяют не только стабильность, но и способность приложения переносить жесткие условия и сильные нагрузки длительное время.[3,c.544]

Тестирование стабильности проводится с целью убедиться в том, что приложение выдерживает ожидаемую нагрузку в течение длительного времени. При проведении этого вида тестирования осуществляется наблюдение за потреблением приложением памяти, чтобы выявить потенциальные утечки. Кроме того, такое тестирование выявляет деградацию производительности, выражающуюся в снижении скорости обработки информации и (или) увеличении времени ответа приложения после продолжительной работы по сравнению с началом теста.[17]

Оценивание надежности программных комплексов включает измерение количественных характеристик: завершенности, устойчивости к дефектам, восстанавливаемости и доступности-готовности . При этом предполагается, что в контракте, техническом задании или спецификации требований зафиксированы, и утверждены заказчиком определенные значения этих характеристик и их приоритеты. Измерения проводятся при функционировании готового программного комплекса для сопоставления с заданными требованиями и для оценивания рисков соответствия этим требованиям. Тестирование для оценки надежности комплекса программ должно проводиться в тестовом окружении, которое максимально приближено к реальным условиям применения системы. Входные параметры тестов следует задавать на основе вероятностного распределения соответствующих характеристик или их наборов при эксплуатации программногоmкомплекса.[17]
Для прямых, количественных измерений надежности необходимы инструментальные средства, встроенные в операционную систему или в соответствующие компоненты комплекса программ. Эти средства должны в динамике реального функционирования программ, автоматически селектировать и регистрировать аномальные ситуации, дефекты и искажения вычислительного процесса, программ и данных, выявляемые аппаратным, программно-алгоритмическим контролем или пользователями. Накопление и систематизация проявлений дефектов при исполнении программ позволяет оценивать основные показатели надежности, помогает определять причины сбоев и отказов и подготавливать данные для повышения надежности программных комплексов. Регулярная регистрация и обобщение таких данных способствует устранению ситуаций, негативно влияющих на функциональную пригодность и другие важные динамические характеристики. [15]

2.3 Конфигурационное тестирование

Конфигурационное тестирование — ещё один из видов традиционного тестирования производительности. В этом случае вместо того, чтобы тестировать производительность системы с точки зрения подаваемой нагрузки, тестируется эффект влияния на производительность изменений в конфигурации. Хорошим примером такого тестирования могут быть эксперименты с различными методами балансировки нагрузки. Конфигурационное тестирование также может быть совмещено с нагрузочным, стресс или тестированием стабильности.[4,c.21]

В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

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

2. Проект по миграции системы с одной платформы на другую. Цель Тестирования: Проверить объект тестирования на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.[12,c.25]

Уровни проведения тестирования. Для клиент–серверных приложений конфигурационное тестирование можно условно разделить на два уровня (для некоторых типов приложений может быть актуален только один): серверный или клиентский.

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

1. Аппаратные средства (тип и количество процессоров, объем памяти, характеристики сети / сетевых адаптеров и т.д.)

2. Программные средства (ОС, драйвера и библиотеки, стороннее ПО, влияющее на работу приложения и т.д.). [14]

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

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

1. Тип, версия и битность операционной системы (подобный вид тестирования называется кросс–платформенное тестирование)

2. Тип и версия Web браузера, в случае если тестируется Web приложение (подобный вид тестирования называется кросс–браузерное тестирование)

3. Тип и модель видео адаптера (при тестировании игр это очень важно)

4. Работа приложения при различных разрешениях экрана

5. Версии драйверов, библиотек и т.д. (для JAVA приложений версия JAVA машины очень важна, тоже можно сказать и для .NET приложений касательно версии .NET библиотеки) и т.д.[15]

Порядок проведения конфигурационного тестирования. Перед началом проведения конфигурационного тестирования рекомендуется:

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

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

3. Определение целей тестирования производительности

В общих случаях тестирование производительности может служить разным целям.[12,c.19]

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

Многие тесты на производительность делаются без попытки осмыслить их реальные цели. Перед началом тестирования всегда должен быть задан бизнес-вопрос: «Какую цель мы преследуем, тестируя производительность?». Ответы на этот вопрос являются частью технико-экономического обоснования (или business case) тестирования. Цели могут различаться в зависимости от технологий, используемых приложением, или его назначения, однако, они всегда включают что-то из нижеследующего:

1.Параллелизм / Пропускная способность:

• Если конечными пользователями приложения считаются пользователи, выполняющие логин в систему в любой форме, то в этом случае крайне желательно достижение параллелизма. По определению это максимальное число параллельных работающих пользователей приложения, поддержка которого ожидается от приложения в любой момент времени. Модель поведения пользователя может значительно влиять на способность приложения к параллельной обработке запросов, особенно если он включает в себя периодически вход и выход из системы.[12,c.23]
• Если концепция приложения не заключается в работе с конкретными конечными пользователями, то преследуемая цель для производительности будет основана на максимальной пропускной способности или числе транзакций в единицу времени. Хорошим примером в данном случае будет являться просмотр веб-страниц, например, на портале Wikipedia.

2. Время ответа сервера.

Эта кон­цеп­ция стро­ит­ся во­круг вре­ме­ни от­ве­та од­но­го узла при­ло­же­ния на за­прос, по­слан­ный дру­гим. Про­стым при­ме­ром яв­ля­ет­ся HTTP 'GET' за­прос из бра­у­зе­ра ра­бо­чей стан­ции на веб-сер­вер. Прак­ти­че­ски все при­ло­же­ния, раз­ра­бо­тан­ные для на­гру­зоч­но­го те­сти­ро­ва­ния ра­бо­та­ют имен­но по этой схеме из­ме­ре­ний. Ино­гда це­ле­со­об­раз­но ста­вить за­да­чи по до­сти­же­нию про­из­во­ди­тель­но­сти вре­ме­ни от­ве­та сер­ве­ра среди всех узлов при­ло­же­ния.[12,c.27]

3.Время отображения.

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

4. Требования к производительности.

Очень важно де­та­ли­зи­ро­вать тре­бо­ва­ния к про­из­во­ди­тель­но­сти и до­ку­мен­ти­ро­вать их в ка­ком-ли­бо плане те­сти­ро­ва­ния про­из­во­ди­тель­но­сти. В иде­аль­ном слу­чае это де­ла­ет­ся на ста­дии раз­ра­бот­ки тре­бо­ва­ний при раз­ра­бот­ке си­сте­мы, до про­ра­бот­ки де­та­лей её ди­зай­на. См. Ин­же­не­рия про­из­во­ди­тель­но­сти.[12,c.30]

Од­на­ко те­сти­ро­ва­ние производительности часто не про­во­дит­ся со­глас­но спе­ци­фи­ка­ции, так как нет за­фик­си­ро­ван­но­го по­ни­ма­ния о мак­си­маль­ном вре­ме­ни от­ве­та для за­дан­но­го числа поль­зо­ва­те­лей. Те­сти­ро­ва­ние про­из­во­ди­тель­но­сти часто ис­поль­зу­ет­ся как часть про­цес­са про­фай­лин­га про­из­во­ди­тель­но­сти. Его идея за­клю­ча­ет­ся в том, чтобы найти «сла­бое звено» — такую часть си­сте­мы, соп­ти­ми­зи­ро­вав время ре­ак­ции ко­то­рой, можно улуч­шить общую про­из­во­ди­тель­ность си­сте­мы. Опре­де­ле­ние кон­крет­ной части си­сте­мы, сто­я­щей на этом кри­ти­че­ском пути, ино­гда очень непро­стая за­да­ча, по­это­му неко­то­рые при­ло­же­ния для те­сти­ро­ва­ния вклю­ча­ют в себя (или могут быть до­бав­ле­ны с по­мо­щью add-on’ов) ин­стру­мен­ты, за­пу­щен­ные на сер­ве­ре (аген­ты) и на­блю­да­ю­щие за вре­ме­нем вы­пол­не­ния тран­зак­ций, вре­ме­нем до­сту­па к базе дан­ных, овер­хе­да­ми сети и дру­ги­ми по­ка­за­те­ля­ми сер­вер­ной части си­сте­мы, ко­то­рые могут быть про­ана­ли­зи­ро­ва­ны вме­сте с осталь­ной ста­ти­сти­кой по про­из­во­ди­тель­но­сти.[12,c.43]

Те­сти­ро­ва­ние производительности может про­во­дить­ся с ис­поль­зо­ва­ни­ем гло­баль­ной сети и даже в гео­гра­фи­че­ски уда­лен­ных ме­стах, если учи­ты­вать тот факт, что ско­рость ра­бо­ты сети Ин­тер­нет за­ви­сит от ме­сто­по­ло­же­ния. Оно также может про­во­дить­ся и ло­каль­но, но в этом слу­чае необ­хо­ди­мо на­стро­ить се­те­вые марш­ру­ти­за­то­ры таким об­ра­зом, чтобы по­яви­лась за­держ­ка, при­сут­ству­ю­щая во всех пуб­лич­ных сетях. На­груз­ка, при­ла­га­е­мая к си­сте­ме, долж­на сов­па­дать с ре­аль­ным по­ло­же­ни­ем дел. Так на­при­мер, если 50 % поль­зо­ва­те­лей си­сте­мы для до­сту­па к си­сте­ме ис­поль­зу­ют се­те­вой канал ши­ри­ной 56К, а дру­гая по­ло­ви­на ис­поль­зу­ет оп­ти­че­ский канал, то ком­пью­те­ры, со­зда­ю­щие те­сто­вую на­груз­ку на си­сте­му долж­ны ис­поль­зо­вать те же со­еди­не­ния (иде­аль­ный ва­ри­ант) или эму­ли­ро­вать за­держ­ки вы­ше­ука­зан­ных се­те­вых со­еди­не­ний, сле­дуя за­дан­ным про­фай­лам поль­зо­ва­те­лей.[15]

Прямыми или косвенными целями любого тестирования, так или иначе затрагивающего вопросы производительности, является:

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

Таким образом, тестирование производительности позволяет обнаружить и устранить широкий спектр потенциальных проблем, которые программное средство может начать испытывать на стадии эксплуатации.[12,c.19]

4. Подходы в зависимости от категорий приложений

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

• Блочное (Unit testing) — тестирование одного модуля в изоляции.
• Интеграционное (Integration Testing) — тестирование группы взаимодействующих модулей.
• Системное (System Testing) — тестирование системы в целом.

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

1.Блочноебтестирование.
Блочное (модульное, unit testing) тестирование наиболее понятное для программиста. Фактически это тестирование методов какого-то класса программы в изоляции от остальной программы. 
Не всякий класс легко покрыть unit тестами. При проектировании нужно учитывать возможность тестируемости и зависимости класса делать явными. Чтобы гарантировать тестируемость можно применять TDD методологию, которая предписывает сначала писать тест, а потом код реализации тестируемого метода. Тогда архитектура получается тестируемой. Распутывание зависимостей можно осуществить с помощью Dependency Injection. Тогда каждой зависимости явно сопоставляется интерфейс и явно определяется как инжектируется зависимость — в конструктор, в свойство илиовометод.[9,c.508]
Для осуществления unit тестирования существуют специальные фреймворки. Например, NUnit или тестовый фреймфорк из Visual Studio 2008. Для возможности тестирования классов в изоляции существуют специальные Mock фреймворки. Например, Rhino Mocks. Они позволяют по интерфейсам автоматически создавать заглушки для классов-зависимостей, задавая у них требуемоелповедение.[10,c.412]
По unit тестированию написано много статей. Мне очень нравится MSDN статья Write Maintainable Unit Tests That Will Save You Time And Tears, в которой хорошо и понятно рассказывается как создавать тесты, поддерживать которые со временем не становится обременительно.

2.Интеграционноеотестирование.
Интеграционное тестирование, на мой взгляд, наиболее сложное для понимания. Есть определение — это тестирование взаимодействия нескольких классов, выполняющих вместе какую-то работу. Однако как по такому определению тестировать не понятно. Можно, конечно, отталкиваться от других видов тестирования. Но это чревато.
Если к нему подходить как к unit-тестированию, у которого в тестах зависимости не заменяются mock-объектами, то получаем проблемы. Для хорошего покрытия нужно написать много тестов, так как количество возможных сочетаний взаимодействующих компонент — это полиномиальная зависимость. Кроме того, unit-тесты тестируют как именно осуществляется взаимодействие (см. тестирование методом белого ящика). Из-за этого после рефакторинга, когда какое-то взаимодействие оказалось выделенным в новый класс, тесты рушатся. Нужно применять менее инвазивный метод.
Подходить же к интеграционному тестированию как к более детализированному системному тоже не получается. В этом случае наоборот тестов будет мало для проверки всех используемых в программе взаимодействий. Системное тестирование слишком высокоуровневое.
Хорошая статья по интеграционному тестированию мне попалась лишь однажды — Scenario Driven Tests. Прочтя ее и книгу Ayende по DSL DSLs in Boo, Domain-Specific Languages in .NET у меня появилась идея как все-таки устроитьлинтеграционноелтестирование.[13,c.61]
Идея простая. У нас есть входные данные, и мы знаем, как программа должна отработать на них. Запишем эти знания в текстовый файл. Это будет спецификация к тестовым данным, в которой записано, какие результаты ожидаются от программы. Тестирование же будет определять соответствие спецификации и того, что действительно находит программа. Проиллюстрирую на примере. (Приложение 2)

3.Системноемтестирование.
Системное — это тестирование программы в целом. Для небольших проектов это, как правило, ручное тестирование — запустил, пощелкал, убедился, что (не) работает. Можно автоматизировать. К автоматизации есть дважподхода.[7,c.432]
Первый подход — это использовать вариацию MVC паттерна — Passive View (вот еще хорошая статья по вариациям MVC паттерна) и формализовать взаимодействие пользователя с GUI в коде. Тогда системное тестирование сводится к тестированию Presenter классов, а также логики переходов между View. Но тут есть нюанс. Если тестировать Presenter классы в контексте системного тестирования, то необходимо как можно меньше зависимостей подменять mock объектами. И тут появляется проблема инициализации и приведения программы в нужное для начала тестирования состояние. В упомянутой выше статье Scenario Driven Tests об этом говорится подробнее.
Второй подход — использовать специальные инструменты для записи действий пользователя. То есть в итоге запускается сама программа, но щелканье по кнопкам осуществляется автоматически. Для .NET примером такого инструмента является White библиотека. Поддерживаются WinForms, WPF и еще несколько GUI платформ. Правило такое — на каждый use case пишется по скрипту, который описывает действия пользователя. Если все use case покрыты и тесты проходят, то можно сдавать систему заказчику. Акт сдачи-приемки должен подписать.[11,c.527]

ЗАКЛЮЧЕНИЕ

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

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

Далее были рассмотрены фазы и методы тестирования. При тестировании как правило выделяют три фазы:

• модульное,
• интеграционное
• системное тестирование.

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

• Метод «белого ящика».
• Метод «черного ящика».
• Метод «серого ящика».

В тестировании производительности различают несколько направлений, а именно:

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

В своей работе я основывался на трёх основных направлениях,таких как :

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

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

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

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

Список литературы

1. Борзов Ю.В., Уртанг Г.Б., Шимаров В.А. «Выбор путей программы для построения тестов» УСиМ. – 1989. – N.6 – с.29-36
2. Дастин Э., Рэшка Дж., Пол Дж. «Автоматизированное тестирование программного обеспечения» Изд. Лори 2003, 310 с.
3. Канер С., Фолк ДЖ., Нгуен Енг. «Тестирование программного обеспечения» К.: Диасофт, 2000 – 544 с.
4. Карлбертсон Р., Браун К., Кобб Г. «Быстрое тестирование» Изд. Вильямс 2002, 216 с.
5. Липаев В.В. «Отладка сложных программ: Методы, средства, технология.» М.: Энергоатомиздат, 1993, 384 с.
6. Липаев В.В.Тестирование программМ.: Радио и связь, 1986. – 296 с.
7. Макгрегор Дж., Сайкс Д. «Тестирование объектно-ориентированного программного обеспечения» К.: Диасофт, 2002. – 432 с.
8. Майерс Г. «Искусство тестирования программ.» М.: Финансы и статистика, 1982, 176 с.
9.  С.А. Орлов Технологии разработки программного обеспечения: учебник. — 4-е изд. — СПб.: Питер, 2012. — 508 с. — ISBN: 9785459011012.
10.  С.А. Орлов Технологии разработки программного обеспечения: учебник. — 4-е изд. — СПб.: Питер, 2012. — 412 с. — ISBN: 9785459011012.
11. С.А. Орлов Технологии разработки программного обеспечения: Учебник для вузов. 3-е изд. – СПб.: Питер, 2004. – 527 с.: ил.
12. Шимаров В.А. «Тестирование программ: цели и особенности инструментальной поддержки//Программное обеспечение ЭВМ / АН БССР. Институт математики.» Минск, 1994. – Вып. 100 – с.19 – 43
13. Boehm, Barry W.«A Spiral Model of Software Development and Enhancement»IEEE Computer, Vol. 21, no. 5 (May 1988), pp 61-72.
14. Humphrey, Watts S. «Managing the Software Process.» Reading, MA: Addison-Wesley, 1989.(перевод)
15. Marks, David M. «Testing Very Big Systems.» New-York: Bellcore (McGraw-Hill), 1992.(перевод).
16. Бек У. Заблуждение глобализма / У. Бек // Перспективы. URL: http://www.perspektivy.info/print.php?ID=36187. (Дата обращения: 01.03.2019).
17. Липаев В.В.. Экономика производства программных продуктов.. 2011/Липае В.В./// Перспективы. URL: https://scibook.net/informatika_1210/testirovanie-nadejnosti-bezopasnosti-66213.html (Дата обращения: 01.03.2019).

ПРИЛОЖЕНИЕ

Приложение 1

Таблица 1

ПО	Наименование производителя	Комментарии
OpenSTA	'Open System Testing Architecture'	Свободно распространяемое программное обеспечение для нагрузочного/стресс тестирования, лицензированное GNU GPL. Использует распределенную архитектуру приложений, основанную на CORBA. Доступна версия под Windows, хотя имеются проблемы с совместимостью с Windows Vista. Поддержка прекращена в 2007 году.
IBM Rational Performance Tester	IBM	Основанное на среде разработки Eclipse ПО, позволяющее создавать нагрузку больших объёмов и измерять время отклика для приложений с клиент-серверной архитектурой. Требует лицензирования.
JMeter	Открытый проект Apache Jakarta Project	Основанный на Java кроссплатформенный инструментарий, позволяющий производить нагрузочные тесты с использованием JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP соединений. Даёт возможность создавать большое количество запросов с разных компьютеров и контролировать процесс с одного из них.
HP LoadRunner	HP	Инструмент для нагрузочного тестирования, изначально разработанный для эмуляции работы большого количество параллельно работающих пользователей. Также может быть использован для unit- или интеграционного.
SilkPerformer	Micro Focus
Visual Studio Load Test	Microsoft	Visual Studio предоставляет инструмент для тестирования производительности включая load / unit testing

Приложение 2

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

1) Допустим в присланных документах есть несколько разделов. Тогда в спецификации мы можем указать, что у разбираемого документа должны быть разделы с указанными именами:

$SectionNames = Введение, Текст статьи, Заключение, Литература

2) Другой пример. При конвертировании нужно разбивать геометрические фигуры на примитивы. Разбиение считается удачным, если в сумме все примитивы полностью покрывают оригинальную фигуру. Из присланных документов выберем различные фигуры и для них напишем свои спецификации. Факт покрываемости фигуры примитивами можно отразить так:

$IsCoverable = true

Приложение 3

Таблица 2 – Цели различных видов тестирования производительности

ВИД ТЕСТИРОВАНИЯ ПРОИЗВОДИТЕЛЬНОСТИ	ЦЕЛИ
Тестирование производительности	оценка времени выполнения операций при определённой интенсивности и очерёдности выполнения этих операций; оценка реакции на изменение количества пользователей, одновременно работающих с приложением; оценка границ интенсивности нагрузки, при которых производительность выходит за рамки приемлемой; оценка показателей масштабируемости приложения.
Нагрузочное тестирование	оценка скорости реакции приложения на различные значения нагрузки в допустимых пределах; оценка использования приложением системных ресурсов при различных значениях нагрузки; оценка изменения со временем поведения приложения при сохранении допустимой нагрузки длительное время.
Стрессовое тестирование	оценка реакции приложения на нестандартные и стрессовые случаи изменения нагрузки, в т.ч.: резкое непредсказуемое изменение интенсивности нагрузки, значительное превышение предельно допустимой нагрузки,  интенсивное использование функций приложения, являющихся "узким местом" в производительности.
Объёмное тестирование	оценка показателей производительности приложения в случаях приёма, обработки и генерации данных различного объёма и с различными показателями вычислительной сложности обработки; оценка способности приложения обрабатывать большие объёмы данных в условиях высокой загрузки системных вычислительных ресурсов; оценка способности приложения обрабатывать большие объёмы данных при недостатке оперативной памяти.