Дайте характеристику нефункциональных видов тестирования
Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает.
Ниже перечислены основные виды нефункциональных тестов:
- Все виды тестирования производительности:
- нагрузочное тестирование (Performance and Load Testing)
- стрессовое тестирование (Stress Testing)
- тестирование стабильности или надежности (Stability / Reliability Testing)
- объемное тестирование (Volume Testing)
· Тестирование установки (Installation testing)
· Тестирование удобства пользования (Usability Testing)
· Тестирование на отказ и восстановление (Failover and Recovery Testing)
· Конфигурационное тестирование (Configuration Testing)
· Дайте характеристику связанных с изменениями видов тестирования
После проведения необходимых изменений, таких как исправление бага/дефекта, программное обеспечение должно быть пере тестировано для подтверждения того факта, что проблема была действительно решена.
Ниже перечислены виды тестирования, которые необходимо проводить после установки программного обеспечения, для подтверждения работоспособности приложения или правильности осуществленного исправления дефекта:
- Дымовое тестирование (Smoke Testing)
- Регрессионное тестирование (Regression Testing)
- Тестирование сборки (Build Verification Test)
- Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)
· Что такое тестирование производительности?
Нагрузочное тестирование или тестирование производительности - это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком либо общем (разделяемом ими) ресурсе.
· Каковы основные виды нагрузочного тестирования (производительности)
В нагрузочное тестирование входят следующие виды тестирования производительности:
· Тестирование собственно производительности (Performance testing)
· Стрессовое тестирование (Stress Testing)
· Объемное тестирование (Volume Testing)
· Тестирование стабильности или надежности (Stability / Reliability Testing)
· Load vs Performance Testing
· Тестирование собственно производительности (Performance testing)
Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:
- измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций
- определение количества пользователей, одновременно работающих с приложением
- определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций)
- исследование производительности на высоких, предельных, стрессовых нагрузках
· Стрессовое тестирование (Stress Testing)
Стрессовое тестирование позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.
Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера.
Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом цели стрессового тестирования могут пересекаться с целями тестирования производительности.
· Объемное тестирование (Volume Testing)
Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения, при этом происходит:
- измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций
- может производиться определение количества пользователей, одновременно работающих с приложением
· Тестирование стабильности/надежности (Stability / Reliability Testing)
Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Времена выполнения операций могут играть в данном виде тестирования второстепенную роль.
При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты влияющие именно на стабильность работы.
· Load vs Performance Testing
В англоязычной терминологии вы можете так же найти еще один вид тестирования - Load Testing - тестирование реакции системы на изменение нагрузки (в пределе допустимого).
Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времен отклика) на разных нагрузках.
Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.
· Отличие нагрузочного тестирования от стресс тестирования?
Задачей нагрузочного тестирования является определение масштабируемости приложения под нагрузкой. При этом происходит:
· измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.
· определение количества пользователей, одновременно работающих с приложением.
· определение границ приемлемой производительности при увеличении нагрузки (при увеличении интенсивности выполнения этих операций)
· исследование производительности на высоких, предельных, стрессовых нагрузках.
Задачей стрессового тестирования является проверка насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.
Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера.
Также одной из задач при стрессовом тестировании может быть оценка деградации производи-тельности.
Таким образом цели стрессового тестирования могут пересекаться с целями тестирования производительности.
· Цели преследуемые стресс и нагрузочным тестированием ?
Основными целями нагрузочного тестирования являются:
- Оценка производительности и работоспособности приложения на этапе разработки и передачи в эксплуатацию
- Оценка производительности и работоспособности приложения на этапе выпуска новых релизов, патч-сетов
- Оптимизация производительности приложения, включая настройки серверов и оптимизацию кода
- Подбор соответствующей для данного приложения аппаратной (программной платформы) и конфигурации сервера
Заметим, что в рамках одной цели могут использоваться разные виды тестов производительности и нагрузки, например, для первой, второй и третьей цели нужно производить как тестирование производительности так и тестирование стабильности.
Но при планировании нагрузочного тестирования логичнее все же отталкиваться от технических целей (а не коммерческих, перечисленных выше), которые достигаются в результате тестирования и классифицировать тесты по ним:
- Если интересует исследование производительности приложения, а именно времена отклика для операций на разных нагрузках в довольно широких диапазонах, включая стрессовые нагрузки то это все таки тестирование производительности (Performance Testing)
- Если целью является понимание насколько приложение устойчиво в режиме длительного использования (исключение утечек памяти, некорректных конфигурационных настроек и т.д.) то проводится долгий нагрузочный тест - это тестирование стабильности (Stability Testing).
При этом анализ времен отклика может иметь место, но не быть первым приоритетом, главное чтобы система "не упала".
- Стресс тестирование (Stress Testing) имеет своей целью проверить возвращается ли система после запредельной нагрузки (и как скоро) к нормальному режиму.
Также целями стрессового тестирования могут быть проверки поведения системы в случаях когда, один из серверов приложения в пуле перестаёт работать, аварийно изменилась аппаратная конфигурации сервера базы данных и т.д.
Отметим также, что при стрессовом тестировании проверяется не производительность системы, а её способность к регенерации после сверх нагрузки .
Главное все-таки в том, чтобы понимать цели того или иного тестирования и постараться их достигнуть.
· Терминология в нагрузочном тестировании
Чтобы обсуждать подходы к нагрузочному тестированию и проблемы решаемые с его помощью, предлагаем начать с терминологии. Понимая под различными терминами одни и те же сущности можно говорить на "одном языке".
Нагрузочное тестирование или Тестирование производительности - это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком либо общем (разделяемом ими) ресурсе.
В качестве примера можно привести работу сотрудников современного банка, в котором все работают с одними и теми же программными приложениями, установленными на банковских серверах. Или использование программного приложения веб магазин, в данном случае посетителями, нагружающими сервера, будут пользователи интернета.
Моделирование нагрузки происходит с помощью специальных продуктов и техник. Что же, чем и как мы собираемся моделировать? Для того чтобы разобраться в этом и нужно определиться с терминологией:
- Виртуальный пользователь (Virtual User) - программный процесс, циклически выполняющий моделируемые операции
- Итерация (Iteration) – это один повтор выполняемой в цикле операции
- Интенсивность выполнения операции (Operation Intensity) - частота выполнения операции в единицу времени, в тестовом скрипте задается интервалом времени между итерациями
- Нагрузка (Loading) - совокупное выполнение операций на общем ресурсе (тр./сек, хитов/сек)
- Производительность (Performance) - количество выполняемых операций за период времени (N операций за M часов)
- Масштабируемость приложения (Application Scalability) - пропорциональный рост производительности при увеличении нагрузки
- Профиль нагрузки (Performance Profile) - это набор операций с заданными интенсивностями, полученный на основе сбора статистических данных либо определенный путем анализа требований к тестируемой системе
- Нагрузочной точкой называется рассчитанное (либо заданное Заказчиком) количество виртуальных пользователей в группах, выполняющих операции с определенными интенсивностями
Теперь рассмотрим как эти сущности связаны между собой.
Выразив интенсивность через интервал времени между итерациями, видим что рост интенсивно-сти выполняемых операций - это сокращение интервала времени.
Рост нагрузки пропорционален росту интенсивности.
Естественно также, что при увеличении интенсивности растет производительность. При этом увеличивается степень использования (загруженности) ресурсов.
С какого-то момента рост производительности прекращается (а нагрузка может продолжать расти), происходит насыщение и затем деградация системы.
В дополнение можно заметить что при тестировании изменение интенсивности операций может подчиняться какому либо закону (например, Пуассона) либо быть равномерным в течении всего теста.
· Модель нагрузочного тестирования
Для разработки модели нагрузки необходимо определить следующее:
- список тестируемых операций
- интенсивность выполнения операций
- зависимость изменения интенсивности выполнения операций от времени
В список тестируемых задач должны войти операции, критичные с точки зрения бизнеса, а также с технической точки зрения:
· Критичными с точки зрения бизнеса являются операции, скорость выполенения которых, реально влияет на производительность бизнес процесса.
Например, увеличение длительности обслуживания клиентов в банке, невозможность выполнения необходимого количества операций в течение дня и так далее.
- Критичными с технической точки зрения являются ресурсоемкие операции, требующие большое количество памятьи, серьезно задействующие процессор, создающие значительный сетевой трафик.
Как правило, это операции выполняемые одновременно большим количеством бизнес пользователей или создание сложных отчетов, в которые входят так называемые "тяжелые" запросы к базе данных.
Нужно еще раз подчеркнуть, что под степенью критичности операции мы подразумеваем её влияние на бизнес процесс и работоспособность системы. Например, создание какого-нибудь отчета, полностью загружающего сервер базы данных в ночное время, не будет носить высокий приоритет для оптимизации, а в рабочие часы будет иметь максимальный приоритет.
· Этапы разработки модели нагрузки
Изучение Приложения
Определение профиля нагрузки
Расчет нагрузочных точек
Baseline нагрузочная точка
· Изучение приложения
Будем называть тестируемое прикладное программное обеспечение "приложением". Чтобы выделить части приложения, а именно операции, которые будут тестироваться, необходимо провести работу связанную с изучением приложения.
Очень большую пользу при этом должны оказать разработчики приложения, если речь идет о тестировании в процессе разработки, либо бизнес пользователи и системные администраторы, если приложение находится в процессе эксплуатации. В ходе этой работы разумно сделать такие шаги:
- Описать компоненты приложения и составить схемы взаимодействия между ними
- Выделить критические с точки зрения предполагаемого тестирования операции. В качестве таковых могут быть выбраны:
- Операции с "тяжелыми" запросами к базе данных, процессы генерации отчетов
- Операции, выполняемые большим количеством пользователей или с высокой интенсивностью
- Операции критичные с точки зрения бизнеса, и к тому же удовлетворяющие условиям двух верхних пунктов
Еще раз хочется заметить, что опрос бизнес пользователей или совместное исследование с разработчиками и администраторами системы может значительно облегчить задачу.
Если приложение находится в эксплуатации, то можно провести мониторинг загрузки компонен-тов аппаратных серверов (процессора, память, диски) и проанализировать системные журналы веб серверов (снять stats pack, если в качестве сервера базы данных, например, используется Oracle).
Системные журналы могут показать пики высокой активности пользователей в течение дня и дать количественное оценки того сколько транзакций (хитов) выполняется в единицу времени.
Согласно закону Паретто или принципу 20/80, 20% операций приложения генерируют 80% нагрузки в системе, поэтому нужно стараться выбрать для моделирования именно эти 20% операций.
· Определение профиля нагрузки
Ключевым моментом в модели нагрузки являются выбранные для тестирования операции или профиль нагрузки.
Естественно выполняться эти операции в тесте должны одновременно. Профилей нагрузки для приложения может быть несколько и это оправдано. Ведь бизнес пользователи могут выполнять разные наборы операций в разное время.
Например, начало операционного дня и конец дня, начало месяца (квартала) и соответственно завершение могут отличаться.
Таким образом получаем различные наборы операций приложения, выполняющиеся одновременно и соответственно создающие различную нагрузку. Кстати, меняться могут не только сами операции но и их интенсивности.
В первом приближении моделью нагрузки является набор профилей нагрузки, где каждый профиль отличается от другого или набором операций или интенсивностями выполнения этих операций.
Пример профиля нагрузки, в который входит 5 операций, значение n может быть различным для каждой операции:
<Профиль нагрузки>
- Операция_1 - интенсивность выполнения n раз / ед. времени
- Операция_2 - интенсивность выполнения n раз / ед. времени
- Операция_3 - интенсивность выполнения n раз / ед. времени
- Операция_4 - интенсивность выполнения n раз / ед. времени
- Операция_5 - интенсивность выполнения n раз / ед. времени
· Расчет нагрузочных точек
Поскольку в профиле нагрузки как правило присутствует несколько операций - это означает, что у нас будет несколько групп пользователей.
Желательно моделировать каждую операцию отдельной группой виртуальных пользователей (хотя в жизни часто бывает наоборот, один бизнес пользователь может отвечать за выполнение нескольких операций).
Тем не менее, если назначить одному виртуальному пользователю выполнение одной операции, то так легче выдержать определенную интенсивность (и соответственно производительность) для этой операции в тесте, чем в случае, когда виртуальному пользователю назначается последова-тельная цепочка операций.
Зная интенсивность выполнения операции нужно определить количество виртуальных пользователей в группе, выполняющих эту операцию.
Идеальный случай когда работа с приложением аналогична работе заводского конвейера и есть точные оценки сколько операций в день делает один пользователь.
Чаще всего бывает не так и известно только общее количество операций выполняемое в течение дня.
Так же может оказаться, что интенсивность выполнения операции каждым пользователем очень низкая, например, один пользователь выполняет операцию раз в день или раз в два дня.
Моделирование работы с пересчетом интенсивностей в этом случае можно проиллюстрировать следующим примером
ПРИМЕР: (для одной операции)
Количество операций = 200 за 4 часа
Количество бизнес пользователей = 20
1. Определяем количество операций для каждого пользователя
200/20 = 10
2. В час каждый пользователь выполняет 2.5 операции
10/4 = 2.5
3. Определяем период повторения операции (интенсивность) для каждого пользователя
60/2.5 = 24 минуты
4. Чтобы уменьшить время теста до часа, и при этом получить хоть какую то статистику по выполнению операций, а так же улучшить "перемешивание" операций во время теста, можно увеличить интенсивность в 4 раза, при этом уменьшив количество пользователей так же в 4 раза.
24/4 = 6 мин. = 360 секунд
Таким образом, 5 виртуальных пользователей, выполняя операцию с периодом 6 минут, обеспечат за 4 часа заданную производительность равную 200 операциям.
Что дает такой пересчет:
Во-первых, есть возможность снизить время теста, не теряя статистики выполнения операций, а следовательно и достоверности результатов теста.
Во-вторых, можно снизить количество моделируемых пользователей там где их число уходит за несколько тысяч и таким образом понизить требования к количеству ресурсов нагружающих компьютеров
1 пользователь может требовать до 10Мб оперативной памяти нагружающего компьютера
В некоторых случаях количество пользователей ограничивается условиями лицензионного соглашения (стоимость лицензии для тестового инструментария зависит от количества виртуальных пользователей)
Какие есть ограничения:
Для некоторых приложений, может быть критично количество одновременно открываемых соединений между клиентом и сервером.
Встречались ситуации когда запросы к базе данных начинали работать значительно медленнее если при работе с приложением увеличивается количество именно разных пользователей (разные логины) а не интенсивность запросов.
И наконец, увеличение интенсивности выполнения операций, не должно приводить к ситуации когда период повторения становится меньше чем время выполнения самой операции.
В любом случае, несмотря на некоторые ограничения, подобный расчет может допускать варьирование количеством виртуальных пользователей и интенсивностью выполнения ими операций.
При этом производительность и соответственно нагрузка не должна изменяться и отличаться от заданной. Итак, нагрузочная точка включает в себя расчеты виртуальных пользователей и интенсивностей по всем операциям профиля нагрузки.
· Baseline нагрузочная точка
Хочется заметить что расчет нагрузочной точки, описанный в разделе Расчет точек нагрузки, основанный на собранной для работающего приложения статистике (или на ожидаемом объеме работы для вновь разработанного приложения), является исходным для дальнейшего роста нагрузки, а сама рассчитанная нагрузочная точка может считаться базовой или baseline точкой. Теперь можно увеличивать нагрузку, двигаясь с некоторым шагом, увеличивая при этом только количество виртуальных пользователей в группах, не изменяя интенсивности выполнения операций для одного виртуального пользователя.
Полная модель нагрузки - это набор профилей нагрузки со всеми нагрузочными точками для каждого профиля. При разработке тестовых сценариев должны быть корректно реализованы все нагрузочные точки.
Еще хотелось бы добавить, что нагрузочных точек для каждого профиля должно быть не меньше трех, чтобы можно было оценить зависимость времен отклика выполняемых операций от роста нагрузки.
Очевидно, что чем линейнее такая зависимость тем лучше масштабируемость приложения и выше предсказуемость его поведения под нагрузкой.
· Тестирование безопасности или Security and Access Control Testing
Тестирование безопасности - это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.