Что такое интеграционное тестирование? (Пример)

Что такое интеграционное тестирование?

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

Интеграционное тестирование направлено на проверку обмена данными между этими модулями. Поэтому его еще называют 'ЭТО' (Интеграция и тестирование), «Тестирование строк» а иногда «Тестирование потоков».

👉 Зарегистрируйтесь на бесплатный проект по тестированию интеграции в реальном времени

Когда и зачем проводить интеграционное тестирование?

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

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

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

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

Нажмите здесь если видео недоступно

Пример интеграционного тестового примера

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

Примеры интеграционных тестовых случаев для следующего сценария: приложение имеет 3 модуля, например «Страница входа», «Mail«Ящик» и «Удаление писем», и каждый из них логически интегрирован.

Здесь не стоит слишком концентрироваться на тестировании страницы входа, так как это уже было сделано в Модульное тестирование. Но проверьте, как это связано с Mail Box Страница.

Кроме того, Mail Box: Проверьте его интеграцию с Delete MailМодуль s.

Идентификатор тестового случая	Цель тестового примера	Тестовый кейс Descriptион	ожидаемый результат
1	Проверьте интерфейсную связь между входом в систему и Mailкоробчатый модуль	Введите учетные данные для входа и нажмите кнопку «Войти».	Чтобы быть направленным в Mail Box
2	Проверьте интерфейсную связь между Mailполе и кнопку «Удалить» Mailс Модуль	С Mailполе, выберите адрес электронной почты и нажмите кнопку «Удалить»	Выбранное электронное письмо должно появиться в папке «Удаленные/Корзина».

лучший инструмент интеграционного тестирования

1) Testsigma

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

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

Требования:

• Единые сценарии тестирования API и пользовательского интерфейса: Эта функция позволяет объединять вызовы API, взаимодействие с пользовательским интерфейсом и проверки в рамках единого целостного тестового сценария. Она исключает переключение контекста между отдельными инструментами и обеспечивает полное покрытие интеграции. Вы можете убедиться, что ответы бэкэнда корректно влияют на поведение фронтенда в реальных рабочих процессах. Я использую это для эффективной проверки сквозной согласованности данных между различными сервисами.
• Расширенная параметризация и обработка данных: Testsigma предоставляет гибкие возможности управления данными для тестирования разнообразных сценариев интеграции с различными входными данными и условиями. Вы можете выносить тестовые данные во внешние среды, повторно использовать наборы данных в разных потоках и проверять несколько путей интеграции. Эта функция поддерживает динамическую загрузку данных и конфигурации, специфичные для конкретной среды. Я обнаружил, что это особенно эффективно для систематического охвата крайних случаев и граничных условий.
• Многоуровневые утверждения и проверки: Это позволяет проводить всестороннюю проверку ответов API, состояний базы данных и элементов пользовательского интерфейса в рамках интегрированных тестовых потоков. Вы можете одновременно проверять JSON-данные, коды состояния HTTP, значения базы данных и визуальные компоненты. Эта функция обеспечивает полную проверку точек интеграции. Я использую её для выявления тонких проблем преобразования данных, которые могут быть упущены при одноуровневом тестировании.
• Поддержка непрерывной интеграции и развертывания: Платформа легко интегрируется с конвейерами CI/CD для автоматического выполнения интеграционных тестов при каждой сборке или развертывании. Вы можете настраивать триггеры, веб-хуки и запланированные запуски для обеспечения непрерывной проверки. Она поддерживает популярные инструменты, такие как... Jenkins, GitLab и Azure DevOps. Я рекомендую использовать это для выявления регрессий в интеграции на ранних этапах цикла разработки.
• Централизованная отчетность и анализ отказов: Testsigma генерирует подробные отчеты, которые выделяют сбои интеграции, их первопричины и влияние на работу различных сервисов. Вы можете детализировать конкретные этапы тестирования, просматривать пары запрос-ответ и т. д. tracПроблемы с потоком данных. Эта функция предоставляет исторические тенденции и сравнительную аналитику. Я использовал ее для ускорения отладки и эффективной координации исправлений между распределенными командами.

Цены:

• Цена: Индивидуальная ценовая политика корректируется в зависимости от объема интеграционного тестирования, потребностей среды и структуры команды.
• Бесплатная пробная версия: 14-дневная бесплатная пробная версия

Посетите Testsigma >>

14-дневная бесплатная пробная версия

---

2) Testiny

Testiny Это современная облачная платформа для управления тестированием, на которую я полагаюсь, когда интеграционное тестирование требует четкого отображения результатов. tracУдобство взаимодействия между сервисами, API-интерфейсыtracи сквозных процессов. Он создан для команд контроля качества, которые координируют межсервисную проверку в нескольких модулях и стеках.

Запуск программ интеграционного тестирования в TestinyМне очень понравилось, как настраиваемые поля позволяют мне... track API-конечных точек, зависимых сервисов и данныхtracколичество тестов на каждый случай. Интеграция с Jira и GitHub означала, что неудачные запуски интеграции направлялись непосредственно в нужную команду разработчиков.

Требования:

• Организация тестирования на основе модулей: Testiny Это позволяет структурировать интеграционные тестовые случаи по сервисам или модулям, что упрощает навигацию по сложным планам тестирования между сервисами. Тесты API, пользовательского интерфейса и уровня данных можно логически группировать. Я использую это для управления интеграционными наборами, охватывающими несколько сервисов.
• Массовое редактирование тестовых случаев: Это позволяет редактировать большие группы интеграционных тестов одновременно, что крайне важно при работе с API.tracts shift. Вы можете за считанные секунды скорректировать ожидаемые полезные нагрузки, заголовки или зависимости. Я полагаюсь на это всякий раз, когда вышестоящие сервисы выпускают критические изменения.
• Выполнение в реальном времени Tracking: Testiny Отображает текущий прогресс выполнения интеграционных тестов, позволяя руководителям отслеживать выполнение задач в разных командах. Это помогает выявлять критические сбои интеграции в момент их возникновения. Я считаю, что это обеспечивает координацию циклов интеграции между несколькими командами.
• Проблема коренных народов TracИнтеграции Ker: Он подключается к Jira, GitHub, GitLab. Azure DevOps, Redmine, Linear, AsanaConfluence, Trello и monday.com позволяют напрямую связывать неудачные интеграционные тесты с отделом разработки. Это позволяет поддерживать тесную взаимосвязь между рабочими процессами контроля качества и разработки. Я предпочитаю это ручному созданию заявок между командами.
• Профессиональные PDF-отчеты: Платформа создает качественные PDF-отчеты по этапам интеграционного тестирования, которыми вы можете делиться с заинтересованными сторонами. Вы можете включить в них данные о покрытии кода и тенденциях возникновения ошибок. Я предоставляю эти отчеты при каждом завершении интеграционного тестирования.

Цены:

• Цена: Бесплатный тарифный план рассчитан на 3 пользователей; платные планы предусматривают увеличение количества рабочих мест и включают премиум-поддержку.
• Бесплатная пробная версия: 21-дневная бесплатная пробная версия

Войти Testiny >>

21-дневная бесплатная пробная версия

---

3) Testpad

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

В ходе интеграционного тестирования микросервисных архитектур, TestpadИерархические контрольные списки упростили вложение потоков между сервисами в родительские сценарии. Связь между Jira и GitHub позволяла направлять сбои интеграции соответствующим ответственным разработчикам.

Требования:

• Вложенные контрольные списки интеграции: Testpad Эта функция организует сценарии интеграционного тестирования в иерархические контрольные списки, позволяя группировать потоки взаимодействия между сервисами в рамках более широких сценариев использования. Вы можете развернуть список для получения подробной информации или свернуть для получения сводного представления. Я использую это для того, чтобы сложные пути интеграции оставались читаемыми.
• Быстрое редактирование с клавиатуры: Это позволяет создавать и редактировать планы интеграционного тестирования полностью с клавиатуры, благодаря чему захват тестов остается быстрым. Вы можете делать отступы, изменять порядок и клонировать сценарии интеграции без замедления работы. Я использую это при документировании новых межсервисных потоков в середине спринта.
• Исследовательское интеграционное тестирование: Testpad Поддерживается исследовательское интеграционное тестирование наряду со скриптовыми сценариями, позволяющими тестировщикам исследовать неожиданные взаимодействия сервисов. Вы можете фиксировать результаты в режиме реального времени по мере появления путей интеграции. Я считаю это ценным при интеграции новых сторонних сервисов.
• Вопрос Tracker Linking: Это позволяет напрямую связывать неудачные проверки интеграции с задачами в Jira и GitHub из каждого тестового элемента. Вы можете быстро направлять сообщения о сбоях интеграции соответствующим владельцам сервисов. Я предпочитаю это ручной передаче информации между отделами тестирования и разработки.
• Отчеты о ходе работы, которыми можно поделиться: Платформа мгновенно генерирует отчеты, которыми можно поделиться, что обеспечивает прозрачность хода интеграционного тестирования. Вместо совещания по статусу проекта можно просто отправить ссылку заинтересованным сторонам. Я делюсь этими отчетами ежедневно во время циклов выпуска интеграционных решений.

Цены:

• Цена: Стоимость тарифных планов начинается от 59 долларов в месяц, для больших команд доступны индивидуальные корпоративные планы.
• Бесплатная пробная версия: Бесплатная пробная версия 30 дней

Войти Testpad >>

30-дневная бесплатная пробная версия

Виды интеграционного тестирования

Программная инженерия определяет ряд стратегий выполнения интеграционного тестирования, а именно:

• Подход «большого взрыва»:
• Поэтапный подход: который далее делится на следующие
  • Подход «снизу вверх
  • Нисходящий подход
  • Сэндвич-подход – сочетание сверху вниз и снизу вверх

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

Испытание Большого Взрыва

Испытание Большого Взрыва — это подход к интеграционному тестированию, при котором все компоненты или модули интегрируются одновременно, а затем тестируются как единое целое. Этот объединенный набор компонентов рассматривается во время тестирования как единое целое. Если все компоненты в блоке не завершены, процесс интеграции не будет выполнен.

Преимущества:

• Более быстрая установка – Все модули интегрированы за один раз.
• Полный вид системы – Немедленно обратите внимание на общее поведение.
• Никаких заглушек/драйверов – Сокращает дополнительные усилия по разработке.
• Подходит для небольших проектов – Более простые системы подходят хорошо.
• Ориентированный на пользователя – Максимально соответствует опыту конечного пользователя.

Минусы:

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

Инкрементное тестирование

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

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

• Вверх дном
• Сверху вниз
• Сэндвич-подход

Тестирование интеграции снизу вверх

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

Схематическое представление:

Преимущества:

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

Минусы:

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

Тестирование интеграции сверху вниз

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

Преимущества:

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

Минусы:

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

Преимущества:

• Сбалансированный подход – Сочетает в себе преимущества подходов «сверху вниз» и «снизу вверх».
• Параллельное тестирование – Верхний и нижний модули тестируются одновременно.
• Более быстрое покрытие – Больше модулей протестировано ранее.
• Критические модули приоритетны – Проверены как высокие, так и низкие уровни.
• Сниженный риск – Проблемы обнаружены с обеих сторон.

Минусы:

• Высокая сложность – Сложнее планировать и управлять.
• Нужны заглушки/драйверы – Дополнительные усилия для испытания подмостей.
• дорогой – Требуется больше ресурсов и времени.
• Средние модули задерживаются – Проверяется только сверху и снизу.
• Не идеально подходит для небольших систем – Накладные расходы перевешивают выгоды.

Что такое заглушки и драйверы в интеграционном тестировании?

Заглушки и драйверы — это важные фиктивные программы, которые позволяют проводить интеграционное тестирование, когда не все модули доступны одновременно. Эти тестовые дубликаты имитируют отсутствующие компоненты, позволяя продолжать тестирование, не дожидаясь полной разработки системы.

Что такое заглушки?

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

Характеристики заглушек:

• Имитировать поведение модуля нижнего уровня
• Возвращает жестко запрограммированные или простые вычисляемые значения
• Используется в нисходящем интеграционном тестировании
• Реализация минимальной функциональности

Что такое драйверы?

Драйверы — это фиктивные программы, которые вызывают тестируемый модуль, имитируя компоненты более высокого уровня. Они передают тестовые данные модулям более низкого уровня и собирают результаты. Например, при тестировании модуля базы данных драйвер имитирует уровень бизнес-логики, отправляя запросы.

Характеристики водителей:

• Вызов тестируемых модулей с тестовыми данными
• Сбор и проверка ответов
• Используется в интеграционном тестировании снизу вверх
• Контроль хода выполнения теста

Пример практической реализации

Payment Module Testing:
- Stub: Simulates tax calculation service returning 10% tax
- Driver: Simulates checkout process calling payment module
- Result: Payment module tested independently of unavailable components

Когда использовать каждый?

Компонент	Использовать заглушку	Использовать драйвер
Подход к тестированию	Тестирование сверху вниз	Тестирование снизу вверх
Заменяет	Модули нижнего уровня	Модули более высокого уровня
Функция	Возвращает фиктивные данные	Отправляет тестовые данные
Многогранность	Простые ответы	Тестовая оркестровка

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

Как проводить интеграционное тестирование?

Процедура интеграционного тестирования, независимо от стратегий тестирования программного обеспечения (обсуждавшихся выше):

1. Подготовьте интеграцию План испытаний
2. Разработайте тестовые сценарии, кейсы и сценарии.
3. Выполнение тестовых случаев с последующим сообщением о дефектах.
4. Tracking и повторное тестирование на наличие дефектов.
5. Шаги 3 и 4 повторяются до успешного завершения интеграции.

Слип/Классические DescriptИон планов интеграционного тестирования

Он включает в себя следующие атрибуты:

• Методы/подходы к тестированию (как обсуждалось выше).
• Области и внеобласти интеграционного тестирования.
• Роли и обязанности.
• Предварительные условия для интеграционного тестирования.
• Тестовая среда.
• Планы рисков и смягчения их последствий.

Каковы критерии входа и выхода интеграционного тестирования?

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

Критерии входа:

• Компоненты/модули, прошедшие модульное тестирование
• Все высокоприоритетные ошибки исправлены и закрыты.
• Все модули должны быть успешно закодированы и интегрированы.
• Интеграционные тесты. План, тестовый пример, сценарии, которые необходимо утвердить и задокументировать.
• необходимые Тестовая среда быть настроенным для интеграционного тестирования

Критерии выхода:

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

Как бы вы разработали тестовые случаи для интеграции?

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

Шаг	вход	Ожидаемый результат
1	Пользователь вводит действительные учетные данные на экране входа.	Учетные данные безопасно передаются в API аутентификации
2	API проверяет учетные данные по базе данных	База данных подтверждает совпадение имени пользователя и пароля
3	API возвращает токен аутентификации	Токен сгенерирован и отправлен обратно в приложение
4	Пользовательский интерфейс перенаправляет пользователя на панель управления	Сеанс пользователя успешно установлен

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

Лучшие практики/руководства по интеграционному тестированию

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

Общие проблемы и решения

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

1. Управление сложными зависимостями

Задача: Множественные зависимости модулей создают сложные сценарии тестирования с каскадными сбоями.

Решение: Используйте внедрение зависимостей, контейнеризацию (Docker) и тестирование на инкрементальных уровнях. Документируйте все взаимосвязи в матрицах зависимостей.

2. Неполные модули

Задача: Тестирование блокируется, если зависимые модули не готовы.

Решение: Разрабатывайте комплексные заглушки/драйверы заранее, используйте виртуализацию служб (WireMock), и реализовать contract-тестирование с использованием четко определенных интерфейсов.

3. Управление тестовыми данными

Задача: Поддержание единообразных и реалистичных данных испытаний во всех системах.

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

4. Конфигурация среды

Задача: Несогласованность сред приводит к сбоям интеграции.

Решение: Используйте инфраструктуру как Code (IaC), контейнеризация для обеспечения единообразия среды и инструменты управления конфигурацией, такие как Ansible.

5. Отладка сбоев интеграции

Задача: Выявление коренных причин в нескольких компонентах — сложная задача.

Решение: Внедрить комплексное логирование, использовать распределенную систему. tracи добавить идентификаторы корреляции к (Йегер/Зипкин) track запросов между сервисами.

6. Интеграция сторонних сервисов

Задача: Недоступность внешних сервисов или изменения API прерывают тестирование.

Решение: Имитация внешних служб (Postman Mock Server), реализуют механизмы повторных попыток и поддерживают тестирование совместимости версий API.

7. Узкие места производительности

Задача: Точки интеграции становятся узкими местами под нагрузкой.

Решение: Проводите предварительное профилирование производительности, реализуйте стратегии кэширования и используйте асинхронную связь там, где это необходимо.

Часто задаваемые вопросы (FAQ)

Резюме