Исследование плавающих багов

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

Если вы способны уверенно справляться с плавающими багами — вы входите в тот процент хороших тестировщиков. Именно самые интересные истории в тестировании ПО связаны с охотой на “белых китов” в океане сложного кода.

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

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

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

  1.  так и задумано
  2.  данное поведение не несет в себе угрозы 

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

Deus ex machina. Разработчик мог специально что-то поменять, а затем октатить изменения. Довольно расспространенное явление, когда над разными частями платформы одновременно работает несколько разработчиков или команд, при этом не координируя свои действия друг с другом. А возможно, это просто модификации приложения хакерами.

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

Изменение платформы. Один из компонентов платформы мог быть заменен или переконфигурирован. Пользователь мог что-то изменить в компоненте, от которого зависит четкая работа продукта. Довольно расспространенный источник таких проблем – автоматические обновления Windows, изменения в конфигурации памяти и дискового пространства.

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

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

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

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

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

Замершее условие. Решение, которое должно основываться на статусе условия, могло перестать проверять это условие, застряв в состоянии «всегда да» или «всегда нет».

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

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

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

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

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

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

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

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

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

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

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

Deus Ex Machina. Кто-то еще работает с продуктом в то же самое время, что и пользователь – другой тестировщик, другой пользователь, хакер.

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

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

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

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

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

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

Записаться сейчас / Бесплатная консультация





Ваше имя (обязательно)

Ваш телефон (обязательно). В формате +375XXXXXXXXX