automation test что это за программа на андроид

Автоматизация тестирования Android приложений

Концепция автоматического тестирования

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

Далее рассматриваются средства, позволяющие автоматизировать перечисленные шаги.

Управление Android устройствами

Для начала нужно выделить компьютер на котором будет запускаться автоматическое тестирование и настроить на нем Android SDK. Примеры приводятся для компьютера с установленной ОС Linux.

На всех тестируемых устройствах нужно отключить экран блокировки и максимально увеличить время ожидания. Для некоторых методов тестирования нужно отключить смену ориентации экрана.

В Android SDK имеются две утилиты для управления устройствами: adb и MonkeyRunner.

Я постараюсь подробно описать автоматизацию действий, использующихся при тестировании. Тем, кто знаком с ADB и MonkeyRunner имеет смысл сразу переходить к разделу «Способы автоматизированного тестирования».

Управление с помощью утилиты ADB

ADB (Android Debug Bridge) – утилита для управления Android устройствами из командной строки. Официальная документация по ADB: developer.android.com/tools/help/adb.html

Проверка работы ADB

Устанавливаем и настраиваем Android SDK, подключаем к компьютеру Android устройства и выполняем команду:

Команда выдаст список всех подключенных устройств. Если список устройств не пуст, значит ADB настроен и работает.

Работа с несколькими устройствами

Основные команды ADB

Открыть консоль на устройстве:

Запустить команду на устройстве:

В Android присутствуют многие стандартные утилиты Linux: ls, cat, dmesg,…

Установить приложение из apk файла:

Название package можно получить из apk файла командой:

Загрузить файл с устройства на компьютер:

Загрузить файл с компьютера на устройство:

Запускает указанную activity. Название activity, которая запускается при выборе приложения в меню можно получить из apk файла командой:

Чтение логов

Чтение логов в Android производится утилитой logcat.
Домашняя страница утилиты logcat: developer.android.com/tools/help/logcat.html

Считать логи с устройства (блокируется до нажатия Ctrl-C):

Очистить буфер логов на устройстве:

Считать буфер логов на устройстве (выдает текущее содержимое буфера, не блокируется):

Снятие скриншотов с помощью утилиты screencap

Утилита screencap сохраняет текущее содержимое экрана в графический файл:

Утилита screencap имеется на телефонах с Android 4.x и выше. На предыдущих версиях Android снятие скриншотов можно производить с помощью MonkeyRunner.

Пример BASH скрипта для тестирования приложения c помощью ADB

Управление с помощью MonkeyRunner

Утилита MonkeyRunner предоставляет API для написания скриптов, которые управляют Android устройстами. С помощью MonkeyRunner можно написать скрипт на языке Python, который устанавливает Android приложение, запускает его, имитирует действия пользователя, снимает скриншоты и сохраняет их на компьютер. Утилита MonkeyRunner использует Jython для выполнения скриптов.

Чтение логов с помощью MonkeyRunner

Скрипт запишет логи в файл example.log в текущей директории.

Снятие скриншотов

Скрипт снимает скриншот и сохраняет его в файл screenshot.png в текущей директории.

Пример управления устройством с помощью MonkeyRunner

Средства автоматизированного тестирования

Тестирование с помощью monkey

Представьте, что устройство попало в цепкие лапы очень активной и творческой обезьяны – утилита monkey призвана имитировать подобную ситуацию.

Утилита monkey входит в состав Android SDK. Утилита отправляет на устройство поток псевдо-случайных действий пользователя. Параметры командной строки задают количество действий пользователя, соотношение их типов и имя тестируемого пакета, чтобы, например, обезьяна не вышла за пределы тестируемого приложения и не начала рассылать SMS по всем контактам из адресной книги.

Примеры использования и перечень параметров приведены на домашней странице: developer.android.com/tools/help/monkey.html

Главное достоинство monkey – отсутствие затрат на поддержку. Кроме того, стресс-тестирование приложения потоком произвольных событий может обнаружить нетривиальные ошибки.

Тестирование с помощью MonkeyRunner

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

Тестирование с помощью getevent/sendevent

На устройстве должны воспроизвестись записанные действия.

Тестирование с помощью Robotium

В отличии от рассмотренных ранее способов Robotium не входит в состав Android SDK, а распространяется под Open Source лицензией.

Главное отличие Robotium в том, что тестовые действия описываются на уровне интерфейса приложения. В рассмотренных ранее способах тестовые действия явно или неявно описывались на уровне устройств ввода.

Например, в приложении нужно нажать кнопку «OK». С помощью скрипта MonkeyRunner нажатие на кнопку реализуется как: «Коснуться точки экрана с координатами (x0, y0)». С помощью Robotium это реализуется как: «Нажать кнопку с текстом «OK»».

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

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

Например, после нажатия на кнопку «OK» в приложении должен появиться список с элементом «Item 1». С помощью Robotium можно проверить, появился ли список с таким элементом.

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

Сравнение способов тестирования

Анализ результатов

В результате тестирования приложения перечисленными выше способами мы получили логи и скриншоты. Теперь их нужно проанализировать на наличие ошибок.

Анализ логов

Анализ скриншотов

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

Также полезно сравнивать скриншот до и после запуска приложения – это позволяет определять случаи, когда приложение аварийно завершается без сообщений на экране и в логах.

MonkeyRunner позволяет сравнить два скриншота с заданным допуском в процентах:

К сожалению, в API MonkeyImage не предусмотрена функция загрузки из файла. Поэтому для сравнения сохраненных скриншотов придется писать свою функцию, например с помощью Python Imaging Library.

Сброс состояния устройства после тестирования

После тестирования приложения устройство нужно вернуть в первоначальное состояние.

Многократное нажатие кнопки «Назад»

Нажимаем кнопку «Назад» используя MonkeyRunner:

На практике этот вариант оптимален, так как имитирует поведение реального пользователя.

Заключение

В заметке были рассмотрены некоторые способы автоматического тестирования Android приложений, их достоинства и недостатки. Кроме того, рассмотрены инструменты, входящие в Android SDK или распространяющиеся под Open Source лицензией.

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

Источник

Автоматизация тестирования мобильных приложений: сравнение инструментов

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

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

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

Классификация инструментов

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

Автоматизация тестирования приложений на Android

UI Automator

Мощный инструмент тестирования с продвинутой внешней интеграцией. Это значит, что данный фреймворк не только позволяет тестировать само приложение, но также способен “общаться” с операционной системой и другими приложениями — например, активировать и деактивировать Wi-Fi, GPS, открывать меню настроек в ходе теста и производить другие внешние взаимодействия.

Предназначение UI Automator — тестирование “чёрного ящика” (black-box testing). Это значит, что анализ производится с позиций внешнего пользователя без доступа к коду.

К основным особенностям относятся:

Espresso

Более лёгкий по сравнению с UI Automator инструмент, не подходящий для взаимодействия с внешними приложениями, но удобный для тестирования “белого ящика” (white-box) с доступом к исходному коду конкретного приложения или тестирования “серого ящика” (grey-box), при котором имеется доступ к некоторым внутренним процессам и структуре.

Вместе с тем, Espresso выделяется мощным API https://github.com/hamcrest. Интерфейс добавляет удобные методы для проверок в автотестах, например:
assert_that(1, less_or_equal(2)). Для тестирования webview при этом используются специальные методы.

UI Automator и Espresso взаимно дополняют друг друга и могут использоваться в комплексе в рамках одного проекта.

Автоматизация тестирования iOS-приложений

XCUITest

Инструмент для black-box тестирования без обращения к коду приложения. Работает только с нативными продуктами — к сожалению, провести cross-app тесты не получится.

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

Полезным дополнением является test recorder, который даёт возможность писать тесты путём записи действий в приложении даже тем, кто не работает с кодом.

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

XCUITest, в отличие от Espresso, работает в отдельном потоке, во время тестирования нужно дождаться появления определенных элементов и параметров. Актуальное состояние приложения не считывается, и задержки в обновлении данных могут привести к невозможности обнаружения запрашиваемых элементов.

EarlGrey

У EarlGrey акцент сделан на воспроизведении пользовательского опыта. Пока элементы на экране не представлены визуально, имитация работы с приложением не запускается.

При этом отмечается ряд удобств и преимуществ. Во-первых, специалистам нравится то, как фреймворк синхронизирует запросы, UI и потоки. Не нужно никаких waitforview и wait.

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

Универсальные инструменты

Универсальные инструменты (или “комбайны”) позволяют не ограничивать свой выбор только Android или iOS, а работать с обеими платформами.

Такие инструменты применимы для тестирования приложений следующих видов:

Detox

На наш взгляд, Detox удобен для приложений, написанных на React Native. Тесты пишутся на JavaScript, при этом iOS и Android приложения генерируются из одного и того же кода JavaScript и максимально похожи. Это позволяет использовать одинаковые тесты для обеих платформ.

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

Detox может обращаться к памяти и отслеживать выполняемые процессы. Принцип grey-box помогает бороться с неустойчивостью, выражающейся в том, что при сквозном тестировании:

Detox не нуждается в WebDriver, работая с нативным драйвером через JSON. Он задействует нативные методы прямо на устройстве. Внутри данного фреймворка применяются EarlGrey для iOS и Espresso для Android.

Фреймворк работает как с эмуляторами, так и с физическими устройствами.

Appium

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

При тестировании используются фреймворки от вендоров — то есть вы работаете именно с исходным приложением. Для Android 4.2+, соответственно, применяется UiAutomator/UiAutomator2, а для iOS 9.3+ — XCUITest. В качестве оболочки фреймворков используется WebDriver (он же — Selenium WebDriver).

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

Ranorex

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

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

Легко интегрируется с существующей CI-средой: с такими системами управления заявками, как Jira и TFS, а также с системами контроля версий — например, Git и SVN.

В Ranorex прокачано data-driven тестирование с подгрузкой данных из SQL, CSV, Excel.

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

Сочетает все три подхода к тестированию: black-box, white-box и grey-box.

TestComplete

Платная среда для автоматизации тестирования мобильных, веб и десктопных приложений. Поддерживает Android и iOS, а в разрезе типов приложений: нативные, веб-приложения и гибридные.

Ориентированный, в основном, на функциональное и юнит-тестирование, инструмент также предоставляет возможность проводить многие другие виды тестирования:

Данный инструмент распознаёт объекты и элементы управления, предлагая специальные команды для эмуляции взаимодействия пользователя с ними. Интегрируется с Jenkins, Git и Jira, что позволяет запускать непрерывное бесшовное тестирование.

Подводя итоги

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

Рассмотрим на примере. Если перед вами стоит задача протестировать небольшое приложение в сжатые сроки, в первую очередь нужно учитывать такие факторы, как тип тестируемого приложения и опыт ваших специалистов. Если тесты пишет разработчик, лучше выбрать родной язык и инструмент для его платформы (см. в таблице ниже). Если тестами занимаются специалисты SDET, которые знакомы с другими языками (Java, JavaScript, Python и др.) и работали с Selenium, удобно использовать Appium. Если опытного SDET в команде нет, а тесты будут писать специалисты QA, лучше выбрать платные фреймворки, поскольку в них есть утилиты для записи тестов и более стабильная техподдержка, чем в open source фреймворках.

Из нашей практики:
Мы работали с одним интернет-магазином, у которого было два мобильных приложения – на iOS и Android. Для покрытия тестами основных пользовательских сценариев мы выбрали Appium по нескольким причинам:

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

Источник

Ускорить смартфон

Все нижеописанные операции с лёгкостью могут превратить ваш смартфон в кирпич! 100 раз подумайте и изучите нюансы, прежде чем что-то делать. И всё забекапить, да.

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

Для начала я досконально посмотрел на оперативу, что до рута было мне недоступно: оказалось, что в ней сидит куча хлама, который я использую раз в год и закрываю сразу после использования. Даже если закрыть принудительно процесс в оперативе, то он всё равно скоро сам запустится. Причём это не какой-нить индийский говнософт. Ща уже забылось, но помню яндекс-карты жрали около 50 МБ оперативы. Для масштаба: после загрузки смарта доступны около 500 МБ. И я могу их понять: каждая прога хочет сидеть в оперативе, чтобы быстро запускаться и всякие свои служебные дела делать. Если прога позаботится о пользователе и будет выгружать себя из оперативы, то высок риск что пользователь сменит её на другую, которая быстро запускается, так как сидит в оперативе. А то, что именно из-за неё тормозит смарт пользователь не узнает, ведь таких прог в оперативе множество. Поэтому разработчики вынуждены жертвовать быстродействием смартфона.

На моём смарте около 280 процессов. Думаю, около 100 я на тот момент уже заблокировал. Если посмотреть на названия остальных работающих процессов, то можно увидеть, что присутствует куча ненужного (или редкоиспользуемого) многим хлама. Процессы для bluetooth, VPN, сетевых служб, заставок экрана, фона рабочего стола, шрифтов, принтеров, системных настроек. Заблокировав много чего из перечисленного у меня перестал работать инет и звонки. Пришлось что-то возвращать обратно и блокировать внимательнее. Назначение процессов можно было понять из названий, значков и при помощи гугла.

1. Некоторые приложения при запуске ругаются на отсутствие некоторых гугловских сервисов, но работать ни им, ни мне это не мешает.

3. Не работают приложения Google sheets и Google docs (требуется вагон процессов). Для меня это не большая, но заметная проблема. Поэтому когда приспичит (раз в два месяца), я их использую из браузера.

4. Я заблокировал даже те приложения, которые использую раз в неделю. Соответственно, пару раз в неделю я лезу в Titanium Backup и разблокирую их. На это уходит около 5-10 секунд, но выигрыш от свободной оперативы гораздо больше.

Источник

Автотесты на Android. Картина целиком

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

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

Зачем нужны автотесты?

Есть мнение, что UI-тесты не нужны, если у вас достаточное количество юнит- и интеграционных тестов. Но от следующей метафоры никуда не деться. Представьте, что вы собираете велосипед. У вас есть два хорошо протестированных колеса, протестированная рама вместе с седлом, протестированная система педалей с цепью и рулем. То есть мы с вами имеем хороший набор интеграционных и юнит-тестов. А велосипед-то в итоге поедет? Чтобы это проверить, вы нанимаете ручных тестировщиков, которые перед каждым релизом должны убедиться, что безупречные детали корректно взаимодействуют друг с другом, и велосипед будет ездить и доставлять пользователю удовольствие.

Так же и с любым программным обеспечением для мобилок. К сожалению, в мобильном мире мы не можем откатить неудачные изменения быстро, ведь все обновления идут через Google Play Store и App Store, что сразу накладывает ограничения в виде долгой раскатки в сравнении с веб- и backend-аналогами, обязательной совместимости версий и зависимости от решения пользователя обновляться или нет. Поэтому нам критически важно всегда убеждаться перед релизом, что основные пользовательские сценарии приложения работают именно так, как ожидается.

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

Все это естественным образом подводит к необходимости автоматизации проверки пользовательских сценариев, то есть написания end-to-end- или автотестов. У «Авито» есть рассказ о том, как автотесты помогают и сколько они стоят (2019 год). Однако большинство команд такой метод отпугивает своей сложностью и необходимостью вкладывать существенные ресурсы, чтобы выстроить процесс. Это возвращает нас к цели данной статьи и вообще к одной из целей Avokado Project — стандартизировать процесс автотестирования в Android и существенно уменьшить его стоимость.

Картина целиком

Итак, обещанная картина целиком.

Если вы чего-то не понимаете, не переживайте. Мы сейчас пройдемся подробно по всем пунктам.

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

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

Выбор инструментов для написания автотестов

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

Первая развилка — это выбор между кроссплатформенным решением (Appium и т. д.) и нативным решением (Espresso, UI Automator). Много копий сломано в этих спорах. Рекомендуем посмотреть выступление наших коллег, полное драматизма и накала страстей.

Спойлер — мы за нативные решения. По нашему опыту, они:

Кроме того, Google поддерживает Espresso и UI Automator.

Больше почитать про сравнение вы можете в статьях:

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

Kaspresso

Kaspresso — это фреймворк, который:

Вы можете прочитать о Kaspresso на GitHub и Habr.

Test runner

Вы написали несколько тестов. Теперь их нужно запустить. За этот этап отвечает Test Runner, или просто раннер.

Что нам предлагает Google? Утилиту AndroidJUnitRunner и ее специальный режим — Orchestrator. AndroidJUnitRunner делает то, что от него и требуется — просто запускает тесты, позволяя еще и параллелить их выполнение. Orchestrator позволяет продолжить выполнение тестов, даже если некоторые из них упали, и дает возможность минимизировать общее состояние между тестами. Так достигается изоляция исполнения каждого теста.

Но со временем требований к раннеру становится все больше. Вот некоторые из них:

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

Однако, Marаthon, к сожалению, не обладает некоторыми важными, по нашему мнению, свойствами. В частности, в нем нет:

Кроме того, мы считаем, что раннер должен быть платформенным, то есть либо для Android, либо для iOS. Это обусловлено уникальной спецификой каждой ОС и вытекающей отсюда сложностью внесения изменений в раннер.

Поэтому прямо сейчас мы работаем над Avito Runner, в котором хотим собрать все лучшие и зарекомендовавшие себя наработки и идеи. Ждите будущих анонсов!

На чем запускать тесты

Параллельно с вопросом о том, какой раннер выбрать для тестов, перед вами встает другой: а на чем лучше запускать тесты? Есть три опции:

Мы делаем ставку на Docker.
В сети есть разные Docker-образы Android-эмуляторов, мы рекомендуем обратить внимание на следующие:

Как уже было упомянуто выше, подготовка образа требует некоторой сноровки. Плюс зачастую есть желание эмулятор преднастроить: выключить анимацию, залогиниться в аккаунт Google, выключить Google Play Protect и многое другое. Все эти вещи непросто организовать. Поэтому в скором времени мы хотим выкатить подробную документацию о том, как готовить и использовать образы быстро.

Инфраструктура

Вы написали сотни UI-тестов. Часть из них вы хотите запускать в рамках PR, а значит, весь тестовый набор должен проходить в максимально короткие сроки, например, до 20 минут. Вот тут наступает настоящее масштабирование.

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

Итак, что вам примерно предстоит:

В ближайшее время мы планируем выпустить Avito Runner и статьи, которые помогут настроить инфраструктуру.

Остальное

Не забывайте про такие немаловажные моменты, как:

Про все это мы еще обязательно поговорим.

Заключение

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

Источник