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

• Блочное (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

Приложение 2

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

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

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

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

$IsCoverable = true