Что делать с багами, которые невозможно повторить?
#1
Отправлено 18 марта 2005 - 07:51
Пусть модератор меня поправит, если тема попала не на тот форум.
Попробую сформулировать. Предположим, есть некий продукт. Продукт успешно разработан, функциональность протестирована, проведены нагрузочные испытания, документация написана и продукт отправляется к заказчику на тестовое внедрение.
И тут возникает трабл - на стенде продукт отлично работает, делает все, что ему положено, корректно обрабатывает ошибочные ситуации, а вот у заказчика вылазит критичный баг. Ну предположим, Главная Служба Продукта вываливается и ни каким образом не подает признаков - что собственно говоря ей не нравится. Оживить службу не удается.
Заказчик нервничает, инженер "внедренец" шлет гневные письма и требует разобраться. Разработчик говорит, что не может установить причину проблемы, нужно повторить ошибку в условиях стенда и посмотреть подробнее что происходит.
А на стенде ошибка не воспроизводится :-(
А теперь, уважаемые знатоки, вопрос. Что делать в такой ситуации? бороться до последнего и пытаться воспроизвести баг на стенде любой ценой? что делать чтобы такой ситуации не возникало? увеличить объем тестирования продукта в различном окружении?
Или есть другие решения?
хотелось бы услышать ваши предожения или описания подобных ситуаций - может быть вы тоже с ними сталкивались? что вы делали?
#2
Отправлено 18 марта 2005 - 08:24
Есть VMWare. И есть VMWare P2V Assistant. Этот ассистент дает возможность из реальной машины сделать VWMare-ный образ.
Заряжаете клиенту VMWare P2V Assistant, потом у себя разворачиваете эту вирутальную машинку и копаете до тех пор пока не найдете разницу в системе заказчика и своем тестовом стенде.
ИМХО так надо...
#3
Отправлено 18 марта 2005 - 08:39
2. Попытаться сделать у заказчика подобие вашего стенда т.е. инсталировать/деинсталировать все что есть на вашем стенде и какимто образом может влиять на продукт (по коментария програмиста).
3. Переустановить ВСЕ заново (в пределах разумного).
4. Если клиент еще не очень зол B) то может быть позволит програмисту на месте в отладчике посмотреть где ошибка.
Есть такая особенность называется - "Эфект показа". (это когда при покзе все из рук валится и ничего неработает) :)
#4
Отправлено 18 марта 2005 - 08:42
#5
Отправлено 18 марта 2005 - 09:03
делать у заказчика подобие тестового стенда - не есть выход. Внедряться то будет не в условиях стенда, так что рано или поздно продукту придется столкнуться с суровой реальностью.
Немного усложним задачу - предположим, что программера к клиенту привести нельзя. И все общение идет через инженера, внедряющего продукт. Всю информацию, какую только можно, этот инженер предоставит.
Информация есть, а повторить ситуацию не удается. Вполне возможно что, что то не учли - но что именно?
Хороший вариант с логами. Добавить в продукт функцию самодиагностики - пусть создает файл логов, где будет вестись протокол действий - чтобы отследить, на каком этапе ошибка возникла. Но поезд уже ушел. Это скорее замечание на будущее.
Вообще как быть с "парниковым эффектом" - не возможно повторить на стенде все разнообразие ситуаций, с которыми столкнется продукт в реальности. Или все таки можно? Или это и не нужно?
И вообще, есть ли какая то гарантия, что продукт, прошедший тестирование будет хорошо себя вести у заказчика?
#6
Отправлено 18 марта 2005 - 09:23
Просто иногда у какого-нибудь пользователя находится такая конфигурация, что никаким тестерам она и в страшном сне не приснится :) Еще программисты рассказывали про фирменные компьютеры, у которых другие номера прерываний используются. И пока там с дебагером не посидишь, то ничего не поймешь.
#7
Отправлено 18 марта 2005 - 09:30
IMHO, абсолютно все разнообразие реальных ситуаций повторить нельзя, но стремиться к этому нужно, т.е. создавать именно разнообразные ситуации. А насчет гарантии... У нас недавно продукт выходил - все уже протестили - работает, со дня на день будем выкладывать и тут приходит новое обновление на "Окна" с которым он никак не хочет "дружить". Программисты разобрались, неполадку устранили, дело оказалось в изменении какой-то системной структуры данных, но где гарантия, что в одном из следующих обновлений не поменяеться еще чего нибуть.Вообще как быть с "парниковым эффектом" - не возможно повторить на стенде все разнообразие ситуаций, с которыми столкнется продукт в реальности. Или все таки можно? Или это и не нужно?
И вообще, есть ли какая то гарантия, что продукт, прошедший тестирование будет хорошо себя вести у заказчика?
#8
Отправлено 18 марта 2005 - 09:31
Если нет то -
Я имел ввиду, что может быть необходимо что то доинсталить что есть на стенде но по мнению програмиста "скорее всего не должно влиять, но попробывать стоит".cделать у заказчика подобие тестового стенда - не есть выход. Внедряться то будет не в условиях стенда, так что рано или поздно продукту придется столкнуться с суровой реальностью.
И еще - если есть возможность создать второй стенд джля тестирования по характеристика похожий с клиентским. И желательно чтобы его сделал тот кто внедрял (он ведь сможет повторить последовательность своих действий у клиента). :)
#9
Отправлено 18 марта 2005 - 12:24
1. Не компетентен внедренец
2. Не компетентен разработчик
Ответы на вопросы:
1. Проще всего проблему локализовывать методом исключения. Для начала, составляете точную!!! инструкцию по установке системы внедренцу. Предположим, версия продукта на стенде и у заказчика одинаковая, значит его исключаем. Остаётся, предположим, операционка, сервер БД, .NET Framework, сеть, железо и так далее. Разрабатываете проверки, при помощи которых можно определить работоспособность того или иного, и, вперёд, на локализацию. С такими проблемами сам много раз сталкивался в свою бытность внедренцем. В основном, проблемы удавалось решить. Как правило, причина была в сторонных производителях, например железка какая-нибудь кривая или разные версии софта конфликтуют между собой (как пример, были проблемы с Sybase 12.5 и WinXP, а тестировалось под Win2K).
2. В этом есть смысл только после выполнения пункта один, при условии точного повторения конфигурации заказчика.
3. У каждого продукта должны быть определённые системные требования, при выполнении которых поставщик гарантирует стабильную работу продукта у заказчика.
4. Надо уделять побольше времени для конфигурационного тестирования и тестирования инсталляции.
ну и так далее
#10
Отправлено 21 марта 2005 - 10:16
Про варианты удалённого подключения, думаю, рассказывать не надо :)
#11
Отправлено 22 марта 2005 - 09:27
Почему не надо???Ещё одна рекоммендация: подключиться к заказчику удалённо, дабы не тратить деньги на командировки, усадить рядом с собой "автора" и дебажиться.
Про варианты удалённого подключения, думаю, рассказывать не надо :)
Господа, поделИтесь, пожалуйста, чем и как пользуетесь для удаленного подключения.
Заранее спасибо.
#12
Отправлено 22 марта 2005 - 09:40
А сейчас посмотрел на их сайт, и назвали уже по-другому -- RealVNC и денег вроде берут :)
http://www.realvnc.com/download.html
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных