Какие-либо хорошие стратегии контакта с 'не восстанавливаемые' ошибки?
После дополнительных исследований выяснилось, что протоколы и делегаты - правильный путь / Apple предпочитает делать это.
В конечном итоге я использовал этот пример
Обмен данными между контроллерами представления и другими объектами @ iPhone Dev SDK
Работал нормально и позволил мне передать строку и массив вперед и назад между моими взглядами.
Спасибо за вашу помощь.
14 ответов
- Проверьте шаги, использованные для создания ошибки
Часто люди, сообщающие об ошибке, или люди, воспроизводящие ошибку, делают что-то неправильно и не попадают в то же состояние, даже если они думают, что да. Попытайтесь пройти это с отчитывающейся стороной. У меня был пользователь INSIST, что права администратора не отображались правильно. Я попытался воспроизвести ошибку, но не смог. Когда мы прошли через это вместе, выяснилось, что в этом случае он входил в систему как обычный пользователь.
- Проверьте систему / среду, в которой возникла ошибка
Я обнаружил много «невоспроизводимых» ошибок, и только позже обнаружил, что они ВОСПРОИЗВОДИМЫЕ в Mac OS (10.4) с X-версией Safari. И это относится не только к браузерам и рендерингу, это может применяться ко всему; другие приложения, которые в настоящее время выполняются, независимо от того, является ли пользователь RDP или локальным, администратором или пользователем и т. д. Убедитесь, что ваша среда максимально приближена к их среде, прежде чем называть ее невоспроизводимой.
- Соберите снимки экрана и Журналы
После того, как вы убедились, что пользователь все делает правильно и по-прежнему получает ошибку, и что вы делаете именно то, что они делают, и вы НЕ получаете ошибку, пора посмотреть, что вы действительно можете сделать. об этом. Скриншоты и логи важны. Вы хотите точно знать, как это выглядит и что именно происходило в то время.
Возможно, что журналы могут содержать некоторую информацию, которую вы можете воспроизвести в своей системе, и как только вы сможете воспроизвести точный сценарий, возможно, вам удастся скрыть ошибку.
Снимки экрана также помогают в этом, потому что вы можете обнаружить, что «кусок X загружен правильно, но этого не должно быть, потому что он зависит от Y», и это может дать вам подсказку. Даже если пользователь может описать, что делает, снимок экрана может помочь еще больше.
- Соберите пошаговое описание от пользователя
Очень часто винят пользователей и не доверяют ничему, что они говорят ( потому что они называют «пользовательский контроль» «штукой»), но даже если они могут не знать названий того, что видят, они все равно смогут описать некоторые из наблюдаемых действий. Сюда входят некоторые незначительные ошибки, которые могли произойти за несколько минут ДО того, как произошла настоящая ошибка, или, возможно, медлительность в некоторых вещах, которые обычно выполняются быстро. Все эти вещи могут быть подсказками, которые помогут вам сузить, какой аспект вызывает ошибку на их компьютере, а не на вашем.
- Попробуйте альтернативные подходы, чтобы получить ошибку.
Если все остальное не помогает, попробуйте взглянуть на часть кода, которая вызывает проблемы, и, возможно, выполните рефакторинг или используйте обходной путь. Если у вас есть возможность создать сценарий, в котором вы начинаете с уже имеющейся половины информации (надеюсь, в UAT), попросите пользователя попробовать этот подход и посмотреть, возникает ли ошибка по-прежнему. Вам лучше всего создать альтернативные, но похожие подходы, которые позволят осветить ошибку в ином свете, чтобы вы могли лучше ее изучить.
Если у вас есть возможность создать сценарий, в котором вы начинаете с уже имеющейся половины информации (надеюсь, в UAT), попросите пользователя попробовать этот подход и посмотреть, возникает ли ошибка по-прежнему. Вам лучше всего создать альтернативные, но похожие подходы, которые позволят осветить ошибку в ином свете, чтобы вы могли лучше ее изучить. Если у вас есть возможность создать сценарий, в котором вы начинаете с уже имеющейся половины информации (надеюсь, в UAT), попросите пользователя попробовать этот подход и посмотреть, возникает ли ошибка по-прежнему. Вам лучше всего создать альтернативные, но похожие подходы, которые позволят осветить ошибку в ином свете, чтобы вы могли лучше ее изучить.There's a nice new feature in Windows 7 that allows the user to record what they're doing and then send a report - it comes through as a doc with screen-shots of every stage. Hopefully it'll help in the cases where it's the user interacting with the application in an order that the developer wouldn't think of. I've seen plenty of bugs where it's just a case that the developer's logical way of using the app doesn't fit with how end users actually do it... resulting in lots of subtle errors.
If it is not reproduce able get logs, screen shots of exact steps to reproduce.
Иногда ошибка не воспроизводится даже в предварительной среде, которая является точной копией рабочей среды. Проблемы с параллелизмом печально известны этим.
Причина может быть просто в эффекте Гейзенберга, то есть наблюдение меняет поведение. Другая причина может заключаться в том, что вероятность попадания в комбинацию событий, вызывающих ошибку, очень мала.
Иногда вам повезло, и у вас есть журналы аудита, которые вы можете просмотреть, что значительно увеличивает шансы на повторное создание проблемы. Вы также можете создать нагрузку на среду с большим объемом транзакций. Это эффективно сокращает время, так что если ошибка возникает, скажем, раз в неделю, вы можете надежно воспроизвести ее за 1 день, если вы нагружаете систему до 7-кратной производственной нагрузки.
Вы говорите о проблемах, которые воспроизводимы, но только в некоторых системах. С ними легко справиться:
Первый шаг: используя какое-то удаленное программное обеспечение, вы позволяете клиенту указывать вам, что делать, чтобы воспроизвести проблему в системе, в которой оно есть. Если это не удается, закройте его.
Второй шаг: попробуйте воспроизвести проблему в другой системе. Если это не удается, сделайте точную копию системы клиентов.
Третий шаг: Если он все еще не работает, у вас нет другого выбора, кроме как попытаться отладить его в системе клиента.
Как только вы сможете воспроизвести это, вы можете исправить это. Не имеет значения, в какой системе.
Сложная проблема - это действительно невоспроизводимые проблемы, то есть вещи, которые происходят только с перерывами. Для этого мне придется вмешиваться с отчетами, журналами и строгим отношением требований. :)
With a web project I'm developing at the moment I'm doing something very similar to your technique. I'm building a page that I can direct users to in order to collect information such as their browser version and operating system. I'll also be collecting the apps registry info so i can have a look at what they've been doing.
This is a very real problem. I can only speak for web development, but I find users are rarely able to give me the basic information I would need to look into the issue. I suspect it's entirely possible to do something similar with other kinds of development. My plan is to keep working on this system to make it more and more useful.
But my policy is never to close a bug simply because I can't reproduce it, no matter how annoying it may be. And then there's the cases when it's not a bug, but the user has simply gotten confused. Which is a different type of bug I guess, but just as important.
Well, you try your best to reproduce it, and if you can't, you take a long think and consider how such a problem might arise. If you still have no idea, then there's not much you can do about it.
If it happens in one context, and not in another, we try to enumerate the difference between both, and eliminate them.
Sometimes this works (e.g. other hardware, dual core vs. hyperthreading, laptop-disk vs. workstation disk, ...).
Sometimes it doesn't. If it's possible, we may start remote-debugging. If that doesn't help, we may try get our hands on the customer's system.
But of course, we don't write too many bugs in the first place :)
Error-reporting, log files, and stern demands to "Contact me immediately if this happens again."
I add logging to the exception handling code throughout the program. You need a method to collect the logs (users can email it, etc.)
Preemptive checks for code versions and sane environments are a good thing too. With the ease of software updates these days the code and environment the user is running has almost certainly not been tested. It didn't exist when you released your code.
Вам помогут некоторые новые функции Visual Studio 2010. См .:
решено "стерильно" и "жутко"
У нас есть две закрытые категории ошибок для этой ситуации.
стерильные - невозможно воспроизвести.
жуткий - признается, что есть проблема, но она просто периодически появляется, не совсем понятна и дает всем слабый случай появления криков.
Краткий ответ: Провести подробный анализ кода предполагаемого ошибочного кода с целью исправления любых теоретических ошибок и добавления кода для отслеживания и регистрации любых будущих ошибок.
Длинный ответ: Приведем реальный пример из мира встраиваемых систем: мы производим промышленное оборудование, содержащее индивидуальную электронику и встроенное программное обеспечение, работающее на нем.
Заказчик сообщил, что ряд устройств на одном сайте испытывали одну и ту же неисправность в случайные интервалы. Их симптомы были одинаковыми в каждом случае, но они не могли определить очевидную причину.
Очевидно, нашим первым шагом была попытка воспроизвести неисправность в том же устройстве в нашей лаборатории, но мы не смогли этого сделать.
12154] Итак, вместо этого мы разослали предполагаемый ошибочный код внутри отдела, чтобы попытаться получить как можно больше идей и предложений. Затем мы провели ряд встреч по обзору кода, чтобы обсудить эти идеи и определить теорию, которая: (а) объясняет наиболее вероятную причину неисправностей, наблюдаемых в полевых условиях; (б) объяснил, почему мы не смогли воспроизвести его; и (c) привели к улучшениям, которые мы могли внести в код, чтобы предотвратить возникновение сбоя в будущем.
В дополнение к (теоретическим) исправлениям ошибок мы также добавили код мониторинга и ведения журнала, чтобы, если сбой произошел опять же, мы смогли извлечь полезные данные из рассматриваемого устройства.
Насколько мне известно, это улучшенное программное обеспечение было впоследствии развернуто на месте и, похоже, было успешным.
Ведение журнала - ваш друг!
Обычно, когда мы обнаруживаем ошибку, которую не можем воспроизвести, мы либо просим клиента включить дополнительное ведение журнала (если оно доступно), либо мы выпускаем версию с дополнительным журналированием, добавленным вокруг области, которая нас интересует. В целом, ведение журнала у нас отличное и может быть очень подробным, поэтому выпуск версий с дополнительным журналированием происходит нечасто.
Вы также следует рассмотреть возможность использования дампов памяти (которые в IMO также относятся к ведению журнала). Создание мини-дампа происходит так быстро, что его обычно можно сделать на производственных серверах даже под нагрузкой (пока количество создаваемых дампов невелико).
Как я это вижу: возможность воспроизвести проблему - это хорошо потому что это дает вам среду, в которой вы можете отлаживать, экспериментируйте и экспериментируйте более свободно, но - воспроизведение ошибки ни в коем случае не является необходимым для ее отладки ! Если ошибка возникает только в какой-то другой системе, вам все равно необходимо диагностировать и отладить проблему таким же образом, просто на этот раз вам нужно быть более умным в том, как вы это делаете.