Как устранить слепые зоны с помощью визуального тестирования
Время на прочтение
4 мин
Количество просмотров 2.2K
Перевод статьи подготовлен в преддверии старта курса «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.
Как устранить слепые зоны с помощью визуального тестирования
Время на прочтение
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. Понятное сообщение
- Ошибки приложений
- Используйте изображения и юмор
- Как устранить слепые зоны с помощью визуального тестирования
- Что такое визуальное тестирование?
- Надо ли начинать все сначала?
- Что делать, если я не хочу делать снимок всего экрана?
- Игнорирование областей
- Рамки для области
- Будьте внимательны с границами
- Что насчет динамических данных, которые разнятся от теста к тесту?
- Неужели визуальное тестирование применимо только в веб-приложениях?
- Как начать работать с визуальным тестированием
Мобильный дизайн: сообщения об ошибках — Часть 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. Страница не найдена.» Однако когда пользователь теряет значительное количество времени в результате сбоя, говорить «Опаньки!» совершенно неуместно.
«Опаньки! Возникла ошибка, и мы не смогли опубликовать эту историю»
Итак, чтобы создать идеальную страницу ошибки, стоит учесть следующее:
- Сообщения об ошибках должны появляться, как только возникает проблема.
- Необходимо сохранять введенную пользователем информацию на случай возникновения ошибки.
- Сообщение должно быть написано простым языком, содержать причину ошибки и рекомендации дальнейших действий пользователя.
- Не пугайте и не сбивайте с толку пользователей своим сообщением.
- Не забирайте у пользователя контроль над системой в случае возникновения не столь серьезной проблемы.
- Внесите немного юмора, чтобы смягчить проблему.
Источник
Как устранить слепые зоны с помощью визуального тестирования
Перевод статьи подготовлен в преддверии старта курса «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): в этом случае будут обнаружены и некоторые проблемы из первой и второй групп.
Работа с ненайденными ресурсами для каждого сайта индивидуальна, но ее тоже можно разбить на несколько больших групп:
- Работа с ошибками разработки. Часть таких ошибок может быть связано с отсутствием иконок сайта (apple-touch-icon.png, apple-touch-icon-precomposed.png, browserconfig.xml и др), для их исправления есть подробное руководство (нужно подготовить все необходимые файлы для сайта и залить на хостинг). Другая часть ошибок — с реальными «косяками» при сборке сайта (отсутствие фоновых изображений для элементов управления, отсутствие JavaScript-библиотек или файлов стилей, которые используются сторонними модулями).Нужно тщательно посмотреть, откуда вызывается «битый» ресурс — и либо положить его на хостинг в нужное место, либо удалить его вызов из требуемого файла. Также возможны ошибки с неверным автоматическим наименованием изображений или ресурсных файлов. Естественно, это все технические ошибки сайта, и все их нужно устранять.
- Работа с «битыми» ссылками. Если устранить ошибки, связанные с «битыми» ресурсами, то останутся ошибки, относящиеся к страницам сайта. Самые очевидные из них — проблемы, найденные поисковыми роботами или реальными пользователями при посещении сайта. Все такие «битые» ссылки (404 ошибки из панели Google, Яндекс или обнаруженные при проверке сайта или по логам) нужно просмотреть, а затем поставить каждой «битой» ссылке в соответствие правильную страницу. Для поисковиков это позволит учесть вес «битой» страницы, а для пользователей — получить правильную страницу вместо ненайденной.Далее нужно взять весь список страниц «неправильная — правильная» и сформировать правила редиректов (через .htaccess, конфигурацию nginx или инструментами системы управления сайтом).Полное руководство, как настроить редиректы, можно найти здесь.
- Структурные ошибки. Более редкие проблемы, — например, ошибки пагинации или разделов меню — исправляются уже за счет доработок шаблонов сайта, внутренних модулей или настроек. Сюда же можно отнести проблемы с внутренними редиректами (раздел сайта «переехал», но остались в структуре сайта ссылки на старый раздел, и используются они вместо новых ссылок) и протоколами (ресурсы вызываются по
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»
Слайд 4Как определить дефект перед нами или нет?
Программа
не делает, то что она должна делать
согласно ТЗ.
Программа делает что-то, чего она не должна делать согласно ТЗ.
Программа делает что-то, о чём в требованиях не упоминалось.
Программа не делает чего-то, о чём не говорится в требованиях , однако подразумевается, что она должна это делать.
Программа трудна для понимания и неудобна в использовании.
Слайд 5Оформление отчёта об ошибке
Цель составления :отчета об
ошибке является ее исправление.
Каждое хорошее описание ошибки
должно содержать роено три вещи
Какие шаги привели к ошибке;
Что Вы ожидали, увидеть;
Что Вы на самом деле увидели.
1 отчет в багтреккере на I баг
1 отчет в багтреккере на один итот жебаг, который воспроизводится браузерах/ОС.
Слайд 6Основные типы дефектов ПО
функциональные ошибки
Слайд 7Функциональные ошибки. Примеры:
1. Не сохраняются изменения данных
в профиле
2. Не работает добавление комментария
3. Не
работает удаление товара из корзины
4. Не работает поиск
Слайд 8Основные типы дефектов ПО
функциональные ошибки
визуальные ошибки
Слайд 9Визуальные ошибки. Примеры:
1. Текст вылезает за границы
поля
2. Элемент управления сайтом наслаивается на нижестоящий
элемент.
3. Не отображается картинка
Слайд 10Основные типы дефектов ПО
функциональные ошибки
визуальные ошибки
логические
ошибки
Слайд 11Логические ошибки. Примеры:
1. Можно поставить дату рождения
в будущем. 31 февраля, 31 июня и
т.д.
2. Можно сделать заказ не указав адрес доставки
3. Неверная работа логики поиска
Слайд 12Основные типы дефектов ПО
функциональные ошибки
визуальные ошибки
логические
ошибки
ошибки контента
Слайд 13Ошибки контента. Примеры:
1. Конвертация валют идет по
некор-ректному курсу.
2. Орфографические или пунктуацион-ные ошибки.
3. Картинка
товара не соответствует карточке товара
Слайд 14Основные типы дефектов ПО
функциональные ошибки
визуальные ошибки
логические
ошибки
ошибки контента
ошибки удобства
использования
Слайд 15Ошибки удобства использования. Примеры:
1. Отсутствие подсветки или
текста ошибки при некорректно заполненных полях формы
2.
Сброс значений заполненных полей при некорректной попытке регистрации
3. Перегруженный интерфейс (чрезмерное количество однотипных точек входа)
Слайд 16Основные типы дефектов ПО
функциональные ошибки
визуальные ошибки
логические
ошибки
ошибки контента
ошибки удобства
использования
ошибки безопасности
Слайд 17Ошибки безопасности. Примеры:
1. XSS-уязвимости
2. SQL-инъекции
Слайд 18Зачем документируют дефекты
Чтобы не забыть
Чтобы иметь возможность
исправлять конкретные проблемы
Чтобы собирать метрики
Слайд 19Ошибки безопасности. Примеры:
1. XSS-уязвимости
2. SQL-инъекции
Слайд 20Простые правила оформления
Один дефект — один репорт
Говорящее
название
Понятное описание
Слайд 21Оформление ошибок. Название
Локатор. Действие для проявления. Проявление.
Ожидаемый результат.
Где? Что делал? Что получилось? Что
ожидали?
Слайд 22Оформление ошибок. Описание
1. Предусловия воспроизведения
2. Последовательность действий
для воспроизведения
3. Фактический результат
4. Ожидаемый результат
Слайд 23Оформление ошибок. Доп. инфо
1. Окружение/условия воспроизведения
2. Скриншоты/видео
3.
Логи/артефакты работы ПО
4. Атрибуты ошибки (важность, компонент)
Слайд 24Атрибуты бага: (Summary)
Принцип описания сути(Summary)
бага:
Что?
Где?
Когда?, (При каких условиях?)
Слайд 25Практика формулирования Summary бага.
Сформулируйте баг на скриншоте
используя принцип: Что, где, когда?
Слайд 26Практика формулирования Summary бага.
Ответ:
Что: Отсутствует выпадающее меню
Где:
в пункте Actionc
Когда: при не выбранном
документе.
Слайд 27Серьёзность и Приоритет багов.
СЕРЬЁЗНОСТЬ
S1 Блокирующий (Blocker)
S2 Критический
(Critical)
S3 Значительный (Major)
S4 Незначительный (Minor)
S5 Тривиальный (Trivial)
ПРИОРИТЕТ
P1
Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)
Слайд 31Жизненный цикл дефекта.
Варианты прохождения багов:
1. (новый)new (отклоненный)rejected
(закрытый)closed
2. new (отложенный)deferred
3. new (принятый)Accepted (открытый)open (исправленный)fixed (закрытый)closed
4. new accepted pen fixed closed (открыт снова)reopend
Слайд 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 г.
1. Напоминание!
Тестирование
= поиск дефектов!
Тестирование-
процесс
исследования ПО с целью
получения информации о качестве
продукта.
2. Что такое дефект (баг)?
Дефект
(он же баг) — это несоответствие
фактического результата выполнения
программы ожидаемому результату.
3. «First actual case of bug being found»
4. Как определить дефект перед нами или нет?
Программа
не делает, то что она должна
делать согласно ТЗ.
Программа
делает что-то, чего она не
должна делать согласно ТЗ.
Программа
делает что-то, о чём в
требованиях не упоминалось.
Программа
не делает чего-то, о чём не
говорится в требованиях , однако
подразумевается, что она должна это делать.
Программа
трудна для понимания и
неудобна в использовании.
5. Оформление отчёта об ошибке
Цель составления :отчета об ошибке является ее
исправление.
Каждое хорошее описание ошибки должно содержать
роено три вещи
1. Какие шаги привели к ошибке;
2. Что Вы ожидали, увидеть;
3. Что Вы на самом деле увидели.
.1 отчет в багтреккере на I баг
.1 отчет в багтреккере на один итот жебаг, который
воспроизводится браузерах/ОС.
6. Основные типы дефектов ПО
функциональные
ошибки
7. Функциональные ошибки. Примеры:
1.
Не сохраняются изменения данных в
профиле
2.
Не работает добавление комментария
3.
Не работает удаление товара из
корзины
4.
Не работает поиск
8. Основные типы дефектов ПО
функциональные ошибки
визуальные ошибки
9. Визуальные ошибки. Примеры:
1.
Текст вылезает за границы поля
2.
Элемент управления сайтом
наслаивается на нижестоящий элемент.
3.
Не отображается картинка
10. Основные типы дефектов ПО
функциональные
ошибки
визуальные ошибки
логические ошибки
11. Логические ошибки. Примеры:
1.
Можно поставить дату рождения в
будущем. 31 февраля, 31 июня и т.д.
2.
Можно сделать заказ не указав адрес
доставки
3.
Неверная работа логики поиска
12. Основные типы дефектов ПО
функциональные
ошибки
визуальные ошибки
логические ошибки
ошибки контента
13. Ошибки контента. Примеры:
1.
Конвертация валют идет по некорректному курсу.
2.
Орфографические или пунктуационные ошибки.
3.
Картинка товара не соответствует
карточке товара
14. Основные типы дефектов ПО
функциональные
ошибки
визуальные ошибки
логические ошибки
ошибки контента
ошибки удобства
использования
15. Ошибки удобства использования. Примеры:
1.
Отсутствие подсветки или текста
ошибки при некорректно заполненных
полях формы
2.
Сброс значений заполненных полей
при некорректной попытке регистрации
3.
Перегруженный интерфейс
(чрезмерное количество однотипных
точек входа)
16. Основные типы дефектов ПО
функциональные
ошибки
визуальные ошибки
логические ошибки
ошибки контента
ошибки удобства
использования
ошибки безопасности
17. Ошибки безопасности. Примеры:
1.
XSS-уязвимости
2. SQL-инъекции
18. Зачем документируют дефекты
Чтобы
Чтобы
не забыть
иметь возможность
исправлять конкретные проблемы
Чтобы собирать метрики
19. Ошибки безопасности. Примеры:
1.
XSS-уязвимости
2. SQL-инъекции
20. Простые правила оформления
Один дефект — один репорт
Говорящее название
Понятное описание
21. Оформление ошибок. Название
Локатор. Действие для проявления.
Проявление. Ожидаемый результат.
Где? Что делал? Что получилось? Что
ожидали?
22. Оформление ошибок. Описание
1. Предусловия воспроизведения
2. Последовательность действий для
воспроизведения
3. Фактический результат
4. Ожидаемый результат
23. Оформление ошибок. Доп. инфо
1. Окружение/условия воспроизведения
2. Скриншоты/видео
3. Логи/артефакты работы ПО
4. Атрибуты ошибки (важность, компонент)
24. Атрибуты бага: (Summary)
Принцип описания
сути(Summary) бага:
Что?
Где?
Когда?, (При каких условиях?)
25. Практика формулирования Summary бага.
Сформулируйте
баг на скриншоте
используя принцип: Что, где, когда?
26. Практика формулирования Summary бага.
Ответ:
Что:
Отсутствует выпадающее меню
Где:
в пункте Actionc
Когда:
при не выбранном документе.
27. Серьёзность и Приоритет багов.
СЕРЬЁЗНОСТЬ
ПРИОРИТЕТ
S1 Блокирующий (Blocker)
S2 Критический (Critical)
S3 Значительный (Major)
P1 Высокий (High)
S4 Незначительный (Minor)
P2 Средний (Medium)
S5 Тривиальный (Trivial)
P3 Низкий (Low)
28. Жизненный цикл дефекта.
29. Жизненный цикл дефекта.
30. Состояние дефектов
31. Жизненный цикл дефекта.
Варианты прохождения багов:
1. (новый)new
(отклоненный)rejected
(закрытый)closed
2. new
(отложенный)deferred
3. new
(принятый)Accepted
(открытый)open
(исправленный)fixed
(закрытый)closed
4. new
pen
accepted
(открыт снова)reopend
fixed
closed
32. Дефекты — основной продукт работы тестировщиков !!!
Целью визуализации данных является облегчение восприятия массивов информации и выявления закономерностей, которые сложно заметить в текстовой таблице. Перед публикацией визуализаций аналитикам следует проверять результаты своей работы на наличие элементов, которые могут сбить с толку конечного пользователя. В данной статье мы рассмотрим основные принципы восприятия визуальной информации пользователями и наиболее частые ошибки визуализации, которые могут вводить пользователей в заблуждение и которых следует избегать. В качестве основы взят материал на elearning.tableau.com Informing Without Misleading, а также мой собственный опыт.
Атрибуты, помогающие пользователям увидеть разницу
Для восприятия визуальной информации и обнаружения закономерностей мозг использует преаттентивные атрибуты (приведены на рисунке ниже), которые помогают определить разницу без особых усилий и внимания. К таким атрибутам относятся длина, ширина, ориентация, размер, форма, выделение, позиция относительно других, группировка (расстояние между соседями и другими объектами), цветовой тон, интенсивность цвета и другие. Визуализация предполагает кодирование значений численных и дискретных полей каким-либо способом на основании преаттентивных атрибутов: текстом, символами, цветом, типом маркировки, размером, длиной, шириной и т.д.
From Wikipedia, the free encyclopedia
This article is about consistency throughout a single work of fiction. For a broader franchise of related works, see Fictional universe. For continuity as applied to a fictional universe, see Canon (fiction).
In fiction, continuity is the consistency of the characteristics of people, plot, objects, and places seen by the audience over some period of time. It is relevant to many genres and forms of storytelling, especially if it is long-running.
Continuity is particularly a concern in the process of film and television production due to the difficulty of rectifying errors after filming ends. Continuity can also apply to other art forms, such as novels, comics, and video games, though usually on a smaller scale; it also applies to fiction used by persons, corporations, and governments in the public eye.
Most film and TV productions have a script supervisor on hand whose job is to pay attention to and attempt to maintain continuity across the chaotic and typically non-linear production schedule. It is an inconspicuous job because if done well, none may ever notice. The script supervisor gathers numerous paperwork, photographs, and other documentation which note a large quantity of detail for maintaining the continuity of the production; Some of the gathered documents can be sometimes assembled into the story bible. The gathered information and photographs usually regard factors both within the scene and the technical details of the production, including meticulous records of camera positioning and equipment settings. Film-based Polaroid cameras were once standard but have since been replaced by digital cameras; all of this is, ideally, all related shots can match, due to filming being split up over months in different sets and locations.
In comic books, continuity has also come to mean a set of contiguous events, sometimes said to be «set in the same universe.»
Continuity errors[edit]
Many continuity errors are subtle, such as minor changes between shots (like the level of drink in a glass or the length of a cigarette); these minor errors often remain due to relative indifference to the final cut. While minor errors are often unnoticed by the average viewer, other errors may be more noticeable, such as sudden drastic changes in the appearance of a character. Productions will aim to prevent such errors in continuity because they can affect the audience’s suspension of disbelief.
In cinema, special attention must be paid to continuity because scenes are rarely shot in the order in which they appear in the final film. The shooting schedule is often dictated by location permit issues and other logistics. For example, a character may return to Times Square in New York City several times throughout a movie, but as it is extraordinarily expensive to close off Times Square, those scenes will likely be filmed all at once to reduce permit costs. Weather, the ambiance of natural light, cast and crew availability, or any number of other circumstances can also influence a shooting schedule.
Measures against continuity errors in the film[edit]
Film production companies use various techniques to prevent continuity errors. The first would be to film all the shots for a particular scene together and all shots of consecutive scenes together (if the scenes take place together, with no break between them in the film’s timeline). This allows actors to remain in costume, in character, and in the same location (and with the same weather, if shooting on location).
The second major technique is for costume designers, production designers, prop masters, and make-up artists to take instant photographs of actors and sets at the beginning and end of each day’s shooting (once made possible by Polaroid cameras, now done with digital cameras and cell phones as well). This allows the various workers to check each day’s clothing, set, props, and make-up against a previous day’s.
The third is to avoid shooting on location entirely but instead film everything on a studio set. This allows weather and lighting to be controlled (as the shooting is indoors), and for all clothing and sets to be stored in one place to be hauled out the next day from a secure location.
Editing errors[edit]
Editing errors can occur when a character in a scene references a scene or incident that has not occurred yet, or of which they should not yet be aware.[citation needed]
An example of an editing error can be seen in the film It’s a Mad, Mad, Mad, Mad World (1963), where a scene of people climbing a slope at the start is seen from below and then replayed from above.
Visual errors[edit]
Visual errors are instant discontinuities occurring in visual media such as film and television. Items of clothing change colors, shadows get longer or shorter, items within a scene change place or disappear, etc.
One of the earliest examples of a visual error appears in Charlie Chaplin’s 1914 movie The Property Man.[1] Here, in a supposedly smooth step from one room to another, the Tramp loses his hat in one room, but it is instantly back on his head as he enters the next room. Rather «loose» plots and a lack of continuity editing made most early films rife with such errors.
Another example occurs in the 1998 film Waking Ned, when two of the film’s characters, Jackie and Michael, are walking through a storm towards Ned’s house. The umbrella they are under is black during their conversation as they walk towards the house (filmed from slightly above and to the front). However, after cutting to a lower shot (filmed from behind Jackie), Michael walks onscreen from the right holding an umbrella that is not black but beige, with a brown band at the rim.
Another glaring example of poor continuity occurs in the Disney film Pete’s Dragon (filmed in 1976). During the song «Brazzle Dazzle Day» when Lampie (Mickey Rooney), Pete (Sean Marshall), and Nora (Helen Reddy) climb the stairs to the top of the lighthouse, Pete’s shirt beneath his overalls is orange. But after descending to the bottom again and coming out of the lighthouse door, his shirt is now grey.
Plot errors[edit]
A plot error, or a plot hole as it is commonly known, reflects a failure in the consistency of the created fictional world. A character might state he was an only child, yet later mention a sibling. In the TV show Cheers, Frasier Crane’s wife Lilith mentions Frasier’s parents are both dead, and, in another episode, Frasier himself claims his father to have been a scientist. When the character was spun off into Frasier, his father, a retired policeman named Martin, became a central character. Eventually, in an episode featuring Cheers star Ted Danson, the inconsistency was given the retroactive explanation that Frasier was embarrassed about his father’s lowbrow attitudes and thus claimed his death. This is a frequent occurrence in sitcoms, where networks may agree to continue a show, but only if a certain character is emphasized, leading other minor characters to be written out of the show with no further mention of the character’s existence, while the emphasized character (usually a breakout character, as in the case of Frasier Crane) develops a more complete back story that ignores previous, more simplified backstories.
Homeric nod[edit]
Look up Homer nods in Wiktionary, the free dictionary.
A Homeric nod (sometimes heard as ‘Even Homer nods’) is a term for a continuity error that has its origins in Homeric epic. The proverbial phrase for it was coined by the Roman poet Horace in his Ars Poetica:[2] «et idem indignor quandoque bonus dormitat Homerus» («and yet I also become annoyed whenever the great Homer nods off»).
There are numerous continuity errors in Homer that can be described as «nods», as for example:
- In Iliad,[3] Menelaos kills a minor character, Pylaimenes, in combat. Pylaimenes is later[4] still alive to witness the death of his son.
- In Iliad 9.165-93 three characters, Phoinix, Odysseus, and Aias set out on an embassy to Achilleus; however, at line 182 the poet uses a verb in the dual form to indicate that there are only two people going; at lines 185ff. verbs in the plural form are used, indicating more than two; but another dual verb appears at line 192 («the two of them came forward»).
In modern Homeric scholarship, many of Homer’s «nods» are explicable as the consequences of the poem being retold and improvised by generations of oral poets. In the second case cited above, it is likely that two different versions are being conflated: one version with an embassy of three people, another with just two people.
Alexander Pope was inclined to give Homeric nods the benefit of the doubt, saying in his Essay on Criticism that «Those oft are Stratagems which Errors seem, Nor is it Homer Nods, but We that Dream.»
Aging discrepancies[edit]
The practice of accelerating the age of a television character (usually a child or teenager) in conflict with the timeline of a series and/or the real-world progression of time is popularly known as Soap Opera Rapid Aging Syndrome, or SORAS.[5] Children unseen on screen for a time might reappear portrayed by an actor several years older than the original.[6] Usually coinciding with a recast, this rapid aging is typically done to open up the character to a wider range of storylines, and to attract younger viewers.[5] A recent example of this occurring is in the BBC’s Merlin series, in which Mordred is initially played by a young child in Season 4, yet suddenly grows up into his late teens in time for the start of Season 5, with the rest of the characters aging by only three years.
The reverse can also happen. On the television program Lost, the character of 10-year-old Walt Lloyd was played by 12-year-old actor Malcolm David Kelley. The first few seasons took place over the course of just a few months, but by that point, Lloyd looked much older than 10. In his remaining few appearances, special effects were used to make him look younger, or the scene took place years later.
Deliberate continuity errors[edit]
Sometimes a work of fiction may deliberately employ continuity errors, usually for comedy. For example, in the Marx Brothers’ classic film Duck Soup, at the climax of the film, the camera shows a shot of Groucho Marx speaking a line, followed by a cutaway shot of something else happening, followed by another shot of Groucho. Each time, Groucho’s hat changes, usually to something more outrageous than before (a Napoleonic hat, a Prussian hat, etc.).
Dealing with errors[edit]
When continuity mistakes have been made, explanations are often proposed by either writers or fans to smooth over discrepancies. Fans sometimes make up explanations for such errors that may or may not be integrated into canon; this has come to be colloquially known as fanwanking (a term originally coined by the author Craig Hinton to describe excessive use of continuity).[7] Often when fans do not agree with one of the events in a story (such as the death of a favorite character), they will choose to ignore the event in question so that their enjoyment of the franchise is not diminished. When the holder of the intellectual property discards all existing continuity and starts from scratch, it is known as rebooting. Fans call a less extreme literary technique that erases one episode the reset button. See also fanon.
A conflict with previously-established facts is sometimes deliberate; this is a retcon, as it is a retroactive change in continuity. Retcons sometimes clarify ambiguities or correct perceived errors. This is not to be confused with the continuance of a reality (continuality).
Real-time programs vs. traditional films[edit]
Television programs like 24, in which actors have to appear as if it is the same day for 24 consecutive episodes, have raised public recognition of continuity. However, traditional films have frequently had much of the same sort of issues to deal with; film shoots may last several months, and as scenes are frequently shot out of story sequence, footage shot weeks apart may be edited together as part of the same day’s action in the completed film. In some ways, 24 presents a simpler situation, as costumes and hairstyles generally should not change very frequently; in many feature films, a range of different hairstyles and costumes must be created, changed, and then recreated exactly, as various scenes are shot.
Ageless characters[edit]
Some fiction ignores continuity to allow characters to slow or stop the aging process, despite real-world markers like major social or technological changes. In comics this is sometimes referred to as a «floating timeline», where the fiction takes place in a «continuous present».[8] Roz Kaveney suggests that comic books use this technique to satisfy «the commercial need to keep certain characters going forever».[9] This is also due to the fact that the authors have no need to accommodate the aging of their characters, which is also typical of most animated television shows.[10] Kevin Wanner compares the use of a sliding timescale in comics to the way ageless figures in myths are depicted interacting with the contemporary world of the storyteller.[11] When certain stories in comics, especially origin stories, are rewritten, they often retain key events but are updated to a contemporary time, such as with the comic book character Tony Stark, who invents his Iron Man armor in a different war depending on when the story is told.[12]
References[edit]
- ^ «Charlie Chaplin : Films».
- ^ Lines 358-359.
- ^ Book V Lines 576-579
- ^ Book XIII Lines 643-659
- ^ a b Clayton-Millar, Kim (April 24, 2006). «Soaps’ rising stars». Tonight. Independent News & Media. Retrieved December 17, 2009.
- ^ Bird, S. Elizabeth (2003). The Audience in Everyday Life: Living in a Media World. New York: Routledge. p. 135. ISBN 0-415-94259-4. Retrieved December 12, 2009.
- ^ Parkin, Lance (2007). AHistory: An Unauthorized History of the Doctor Who universe (2nd ed.). Des Moines, Iowa: Mad Norwegian Press. p. 13. ISBN 978-0-9759446-6-0.
- ^ Jeffery, Scott (2016), Jeffery, Scott (ed.), «The Rhizome of Comic Book Culture», The Posthuman Body in Superhero Comics: Human, Superhuman, Transhuman, Post/Human, Palgrave Studies in Comics and Graphic Novels, New York: Palgrave Macmillan US, pp. 37–67, doi:10.1057/978-1-137-54950-1_3, ISBN 978-1-137-54950-1
- ^ Kaveney, Roz (2008). Superheroes!: Capes and Crusaders in Comics and Films. Bloomsbury Academic. p. 22. ISBN 9781845115692.
- ^ Goertz, Allie; Prescott, Julia; Oakley, Bill; Weinstein, Josh (2018-09-18). 100 Things The Simpsons Fans Should Know & Do Before They Die (in Arabic). Triumph Books. ISBN 978-1-64125-109-9.
- ^ Wanner, Kevin J. (2018). «Authority Apart from Truth: Superhero Comic Book Stories as Myths». In Urban, Hugh; Johnson, Greg (eds.). Irreverence and the Sacred: Critical Studies in the History of Religions. Oxford University Press. p. 84.
- ^ Méon, J. M. (2018). «Sons and Grandsons of Origins: Narrative Memory in Marvel Superhero Comics». In Ahmed, Maaheen; Crucifix, Benoît (eds.). Comics Memory: Archives and Styles. Palgrave Macmillan. pp. 203–204. ISBN 978-3319917450.
Further reading[edit]
- Miller, Pat (December 1998). Script Supervising and Film Continuity, Third Edition. Focal Press. ISBN 0-240-80294-2.
- Gillan, Audrey (2008-11-10). «An Aston Martini, stirred not shaken, please Pennymoney / Site lists 007 continuity gaffes in new Bond film / Odd Corsas, corpses and capitals spotted in movie». The Guardian. Retrieved 2008-12-21.
- Stamberg, Susan (2008-02-21). «When Continuity Counts, Call a Script Girl — Er, Guy». National Public Radio. Retrieved 2008-12-21.
- Miller, Susan W. (2005-08-05). «Career Counselor: Script Supervisor». Los Angeles Times. Archived from the original on February 3, 2009. Retrieved 2008-12-21.