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

Автор: Джеймс Бах (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. Прочие причины связаны с тем, что ваша ментальная модель системы и того, что на нее влияет, неверна или неполна.

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

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

Разные значения в дебаге и релизе
В общем в чем суть, пишу игру, участок сетевого кода написан с помощью 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) Ожидаемый и фактический результат:

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

Скриншот:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение.

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

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

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

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

Вам также может быть интересно

Обучение программированию

Эффекты с изображениями

Как сделать — визуальные эффекты изображениям Узнайте, как добавить визуальные эффекты к изображениям. Фильтры

Обучение программированию

Язык xml схемы данных

Понимание XML Узнайте, как Расширяемый язык разметки (Extensible Markup Language — XML) облегчает универсальный

Обучение программированию

Юмор пиво для программиста

ХАЙФХАК: ПРОГРАММИСТ ВЗЛОМАЛ СИСТЕМУ, ЧТОБЫ ПОПИТЬ ПИВО БЕСПЛАТНО / пиво :: geek новости ::

Обучение программированию

Язык обработки данных awk

Примеры команды AWK в Linux Введение AWK назван в честь фамилии его авторов: Альфред

Обучение программированию

Я загружаю timagelist динамически как сделать картинки из timagelist прозрачными

Я загружаю timagelist динамически как сделать картинки из timagelist прозрачными? Элемент управления ImageList содержит

Обучение программированию

Язык преобразований xsl (xslt)

Введение в XSLT XSLT представляет собой способ для XML-документов в другие XML или документы

Обучение программированию

Является ли указанная страница — домашней (IE)

Является ли указанная страница — домашней? (IE) При создании новой вкладки (about:Tabs) в IE9

Обучение программированию

Язык преобразований XSLT

Справочник по интерфейсу администратора Ссылки Назад «> Вверх Вперед Опубликованные SQL View > XSLT

Обучение программированию

Ядро и процессы

Что такое ядро в биологии? Строение и функции ядра В каждой живой клетке протекает

Обучение программированию

Язык программирования alfa

Язык программирования alfa По питанию контроллеры делятся на два типа: с питанием 220 В

Обучение программированию

Язык cc

C++ — Базовый синтаксис Когда мы рассматриваем программу на C ++, ее можно определить

Обучение программированию

Язык рефал

Язык рефал Ура! Сегодня, 30.05.2005, наконец появилась адаптированная к современным платформам Windows-(95/98/ME/NT/2000/XP) и UNIX

Обучение программированию

Эффект pазвивающегося флага

Scrontch’s Flag Designer Design Your Flag! Generates Scalable Vector Graphics (SVG). This App requires

Обучение программированию

Язык sql

SQL-Урок 1. Язык SQL. Основные понятия. Для того, чтобы начать изучать SQL нам нужно

Обучение программированию

Язык с

C++ с нуля Этот самоучитель создан для тех, кто хочет освоить основы программирования на

Обучение программированию

Эффект горящей надписи

Простой огненный текст в Фотошопе Конечный результат: Ресурсы урока: Шаг 1 Создайте новый документ

Обучение программированию

Язык xml documents type definitions (dtd)

Язык XML — практическое введение . Documents Type Definitions (DTD) В XML- документах DTD

Обучение программированию

Языки и грамматики простейший компилятор

ГРАММАТИКА ЯЗЫКОВ ПРОГРАММИРОВАНИЯ Описанию грамматики языка предшествует описание его алфавита. Алфавит любого языка состоит

Обучение программированию

Эффект ледяной надписи

Ледяной текст в Фотошопе Конечный результат: Ресурсы урока: 1. Создание фона Шаг 1 Создайте

Обучение программированию

Язык xml dom совместимые анализаторы

XML-анализаторы в java XML как набор байт в памяти, запись в базе или текстовый

Обучение программированию

Языки описания пользовательских интерфейсов

Языки описания пользовательских интерфейсов Язык описания интерфейсов Язык описания интерфейсов (IDL), используемый OMG определяет

Обучение программированию

Эффект линзы (watcom c)

Эффект линзы (watcom c) Просветляющие покрытия от ZEISS Высококачественные линзы требуют высоколассного подхода: защита,

Обучение программированию

Язык xml xml в microsoft internet explorer 5 0

Основы XML для начинающих пользователей Введение в правильную разметку XML означает Extensible Markup Language,

Обучение программированию

Языки программирования

Языки программирования Язык программирования — искусственный (формальный) язык, предназначенный для записи программ для исполнителя