Визуальные ошибки это

Как устранить слепые зоны с помощью визуального тестирования

Время на прочтение
4 мин

Количество просмотров 2.1K

Перевод статьи подготовлен в преддверии старта курса «Python QA Engineer».


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

Самое плохое в визуальных ошибках это то, что их нельзя «поймать» с помощью обычного автоматизированного тестирования. Так происходит потому, что большинство инструментов автоматизированного тестирования сверяются с DOM (document object model), чтобы сообщить о состоянии приложения.

Например, приложение из этого твита не показывает последнюю цифру цены, однако полная цена есть в DOM. В первом случае настоящая цена 1250 новозеландских долларов, но отображается она как 125 новозеландских долларов. Очень большая разница!

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

Что такое визуальное тестирование?

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

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

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

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

Надо ли начинать все сначала?

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

Визуальное тестирование можно интегрировать в вашу уже существующую систему тестирования. Многие инструменты визуального тестирования поддерживают все основные языки программирования, а также фреймворки автоматизации, такие как Selenium WebDriver, Cypress, Appium и другие.

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

Например, в примере из Wellington Suite выше, текущие тесты, скорее всего, включают в себя assert-ы для цен. Конечно же, вы можете оставить их и к ним уже добавить визуальные тесты, чтобы убедиться, что цены отображаются правильно. Сравнение, произведенное алгоритмами визуального тестирования, уже гарантирует, что цена корректная и отображается правильно. В итоге получается, что для тестов нужно писать меньше кода, а чем меньше кода, тем легче его поддерживать.

Что делать, если я не хочу делать снимок всего экрана?

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

Игнорирование областей

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

Рамки для области

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

Будьте внимательны с границами

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

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

Что насчет динамических данных, которые разнятся от теста к тесту?

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

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

Неужели визуальное тестирование применимо только в веб-приложениях?

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

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

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

Как начать работать с визуальным тестированием

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


Тестирование вёрстки с помощью Selenium и Python.


Содержание

  1. Мобильный дизайн: сообщения об ошибках — Часть 1
  2. Что такое сообщение об ошибке?
  3. Легче предупредить, чем исправить
  4. Сообщения об ошибках неправильного ввода данных
  5. 1. Правильное время (встроенная валидация)
  6. 2. Правильное место
  7. 3. Правильный цвет (интуитивный дизайн)
  8. 4. Понятное сообщение
  9. Ошибки приложений
  10. Используйте изображения и юмор
  11. Как устранить слепые зоны с помощью визуального тестирования
  12. Что такое визуальное тестирование?
  13. Надо ли начинать все сначала?
  14. Что делать, если я не хочу делать снимок всего экрана?
  15. Игнорирование областей
  16. Рамки для области
  17. Будьте внимательны с границами
  18. Что насчет динамических данных, которые разнятся от теста к тесту?
  19. Неужели визуальное тестирование применимо только в веб-приложениях?
  20. Как начать работать с визуальным тестированием

Мобильный дизайн: сообщения об ошибках — Часть 1

Ошибаться свойственно всем. Ошибки возникают и при взаимодействии людей с пользовательскими интерфейсами (user interfaces). Иногда они происходят по вине человека, а иногда причина кроется в самом приложении. Какова бы ни была причина, ошибки и то, как вы справляетесь с ними, оказывает огромное влияние на пользовательский опыт (user experience). Бесполезные сообщения об ошибках могут привести к тому, что пользователь разочаруется и найдет замену вашему приложению.

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

Что такое сообщение об ошибке?

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

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

Легче предупредить, чем исправить

Если вы разрабатываете приложение, то вам должны быть известны наиболее распространенные взаимодействия, способные привести к ошибкам. Например, обычно бывает трудно заполнить форму с первой попытки или невозможно синхронизировать данные из-за плохого соединения с сетью. Эти случаи нужно учитывать, чтобы свести к минимуму ошибки. Другими словами, лучше их предотвратить, предлагая пользователю советы и проявляя гибкость.

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

Мудрое решение в этом случае представляет Booking.com: их селектор диапазона дат позволяет выбрать только текущую или последующие даты, и человек таким образом никак не сможет ошибиться.

Приложение Booking.com делает прошедшие даты неактивными для выбора

Сообщения об ошибках неправильного ввода данных

Валидация форм необходима для сообщения пользователю об имеющихся неточностях в введенных им данных. Хорошая валидация формы содержит четыре важных элемента:

1. Правильное время (встроенная валидация)

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

Валидация должна незамедлительно информировать пользователей о правильности введенной ими информации. Главный принцип хорошей валидации формы таков: Разговаривайте с пользователями! Говорите им, что идет не так! Это поможет им сократить время на исправление ошибок.

2. Правильное место

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

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

3. Правильный цвет (интуитивный дизайн)

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

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

4. Понятное сообщение

Ваше сообщение об ошибке должно четко говорить пользователю, что конкретно не так и что ему нужно исправить. То есть вместо вывода сообщения «недействительный email» следует уточнить, что именно неправильно: допущена опечатка, этот e-mail уже занят и т.д. Затем необходимо предложить пользователю варианты действий (войти или восстановить пароль).

«Этот email уже зарегистрирован. Хотите войти или восстановить свой пароль?»

Ошибки приложений

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

Вы никогда не должны показывать сообщения следующего рода:

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

Это сообщение об ошибке было написано разработчиком для разработчика: «Операция не может быть завершена (WDGeneralNetworkError 500)»

2. Тупиковое сообщение. Такие сообщения не дают никакой полезной информации для пользователей.

Экран приложения Spotify просто заявляет о том, что «произошла ошибка», и не дает никаких дальнейших рекомендаций пользователю

3. Абстрактное сообщение. Сообщение в примере ниже дает пользователям ровно такой же объем информации, как и в предыдущем случае. Непонятно, что оно означает и что делать дальше.

«Сервер c таким именем хоста не может быть найден. Повторите попытку»

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

Ваше сообщение об ошибке должно четко и понятным для пользователя языком информировать о том:

  • Что пошло не так и по какой возможной причине
  • Что должен сделать пользователь, чтобы исправить эту ошибку

«Не удается подключиться к этой сети. Вы должны подключиться к Wi-Fi сети, чтобы управлять iTunes или Apple TV»

Используйте изображения и юмор

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

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

В Gmail при создании нового аккаунта можно натолкнуться на такое сообщение об ошибке:

А вы фанат пунктуации! Увы, имена пользователей не могут содержать многоточия

Тем не менее, юмор не всегда может быть уместен. Это зависит от того, насколько серьезная проблема. Например, юмор вполне можно использовать для констатации такой простой проблемы как «Ошибка 404. Страница не найдена.» Однако когда пользователь теряет значительное количество времени в результате сбоя, говорить «Опаньки!» совершенно неуместно.

«Опаньки! Возникла ошибка, и мы не смогли опубликовать эту историю»

Итак, чтобы создать идеальную страницу ошибки, стоит учесть следующее:

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

Источник

Как устранить слепые зоны с помощью визуального тестирования

Перевод статьи подготовлен в преддверии старта курса «Python QA Engineer».

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

Самое плохое в визуальных ошибках это то, что их нельзя «поймать» с помощью обычного автоматизированного тестирования. Так происходит потому, что большинство инструментов автоматизированного тестирования сверяются с DOM (document object model), чтобы сообщить о состоянии приложения.

Например, приложение из этого твита не показывает последнюю цифру цены, однако полная цена есть в DOM. В первом случае настоящая цена 1250 новозеландских долларов, но отображается она как 125 новозеландских долларов. Очень большая разница!

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

Что такое визуальное тестирование?

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

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

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

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

Надо ли начинать все сначала?

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

Визуальное тестирование можно интегрировать в вашу уже существующую систему тестирования. Многие инструменты визуального тестирования поддерживают все основные языки программирования, а также фреймворки автоматизации, такие как Selenium WebDriver, Cypress, Appium и другие.

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

Например, в примере из Wellington Suite выше, текущие тесты, скорее всего, включают в себя assert-ы для цен. Конечно же, вы можете оставить их и к ним уже добавить визуальные тесты, чтобы убедиться, что цены отображаются правильно. Сравнение, произведенное алгоритмами визуального тестирования, уже гарантирует, что цена корректная и отображается правильно. В итоге получается, что для тестов нужно писать меньше кода, а чем меньше кода, тем легче его поддерживать.

Что делать, если я не хочу делать снимок всего экрана?

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

Игнорирование областей

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

Рамки для области

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

Будьте внимательны с границами

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

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

Что насчет динамических данных, которые разнятся от теста к тесту?

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

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

Неужели визуальное тестирование применимо только в веб-приложениях?

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

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

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

Как начать работать с визуальным тестированием

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

Источник

Визуальные проблемы сайта

Сейчас Chrome-браузеры безусловно доминируют у пользователей (включая даже браузер Opera, который использует движок Chrome), поэтому проверка работы сайта в Chrome — это первое, что нужно сделать. Для проверки отображения сайта (или страниц сайта) в других браузерах можно воспользоваться Browser Shots — и задать самые последние версии популярных (пока еще) браузеров — Mozilla Firefox, Internet Explorer или Safari.

Для проверки отображения сайта на мобильных устройствах можно воспользоваться либо проверкой WebPageTest — нужно выбрать мобильный браузер для проверки скорости, будет снят скриншот сайта по итогам проверки. Для более детальной проверки можно воспользоваться Cross Browser Testing.

По скриншотам сайта практически всегда видно, есть ли какие-то проблемы с отображением или версткой. И что нужно поправить (где что «разъехалось»).

Другим подходом по исправлению ошибок сайта является приведение страниц сайта к стандартам. Основных стандартов, отвечающих за визуальную составляющую сайтов, три — HTML, CSS, WCAG (последний отвечает за удобство использования сайта). К сожалению, кроссбраузерная верстка на текущий момент, практически, исключает соответствие стандарту CSS. Но соответствие стандартам HTML и WCAG полезно как для текущей работы сайта (исправляет ряд пользовательских и технических проблем).

Стандарт HTML проверяется известным образом: через сервис validator.w3.org. Стандарт WCAG — через менее известные сервисы (например, AChecker). Все эти сервисы выдают конкретный набор технических ошибок сайта, которые нужно исправлять.

Проблемы скорости сайта

Медленная работа сайта напрямую к техническим ошибкам не относится, но для качественного и эффективного сайта его быстрая работа — неотъемлемая часть. Для получения конкретного списка ошибок и их исправления (на начальном этапе) отлично подойдет сервис Google PageSpeed Insights(исправление ошибок до оценки 90, после этого ошибки перестают быть релевантными реальным проблемам скорости).

Если «тормоза» сайта связаны с сервером, то при исправлении ошибок серверной части (о них дальше) вы автоматически решите значительную часть проблем скорости на стороне сервера.

Более глубокая диагностика скорости сайта может быть выполнена с помощью сервиса Айри.рф или WebPageTest.

Ненайденные ресурсы

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

Для сбора проблем первой группы — «битых» ссылок — отлично подойдут отчеты Google Webmasters или Яндекс.Вебмастер. Конечно, желательно устранить все ошибки сайта до того, как их нашли поисковые роботы (чтобы не терять в эффективности продвижения), но если проблемы нашли, то их нужно срочно устранять. Вторая группа получается из анализа логов посещаемости сайта (access.log), для этого нужно получить логи сайта в хостинга и воспользоваться любым анализатором (например, AWStats), либо доступна из панели хостинг-провайдера или облачного сервиса. Третья группа достоверно может быть получена только ручной проверкой сайта, но также хорошо подходят программы или сервисы для сканирования сайта (например, Xenu): в этом случае будут обнаружены и некоторые проблемы из первой и второй групп.

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

  1. Работа с ошибками разработки. Часть таких ошибок может быть связано с отсутствием иконок сайта (apple-touch-icon.png, apple-touch-icon-precomposed.png, browserconfig.xml и др), для их исправления есть подробное руководство (нужно подготовить все необходимые файлы для сайта и залить на хостинг). Другая часть ошибок — с реальными «косяками» при сборке сайта (отсутствие фоновых изображений для элементов управления, отсутствие JavaScript-библиотек или файлов стилей, которые используются сторонними модулями).Нужно тщательно посмотреть, откуда вызывается «битый» ресурс — и либо положить его на хостинг в нужное место, либо удалить его вызов из требуемого файла. Также возможны ошибки с неверным автоматическим наименованием изображений или ресурсных файлов. Естественно, это все технические ошибки сайта, и все их нужно устранять.
  2. Работа с «битыми» ссылками. Если устранить ошибки, связанные с «битыми» ресурсами, то останутся ошибки, относящиеся к страницам сайта. Самые очевидные из них — проблемы, найденные поисковыми роботами или реальными пользователями при посещении сайта. Все такие «битые» ссылки (404 ошибки из панели Google, Яндекс или обнаруженные при проверке сайта или по логам) нужно просмотреть, а затем поставить каждой «битой» ссылке в соответствие правильную страницу. Для поисковиков это позволит учесть вес «битой» страницы, а для пользователей — получить правильную страницу вместо ненайденной.Далее нужно взять весь список страниц «неправильная — правильная» и сформировать правила редиректов (через .htaccess, конфигурацию nginx или инструментами системы управления сайтом).Полное руководство, как настроить редиректы, можно найти здесь.
  3. Структурные ошибки. Более редкие проблемы, — например, ошибки пагинации или разделов меню — исправляются уже за счет доработок шаблонов сайта, внутренних модулей или настроек. Сюда же можно отнести проблемы с внутренними редиректами (раздел сайта «переехал», но остались в структуре сайта ссылки на старый раздел, и используются они вместо новых ссылок) и протоколами (ресурсы вызываются по http://, но идет редирект на https:// — правильнее вызывать сразу по https).

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

Серверные проблемы

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

Ошибки размещения

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

Серверные ошибки

Более серьезными являются серверные ошибки (HTTP коды 502, 503, 504, подробнее о HTTP кодах), они напрямую влияют на качество веб-сайта и возможность его исправной работы. Код 502 говорит, чаще всего, об ошибке в веб-приложении (скрипте), 503 — о слишком большой нагрузке на хостинг (он не справляется с входящим потоком запросов), а 504 — о превышении времени обработки скриптов (может быть связана как с ошибкой в скриптах, так и большой нагрузкой на хостинг или недостаточными ресурсами вашего хостинга).

Каждая серверная ошибка — это «потерянный» пользователь. Если 404 ошибки, в большинстве случаев, не ведут к обнулению конверсии, то указанные серверные ошибки ведут. Исправление серверных ошибок находится полностью в зоне ведения вашей команды веб-разработки. Количество серверных ошибок (и детальную информацию по ним) можно узнать только из логов хостинга (error.log), в анализе и исправлении помогут специальные инструменты (и отладочная информация).

Серверные отказы

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

В первом случае необходимо проверить, чтобы запросы на стороне хостинга обрабатывались достаточно быстро (рекомендуемое время обработки запроса не более 500 мс). Во втором случае при большом количестве отказов имеет смысл задуматься о смене хостинга или применении CDN для сайта (чтобы «приблизить» сайт к посетителям).

JavaScript-ошибки

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

Как отследить JavaScript-ошибки? Существует некоторое количество интернет-сервисов по сбору JavaScript-ошибок с сайта (например, Track.js или Айри.рф), а также возможность сбора информации из браузеров прямо на сайт (в базу данных) — JSNLog. Каждый инструмент позволяет получить полный список ошибок и максимальное описание окружения для их воспроизведения. Дальше — дело за малым: передать список разработчикам сайта (или ответственным за клиентскую часть) с обязательным исправлением.

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

Автор: Мария Питерская, Айри.рф (Коммерческий директор)

Слайд 1Напоминание!
Тестирование = поиск дефектов!
Тестирование- процесс исследования ПО

с целью получения информации о качестве продукта.

Напоминание! Тестирование = поиск дефектов! Тестирование- процесс исследования ПО с целью получения


Слайд 2Что такое дефект (баг)?
Дефект (он же баг) — это

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

Что такое дефект (баг)? Дефект (он же баг) — это несоответствие фактического результата выполнения


Слайд 3«First actual case of bug being found»

«First actual case of bug being found»


Слайд 4Как определить дефект перед нами или нет?
Программа

не делает, то что она должна делать

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

Как определить дефект перед нами или нет? Программа не делает, то что


Слайд 5Оформление отчёта об ошибке
Цель составления :отчета об

ошибке является ее исправление.
Каждое хорошее описание ошибки

должно содержать роено три вещи
Какие шаги привели к ошибке;
Что Вы ожидали, увидеть;
Что Вы на самом деле увидели.
1 отчет в багтреккере на I баг
1 отчет в багтреккере на один итот жебаг, который воспроизводится браузерах/ОС.

Оформление отчёта об ошибке Цель составления :отчета об ошибке является ее исправление.


Слайд 6Основные типы дефектов ПО
функциональные ошибки

Основные типы дефектов ПО  функциональные ошибки


Слайд 7Функциональные ошибки. Примеры:
1. Не сохраняются изменения данных

в профиле
2. Не работает добавление комментария
3. Не

работает удаление товара из корзины
4. Не работает поиск

Функциональные ошибки. Примеры: 1. Не сохраняются изменения данных в профиле 2. Не


Слайд 8Основные типы дефектов ПО
функциональные ошибки
визуальные ошибки

Основные типы дефектов ПО  функциональные ошибки визуальные ошибки


Слайд 9Визуальные ошибки. Примеры:
1. Текст вылезает за границы

поля
2. Элемент управления сайтом наслаивается на нижестоящий

элемент.
3. Не отображается картинка

Визуальные ошибки. Примеры: 1. Текст вылезает за границы поля 2. Элемент управления


Слайд 10Основные типы дефектов ПО
функциональные ошибки
визуальные ошибки
логические

ошибки

Основные типы дефектов ПО  функциональные ошибки визуальные ошибки логические ошибки


Слайд 11Логические ошибки. Примеры:
1. Можно поставить дату рождения

в будущем. 31 февраля, 31 июня и

т.д.
2. Можно сделать заказ не указав адрес доставки
3. Неверная работа логики поиска

Логические ошибки. Примеры: 1. Можно поставить дату рождения в будущем. 31 февраля,


Слайд 12Основные типы дефектов ПО
функциональные ошибки
визуальные ошибки
логические

ошибки
ошибки контента

Основные типы дефектов ПО  функциональные ошибки визуальные ошибки логические ошибки ошибки контента


Слайд 13Ошибки контента. Примеры:
1. Конвертация валют идет по

некор-ректному курсу.
2. Орфографические или пунктуацион-ные ошибки.
3. Картинка

товара не соответствует карточке товара

Ошибки контента. Примеры: 1. Конвертация валют идет по некор-ректному курсу. 2. Орфографические


Слайд 14Основные типы дефектов ПО
функциональные ошибки
визуальные ошибки
логические

ошибки
ошибки контента
ошибки удобства

использования

Основные типы дефектов ПО  функциональные ошибки визуальные ошибки логические ошибки ошибки


Слайд 15Ошибки удобства использования. Примеры:
1. Отсутствие подсветки или

текста ошибки при некорректно заполненных полях формы
2.

Сброс значений заполненных полей при некорректной попытке регистрации
3. Перегруженный интерфейс (чрезмерное количество однотипных точек входа)

Ошибки удобства использования. Примеры: 1. Отсутствие подсветки или текста ошибки при некорректно


Слайд 16Основные типы дефектов ПО
функциональные ошибки
визуальные ошибки
логические

ошибки
ошибки контента
ошибки удобства

использования
ошибки безопасности

Основные типы дефектов ПО  функциональные ошибки визуальные ошибки логические ошибки ошибки


Слайд 17Ошибки безопасности. Примеры:
1. XSS-уязвимости
2. SQL-инъекции

Ошибки безопасности. Примеры: 1. XSS-уязвимости 2. SQL-инъекции


Слайд 18Зачем документируют дефекты
Чтобы не забыть
Чтобы иметь возможность

исправлять конкретные проблемы
Чтобы собирать метрики

Зачем документируют дефекты Чтобы не забыть Чтобы иметь возможность исправлять конкретные проблемы Чтобы собирать метрики


Слайд 19Ошибки безопасности. Примеры:
1. XSS-уязвимости
2. SQL-инъекции

Ошибки безопасности. Примеры: 1. XSS-уязвимости 2. SQL-инъекции


Слайд 20Простые правила оформления
Один дефект — один репорт
Говорящее

название
Понятное описание

Простые правила оформления Один дефект - один репорт Говорящее название Понятное описание


Слайд 21Оформление ошибок. Название
Локатор. Действие для проявления. Проявление.

Ожидаемый результат.
Где? Что делал? Что получилось? Что

ожидали?

Оформление ошибок. Название Локатор. Действие для проявления. Проявление. Ожидаемый результат. Где? Что


Слайд 22Оформление ошибок. Описание
1. Предусловия воспроизведения
2. Последовательность действий

для воспроизведения
3. Фактический результат
4. Ожидаемый результат

Оформление ошибок. Описание 1. Предусловия воспроизведения 2. Последовательность действий для воспроизведения 3.


Слайд 23Оформление ошибок. Доп. инфо
1. Окружение/условия воспроизведения
2. Скриншоты/видео
3.

Логи/артефакты работы ПО
4. Атрибуты ошибки (важность, компонент)

Оформление ошибок. Доп. инфо 1. Окружение/условия воспроизведения 2. Скриншоты/видео 3. Логи/артефакты работы


Слайд 24Атрибуты бага: (Summary)
Принцип описания сути(Summary)

бага:

Что?
Где?
Когда?, (При каких условиях?)

Атрибуты бага: (Summary)   Принцип описания сути(Summary) бага:  Что? Где?


Слайд 25Практика формулирования Summary бага.
Сформулируйте баг на скриншоте

используя принцип: Что, где, когда?

Практика формулирования Summary бага. Сформулируйте баг на скриншоте используя принцип: Что, где, когда?


Слайд 26Практика формулирования Summary бага.
Ответ:
Что: Отсутствует выпадающее меню
Где:

в пункте Actionc
Когда: при не выбранном

документе.

Практика формулирования Summary бага. Ответ: Что: Отсутствует выпадающее меню Где: в пункте


Слайд 27Серьёзность и Приоритет багов.
СЕРЬЁЗНОСТЬ
S1 Блокирующий (Blocker)

S2 Критический

(Critical)

S3 Значительный (Major)

S4 Незначительный (Minor)

S5 Тривиальный (Trivial)

ПРИОРИТЕТ
P1

Высокий (High)

P2 Средний (Medium)

P3 Низкий (Low)

Серьёзность и Приоритет багов. СЕРЬЁЗНОСТЬ S1 Блокирующий (Blocker)  S2 Критический (Critical)


Слайд 31Жизненный цикл дефекта.
Варианты прохождения багов:

1. (новый)new (отклоненный)rejected

(закрытый)closed
2. new (отложенный)deferred
3. new (принятый)Accepted (открытый)open (исправленный)fixed (закрытый)closed
4. new accepted pen fixed closed (открыт снова)reopend

Жизненный цикл дефекта.  Варианты прохождения багов:   1. (новый)new


Слайд 32Дефекты — основной продукт работы тестировщиков !!!

Дефекты - основной продукт работы тестировщиков !!!


В повествовании согласованность характеристик людей, сюжета, объектов и мест, видимых читателем или зрителем во времени

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

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

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

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

Содержание

  • 1 Ошибки целостности
    • 1.1 Меры против ошибок целостности пленки
    • 1.2 Ошибки редактирования
    • 1.3 Визуальные ошибки
    • 1.4 Ошибки изображения
    • 1.5 Кивок Гомера
      • 1.5.1 Современное использование
    • 1.6 Несоответствие возраста
  • 2 Преднамеренные ошибки непрерывности
  • 3 Работа с ошибками
  • 4 Программы реального времени по сравнению с традиционными фильмами
  • 5 Нестареющие персонажи
  • 6 Ссылки
  • 7 Дополнительная литература

Ошибки непрерывности

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

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

Меры против ошибок непрерывности в фильме

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

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

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

Ошибки редактирования

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

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

Визуальные ошибки

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

Один из самых ранних примеров визуальной ошибки появляется в Чарли Чаплине 1914 год фильм Собственник. Здесь, якобы плавным переходом из одной комнаты в другую, Бродяга теряет свою шляпу в одной комнате, но она мгновенно возвращается ему на голову, когда он входит в следующую комнату. Достаточно «рыхлые» сюжеты и отсутствие снятых в большинстве ранних фильмов таких ошибок изобилуют.

Другой пример встречается в фильме 1998 Пробуждение Неда, когда двое героев фильма, Джеки и Майкл, идут сквозь шторм к дому Неда. Зонтик, под которым они находятся, черный во время их разговора, когда они идут к дому (снято немного сверху и спереди), но после перехода к кадру снизу (снято сзади Джеки) Майкл идет по экрану справа, держа зонт не черный, а бежевый, с коричневой полосой по краю.

Еще один яркий пример плохой преемственности — это фильм Диснея Дракон Пита (снят в 1976 году). Во время песни «Brazzle Dazzle Day», когда Лэмпи (Микки Руни), Пит (Шон Маршалл) и Нора (Хелен Редди) поднимаются по лестнице на вершину маяка, рубашка Пита под комбинезоном оранжевого цвета. Но после того, как он снова спустился на дно и вылез из двери маяка, его рубашка теперь серая.

Хотя ошибки визуальной целостности логически ограничиваются визуальными средствами, параллельные ошибки могут возникать в тексте. В «Сказке Миллера » в Чосере в Кентерберийских рассказах дверь срывается с петель, но в следующей сцене медленно закрывается.

Ошибки сюжета

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

Гомеровский кивок

A Гомер кивает (иногда слышится как «Даже Гомер кивает ‘) является ошибкой непрерывности. Он берет свое начало в гомерическом эпосе.

. пресловутая фраза для него была придумана римским поэтом Горацием в его Ars poetica :

… et idem. возмущаться quandoque Bonus dormitat Homerus

… и все же меня раздражает всякий раз, когда великий Гомер кивает прочь.

В Гомере есть множество ошибок преемственности, которые напоминают «кивки», например:

  • В Илиаде, Менелай убивает второстепенного персонажа, Пиламена, в бою; который позже еще жив, чтобы засвидетельствовать смерть своего сына.
  • В Илиаде 9.165-93 три персонажа: Финикс, Одиссей и Айас отправился в посольство к Ахиллею ; однако в строке 182 поэт использует глагол в двойной форме , чтобы указать, что идут только два человека; в строках 185 и далее. используются глаголы в форме множественного числа, обозначающие более двух; но еще один двойной глагол появляется в строке 192 («двое из них выступили вперед»).

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

Александр Поуп был склонен кивать Гомеру в пользу сомнения:

Часто это стратагемы, которые кажутся ошибками,. И не Гомер кивает, а Мы, которые мечтаем. — Очерк критики

Современное употребление

В своей онлайн-колонке Best of The Web Today Джеймс Таранто из The Wall Street Journal часто использовал фраза «Гомер кивает» как заголовок опровержения или исправления.

Несоответствия в возрасте

Практика увеличения возраста телевизионного персонажа (обычно ребенка или подростка), противоречащего временной шкале сериала и / или реальному течению времени, является широко известный как синдром быстрого старения мыльной оперы или SORAS. Дети, невидимые на экране какое-то время, могут снова появиться в роли актера, который на несколько лет старше оригинала. Обычно это быстрое старение, совпадающее с переделкой, обычно делается для того, чтобы открыть персонажу более широкий спектр сюжетных линий и привлечь более молодых зрителей. Недавний пример этого — в сериале BBC Мерлин, в котором Мордреда сначала играет маленький ребенок в 4-м сезоне, но он внезапно вырастает до позднего подросткового возраста к началу 5-го сезона. а остальные персонажи стареют всего на три года.

Может случиться и обратное. На Lost (сериал) 10-летний Уолт Ллойд сыграл 12-летнего Малкольма Дэвида Келли. Первые несколько сезонов длились всего несколько месяцев, но к этому моменту Ллойд выглядел намного старше 10. В оставшихся нескольких выступлениях использовались специальные эффекты, чтобы он выглядел моложе, или сцена происходила годами позже.

Преднамеренные ошибки непрерывности

Иногда в художественном произведении могут намеренно использоваться ошибки непрерывности, обычно в комедии. Например, в классическом фильме братьев Маркс Утиный суп, в кульминации фильма камера показывает кадр из Граучо Маркс произнесение реплики, за которой следует кадр того, что происходит что-то еще, а затем еще один кадр Граучо. Каждый раз шляпа Граучо меняется, обычно на что-то более возмутительное, чем раньше (наполеоновская шляпа, прусская и т. Д.).

Работа с ошибками

Когда были допущены ошибки непрерывности, писатели или фанаты часто предлагают объяснения, чтобы сгладить несоответствия. Поклонники иногда придумывают объяснения таких ошибок, которые могут или не могут быть интегрированы в canon ; в просторечии это стало известно как фан-ванкинг (термин, первоначально введенный автором Крейгом Хинтоном для описания чрезмерного использования непрерывности). Часто, когда фанаты не согласны с одним из событий в истории (например, смертью любимого персонажа), они предпочитают игнорировать данное событие, чтобы не уменьшать их удовольствие от франшизы. Когда владелец интеллектуальной собственности отказывается от всей существующей непрерывности и начинает с нуля, это называется перезагрузкой. Фанаты называют менее экстремальный литературный прием, стирающий одну серию, кнопкой сброса. См. Также fanon.

Расхождения в прошлой преемственности иногда делаются преднамеренно; это известно как ретконнинг. Ретконы также иногда используются для исправления или сокрытия предполагаемой ошибки. Не следует путать с продолжением реальности (непрерывностью).

Программы в реальном времени по сравнению с традиционными фильмами

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

Нестареющие персонажи

Некоторые художественные произведения игнорируют непрерывность, чтобы позволить персонажам замедлить или остановить процесс старения, несмотря на такие маркеры реального мира, как серьезные социальные или технологические изменения. В комиксах это иногда называют «плавающей временной шкалой», где художественная литература происходит в «непрерывном настоящем». Роз Кавени предполагает, что комиксы используют эту технику для удовлетворения «коммерческой потребности в поддержании жизни определенных персонажей. навсегда ». Это также связано с тем, что авторам не нужно учитывать старение персонажей, что также характерно для большинства анимационных телешоу. Кевин Ваннер сравнивает использование скользящей шкалы времени в комиксах с тем, как нестареющие фигуры в мифах изображаются взаимодействующими с современным миром рассказчика. Когда определенные истории в комиксах, особенно истории происхождения, переписываются, они часто сохраняют ключевые события, но обновляются до современного времени, например, с персонажем комиксов Тони Старком, который изобретает свою броню Железного человека в броне. разные войны в зависимости от того, когда рассказывается история. Другие примеры художественной литературы, в которой персонажи не стареют, включают Симпсоны, серию Дживса, романы Ниро Вулфа и первую серию Арчи комиксы.

Ссылки

Дополнительная литература

  • Miller, Pat (декабрь 1998 г.). Сценарий надзора и непрерывность фильма, третье издание. Фокусное нажатие. ISBN 0-240-80294-2 .
  • Гиллан, Одри (2008-11-10). «Астон Мартини, взбалтывать, не встряхивать, пожалуйста, Пеннимони / Сайт перечисляет оплошности 007 в новом фильме о Бонде / Odd Corsas, трупы и заглавные буквы, замеченные в фильме». Хранитель. Проверено 21 декабря 2008 г.
  • Стамберг, Сьюзан (21 февраля 2008 г.). «Когда важна преемственность, позови сценариста — эээ, парень» . Национальное общественное радио. Проверено 21 декабря 2008 г.
  • Miller, Susan W. (2005-08-05). «Карьерный консультант: руководитель сценария». Лос-Анджелес Таймс. Архивировано из оригинального 3 февраля 2009 г. Получено 21 декабря 2008 г.

Понравилась статья? Поделить с друзьями:

Не пропустите эти материалы по теме:

  • Яндекс еда ошибка привязки карты
  • Визуализация матрицы ошибок
  • Визуал студио не показывает ошибки
  • Виды ошибок русский язык шпаргалка для учителя
  • Виды ошибок росреестра

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии