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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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]