Home

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

Оригинал статьи: http://www.satisfice.com/blog/archives/34

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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