Баги и ошибки на сайте - ErrorsMaster.ru - большая энциклопедия ошибок и их решений

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

1. Средства языка JavaScript

Блоки try/catch

Функции, которые могут выполниться с ошибкой, оборачивают в блоки try/catch. Сначала программа пытается выполнить код в блоке try. Если по каким-то причинам выполнение кода сломалось, программа переходит в блок catch, где доступны три параметра:

name — стандартизированное имя ошибки;
message — сообщение о деталях ошибки;
stack — текущий стек вызова, в котором произошла ошибка.

То есть:

try {
   callFunc();
} catch (e) {
   console.log(e.name) // ReferenceError
   console.log(e.message) // callFunc is not defined
   console.log(e.stack) // ReferenceError: callFunc is not defined at window.onload
}

Для разработчика главное то, что программа сможет продолжить выполнение после блока catch. Таким образом, взаимодействие с пользователем не прервется.

С помощью блока try/catch также можно вызывать собственные ошибки, например при проверке данных:

const user = {
  name : "Mike"
};
try {
   if (!user.age) throw new SyntaxError("User age ia absent!");
} catch (e) {
   console.log(e.name) // SyntaxError
   console.log(e.message) // User age ia absent!
   console.log(e.stack) // SyntaxError: User age ia absent! at window.onload
}

Наконец, можно расширить эту инструкцию еще одним блоком — finally, который выполняется всегда: и в случае, если в try не было ошибки, и в случае, если управление перешло в блок catch:

try {
   callFunc();
} catch (e) {
   console.log(e)
} finally {
   ...
}

Иногда используют инструкцию try/finally (без catch), чтобы была возможность продолжать использование кода без обработки конкретных ошибок.

Событие window.onerror

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

У глобального объекта window существует событие onerror (использовать его надо аккуратно: в разных браузерах реализация может отличаться!):

window.onerror = function(message, url, line, col, error) {
   console.log(`${message}n В ${line}:${col} на ${url}`);
};

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

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

Компоненты фреймворков

Некоторые JS-фреймворки (React, Vue) предлагают собственные решения по обработке ошибок. Например, React сможет отрисовать специальную верстку на месте блока, в котором произошла ошибка:

class ErrorBoundary extends React.Component {
   constructor(props) {
       super(props);
       this.state = { hasError: false };
   }
   static getDerivedStateFromError(error) {
       // Обновить состояние с тем, чтобы следующий рендер показал запасной UI.
       return { hasError: true };
   }
   componentDidCatch(error, errorInfo) {
       // Можно также сохранить информацию об ошибке в соответствующую службу журнала ошибок
       logErrorToMyService(error, errorInfo);
   }
   render() {
       if (this.state.hasError) {
           // Можно отрендерить запасной UI произвольного вида
           return <h1>Что-то пошло не так.</h1>;
       }
       return this.props.children;
   }
}
<ErrorBoundary>
   <MyWidget />
</ErrorBoundary>

Фактически, компонент React оборачивается специальным компонентом, который обрабатывает ошибки. Это напоминает оборачивание функций с помощью конструкции try/catch.

Рассказываем об IT-бизнесе, технологиях и цифровой трансформации

Подпишитесь в соцсетях или по email

2. Средства сборки проекта

Современные JS-скрипты, как правило, делаются транспилируемыми. То есть разработка ведется с использованием последних стандартов ES. А затем код разработчика с помощью сборщика проектов (такого как Webpack) преобразуется в код, который будет гарантированно работать в выбранном числе браузеров.

На этапе сборки код проверяется на верность синтаксиса. Незакрытая скобка или неправильное обозначение поля класса немедленно вызовут ошибку при сборке, и бандл просто не соберется. Разработчику придется сразу исправить такие ошибки, чтобы работать дальше.

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

3. Тестирование

Еще один способ не допустить ошибок в коде – тестировать его. Во фронтенде есть инструменты для эффективного использования юнит-тестов. Обычно используют фреймворки, такие как Jest, Karma, Mocha, Jasmine. Вместе с тестовыми фреймворками часто используют расширения, такие как Enzyme, React Testing Library, Sinon и другие, позволяющие обогатить тесты с помощью мокирования, функций-шпионов и других инструментов.

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

const func = (data) => {
   return JSON.parse(data)
}
func('{"a":1}')

Однако он сломается, если подать ему неверное значение:

func() // Uncaught SyntaxError: Unexpected token u in JSON at position 0.

Этот код тоже проходит валидацию при сборке:

const obj = {
   outer : {
       last : 9
   }
}
if (obj.outer.inner.last) {
   console.log("SUCCESS")
}

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

if (obj.outer?.inner?.last) {
   console.log("SUCCESS")
}

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

4. Логирование

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

Смысл простой: на каждое событие window.onerror или в каждый переход исполнения кода в блок catch выполняется простой AJAX-запрос на специально выделенный адрес сервера, в тело которого кладется информация об ошибке. Далее потребуется инструмент, который быстро оповестит техподдержку и разработчиков о наличии новых ошибок и позволит эффективно работать с ними. Самый популярный из таких инструментов для фронтенда — Sentry.

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

Подключать Sentry можно как непосредственно в HTML-файле, так и в компонентах, выполненных на одном из популярных фреймворков: React, Vue, Angular, Ember и других.

Для подключения возможностей логирования прямо в браузере в секции <head></head> загружаем скрипт:

<script
   src="https://browser.sentry-cdn.com/5.13.0/bundle.min.js"
   integrity="sha384-ePH2Cp6F+/PJbfhDWeQuXujAbpil3zowccx6grtsxOals4qYqJzCjeIa7W2UqunJ"
   crossorigin="anonymous"></script>

Далее в коде JS инициализируем:

Sentry.init({
   dsn: 'https://<your account key here>@sentry.io/<your project id here>'
});

Всё. Если и когда в коде ниже этой строчки произойдет ошибка, Sentry выполнит ее логирование. Логи будут записаны даже тогда, когда ошибка произошла по вине скриптов с других доменов:

Sentry имеет широкие возможности по анализу массива сообщений об ошибках и настройке уведомлений. Также возможна группировка логов ошибок по релизам вашего продукта:

Sentry.init({
   dsn: 'https://<your account key here>@sentry.io/<your project id here>',
   release: '2020.03.06.1'
});

С помощью Sentry в статистику можно передать контекст ошибки, например, информацию о клиенте, fingerprint, уровень ошибки (fatal, error, warning, info, debug), проставить теги.

Есть возможность записывать в статистику пользовательские события. Например, можно поставить на отслеживание изменение размеров окна браузера или совершение AJAX-запроса. Также у Sentry есть собственный виджет с окном обратной связи, которое можно показать пользователю при ошибке. Это даст дополнительную информацию для расследования обстоятельств возникновения ошибки.

Для развертывания Sentry вместе с фреймворками достаточно просто установить пакет и подключить:

# Using yarn
yarn add @sentry/browser
# Using npm
npm install @sentry/browser

Делаем инициализацию в главном скрипте проекта (для React и Angular):

import * as Sentry from "@sentry/browser";
Sentry.init({ dsn: 'https://<your account key here>@sentry.io/<your project id here>' });

Для Vue и Ember передаем еще одну обязательную строку конфигурации:

# Vue
Sentry.init({
   dsn: '<your account key here>@sentry.io/<your project id here>',
   integrations: [new Integrations.Vue({Vue, attachProps: true})],
});
# Ember
Sentry.init({
   dsn: '<your account key here>@sentry.io/<your project id here>',
   integrations: [new Integrations.Ember()]
});

Пакет integrations устанавливается отдельно:

# Using yarn
yarn add @sentry/integrations
# Using npm
npm install @sentry/integrations

Для предотвращения конфликтов и дублирования информации при подключении нескольких скриптов в одном проекте Sentry позволяет создавать отдельного клиента для каждой инициализации логирования:

import { BrowserClient } from "@sentry/browser";
const client = new BrowserClient({
   dsn: '<your account key here>@sentry.io/<your project id here>',
});
client.captureException(new Error('example'));

На сайте проекта есть подробная документация с примерами использования: https://docs.sentry.io.

Оригинал статьи на Habr.com.

Источник

Содержание

1.ПРОВЕРКА ПОЛЯ ЭЛЕКТРОННОЙ ПОЧТЫ
2.КНОПКИ ЛИБО ССЫЛКИ НЕ СРАБАТЫВАЮТ
3.КНОПКИ И ССЫЛКИ ОТКРЫВАЮТ НЕ ТУ ИНФОРМАЦИЮ
4.ПОЛЯ К ОБЯЗАТЕЛЬНОМУ ЗАПОЛНЕНИЮ
5.ИНФА НЕ ДОБАВЛЯЕТСЯ, НЕ ОБНОВЛЯЕТСЯ ИЛИ НЕ ПРИСУТСТВУЕТ ВООБЩЕ
6.ПРИ НЕВЕРНОМ ПАРОЛЕ — НЕТ ОПОВЕЩЕНИЯ ОБ ЭТОМ
7.ВЫБОРОЧНЫЙ ПОИСК
8.Ё ЗАБЫТАЯ
9.АККАУНТ ОТКАЗЫВАЕТСЯ УДАЛЯТСЯ
10.31 ЧИСЛО МЕСЯЦА
11.ПРИ НЕВЕРНЫХ ДАННЫХ — НЕТ ОПОВЕЩЕНИЯ
12.КЛАВИША ENTER
13.INTERNET EXPLORER
14.БАГ СО СТРЕЛКОЙ “НАЗАД” БРАУЗЕРА
15.СМЕЩЕНИЕ/НАЛОЖЕНИЕ ВЕРСТКИ
16.ПРОБЛЕМА С ОГРАНИЧЕНИЕ ПО КОЛИЧЕСТВУ СИМВОЛОВ
17.ГЛЮЧИТ СОРТИРОВКА ИЛИ ФИЛЬТРАЦИЯ ЧЕГО-ЛИБО
18.ПОЛОСЫ ПРОКРУТКИ И ИХ АНОМАЛИИ
19.ПРОБЛЕМЫ С ВАЛИДАЦИЕЙ ВАЖНОЙ ИНФОРМАЦИИ
20.НЕ ПОЛУЧАЕТСЯ ЗАРЕГИСТРИРОВАТЬ ВТОРОГО «НОВОГО ПОЛЬЗОВАТЕЛЯ»
21.БЕСКОНЕЧНАЯ ЗАГРУЗКА СТРАНИЦЫ И ДР.
22.СТРОКА ВВЕДЕНИЯ URL САЙТОВ
23.ИТОГОВАЯ КОНЕЧНАЯ ЦЕНА
24.ОТРИЦАТЕЛЬНЫЕ ЗНАЧЕНИЯ НА МЕСТЕ ЦЕНЫ ЛИБО КОЛ-ВА
25.КНОПКА НЕ ОТВЕЧАЕТ ФОРМЕ ЕЁ КАРТИНКИ
26.ОДНА РЕГИСТРАЦИЯ НА ОДИН EMAIL
27.НАСТРОЙКА ОДНОГО ПАРАМЕТРА СБРАСЫВАЕТ НЕСВЯЗАННЫЙ ДРУГОЙ ПАРАМЕТР
28.НЕВЕРНО ПОДОБРАННЫЕ ИЗОБРАЖЕНИЯ
29.БАГ ВО ВРЕМЯ ИЗМЕНЕНИЯ ВАЛЮТЫ
30.НЕВОЗМОЖНО СМЕНИТЬ ПАРОЛЬ
31.ОПЕЧАТКИ

-Самые распространенные баги веб-сайтов

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

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

Я же составил для тебя список наиболее часто попадающихся МНЕ ошибок.

Список привожу ниже. Надеюсь он принесет тебе немало пользы.

Для вас я сегодня предоставлю список ошибок которые чаще всего попадались именно мне. Нижележащий список наверняка вам пригодиться.

Самые распространенные баги веб-сайтов:

1. Проверка поля электронной почты

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

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

При отсутствииприсутствии чего-либо в поле email — давать визуальное оповещение или подтверждение. Не нужно об этом забывать!

2. Кнопки либо ссылки не срабатывают

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

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

3. Кнопки и ссылки открывают не ту информацию

Говоря о ссылках хотелось бы упомянуть случаи ссылки на то что не должна была направлять. Проблема тут в том что крайне просто упустить информацию о том что должно открываться по ссылке и не заметить тут ошибки вовсе. Не все внимательно читают в информацию которая описывает то что всё же должно их ждать по переходу по ссылке. Крайне важно не допускать перепутанных ссылок.

4. Поля к обязательному заполнению

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

5. Инфа не добавляется, не обновляется или не присутствует вообще

Пропажа цифр и их «застывание» с невозможностью обновить показатель не изменяясь при множественных попытках. Крайне неприятный баг с которым встречаются пользователи интернет магазинов и банкингов вовремя итогового подсчёта средств или подсчётом кол-ва набранного товара.

6. При неверном пароле — нет оповещения об этом

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

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

7. Выборочный поиск

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

8. Ё забытая

Часто забытая или целенаправленно игнорируемая буква. Часто при ограничении разрешенных символов программисты случайно включают и букву Ё в «запрещенные» списки. Не забывайте об этой букве алфавита, хоть из-за её места расположения на клавиатуре порой хочется.

9. Аккаунт отказывается удалятся

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

10. 31 число месяца

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

11. При неверных данных — нет оповещения

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

12. Клавиша enter

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

13. Internet Explorer

Печально известный браузер который кроме низкой скорости работы еще отличился кучей «жуков». Это относится в первую очередь ранним версиям и к версиям от 8 и до 11.

Браузер зачастую по стандарту ставится на Windows(не считая 10-тки с её новым браузером). Неопытные и ленивые люди использующие компьютеры не меняют его на более хорошие альтернативы. Из-за этого огромная часть трафика открывается именно им. С этим браузером имеется самое большое количество отличий во время просмотра сайта: верстка на тестируемых сайтах поломана, сжата, передвинута, скрыта и некоторые элементы не выполняют своих функций.

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

Суть в том что при введении числа начинающегося с цифры 0, то подсчет итогов может выдать случайную цифру(например вместо 012 — 147). Это не связано ни с какими формулами, вычитаниями и сложениями деления на нуль. При чём если ввести цифру 9 или 8 то поле просто станет пустым. Это довольно странная и неприятная штука исключительно уникальна для Интернет Экпловера.

14. Баг со стрелкой “назад” браузера

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

15. Смещение/наложение верстки

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

16. Проблема с ограничение по количеству символов

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

17. Глючит сортировка или фильтрация чего-либо

Функция сортировки не работает корректно, тормозит и неактивна.

Частая проблема плохих интернет-шопов

18. Полосы прокрутки и их аномалии

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

19. Проблемы с валидацией важной информации

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

20. Не получается зарегистрировать второго «нового пользователя»

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

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

21. Бесконечная загрузка страницы и др.

Если программист плохо составит цикл это приводит к зацикливанию. Из-за нехватки памяти на это поочерёдно зависает страница, браузер и ОС.

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

22. Строка введения url сайтов

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

Так не должно происходит совсем. Пользователь в идеале должен иметь возможность начинать как с 3-ёх W так и с особой приставки. Всё же заботится о о таких мелочах важно чтобы не отпугивать посетителей странными штуками которые ведут к нелегитимному вводу url.

23. Итоговая конечная цена

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

24. Отрицательные значения на месте цены либо кол-ва

Крайне запретить вводить отрицательные цифры в поля количества и цен. Иначе это приведёт ошибкам и при особенных курьезным случаям переводу денег с сайта вместо оплаты на сайте. Реальный случай на известном сайте Амазон подтверждает этот странный феномен.При вводе количества книжек со знаком минус, цены этих книг переводились на карточки покупателей.

25. Кнопка не отвечает форме её картинки

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

26. Одна регистрация на один email

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

27. Настройка одного параметра сбрасывает несвязанный другой параметр

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

28. Неверно подобранные изображения

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

29. Баг во время изменения валюты

Если в общей цене бронирования или при смене одной валюты на другую, не меняются цифры следует внимательно перепроверить валюту.

30. Невозможно сменить пароль

Очень проблематичная штука — изменение пароля. То не вышлет на почту новый пароль, то не сохраняется новый пароль а то и вообще после изменения пароля сайт может не принимать новый пароль «помня» еще прошлый.

31. Опечатки

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

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

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

Источник

Содержание

-Самые распространенные баги веб-сайтов

Я же составил для тебя список наиболее часто попадающихся МНЕ ошибок.

Список привожу ниже. Надеюсь он принесет тебе немало пользы.

Самые распространенные баги веб-сайтов:

1. Проверка поля электронной почты

2. Кнопки либо ссылки не срабатывают

3. Кнопки и ссылки открывают не ту информацию

4. Поля к обязательному заполнению

5. Инфа не добавляется, не обновляется или не присутствует вообще

6. При неверном пароле — нет оповещения об этом

7. Выборочный поиск

8. Ё забытая

9. Аккаунт отказывается удалятся

10. 31 число месяца

11. При неверных данных — нет оповещения

12. Клавиша enter

13. Internet Explorer

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

14. Баг со стрелкой “назад” браузера

15. Смещение/наложение верстки

16. Проблема с ограничение по количеству символов

17. Глючит сортировка или фильтрация чего-либо

Функция сортировки не работает корректно, тормозит и неактивна.

Частая проблема плохих интернет-шопов

18. Полосы прокрутки и их аномалии

19. Проблемы с валидацией важной информации

20. Не получается зарегистрировать второго «нового пользователя»

21. Бесконечная загрузка страницы и др.

22. Строка введения url сайтов

23. Итоговая конечная цена

24. Отрицательные значения на месте цены либо кол-ва

25. Кнопка не отвечает форме её картинки

26. Одна регистрация на один email

27. Настройка одного параметра сбрасывает несвязанный другой параметр

28. Неверно подобранные изображения

29. Баг во время изменения валюты

30. Невозможно сменить пароль

31. Опечатки

В этой статье я рассмотрю вопрос выявления и обработки ошибок, возникающих на фронтенде (браузер или web-view).

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

1. Средства языка JavaScript

Блоки try/catch

name — стандартизированное имя ошибки;
message — сообщение о деталях ошибки;
stack — текущий стек вызова, в котором произошла ошибка.

То есть:

try {

   callFunc();

} catch (e) {

   console.log(e.name) // ReferenceError

   console.log(e.message) // callFunc is not defined

   console.log(e.stack) // ReferenceError: callFunc is not defined at window.onload

}

С помощью блока try/catch также можно вызывать собственные ошибки, например при проверке данных:

const user = {

  name : «Mike»

};

try {

   if (!user.age) throw new SyntaxError(«User age is absent!»);

} catch (e) {

   console.log(e.name) // SyntaxError

   console.log(e.message) // User age is absent!

   console.log(e.stack) // SyntaxError: User age is absent! at window.onload

}

try {

   callFunc();

} catch (e) {

   console.log(e)

} finally {

   ...

}

Событие window.onerror

window.onerror = function(message, url, line, col, error) {

   console.log(`${message}n В ${line}:${col} на ${url}`);

};

Компоненты фреймворков

class ErrorBoundary extends React.Component {

   constructor(props) {

       super(props);

       this.state = { hasError: false };

   }

   static getDerivedStateFromError(error) {

       // Обновить состояние с тем, чтобы следующий рендер показал запасной UI.

       return { hasError: true };

   }

   componentDidCatch(error, errorInfo) {

       // Можно также сохранить информацию об ошибке в соответствующую службу журнала ошибок

       logErrorToMyService(error, errorInfo);

   }

   render() {

       if (this.state.hasError) {

           // Можно отрендерить запасной UI произвольного вида

           return <h1>Что-то пошло не так.</h1>;

       }

       return this.props.children;

   }

}

<ErrorBoundary>

   <MyWidget />

</ErrorBoundary>

2. Средства сборки проекта

3. Тестирование

const func = (data) => {

   return JSON.parse(data)

}

func('{«a»:1}')

Однако он сломается, если подать ему неверное значение:

func() // Uncaught SyntaxError: Unexpected token u in JSON at position 0.

Этот код тоже проходит валидацию при сборке:

const obj = {

   outer : {

       last : 9

   }

}

if (obj.outer.inner.last) {

   console.log(«SUCCESS»)

}

if (obj.outer?.inner?.last) {

   console.log(«SUCCESS»)

}

4. Логирование

Для подключения возможностей логирования прямо в браузере в секции загружаем скрипт:

<script

   src=«https://browser.sentry-cdn.com/5.13.0/bundle.min.js»

   integrity=«sha384-ePH2Cp6F+/PJbfhDWeQuXujAbpil3zowccx6grtsxOals4qYqJzCjeIa7W2UqunJ»

   crossorigin="anonymous"></script>

Далее в коде JS инициализируем:

Sentry.init({

   dsn: 'https://<your account key here>@sentry.io/<your project id here>'

});

Sentry.init({

   dsn: 'https://<your account key here>@sentry.io/<your project id here>',

   release: '2020.03.06.1'

});

Для развертывания Sentry вместе с фреймворками достаточно просто установить пакет и подключить:

# Using yarn

yarn add @sentry/browser

# Using npm

npm install @sentry/browser

Делаем инициализацию в главном скрипте проекта (для React и Angular):

import * as Sentry from «@sentry/browser»;

Sentry.init({ dsn: 'https://<your account key here>@sentry.io/<your project id here>' });

Для Vue и Ember передаем еще одну обязательную строку конфигурации:

# Vue

Sentry.init({

   dsn: '<your account key here>@sentry.io/<your project id here>',

   integrations: [new Integrations.Vue({Vue, attachProps: true})],

});

# Ember

Sentry.init({

   dsn: '<your account key here>@sentry.io/<your project id here>',

   integrations: [new Integrations.Ember()]

});

Пакет integrations устанавливается отдельно:

# Using yarn

yarn add @sentry/integrations

# Using npm

npm install @sentry/integrations

import { BrowserClient } from «@sentry/browser»;

const client = new BrowserClient({

   dsn: '<your account key here>@sentry.io/<your project id here>',

});

client.captureException(new Error('example'));

На сайте проекта есть подробная документация с примерами использования: https://docs.sentry.io.

Статья подготовлена при поддержке облачной платформы Mail.ru Cloud Solutions.

Что еще почитать по теме:

Переиспользуемые компоненты React: как перестать писать одно и то же.
Как избежать ошибок при разработке на React.
Наш телеграм-канал с новостями о цифровой трансформации.

Краткое содержание

Вы узнаете, что это такое – баг, какие баги бывают на веб-сайтах и в целом в интернет-маркетинге, и чем они чреваты. Понятным языком сделаны акценты на принципиальные вопросы – существенные для понимания владельцами веб-ресурсов. Для бизнесменов эта информация особенно полезна, поскольку к коммерческим сайтам предъявляются повышенные требования, ибо речь о деньгах. В «Конкретике» выделены наиболее актуальные вопросы по работе с багами, и традиционно предложена помощь от Digital Agency «ST». В конце, как обычно, – ссылки на дополнительные материалы.

1. «Классические» баги

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

Баг означает ошибку в программировании, приводящую к некорректной работе или вообще серьёзным сбоям программы, вплоть до её отказа. Но эти ошибки не всегда явные, а потому и называются «баги», что в переводе с английского (bug) означает насекомое, а в конкретном смысле – «жучки», т.е. скрытые дефекты.

Сам программист может не видеть такие дефекты (на то они и баги). Соответственно, большинство из них выявляется уже в процессе работы с программой. Поэтому перед выпуском программного продукта, например, в продажу, он обязательно проходит этап тестирования. Этот этап как раз и направлен на выявление багов. Затем ещё может проводиться «обкатка» программы на пользователях в так называемой бета-версии. На этом этапе – уже пользователями – выявляются дополнительные недочёты – баги. Наконец, даже после выпуска коммерческой версии программного продукта, в нём всё равно могут «вылезать» баги. Типичный пример – операционная система Windows. Помимо выхода её новых версий, к каждой версии Microsoft выпускает постоянные обновления, призванные в т.ч. устранить недочёты – «заткнуть дыры».

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

2. Баги сайта

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

2.1. Программные баги сайта

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

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

2.2. SEO-баги

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

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

К таким ошибкам относятся, например, технические внутренние дубли сайта, возникающие вследствие некорректной работы CMS (багов в ней) и недочётов в файле robots.txt; технические внешние дубли, возникающие при неправильной склейке зеркал; неграмотное оформление метатегов, прочих участков HTML-кода и т.д. Вообще SEO-ошибок может быть очень много, и рассматривать (выявлять) их следует отдельно для каждого сайта. Сама по себе, это очень важная и комплексная работа – SEO-аудит сайта.

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

2.3. Юзабилити-баги

Ошибки могут быть допущены и в отношении юзабилити, т.е. удобства работы пользователей с сайтом. Выше уже были перечислены некоторые технические ошибки такого рода: нерабочие поиск, фильтры, форма регистрации и проч. Но и само наполнение сайта – его контент в широком смысле: структура, навигационные возможности, например меню, – а также картинки, тексты, кнопки и ссылки на отдельных страницах и т.д., – во всех этих вещах могут быть допущены ошибки. Они могут существенно осложнять взаимодействие пользователей с сайтом (плохое юзабилити). И «фишка» в том, что самому веб-разработчику, а также владельцу сайта эти ошибки далеко не всегда очевидны. А между тем, подобные ошибки могут существенно ухудшать качество сайта, что особенно критично в отношении бизнес-ресурсов: падает их продающая способность. Более того, неудобство сайтов для пользователя видно и поисковым системам через так называемые поведенческие факторы (ПФ). Для поисковиков это сигнал к понижению ранжирования сайта в своей выдаче. И это дополнительный фактор, снижающий коммерческую эффективность веб-ресурса, о чём говорилось выше (см. раздел 2.2 «SEO-баги»).

3. Конкретика

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

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

А ниже, собственно, конкретика:

Технический аудит сайта, тестирование всего функционала.
SEO-аудит сайта.
Юзабилити-аудит сайта.
Комплексный аудит сайта.
По результатам аудитов – исправление ошибок и оптимизация сайта.
Создание сайта с нуля.

Обращайтесь. Мы будем рады вам помочь!

«Баг на сайте!»,
или как не разругаться
с программистами
при тестировании

Провели еще один мастер-класс, теперь для тестировщиков. Баг не пройдет!

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

Расшифровка видео — под ним. Осторожно, многобукаф.

Дисклеймер: используется ненормативная лексика. Потому что так понятней. Уберите детей от экрана!

Две недели назад мы зарелизили новый сайт Сибирикса. За несколько дней до этого в студии проходил локальный апокалипсис. Люди бегали по офису, писали во внутренний чат: «Аааа, срочно, важно!!!», закидывали менеджера пожеланиями и хотелками. И менеджер что-то решал

Но попробуй-ка подойти с багом прямо в голову к матерому программисту. В панике прибеги, скажи: «Срочно, важно, давай реши!» Какая реакция возникнет? Психанет. В большинстве случаев.

Итак, как тестировать и записывать баги, при этом не разругаться с разработчиками и не оставить в проекте багов?

1. Делаем багтрекер (можно на коленке)

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

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

2. Не создаем конфликты на ровном месте

Когда пишешь разработчику матом, либо КАПСОМ, либо просто «баг» или даже «косяк» — это воспринимается как личное оскорбление. Это серьезный плевок в душу разработчика.

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

Что тут плохо? Непонятно.
Ответят вот так:

Когда начинаете диалог, пишите нейтральными словами.

Начнете диалог — вам ответят.

Наши заказчики иногда развернуто отвечают:

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

Но разработчику понятней не стало:

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

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

Возникает желание показать — добавьте скриншот.

4. Приводим к единому формату

У нас есть принятый формат таблички. Он выглядит адекватно:

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

Иногда тестировщики присылают экзотически названные листы «BUGS FINAL BUILD 15 LATEST VERSION BY VASILIY POUPKINE». Так делать не надо. Должно быть понятно, в каком браузере происходит баг и в каком месте. И дальше ссылка на скриншот.

5. Пишем адекватно

Скриншот — инструмент для демонстрации. Им можно проиллюстрировать явление, но не зафиксировать.

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

Такой скриншот неинформативен. Непонятно, в чем проявляется баг. Добавьте конкретики.

Сделайте описание бага на листе.

Скриншот дополнен комментарием, но не информативен.

Когда скриншот один — это еще терпимо. Если их много — баглист превращается в мешанину.

6. Не используем ссылки «См. п. N»

Часто тестировщики пишут «Аналогично строке 14»… Что здесь не так? Менеджер пересортирует документ, скопирует пару строк из одного баглиста в другой… И связь пропадет. Не надо делать такие включения. Каждое описание должно быть в понятном текстовом виде.

7. Делаем понятные описания проблемы

По такому описанию проблема найдена. Но слово «абракадабра» лучше заменить. Проблема-то для юзера. Для разработчика нормально, он же правильно все сделал, загрузил через Битрикс.

Ну да, ссылка есть, все стандартно. Битрикс в этом разделе генерировать понятные урлы не обучен. Разработчик говорит: «норм». А SEO и впечатление от просмотра страдают.

8. Не указываем личные мнения

Частая ошибка — пишем не то, что надо сделать, а личные мнения. Такие комментарии покрасят серым и проигнорят.

Другая ситуация, по сути, примерно такая же. Выписываем комментарий — но непонятно, баг это или фича. Кнопка зеленая! Спасибо, кэп. Она должна быть зеленая? Она сейчас зеленая? Или она при определенных обстоятельствах должна быть зеленой? Это конкретно бесит. Это текст ради текста.

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

9. Расставляем приоритеты

Наши разработчики идут по баглистам в порядке приоритетов:

0 — критические баги, сайт не работает вообще или работает не так, как ожидается;
1 — критичное юзабилити, забытые фичи;
2 — некритичные баги;
3 — некритичное юзабилити;
4 — ошибки в текстах;
8 — хотелки.

Написали «Ссылочку мне сделай красиво». Ок. Баг без приоритета. Разработчик начнет делать вперемешку, если не проигнорит. И будет злиться и посылать в далекое пешее путешествие.

При таком подходе программист исправит баг, и даже не особо перенервничает. Ну ладно, раз просит — сделаю.

10. Не подкидываем посуду

Новый сайт Сибирикса тестировали ежедневно. Каждый день создавался новый лист. Баги отлавливались сразу.

В чем минус постоянной работы над проектом?

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

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

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

Давайте оставим маты на полу в спортзале, перестанем писать капсом и употреблять в багтрекерах «косяки». Это воспринимается разработчиками как личное оскорбление. Пишете об ошибке — максимально конкретно указывайте место, где она возникла. И текстом, не скриншотом. Чтобы потом можно было легко найти баг через Ctrl + F. И не забывайте расставлять приоритеты. Если баг описан как пожелание, это нифига не конкретизируется до той поры, пока не выставлен приоритет. И, главное, указывая о проблеме, указывайте, что ожидается получить

Богдан Василенко

SEO-специалист SE Ranking

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

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

В чём заключается оптимизация сайта?

Оптимизация сайта или SEO (Search Engine Optimization) представляет собой комплекс действий, цель которых — улучшить качество ресурса и адаптировать его с учётом рекомендаций поисковых систем.

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

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

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

Как обнаружить проблемы SEO на сайте?

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

Один из примеров — сервис SE Ranking, объединяющий в себе разные аналитические инструменты. Результатом SEO-анализа будет комплексный отчёт. Для запуска анализа сайта онлайн нужно создать проект, указать в настройках домен своего ресурса, и перейти в раздел «Анализ сайта». Одна из вкладок — «Отчёт об ошибках», где отображаются выявленные проблемы оптимизации.

Все параметры сайта разделены на блоки: «Безопасность», «Дублирование контента», «Скорость загрузки» и другие. При нажатии на любую из проблем появится её описание и рекомендации по исправлению. После технической SEO оптимизации и внесения корректировок следует повторно запустить аудит сайта. Увидеть, были ли устранены ошибки, можно колонке «Исправленные».

Ошибки технической оптимизации и способы их устранения

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

Отсутствие протокола HTTPS

Расширение HTTPS (HyperText Transfer Protocol Secure), которое является частью доменного имени, — это более надежная альтернатива протоколу соединения HTTP. Оно обеспечивает шифрование и сохранность данных пользователей. Сегодня многие браузеры блокируют переход по ссылке, начинающейся на HTTP, и отображают предупреждение на экране.

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

Как исправить

Чтобы перевести ресурс на HTTPS, необходимо приобрести специальный сертификат и затем своевременно продлевать срок его действия. Настроить автоматическое перенаправление с HTTP-версии (редирект) можно в файле конфигурации .htaccess.

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

У сайта нет файла robots.txt

Документ robots размещают в корневой папке сайта. Его содержимое доступно по ссылке website.com/robots.txt. Этот файл представляет собой инструкцию для поисковых систем, какое содержимое ресурса следует сканировать, а какое нет. К нему роботы обращаются в первую очередь и затем начинают обход сайта.

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

Как исправить

Создайте текстовый документ с названием robots в корневой папке сайта и с помощью директив пропишите внутри рекомендации по сканированию содержимого страниц и каталогов. В файле могут быть указаны виды роботов (user-agent), для которых действуют правила; ограничивающие и разрешающие команды (disallow, allow), а также ссылка на карту сайта (sitemap).

Проблемы с файлом Sitemap.xml

Карта сайта — это файл, содержащий список всех URL ресурса, которые должен обойти поисковый робот. Наличие sitemap.xml не является обязательным условием, для попадания страниц в индекс, но во многих случаях файл помогает поисковику их обнаружить.

Обработка XML Sitemap может быть затруднительна, если ее размер превышает 50 МБ или 50000 URL. Другая проблема — присутствие в карте страниц, закрытых для индексации метатегом noindex. При использовании канонических ссылок на сайте, выделяющих их похожих страниц основную, в файле sitemap должны быть указаны только приоритетные для индексации URL.

Как исправить

Если в карте сайта очень много URL и её объем превышает лимит, разделите файл на несколько меньших по размеру. XML Sitemap можно создавать не только для страниц, но и для изображений или видео. В файле robots.txt укажите ссылки на все карты сайта.

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

Дубли контента

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

Причиной, почему дубли страниц попадают в индекс, может быть отсутствие или неправильная настройка «зеркала» — редиректа между именем сайта с www и без. В этом случае поисковая система индексирует две идентичные страницы, например, www.website.com и website.com.

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

Как исправить

Настройте www-редиректы и проверьте с помощью SEO-аудита, не осталось ли на сайте дублей. При создании страниц с минимальными отличиями используйте канонические ссылки, чтобы указать роботу, какие из них индексировать. Чтобы не ввести в заблуждение поисковые системы, неканоническая страница должна содержать тег rel=”canonical” только для одного URL.

Страницы, отдающие код ошибки

Перед тем, как отобразить страницу на экране, браузер отправляет запрос серверу. Если URL доступен, у него будет успешный статус HTTP-состояния — 200 ОК. При возникновении проблем, когда сервер не может выполнить задачу, страница возвращает код ошибки 4ХХ или 5ХХ. Это приводит к таким негативным последствиям для сайта, как:

Ухудшение поведенческих факторов. Если вместо запрошенной страницы пользователь видит сообщение об ошибке, например, «Page Not Found» или «Internal Server Error», он не может получить нужную информацию или завершить целевое действие.
Исключение контента из индекса. Когда роботу долго не удается просканировать страницу, она может быть удалена из индекса поисковой системы.
Расход краулингового бюджета. Роботы делают попытку просканировать URL, независимо от его статуса. Если на сайте много страниц с ошибками, происходит бессмысленный расход краулингового лимита.

Как исправить

После анализа сайта найдите страницы в статусе 4ХХ и 5ХХ и установите, в чём причина ошибки. Если страница была удалена, поисковая система через время исключит её из индекса. Ускорить этот процесс поможет инструмент удаления URL. Чтобы своевременно находить проблемные страницы, периодически повторяйте поиск проблем на сайте.

Некорректная настройка редиректов

Редирект — это переадресация в браузере с запрошенного URL на другой. Обычно его настраивают при смене адреса страницы и её удалении, перенаправляя пользователя на актуальную версию.

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

Но при настройке переадресаций нередко возникают такие проблемы, как:

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

Как исправить

Проведите SEO-аудит сайта и найдите страницы со статусом 3ХХ. Если среди них есть цепочки редиректов, состоящие из трех и более URL, их нужно сократить до двух адресов — исходного и актуального. При выявлении зацикленных переадресаций необходимо откорректировать их последовательность. Страницы, имеющие статус ошибки 4ХХ или 5ХХ, нужно сделать доступными или удалить из цепочки.

Низкая скорость загрузки

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

Google использует специальные показатели Core Web Vitals для оценки сайта, где о скорости говорят значения LCP (Largest Contentful Paint) и FID (First Input Delay). Рекомендуемая скорость загрузки основного контента (LCP) — до 2,5 секунд. Время отклика на взаимодействие с элементами страницы (FID) не должно превышать 0,1.

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

объёмные по весу и размеру изображения;
несжатый текстовый контент;
большой вес HTML-кода и файлов, которые добавлены в него в виде ссылок.

Как исправить

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

Также будет полезно настроить сжатие текстов. Благодаря заголовку Content-Encoding, сервер будет уменьшать размер передаваемых данных, и контент будет загружаться в браузере быстрее. Также полезно оптимизировать объем страницы, используя архивирование GZIP.

Не оптимизированы элементы JavaScript и CSS

Код JavaScript и CSS отвечает за внешний сайта. С помощью стилей CSS (Cascading Style Sheets) задают фон, размер и цвета блоков страницы, шрифты текста. Сценарии на языке JavaScript делают дизайн сайта динамичным.

Элементы CSS/JS важны для ресурса, но в то же время они увеличивают общий объём страниц. Файлы CSS, превышающие по размеру 150 KB, а JavaScript — 2 MB, могут негативно влиять на скорость загрузки.

Как исправить

Чтобы уменьшить размер и вес кода CSS и JavaScript, используют такие технологии, как сжатие, кэширование, минификация. SEO-аудит помогает определить, влияют ли CSS/JS-файлы на скорость сайта и какие методы оптимизации использованы.

Кэширование CSS/JS-элементов снижает нагрузку на сервер, поскольку в этом случае браузер загружает сохранённые в кэше копии контента и не воспроизводит страницы с нуля. Минификация кода, то есть удаление из него ненужных символов и комментариев, уменьшает исходный размер. Ещё один способ оптимизации таблиц стилей и скриптов — объединение нескольких файлов CSS и JavaScript в один.

Отсутствие мобильной оптимизации

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

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

О проблемах с настройками мобильной версии говорит отсутствие метатега viewport, отвечающего за адаптивность страницы под экраны разного формата, или его неправильное заполнение. Также о нестабильности элементов страницы во время загрузки информирует еще показатель производительности сайта Core Web Vitals — CLS (Cumulative Layout Shift). Его норма: 0,1.

Как исправить

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

Обратите внимание, чтобы в HTML-коде страниц были метатеги viewport. При этом значение device-width не должно быть фиксированным, чтобы ширина страницы адаптировалась под размер ПК, планшета, смартфона.

Отсутствие alt-текста к изображениям

В HTML-коде страницы за визуальный контент отвечают теги <img>. Кроме ссылки на сам файл, тег может содержать альтернативный текст с описанием изображения и ключевыми словами.

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

Как исправить

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

Заключение

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

К частым проблемам оптимизации можно отнести:

имя сайта с HTTP вместо безопасного расширения HTTPS;
отсутствие или неправильное содержимое файлов robots.txt и sitemap.xml;
медленная загрузка страниц;
некорректное отображение сайта на смартфонах;
большой вес файлов HTML, CSS, JS;
дублированный контент;
страницы с кодом ошибки 4ХХ, 5ХХ;
неправильно настроенные редиректы;
изображения без alt-текста.

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

Автор: Надежда Князева

Все продукты получаются неидеальными. Да-да! С багами! Некоторые из них никогда не будут поправлены. Произнесите это слово по слогам, чтобы почувствовать всю обреченность и окончательность этого вердикта: ни-ког-да!

Тип 1. Баги, связанные с устаревшими устройствами и программами

Если вы делаете продукт в 2018 году, нет смысла добавлять специальную верстку для Internet Explorer 6 или подстраиваться под iPhone 4. Конечно, это почти абсурдные примеры, но человек в здравом уме вряд ли будет поддерживать старое устройство или древнюю версию браузера, так как их аудитория уменьшается с каждым днем и однажды просто исчезнет.

Здесь стоит сделать оговорку: все же не стоит отсекать идею пофиксить подобный баг сразу. Все нужно соотносить с полезностью для пользователей и вашими затратами. Например, если вы потратите на фикс 10 минут, а «спасибо» вам при этом скажут десятки тысяч человек, нужно браться за работу. А вот тратить 20 часов для одного пользователя бесплатной версии, который отписался под одним из ваших постов на Хабре годичной давности, – это непродуктивное решение.

Тип 2. Баги в сторонних компонентах

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

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

Тип 2 и 3/4 . Баги, связанные с технологией

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

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

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

Тип 3. Баги, которые никогда не воспроизведутся у пользователей

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

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

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

Тип 4. Баги, которые сложно повторить

Как правило, это ошибка, которая повторяется при условии, что ваши GPS-координаты сообщают, что вы в Зимбабве. И вы стоите лицом на восток. По колено в воде. В новолуние. И ровно в полночь вам приходит push-уведомление.

Тип 5. Баги, которые приносят деньги

История из жизни: в одной компании, занимавшейся мультимедийным софтом, делали бесплатную программу. Во время ее установки пользователя вежливо спрашивали, не желает ли он установить еще и расширение для браузера. При этом чекбокс оставался серым, а галочка «Установить расширение для браузера» стояла по умолчанию, так что создавалась иллюзия неактивности этого элемента интерфейса. Хотя, знаете что? На самом деле ее можно было убрать. И как вы уже могли догадаться, монетизация бесплатного приложения была организована именно с помощью этого расширения. Серый чекбокс – очевидный баг, с обнаружения которого прошло уже много лет, но его до сих пор не поправили.

Тип 6. Баги, которые ни на что не влияют

Обычно это что-то незначительное: например, пустая div’ка в html-коде. Это несомненный баг, но поскольку он сидит себе и не высовывается, то и править его никто не будет.

Тип 7. Баги, за которые никто не отвечает

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

Абстрактный сценарий такой: несколько отделов создают общую фичу. Сначала дизайнеры нарисовали кнопку и забыли. Потом программист из отдела 1 в силу своей загруженности подготовил компонент, забыв пробросить туда кое-какие методы. Программист из отдела 2 взял готовый компонент и вставил его в продукт без исправлений. Работает? Скорее всего, работает, но при этом может, например, выглядеть уродливо. Ну а поскольку для всех героев это была всего лишь побочная задача среди сотен других, то все так и остается.

Баги, за которые никто не отвечает, могут быть довольно критичными. При этом их никто не будет фиксить до тех пор, пока пользователи молчат. И это тревожный звоночек… а может, даже целый колокол! Звонит он не только и столько по заброшенной части продукта – он звонит по организационным процессам в компании.

Как с этим жить?

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

Наличие незакрытых тикетов в багтрекере – это не свидетельство некомпетентности и не трагедия. Да, здесь автор немного драматизирует, прочитав на stackexchage трэд о том, как стать zero-bug programmer (ответ: не писать код или найти себе плохих тестировщиков).

Более того, если у вас много неисправленных багов, вы знаете о них и приняли осознанное решение не вносить правку – это здорово! Вы знаете ваш продукт и готовы ко всему!

Судьба бага

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

баги, которые нельзя не поправить;
все остальные.

Во втором случае вам всегда придется принимать бизнес-решение, руководствуясь как минимум двумя вещами – здравым смыслом и собственной выгодой.

В эссе основателя Source Gear Эрика Синка My life as a Сode Economist автор предлагает задавать себе по поводу каждого бага четыре вопроса:

Степень критичности: когда этот баг повторяется, каков его негативный эффект и насколько он критичен для системы?
Частота: как часто он повторяется?
Цена: сколько усилий и ресурсов нам потребуется, чтобы поправить этот баг (пока мы правим баги, мы не делаем что-то новое)?
Риск: чем мы рискуем, когда правим этот баг (любое изменение кода – это риск)?

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

Обсудить в форуме

Источник

Краткое содержание

1. «Классические» баги

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

2. Баги сайта

2.1. Программные баги сайта

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

2.2. SEO-баги

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

2.3. Юзабилити-баги

3. Конкретика

А ниже, собственно, конкретика:

Технический аудит сайта, тестирование всего функционала.
SEO-аудит сайта.
Юзабилити-аудит сайта.
Комплексный аудит сайта.
По результатам аудитов – исправление ошибок и оптимизация сайта.
Создание сайта с нуля.

Обращайтесь. Мы будем рады вам помочь!

Источник

Баг (bug) – это ошибка в коде или в работе программы. Разработчики описывают этим сленговым словом ситуацию, когда что-то работает неправильно, выдает неверный или непредсказуемый результат.

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

Программу с багами называют забагованной. А отладку кода – дебаггингом, то есть избавлением от багов.

Слово bug в переводе с английского означает «жук». Оно пришло в программирование из сленга инженеров, которые называли багами ошибки при работе электронных схем. А в 1947 году создательница первого компилятора Грейс Хоппер обнаружила в компьютере Mark II бабочку, закоротившую контакты. В журнале происшествий написали: «Первый случай, когда был найден настоящий баг». Так термин закрепился в компьютерной сфере.

Рукописная запись с багом, то есть с жуком

Сейчас записи вместе с бабочкой находятся в Национальном музее американской истории

Где встречаются баги

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

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

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

Известный смешной баг игры Mount and Blade: из-за сбоя в файлах игры вместо неба отображалось огромное лицо

На сайтах. Современные сайты такие гибкие и функциональные благодаря скриптам, написанным на языках программирования. В браузере работает JavaScript, на сервере языки могут быть разными: PHP, Python, Ruby и другие. Баг может возникнуть и на стороне сервера, и в клиентской части сайта – иногда его замечают только после выпуска в продакшн. Есть даже понятие bug bounty: вознаграждение, которое компания выплачивает пользователю, нашедшему критичный баг в информационной безопасности.

Кто сталкивается с багами

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

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

Из-за чего возникают баги

Мы выяснили, что такое баг. Теперь поговорим о причинах, из-за которых они появляются.

Первая и наиболее распространенная причина – ошибка разработчика. В IT-среде есть шутка: «Кто же победит: человек, венец природы… или крохотная забытая скобочка?». Маленькие недочеты могут быть очень критичными. Если поставить плюс вместо минуса в простейшем математическом вычислении, то получится совершенно другой результат.
Иногда причиной багов становится незнание. Например, разработчик был не в курсе специфического поведения какой-нибудь конструкции в языке, поэтому воспользовался ею не совсем корректно.
Часто баги возникают, если в команде программистов нет слаженности. Один не понимает, что написал другой, правит код по своему усмотрению и получает некорректное поведение программы.
Наконец, дизайн программы и архитектурные ошибки тоже могут быть причиной багов. Использование неоптимальных алгоритмов, ведущих к сбоям, неверный выбор инструментов – все это может привести к забагованности.

Известный в интернете забавный случай показывает, насколько неочевидными бывают баги

Ворнинги, вылеты, исключения: чем отличаются от багов

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

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

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

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

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

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

Какими бывают баги

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

Опечатка – простейший вариант. Разработчик случайно пишет не то, и вся программа работает неправильно.
Бесконечный цикл – ситуация, когда условие для выхода из цикла никогда не наступает, и программа виснет.
Переполнение буфера – явление, когда программе перестает хватать памяти, и она начинает пользоваться памятью за пределами выделенного ей количества.
Состояние гонки – баг многопоточных приложений, когда несколько потоков одновременно обращаются к одному и тому же элементу и как бы «соревнуются» за доступ. Результат непредсказуем.
Количественный баг – ошибка при работе с большим количеством действий, когда при многократных повторениях появляются баги. Например, большое количество данных распределяется неравномерно.
Демонстрационный эффект – явление, когда программа работала нормально на этапе написания, но сломалась при демонстрации. Зачастую возникает из-за недостаточного тестирования и невнимательности: разработчик не учел какой-то сценарий.

Баги – это очень плохо?

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

Например, баг в медицинском оборудовании может привести к трагедии. Баг в коде сайта – к утечке огромного бюджета: так было, когда блокчейн-компания Compound случайно отправила своим пользователям почти 90 миллионов долларов. А самый дорогой баг в истории – арифметическое переполнение в программной начинке ракеты-носителя «Арион-5», из-за которого ракета взорвалась в полете.

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

Баг на табло, вместо 2000 года показывает 1900

Знаменитая «проблема 2000 года» или Y2K: когда наступил 2000 год, многие компьютеры по всему миру восприняли его как 1900

Как избежать багов

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

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

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

Источник