Post или pre лучше и где применяется

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 – перевод

Как выбрать инструмент для тестирования 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.

Словарь киношника: часть 2

Сет дизайнер — оформляет съемочное пространство, отвечает за декорации для фотосессий или модных показов.

Стилист по волосам — мастер, который делает прически или стрижки, а также подбирает стиль, который наиболее подходит для съёмок.

Стедикам – вспомогательное оборудование камеры, предназначенное для стабилизации камеры и, соответственно, изображения при ручной съемке.

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

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

Саунд-дизайнер — это профессиональный эксперт в работе со звуковым, шумовым и музыкальным сопровождением.

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

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

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

Продакшн бриф – документ, в котором описаны все пожелания заказчика по поводу будущего рекламного ролика со всеми необходимыми замечаниями и пометками продакшна.

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

Продакт плейсмент/ рекламная интеграция — приём неявной (скрытой) рекламы , заключающийся в том, что реквизит, которым пользуются герои в фильмах, телевизионных передачах, компьютерных играх, музыкальных клипах, книгах, на иллюстрациях и картинах, имеет реальный коммерческий аналог. Может проявляться в демонстрации непосредственно самого́ рекламируемого продукта, его логотипа, а также упоминания продукта в положительном смысле.

Например, наши проекты с рекламной интеграцией.

Проп- стилист — человек, который выстраивает композицию для предметной съемки.

ППМ (pre-production meeting) — обсуждение всех деталей перед съемкой проекта: согласование сценария, раскадровок, костюмов, актеров, локаций, приемов. Особенно важен на больших проектах.

Прелайт (pre-light) — упрощенное выставление осветительной техники за день или несколько дней.

Прешут (pre-shoot) — процесс, в ходе которого режиссёр и оператор делают черновые кадры всего будущего ролика/фильма или отдельных сцен. Часто часть кадров снимается, а другая заполняется стоковыми материалами.

Продакшен сервис (Production service) — услуга по организации процесса съемок уже готовой концепции. Кинемотор принимал участие на следующих проектах в качестве продакшн-сервиса:

Пэкшот (pack-shot) — это кадр с изображением продукта в рекламе, как правило вместе с логотипом или лозунгом. Обычно пэкшотом заканчивается рекламный ролик.

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

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

Референс(или просто «реф») — это образец или пример, на который ссылаются при создании проекта. Продюсер иногда просит предоставить такие примеры, чтобы лучше себе представить атмосферу или стилистику изображения будущего ролика. Основной термин в продакшене. Часто необходимо уделять львиную часть рабочего времени для поиска подходящих рефов.

Ротоскопинг — техника покадрового отделения объекта от фона. Относительно долго и дорого. Нужна для удаления/вырезания объектов, если невозможно использовать хромакей.

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

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

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

Фокус-пуллер — первый ассистент оператора, ответственный за фокусировку объектива.

Фуд-стилист — специалист по оформлению продуктов для фотографирования. Их цель — сделать продукты питания и напитки как можно более привлекательными и желанными на фотографии и видеороликах.

Хромокей (или просто «хромак») — задник / фон зеленого или синего цвета из специального материала; используется с целью наложения любого фонового изображения в процессе обработки и монтажа отснятого материала. Чаще всего применяется для съемки новостных программ или рекламных роликов со сложной компьютерной графикой.

Художник по гриму — полностью разрабатывает образ актера, отвечает за то, как этот образ будет “работать” в кадре. Поэтому художник глубоко изучает сценарий фильма и характер героев, чтобы придумать общую концепцию. Затем он совместно с режиссером подбирает референсы и детали образа. Наконец он закупает нужные материалы, а также согласует свою работу с общим съемочным графиком.

Художник раскадровщик – специалист, отвечающий за представление сценария в графической форме.

Художник-постановщик — человек, ответственный за визуальное решение в кадре: цвет, локация, реквизит, декорации. Работает в тандеме с режиссером-постановщиком и оператором-постановщиком.

Цейтраферная съемка (обычно используется термин «Таймлапс») — специальный вид кино- и фотосъемки, при которой осуществляется фотографирование серии кадров одного и того же объекта с одной и той же точки съемки через равные промежутки времени. Предназначается для фотографирования медленно протекающих процессов. Промежутки могут длиться от долей секунды (серийная съемка) до часов и даже суток. Называется также «интервальной съемкой».

Некоторые таймлапсы можно увидеть в данном проекте в самом начале.

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

Шурехи — это любые мелкие детали и объекты, а также другие структуры, не несущие прямой смысловой нагрузки. Используются для придания необходимой атмосферы и декорирования кадры. Добавляются на постпродакшне.

NDA (non-disclosure agreement, соглашение о неразглашении) — юридический договор, заключённый двумя сторонами с целью взаимного обмена материалами, знаниями или другой информацией с ограничением к ней доступа третьим лицам. Данный тип соглашений служит для предотвращения утечки любой конфиденциальной информации: от коммерческой тайны до персональных данных

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

VFX — визуальные эффекты, созданные на компьютере.

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

Модуль Pre/Post ANSYS CFX

Мы продолжаем знакомить наших читателей с возможностями современных расчетных комплексов компании ANSYS, Inc. В настоящей статье на примере гидравлического расчета воздуховода системы вентиляции рассмотрены основные приемы работы с программным продуктом ANSYS CFX. Кроме того, для полноты изложения материала мы включили в статью описание последовательности построения расчетной сетки для нашей задачи в ICEM CFD. В этот раз мы создадим сетку, составленную из гексаэдрических элементов. Таким образом, следуя нашим инструкциям, вы всегда сможете без особого труда решить похожую задачу в расчетном комплексе ANSYS CFX.

Прежде всего — несколько слов о модуле ICEM CFD/Hexa. В основе метода построения гексаэд- рической сетки в ICEM CFD лежит понятие блока: практически любая твердотельная модель может быть описана набором блоков, точно повторяющих ее топологию. Например, круглое U-образное колено можно представить в виде шести блоков- параллелепипидов, как это показано на рис. 1.

Рис. 1. Пример блочной структуры.

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

Рис. 2. Геометрия расчетной модели.

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

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

Теперь перейдем к практической части нашего мастер-класса. Вид и основные геометрические размеры расчетного объекта показаны на рис. 2. Это тройник прямоугольного сечения с плавным поворотом на 90°. Поскольку тройник обладает симметрией, достаточно вырезать из него половину и в препроцессоре ANSYS CFX задать на соответствующей поверхности граничное условие симметрии.

Построение гексаэдрической сетки

Импортируем геометрическую модель в ICEM CFD. Наша модель была предварительно сохранена в формате Parasolid, поэтому используем команду File ^Import Geometry ^ParaSolid, указываем директорию, в которой находится файл, и единицы измерения. Последняя опция служит также для масштабирования модели, если это необходимо.
Переходим в меню Blocking ^Create Block. Выбираем тип блока 3D Bounding Box, затем с помощью ограничивающего прямоугольника (левая кнопка мыши) выделяем все геометрические объекты, которые в данный момент отображаются на экране. Нажимаем кнопку OK.

Рис. 3-8. Этапы построения гексаэдрической сетки.

Рис. 9-10. Завершение построения сетки.

Препроцессор ANSYS CFX

Чтобы начать работу в ANSYS CFX, необходимо загрузить CFX Launcher и далее в поле Working Directory указать рабочую директорию проекта. При выборе имени директории следует учитывать, что Launcher не распознает буквы русского алфавита и специальные символы.

Вызов модуля CFX-Pre производится из главного меню CFX — CFX-Pre — на экране появляется пустое окно проекта. Для создания нового проекта следует перейти в меню File — New Simulations и в режиме General создать файл.

Графическое окно препроцессора условно можно разделить на три области: 1 — область меню, 2 — область дерева модели, 3 — окно просмотра (рис. 11).

Область дерева модели состоит из нескольких закладок: Physics — задание граничных условий, выбор физических моделей; Mesh — операции с расчетной сеткой; Regions — работа с расчетной областью; Expressions — создание выражений (например, для задания профиля скорости на входе); Materials — выбор материалов и указание их свойств; Reactions — выбор моделей горения или описание химических реакций.

После создания нового файла мы автоматически попадаем в закладку Mesh. Для импорта сетки нажимаем на кнопку Import mesh, находящуюся в правой части закладки. Указываем тип сетки (Mesh Format), то есть в нашем случае — ICEM CFD, выбираем нужный файл и размерность единиц — мм. В общем случае можно импортировать несколько сеток и соединить их интерфейсами.

После импорта сетки необходимо определить расчетную область (Domain) и все физические условия в ней. Команда определения расчетной области вызывается из главного меню следующим образом: Create — Flow Objects — Domain. После указания имени на экране должна появиться панель Edit Domain, где мы указываем тип расчетной области — Fluid Domain, рабочее тело — Air Ideal Gas и относительное давление — 101 325 Па.

Далее переходим в закладку Fluid Models и в списке Heat Transfer Model выбираем изотермический (Isothermal) расчет. Устанавливаем температуру рабочего тела в расчетной области равной 50 °С. В качестве модели турбулентности выбираем Shear Stress Transport (SST).

Рис. 11. Окно препроцессора ANSYS CFX (CFX-Pre).

Следующий шаг создания расчетной модели — это задание соответствующих граничных условий на границе расчетной области. Мы будем использовать следующие типы граничных условий: Inlet (Вход), Opening (Свободный выход), Symmetry (Симметрия) и Wall (Стенка). Расстановка граничных условий осуществляется командой Create—Flow Objects—Boundary Conditions.

Рис. 12. Панель Define Run.

На входе задаем скорость (Normal speed) 20 м/с и начальный уровень турбулентности потока 5%. На выходе задаем условие Opening с опцией Opening Pressure and Directions. В поле Relative Pressure задаем давление 0 Па и указываем направление потока (Flow Direction) как перпендикулярное плоскости выхода. На боковой стенке половины тройника ставим условие симметрии Symmetry.

По умолчанию на оставшихся поверхностях будет задано граничное условие Wall (No Slip).

В меню Solver control (Create—Flow Objects — Solver Control) задаются параметры, которые определяют процесс расчета: метод расчета, критерий сходимости, число итераций и шаг по времени. В нашем случае мы укажем максимальное число итераций (Max. Iterations) — 1000 и выберем опцию автоматического определения шага по времени Auto Timescale.

Сохраняем все настройки расчетного варианта в файл-описание (*.def): File — Write Solver File. После выполнения этого действия автоматически загрузится Solver Мanager, а на экране появится панель Define Run (рис. 12).

Постпроцессор ANSYS CFX

Рассмотрим кратко интерфейс постпроцессора ANSYS CFX и методы работы с ним.

Постпроцессор ANSYS CFX работает с файлами результатов (*.res, *.trn), файлами сеток в собственном формате (*.gtm), файлами ошибок, генерируемых решателем (*.res.err), файлами-описаниями (*.def) и др.

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

Для перехода в режим постпроцессора следует вызвать из главного меню CFX Launcher команду CFX -> CFX-Post. В результате на экране появится главное окно постпроцессора CFX-Post (рис. 13).

Сразу же можно заметить, что постпроцессор ANSYS CFX имеет схожий с препроцессором интерфейс, поэтому главное окно CFX-Post так же легко делится на три условные зоны: 1 — дерево постпроцессора (выбор объектов), 2 — редактирование настроек объектов, 3 — окно просмотра (см. рис. 13).

Рис. 13. Окно постпроцессора (CFX-Post).

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

Создание геометрического объекта

В постпроцессоре ANSYS CFX можно создать следующие геометрические объекты: точки (Point), облако точек (Point Cloud), линии (Line), плоскости (Plane), поверхности (Isosurface — изоповерх- ности и Surface of Revolution — поверхности вращения), объемы (Volume) и сплайны (Polyline).

Для создания геометрических объектов применяется команда Create^Location и далее из выпадающего списка выбирается нужный объект, например плоскость. Затем следует присвоить имя новой плоскости (Plane 1) и нажать на Apply. На экране слева (область 2) появится панель редактирования свойств объекта (рис. 14).

Рис. 14. Панель редактирования свойств объекта.

Для создания плоскости могут использоваться следующие способы (Definition Method) из закладки Geometry: Three Points — по трем точкам, Point and Normal — по точке и нормальному вектору, XY/YZ/ZX Plane — по любым двум ортам.

Мы применили метод ZX Plane. С помощью ползунка можно перемещать секущую плоскость по нормали (ось Y) вверх-вниз.

Для отрисовки линий пересечения граней элементов расчетной сетки с плоскостью следует перейти в закладку Render, убрать галочку напротив Draw Faces и поставить ее напротив Draw Lines. Далее необходимо поменять режим Colour Mode с Default на User Specified и выбрать цвет линии. Вид секущей плоскости представлен на рис. 15.

Рис. 15. Вид секущей плоскости.

Заливка

Для тоновой заливки плоскости необходимо выполнить следующие действия: перейти в закладку Colour и изменить режим цвета c Constant (постоянный) на Variable (переменный). После этого из списка Variable следует выбрать нужную переменную (Pressure, Temperature, Total Pressure…) и указать диапазон изменения (Range) значений расчетной переменной (по умолчанию — Global, то есть максимальное и минимальное значения переменной, полученные во всей расчетной области). Затем нужно нажать на кнопку Apply. Как видите, изображение в окне просмотра осталось прежним. Но здесь все верно — просто мы забыли в закладке Render снять галочку напротив Draw Lines. На рис. 16 представлено поле давлений.

Рис. 16. Поле давлений.

Создание векторов

Для создания векторов используется команда Create—Vector.

В качестве опорного объекта в поле Locations указываем плоскость Plane 1. В списке режимов дискретизации (Sampling) выбираем Equally Spaced (равноотстоящие векторы) и в поле параметра # of Points указываем нужное число векторов. В качестве переменной (для раскраски векторов) выбираем скорость (Velocity). Результат приведен на рис. 17.

Длина векторов регулируется параметром Symbol Size, который находится в закладке Symbol. Если вы хотите, чтобы все векторы имели одинаковую длину, используйте операцию Normalize Symbols.

Рис. 17. Вектора скоростей.

Детализация структуры течения

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

Начнем с создания сферы Volume 1, ограничивающей вихревую зону: Create — Location — Volume. В списке Method выбираем Sphere и указываем координаты центра сферы (-0,35; 0; -0,3) и радиус сферы (150 мм).

Теперь, если мы выберем режим Below Intersection, то получим сферу, а если Above Intersection — объем, полученный вычитанием из объема расчетной области объема сферы.

Следующий шаг — построение линий тока, ограниченных объемом сферы. Команда построения линий тока вызывается из главного меню Create—Streamline. Используем следующие настройки объекта Streamline: Type — 3D Streamline, Start From — Volume 1, Reduction — Max Number of Points, Max Points — 50, Variable — Velocity, Direction — Forward.

Для отображения на экране точек, из которых будут запущены треки, нажмите на кнопку Preview Seed Points .

После этого в разделе Symbol мы должны поставить галочку напротив Draw Symbols (отрисовка символов) и выбрать символ — это может быть Arrowhead (острие стрелки), Ball (шар), Fish3D (рыбка) и др. Мы остановили свой выбор на Arrowhead (рис. 18).

Рис. 18. Структура вихревой зоны.

Создание двумерного графика

В заключение расскажем о том, какие действия надо выполнить в постпроцессоре ANSYS CFX, чтобы построить график изменения какой-либо расчетной величины вдоль произвольной кривой.

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

Предварительной операцией по созданию кривой является построение срединной поверхности, которая для постпроцессора является типичной User Surface (поверхность пользователя). Выполняем команду Create^Location^ User Surface. В закладке Geometry выбираем метод построения поверхности Offset From Surface (эквидистантная поверхность). В качестве опорной поверхности используем одну из стенок воздуховода (на рис. 19 она выделена синим цветом).

Рис. 19. Срединная поверхность.

В поле Distance указываем расстояние, на которое перемещается опорная поверхность, — в нашем случае это 100 мм. Все остальные настройки оставляем без изменений. Нажимаем на кнопку Apply. Срединная поверхность (User Surface 1) построена.

После этого создаем контур (Contour) с помощью команды Create ^Contour. В качестве Locations указываем поверхность User Surface 1, выбираем переменную Pressure и задаем число контуров (# of Contours) равным 3. В результате срединная поверхность приобретет вид двух полос-контуров (на рис. 19 — желтая и бирюзовая полосы).

Теперь приступим к созданию самой кривой (Polyline 1): Create ^Location ^Polyline. Выбираем метод From Contour (Извлечь из контура) и указываем контур (Contour). Нажимаем на кнопку Apply. На этом процедуру построения вспомогательной кривой можно считать завершенной.

Рис. 20. Панель Chart.

Для создания графиков используется команда Create ^Chart. Переходим в закладку Chart Line и в списке Locations выбираем Polyline 1. В качестве переменной, значения которой будут откладываться по оси Х, указываем Chart Count, а по оси Y — Pressure (рис. 20).