Ловим баги или почему программы допускают "недопустимые операции"


Содержание

Ловим баги или почему программы допускают "недопустимые операции"

Доброе время суток !

Новости сайта «Все о Дельфи от Чертенка » от 05.11 выпуск 11

Напоминаю, что сайт рассылки находится по адресу: www.chertenok.wallst.ru ,
пожалуйста, обновите Ваши закладки !

Новые статьи на сайте:

Жду Ваших идеи и предложений (в том числе по оформлению рассылки) .
Рекомендуемый формат подписки — html.

С наилучшими пожеланиями, Ваш Владимир aka Чертёнок.

Ловим баги или Почему программы допускают «недопустимые операции»

Ловим баги или Почему программы допускают «недопустимые операции»

Е. Левшаков, В. Ковалев, mcsa.ru

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

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

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

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

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

Ошибки возникают при старте и закрытии Delphi или формировании проекта. Причиной могут являться сбои в «железе» компьютера.

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

И в конце концов просто попытаться заменить драйвера на более свежие.

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

Хотя Windows 9X популярная система, разработку лучше проводить в Windows NT или Windows 2000 — это более устойчивые операционные системы. Естественно, при переходе на них придется отказаться от некоторых благ семейства Windows 95/98/Me — в частности, не все программы адаптированы для Windows NT/2000. Зато вы получите более надежную и стабильную систему.

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

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

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

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

Вы могли бы рассмотреть компилирование вашего приложения с директивой <$D>, данная директива компилятора может создавать файлы карты (файлы с расширением map, которые можно найти в том же каталоге, что и файлы проекта), которые могут послужить большой справкой в локализации источника подобных ошибок. Для лучшего «контроля» за своим приложением компилируйте его с директивой <$D>. Таким образом, вы заставите Delphi генерировать информацию для отладки, которая может послужить подспорьем при выявление возникающих ошибок.

Следующая позиция в Project Options — Linker & Compiler позволяет вам, определить все для последующей отладки. Лучше всего, если помимо самого выполняемого кода будет доступна и отладочная информация — это поможет при поиске ошибок. Отладочная информация увеличивает размер файла и занимает дополнительную память при компилировании программ, но непосредственно на размер или быстродействие выполняемой программы не влияет. Включение опций отладочной информации и файла карты дают детальную информацию только если вы компилируете программу с директивой <$D+>.

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

Таким образом вы без труда сможете найти точный адрес той подпрограммы, которая была ответственна за ошибку. Одна из наиболее общих причин ошибок выполнения — использование объекта, который еще не был создан. Если второй адрес при выдачи ошибки — FFFFFFF (или 0000000) Вы можете почти утверждать, что было обращение к объекту, который еще не был создан. Например, вызов метода формы, которая не была создана.
Попытаемся разобратся в этой ситуации. Предположим, что BadForm есть в списке «Available forms» в окне Project Options|Forms. В этом списке находятся формы, которые должны быть созданы и уничтожены вручную. В коде выше происходит вызов метода Refresh формы BadForm, что вызывает нарушение доступа, так как форма еще не была создана, т.е. для объекта формы не было выделено памяти.

Если вы установите «Stop on Delphi Exceptions» в Language Exceptions tab в окне Debugger Options, возможно возникновение сообщения об ошибке, которое покажет, что произошло ошибка типа EACCESSVIOLATION. EACCESSVIOLATION — класс исключение для недопустимых ошибок доступа к памяти. Вы будете видеть это сообщение при разработке вашего приложения, т.е. при работе приложения, которое было запущено из среды Delphi.

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

Первое шестнадцатиричное число (‘0043F193’) — адрес ошибки во время выполнения программы. Выберите опцию меню ‘Search|Find Error’, введите адрес, в котором произошла ошибка (‘0043F193’) в диалоге и нажмите OK. Теперь Delphi перетранслирует ваш проект и покажет вам строку исходного текста, где произошла ошибка во время выполнения программы, то есть BadForm.Refresh.

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

Недопустимый параметр API


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

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

Индексация пустой строки

Пустая строка не имеет никаких достоверных данных. Следовательно, попытка индексировать пустую строку — подобно попытке обратиться к нулю, что приведет также к ошибке:

Обращение к динамической переменной

Вы должны строить обращение к динамической переменной корректно, иначе вы перемещаете адреса указателей и возможно разрушаете другие выделенные ячейки памяти.
procedure TForm1.Button1Click(Sender: TObject);

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

Ловим баги или почему программы допускают "недопустимые операции"

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

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

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

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

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

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

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

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

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

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

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

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

Как правильно описывать похожие баги или один баг в разных браузерах

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

Однотипные баги в разных местах

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

Рассмотрим данные ситуации подробнее:

  1. При изменении локализации некоторые элементы не переведены.

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

  • Названия разделов «Women», «Dresses» и «T-Shirts» не переведены на главной странице сайта после переключения языка сайта на «Русский».
  • Текст баннеров «Excepteur occaecat», «3 Days sale» и «Only online summer» не переведен на главной странице сайта после переключения языка сайта на «Русский».

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

Например:

Summary: Курсор мыши не меняется на «Указатель» на главной странице сайта после наведения на кнопку «Обратная связь».


Description: Курсор мыши не меняется на «Указатель» на главной странице сайта после наведения на кнопку «Обратная связь». Дефект также воспроизводится для кнопок «Добавить в корзину» и «Избранное».

  1. Текст выходит за пределы отведенной области.

На скриншоте отчетливо видно, что текст кнопок «Toista panos» и «Toista panos x2» выходит за пределы отведенной области. В данном случае не стоит заводить отдельные отчеты об ошибках на каждый отдельный элемент. Лучше завести один баг-репорт, в котором перечислить найденные элементы с дефектами:

  • Текст кнопок «Toista panos» и «Toista panos x2» выходит за пределы отведенной области на экране «Table» после переключения языка на «Finnish».

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

Например:

Summary: The «Details» value field is overlapped by the «Round ID» text on the «Hand History» screen.

Description: The «Details» value field is overlapped by the «Round ID» text on the «Hand History» screen. The issue is reproduced with all languages, except English.

Также рассмотрим одну из типичных ошибок новичков.

Обратите внимание на расположение кнопки «Корзина». Элемент одновременно не выровнен и по горизонтали, и по вертикали. Так и нужно писать в отчете об ошибке:

  • Кнопка «Корзина» не выровнена по горизонтали и вертикали на главной странице сайта.

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

Что делать, если баг встретился в разных браузерах?

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

Необходимо просто перечислить все браузеры / устройства / ОС в одном баг-репорте, на которых воспроизводится баг в отдельном поле «Environment», если оно есть, либо в «Additional Info».

Пример:

Environment:
Safari 4.1.3
IE 11.435
Chrome 43.567 (56)

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

Пример:

Кнопка «Вход» не переведена и отображается как «Enter» на страницах «Регистрация», «Меню» и «Поиск». На остальных же – отображается переведенной. Если в шагах мы указали, как воспроизвести баг, скажем, для страницы «Search», тогда в «Additional Info» пишется:

The bug is also reproduced on the «Registration» and «Menu» pages.

Стоит понимать, что можно объединить несколько однотипных инцидентов в один, но чаще всего один баг-репорт должен сообщать об одном баге.

Освежим в памяти основные понятия при заведении бага:

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

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

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

Атрибуты бага в баг-трекере:

ID – это уникальный идентификатор бага в баг-трекере. Автоматически присваивается системой.

Summary – краткое и лаконичное описание бага, отвечающее на вопрос «Что произошло, где произошло и при каких условиях?».

Например: «The «404 Page not Found» error message is shown (что?) on the «Contact us» page (где?) after clicking the «Contact us» link (когда?)». То есть описание бага должно быть такое, чтобы программисту его даже можно было не открывать, а сразу искать в чем же баг. Но чаще попадаются все же сложные баги, которые и требуют описания внутри дополнительных действий и разъяснений, как же его воспроизвести и как на самом деле должно быть, так что только по Summary может быть трудно понять проблему. Поэтому существуют следующие, приведенные ниже, поля:

Илон Маск рекомендует:  Что такое код asp getnexturl


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

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

Так как шаги создания админа – не суть этого бага, то это действие можно вынести в Preconditions. Например: «A new admin account is created»

Steps to Reproduce – поле используется для описания шагов, необходимых для воспроизведения данного бага.

Например:

  1. Open the login page of admin panel.
  2. Enter valid credentials into the «Username» and «Password» text fields.
  3. Click the «Sign in» button.

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

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

The «You have entered incorrect user or password» message is displayed on the login page after entering valid credentials

Expected Result – правильное поведение системы после выполнения последнего шага.

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

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

В разных баг-трекерах приоритетность может определяться разными уровнями (от «Immediate» до «Low», или цифрами от 1 до 4), принцип от наивысшего приоритета к низшему. В некоторых трекерах может вовсе и не быть такого поля (например, Pivotal tracker).

Severity – указывает на серьезность ошибки с точки зрения влияния на работу ПО. Существуют несколько уровней серьезности ошибки, таких как:

  • Blocker. Баг блокирует дальнейшую работу приложения или блокирует дальнейшее тестирование. Например, после создания пользователя, с существующим именем нельзя войти в систему любым пользователем, так как отображается SQL ошибка на главной странице, предотвращающая всяческие попытки входа в систему.
  • Critical. Баг оказывает существенное влияние на работу ПО, но не блокирует его работу. Например, пользователь может войти в систему без введения пароля.
  • Major. Баг оказывает незначительное влияние на работу ПО. Например, количество записей в списке записей подсчитывается неверно.
  • Minor. Баг не влияет на функционал ПО. Например, грамматическая ошибка в названии чего-либо.

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

Следует отметить, что во многих случаях Severity бага будет примерно равен его Priority. Но это не всегда так.

Например:

  • Логотип компании на главной странице отображается неверно или не отображается вовсе. Такого рода дефект не оказывает никакого влияния на функционал сайта, но с точки зрения бизнеса, это очень серьезно. В итоге, имеем наинизшую серьезность и наивысший приоритет.
  • Отображается ошибка 404 при попытке перейти в один из разделов сайта. Казалось бы, необходимо устанавливать максимальные Severity и Priority, но менеджер проекта два дня назад сообщил, что в текущей итерации работ в том функционале не планируется, т.к. это не самый важный функционал и есть задачи более важные. В итоге, имеем Severity = Blocker, но Priority = Low.

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

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

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

Ловим баги или почему программы допускают "недопустимые операции"

• Продукт у нас хороший, и вы бы сами убедились, если бы не…

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Как локализовать плавающие баги
12.07.2020 14:37

Автор: Джеймс Бах (James Bach)

Перевод: Ольга Алифанова

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

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

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

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

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

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

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

Принципы работы с плавающими багами

  • Успокойтесь, они, скорее всего, не вызваны злыми духами.
  • Если это случилось один раз – скорее всего, это произойдет снова.
  • Если баг не был исправлен, вряд ли он самоликвидировался навсегда.
  • С осторожностью относитесь к исправлениям плавающих багов. Исправленный баг и неисправленный плавающий баг неотличимы друг от друга по определению в течение какого-то времени и/или при определенных условиях.
  • Любое состояние системы, переход в которое занимает длительное время в обычных обстоятельствах, может быть мгновенно достижимым в непредсказуемых ситуациях.
  • Сложное и запутанное поведение обычно спровоцировано чем-то довольно простым.
  • Сложное и запутанное поведение иногда спровоцировано целым комплексом причин.
  • Плавающие баги зачастую могут рассказать вам много интересного про ваш продукт.
  • Очень легко поддаться уверенности, что ваше предположение об источнике проблемы разумно, остроумно и имеет смысл – оно просто неверное.
  • Ключ к разгадке может находиться в руках другого человека.
  • Возможно, что баг, «плавающий» на тест-стенде, легко воспроизведется на проде.
  • Принцип Pentium 1994: плавающая техническая проблема может привести к систематическим и очень дорогостоящим проблемам бизнеса.
  • Проблема может быть плавающей, но риск, связанный с ней, стабилен.
  • Чем выше тестируемость продукта, тем легче исследовать плавающие баги.
  • Когда вы исключили все невозможное, то то, что осталось, каким бы невероятным оно ни было, уже нанесло существенный урон! Поэтому не ждите момента, когда вы полностью раскусите этот орешек, заводите плавающие баги как можно раньше!
  • Если вы не успеваете ущучить плавающий баг до релиза, сделайте все, что в ваших силах, чтобы все-таки выловить его и исправить. Получайте удовольствие от процесса, так сказать.

Общие советы по исследованию плавающих проблем

  • Перепроверьте свои базовые предположения: используете ли вы именно тот компьютер? Тестируете ли вы именно то, что нужно? Верны ли ваши наблюдения?
  • Свидетельства очевидцев могут оставить за бортом важную информацию, поэтому слушайте, но не нужно излишней уверенности в чужих словах.
  • Пригласите других наблюдателей, подключите к процессу большее количество людей.
  • Мотивируйте людей сообщать о плавающих проблемах.
  • Если вам сказали, что причина проблемы ТОЧНО не в этом, обратите на ЭТО особое внимание.
  • Проверьте сайты технической поддержки каждого из сторонних компонентов, который используется в вашем приложении. Возможно, ваша проблема там указана.
  • Ищите инструменты, которые помогут вам наблюдать за поведением системы и контролировать его.
  • Налаживайте коммуникацию с наблюдателями (особенно с реальными пользователями).
  • Соберите все загадочные баги в одном месте, чтобы легче было отслеживать закономерности.
  • Просмотрите список багов, поищите в нем похожие на плавающий баг проблемы.
  • Точнее зафиксируйте свои наблюдения, пользуйтесь инструментами.
  • Улучшите тестируемость вашего продукта, добавьте логирование и интерфейсы с поддержкой сценариев.
  • Точнее контролируйте данные, которые вы вводите (включая их последовательность, время, типы, размеры, источники, итерации, комбинации).
  • Систематически покрывайте тестами данные ввода и состояния системы.
  • Сохраняйте абсолютно все логи. Возможно, позже вам понадобится сравнить новые логи со старыми.
  • Если проблема чаще возникает в одних ситуациях и реже – в других, проведите статистический анализ разницы между закономерностями в этих ситуациях.
  • Попробуйте контролировать то, что, с вашей точки зрения, не имеет значения.
  • Упрощайте все. Попытайтесь менять одну переменную за раз, попробуйте разбить систему на части (помогает понять и изолировать проблему).
  • Усложняйте. Попытайтесь изменить несколько переменных за раз, устройте в системе бардак (помогает выловить «лотерейные» баги).
  • Добавьте элемент случайности в состояния системы и обрабатываемые данные (возможно, при помощи менее жесткого контроля), чтобы добиться состояний, которые, возможно, не вписываются в ваш обычный шаблон использования.
  • Создайте искусственный стресс (высокая нагрузка, большие объемы данных).
  • Поставьте ловушку, чтобы при возникновении проблемы в следующий раз вам удалось изучить ее получше.
  • Подумайте насчет код-ревью.
  • Поищите конфликты между компонентами, созданными разными компаниями.
  • Собирайте и храните рассказы о локализации плавающих багов.
  • Систематически размышляйте о причинах плавающих багов (см. ниже).
  • Опасайтесь потратить кучу времени на мелкий баг, всегда спрашивайте себя, стоит ли он того.
  • Если ничего не помогает, дайте проблеме отлежаться, поработайте над чем-нибудь другим и последите, не появится ли она снова.

Возможные причины плавающих багов

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

Вероятная причина номер 1: Система ведет себя точно так же, как и вела. Кажущийся сбой поведения – артефакт, относящийся к вашему восприятию.

  • Плохие наблюдения. Наблюдатель мог быть невнимательным — например, подвергнуться «Слепоте невнимания» – феномену, когда мозг занят чем-то еще, и человек не видит того, что находится у него прямо перед носом. Если показать ему то же самое еще раз, он увидит нечто новое для себя и предположит, что раньше такого не происходило. К тому же так работает ряд оптических иллюзий, демонстрируя кажущееся иным поведение при том, что ровным счетом ничего не изменилось.
  • Наблюдения, не относящиеся к делу. Наблюдатель обращает внимание на различия, которые не имеют значения. То, что важно, остается стабильным. Это случается, когда наблюдатель чересчур пристально бдит за мелочами.
  • Плохая память. Возможно, наблюдатель плохо запомнил свои впечатления, или записи, фиксирующие проблему, повреждены. Когда вы наблюдаете за чем-то, ваш мозг обрабатывает кучу данных! Он немедленно упаковывает их и пытается связать их с другими данными, при этом важная информация может потеряться. К тому же в процессе разработки и тестирования мы повторяем одно и то же довольно часто, и можем запутаться в деталях каждого отдельного наблюдения.
  • Ложная атрибуция. Наблюдатель приписывает свое наблюдение не тому, чему нужно. К примеру, «Microsoft Word упал» может означать, что упала Windows, и причина падения не имеет к Word ни малейшего отношения. Word вообще ничего не делал. Этот феномен еще называют «ложной корреляцией» и часто встречается, когда одно событие следует сразу же после другого, и кажется, что это причина и следствие. Благодаря ложной корреляции плавающие баги зачастую считаются обычными багами, появившимися из-за крайне сложного и маловероятного комплекса причин.
  • Искажение фактов. Наблюдатель, возможно, неверно передает информацию. Причин может быть множество – например, вполне невинная: он настолько уверен в своих предположениях, что передает свои наблюдения определенным образом. Как-то раз я спросил сына, подключена ли его нерабочая Playstation к сети. «Конечно», огрызнулся он. Попробовав решить проблему так и сяк, я решил, что блок питания умер. После чего посмотрел на него и обнаружил, что штекер не включен в розетку.
  • Ненадежный оракул. Мнение наблюдателя насчет того, что является проблемой, а что нет, постоянно меняется. У нас может создаться впечатление, что проблема плавающая, только потому, что некоторые люди – иногда – не считают это поведение проблемой, даже если оно вполне предсказуемое. Другие люди могут отнестись к вопросу иначе, и даже один и тот же человек может поменять свое мнение.
  • Ненадежная коммуникация. Коммуникация с наблюдателем может быть неполной. У нас создается ощущение, что мы нашли плавающий баг, потому что сообщения о нем не всегда до нас доходят, даже если проблема вполне предсказуема. Фраза «Мне кажется, проблема больше не проявляется» может означать, что люди просто перестали о ней сообщать.

Вероятная причина номер 2: Система ведет себя иначе, потому что это другая система.

  • Deusexmachina. Разработчик мог специально что-то поменять, а потом вернул все назад. Это часто случается, когда над разными частями платформы одновременно работает несколько разработчиков или команд, не координируя свои действия друг с другом. Другой вариант – злонамеренные модификации приложения хакерами.
  • Случайное изменение. Разработчик мог внести правки случайно. Возможно, незапланированные побочные эффекты и приводят к возникновению плавающих проблем. К тому же разработчик может ошибиться и выкатить правки на прод вместо тест-стенда.
  • Другая платформа. Один из компонентов платформы мог быть заменен или переконфигурирован. Администратор или пользователь могли специально или случайно изменить что-то в компоненте, от которого зависит продукт. Частый источник таких проблем – автоматические обновления Windows, изменения в конфигурации памяти и дискового пространства.
  • Проблемы железа. Может, какой-то физический компонент системы сбоит время от времени. Перебои могут быть вызваны естественными вариациями в его работе, магнитными полями, излишне высокой температурой, низким зарядом батареи, плохим обслуживанием или физическим шоком.
  • Чужая система. В работу вашего приложения может вмешаться какое-нибудь еще. Например, в веб-тестировании я могу иногда получать неверные результаты из-за прокси-сервера провайдера, который загружает кэшированную версию страницы в неподходящий момент. Другие примеры такого вмешательства – это сканирование на вирусы, обновления системы, другие программы или та же самая программа, запущенная повторно.
  • Проблемы кода. Может, проблема кроется в том, как написан код. Один из худших багов, созданных моими руками (худших в смысле тяжести поиска причины) возникал из-за кода в игре, который иногда перезаписывал данные в совершенно другой части программы. Из-за природы этих данных игра не падала — зато поврежденная функция передавала управление функции, которая следовала сразу за ней в памяти приложения. Мне понадобилось несколько дней (и эмулятор чипа), чтобы это понять.
  • Раздвоение личности. То, что вы понимаете под системой, может на самом деле состоять из нескольких систем, мимикрирующих под единую. К примеру, я могу получать разные результаты от Google в зависимости от того, на какой сервер Гугла я попадаю. Или разные компьютеры тест-команды имеют разные версии ключевого компонента, или я опечатался в URL и случайно начал тестировать на другом сервере.
  • Человеческий фактор. Возможно, за запуск части системы отвечает человек, и этот человек ведет себя по-разному.

Вероятная причина номер 3. Система ведет себя иначе, потому что находится в другом состоянии.

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

Вероятная причина номер 4. Система ведет себя иначе, потому что получила другие вводные данные.

  • Случайный ввод. Пользвоатель мог ввести что-то или изменить ввод таким образом, что это не должно было ни на что повлиять – но все же повлияло. Это можно назвать синдромом Умного Ганса – лошади, которая периодически умудрялась решать математические задачи. В результате Оскар Пфунгст обнаружил, что лошадь реагировала на непроизвольные микродвижения своего хозяина. В своей области я как-то раз столкнулся с плавающим багом, который возникал, когда солнце проникало через мое окно и падало на оптический сенсор моей мыши. Погодные условия никак не должны были повлиять на ввод данных в приложение – однако влияли. Более распространенный пример странного поведения – баги, возникающие, когда вы используете клавиатуру, а не мышь, чтобы отдать какую-либо команду. Случайный ввод может быть невидимым глазу без специальных инструментов и рекордеров. Например, два идентичных текста в RFT-формате, один из которых сохранен через Word, а другой через Wordpad, выглядят очень похоже, но совсем не идентичны.
  • Секретные границы и условия. Программа может вести себя иначе из-за скрытых границ или областей падения, которые никем не задокументированы и которых вы не ожидаете, выстраивая свою ментальную модель продукта. Как-то раз я тестировал поиск, который вел себя совершенно иначе, если количество найденных записей равнялось тысяче или пятидесяти тысячам. Я обнаружил эти скрытые границы совершенно случайно.
  • Другой профиль использования. Использование приложений некоторыми пользователями может чем-то специфически отличаться. Их предположения насчет ввода ведут к другим результатам вывода. Пользователи с определенным опытом – например, программисты – могут систематически замечать (или не замечать) определенные типы поведения приложения.
  • Призрачный ввод. Источником ввода может быть не пользователь, а машина. Такой ввод часто незаметен пользователю, и включает вариации из-за разных файлов, различные сигналы от периферийных устройств, или данные, поступающие по сети.
  • DeusExMachina. Кто-то еще взаимодействует с продуктом в то же самое время, что и пользователь – другой тестировщик, другой пользователь, хакер.
  • Дефектный ввод. Данные могли быть повреждены или перехвачены на пути к системе. Особенно это касается клиент-серверных приложений.
  • Время в качестве вводных данных. Плавающие баги могут зависеть и от времени как такового. Время всегда меняется вне зависимости от того, удалось ли вам проконтролировать и зафиксировать все остальное. Когда время и дата, или временные интервалы, используются в качестве данных, баги могут проявляться только в определенное время.
  • Временная лотерея. Вариации ввода, которые обычно не имеют значения, могут внезапно стать критическими в определенное время или при определенной нагрузке. От этой проблемы страдал Mars Rover – окно уязвимости в три миллисекунды, когда операция записи могла писать в защищенную часть памяти.
  • Комбинационная лотерея. Вариации ввода, которые обычно не имеют значения, могут вызвать проблему, если они скомбинированы определенным образом.

Вероятная причина номер 5. Прочие причины связаны с тем, что ваша ментальная модель системы и того, что на нее влияет, неверна или неполна.

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

Программа при релизе не работает, а при дебаге работает


16.06.2013, 03:02

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

Почему вылетает программа при 32768, а при 20 все работает нормально?
Помогите исправить, почему программа вылетает при больших числах, а если поставить маленькие то все.

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

Ловим баги или почему программы допускают "недопустимые операции"

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

Но помимо чисто железных проблем — большую головную боль могут вызвать ошибки в работе программного обеспечения. Особенно это касается непосредственно операционной системы. Зачастую Windows терпит крах спонтанно. Вот рекомендации которые помогут вам создать более устойчивую среду программирования:
Хотя Windows 9X популярная система, разработку лучше проводить в Windows NT или Windows 2000 — это более устойчивые операционные системы. Естественно при переходе на них придется отказаться от некоторых благ семейства Windows 95/98/Me — в частности не все программы адоптированы для Windows NT/2000. Зато вы получите более надежную и стабильную систему.
Не забывайте о том, как важно всегда иметь под рукой свежие версии компонентов для Delphi и дополнительных библиотек. В отличие от Windows создатели данных пакетов стараются от версии к версии уменьшать количество ошибок.
Следите за тем, что бы устанавливаемые компоненты были предназначены непосредственно для вашей версии Delphi. Попробуйте деинсталлировать чужеродные компоненты один за другим (или пакет за пакетом) пока проблема не будет устранена.
Контролируйте все программные продукты установленные на вашей машине и деинсталлируйте те из них, которые сбоят. Фаворитами AV среди них являются шароварные утилиты и программы и бета версии программных продуктов.
Все вышеперечисленное в основном не касалось самого процесса программирования и в малой степени зависит от разработчика. Теперь же обратимся к теме, как не допустить при разработки программного продукта ситуации при которой, он сам будет являться причиной ошибки.
Вы могли бы рассмотреть компилирование вашего приложения с директивой <$D>, данная директива компилятора может создавать файлы карты (файлы с расширением map, которые можно найти в том же каталоге, что и файлы проекта), которые могут послужить большой справкой в локализации источника подобных ошибок. Для лучшего «контроля» за своим приложением, компилируйте его с директивой <$D>. Таким образом, вы заставите Delphi генерировать информацию для отладки, которая может послужить подспорьем при выявление возникающих ошибок.
Следующая позиция в Project Options — Linker & Compiler позволяет вам, определить все для последующей отладки. Лучше всего, если помимо самого выполняемого кода будет доступна и отладочная информация — это поможет при поиске ошибок. Отладочная информация увеличивает размер файла и занимает дополнительную память при компилировании программ, но непосредственно на размер или быстродействие выполняемой программы не влияет. Включение опций отладочной информации и файла карты дают детальную информацию только, если вы компилируете программу с директивой <$D+>.
Эта информация состоит из таблицы номеров строк для каждой процедуры, которая отображает адреса объектных кодов в номера строк исходного текста. Директива $D обычно используется совместно с другой директивой — $L, что позволяет или запрещает генерацию информации о локальных символах для отладки.
Таким образом вы без труда сможете найти точный адрес той подпрограммы, которая была ответственна за ошибку. Одна из наиболее общих причин ошибок выполнения — использование объекта, который еще не был создан. Если второй адрес при выдачи ошибки — FFFFFFF (или 0000000) Вы можете почти утверждать, что было обращение к объекту, который еще не был создан. Например, вызов метода формы, которая не была создана.
Попытаемся разобратся в этой ситуации. Предположим, что BadForm есть в списке «Available forms » в окне Project Options|Forms. В этом списке находятся формы, которые должны быть созданы и уничтожены вручную. В коде выше происходит вызов метода Refresh формы BadForm, что вызывает нарушение доступа, так как форма еще не была создана, т.е. для объекта формы не было выделено памяти. Если вы установите «Stop on Delphi Exceptions » в Language Exceptions tab в окне Debugger Options, возможно возникновения сообщение об ошибке, которое покажет, что произошло ошибка типа EACCESSVIOLATION. EACCESSVIOLATION — класс исключение для недопустимых ошибок доступа к памяти. Вы будете видеть это сообщение при разработке вашего приложения, т.е. при работе приложения, которое было запущено из среды Delphi. Следующее окно сообщения будет видеть пользователь — и программа будет закрыта при совершение недопустимой операции: Первое шестнадцатиричное число (‘0043F193’) — адрес ошибки во время выполнения программы в программе. Выберите, опцию меню ‘Search|Find Error’, введите адрес, в котором произошла ошибка (‘0043F193’) в диалоге и нажмите OK. Теперь Delphi перетранслирует ваш проект и покажет вам, строку исходного текста, где произошла ошибка во время выполнения программы, то есть BadForm.Refresh. Естественно, что списка наиболее общих причин ошибок, вызывающих аварийное завершение работы программы, написанной в Delphi в чистом виде нет. Есть несколько общих «узких мест» в коде и структуре программы, когда подобная ошибка может произойти. Перечислим наиболее распространенные.

Недопустимый параметр API

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

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

Программы для фильтрации баннеров, всплывающих окон, Flash и прочих «интернет-неудобств»

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

реклама

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

реклама

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

  • Принимать все всплывающие окна.
  • Блокировать все всплывающие окна.
  • Открывать всплывающие окна в фоновом режиме.
  • Открывать только запрошенные или Блокировать нежелательные всплывающие окна.

реклама

Существует очень много различных браузеров, использующих для работы движок Internet Explorer и фактически являющихся надстройкой над ним. Из них можно выделить две разработки, отличающиеся наибольшей функциональностью, полной русификацией, признанием пользователей и при этом являющихся полностью бесплатными. Так, Avant Browser очень прост и интуитивно понятен в использовании (особенно для имевших дело с браузером Opera, т.к. разрабатывался по его образу и подобию) и обладает широкими и эффективными средствами блокировки и фильтрации:

  • Возможность запрета Flash-анимации в одно нажатие мышью.
  • Функция блокировки нежелательных всплывающих окон с широкими возможностями настройки:
    • включение и отключение «в один клик»;
    • возможность выбора режима открытия (поверх всех окон / в фоновом режиме);
    • наличие «черного списка» и списка исключений;
    • возможность воспроизведения произвольного звука при блокировании всплывающего окна.
  • Блокировщик рекламы с возможностью настройки, указания списка исключений и функцией замены блокированных баннеров на картинки с уведомлением.
  • Возможность просмотр списка блокированных адресов.

реклама

Второй заслуживающий внимания браузер на ядре Internet Explorer — адаптированная русская версия бесплатного MYiE2RU, являющегося одним из самых популярных браузеров в нашей стране. Открытая архитектура и модульный принцип делают его чрезвычайно подверженным настройке и модификации. Возможности фильтрации нежелательной рекламы и всплывающих окон во многом соответствуют таковым в Avant Browser и, по заявлению разработчиков MYiE2RU, принцип реализации был заимствован именно из последнего:

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

реклама

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

Еще один простой, доступный и интересный вариант «убить рекламу» — использование брандмауэра Outpost Firewall, имеющего стандартные подключаемые модули для фильтрации рекламы и интерактивных элементов, которые позволяют с успехом выполнять ряд интересующих нас задач, в частности:

  • Фильтровать рекламные баннеры и заменять их текстом или прозрачным фоном:
    • по предустановленному списку, пользовательскому списку и списку исключений;
    • по размеру в пикселах.
  • Блокировать интерактивные элементы (в том числе Flash и всплывающие окна) полностью или по выбору пользователя.

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

  • Outpost Firewall Pro 2.1.303.314 (7,8 МБ, Windows 98/ME/NT/2000/XP).
  • Домашняя страница .

Одним же из наиболее универсальных и эффективных методов борьбы с интернет-рекламой, всплывающими окнами и множеством прочих неприятных «назойливостей» является использование специализированных программ. Пожалуй, наиболее удобным и мощным средством является небольшая утилита AD Muncher. Программа «селится» в системном трее и фильтрует весь трафик для всех приложений, т.е. не только для запущенных браузеров, но и для прочих программ, содержащих рекламные баннеры, например, ICQ, Morpheus, Kazaa, Opera, Bearshare, LimeWire. Список возможностей огромен:

  • Большой стандартный список отображающих рекламу серверов и мощные возможности его тонкой настройки для фильтрации/блокировки новых баннеров, а также нежелательных материалов нерекламного характера и необычных способов рекламы.
  • Блокирование всплывающих окон, появляющихся через одинаковые интервалы времени, по загрузке и уходу с сайта; отображение списка блокированных окон.
  • Возможность удаления:
    • фоновых рисунков, звуковых файлов;
    • команд, исполняющихся при уходе со страницы;
    • кода, вмешивающегося в использование мышки;
    • модификаций строки состояния на странице;
    • команд фокусировки страниц, открывающие соответствующую страницу поверх других;
    • автоматического обновления страниц по таймеру;
    • и многих других элементов.
  • Возможность включения/отключения фильтрации отдельно для каждого приложения.
  • Очень удобная функция замены блокированных баннеров на их подпись из тега «ALT».
  • И множество других вспомогательных и направленных на сохранение конфиденциальности функций.

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

  • Ad Muncher 4.51a (156 КБ, Windows 9x/ME/NT4/2000/XP/2003).
  • Домашняя страница.

В противовес распространяемому на коммерческой основе Ad Muncher можно привести бесплатную альтернативу, реализованную в виде прокси-сервера — Proxomitron Naoko. К сожалению, развитие программы приостановлено, но, тем не менее, она до сих пор является одним из самых эффективных, гибко настраиваемых и мощных средств фильтрации интернет-трафика, требующего однако, углубленного изучения способов применения и настроек. Из интересующих нас возможностей программа предлагает:

  • Отключать или ограничивать загрузку всплывающих окон, блокировать появление окон подтверждения.
  • «Убивать» большинство рекламных баннеров и счетчиков посещаемости.
  • Останавливать бегущий текст в строке статуса / показывать в ней реальный адрес.
  • Убирать или изменять выбранные Java скрипты или апплеты, фоновые рисунки.
  • Блокировать логотипы, скрипты, авто-обновление страниц, музыку и звуки.
  • Удалять динамический HTML, фреймы или таблицы.
  • А также многое другое.

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

  • Proxomitron Naoko 4.5 (1,56 МБ, Windows 9x/ME/NT/2000/XP) — c русификатором и русской справкой.
  • Домашняя страница.

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

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

Обсудить методы и средства можно в специальной ветке нашей конференции.

Почему компьютерный сбой называют *БАГ*?

В самом первом переводе bug — это «насекомое» , конкретнее — клоп. Во втором, известном по шпионским фильмам — «жучок» , малоформатное подслушивающее устройство. Есть ещё с десяток оттенков этого великолепного по краткости слова, но «прописку» в русском получило одно: дефект, присущий чему-то техническому или программному изначально. Таким образом, баг — это не то, что ломается по прошествии времени в силу износа, а то, что обнаруживает себя спустя какое-то время. Обнаруживает самым прискорбным образом: внезапно портит игру, прогу, комп, связь, наладку, проверку… всё, что угодно.

в «Неакадемическом словаре языкового уплотнения» — “Bug — баг”
История его такова. Затрудняюсь сказать, где именно это было, хотя история эта реальна и имеет точный «географический» адрес, но где-то в США, ещё в 50-е годы ХХ века, в одном из первых вычислительных центров постоянно случались неполадки в компьютере. Тогдашние компьютеры были собраны на электромагнитных реле и радиолампах, занимали гигантские помещения, снабжались электроэнергией от отдельных подстанций, и их работу обеспечивала целая команда техников, лаборантов и программистов (потому что операционных систем как таковых в те времена не существовало) .
Неполадки были для этих мастодонтов самым обычным делом. И вот команда техников, разыскивая источник очередного сбоя, наткнулась на… личинку моли, той самой, что портит шерстяные вещи. Она забилась между контактами реле, и контакты перестали замыкаться. Техники вынули раздавленное и прилипшее к контактам насекомое, почистили контакты, и сделали соответствующую запись в рабочем журнале дежурства. Будучи людьми не без юмора, в графу «причина неисправности» они записали “Bug found” («найден жучок») , а в графу «предпринятые действия» записали “Debugging performed” (буквально «произведено обезжучивание») . И, хмыкнув, вернулись в главное помещение коротать время до следующей неисправности. Потом появился кто-то из начальства, проверил журнал… и через несколько минут хихикал весь вычислительный центр. Шутка быстро разошлась, поскольку в те времена все, кто имел касательство к компьютерам, являли собой как бы касту жрецов научно-технического прогресса и были друг с другом знакомы, так что словечко вошло в обиход моментально.
Впоследствии техническая сторона дела существенно изменилась, и системы стали на много порядков более надёжными, но на смену живым жучкам пришли программные ошибки, ещё более неуловимые, которые и стали теперь именоваться этим термином. В этом смысле, по существу, баг — это не дефект, это — всегда результат чьей-то недоработки, приводящей к неверной работе или вообще к сбою программы.

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

В действительности этот случай произошёл 9 сентября 1947, а не 1945, года. Слово «bug» в современном значении употреблялось задолго до этого. Так, в течение Второй мировой войны словом «bugs» назывались проблемы с радарной электроникой.

Основы тестирования. Как правильно составить баг-репорты

Зачем нужен хороший баг-репорт?

Если ваш отчет об ошибках (баг-репорт) составлен правильно, то шансы на быстрое исправление этих багов — выше. Таким образом, исправление ошибки зависит от того, насколько качественно вы о ней сообщите. Составление отчетов об ошибках — не что иное, как навык, и сейчас мы рассмотрим, как его сформировать.

«Смысл написания отчета о проблемах (баг-репорта) состоит в том, чтобы исправить эти проблемы» — Cem Kaner. Если тестировщик не сообщает об ошибке правильно, программист, скорее всего, отклонит эту ошибку, заявив, что она невоспроизводима.

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

Каковы качества хорошего баг-репорта в разработке программного обеспечения?

Любой может написать баг-репорт. Но не каждый может написать эффективный бар-репорт.

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


Характеристики и методы включают в себя:

1) Наличие четко определенного номера ошибки:

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

2) Воспроизводимость:

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

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

3) Будьте конкретны:

Не пишите очерк о проблеме.

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

Эффективный баг-репортинг

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

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

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

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

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

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

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

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

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

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

Как сообщить об ошибке?

Используйте следующий простой шаблон баг-репорта:

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

Составитель отчета: Ваше имя и адрес электронной почты.

Продукт: В каком продукте вы нашли эту ошибку.

Версия: Версия продукта с ошибкой, если таковая имеется.

Компонент: Основные подмодули продукта.

Платформа:

Укажите аппаратную платформу, на которой вы обнаружили эту ошибку. Различные платформы, такие как «ПК», «MAC», «HP», «Sun» и т. д.

Операционная система:

Укажите все операционные системы, в которых вы обнаружили ошибку. Операционные системы, такие как Windows, Linux, Unix, SunOS, Mac OS. Упомяните разные версии ОС, такие как Windows NT, Windows 2000, Windows XP и т. д., если это применимо.

Приоритет:

Когда следует исправлять ошибку? Приоритет обычно устанавливается от P1 до P5. P1 следует понимать, как «исправить ошибку с наивысшим приоритетом» и P5 — «исправить, если позволяет время».


Серьезность ошибки:

Описывает влияние ошибки.

Типы Серьезности ошибки:

  • Блокировщик (Blocker): дальнейшая работа по тестированию невозможна.
  • Критическая (Critical): сбой приложения, потеря данных.
  • Major: серьезная потеря функциональности.
  • Minor: незначительная потеря функциональности.
  • Незначительная (Trivial): некоторые улучшения пользовательского интерфейса.
  • Улучшение (Enhancement): запрос новой функции или некоторого улучшения существующей.

Статус ошибки:

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

Позднее ошибка проходит через различные этапы, такие как «Исправлено», «Проверено», «Повторно открыто», «Не исправлено» и т. д.

Назначить разработчику:

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

URL:

URL страницы, на которой произошла ошибка.

Краткое резюме:

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

Описание:

Подробное описание ошибки.

Используйте следующие поля для поля описания:

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

Это важные шаги в отчете об ошибках. Вы также можете добавить «Тип отчета» как еще одно поле, которое будет описывать тип ошибки.

Типы отчетов включают в себя:

1) Ошибка в коде
2) Ошибка проектирования
3) Новое предложение
4) Проблема с документацией
5) Аппаратная проблема

Важные фичи в вашем отчете об ошибках

Рассмотрим несколько составляющих отчета о найденном баге

Ниже приведены важные элементы баг-репорта:

1) Номер ошибки/идентификатор:

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

2) Наименование ошибки:

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

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

3) Приоритет:

В зависимости от серьезности ошибки, для нее может быть установлен приоритет. Ошибка может быть Blocker, Critical, Major, Minor, Trivial или предложением по улучшению функционала. Приоритет ошибки от P1 до P5 может быть задан так, чтобы важные из них просматривались первыми.

4) Платформа / Среда:


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

5) Описание:

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

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

6) Шаги для воспроизведения ошибки:

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

Хороший пример правильно написанной пошаговой процедуры приведен ниже:

Последовательность шагов:

  • Выберите продукт wer05.
  • Нажмите на «Добавить в корзину».
  • Нажмите «Удалить», чтобы удалить продукт из корзины.

7) Ожидаемый и фактический результат:

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

8) Скриншот:

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

Некоторые дополнительные советы, для написания хорошего баг-репорта

Ниже приведены некоторые дополнительные советы, чтобы написать хороший отчет об ошибке:

1) Немедленно сообщите о проблеме:

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

2) Воспроизведите ошибку три раза перед написанием баг-репорта:

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

3) Протестируйте эту же ошибку на других похожих модулях:

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

4) Составьте хорошее резюме ошибки:

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

5) Прочитайте несколько раз отчет об ошибке, прежде чем нажать кнопку «Отправить»:

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

6) Не используйте оскорбительные выражения:

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

Заключение.

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

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

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

С нашей стороны для качественной подготовки тестировщиков, предлагаем вам ознакомиться с курсом подготовки специалиста-тестировщика на ITVDN — Quality Assurance

Илон Маск рекомендует:  Что такое код drawpoly
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL