Курсовая работа (т): Разработка приложения, реализующего метод Флойда

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

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

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

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

Инструментарий для тестирования производительности.

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

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

Наиболее популярные инструменты для нагрузочного тестирования представлены ниже.

Стресс-тестирование.

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

Основные принципы.

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

Необходимость стресс-тестирования диктуется следующими факторами:

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

2.      В случае SLA-контракта (соглашения об уровне услуг) стоимость отказа системы в экстремальных условиях может быть очень велика.

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

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

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

Основные направления применения стресс-тестирования:

·    общее исследование поведения системы при пиковых нагрузках;

·        исследование обработки ошибок и исключительных ситуаций системой при пиковых нагрузках;

·        исследование узких мест системы или отдельных компонент при диспропорциональных нагрузках;

·        тестирование ёмкости системы.

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

Пропорциональная нагрузка.

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

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

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

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

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

Часто в "домашних" условиях тестирование стабильности совмещают со стресс-тестированием, то есть проверяют не только стабильность, но и способность приложения переносить жесткие условия и сильные нагрузки длительное время.

Юзабилити-тестирование - исследование, выполняемое с целью определения, удобен ли некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения. Таким образом, проверка эргономичности измеряет эргономичность объекта или системы. Проверка эргономичности сосредоточена на определённом объекте или небольшом наборе объектов, в то время как исследования взаимодействия человек-компьютер в целом - формулируют универсальные принципы.

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

Процесс.

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

Процесс тестирования фиксируется в протоколе (логе) и/или на аудио- и видеоустройства - с целью последующего более детального анализа.

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

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

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

.     Речь модератора и респондента;

2.      Выражение лица респондента (снимается на видеокамеру);

.        Изображение экрана компьютера, с которым работает респондент;

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

·    перемещение курсора и нажатия на клавиши мыши;

·        использование клавиатуры;

·        переходы между экранами (браузера или другой программы).

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

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

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

Тестирование безопасности.

Тестирование безопасности - оценка уязвимости программного обеспечения к различным атакам.

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

·        попытки узнать пароль с помощью внешних средств;

·              атака системы с помощью специальных утилит, анализирующих защиты;

·              подавление, ошеломление системы (в надежде, что она откажется обслуживать других клиентов);

·              целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;

·              просмотр несекретных данных в надежде найти ключ для входа в систему.

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

Локализация программного обеспечения.

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

Для локализации в английском языке иногда применяют сокращение "L10n". Где буквы "L" и "n" - начало и окончание слова Localization, а цифра 10 - количество букв между ними.

Тестирование по стратегии чёрного ящика.

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

Понятие "чёрного" ящика.

Под "чёрным ящиком" понимается объект исследования, внутреннее устройство которого неизвестно. Понятие "чёрный ящик" предложено У.Р. Эшби. В кибернетике оно позволяет изучать поведение систем, то есть их реакций на разнообразные внешние воздействия и в то же время абстрагироваться от их внутреннего устройства.

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

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

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

В настоящее время известны два вида "чёрных" ящиков. К первому виду относят любой "чёрный" ящик, который может рассматриваться как автомат, называемый конечным или бесконечным. Поведение таких "чёрных" ящиков известно. Ко второму виду относятся такие "чёрные" ящики, поведение которых может быть наблюдаемо только в эксперименте. В таком случае в явной или неявной форме высказывается гипотеза о предсказуемости поведения "чёрного" ящика в вероятностном смысле. Без предварительной гипотезы невозможно любое обобщение, или, как говорят, невозможно сделать индуктивное заключение на основе экспериментов с "чёрным" ящиком. Для обозначения модели "чёрного" ящика Н. Винером [2] предложено понятие "белого" ящика. "Белый" ящик состоит из известных компонентов, то есть известных X, Y, δ, λ. Его содержимое специально подбирается для реализации той же зависимости выхода от входа, что и у соответствующего "чёрного" ящика. В процессе проводимых исследований и при обобщениях, выдвижении гипотез и установления закономерностей возникает необходимость корректировки организации "белого" ящика и смены моделей. В связи с этим при моделировании исследователь должен обязательно многократно обращаться к схеме отношений "чёрный" - "белый" ящик.

Исследование поведения "черного" ящика.

Рассмотрим, как изучается и исследуется поведение "черного" ящика второго вида. Предположим, что дана некоторая система управления, внутреннее строение которой неизвестно. Система управления имеет входы  и выходы .

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

Стратегия тестирования по принципу "Белого ящика".

"Белый ящик" - тестирование кода на предмет логики работы программы и корректности её работы с точки зрения компилятора того языка, на котором она писалась.

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

Техника Белого ящика включает в себя следующие методы тестирования:

·    покрытие операторов;

·        покрытие решений;

·        покрытие условий;

·        покрытие решений и условий;

·        комбинаторное покрытие условий.