# Тестирование сервиса (Service Testing)

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

* Performance;
* Reliability;
* Manageability;

Во всех трех случаях нам необходимо моделировать пользовательскую нагрузку для эффективного проведения тестов. Цели производительности, надежности и управляемости существуют в контексте реальных клиентов, использующих сайт для бизнеса. Скорость отклика (в данном случае время, необходимое одному системному узлу для ответа на запрос другого) сайта напрямую зависит от ресурсов, доступных в технической архитектуре. Чем больше клиентов используют эту услугу, тем меньше технических ресурсов доступно для обслуживания запросов каждого пользователя, и время отклика сокращается. Очевидно, что слабо загруженная служба с меньшей вероятностью выйдет из строя. Большая часть сложности программного и аппаратного обеспечения существует для удовлетворения требований к ресурсам в рамках технической архитектуры, когда сайт сильно загружен. Когда сайт загружен (или перегружен), конфликтующие запросы ресурсов должны управляться различными компонентами инфраструктуры, такими как серверные и сетевые операционные системы, системы управления базами данных, продукты веб-серверов, брокеры объектных запросов, промежуточное ПО и т. д. Эти компоненты инфраструктуры обычно более надежны, чем код специально созданного приложения, которому требуются ресурсы, но сбои могут произойти в одном из следующих случаев:

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

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

**Тестирование управления услугами** (Service Management Testing). Когда служба развертывается в производственной среде, ею необходимо управлять. Для поддержания работоспособности службы необходимо, чтобы ее отслеживали, обновляли, создавали резервные копии и быстро исправляли, когда что-то пойдет не так. Процедуры, которые менеджеры служб используют для выполнения обновлений, резервного копирования, выпусков и восстановлений после сбоев, критически важны для обеспечения надежной службы, поэтому им необходимо тестирование, особенно если служба претерпит быстрые изменения после развертывания. Необходимо решить следующие конкретные проблемы:

* Процедуры не дают желаемого эффекта;
* Процедуры неработоспособны или непригодны;
* Процедуры нарушают прямую трансляцию;

По возможности тесты должны проводиться реалистично.

Источник:

[Leadership in test: service testing](https://theqalead.com/topics/service-testing/)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/testirovanie-servisa-service-testing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.