Может кому будет интересно как «по-быстрому» провести нагрузочное тестирование своего веб-приложения.
Подробности под катом

Вместо предисловия

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

Не «по-быстренькому»

Вообщем задача не на один час

А по-быстренькому?

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

Совсем по-быстренькому?

Нагрузочное тестирование за 1.5 часа

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

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

На этом графике показывается как терзалась система - в моем случае максимально было 47 пользователей - и чуть более 3-ех запросов в секунду
Ну и самый интересный


Из которого следует - что если исключить максимальный пик в 5 секунд (в этот момент решил включиться Garbage Collector) - в остальном приложение вело себя хорошо - и не зависимо от количества пользователей - то есть - нагрузка в 50 пользователей сайт не нагружает - есть еще и запас хороший.

Понятно - что такое тестирование не совсем «серьезное» по выдаваемым результатам, да и 50 одновременных пользователей - нельзя назвать серьезной нагрузкой, но, учитывая потраченное время (полтора часа) и деньги (0 руб) - результат вполне адекватный. По крайней мере мы убедились что если с производительностью есть какие-то проблемы - в ближайшие месяцы мы ее все-таки не увидим

Чуть подлинней и подороже

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

Зачем производится нагрузочное тестирование:

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

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

Apache HTTP server benchmarking tool

Бесплатный

Самый часто используемый, т.к входит в состав Apache.

Ab ://]hostname[:port]/path

где основные необходимые options:

C concurrency - количество одновременных запросов к серверу (по умолчанию 1);
-n requests - общее количество запросов (по умолчанию 1).

В результате команды получаем такой отчет:

Concurrency Level: 10 Time taken for tests: 0.984 seconds Complete requests: 100 Failed requests: 0 Write errors: 0 Total transferred: 3725507 bytes HTML transferred: 3664100 bytes Requests per second: 101.60 [#/sec] (mean) Time per request: 98.424 (mean) Time per request: 9.842 (mean, across all concurrent requests) Transfer rate: 3696.43 received Connection Times (ms) min mean[+/-sd] median max Connect: 1 2 3.6 1 23 Processing: 63 94 21.5 90 173 Waiting: 57 89 21.6 84 166 Total: 64 96 21.5 92 174

Плюсы :

• Есть везде, где есть Apache;
• Не требует никакой дополнительной настройки;
• Очень простой инструмент.

Минусы :

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

Joe Dog Siege

Бесплатный

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

В файле-сценарии задаются URL-ы и запросы тестирования. Если сценарий большой по объему, то можно вынести все запросы в отдельный файл и в команде указать этот файл при тестировании:

# cat urls.txt # URLS file for siege # -- http://www.bitrix24.ru/ http://www.bitrix24.ru/support/forum/forum1/topic3469/?PAGEN_1=2 http://www.bitrix24.ru/register/reg.php POST domain=test&login=login http://www.bitrix24.ru/search/ POST

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

Результат можно выводить в log-файл или сразу в консоль в режиме реального времени:

HTTP/1.1 200 0.44 secs: 12090 bytes ==> GET / HTTP/1.1 200 0.85 secs: 29316 bytes ==> GET /support/forum/forum1/ HTTP/1.1 200 0.85 secs: 29635 bytes ==> GET /support/forum/forum1/ HTTP/1.1 200 0.34 secs: 12087 bytes ==> GET / [...] done. Transactions: 100 hits Availability: 100.00 % Elapsed time: 12.66 secs Data transferred: 1.99 MB Response time: 0.64 secs Transaction rate: 7.90 trans/sec Throughput: 0.16 MB/sec Concurrency: 5.02 Successful transactions: 100 Failed transactions: 0 Longest transaction: 1.06 Shortest transaction: 0.31

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

Плюсы :

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

Минусы :

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

Apache JMeter

Бесплатный

Основные возможности:

• Написан на Java;
• HTTP, HTTPS, SOAP, Database via JDBC, LDAP, SMTP(S), POP3(S), IMAP(S);
• Консоль и GUI;
• Распределенное тестирование;
• План тестирования – XML-файл;
• Может обрабатывать лог веб-сервера как план тестирования;
• Визуализация результатов в GUI.

Результаты выводятся в графическом виде:

Плюсы :

• Кроссплатформенный, т.к написан на Java;
• Очень гибкий, используется много протоколов, не только веб-сервер, но и базы;
• Управляется через консоль и gui интерфейс;
• Использование напрямую логов веб-сервера Apache и Nginx в качестве сценария c возможностью варьирования нагрузки по этим профилям;
• Достаточно удобный и мощный инструмент.

Минусы :

• Ресурсоемкий;
• На длительных и тяжелых тестах часто падает по разным причинам;
• Стабильная работа зависит от окружения и конфигурации сервера.

Tsung

Бесплатный

Основные возможности:

• Написан на Erlang;
• HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP, Jabber/XMPP;
• Консоль (GUI через сторонний плагин);
• Распределенное тестирование (миллионы пользователей);
• Фазы тестирования;
• План тестирования – XML;
• Запись плана с помощью Tsung recorder’а;
• Мониторинг тестируемых серверов (Erlang, munin, SNMP);
• Инструменты для генерации статистики и графиков из логов работы.

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

Плюсы :

• Т.к на писан на Erlang, то хорошо масштабируется, зависит от выделяемых ресурсов;
• Может выполнять роль распределенной системы, на большом количестве машин;
• Большое количество тестируемых систем - не только веб-серверы и БД, но и, к примеру, XMPP-сервер: может отправлять сообщения, тесты с авторизацией;
• Управление через консоль, но, благодаря поддержке плагинов, можно управлять и с помощью стороннего плагина с gui-интерфейсом;
• Наличие в комплекте инструмента Tsung Recorder - своего рода, proxy-сервер, через который можно ходить по тестируемому сайту и записывать сразу как профиль нагрузки;
• Генерация различных графиков тестирования с помощью скриптов.

Минусы :

• Нет gui-интерфейса;
• Только *nix системы.

WAPT

Платный

Основные возможности:

• Windows
• Платный (есть триал на 30 дней / 20 виртуальных пользователей);
• Запись плана тестирования из десктопных и мобильных браузеров;
• Зависимости в планах тестирования (последующий URL в зависимости от ответа сервера);
• Имитации реальных пользователей (задержки между соединениями, ограничение скорости соединений).

Отчет можно вывести как таблицей, так и графиком.

Новое программное обеспечение и другие высокотехнологические продукты регулярно появляются на современном IT-рынке. Определить степень сопоставимости для решения конкретных задач, в каком объеме и достаточно ли безопасны в использовании возможно только в режиме нагруженного тестирования – услуги, которая предоставляется Компанией «Getbug Engineering ».

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

Этапы нагрузочного тестирования

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

Нагрузочное тестирование онлайн

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

Цели нагрузочного тестирования :

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

Оборудование тестового стенда должно как можно ближе соответствовать промышленной конфигурации. Особенно если на основе полученных в результате тестирования времени выполнения операций будут приниматься бизнес решения. Если речь идет об оптимизации приложения, то соответствие конфигураций тестового стенда и промышленного уже не так актуально. Для мониторинга тестовых серверов необходимо иметь доступ на сервера с правами для использования необходимых утилит, например, MS Windows Performance для MS Windows или sar, iostat, vmstat для unix-образных OS.

Инструменты и сценарии нагрузочного тестирования

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

Тестирование производительности (Performance testing )

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

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

Тестирование стабильности (Stability / Reliability Testing )

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

Стрессовое тестирование (Stress Testing )

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

Объемное тестирование (Volume Testing )

Объемное тестирование позволяет оценить производительность при увеличении объемов данных в базе данных приложения:

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

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

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

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

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

Мы проводим комплекс работ любой сложности и обладаем лабораторией, квалифицированными специалистами и собственными инструментами разработки и проведения тестовых работ.

Нагрузочное тестирование (англ. load testing ) - подвид тестирования производительности, сбор показателей и определение производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).

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

Нагрузочное тестирование программного обеспечения

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

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

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

Одним из оптимальных подходов в использовании нагрузочного тестирования для измерений производительности системы является тестирование на стадии ранней разработки. Нагрузочное тестирование на первых стадиях готовности архитектурного решения с целью определить его состоятельность называется "proof-of-concept" тестированием.

Основные принципы нагрузочного тестирования

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

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

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

В общем случае время отклика системы подчиняется функции нормального распределения .

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

Основные показатели (метрики) производительности

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

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

Метрика, показывающая количество памяти, использованной приложением. Использованная память делится на несколько категорий:

• Virtual - объём виртуального адресного пространства, которое использует процесс. Этот объём подразумевает, как использование соответствующего дискового пространства так и оперативной памяти. Система виртуальной памяти гарантирует, что потоки одного процесса не получат доступа к памяти принадлежащей другому процессу.
• Private - объём адресного пространства, занятого процессом и не разделяемого с другими процессами.
• Working Set - набор страниц памяти, недавно использованных процессом. В случае, когда свободной памяти достаточно, страницы остаются в наборе, даже если они не используются. В случае, когда свободной памяти остаётся мало, использованные страницы перемещаются из ОЗУ на жёсткий диск (или другой накопитель, такой как Флеш-память), освобождая ОЗУ для загрузки других активных страниц памяти.
• Shared - объём используемой процессом физической памяти, которая может использоваться совместно с другими процессами. Хотя память выделенная процессу должна быть изолированной, процессам, иногда, необходимо иметь возможность обмениваться информацией. Общая память является самым быстрым способом межпроцессного взаимодействия .

При работе приложения память заполняется ссылками на объекты, которые, в случае неиспользования, могут быть очищены специальным автоматическим процессом, называемым сборщиком мусора . Время затрачиваемое процессором на очистку памяти таким способом может быть значительным, в случае, когда процесс занял всю доступную память (в Java - так называемый «постоянный Full GC») или когда процессу выделены большие объёмы памяти, нуждающиеся в очистке. На время, требующееся для очистки памяти, доступ процесса к страницам выделенной памяти может быть заблокирован, что может повлиять на конечное время обработки этим процессом данных.

Эта метрика не связана непосредственно с производительностью приложения, однако её показатели могут указывать на пределы производительности системы в целом.

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

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

> Нагрузочное тестирование

Нагрузочное тестирование или тестирование производительности

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

Основные виды тестирования производительности

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

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

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

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

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

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

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

Load vs Performance Testing

В англоязычной терминологии вы можете так же найти еще один вид тестирования - Load Testing - тестирование реакции системы на изменение нагрузки (в пределе допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.