Как выбрать инструмент для тестирования API
В список требований, предъявляемых к QA-специалистам, включают умение тестировать API приложений.
Обращения к API помогают оптимизировать процесс тестирования: сократить время на проведение, расширить покрытие кейсами, минимизировать зависимость от внешних систем, например, клиентской части приложения. Кроме того, обращения к эндпойнтам позволяют проверить тестовые случаи, которые невозможно воспроизвести, используя только графический интерфейс.
Чтобы выбрать инструмент для тестирования API на своем проекте, вам нужно четко представлять свои цели, объект и результат, который хотите получить. Неправильно выбранный инструмент может привести к увеличению трудоемкости и затягиванию процесса тестирования, а также к пропуску багов.
В этом материале мы рассмотрим наиболее распространенные виды API, выделим их характерные особенности, а также разберем популярные инструменты для тестирования API и опишем применение на практике. Изучив этот материал, вы сможете выбрать наиболее подходящий инструмент и использовать его на своем проекте.
Что такое API
API (Application Programming Interface) – это программный интерфейс приложений. Чтобы понять, как он работает, возьмем классический пример: клиент и сервер. API можно представить как рычаги, протянутые с сервера на клиент. Благодаря им клиент может воспользоваться функциями, реализованными на сервере. То есть API – это интерфейс, с помощью которого одна система может связываться с другой.
Рассмотрим характерные особенности Web-API, наиболее распространенных в настоящее время: SOAP, REST и gRPC.
SOAP API
Первоначально предназначался преимущественно для удаленного вызова процедур. Сейчас протокол используется также для обмена произвольными сообщениями в формате XML. Основная отличительная черта SOAP API в том, что вся информация передается в XML-сообщениях между клиентом и сервером.
SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и другими. Однако взаимодействие с каждым имеет свои особенности. Например, в случае реализации с помощью HTTP/HTTPS применяется только метод POST. Одним из ключевых понятий в данном типе API является файл WSDL, включающий себя описание методов тестируемого сервиса. Импортируя такой файл, вы получаете список готовых обращений к эндпойтам.
REST API
Архитектурный стиль сетевого взаимодействия компонентов распределенного приложения. Впервые термин был использован в 2000 году одним из создателей НТТР. Сам по себе REST не является протоколом. Это набор правил того, как разработчику организовать написание кода серверного приложения, чтобы все системы эффективно обменивались данными, и приложение можно было масштабировать.
В стиле REST можно выделить несколько характерных особенностей:
- Привязка к методам HTTP и, соответственно, использование только этого протокола для передачи данных.
- Использование различных форматов для передачи данных, таких как JSON, XML, HTML. Наиболее часто используется JSON ввиду его легкости, простоты и человекочитаемости.
gRPC
Система удаленного вызова процедур, разработанная компанией Google в 2015 году. В качестве транспорта gRPC использует протокол HTTP v2. Чаще всего gRPC помогает организовать взаимодействие в микросервисной архитектуре. Реализация общения через gRPC происходит следующим образом: клиентское приложение может напрямую вызвать метод серверного приложения так же, как если бы это был локальный метод клиента.
Отличительная черта реализации приложений с помощью gRPC API — наличие компонента gRPC STUB. Это модуль, который конвертирует данные из человекочитаемых в бинарные файлы и передает их между клиентом и сервером. Еще одна неотъемлемая часть gRPC API это .proto файл – описание того, какие методы есть в приложении, и взаимосвязь между запросом и ответом.
Познакомившись с примерами реализации API, становится понятно, что они представляет собой структуру вида «запрос — ответ». В запросе нужно передавать некоторые параметры, в ответ на которые приходят соответствующие данные.
Инструменты для тестирования API
Существуют десятки различных инструментов, с помощью которых тестируют API. Все их можно разделить по уровню освоения на простые, средние и сложные. Чтобы их сравнить, сформулируем основные критерии.
- Принципиальная возможность обратиться к эндпойнтам приложения.
- Возможность отправить свои собственные параметры запроса.
- Способность хранить тест-кейсы.
- Быстрота написания тестов.
- Скорость освоения инструмента.
- Возможности автоматизации проверки ожидаемых результатов.
- Дополнительные возможности автоматизации тестирования.
- Возможности использования переменных окружения.
- Способность использовать мок-сервисы, заглушки и т. д.
- Особенности запуска готовых тестов.
- Интеграция с системами CI/CD.
- Дополнительный функционал, облегчающий тестирование.
Сваггероподобные системы
Это инструменты простого уровня — Swagger UI, Яндекс Полигон, а также прочие внутрипроектные интерактивные виды документации API.
В стандартный функционал сваггероподобных систем входят: отправка запросов, просмотр ответов, возможность посмотреть готовые примеры запросов и ответов, варианты авторизации, возможность экспорта ответа в файл и генерация cURL запроса.
Плюсы сваггероподобных систем:
- Это, как правило, полностью готовые инструменты, в которых уже созданы все обращения к эндпойнтам, тела запросов и другие параметры.
- Они очень быстры и просты в освоении и использовании из-за элементарного функционала.
- Содержат примеры ответов и описание приходящих в них параметров.
- Не требуют установки на устройство пользователя, они уже развернуты на стенде.
- Генерируют cURL, который можно приложить к баг-репорту, чтобы разработчик мог быстрее воспроизвести баг и исправить его.
Минусы сваггероподобных систем:
- Они хранят только заранее прописанные разработчиком параметры запросов, которые могут быть избыточными или наоборот, неполными.
- Нельзя сохранять свои параметры запросов. То есть после обновления страницы сваггероподобной системы пропадет все, что вы туда ввели. Таким образом, параметры запросов, использующиеся в тест-кейсах, придется хранить в отдельных документах, а это неудобно.
- Нельзя создавать коллекции запросов, так как невозможно сохранять свои варианты запросов.
- Нельзя создавать скрипты-проверки, ожидаемый результат с фактическим придется сверять глазами/руками.
- Невозможны прогоны, то есть автоматизированный последовательный запуск запросов.
- Нельзя создавать и использовать никакие окружения, переменные.
- Полезность описаний в сваггероподобных системах очень разнится от проекта к проекту.
Когда выбирать сваггероподобные системы? Так как это не инструмент тестирования, а интерактивная документация по API, такие системы чаще используются для ознакомления с эндпойнтами и исследовательских проверок. В остальных случаях использовать сваггероподобные системы не рекомендуется, разве что вы работаете на специфическом проекте, и другие инструменты использовать невозможно. Например, закрытый проект, где вы работаете на виртуальных машинах и удаленных рабочих столах, и при этом нет возможности установить никакой из API-клиентов. Тогда все, что вы можете — использовать Swagger или подобную систему, чтобы тестировать эндпойнты сервиса.
API-клиенты
Инструменты среднего уровня сложности. Это, как правило, десктопные приложения, которые позволяют обратиться к эндпойнтам. Также они предоставляют дополнительные возможности — использование переменных, рандомайзеров, скриптов и других функций.
Insomnia
При открытии Insomnia мы видим главную страницу, на которой можно настроить само приложение и свой аккаунт, меню создания проектов, а также список уже созданных. Добавить новый проект можно различными способами: импортирование из локального файла, «подтягивание» с внешнего ресурса по URL, копирование API проекта из Git.
При открытии проекта становится доступным функционал добавления новых и список созданных запросов. Окно запроса дает возможность вводить и сохранять отправляемые параметры. Посмотреть и сохранить в качестве примера приходящий ответ можно в окне справа.
Insomnia поддерживает широкий набор возможностей для обращений к различным API: набор методов HTTP/s, обращения к gRPC API, а также кастомные методы со своими параметрами. Вариантов форматов передаваемых сообщений тоже много: JSON, XML, YAML, EDN, бинарные файлы, GraphQL Query.
Важная особенность Insomnia — возможность создавать переменные окружения, которые будут подтягиваться или автоматически генерироваться в зависимости от настройки. Значения из переменных можно использовать в тестах, чтобы автоматизировать их и упростить себе работу.
На странице проекта во вкладке “Test” добавляются проверки к отправляемым запросам, сравнивающие пришедший ответ с ожидаемым результатом. Запрос с добавленными проверками называется Тестом. Несколько запросов можно объединить в Тест-сьют.
Insomnia поддерживает возможность запускать тесты списками с помощью раннера. При этом отображаются отправляемые запросы и результаты проверок
Плюсы Insomnia:
- Легкий в освоении интерфейс относительно других подобных API-клиентов.
- Кроссплатформенность.
- Возможность загрузки проектов из Swagger. Можем по URL импортировать проект, и у нас появятся все те же списки с описаниями, как это было в Swagger.
- Возможность настройки окружения.
- Возможность создавать динамические переменные.
- Возможность создавать и прогонять тест-кейсы.
- Возможность поддержки версионности кейсов с подключением их к Git.
- Возможность тестирования разных API, таких как REST, SOAP, gRPC, GraphQL и другие.
Минусы Insomnia:
- Создание тест-кейсов из нескольких запросов затруднено. Если тест-кейс состоит из нескольких последовательных шагов/запросов, то он будет обозначаться как тест-сьют, соответственно, построить иерархию кейсов сложно из-за одного уровня вложенности (папка (тест-сьют) – запрос).
- Невозможен параллельный запуск запросов и кейсов.
- Настройка переменных окружения сложная относительно других API-клиентов.
- Небольшой выбор встроенных скриптов-рандомайзеров по сравнению с другими инструментами.
- Нет встроенного списка проверок к ответам.
Используйте Insomnia, когда нужно тестировать разные виды API, использовать окружения, переменные, скрипты, и при этом функции Postman для вас избыточны. Или если вам нужен удобный API-клиент для тестирования gRPC.
Postman
Очень популярный API-клиент. Хоть его интерфейс и пугает насыщенностью, разобраться в нем достаточно просто. На домашней странице предлагается выбрать рабочее пространство. Это своеобразная «папка», в которую добавляются коллекции запросов, окружения, переменные, мок-заглушки и другое. Такое разделение очень удобно, если у вас есть несколько тестируемых проектов или сервисов.
В каждом рабочем пространстве есть:
- список коллекций, расположенный в окне “Collections”;
- документация API, сюда можно импортировать Swagger;
- окно, в котором редактируются окружение и переменные;
- функционал создания мок-заглушек.
- «монитор» — функция, позволяющая по таймеру запускать коллекции запросов. Причем это можно делать облачно, без необходимости держать свой компьютер включенным.
Окно запроса состоит из поля для указания HTTP-метода и URL запроса, настройки параметров (заголовки и тело), Pre-request Script — скриптов, которые будут исполняться до отправки сообщения, Tests — кода, который будет исполняться после выполнения запроса.
Оранжевым цветом выделяются переменные в Postman. Они бывают автоматически генерируемые (имя начинается с $, например, $randomInt — генерирует рандомное число) и созданные пользователем (куда можно записать все что угодно).
В данном случае создается переменная ‘CreateTime’ в которую записывается время, генерируемое с помощью JS в Pre-request Script.
Во вкладке Test мы видим код, который сверяет ожидаемый и фактический результат. Проверки в Postman начинаются с конструкции ‘pm.test”. Первым тестом мы проверяем статус-код. Если он равен 200, то во вкладке Test results в ответе появится сообщение “Status code is 200”. Второй тест — проверка id животного. Видим, что в ответе пришел именно тот id животного, которое мы создавали, то есть сверяем со значением из переменной окружения.
Также во вкладку Test можно добавить код, выполняющий любые действия — например, достающий из ответа значение, которое хранится в произвольном поле, и передающий его в переменную окружения.
Плюсы Postman:
- Относительно простой интерфейс.
- Возможность подключения в Swagger.
- Возможность создавать рабочие пространства и коллекции.
- Поддержка мок-серверов и прогонов коллекций (ручные и периодические).
- Отдельный компонент-перехватчик запросов.
- Окружения, переменные и возможность их настраивать, создавать, редактировать.
- Возможность тестирования разных видов API, таких как REST, SOAP и т.д.
- Поддержка интеграции с Git.
- Очень много встроенных скриптов-рандомайзеров.
- Возможность написания кастомных скриптов проверок с помощью языка JavaScript.
- Очень много встроенных вариантов проверок в сниппетах.
- Возможность написания кастомных проверок с помощью JS.
- Возможность запускать коллекции из командной строки с помощью инструмента-компаньона Newman.
- Возможность интеграции Newman с системами непрерывной сборки. Например, мы можем создать коллекцию в Postman, она передается Newman, интегрируется с системами непрерывной сборки, и Newman запускает эту коллекцию при обновлении версии стенда, приложения или в других подобных ситуациях.
Минусы Postman:
- Коллекции и окружения к ним экспортируются отдельно.
- Невозможен параллельный запуск кейсов в Postman. Например, вы тестируете асинхронный сервис и есть некий этап ожидания между созданием задания и получением на него результата. В этом случае лучше, чтобы ваш инструмент тестирования позволял запускать проверки параллельно и ждать результата в каждом случае по отдельности. Иначе вы будете ждать их очень долго, особенно когда много тест-кейсов. Прогон такой коллекции будет растянутым.
- Раннер, который последовательно запускает запросы, видит именно список запросов, а не кейсы. Это несет в себе риски, когда кейс состоит из нескольких запросов. Например, папка представляет собой тест-кейс. У вас десять папок, в которых десять тест-кейсов, и в каждом по два-три шага. Когда запускаете раннер, вам видны 30 последовательных запросов. Поэтому в некоторых запросах в разных тест-кейсах вам нужно писать скрипты, которые в случае провала автоматически очистят некоторые переменные от своих значений. Тогда следующий кейс пройдет без ошибок и там не останется значений, которые не воспринимаются следующим кейсом. Это влияет на независимость тест-кейсов друг от друга.
Postman следует использовать, когда вам нужен удобный и мощный API-клиент для тестирования разных видов API с возможностью использовать продвинутые переменные и скрипты в запросах. При этом не важен параллельный запуск кейсов в вашем проекте и вы понимаете особенности построения кейсов из нескольких запросов.
SOAPUI
Первоначально был создан для тестирования SOAP сервисов, но впоследствии стал применяться и для REST API. Инструмент позволяет создавать и импортировать проекты, в нем есть меню работы с тест-кейсами, список всех проектов и меню действий над текущим.
При открытии проекта становится доступным список всех запросов, существующих в вашем сервисе, и список тест-кейсов. Это одна из отличительных черт SOAPUI — запросы в библиотеке и тесты существуют отдельно. То есть мы описали 15 запросов, а потом можем в любых комбинациях использовать их в тестах, ставить в разном порядке в зависимости от потребности.
Тест-сьюты состоят из тест-кейсов, а тест-кейсы — из шагов. Шаги могут быть как запросами, так и служебными действиями.
Запросы настраиваются в отдельном окне, где можно добавить и сохранить передаваемые данные, отправить запрос, посмотреть ответ на него, а также прикрепить проверки ожидаемого результата (в данном случае проверки Contains).
К служебным действиям относятся, например, таблицы с тестовыми данными (testdata), которые будут с помощью переменных подтягиваться в запросы. Таблицы имеют простую структуру “name-value”, причем value может быть не только статическим, но и генерироваться скриптом.
Еще одним видом служебных действий являются шаги трансфера (Transfer mail), выполняющие передачу данных между запросами, либо между запросом и таблицей с данными. Структура передачи также простая “source-target ”. Единственная особенность тут: грамотно указать с помощью языка парсинга поля обмена данными.
Интуитивно понятный функционал запуска тест-кейсов состоит из: кнопки «старт/стоп» и переключателя последовательного или параллельного запуска проверок. При нажатии на кнопку “Start” показывается список запущенных кейсов, а также результат их прохождения. Открыв проваленный кейс можно увидеть на каком шаге он «упал» и почему (в данном примере — потому что нет значения, который передается в “mail”). При этом следующий шаг не запускался, и это одна из особенностей SOAPUI. Он видит именно тест-кейсы, а не список шагов. Если какой-то шаг в тест-кейсе провалился, то остальные шаги он не запускает и переходит далее. Следующие кейсы работают только с переменными, скриптами и тестовыми данными внутри них самих, не видя переменные из других кейсов.
Настройка последовательного или параллельного запуска кейсов «из коробки» — это также отличительная особенность SOAPUI. Во многих случаях это сильно экономит ваше время.
Плюсы SOAPUI:
- Возможность создания проектов с помощью Swagger (для REST API) и файлов WSDL (для SOAP API).
- Возможность тестировать REST и SOAP.
- Легкий экспорт и импорт проектов одним файлом. То есть вы экспортируете этот файл один раз, передаете коллеге, он устанавливает его и импортирует себе. Нет необходимости переносить отдельно переменные, окружение и сами запросы, как в Postman.
- Возможность использовать окружения и переменные.
- Возможность написания кастомных скриптов для проверки ожидаемого и фактического результата.
- Встроенные варианты проверок.
- Параллельный запуск кейсов, что очень важно.
- Раннер видит именно список кейсов, а не список запросов и список шагов в них.
- Можно сделать нагрузочные тесты.
- Можно написать мок-заглушки.
- Eсть возможность использовать функционал прокси.
Минусы SOAPUI:
- Сложный интерфейс относительно предыдущих API-клиентов.
- Не поддерживает gRPC и GraphQL в бесплатной версии.
- Не поддерживает интеграцию с Git в бесплатной версии.
- Не поддерживает интеграцию с системами непрерывной сборки в бесплатной версии.
SOAPUI подойдет, если у вас есть много тест-кейсов из нескольких запросов, а также нужен параллельный запуск этих кейсов. Когда у вас есть кейсы с вилкой результатов. Если на проекте нет потребности тестировать API кроме REST и SOAP. Когда вам не обязательно интегрировать тесты с системами непрерывной сборки.
Библиотеки. Rest Assured
Библиотеки это не самостоятельные инструменты, они написаны для использования внутри языков программирования. Так как на рассмотрение большого количества существующих библиотек тестирования API уйдет много времени. Рассмотрим их типичный функционал на примере популярной Rest Assured.
Так выглядит тест, написанный с использованием Rest Assured. С помощью public void объявляется тест “whenCreatePerson_thenStatus201” в given() задаются предварительные условия запроса, блок when() отправляет запрос к эндпойнту, а в then() происходит сверка ожидаемого и фактического результата. В данном примере проверяется, что при успешном создании пользователя приходит статус-код 201 (Created).
Следующий тест чуть более сложный: здесь обновляется предварительно созданный пользователь. При этом проверяются два ожидания: на статус-код 200 и в теле поле “name” будет иметь значение “Michail”.
Плюсы Rest Assured:
- Полная интеграция с системами CI/CD и возможность автоматически запускать проверки при появлении новой версии приложения на стенде.
- Возможность подключить инструмент Allure Reporting для автоматизированного формирования отчетов о тестировании.
- Возможность реализовать практически любые проверки, которые можете написать сами, и практически любые предзапросные скрипты.
- Скорость работы тестов, написанных с помощью библиотек, и в частности Rest Assured, быстрее, чем у API-клиентов.
Минусы Rest Assured:
- Нужно уметь писать код, причем хорошо. Rest Assured использует язык Java. Первый тест из учебника написать не сложно, но создать тесты которые действительно принесут пользу вашему проекту — это не так просто.
- Официальные туториалы для фреймворков и библиотек подходят только для мелких проектов либо для написания тестов а-ля “Hello, world!”. Наилучшие паттерны написания кейсов придется искать самостоятельно по форумам и другим источникам.
Фреймворки стоит выбирать, если вы уже умеете хорошо писать код или твердо намерены прокачаться в этом деле. Когда хотите глубокой автоматизации и интеграции кейсов с CI/CD. Если в кейсах много логик, для которых нужны сложные скрипты. Если для вашего проекта важно увеличение скорости повторного тестирования, в первую очередь — регрессионного.
Сравнение реального использования инструментов
На проекте автора статьи последовательно вводилось использование инструментов тестирования API.
Сервис назовем условно «Квартет», так как он включает в себя 4 микросервиса. Тип работы — асинхронный. На данном проекте произошла последовательная смена инструментов “Postman — SOAPUI — Rest assured”. Swagger присутствует, но для тестирования он не использовался, так как прохождение кейсов с его помощью, в нашем сервисе, не сильно быстрее использования графического интерфейса. Прохождение кейсов с помощью GUI возьмем за начальную точку сравнения.
Написание каждого тест-кейса заняло 6 минут. 200 кейсов — это 1200 минут или 20 часов. Ручной прогон каждого end to end кейса в среднем занимает 4 минуты с учетом скорости работы фронта, бэка и QA специалиста. 200 кейсов это 800 минут или 13,5 часов.
То есть, если проводить регресс вручную, на это каждый раз будет уходить 13-14 часов. И это без учета времени на баг-репорты, без поправки на усталость специалиста и так далее. Конечно же, такое время неприемлемо в условиях ограниченной QA-команды.
Первым используемым инструментом стал Postman. Скорость погружения в инструмент с момента установки до написания первого кейса, который можно реально использовать — 2 часа. Время на создание первого полностью автоматизированного кейса, который ждет построения файла, проверяет ожидаемый результат и т.д. — 8 часов. То есть освоение инструмента заняло 10 часов. После этого написание и отладка кейсов стали занимать по 10 минут в среднем, то есть на 200 кейсов ушло 34 часа.
Автоматизированное прохождение такого кейса в Postman занимает 50 секунд, то есть 200 кейсов проходят за 2 часа 47 минут. Вроде бы все хорошо, но из за особенностей работы системы, 50 секунд уходит только на успешный кейс, а на неуспешный — до 30 минут. Если проваливаться будут все 200, то такое прохождение займет до 100 часов. Конечно, такого никогда не случалось, но теоретическая возможность такого сценария заставляла искать инструмент с параллельным запуском кейсов. Тем более, что сам сервис мог обрабатывать результаты параллельно.
Им стал SOAPUI. Время погружения в инструмент с установки до написания первого полезного кейса составило 3 часа. Пилотный автоматизированный кейс был написан за 10 часов. 200 кейсов в SOAP UI были написаны за 44 часа. Да, делать тест-кейсы в этом инструменте немного дольше из-за своеобразного интерфейса. Но параллельный запуск полностью окупает этот недостаток. Кейсы запускались порциями по 100 и с учетом особенностей работы сервиса это давало 18 минут на порцию в случае успешного прохождения и 46 минут при неуспешном. То есть 200 успешных кейсов проходили за 36-37 минут, 200 неуспешных — 1 час 32 минуты. Это был успех, который позволил не следить за прогоном, чтобы вовремя остановить его при нескольких неуспешных кейсах подряд. Но SOAPUI не хватает отчетности о тестировании, а главное — нет интеграции с CI/CD, а этого очень хотелось.
Поэтому перешли на Rest Assured в связке с JUnit 5. Погружение заняло 10 часов, еще 11 на написание пилотного кейса. 200 кейсов были созданы за 42 часа. JUnit умеет запускать кейсы параллельно, поэтому запускали теми же порциями по 100, что в итоге дало прохождение 200 успешных кейсов за 35 минут в среднем, неуспешных — за 1 час 29 минут. С виду ускорение незначительное, но не стоит забывать, что появилась отчетность о каждом прогоне и главное — кейсы автоматически запускались при срабатывании определенного триггера. Регресс стал полностью автоматизированным.
Заключение
Мы рассмотрели наиболее распространенные Web-API и инструменты для тестирования разных уровней: от специфичных сваггероподобных систем до библиотек языков программирования. Несмотря на то, что фреймворки и библиотеки кажутся панацеей, это не так. Из приведенного примера внедрения видно — чем «способнее» инструмент, тем он сложнее и дольше в освоении. Выбор решения для тестирования API должен совершаться, исходя из конкретных потребностей проекта. Так, если интеграция с CI/CD не особа нужна, плюс в команде нет специалистов должного уровня, то не надо гнаться за фреймворками, достаточно выбрать подходящий API-клиент.
Лучший инструмент не совершеннее других, а полезнее.
Спасибо за внимание! Полезные материалы для QA-специалистов мы также публикуем в наших соцсетях – ВК и Telegram.
Prefixes Префиксы или приставки в английском языке
Если вы не можете отличить правду от искусной лжи, тогда задумайтесь о законах, о свободе слова, как часто и где менялась власть.
Префиксы или приставки в английском языке используются для словообразования. Они могут менять значение слова, но в большинстве случаев не меняют часть речи. Чаще всего они присоединяются к глаголам, прилагательным, существительным, причастиям.
Не существует четких правил по присоединению префиксов, так как префиксы английского языка были заимствованы из французского, греческого языка и латыни. Потому слова с приставками и их значение лучше запоминать индивидуально. Но знание о префиксах помогает запоминать новые слова быстрее.
Отрицательные префиксы
Приставки un-, in-, im-, il-, ir-, a-, non-, dis-, а также mis— используются для образования отрицательной формы слова или его антонима. Чаще всего они присоединяются к прилагательным. В предложении их можно заменить отрицательной частицей not.
- I am un able to do this. – Я не в силах сделать это.
- I am not able to do this. – Я не в силах сделать это.
- It’s im possible! – Этого не может быть!
- It’s not possible! – Этого не может быть!
Префикс un- используется чаще всего и присоединяется к словам, начинающимся как с гласной, так и с согласной букв.
Префикс in— используется со словами, которые начинаются на гласные (кроме i и u) и согласные.
- accurate → in accurate (неточный)
- organic → in organic (неорганический)
- appropriate → in appropriate (неподходящий)
- sane → in sane (ненормальный)
- definite → in definite (неопределенный)
- decent → in decent (неподобающий)
Префикс im— присоединяется к словам, которые начинаются только на согласные m и p.
- moral → im moral (аморальный)
- mobile → im mobile (недвижимый)
- possible → im possible (невозможный)
- polite → im polite (невежливый)
Префикс il— присоединяется только к словам, начинающимся на согласную l.
- legal → il legal (нелегальный)
- logical → il logical (нелогичный)
- legible → il legible (нечеткий)
- literate → il literate (неграмотный)
Префикс ir— присоединяется только к словам, начинающимся на согласную r.
- regular → ir regular (неправильный)
- responsible → ir responsible (безответственный)
- relevant → ir relevant (неуместный)
- rational → ir rational (нерациональный)
Префикс a— присоединяется только к словам, начинающимся с согласной буквы.
- political → a political (аполитичный)
- sexual → a sexual (бесполый)
- theist → a theist (атеист, неверующий)
- moral → a moral (аморальный)
Префикс -a имеет также значение «на», «в», «в сторону к» или же обозначает образ действия. A- может изменять часть речи слова. Префикс присоединяется к существительным, формируя прилагательные, наречия, или к прилагательным, образовывая наречия.
- a blaze – пылающий, в огне
- a bed – лежащий в постели, на кровати
- a foot – пешком, идущий пешком
- a gape – разинувший рот
- a shore – к берегу, на берег
- a way – далеко, вдали, прочь
- blaze – огонь, пламя
- bed – кровать
- foot – ступня
- gape – зевок, изумленный взгляд
- shore – берег
- way – путь, дорога, маршрут
- a far – вдалеке, далеко
- a loud – вслух, громко
- a low – внизу, вниз
- a wry – искаженный, косо, вбок
- far – далекий, дальний
- loud – громкий
- low – низкий
- wry – кривой, неправильный
Префикс non— может ставиться как перед согласной, так и перед гласной буквой. Может указывать на отрицание или отсутствие чего-то.
- conformist → non comformist (инакомыслящий)
- sense → non sense (бессмыслица)
- descript → non descript (трудноопределимый)
- non -alcoholic (безалкогольный)
Префикс dis— присоединяется к словам, начинающимся как на согласную, так и на гласную. Указывает на противоположность действия, качества.
- like → dis like (не любить)
- agree → dis agree (не соглашаться)
- comfort → dis comfort (дискомфорт)
- appear → dis appear (исчезать)
- order → dis order (беспорядок)
- approve → dis approve (не одобрять)
Префикс mis— указывает на неправильность чего-то, неверность. Ставится перед согласными и гласными буквами.
- understand → mis understand (неправильно понять)
- spell → mis spell (писать с ошибками)
- interpret → mis interpret (неправильно истолковать)
- fortune → mis fortune (неудача)
- focusing → mis focusing (расфокусирование)
- hear → mis hear (ослышаться)
Re-
Префикс re— указывает на повторность действия и чаще всего переводится на русский приставкой «пере-». Часто присоединяется к глаголам.
- re write – переписывать
- re paint – перекрашивать
- re new – обновить
- re direct – перенаправить
- re do – переделать
- re -assort – пересортировать
Co-
Префикс co— указывает на совместность какого-либо действия с кем-то или чем-то.
- co education – совместное обучение
- co exist – сосуществовать
- co operative – совместный
- co worker – сотрудник, коллега
- co llaboration – сотрудничество
- co incidence – совпадение
Ex-
Префикс ex— чаще всего используется с существительными в значении «предыдущий», «прошлый». Эта приставка всегда пишется через дефис. Ex— может быть заменен на прилагательное former (бывший).
- ex -president – бывший президент
- ex -boyfriend – бывший парень
- ex -wife – бывшая жена
- ex -member – бывший участник
- ex -minister – бывший министр
- ex -emperor – бывший император
Префикс ex- также имеет значение «вне», «за пределами», «наружу», а также «точно», «совершенно». В этом случае префикс пишется слитно со словом, так как в большинстве случаев оно не употребляется без префиксов.
- ex terior — экстерьер
- ex pression — выражение, экспрессия
- ex ception — исключение
- ex cavate — выкапывать, откапывать, копать
- ex hale — выдыхать
De-
Префикс de— используется в значении отхода, устранения, обратных процессов.
- de parture – отбытие
- de forestation – вырубка лесов
- de centralization – децентрализация
- de throne – свергать с престола
- de motivate – демотивировать
- de grade – ухудшать, понижать, унижать
Over-, Under-, Sub-
Приставка over— указывает на чрезмерность, превышение чего-то, сверх чего-то, или то, что находится над чем-то.
- over confident – слишком уверенный
- over weight – перевес, излишек веса
- over come – побороть, преодолеть
- over coat – пальто
Приставка under— служит антонимом к over— и переводится как «недо-», «под-».
- under estimate – недооценивать
- under weight – недовес, недостаток веса
- under line – подчеркивать
- under wear – нижнее белье
Префикс sub— означает нахождение под чем-то, подчинение, подразделение, а также имеет значение «почти».
- sub marine – подводная лодка
- sub ordinate – подчиняться
- sub tropical – субтропический
- sub standard – нестандартный
Super-, Hyper-, Hypo-
Префикс super— передает значение нахождения над чем-то, выше чего-то, превышение норм или превосходства качества, размера и т.д.
- super script – надстрочный индекс
- super natural – сверхъестественный
- super market – супермаркет
- super size – большой размер (больше нормы)
Префикс hyper— используется для обозначения преувеличения, превышения чего-то, синонимичен приставке super-. Часто используется в научных терминах. Переводится как «сверх-», «очень», «гипер-».
- hyper active – гиперактивный
- hyper sonic – сверхзвуковой
- hyper thermia – перегревание организма, гипертермия
- hyper power – сверхдержава
Приставка hypo— противоположна по значению к hyper-, означает что-то ниже нормы, находящееся снизу. Также употребляется в терминах.
- hypo activity – пониженная активность
- hypo allergenic – гипоаллергенный
- hypo thermia – гипотермия
- hypo dermic – подкожный
Ultra-, Infra-
Приставки ultra— и infra— противоположны по значению и используются в основном в научных терминах. По значению похожи на приставки hyper— и hypo-.
Приставка ultra— означает что-то находящееся за пределами, крайнее. Слова с таким префиксом переводятся как «сверх», «ультра».
- ultra violet – ультрафиолет
- ultra sonic – сверхзвуковой
- ultra microscopic – ультрамикроскопический
- ultra fast – сверхбыстрый
Приставка infra— означает нахождение ниже чего-либо, под чем-то. Переводится как «под-», «нижне-», «инфра-».
- infra red – инфракрасный
- infra sonic – инфразвуковой, подтональный
- infra specific – внутривидовой
- infra structure – инфраструктура
Pre-, Post-
Префиксы pre— и post— являются парными антонимами.
Префикс pre— означает предшествование чему-то, что-то, что было перед, до.
- pre face – предисловие
- pre pay – предоплата
- pre historic – доисторический
- pre war – довоенный
Префикс post— означает что-то, что было после, следовало за чем-то.
- post graduate – аспирантский, после окончание университета
- post script – послесловие, эпилог
- post date – датировать поздним числом
- post war – послевоенный
Inter-, Intra-, Trans-
Префиксы inter-, intra-, trans— могут быть синонимичны по значению.
Префикс inter— означает «среди чего-то», «между определенными группами», указывает на связь между определенными группами, понятиями.
- inter national – международный
- inter state – межобластной, включающий разные штаты
- inter act – взаимодействовать
- inter change – обмениваться
Префикс intra— (intro-) означает «внутри», «в пределах чего-то».
- intra mural – внутри помещений, стен
- intra venous – внутривенный
- intra day – в течение дня
- intro spect – всматриваться, самоанализ
Префикс trans— означает «действие через что-то», изменения, передачу, переход из одного состояния в другое.
- trans national – транснациональный
- trans atlantic – трансатлантический
- trans port – транспорт
- trans form – изменять, трансформировать
Pro-, Retro-, Anti-
Префикс pro— часто используется для обозначения движения вперед, продвижения или в значении «за что-либо», «в поддержку».
- pro spective – будущий, ожидаемый
- pro gress – прогресс
- pro -American – проамериканский
- pro -reform – сторонники реформ
Приставка retro— используется в значении «назад», «позади».
- retro spective – относящийся к прошлому
- retro gress – ухудшаться, двигаться назад
- retro flex – загнутый назад
- retro act – противодействовать, двигаться назад
Приставка anti— имеет значение «против», «противо-». Выступает антонимом приставки pro-.
- anti biotic – антибиотик
- anti aircraft – противовоздушный
- anti -American – антиамериканский
- anti -corruption – антикоррупционный
Extra-, Out-
Префикс extra— указывает на чрезмерность, выход за пределы, дополнительность или высшую степень чего-то. Часто используется для прилагательных.
- extra curricular – внепрограммный
- extra ordinary – необычный
- extra cellular – внеклеточный
- extra central – внецентральный
Префикс out- имеет значение «вне», «наружу», а также «быть или сделать что-то лучше, чем кто-то другой», «превзойти». Префикс прибавляется к глаголам, существительным и прилагательным.
- out do – превзойти, побороть
- out building – служебное здание, надворная постройка
- out speak – высказаться, говорить лучше
- out standing – выдающийся, знаменитый
Hemi-, Semi-, Demi-
Приставки hemi-, semi-, demi— имеют схожее значение чего-то неполного, сделанного наполовину. Они различны по своему происхождению.
Префикс hemi— чаще всего встречается в научных терминах и означает физическую симметричную половину, «наполовину». Он был заимствован из греческого языка.
- hemi sphere – полушарие
- hemi cycle – полукруг
- hemi plegia – паралич мышц одной половины тела (левой или правой)
- hemi anopia – односторонняя слепота
Латинский префикс semi— кроме значения половины, действия выполненного наполовину, передает значение «практически», «в сущности», «слегка», «до некоторой степени»
- semi circular – полукруглый
- semi final – полуфинал
- semi permanent – почти неизменный
- semi conscious – полусознательный
Французский префикс demi— передает значение «половина», «наполовину», «полу-» и используется в сферах искусства, моды, типографии, в военных терминах или терминах, пришедших из французского языка.
- demi god – полубог
- demi tone – полутон
- demi monde – люди сомнительный репутации
- demi -lance – короткое копье
Mono-, Multi-
Префиксы mono-, multi— являются парными антонимами.
Префикс mono— указывает на что-то единичное, неразделенное, единственное.
- mono logue – монолог, речь одного человека
- mono gamy – моногамия
- mono chromic – одноцветный
- mono poly – монополия
Префикс multi— означает что-то многочисленное, неоднородное.
- multi color – многоцветный
- multi purpose – многоцелевой
- multi user – многопользовательский
- multi way – многоканальный
Mini-, Micro-, Macro-
Префикс mini— указывает на уменьшенную копию чего-то, что-то маленькое.
- mini ature – миниатюра
- mini skirt – юбка мини
- mini mize – уменьшать, минимизировать
- mini mal – минимальный, наименьший
Префикс micro— означает что-то очень малых размеров, то, что сложно заметить невооруженным взглядом.
- micro computer – микрокомпьютер
- micro be – микроб
- micro scope – микроскоп
- micro wave – микроволновой
Префикс macro— является антонимом к micro— и указывает на что-то большое, продолжительное.
- macro scopic – видимый невооруженным глазом
- macro graph – макроснимок
- macro economics – макроэкономика
- macro cosmos – макрокосмос
En- (Em-)
Префикс en— отличается от других префиксов английского языка тем, что может менять часть речи, к которой относится слово. En— часто присоединяется к существительным и прилагательным, формируя глагол. Префикс en— имеет значение «вводить в определенное состояние»,«окружать», «наделять чем-то». Перед согласной p префикс en— меняется на em-.
Особенности написания
В английском языке префиксы, кроме отрицательных, могут писаться слитно или через дефис. В британском варианте английского языка приставки чаще всего пишутся через дефис, а иногда отделько от основного слова. В американском английском приставки пишутся слитно всегда.
Всегда слитно пишутся устоявшиеся выражения, когда слово практически никогда не используется без приставок.
- anti biotic – антибиотик
- sub marine – подводная лодка
- post pone – откладывать
- trans fer – перевод
Предсмертный или пост-смертный анализ или как избежать катастроф
Каждый, кто работал с технологиями, проектами, услугами сталкивался со сбоями или неудачами. Разные масштабы, разные последствия – все имеет свою цену. А можно ли было избежать мелких проблем, значительных неудач или глобальных катастроф? У всего есть причина и следствие. Или если уж это произошло, то как мы должны на это реагировать и какие уроки вынести?
Есть два подхода, позволяющих учиться на прошлых ошибках и избегать их в будущем:
- Подход с угрожающим названием – Post mortem (лат. «после смерти») или посмертное вскрытие.
- Pre-mortem (предварительное/предсмертное вскрытие).
Post-mortem
В процессе создания, предоставления, совершенствования услуг, мы неизбежно сталкиваемся с инцидентами. Техника выходит из строя, люди делают ошибки, процессы не совершенны – все это проявляется в инцидентах. Назначение практики управления инцидентами – минимизировать негативное влияние за счет скорейшего восстановления нормальной работы услуги. Но быстро восстановить услугу – это не избавиться от инцидентов. И если не будет формализованной деятельности изучения первопричин инцидентов, то мы можем работать в режиме пожарной машины бесконечно, прилагая героические усилия в лечении симптоматики, а не болезни. Анализ возникновения инцидентов и устранение первопричины инцидентов – задача для практики управления проблемами. Но как мы исследуем возникающие инциденты? Применяем ли подход посмертного вскрытия и как мы это делаем?
Post-mortem – это задокументированный отчет об инциденте, его последствиях, предпринятых действиях для минимизации или устранения причин, а также предотвращения повторения инцидента. Все это напоминает обзор после восстановления значительного инцидента. Не так ли? Основная цель такого отчета или обзора – это изучение и документирование и понимание основных причин инцидента, принятие превентивных мер, уменьшающих последствия или вероятность возникновения инцидентов. Важно понимать, что при анализе первопричин мы не должны играть в игру поиска крайнего и виноватого в возникновении инцидента. Мы не должны уничижать себя, посыпая голову пеплом. Post-mortem обзор не является наказанием, это возможность для роста, возможность вынести урок из происшедшего для всех.
Понимаю, что, читая эти строки, найдутся и противники идеи не искать виноватого. Когда что-то идет не так, всегда хочется найти виновного. Поиск крайнего заставляет людей “защищаться”, скрывать истинные причины неудач, чтобы избежать наказания. Это явно не способствует открытости, доверию и гарантиям конструктивности, дающим право ошибаться, экспериментировать, улучшать и развивать инновации.
Post-mortem без обвинений (Blameless PostMortems) – это часть внутренней культуры в компании, требующей постоянных усилий. Но выгоды от такой культуры очевидны:
- Улучшение коммуникаций и поддержки
- Повышение инициативы
- Готовность к совершенствованию и экспериментам
- Улучшение культуры обучения
- …
Post-mortem — это способ выстроить процессы вашей команды и активизировать сотрудничество, поощряя культуру открытого обсуждения острых вопросов, совершенствования, поиска решений, а не поиска крайнего.
Pre–mortem
Минута профилактики стоит часов восстановления – эта истина хорошо известна. Но не все задумываются о возможных последствиях. Можно ли их предотвратить? Можно! И здесь поможет Pre-mortem.
Pre-mortem является гипотетической противоположностью Post-mortem’a. В бизнес-обстановке Pre-mortem проводится перед началом проекта, а не в конце, это поможет улучшить проект, а не заставит сокрушаться из-за последствий неудач, когда ничего уже не исправить.
Pre-mortem – это управленческая стратегия, которая позволяет представить, что проект провалился. Такая техника дает возможность оценить ситуацию еще до достижения конечного результата, т. е. проанализировать потенциальные угрозы, лучше подготовиться или даже предупредить потенциальные риски. Кроме этого, если команда заранее представляет провал, она сможет сохранить равновесие при любых обстоятельствах.
Подход Pre-mortem может быть применен при управлении рисками, управлении проектами, проактивной работе практики управления проблемами, проектирования услуг, тестирования и др.
Что потребуется для Pre-mortem анализа:
- Определите сколько времени вам потребуется для спокойной работы
- Постарайтесь пригласить все заинтересованные стороны для диалога, не ограничиваясь только лидерами мнений, тем самым избежав слепых пятен, которые в последствии смогут повлиять на конечный результат. Важный момент – обсуждение лучше проводить вживую, лицом к лицу. Чаты, мессенджеры, электронная почта будут не эффективны.
- Чтобы важные идеи и мнения не упустить – делайте пометки и записи (или поручите это сделать кому-то из вашей команды).
- Проведите мозговой штурм всех возможных причин гибели проекта или возможных неудач.
- Выберите 10-15 проблем, имеющих решающее значение для вашего проекта. Нет смысла учитывать проблемы вне вашей зоны контроля. Сфокусируйтесь только на тех, которые вы способны исправить.
- Теперь определите решения для каждой проблемы: будь то контрмера или резервное копирование.
- Распределите роли и ответственность среди членов команды, если не хотите получить неразбериху и замешательство в самый ответственный момент.
Учтите, нет никаких гарантий, что все будет гладко и легко. Не всегда можно предугадать или предвидеть все возможные ситуации развития событий, но имеет смысл сыграть в игру под названием “Предсмертный анализ”. Она стоит вашего душевного спокойствия в будущем.
Преимущества такого подхода:
- Он дает голос тем, кого мы зачастую не слышим, ценит независимое мышление и создает чувствительность к проблемам
- Он помогает преодолеть проблему «группового мышления», когда небольшая группа единомышленников не может мыслить нестандартно и заставлять себя думать, что все в порядке
- Стресс вызывает выработку кортизола, а он в свою очередь, затуманивает наше мышление. Предсмертный анализ опережает стрессовую ситуацию и помогает мыслить рационально.
- Он улучшает результаты проекта за счет снижения неоправданной самоуверенности и повышает уверенность в решениях проблем
Pre-mortem или Post-mortem – игры стоят свеч. Они могут стать хорошим дополнением вашей корпоративной культуры.
Также по теме:
- Более 3 часов уходит у 65% компаний на анализ проблем, связанных с приложениями
- Эмоциональное выгорание на работе и как его избежать
- Измерение ITSM-процессов: как избежать “футбола”?
- Пост на вечную тему, который должен написать каждый
- Модель Cynefin: анализ контекста при принятии решений
Post или pre лучше и где применяется
Неопубликованная запись
Анатомия микшерного пульта.
Имя автора
Взято из английского журнала SOS. Перевод: Диана Кочиева.
Автор статьи Хью Робджонс решил заняться исследованием строения микшерного пульта начиная фейдерами и заканчивая обработкой и схематехникой.Разнообразие микшерных пультов необычайно широко в наше время, от самых простых 6:2 (входы/выходы), под которые обычно устраиваются танцы и караоке вечеринки, и до 100+канальных монстров. Встречаются всякие конфигурации, например сплит консоли или инлайн. Сплит консоль имеет несколько входных каналов, и имеет отдельную мониторную микс панель в другом месте на контрольной поверхности. Разница между входными каналами и AUX совершенно ясна и легко понять новичку.
Также различаются по ручкам управления или назначениям управляющей поверхностью, и сейчас конечно, аналог тоже управляется цифрой, или даже по правде- везде цифровые платы. Несмотря на огромное разнообразие, многие аспекты функционирования и его конструкция являются общими для всех микшеров, понимание основных принципов, плюс немного здравого смысла сделает любую самую солидную представительную консоль игрушкой для ребенка.
Итак, приступим. Та часть пульта, в которой находится фейдер регулирующий уровень на выходе мастер-шины, носит название мастер-секции, в большинстве студийных пультов она находится в центре, слева от нее находятся канальные фейдеры, а справа — групповые. Из-за такого раздельного расположения подобные конфигурации получили название «сплит» (split).В Сплит мониторных консолях тоже есть группы фейдеров. В группах (часто неправильно называемые подгруппы ) есть выходы для многодорожечного устройства записи. Вы можете смешать несколько каналов в одну группу и записать ее в единое русло. Фейдер группы будет контролировать общий уровень идущий на трек. Обычно это делается в тех консолях ,где одна половина консоли используется для контроля записи, а другая половина используется для воспроизведения — отсюда и фраза сплит консоли. А Инлайн — это пульты в которых мониторинг и запись дорожки можно отслеживать через каждый channel strip.
Пути прохождения сигнала в общем-то выглядят одинаково во всех пультах, ведь у них одно предназначение. Всегда меняются тонкости в зависимости от назначения и ценовых рамок, но принципы остаются теми же: микшер принимает сигналы от ряда источников звука, обрабатывает их, настраивая приемлемый баланс, и качество, и передает полученный микс на рекордер, на воспроизведение, либо на PA системы. Для микшера соответственно требуется большое количество входных каналов, каждый из которых должен уметь обрабатывать сигнал с микрофонным или линейным уровнем, иметь регуляторы громкости и эквалайзеры. Кроме того, он может генерировать дополнительный сигнал, для устройства эффектов и отправлять на многодорожечную запись.
В довершение всего микшер должен обеспечить возможность для прослушивания и измерения сигнала отдельных каналов, основного микса или дополнительных выходов, так чтобы сигнал корректно проходил все этапы.
Большинство микшеров имеют аналогичный путь прохождения сигнала: на входе микрофонный или линейный сигнал пропускается через микрофонный предусилитель или линейный буферный усилитель, где уровень сигнала оптимизирован по перегрузу и шуму, затем проходит через эквалайзер до фейдера. Дополнительные выходы идут либо до фейдера, либо после (pre или post), там обычно находятся точка разрыва, откуда сигнал извлекается из консоли на внешнее устройство обработки (допустим компрессором или нойз-гейтом) и обработанный сигнал возвращается через return обратно в микшер.
Далее сигнал идет либо на нужный выход, или на группу если это необходимо. В случае групп сигнал пройдет через дополнительный эквалайзер, соответственно до фейдера, а после уже на главный выход пульта. Группы справляются с большим количеством каналов одновременно с помощью сигнального процессора.
Первый элемент на пути сигнала является микрофонный усилитель и общий входной каскад. Конструкция микрофонного предусилителя влияет на окрас поступившего звука и с этого момента любая потеря качества звучания не сможет быть восстановлена. И во многих многодорожечных студиях используют внешние микрофонные предусилители, которые конечно же стоят дороже, вместо посредственных преампов встроенных в довольно неплохой среднебюджетный микшер.
Микрофонный усилитель должен справиться со следующей сложной задачей: он должен обеспечить усиление до высокого уровеня сигнала с минимальным шумом; он должен иметь хороший запас в пиках во избежание перегруза; и должен передать каждый тончайший нюанс, от самых низких частот и до самых высоких и не сжимая динамический диапазон.
Самые качественные микрофоны как правило электростатические (конденсаторные), и на каждом микрофонном канале для работы такого рода микрофонов требуется фантомное питание. Этот ток нужен для поляризации капсуля и работы внутреннего предусилителя микрофона.
Микрофоны направленной характеристики имеют нежелательный «эффект близости» (увеличение НЧ), что часто провоцирует перегруз сигнала. Чтобы противодействовать этой проблеме, на каждом канале есть специальный переключаемый ВЧ фильтр, который уберет весь нежелательный хлам, не затрагивая полезный сигнал.
В любом хорошем микрофонном предусилителе предусмотрен большой диапазон регулировки уровня, так что микрофон смело можно будет ставить на отдалении. Сигнал будет передан с хорошим усилением. Для этого есть грубый переключатель уровня- на 5, 10 dB. А в дешевых пультах эта кнопка бывает рассчитана одна на весь диапазон усиления. Чисто с инженерной точки зрения этот подход является совершенным, но в наши дни есть и респектабельное оборудование основанное на втором подходе. Для максимальной гибкости входного тракта динамический диапазон до 70 dB – это желательно, но это накладывает большие требования на схему. Большинство домашних студий может управлять только 50 dB усиления микрофона, что значительно расслабляет проектные ограничения.
Чрезвычайная чувствительность микрофонных предусилителей это очень хорошо, но что бывает когда место в котором стоит микрофон очень зашумлено, например внутри бочки, или под раструб трубы. Во избежание перегруза для подобных ситуаций на входе канала существует переключатель чувствительности на -20 -30 dB (Pad).
Входной тракт также часто оснащен инвертором фазы. Это такой переключатель, который требуется если смешиваются микрофоны противоположной полярности и на выходе происходит взаимное уничтожение, а не сложение. А это все потому, что не все производители пользуются общепринятым стандартом XLR при передачи сигнала в пульт, где 2-ой пин положительный, 3-ий отрицательный- вот и происходит различная поляризация сигнала.
Наконец, большинство пультов оснащены стредством переключения с микрофонного на линейный вход, в том случае когда на один канал приходятся два входа, а такое возможно. На более дорогих консолях будут отдельные регуляторы уровня для каждого входа.
Когда вы выставляете входное усиление на канал, важно деактивировать все настройки эквалайзера, то есть поставить все ручки в положение ноль. Иначе не получится создать естественное звучание, так как эквалайзер будет вносить свои недочеты в различные области и вам будет казаться, что усилив громкость или ослабив вы сможете выровнять частотную характеристику.
Фейдеры каналов обеспечивают удобную корректировку во время записи и воспроизведения. Если фейдер все время находится в нижнем положении, то входное усиление было выставлено неправильно.
Число посылов может колебаться от одного, до восьми. Посылы могут быть переключены для получения сигнала до фейдера, и после фейдера, то есть будет зависим, либо не будет зависим от уровня фейдера. Обычно пре-фейдерная настройка включает в себя гейн и обработку эквалайзера, а есть модели которые обходят тракт эквалайзера. В обоих случаях есть и минусы и плюсы. Режим пре- EQ хорош в тех случаях, когда нет риска обратной связи, тогда как пост- EQ могла бы быть лучше для эффектов или сигнала наушников. Пре- фейдер годится для наблюдений, или когда сигнал должен подаваться так, чтобы фейдер на него никак не влиял. Пост- фейдер обычно используется для домашних систем или на вещании, и для большинства типов обработки, особенно для искусственной реверберации.
Использование пост- фейдерных вспомогательных посылов имеет значение тогда, когда один процессор эффектов обрабатывает основную долю сигнала, потому, что когда канальный фейдер закрыт, его непосредственного вклада на выходе нет. Если пре- фейдерный режим использовать, то канал по прежнему будет звучать даже при выключенном фейдере, это наверно не очень удобно для звукорежиссера.
Чтобы сократить количество относительно дорогих ручек и регуляторов, их ставят на паре дополнительных посылов, и так немного планирования потребуется для оптимизации вспомогательного оборудования в конкретной ситуации. Большие консоли могут быть обеспечены одним или несколькими стерео посылами, где один регулятор становится регулятором уровня, а другой панорамным регулятором.
На выходе один из каналов должен быть смешан с другими каналами. В простейших пультах все каналы могут быть направлены на мастер выход, но более типично когда каналы поступают на группы и потом только на мастер секцию.
В зависимости от предполагаемой роли на пульте, может быть что угодно от двух и до 48 групп, с различным уровнем сложности в плане эквалайзеров, и дополнительных посылов. Обычно группы разделяются на пару — с каналом pan-pot обеспечивающим ограничение сигнала в одной группе, и создающее положение в пространстве . Лучше выбирать для одного источника в пространстве определенный канал стерео. Сложней придется с двумя моно раскинутыми влево и вправо, потому что придется настроить усиление, эквализацию и фейдеры аналогично друг другу, проще работать с выделенным стерео каналом.
Полезное примечание: не используемые каналы не стоит оставлять посланными в группу, иначе это создаст ненужные шумы и помехи ( хотя в каком-то конкретном случае может так и не случиться).
Структура микшера в своем общем строении проста и едина — все входные каналы отправляются на еще меньшее число групп, и потом посылаются на мастер шину, или на остальные выходы. Однако, эта простая структура усложняется если консоль предназначается для работы совместно с многодорожечными рекордерами, особенно если большее число дорожек задействованы. Нормальным считается, если в многодорожечных консолях записываемые дорожки будут посланы на одну группу (тем самым позволяя нескольким каналам быть задействованными в одной дорожке, например для bounce-downs) так 24, 32 или 48 групп могут быть необходимыми.
Входные Каналы — Группы — Выходы Каналов для Мониторинга (Tape Monitor Channels) – Стерео Выход. Вообразите консоль с 72 входами, 48 группами и 48 мониторными выходами, бок о бок: это впечатляет, но это не практично! Такого рода структура идет под общим названием «Сплит консоль» , т к входы для записи и выходы мониторинга полностью самостоятельны. И тут просто понять, насколько этот дизайнерский подход является громоздким, так как количество дорожек увеличивается, и выполнение простых функций, таких как bounce-downs. Часто требуются внешнее прохождение пути сигнала, чтобы изменить маршрут сигнала, с возвратом через входные каналы и затем отправляются в группу.
Чтобы преодолеть эксплуатационную непрактичность в Сплит Консолях, в качестве альтернативного решения была разработана , в дальнейшем ставшая очень популярной, SSL 4000-ой серии консоль. Такие микшерные пульты называются Инлайн , хотя по строению они более сложные, значительно более гибкие в управлении и требуют гораздо меньшего физического пространства. В Инлайн консолях, секция канала становится и входной и выходной, потому ,что каждая полоса микшера включает все функции для приема сигнала, выходов на группы и посылы на мониторы в соответствии с числом заданных полос. Другими словами, модуль 6 содержит микрофонный и линейный вход для канала 6, вместе с дополнительным управлением посылов и эквалайзером, фейдером канала , и выходной маршрутизацией. +The off-tape monitor + монитор для трека 6 для удобства тоже будет на этом модуле, и будут обеспечены дополнительные посылы, эквалайзер (хотя эти обычно разделяются или заимствуются из каналов путей устройства) и фейдер (обычно длинноходный).
Строение консоли позволяет в данной конфигурации много экономных возможностей- уменьшение затрат денежных на ручки управления и габаритов пульта- разделение или расширение вспомогательных посылов для эквалайзера между каналами (запись сигнала) и мониторных выходов (повтор сигнала). Кроме того, чрезвычайно гибкая маршрутизация сигнала для таких операций как отслеживание скачков сигнала становится возможной с добавлением нескольких электронных переключателей внутри самой конструкции (patching внешнего сигнала редко требуется); функции фейдеров канала и мониторинга могут быть переменены местами одним нажатием кнопки, позволяя вручную контролировать тип фейдера для работы с каналом или выходами мониторов.
Это также означает, что во время микс-дауна, вы можете использовать незадействованную дорожку, чтобы подключить виртуальную клавиатуру или возврат с устройства эффектов (отсюда и основная форма продажи в виде 48-канальной с 96 входами на микс-дауне). Расширяя идею повторного использования redundant bits , маршрутизация группы также может быть повторно использованы в качестве пост-фейдерного дополнительного посыла, и вам не надо подключать сторонние устройства, потому что несколько внутренних электронных переключателей могут заново настроить всю консоль быстро и легко.
В нижней части инлайн конструкции очень просто озадачиться сигнальным трактом конкретного звукового источника за исключением, пока вы не обратите внимание на обозначения. Вы только представьте себе ситуацию, когда микрофон подключен в 6 вход, и это будет контролироваться входной секцией и маленьким фейдером канала, затем направляются на tape track 17, и так TRIM контроль группы будет на настройках 17 канала, как и мониторный ответный сигнал будет управляться собственным фейдером. Этот маршрут сигнала может показаться не слишком плохим, но потенциал для путаницы растет, и вы понимаете,что эквализация затрагивает запись (канал) и воспроизведение (монитор)- очень легко непреднамеренно установить несколько эффектов, или сигнал посыла на тот же канал, но из разных модулей ввода/ вывода.
Традиционно, каждая операция на микшере имеет свою ручку или кнопку управления, но поскольку пульты с каждым годом увеличиваются в размерах, то становится невозможным дотянуться до некоторых ручек без необходимости вставать с места и идти с одного конца микшера до другого. Также некоторые возникающие сложности: время, на то чтобы перезагрузить микшерный пульт между сессиями, затраты на подходящие ручки управления, переключатели и потенциометры.. и т.д. эти проблемы привели к росту популярности пультов, с возможностью «назначения» ручек ли кнопок, которые значительно уменьшают количество эксплуатируемых регуляторов, и могут программироваться под разные команды.
Чтобы понять практические возможности «назначения» , стоит рассмотреть возможности обычных ручек управления. Его очевидная роль в изменении параметров сигнала, как уровня, так и изменение частоты эквалайзера. Каждый регулятор обеспечивает доступ к определенной функции, но в конце the control shaft это фактическое устройство , которое изменяет намеченный параметр. Каждая кнопка управления также указывает на текущее состояние параметра, менее очевидная, но более жизненная роль в возможности запоминать свое предыдущее значение, ведь сама по себе она не сможет переключиться.
Учитывая то, что у нас только две руки, «назначаемый» микшер требует только одной или двух ручек управления. Хотя некоторые пульты придерживались этого подхода, большинство проектировщиков признает этот подход не самым практичным. Лучше было б иметь один назначаемый канал микшера, со всеми настройками, эквализацией, чувствительностью, и вспомогательными элементами, а также набор отдельных канальных фейдеров. Назначаемая кнопка на каждый фейдер канала вспоминает параметры канала полосы. Это вполне работающий метод, но когда требуется более быстрый доступ, или если один канал должен оставаться постоянно доступный, в этом случае два или более «назначаемых» канала будет лучше. И, конечно, это упростит параметры настройки канала.
«Назначаемые» консоли, как правило требуют больше труда ссылаясь на отдельные каналы один за другим. Пара консолей могут преодолеть эту проблему, путем выделения одного или двух регуляторов для каждого канала и назначая на них специальные функции.
Хотя «назначаемость» широко используется в цифровой аппаратуре, это также вполне применимо и к аналоговой. Так «возможность назначения» требует цифрового контроля поверхности пульта, отсюда и термин- «цифровое управление аналогом» -подход ,который в настоящее время представляет собой вершину конструкции микшеров.
В идеале, хорошо разработанная система имеет возможность полного контроля эргономикой, преимущества полной автоматизацией, один оператор контролирующий смехотворно большое количество каналов.
Для многих людей, топовым пунктом технической реализации пульта является то, что он «цифровой». Как и большинство цифровых консолей используют «назначаемый» контроль поверхностей, есть одно существенное различие с «аналогом с цифровым управлением» в способе обработки траектории сигнала.
Высококачественный аналоговый микшер имеет значительно большую полосу частот сигнала, и значительно низкий шумовой порог, чем любой цифровой пульт оснащенный простым 16-битный А-Ц и Ц-А преобразователем. Однако, цифровые консоли могут предоставить до 1500дБ внутреннего динамического диапазона, когда сигнал находится в цифровой области, невозможно практически получить перегруз на выходных каналах, или даже услышать любой шум, независимо от количества подключаемых каналов. Вместе.
В действительности, это всё еще относительно ранний этап в совершенствовании цифровых консолей, потому, что нынешнее поколении аналого-цифровых преобразователей не может сравниться с возможностями самых мощных чисто-аналоговых конструкций. Однако, то что разрешение преобразователей превышает 20 бит, и как производители повышают частоту дискретизации, есть растущая тенденция в сторону 96 кГц, кажется бесспорным что цифровые микшеры скоро заменят аналог полностью.
Устройство эквализайзера зависит от предназначения консоли, а также от его цены. Например, на недорогих консолях не может быть эквалайзеров везде.
Тем не менее основы или разработки в эквалайзерах, его главной особенностью является наличие переключателя на Байпас, так что исходные и измененные сигналы могут быть быстро сравнены. Человеческое ухо имеет плохую память, если постоянно не прокручивать образцы для сравнения. Так что эта функция поможет остановиться в те моменты, когда нужные изменения уже достигнуты, но хочется всё еще сделать звук громче и ярче!
На канале предназначена ручка возврата с эффектов и тому подобное, устройство EQ может быть ограничено чуть больше на низких и высоких регуляторах. А обычные входы, одна или больше регуляторов в среднем диапазоне, возможно с регулируемой добротностью Q. В общем, секция эквализации на большинстве микшеров предназначена обеспечить мягкую тональную коррекцию в случае компенсации неблагоприятной позиции микрофона, и помочь сигналу пройти в общий микс. Хотя, всегда есть исключения, микшерные эквалайзеры не принято использовать для устранения узкополосного шума ,как: низкочастотный гул, звуковая акустика или обратная связь. Внешнее оборудование является гораздо более эффективным.
Чтобы использовать эквалайзер эффективно, нужно слушать источник звука, определить что не так, и попробовать проанализировать, какие части частотного спектра нуждаются в корректировке, пользуясь переключателем EQ вкл./выкл (байбасс).
Другая ловушка — это трата времени на эквализацию звука в изоляции (в соло). Когда вы слушаете канал сам по себе, применяя корректирующую эквализацию, чтобы удалить нежелательный грохот, (spill) проникновения, то миксе все равно будет звучать совершенно подругому
Большинство микшеров обеспечивают точку разрыва (Insert) каналов, группы и основные выходы. Инсерты позволяют внешним процессорам эффектов ( обычно это компрессор или шумоподавление) обрабатывать сигнал через разрыв цепи. Более дорогие консоли имеют отдельные разьемы посыла и возврата сигнала, дешевые имеют один разьем стерео джек, требующий кабель в форме Y («штаны»), на одном конце которого разьем — TRS стерео, а на другом два разьема подходящих для коммутации со внешним эффектом. Разрыв может быть установлен в любом месте тракта, либо перед эквалайзером, либо после эквалайзера, или пре-фейдер и пост-фейдер. Иногда можно самостоятельно вручную в тракте пульта сформировать разрыв, установив переключатели на панели управления, и сконструировав два разрыва в различных местах.
Важно знать в какой точке установить разрыв сигнала, так как это может повлиять на функции обработки. Например GATE должен быть установлен до фейдера, в противном случае положение фейдера будет влиять на порог срабатывания эффекта, а это чревато полным исчезновением сигнала. По той же причине он также должен входить в тракт до эквалайзера. Обработка компрессора в режиме пре-фейд означает что фейдер канала эффективно действует на скомпрессированный сигнал, а пост-фейд режим сделает фейдер канала порогом контроля срабатывания. Регулирование фейдера будет иметь очень разные последствия в этом случае.
Точка разрыва также используется не только для подключения процессора эффектов, но и для многодорожечной записи сессии концертного усиления, во время которой микшер будет использоваться в целях как и звукоусиления, но и в целях звукозаписи. Если в пульте этот разьем раздельный, то можно подключит рекордер в разьем «Send»-посыл. Однако на TRS- оснащенных аппаратах сигнал идет через «Send», затем зацикливается через «Return» — возврат прежде чем продолжить свой путь по тракту пульта.