Обнаружение мандельбагов
#1
Отправлено 12 сентября 2012 - 06:56
Как выявлять мандельбаги? Вот такой вопрос. Есть ли какие-то практические рекомендации (системные, организационные) по багам, которые возникают редко и четко не воспроизводятся?
Вот такой пример: есть список писем, крайне редко он отображается пустым. Вот как нужно построить процесс для обнаружения такого поведения. Понятно, что вопрос резиновый и много не ясного, но прежде всего интересуют подходы к таким багам.
Если у вас уже был подобный опыт, поделитесь, пожалуйста, своими соображениями.
Заранее спасибо!
#2
Отправлено 12 сентября 2012 - 08:38
Фиксируйте, сообщайте, отдавайте разработчикам на исследование. Если есть возможность, можно при очередном проявлении бага ничего не трогать и позвать разработчика. Иногда с их видением продукта изнутри всё оказывается гораздо яснее.
#3
Отправлено 12 сентября 2012 - 18:27
Вероятно, может понадобиться воспроизведение на версии с более высоким уровнем логирования и/или с дебажной версией приложения, которая позволит программистам понять причину возникновения бага. Но тут есть один нюанс: бывают такие хитрые баги, которые перестают воспроизводиться при подключении отладчика и даже при другом уровне логирования (если их причина, например, в race-condition)
SQL для тестировщиков
Тренинги по HP QTP и автоматизации тестирования
Если минарет, значит выше всех (с)
#4
Отправлено 13 сентября 2012 - 14:00
Ибо настоящую мандельбагу хрен воспроизведешь или исправишь, а для борьбы с ненастоящей квалификации всей рати может не хватить. ;-)
#5
Отправлено 13 сентября 2012 - 15:24
Иногда можно, иногда нельзя.А, забить на мандельбагу и хрен с ней.
Вот замечательный совет, отличного спеца:
– В больших системах не бывает маловероятных событий. Все, что может случиться, обязательно случится. Пользователи в России и Австралии обязательно нажмут на нужные кнопки одновременно, если вы этого не предусмотрели.
Заранее: Развивать наблюдательность и память.Как выявлять мандельбаги? Вот такой вопрос. Есть ли какие-то практические рекомендации (системные, организационные) по багам, которые возникают редко и четко не воспроизводятся?
Если случилось: лечь на диван и подумать как такое вообще могло случиться. Вот вам два примера разбора одной и той же редкой ошибки:
- э-э-э... ищите в панбагоне
- http://blog.shumoos.com/archives/247
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#6
Отправлено 13 сентября 2012 - 17:09
Именно. На недавнем проекте мы во время тестирования обнаружили странную ситуацию, которую не смогли потом ни разу воспроизвести. Логи к сожалению, не помогли.Иногда можно, иногда нельзя.
А, забить на мандельбагу и хрен с ней.
Вот замечательный совет, отличного спеца:
– В больших системах не бывает маловероятных событий. Все, что может случиться, обязательно случится. Пользователи в России и Австралии обязательно нажмут на нужные кнопки одновременно, если вы этого не предусмотрели.
Забили, ибо времени было очень мало, а задач много.
В продакшене получили больше сотни таких случаев.
SQL для тестировщиков
Тренинги по HP QTP и автоматизации тестирования
Если минарет, значит выше всех (с)
#7
Отправлено 14 сентября 2012 - 05:56
Боже, как мне объять необъятное?– В больших системах не бывает маловероятных событий. Все, что может случиться, обязательно случится. Пользователи в России и Австралии обязательно нажмут на нужные кнопки одновременно, если вы этого не предусмотрели
Боже, как мне убедить кодера, что они нажмут на кнопки и бросят валенки на пульты? ;-)
#8
Отправлено 14 сентября 2012 - 07:12
И как вы решили эту проблему? Логи продакшена, шаги воспроизведения настоящих пользователей как-то помогли воспроизвести баг?Именно. На недавнем проекте мы во время тестирования обнаружили странную ситуацию, которую не смогли потом ни разу воспроизвести. Логи к сожалению, не помогли.
Забили, ибо времени было очень мало, а задач много.
В продакшене получили больше сотни таких случаев.
- Программист.
У тестировщика всегда чётное количество синяков: если он наступил на грабли - обязан воспроизвести ошибку.
(bash.org)
#9
Отправлено 14 сентября 2012 - 11:25
Есть ли какие-то практические рекомендации (системные, организационные) по багам, которые возникают редко и четко не воспроизводятся?
Очевидно, от Тестировщика требуется создать на мбаг репорт с атрибутом «невоспроизводимый». Если потребуется, специально выделят время и ресурсы для попытки его выявления/устранения. Как правило, это в компетенции только разработчиков, а тестеру – только время зря тратить.
Проект сдаётся Заказчику с доведением до него известных/существующих багов (критичных быть не должно), которые устраняются по ходу сопровождения (рефакторинг/патчи, обновление версий сторонних библиотек, производительное железо, сеть...)
В отношении «забить на мбагу» возникает дилема:
1) может быть когда-нибудь некритичный мбаг потом и обнаружится Заказчиком, но раз не воспроизводится, то ничего не поделаешь (отмазок в данном случае у службы поддержки Разработчика найдётся предостаточно)...
2) если потом мбаг проявится так, что Заказчик/Пользователь из-за него понесёт серьёзные убытки, то Разработчику, вероятно, мало не покажется - наверняка возникнут серьёзные проблемы со штрафными санкциями, с репутацией...
Здесь самое главное – Разработчику грамотно составить договор с Заказчиком на создаваемое/сопровождаемое ПО... но это за рамками данной темы...
Как Тестировщику искать непредсказуемый мбаг, происходящий в случайном месте в неопределённое время вне зависимости от доступных для наблюдения предусловий – это, по-моему, неадекватная сверх-задача... научитесь находить (почти)все баги попроще, может тогда мбаг сам вас найдёт.
#10
Отправлено 14 сентября 2012 - 14:27
И только через два года:
(с) Дёниц Карл "Немецкие подводные лодки во второй мировой войне"Хотя работа комиссии по расследованию причин отказа торпед и следствие, проведенное военным трибуналом, внесли большую ясность в этот вопрос, подлинные причины безрезультатной стрельбы наших подводных лодок в период норвежской операции были выяснены только в феврале 1942 года.
30 января 1942 года командир действовавшей в Атлантике подводной лодки U-94 доложил по радио, что при пробной проверке торпеды он обнаружил в гидростате давление, значительно превышающее атмосферное. (Такой осмотр на борту корабля, как правило, не разрешается.) Главный инспектор торпедного оружия немедленно приказал проверить гидростатические приборы всех торпед, подготовленных для отправки на действующий флот. В результате выявился большой процент негерметичных корпусов гидростатов. Нарушение герметичности наблюдалось в местах прохождения рулевых тяг через сальники в гидростат. Для правильной работы гидростат должен быть герметичным. Его работа основана на принципе уравновешивания давления пружины гидростата и гидростатического давления столба воды. В соответствии с этим проводится установка глубины хода торпеды. Нормальное атмосферное давление в гидростате является предпосылкой для правильного хода торпеды по глубине. При проникновении в гидростат повышенного давления к усилию пружины гидростата прибавляется избыточное давление — и равновесие нарушается. В итоге торпеда идет ниже заданной глубины, причем степень ее переуглубления предусмотреть нельзя. Известно, что внутри подводной лодки, находящейся под водой, неизбежно возникает повышенное давление. Оно является результатом попадания внутрь прочного корпуса сжатого воздуха. При длительном подводном плавании давление в подводной лодке сильно возрастает. Так было найдено объяснение причин отказа торпед в период норвежской операции. Подводные лодки в то время ежедневно находились под водой не менее 20 часов. В лодках повышалось давление, оно нарушало работу негерметичного гидростата и заставляло торпеду идти ниже установленной глубины. Это, по-видимому, и явилось причиной неудачи "U-47" при атаке стоявших на якоре английских транспортов. Двигаясь на глубине, превышавшей заданную, торпеды прошли под транспортами и затонули после прохождения своей дальности хода.
Классический трудноуловимый баг. Причину искали два года. Могли бы и не найти. Интересно, а мистер Фейман своим методом мог бы найти этот баг за полчаса? Возможно, бы и смог.
Почитайте про тренировку на поиск таких багов в "Вы, конечно, шутите, мистер Фейнман!". А уж как Фейман проектировал тест дизайн при тестировании системы перлюстрации - это нечто. Пожалуй эту книгу нужно внести в must read для тестировщиков.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#11
Отправлено 14 сентября 2012 - 19:11
1940 год - нацисты оккупировала Норвегию, использовали её промышленный потенциал. U-47, U-94 - немецкие подводные лодки. Фашисты, используют территорию Норвегии как базу для борьбы с советским флотом и союзными конвоями....имели значительное количество отказов торпед...1942 год...U-94...причину искали два года...
Далее гуру восторженно резюмирует:
но нашли......могли бы и не найти...
Потом был 1944 год - активизация фашистких подлодок на Балтике, задача - уничтожение советского флота на этом участке.
Классическое полное затмение разума в выборе иллюстрации.
#12
Отправлено 16 сентября 2012 - 12:36
Как-то была телепередача про эксперименты и испытания в авиастроении. В частности, один инженер в 30-х годах стал исследовать причины пожара самолетов при вынужденной посадке.
Тоже ведь, на первый взгляд, мандельбага.
Как-то он грамотно поставил тестирование и определил, что причина пожара это разрыв бензопровода при ударе о землю и деформации моторной рамы, из-за чего шланг рвался и бензин попадал на раскаленный мотор. Решение - делать бензопровод длиннее, чтобы он был со слабиной и при ударе длина выбиралась, а шланг не рвался.
Аналогичное решение было применено в Советском ракетостроении. В частности, проводка приборов всегда делается с излишней длиной проводов/кабелей, чтобы при вибрациях на старте и в полете ничего не порвалось.
Ps: дошло. пример непатриотичен. ясно.
Хм. Если у врага есть чему поучиться, надо учиться. Значит, таки затмение у вас ;-)
#13
Отправлено 17 сентября 2012 - 07:11
Классическое полное затмение разума в выборе иллюстрации.
А еще надо все BMW уничтожить, ведь они делали моторы для самолетов во время войны.
#14
Отправлено 17 сентября 2012 - 20:16
чьи-то дедушки и бабушки хорошо питались во время войны... чьи-то хорошо воспитывали своих детей и внуков... большинство учила жизнь... stupid, не перевозбуждайтесь, унитазы уничтожать никто не призывает......ещё надо...
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных