Что такое баг и как с ним бороться? Баг - это что? Что такое баги в игре

14.09.2020

Привет баклан.

Чё, руки чешутся? Сломать вебсервер охота, потому что там до хрена сайтов противоречащих твоей кул-хацкерской идеологии? Не суть. Но для начала надо войти в историю и узнать о багах, местах старых багов. Ведь зная суть этих багов, ты сможешь откапать новые баги...
А это уже угроза, так сказать, сила. В этом одна из идей хакера - ПОИСК.
Ну, с чего б начать то? Ну, во-первых, конечно же, CGI баги.

О них и поговорим. Любимая атака (и самая лёгкая) это атака на подтверждения ввода. Суть атаки том, что кривые программисты написали своё детище так, что CGI сценарий неадекватно реагирует на вводимые в него данные. После чего этот сценарий делает не то, что от него хотел разработчик, а то, что хотел злобный взломщик:). Вот, например в IIS есть уязвимость называемая MDAC
RDS. Компонент RDS (удалённый сервис данных) и есть уязвимый объект в
MDAC. А если быть точнее, то этот компонент RDS Data Factory. Если админ - лошпекус, то он оставил настройки по умолчанию, где разрешено исполнение удалённой команды на сервере IIS. Команда выполняется обычно от пользователя
SYSTEM. Теперь о том, как эту багу юзать. На сайте
www.securityfocus.com есть сценарий на языке Перл, который позволяет послать и исполнить любую команду базе данных - btcustmr.mbr (экспериментальная база данных). Где-то я видел експлойт на Дельфи. Фишка заключается в добавлении к SQL запросу строки " | shell(\"$command\") | " . Обнаружив команду оболочки, MDAC выполнит команду в переменой
$command. Да кстати, для любителей посканировать на CGI баги, если вы обнаружите библиотеку "msadc.dll", значит вполне вероятно, что система уязвима.

Не отходя далеко от IIS, следующий баг, обнаруженный известной группой
eEye: В Microsoft IIS 4.0 хреновая проверка в именах файлов.IDC .HTR и.STM. Как юзать Баг???
Хе... пошлю я тебя на... на www.technotronic.com , там ищи прогу под эротичным
названием -Iishack. Все что надо указать это - адрес жертвы, адрес, где лежит твоя прога + путь к проге...
Большинство взломщиков, таким образом, закачивают на испытуемый сервак другую прогу:
Getem.exe. Это Троян, который распаковывает pwdump.exe и запускает
netcat. Pwdump - выводит дамп SAM, а неткат открывает 25 порт и даёт через него доступ к
cmd.exe. То есть сначала ты коннектишься к 25 порту, а затем запускаешь pwdump и смотришь зашифрованные пароли, которые можно протестить L0pht crack"ом, который попробует перебрать пароли.

Далее я расскажу про неправильное использование скрытых тегов. Читал я в одной
книжке, что некоторые магазины используют скрытые теги для присваивания цены товару!
Поясняю: input type=hidden, а value="123". А что тебе помешает поменять value??? Правильно
- совесть! Введи в поисковик (Altavista) "type=hidden
name=price"-а дальше только удача:). Ту я описал лишь два с половиной бага, известных бага. Как искать эти баги? Три пути.
Либо пойти в поисковик и ввести там что-то типа: "url: "_vti_bin" " а далее тупо перебирать выведенные сайты на iis unicode. Второй путь: есть сайт, который надо наказать, бери сканер
и скань на наличие багов, к слову есть хороший CGI сканер на
www.xp-team.com с описаниями от
www.gingroup.ru и небольшой базой експлойтов. Третий путь, путь истинных хакеров, это путь исследования, попытайся переполнить буфер запроса... короче попытайся применить все известные баги. Но будь разумен... не надо пытаться выполнить iis unicode под Apache, ну ты меня понял:).

Всё, я пошёл, мне пора пнуть кота... тьфу ты... у меня ж нет кота... ну пну
ещё кого-нить. Удачного пин...то есть хака, твой Дон Хуан.

Вы уже освоили основные техники тест-дизайна? Отлично! Значит, Вы – квалифицированный тестировщик.

Как научиться находить баги, которые не находят другие тестировщики, несмотря на то, что они знают те же самые техники?

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

Разумеется, техники надо знать. Но для осмысленного, а тем более творческого их применения требуется ещё кое-что:

Нужны дополнительные профессиональные навыки.

Этот тренинг нацелен на формирование у тестировщика специальных навыков:

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

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

Откуда берутся пропущенные баги, которые тестировщик “не заметил”? Почему не заметил? Техники не виноваты. В них ничего не говорится о том, как надо проверять результат. Просто не хватило наблюдательности.

Почему в продуктив попадают баги, для которых тестировщик “не придумал” подходящего теста? Техники не виноваты. Просто неверно выбрана модель или техника применялась не там и не так.

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

Но там не написано главного – как понять, что вы нашли баг? Как его узнать? Как понять, правильно или неправильно работает программа? Говоря “профессиональным” языком – тема оракулов не раскрыта.

Наконец, как понять, правильно или неправильно вы применяете ту или иную технику? Тема оценки полноты покрытия не раскрыта тоже.

На этом тренинге мы будем учиться:

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

Кроме того, мы освоим профессиональную работу с уже обнаруженными багами:

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

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

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

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

После него вы вернётесь на своё рабочее место “намагниченным” и “заряженным” на поиск багов. И они это почувствуют, не сомневайтесь:)

Программа тренинга

День первый

1. Подготовка инфраструктуры, знакомство – 30 минут

2. Тестирование учебной программы (упражнение и разбор), обсуждение на тему «Что важнее – техники или навыки?» – 60+15 минут

3. Тестирование новой программы, искусство задавания вопросов (упражнение и разбор) – 60 минут

4. Что делать, когда ты нашел баг? Глобализация и локализация (демонстрация и обсуждение) – 45 минут

5. Искусство описания багов (упражнение и разбор) – 60 минут

6. Регрессионное тестирование и перепроверка багов – как и зачем много раз выполнять одни и те же тесты? – 45 минут

7. Моделирование: умение смотреть на программу под разными углами (упражнение и разбор) – 45 минут

8. Тестирование юзабилити: поселите у себя в голове персонажей (упражнение) – 30 минут

День второй

1. Стратегия тестирования (обсуждение) – 45 минут

2. Сравнение двух программ: какая лучше? (упражнение и обсуждение) – 60 минут

3. HICCUPPSF: эвристики построения оракулов (демонстрация, упражнение и разбор) – 15+60 минут

4. Построение тестов для сложной функциональности (упражнение и разбор) – 60 минут

5. Тест-кейсы, чеклисты, тестирование методом свободного поиска – в каком соотношении смешивать? (обсуждение) – 30 минут

6. Тестирование методом свободного поиска (упражнение и разбор) – 60 минут

7. Регрессионное тестирование и перепроверка багов – как и зачем много раз выполнять одни и те же тесты? (обсуждение) – 30 минут

8. Автоматизация тестирования (демонстрация и обсуждение) – 45 минут

9. Завершение курса, подведение итогов – 30 минут

В этом тренинге по согласованию с Майклом Болтоном используется методика и упражнения из всемирно известного тренинга Rapid Software Testing. Для подготовки к тренингу тренер Алексей Баранцев трижды провел совместные с Майклом тренинги в качестве ассистента и второго тренера.

Как найти баг в коде

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

Зачем

Очень много времени в верстке уходит на решение багов, и поиски их причин. Если вы чувствуете, что можете потратить более 20 минут на поиски причины - лучше смело использовать этот метод, он редко отнимает более 5-10 минут. Впрочем, менее 5 минут, он тоже редко отнимает. И это его единственный недостаток.

Когда

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

Идея

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

Принцип очень простой, чтобы найти, например, точку на отрезке:

Делим отрезок пополам, определяем в какой половине содержится наша точка
Повторяем процедуру для полученной половины отрезка с точкой

И так, пока не получим нужную точность.

А так это выглядит в задаче про поимку льва в пустыне:

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

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

>Суперпупермегаалгоритм

Удаляем половину или просто большой кусок HTML (CSS)
- Если глюк остался виден, продолжаем процедуру для оставшегося кода
- Если глюк исчез, возвращаем удалённый код и повторяем процедуру для него (удалив другую половину)

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

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

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

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

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

В конце

Даже странно почему об этом способе так мало написано(может потому что это слишком просто?). Надеюсь кому-то он поможет, меня не раз и не два выручал. Вдобавок, такие действия помогают начинающим веб-мастеру лучше разобраться и прочувствовать как работает этот CSS. =) А при поиске глюка в чужом коде - это практически единственный путь.

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

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

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

Опыт оказался весьма позитивным, как для проекта, так и для тестировщиков. Для тестирования использовалось 2 сценария, оно проходило в выходные, и в понедельник я уже имел 84 бага (3 категории A, 15 - B, 62 - С и 4 - D), оформленных согласно требованиям. После исправления всех этих багов продукт был зарелизен.

Кстати, когда оформлял задание для фрилансеров, не смог найти в интернете подходящее описание категорий ошибок, поэтому составил сам. Возможно, кому-то оно будет полезно:

Категория А (I). Наличие ошибок данной категории блокирует для пользователя доступ к основной функциональности продукта. Это могут быть ошибки связанные с регистрацией, авторизацией и / или ошибки, возникновение которых не дает пользователю продвинуться дальше по курсу независимо от его текущего состояния.
Категория B (II). Ограничивают доступ к некоторой функциональности, не влияющей на завершение прохождения продукта или не дают пользователю продвинуться по курсу, в зависимости от предыдущих предпринятых им шагов, заставляя его начать какую-то часть курса проходить заново.
Категория C (III). Ошибки данной категории напрямую не влияют на процесс использования продукта, но ухудшают целостность его восприятия или впечатления от процесса. Сюда входят ошибки верстки, неверное отображение и расположение графических элементов, замедленная реакция контроллов и т.п.
Категория D (IV). Ошибки этой категории по сути не являются ошибками. Категория введена для того, чтобы ошибке можно было присвоить ее, в случае, если она связана с функциональностью, визуализацией и прочими свойствами продукта, представление о реализации которых у тестера отличается от того, что предполагалось реализовать.

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

Спасибо за внимание!

Описав методику систематического поиска багов по Джеймсу Уиттакеру (James A. Whittaker)

Методика туров

Приложение - незнакомый город.
Тестировщик - турист.

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

Как пользоваться методикой

Выбрать тур из списка ниже.
Изучить его цели.
Поставить таймер на 2 часа (час, полчаса).
Провести исследование системы строго по целям тура. Ни на что не отвлекаясь, только “миссия” тура.
При необходимости повторить.

В каждом туре есть описание автора (низкий поклон Джеймсу за разрешение перевода и публикации) в вольном переводе + собственные примеры. Для примеров взят сайт Дадаты - https://dadata.ru .

Отправляемся в путь!

Туры по деловому центру, Tours of the Business District

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

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

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

Туры по историческим районам, Tours Through the Historical District

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

В ПО исторические районы могут быть также слабо соединены, как в Бостоне или сосредоточены в одном месте, как в Кёльне. Исторические районы в ПО представляют собой:

унаследованный код (legacy code);
функции, созданные в предыдущих версиях;
исправления багов.

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

Туры по историческим районам проверяют старую функциональность и исправления ошибок.

Туры по развлекательным районам, Tours Through the Entertainment District

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

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

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

Туры по туристическим районам, Tours Through the Tourist District

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

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

Туры по отельным районам, Tours Through the Hotel District

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

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

Туры по захудалым районам, Tours Through the Seedy District

Это непривлекательные места, о которых расскажет редкий путеводитель. Они полны мошенников и сомнительных личностей, и лучше обходить их стороной. Тем не менее, они привлекают определенный класс туристов.