Причиной начала отладки является обнаружение в процессе работы программы какой-либо ошибки. Отладка может быть начата как в момент обнаружения ошибки, так и позже (например, из-за гипотезы, что в данный момент ошибка проявляется из-за неготовности одного из программных модулей). Процедура отладки в своей наиболее полной форме состоит из следующих шагов:
1. Анализ – поиск информации об ошибке в корпоративных и общедоступных ресурсах (возможно, ваши коллеги уже сталкивались с такой ошибкой?), поиск всех последствий ошибки (может быть, их больше, чем кажется на первый взгляд? может быть, вы наблюдаете последствия нескольких ошибок, случившихся одновременно, или одна из ошибок маскирует другую?), определение типа ошибки, оценка последних изменений, внесенных в проект и являющихся потенциальной причиной ошибки.
2. Проверка воспроизводимости – серия попыток воспроизвести ошибку на другом оборудовании/другой версии прошивки/другом проекте/в других условиях эксплуатации и т.д. В результате вы можете получить новую информацию об ошибке (например, она не воспроизводится на другом аналогичном устройстве – значит, можно выдвинуть гипотезу, что проблема в аппаратной части конкретного прибора), определить набор условий, достаточных для ее воспроизведения, и систематику проявления (например, «воспроизводится при приблизительно каждой десятой перезагрузке ПЛК»). В идеальном случае – после этого пункта вы умеете воспроизводить ошибку со 100% повторяемостью.
3. Локализация ошибки – попытка найти конкретную область, в которой она возникает. На этом этапе следует начать аккуратно вырезать фрагменты проекта ПЛК, отключать службы ОС и т.д. Если после одного из «урезаний» ошибка исчезнет – есть вероятность, что вы нашли фрагмент кода, с которым она связана. С другой стороны, в результате подобных операций ошибка может не исчезнуть, а просто потерять видимые проявления (например, при некорректном доступе к памяти модуль 1 «перезатирал» данные модуля 2, в результате чего происходило деление на 0. После исключения из проекта модуля 2 деления на ноль больше не происходит, но при этом модуль 1 продолжает «перезатирать» чью-то память – просто пока вы не видите внешних проявлений этого). После этого пункта вы должны иметь минимальный набор аппаратных и программных средств, на котором можно воспроизвести проблему – очевидно, что чем меньше устройств входит в состав системы и чем меньше проект – тем проще отлаживать ошибку.
4. Выдвижение и проверка гипотез о возможных причинах ошибки – в результате одной из них ошибка должна быть обнаружена и устранена. В сложных случаях условия и результаты каждого такого теста должны документироваться и сохраняться (иначе в какой-то момент вы забудете, какие гипотезы уже проверили, а какие нет).
5. Проверка устранения ошибки – вы возвращаетесь к п. 2 и проверяете, что ошибка перестала воспроизводиться в рамках всей системы (со всем подключенным оборудованием, с исходным проектом и т.д.).
6. Проверка других фрагментов ПО, в которых может быть допущена эта ошибка (например, если ошибка связана с присвоением некорректных аргументов при вызове функции – то следует проверить все остальные вызовы этой функции на предмет корректности аргументов). 7. Фиксация результатов (добавление информации в корпоративный баг-трекер или wiki, доработка корпоративных стандартов разработки ПО, передача информации коллегам и т.д.) В зависимости от конкретной ошибки, часть шагов может быть пропущена (например, опытный инженер может сразу понять наиболее вероятную причину конкретной ошибки по особенностям ее проявления и сразу перейти к отработке этой гипотезы). В некоторых ситуациях самостоятельно провести отладку не получится и вам потребуется прибегнуть к помощи коллег или других людей (например, сотрудников техподдержки производителя вашего оборудования). В этом нет ничего постыдного – но вы должны с уважением относиться к их времени и заранее предоставить максимальное количество информации:
• перед обращением за помощью соберите стенд, на котором удается воспроизвести ошибку, и убедитесь, что владеете всей информацией о нем (включая версии прошивок и проектов, серийные номера и даты изготовления приборов и т.д.);
• вы должны суметь четко сформулировать описание ошибки (и почему считаете, что наблюдаемая ситуация является ошибкой) и какие действия приводят к ее возникновению. Не забывайте, что человек, к которому вы обращаетесь, может быть не в курсе всех нюансов системы и проектов, которые вы изучаете уже на протяжении нескольких дней или даже недель (в этот момент они становятся вам настолько родными, что уже сложно представить, как кто-то не может по паре фраз понять, что вы вообще имеете в виду) и ему требуется полное и детализированное описание ситуации с указанием всех фактов, которые вам известны. E-mail с одной-двумя фразами типа «иногда крашится программа при старте ПЛК помогите пожалуйста», вероятно, получит самый низкий приоритет и будет рассматриваться только после решения проблем людей, которые более четко и подробно описали свою проблему;
• перед обращением за помощью вы уже должны выдвинуть и отработать некоторые гипотезы и суметь четко рассказать о ваших опытах и их результатах. Вам не следует обижаться, если ваш собеседник попросит повторить всё тоже самое под его присмотром – это не значит, что он вам не доверяет или считает недостаточно компетентным. Это значит лишь то, что он своими глазами хочет увидеть происходящее;
• если вы договорились об удаленном подключении – то должны обеспечить ПК и канал связи с приемлемым быстродействием, а также заранее подготовить всё необходимое оборудование (провода, адаптеры, накопители и т.д.).
• прочитайте статью Саймона Тэтхема (разработчика утилиты PuTTY) «Как эффективно сообщать об ошибках».
Источник: https://oscat.ru/?p=382