Сообщений в теме: 13

[bor4eg]

Здравствуйте, уважаемые участники форума

Как выявлять мандельбаги? Вот такой вопрос. Есть ли какие-то практические рекомендации (системные, организационные) по багам, которые возникают редко и четко не воспроизводятся?

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

[checo]

Такой баг в итоге может оказаться 100% воспроизводимым, но сценарий не всегда ясен для тестировщика.
Фиксируйте, сообщайте, отдавайте разработчикам на исследование. Если есть возможность, можно при очередном проявлении бага ничего не трогать и позвать разработчика. Иногда с их видением продукта изнутри всё оказывается гораздо яснее.

[ch_ip]

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

[CVDX]

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

[SALar]

А, забить на мандельбагу и хрен с ней.

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

Как выявлять мандельбаги? Вот такой вопрос. Есть ли какие-то практические рекомендации (системные, организационные) по багам, которые возникают редко и четко не воспроизводятся?

Заранее: Развивать наблюдательность и память.
Если случилось: лечь на диван и подумать как такое вообще могло случиться. Вот вам два примера разбора одной и той же редкой ошибки:

• э-э-э... ищите в панбагоне
• http://blog.shumoos.com/archives/247

[ch_ip]

А, забить на мандельбагу и хрен с ней.

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

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

[CVDX]

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

Боже, как мне объять необъятное?
Боже, как мне убедить кодера, что они нажмут на кнопки и бросят валенки на пульты? ;-)

[notProgrammer]

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

И как вы решили эту проблему? Логи продакшена, шаги воспроизведения настоящих пользователей как-то помогли воспроизвести баг?

[negro]

Есть ли какие-то практические рекомендации (системные, организационные) по багам, которые возникают редко и четко не воспроизводятся?

Очевидно, от Тестировщика требуется создать на мбаг репорт с атрибутом «невоспроизводимый». Если потребуется, специально выделят время и ресурсы для попытки его выявления/устранения. Как правило, это в компетенции только разработчиков, а тестеру – только время зря тратить.

Проект сдаётся Заказчику с доведением до него известных/существующих багов (критичных быть не должно), которые устраняются по ходу сопровождения (рефакторинг/патчи, обновление версий сторонних библиотек, производительное железо, сеть...)

В отношении «забить на мбагу» возникает дилема:
1) может быть когда-нибудь некритичный мбаг потом и обнаружится Заказчиком, но раз не воспроизводится, то ничего не поделаешь (отмазок в данном случае у службы поддержки Разработчика найдётся предостаточно)...
2) если потом мбаг проявится так, что Заказчик/Пользователь из-за него понесёт серьёзные убытки, то Разработчику, вероятно, мало не покажется - наверняка возникнут серьёзные проблемы со штрафными санкциями, с репутацией...
Здесь самое главное – Разработчику грамотно составить договор с Заказчиком на создаваемое/сопровождаемое ПО... но это за рамками данной темы...

Как Тестировщику искать непредсказуемый мбаг, происходящий в случайном месте в неопределённое время вне зависимости от доступных для наблюдения предусловий – это, по-моему, неадекватная сверх-задача... научитесь находить (почти)все баги попроще, может тогда мбаг сам вас найдёт.

[SALar]

В 1940 году в ходе норвежской операции крингсмарине имели значительное количество отказов торпед.
И только через два года:

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

30 января 1942 года командир действовавшей в Атлантике подводной лодки U-94 доложил по радио, что при пробной проверке торпеды он обнаружил в гидростате давление, значительно превышающее атмосферное. (Такой осмотр на борту корабля, как правило, не разрешается.) Главный инспектор торпедного оружия немедленно приказал проверить гидростатические приборы всех торпед, подготовленных для отправки на действующий флот. В результате выявился большой процент негерметичных корпусов гидростатов. Нарушение герметичности наблюдалось в местах прохождения рулевых тяг через сальники в гидростат. Для правильной работы гидростат должен быть герметичным. Его работа основана на принципе уравновешивания давления пружины гидростата и гидростатического давления столба воды. В соответствии с этим проводится установка глубины хода торпеды. Нормальное атмосферное давление в гидростате является предпосылкой для правильного хода торпеды по глубине. При проникновении в гидростат повышенного давления к усилию пружины гидростата прибавляется избыточное давление — и равновесие нарушается. В итоге торпеда идет ниже заданной глубины, причем степень ее переуглубления предусмотреть нельзя. Известно, что внутри подводной лодки, находящейся под водой, неизбежно возникает повышенное давление. Оно является результатом попадания внутрь прочного корпуса сжатого воздуха. При длительном подводном плавании давление в подводной лодке сильно возрастает. Так было найдено объяснение причин отказа торпед в период норвежской операции. Подводные лодки в то время ежедневно находились под водой не менее 20 часов. В лодках повышалось давление, оно нарушало работу негерметичного гидростата и заставляло торпеду идти ниже установленной глубины. Это, по-видимому, и явилось причиной неудачи "U-47" при атаке стоявших на якоре английских транспортов. Двигаясь на глубине, превышавшей заданную, торпеды прошли под транспортами и затонули после прохождения своей дальности хода.

(с) Дёниц Карл "Немецкие подводные лодки во второй мировой войне"


Классический трудноуловимый баг. Причину искали два года. Могли бы и не найти. Интересно, а мистер Фейман своим методом мог бы найти этот баг за полчаса? Возможно, бы и смог.

Почитайте про тренировку на поиск таких багов в "Вы, конечно, шутите, мистер Фейнман!". А уж как Фейман проектировал тест дизайн при тестировании системы перлюстрации - это нечто. Пожалуй эту книгу нужно внести в must read для тестировщиков.

[negro]

Комментарии по тексту:

...имели значительное количество отказов торпед...1942 год...U-94...причину искали два года...

1940 год - нацисты оккупировала Норвегию, использовали её промышленный потенциал. U-47, U-94 - немецкие подводные лодки. Фашисты, используют территорию Норвегии как базу для борьбы с советским флотом и союзными конвоями.

Далее гуру восторженно резюмирует:

...могли бы и не найти...

но нашли...
Потом был 1944 год - активизация фашистких подлодок на Балтике, задача - уничтожение советского флота на этом участке.

Классическое полное затмение разума в выборе иллюстрации.

[CVDX]

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

Как-то была телепередача про эксперименты и испытания в авиастроении. В частности, один инженер в 30-х годах стал исследовать причины пожара самолетов при вынужденной посадке.
Тоже ведь, на первый взгляд, мандельбага.
Как-то он грамотно поставил тестирование и определил, что причина пожара это разрыв бензопровода при ударе о землю и деформации моторной рамы, из-за чего шланг рвался и бензин попадал на раскаленный мотор. Решение - делать бензопровод длиннее, чтобы он был со слабиной и при ударе длина выбиралась, а шланг не рвался.
Аналогичное решение было применено в Советском ракетостроении. В частности, проводка приборов всегда делается с излишней длиной проводов/кабелей, чтобы при вибрациях на старте и в полете ничего не порвалось.

Ps: дошло. пример непатриотичен. ясно.
Хм. Если у врага есть чему поучиться, надо учиться. Значит, таки затмение у вас ;-)

[stupid]

Классическое полное затмение разума в выборе иллюстрации.

А еще надо все BMW уничтожить, ведь они делали моторы для самолетов во время войны.

[negro]

...ещё надо...

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