Процесс проверки работоспособности программы и исправления обнаруженных при этом ошибок

Обновлено: 21.11.2024

В этом документе описывается, как устранять неполадки, связанные с модулями памяти, в решении Cisco Unified Computing System (UCS). UCS использует двухрядный модуль памяти (DIMM) в качестве модулей оперативной памяти.

Предпосылки

Требования

Cisco рекомендует ознакомиться с унифицированной вычислительной системой Cisco (Cisco UCS).

Используемые компоненты

Этот документ не ограничивается конкретными версиями программного и аппаратного обеспечения.

Однако основное внимание в этом документе уделяется

Блейд-серверы Cisco UCS серии B
Менеджер UCS

Информация в этом документе была получена с устройств в специальной лабораторной среде. Все устройства, используемые в этом документе, запускались с очищенной (по умолчанию) конфигурацией. Если ваша сеть работает, убедитесь, что вы понимаете потенциальное влияние любой команды.

Методология устранения неполадок

В этом разделе рассматриваются основные аспекты проблем с памятью UCS.

Размещение в памяти
Устранение неполадок с модулями DIMM с помощью UCSM и интерфейса командной строки.
Журналы для проверки в службе технической поддержки.

Термины и сокращения

DIMM	Двухрядный модуль памяти
ECC	Код исправления ошибок
LVDIMM	DIMM низкого напряжения
MCA	Архитектура машинной проверки
MEMBIST	Встроенная самопроверка памяти
MRC	Справочный код памяти
POST	Самотестирование при включении питания
SPD	Обнаружение наличия последовательного порта
DDR	Двойная скорость передачи данных
RAS	Надежность, доступность и удобство обслуживания

Размещение в памяти

Размещение памяти, вероятно, является одним из наиболее заметных физических аспектов решения UCS. Обычно сервер поставляется с памятью, предварительно заполненной запрошенным объемом. Однако в случае сомнений обратитесь к руководству по установке оборудования, которое следует регулярно обновлять по мере появления нового оборудования.

Правила заполнения памяти см. в технических спецификациях серии B для конкретной платформы.

Ссылка на технические характеристики серии B:

Ошибки памяти

Ошибка DIMM

Многобитность = неисправимый

POST отображается BIOS, ОС не видит DIMM
Во время выполнения обычно происходит перезагрузка ОС.

Однобит = исправимый

ОС продолжает видеть модуль DIMM

Ошибка ECC (код исправления ошибок)

Ошибка четности
Ошибка SPD (обнаружение серийного номера)

Ошибка конфигурации

Не поддерживаемые модули DIMM
Неподдерживаемое количество модулей DIMM

Непарные модули DIMM
Ошибки несоответствия

Ошибка невозможности установления личности

Проверьте и обновите каталог

Исправимые и неисправимые ошибки

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

Модули DIMM с исправимой ошибкой не отключаются и доступны для использования операционной системой. Общая память и эффективная память должны быть одинаковыми (с учетом зеркального отображения памяти). Об этих исправимых ошибках сообщается в состоянии работоспособности UCSM как «Ухудшение работоспособности», в то время как общая работоспособность работоспособна с исправимыми ошибками.

Неисправимые ошибки, как правило, не могут быть исправлены и могут сделать невозможным продолжение выполнения приложения или операционной системы. Модули DIMM с неисправимой ошибкой отключены, и ОС не видит эту память. В этом случае состояние UCSM operState изменится на «Inoperable».

Устранение неполадок с модулями DIMM с помощью UCSM и CLI

Проверка ошибок из графического интерфейса

< td>Управление td> < td>Проверить SEL на наличие ошибки ECC во время POST/MRC

UCSM		Журналы	Описание
Статус DIMM	SEL	Комментарии
Работоспособен	Работоспособен	Проверьте журнал SEL на наличие ошибок, связанных с модулями DIMM	Модуль DIMM установлен и функционирует.
Рабочий	Ухудшенный	Проверьте SEL на наличие ошибок ECC	Во время выполнения обнаружена исправимая ошибка ECC DIMM.
Удалено	Н/Д	Нет журналов	Модуль DIMM не установлен или повреждены данные SPD.
Отключено	Работоспособно	Проверить SEL на наличие ошибок, не позволяющих установить личность	Проверить и обновить каталог возможностей
Отключено	Н/Д	Проверить SEL, если другой модуль DIMM вышел из строя в том же канале	A DIMM может быть исправным, но отключенным, поскольку неисправный модуль DIMM в том же канале не может поддерживать правило конфигурации.
Disabled	N/A	Нет журналов	Не удалось выполнить правило конфигурации памяти из-за отсутствия модулей DIMM.
Не работает	Не работает/Требуется замена< /td>	Обнаружена ошибка ECC UE.
Ухудшение качества	Не работает	Проверить SEL на наличие ошибок ECC	Состояние DIMM и работоспособность изменены из-за ошибок ECC, обнаруженных до перезагрузки хоста.
Ухудшение качества	Не работает/требуется замена	Обнаружена неисправимая ошибка ECC во время выполнения, DIMM остается ns доступен для ОС, ОС дает сбой и возвращается, но все еще может использовать этот модуль DIMM. Ошибка может повториться позже. В большинстве случаев модули DIMM следует заменять.

Чтобы получить статистику, перейдите в раздел «Оборудование» > «Шасси» > «Сервер» > «Инвентаризация» > «Память», а затем щелкните правой кнопкой мыши память и выберите «Показать навигатор».

Проверка ошибок из интерфейса командной строки

Эти команды полезны при устранении ошибок из интерфейса командной строки.

Из области массива памяти вы также можете получить доступ к DIMM.

сервер области X/Y > массив памяти области Z > область DIMM N

Оттуда вы можете получить статистику по модулям DIMM или сбросить счетчики ошибок.

Если вы видите сообщение об исправимой ошибке, которая соответствует приведенной выше информации, проблема может быть устранена путем сброса BMC вместо повторной установки или сброса блейд-сервера. Используйте следующие команды интерфейса командной строки Cisco UCS Manager:

Сброс BMC не влияет на ОС, работающую на блейд-сервере.

В версиях UCS 2.27, 3.1 и более поздних были удалены пороговые значения для ошибок с исправлением памяти.

Поэтому модули памяти (DIMM) больше не будут помечаться как «Неработоспособные» или «Ухудшенные» исключительно из-за исправленных ошибок памяти.

Потребности отрасли в большей емкости, большей пропускной способности и более низком рабочем напряжении приводят к увеличению количества ошибок памяти. Традиционно в отрасли к исправимым ошибкам относились так же, как к неисправимым, требуя немедленной замены модуля при получении сигнала тревоги. Учитывая обширные исследования, подтверждающие, что исправимые ошибки не коррелируют с неисправимыми ошибками и что исправимые ошибки не снижают производительность системы, команда Cisco UCS рекомендует не заменять модули с исправимыми ошибками немедленно. Клиенты, получившие предупреждение о снижении качества памяти для исправимых ошибок, должны сбросить ошибку памяти и возобновить работу. Если вы будете следовать этой рекомендации, это позволит избежать ненужного нарушения работы сервера. Будущие усовершенствования управления ошибками будут реализованы и помогут различать различные типы исправимых ошибок и определять соответствующие действия, если таковые необходимы.

Рекомендуется использовать версию не ниже 2.1(3c) или 2.2(1b), в которой улучшено управление ошибками памяти UCS

Если указанные выше действия по устранению неполадок не помогли, отправьте запрос в службу поддержки.

Файлы журналов для проверки в службе технической поддержки

Предоставляет информацию о модулях DIMM и массиве памяти.

Техническая поддержка шасси/сервера

В зависимости от платформы/версии перейдите к файлам в пакете технической поддержки

Эти файлы предоставляют информацию о памяти с точки зрения уровня BIOS.

К этой информации можно еще раз обратиться, ссылаясь на приведенные выше таблицы отчетов о состояниях DIMM.

/var/nuova/BIOS/RankMarginTest.txt

Полезно для отображения результатов тестирования из BIOS

Ищите ошибки
Проверьте, не назначены ли какие-либо модули DIMM
показать информацию о модулях DIMM (производитель/скорость/PID)

Первый столбец имеет два значения:

Поиск DIMM (F2)

Вот краткое описание каждого статуса:

0x00 // Не установлено (нет DIMM)

0x01 // Установлено (работает)

0x10 // Неудачное обучение

0x11 // Ошибка обучения часов

0x18 // Ошибка MemBIST

0x20 // Игнорируется (отключено из консоли отладки)

0x21 // Игнорируется (BMC сообщает об ошибке SPD)

0x22 // Игнорируется (не RDIMM)

0x23 // Игнорируется (без ECC)

0x24 // Игнорируется (не x4)

0x25 // Игнорируется (сбой другого модуля PDIMM в том же LDIMM)

0x26 // Игнорируется (другой LDIMM в том же канале не работает)

0x27 // Игнорируется (сбой другого канала в LockStep или Mirror)

0x28 // Игнорируется (недопустимое заполнение PDIMM)

0x29 // Игнорируется (несоответствие организации PDIMM)

0x2A // Игнорируется (несоответствие регистра PDIMM поставщику)

показывает эффективную и неисправную память, установленную на сервере

18h — состояние модуля DIMM помечается как сбой при сбое в тесте MemBist. Замените на заведомо исправный модуль DIMM.

Описание состояния DIMM

00h Не установлено (нет DIMM)

01h Установлено (Работает)

10 часов сбоя (обучение)

11h Failed (обучение часов)

Ошибка за 18 часов (MemBIST)

20h игнорируется (отключено из консоли отладки)

21h игнорируется (BMC сообщает об ошибке SPD)

22 часа игнорируются (не RDIMM)

23 часа игнорируются (без ECC)

24 часа игнорируется (не x4)

25h игнорируется (сбой другого модуля PDIMM в том же модуле LDIMM)

26h игнорируется (сбой других модулей LDIMM в том же канале)

27h игнорируется (другой канал в LockStep или Mirror)

28h игнорируется (недопустимое заполнение памяти)

29h игнорируется (несоответствие организации)

2 Ач игнорируется (несоответствие регистра поставщика)

2Bh-7Fh Зарезервировано

80 часов игнорируются (обходной путь – зацикливание)

81h игнорируется (зависание шины I2C)

82h – FFh зарезервировано

Занесение модулей DIMM в черный список

В Cisco UCS Manager состояние двухрядного модуля памяти (DIMM) основано на записях о событиях SEL. Когда BIOS обнаруживает неисправимую ошибку памяти во время выполнения теста памяти, модуль DIMM помечается как неисправный. Неисправный модуль DIMM считается неработающим устройством.

Если включить черный список модулей DIMM, Cisco UCS Manager отслеживает сообщения о выполнении теста памяти и заносит в черный список все модули DIMM, в которых обнаружены ошибки памяти в данных DIMM SPD. Чтобы позволить хосту отображать любые модули DIMM, которые обнаруживают неисправимые ошибки ECC.

Черный список DIMM был введен в качестве дополнительной глобальной политики в UCSM 2.2(2).

Прошивка сервера должна быть версии 2.2(1)+ для блейд-серверов серии B и версии 2.2(3)+ для стоечных серверов серии C, чтобы правильно реализовать эту функцию.

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

Отладка — это циклическое действие, включающее проверку выполнения и исправление кода. Тестирование, проводимое во время отладки, преследует иную цель, чем окончательное тестирование модуля. Окончательное тестирование модуля направлено на демонстрацию правильности, тогда как тестирование во время отладки в первую очередь направлено на обнаружение ошибок. Это различие существенно влияет на выбор стратегии тестирования.

Предварительные условия для эффективной отладки

Понимание структуры и алгоритма. Если вы работаете над модулем и не понимаете его структуры или алгоритмов, отладка будет очень сложной. Если вы не понимаете структуру, вы не сможете протестировать модуль, потому что не знаете, что он должен делать. Если вы не понимаете алгоритмы, вам будет очень сложно найти ошибки, которые выявляет тестирование. Вторая причина важности понимания алгоритмов заключается в том, что вам может понадобиться это понимание для создания хороших тестовых примеров. Это особенно верно для алгоритмов для сложных структур данных.
Проверка правильности. Существует несколько методов проверки правильности реализации перед ее выполнением.
Доказательства правильности. Одной из полезных проверок кода является проверка кода с использованием логических методов доказательства правильности. Например, если вы знаете предусловия, инварианты, условия завершения и постусловия для цикла, то вы можете выполнить несколько простых проверок. Означает ли предварительное условие вместе с любым кодом входа в цикл, что инвариант изначально истинен? Сохраняет ли тело цикла инвариант? Продвигается ли выполнение тела цикла к завершению цикла? Подразумевает ли инвариант вместе с условием завершения цикла и кодом выхода из цикла постусловие? Даже если эти проверки не найдут всех ошибок, вы сможете лучше понять алгоритм, выполнив проверки.
Отслеживание кода. Часто ошибки можно обнаружить путем отслеживания выполнения различных вызовов служб модуля, начиная с различных начальных условий для модуля. По плохо понимаемым психологическим причинам отслеживание работает лучше всего, если вы описываете свое отслеживание кому-то другому. Чтобы быть эффективной, трассировка процедуры или функции должна выполняться при условии, что вызовы других процедур и функций работают правильно, даже если они являются рекурсивными вызовами. Если вы проследите вызываемую процедуру или функцию, вы обнаружите, что имеете дело со слишком большим количеством уровней абстракции. Обычно это приводит к путанице. Если есть какие-либо сомнения относительно вызываемых процедур и функций, их можно проследить отдельно, чтобы убедиться, что они работают в соответствии со спецификациями.Опять же, трассировка может не выявить все ошибки, но она может улучшить ваше понимание алгоритмов.
Экспертная проверка. Экспертная проверка включает в себя экспертную проверку вашего кода на наличие ошибок. Чтобы быть эффективным, одноранговый узел должен либо уже быть знаком с алгоритмом, либо должен получить алгоритм и код заранее. Когда рецензент встречается с автором кода, автор кода должен представить код с пояснениями того, как он правильно реализует алгоритм. Если рецензент не понимает часть реализации или не согласен с ней, он обсуждает эту часть до тех пор, пока оба не придут к согласию относительно того, является ли это ошибкой. Роль рецензента заключается только в том, чтобы помочь обнаружить ошибки. Разработчику остается исправить их. Большая часть пользы от рецензирования проистекает из психологии представления того, как что-то работает. Часто автор кода обнаруживает свои собственные ошибки во время проверки. В любом случае, полезно, чтобы кто-то со стороны просмотрел вашу работу, чтобы получить другую точку зрения и обнаружить белые пятна, которые кажутся неотъемлемыми при оценке вашей собственной работы. Как и трассировка кода, рецензирование может занять много времени. Для работы в классе рецензирование всего модуля вряд ли окупит себя с точки зрения учебной ценности. Поэтому обзоры должны быть ограничены короткими сегментами кода. Однако для коммерческого программирования гораздо важнее качество кода. Таким образом, рецензирование является важной частью программы обеспечения качества программного обеспечения.
Предвидеть ошибки. К сожалению, люди делают ошибки с аргументами правильности и иногда пропускают случаи при отслеживании кода, а равноправные узлы также не всегда обнаруживают ошибки. Так что программист должен быть готов к тому, что некоторые ошибки останутся в коде после перечисленных выше шагов. Надеюсь, их не будет слишком много.

Требования к отладке

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

Управление модулем

Встроенные драйверы. Встроенные драйверы — это основной программный модуль, содержащий фиксированную последовательность вызовов служб, предоставляемых тестируемым модулем. Последовательность вызовов можно изменить, переписав код драйвера и перекомпилировав его. Для тестирования модулей, поведение которых определяется очень небольшим числом случаев, аппаратные драйверы предлагают то преимущество, что их легко сконструировать. Однако, если случаев слишком много, у них есть недостаток, заключающийся в значительных усилиях по изменению последовательности вызовов.
Интерпретаторы команд. Интерпретатор команд управляет тестируемым модулем, считывая входные данные и интерпретируя их как команды для выполнения вызовов служб модуля. Интерпретаторы команд могут быть спроектированы таким образом, чтобы команды можно было вводить интерактивно или считывать из файла. Интерактивная интерпретация команд часто имеет большое значение на ранних стадиях отладки, тогда как пакетный режим обычно лучше подходит для более поздних стадий отладки и окончательного тестирования. Основным недостатком интерпретаторов команд является сложность их написания, включая возможность того, что много времени может быть потрачено на отладку кода интерпретатора. Это смягчается тем фактом, что большую часть сложного кода можно использовать повторно, и его можно легко адаптировать для тестирования различных типов модулей. Гибкость интерпретаторов команд делает их предпочтительным выбором практически для всех модулей структуры данных.

Получение информации о модуле

Состояние модуля. Модули структуры данных обычно имеют службы для вставки и удаления данных. Эти сервисы почти никогда не генерируют выходные данные сами по себе и часто не возвращают никакой информации через параметры. Следовательно, чтобы протестировать или отладить модуль, программист должен добавить код, предоставляющий информацию об изменениях внутреннего состояния модуля. Обычно программист добавляет процедуры, которые могут отображать содержимое данных модуля. Эти процедуры доступны для модуля драйвера, но обычно удаляются или становятся закрытыми после завершения тестирования. Для отладки полезно иметь процедуры, которые отображают не только содержимое, но и внутреннюю структуру.
Ошибки модуля. Когда модуль имеет сложное внутреннее состояние, с неверным кодом обычно могут возникать недопустимые состояния. Также возможно, что приватные подпрограммы вызываются неправильно. Обе эти ситуации являются ошибками модуля. Когда это целесообразно, в модуль можно добавить код для обнаружения этих ошибок.
Состояние выполнения. Чтобы определить причину ошибок модуля, необходимо знать, какие службы и частные подпрограммы были вызваны при возникновении ошибки. Это состояние выполнения модуля.Одним из распространенных методов определения состояния выполнения является добавление операторов отладочной печати, которые указывают вход и выход из сегментов кода.

Принципы отладки

Немедленно сообщайте об ошибках. Много времени уходит на отладку, чтобы выяснить причину ошибок. Чем раньше обнаружена ошибка, тем проще найти ее причину. Если неправильное состояние модуля обнаруживается сразу после его возникновения, то часто можно определить причину с минимальными усилиями. Если она не обнаружена до тех пор, пока симптомы не появятся в клиентском интерфейсе, может быть сложно сузить список возможных причин.
Максимальное количество полезной информации и простота интерпретации. Очевидно, что желательно максимальное количество полезной информации, и что ее должно быть легко интерпретировать. Простота интерпретации важна в структурах данных. Некоторые ошибки модулей не так просто обнаружить, добавив проверки кода, потому что они зависят от всей структуры. Таким образом, важно иметь возможность отображать структуру в форме, которую можно легко проверить на правильность.
Сведите к минимуму количество бесполезной и отвлекающей информации. Слишком много информации может быть таким же препятствием, как и слишком мало. Если вам приходится работать с распечаткой, которая показывает вход и выход из каждой процедуры в модуле, вам будет очень трудно найти первое место, где что-то пошло не так. В идеале отчеты о состоянии выполнения модуля должны выдаваться только в случае возникновения ошибки. Как правило, отладочная информация, в которой говорится, что проблема здесь, должна быть предпочтительнее, чем отчеты, в которых говорится, что проблема не здесь.
Избегайте сложного одноразового тестового кода. Одной из причин, по которой добавление проверок правильности модуля для ошибок, затрагивающих всю структуру, является контрпродуктивным, является то, что код для этого может быть довольно сложным. Очень обескураживает потратить несколько часов на отладку проблемы только для того, чтобы обнаружить, что ошибка была в отладочном коде, а не в тестируемом модуле. Сложный тестовый код целесообразен только в том случае, если сложные части кода можно использовать повторно.

Вспомогательные средства для отладки

Вспомогательные средства, встроенные в язык программирования

Утверждения утверждений. Некоторые компиляторы Pascal и все компиляторы C, соответствующие стандарту ANSI, имеют процедуры утверждения. Процедура assert имеет единственный параметр, который является логическим выражением. Когда вызов assert выполняется, выражение оценивается. Если он оценивается как true, то ничего не происходит. Если он оценивается как false, программа завершается с сообщением об ошибке. Процедуру утверждения можно использовать для обнаружения ошибок и сообщения о них.
Обратные трассировки. Многие компиляторы Pascal генерируют код, который приводит к обратным трассировкам всякий раз, когда возникает ошибка времени выполнения. Трассировка — это отчет о последовательности активных в данный момент подпрограмм. Иногда трассировка также указывает номера строк в активных подпрограммах. Если доступно, обратная трассировка показывает, где произошла ошибка во время выполнения, но программист должен определить, в чем причина.
Отладчики общего назначения. Многие компьютерные системы или компиляторы поставляются с программами отладки. Например, в большинстве операционных систем UNIX есть отладчики общего назначения, такие как sdb и dbx. Программы отладки предоставляют возможности для пошагового выполнения программы построчно и запуска программы с точками останова, установленными пользователем. Когда строка с точкой останова должна быть выполнена, программа прерывается, чтобы пользователь мог проверить или изменить данные программы. Программы отладки также могут обеспечивать обратную трассировку в случае ошибок во время выполнения. Отладчики часто трудно научиться эффективно использовать. Если они являются единственным инструментом, используемым для отладки, то, вероятно, они не сэкономят много времени. Например, отладка модуля структуры данных с помощью отладчика, но без хорошего тестового драйвера, скорее всего, приведет к тому, что будет потрачено много времени на получение фрагментарной информации об ошибках.

Методы отладки

Пошаговое тестирование

В хорошем дизайне сложного модуля код разбит на множество подпрограмм, длина большинства из которых не превышает 10–15 строк. Для модуля, разработанного таким образом, инкрементное тестирование дает значительные преимущества. Для пошагового тестирования подпрограммы классифицируются по уровням, при этом подпрограммы самого низкого уровня — это те, которые не вызывают другие подпрограммы. Если подпрограмма A вызывает подпрограмму B, то A является подпрограммой более высокого уровня, чем B. Стратегия пошагового тестирования состоит в том, чтобы тестировать подпрограммы по отдельности, работая от самого низкого уровня к более высоким уровням. Чтобы выполнить тестирование на более низких уровнях, тестовый драйвер должен либо иметь возможность вызывать низкоуровневые подпрограммы напрямую, либо программист должен иметь возможность предоставить несколько тестовых входных данных, каждый из которых включает только небольшое количество низкоуровневых подпрограмм. Разработка этих тестовых случаев требует глубокого понимания алгоритмов модуля, а также хорошего воображения.Сила инкрементного тестирования заключается в том, что в любой момент процесса есть лишь небольшое количество мест, где могут возникнуть ошибки. Это автоматически делает отладочную информацию более значимой и приводит к более быстрому определению причины ошибки. Вторая причина инкрементного тестирования заключается в том, что оно значительно снижает вероятность того, что вам придется иметь дело с двумя или более ошибками одновременно. Множественные ошибки часто приводят к запутанной индикации ошибок.

Проверки работоспособности

Код низкого уровня в сложной структуре данных часто пишется с предположением, что код более высокого уровня правильно реализует желаемый алгоритм. Например, низкоуровневый код может быть написан с предположением, что определенная переменная или параметр не может быть NULL. Даже если это предположение подтверждается алгоритмом, все же может быть хорошей идеей провести тест, чтобы увидеть, выполняется ли условие, потому что код более высокого уровня может быть реализован неправильно. Такая проверка называется проверкой работоспособности. Если доступна процедура утверждения, ее можно использовать для проверок. Преимущество проверок работоспособности заключается в том, что они обеспечивают раннее обнаружение ошибок.

Булевы константы для включения и выключения кода отладки

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

Переменные ошибок для управления поведением программы после ошибок

Когда в код добавляются операторы отладочной печати, существует вероятность огромного взрыва бесполезной информации. Проблема в том, что оператор печати сам по себе будет выполняться независимо от того, есть ли ошибка. Таким образом, если ошибка не появляется до тех пор, пока не будет выполнено большое количество вызовов подпрограммы, то большинство сообщений просто говорят вам, что пока все в порядке. Эта проблема значительно усугубляется, если добавленный код отображает внутреннюю структуру структуры данных. Предполагая, что модуль имеет проверки работоспособности для обнаружения ошибок, в модуль можно добавить логическую переменную ошибки. Он должен быть инициализирован значением false, указывающим на отсутствие ошибки. Для большинства структур данных существует операция Create для инициализации. Переменная ошибки может быть инициализирована одновременно. Вместо выхода проверки работоспособности модифицируются таким образом, что они устанавливают переменную ошибки в значение true. Затем код отладки можно заключить в операторы if, чтобы информация печаталась только при обнаружении ошибок. Одним из возможных применений этого метода является получение информации о трассировке, когда она недоступна иным образом.

Методы отслеживания

Чтобы получить обратную трассировку, используйте логическое значение ошибки, заданное проверками работоспособности. В разных местах модуля добавьте код отладки, управляемый переменной ошибки, которая печатает текущую позицию. Обычно более экономично сначала запускать код с завершающей проверкой работоспособности. Затем вам нужно только добавить контролируемый отладочный код в те места, где вызывается подпрограмма, содержащая проверку работоспособности.

Исправление ошибок кода

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

Предположим, что вы запускаете какой-то код и получаете ошибку сегментации. После некоторой проверки вы определяете, что указатель NULL был передан в процедуру, которая не проверяла наличие NULL, но все равно пыталась сослаться через указатель. Следует ли добавить в процедуру проверку указателя NULL, заключив все тело процедуры в оператор if? На этот вопрос невозможно ответить без понимания конструкции и алгоритма. Возможно, если алгоритм реализован правильно, то указатель не может быть NULL, и процедура не выполняет проверку. Если это так, то добавление оператора if не устраняет причину проблемы. Наоборот, это усугубляет ситуацию, скрывая симптомы. Проблема наверняка проявится где-то еще, но теперь симптомы будут дальше удалены от причины. Такой код, как проверка указателя на NULL, следует добавлять только в том случае, если вы уверены, что он должен быть частью алгоритма. Если вы добавите проверку указателя NULL, которая не требуется алгоритмом, она должна сообщить об ошибке. Другими словами, это должна быть проверка на вменяемость. [произошла ошибка при обработке этой директивы]

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

Но если результат одного из тестовых случаев не соответствует ожидаемому, то программа неверна — она содержит ошибки (или дефекты, или «ошибки»). В таких ситуациях тестирование только выявляет наличие ошибок, но не говорит нам, что это за ошибки или как нужно исправить код. Другими словами, тестирование выявляет последствия (или симптомы) ошибок, а не причину ошибок. Затем программист должен пройти процесс отладки, чтобы определить причины и исправить ошибки.

Предотвращение ошибок и защитное программирование

Удивительно, но процесс отладки может занять значительно больше времени, чем сам процесс написания кода. Большая часть (если не большая) часть разработки программного обеспечения уходит на отладку и сопровождение кода, а не на его написание.

Поэтому лучше всего избегать ошибок при написании программы! Важно сесть и подумать, прежде чем писать код: решить, чего именно нужно достичь, как вы планируете это сделать, четко спроектировать высокоуровневый алгоритм, убедить себя в его правильности, решить, какие конкретные структуры данных вы планируете использовать. использовать и какие инварианты вы планируете поддерживать. Все усилия, затраченные на проектирование и обдумывание кода до того, как вы его напишете, окупятся позже. Преимущества двоякие. Во-первых, чистый дизайн уменьшит вероятность дефектов в вашей программе. Во-вторых, даже если ошибка обнаружится во время тестирования, чистый дизайн с четкими инвариантами значительно облегчит отслеживание и исправление ошибки.

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

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

Помните, что цель не в том, чтобы стать экспертом в исправлении ошибок, а в том, чтобы в первую очередь лучше писать надежные, (в основном) безошибочные программы. Что касается отношения, программисты должны не гордиться, когда они исправляют ошибки, а скорее смущаться, что в их коде есть ошибки. Если в программе и есть ошибка, то только потому, что ошибся программист.

Классы дефектов

Даже после тщательного обдумывания и защитного программирования в программе все еще могут быть дефекты. Вообще говоря, есть несколько видов ошибок, с которыми можно столкнуться:

Ошибки синтаксиса или типа. Они всегда перехватываются компилятором и сообщаются в виде сообщений об ошибках. Обычно в сообщении об ошибке четко указывается причина ошибки; например, номер строки, неверный фрагмент кода и объяснение. Такие сообщения обычно дают достаточно информации о том, в чем заключается проблема и что необходимо сделать. Кроме того, редакторы с подсветкой синтаксиса могут дать хорошую индикацию таких ошибок еще до компиляции программы.
Опечатки и другие простые ошибки, которые не были обнаружены средством проверки типов или другими проверками в компиляторе. Как только они выявлены, их можно легко исправить. Вот несколько примеров: отсутствие круглых скобок, например запись x + y * z вместо (x + y) * z ; опечатки, например case t of . | x::tl => содержит(х,т) ; передача параметров в неправильном порядке; или используя неправильный порядок элементов в кортежах.
Ошибки реализации. Может случиться так, что логика в высокоуровневом алгоритме программы верна, но некоторые низкоуровневые конкретные структуры данных обрабатываются неправильно, нарушая некоторые внутренние инварианты представления. Например, программа, поддерживающая отсортированный список в качестве базовой структуры данных, может нарушить инвариант сортировки. В таких случаях может помочь создание отдельных АТД для моделирования каждой абстракции данных: это может отделить логику алгоритма от манипулирования конкретными структурами; таким образом проблема изолируется в АТД. Вызовы repOK() могут указать, какие части АТД вызывают ошибку.
Логические ошибки. Если алгоритм логически ошибочен, программист должен переосмыслить алгоритм.Исправить такие проблемы сложнее, особенно если программа дает сбой всего в нескольких крайних случаях. Нужно внимательно изучить алгоритм и попытаться привести аргумент, почему алгоритм работает. Попытка сконструировать такой аргумент правильности, вероятно, обнажит проблему. Чистый дизайн может сильно помочь в выяснении и исправлении таких ошибок. Фактически, в тех случаях, когда алгоритм слишком сложен для понимания, может быть хорошей идеей переделать алгоритм с нуля и стремиться к более четкой формулировке.

Трудности

Симптомы могут не давать четких указаний на причину. В частности, причина и симптом могут быть удалены либо в пространстве (т.е. в программном коде), либо во времени (т.е. , во время выполнения программы), или и то, и другое. Защитное программирование может помочь сократить расстояние между причиной и следствием ошибки.
Может быть трудно воспроизвести симптомы. Чтобы лучше понять проблему, необходимо повторное воспроизведение. Возможность воспроизвести выполнение одной и той же программы является стандартным препятствием при отладке параллельных программ. Ошибка может проявиться только в одном конкретном чередовании операторов из параллельных потоков, и воспроизвести такое же точное чередование может быть практически невозможно.
Ошибки могут быть взаимосвязаны. Поэтому симптомы могут измениться во время отладки после исправления некоторых ошибок. Новые симптомы необходимо пересмотреть. Хорошая часть заключается в том, что одна и та же ошибка может иметь несколько симптомов; в этом случае исправление ошибки устранит их все.
Исправление ошибки может привести к появлению новых ошибок. Статистика показывает, что во многих случаях исправление ошибки приводит к возникновению новой! Это результат попыток быстро исправить ошибку без понимания общего дизайна и инвариантов, которые должна поддерживать программа. Опять же, четкий дизайн и тщательное обдумывание могут избежать многих из этих случаев.

Стратегии отладки

Поэтапная и восходящая разработка программ. Один из наиболее эффективных способов локализации ошибок — поэтапная разработка программы и ее частое тестирование после добавления каждого фрагмента кода. Весьма вероятно, что если и есть ошибка, то она возникает в последнем фрагменте кода, который вы написали. При поэтапной разработке программы последняя часть кода невелика; поэтому поиск ошибок ограничивается небольшими фрагментами кода. Дополнительным преимуществом является то, что небольшие приращения кода, скорее всего, приведут к небольшому количеству ошибок, поэтому программист не будет перегружен длинными списками ошибок.

Ряд других стратегий можно рассматривать как отношение к тому, где ожидать ошибок:

Нала Дэвис

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

Чтобы проводить эффективное тестирование, вам необходимо знать о различных типах тестирования и о том, когда их следует использовать.

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

Пирамида тестирования программного обеспечения

Пирамида тестирования программного обеспечения. Наслаждайтесь этой бесплатной графикой и поделитесь ею в своем блоге или Twitter.

Пирамида тестирования программного обеспечения охватывает все этапы жизненного цикла разработки программного обеспечения (SDLC). Он включает в себя модульное тестирование в основе, интеграционное тестирование и завершается функциональным тестированием на вершине.

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

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

Например, модульное тестирование — это техническое тестирование, которое поддерживает команду, тогда как тестирование удобства использования — это ориентированное на бизнес тестирование, которое критикует продукт.

Давайте теперь рассмотрим некоторые важные типы тестирования.

Определение модульного тестирования

Модульное тестирование включает тестирование отдельных компонентов кода, а не кода в целом. Он проверяет работу всей логики вашего компонента для раннего выявления ошибок в SDLC, что позволяет вам исправить ошибки до дальнейшей разработки.

Модульное тестирование известно как тестирование "белого ящика", поскольку тестирование проводится с полным знанием структуры и среды приложения.

Одним из примеров модульного тестирования является создание фиктивных объектов для тестирования участков кода, таких как функции с переменными, которые еще не созданы.

Пример модульного теста из раздела "Объяснение модульных тестов"

Определение интеграционного тестирования

Шагом по сравнению с модульным тестированием является интеграционное тестирование, которое объединяет отдельные компоненты и тестирует их как группы. Интеграционное тестирование выявляет проблемы в том, как отдельные компоненты взаимодействуют друг с другом, чтобы увидеть, соответствует ли код всем его функциональным спецификациям.

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

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

В качестве более упрощенного примера, если вы должны выполнить интеграционный тест создаваемой вами службы электронной почты, вам нужно будет протестировать отдельные компоненты, такие как составление почты, сохранение черновиков, отправка, перемещение в папку "Входящие", выход из системы. и т. д.

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

Определение сквозного тестирования

На вершине пирамиды находится сквозное (E2E) тестирование. Как следует из названия, сквозное тестирование полностью воспроизводит работу приложения, чтобы проверить все соединения и зависимости приложения. Это включает сетевое подключение, доступ к базе данных и внешние зависимости.

Вы проводите E2E-тестирование в среде, которая имитирует реальную среду пользователя.

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

Типы тестирования программного обеспечения

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

Определение тестирования безопасности приложений

Одним из наиболее важных видов тестирования приложений является тестирование безопасности приложений. Тестирование безопасности помогает выявить уязвимости приложений, которыми могут воспользоваться хакеры, и устранить их перед выпуском продукта или приложения.

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

Вы можете найти различные типы тестирования безопасности приложений на разных уровнях пирамиды тестирования. Каждый тест имеет свои сильные и слабые стороны. Вы должны использовать различные типы тестирования вместе, чтобы обеспечить их общую целостность.

Определение статического тестирования безопасности приложений (SAST)

Вы должны использовать статическое тестирование безопасности приложений (SAST) в начале SDLC. Это пример модульного тестирования.

SAST отражает знания разработчика, в том числе об общем дизайне и реализации приложения, и поэтому представляет собой тестирование методом «белого ящика» или тестированием наизнанку.

SAST анализирует сам код, а не конечное приложение, и вы можете запускать его без фактического выполнения кода.

По словам аналитиков по безопасности из Cloud Defense,

«SAST проверяет ваш код на нарушение правил безопасности и сравнивает найденные уязвимости между исходной и целевой ветками. затем вы получите уведомление, если зависимости вашего проекта затронуты недавно обнаруженными уязвимостями».

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

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

Определение динамического тестирования безопасности приложений (DAST)

На другом конце спектра находится динамическое тестирование безопасности приложений (DAST), которое проверяет полностью скомпилированное приложение. Вы разрабатываете и запускаете эти тесты, не зная базовых структур или кода.

Поскольку DAST использует точку зрения хакера, его называют «черным ящиком» или тестированием снаружи внутри.

DAST атакует работающий код и пытается использовать потенциальные уязвимости. DAST может использовать такие распространенные методы атак, как межсайтовый скриптинг и внедрение SQL.

DAST используется позже в SDLC и является примером тестирования безопасности интеграции. Несмотря на то, что он медленный (полное DAST-тестирование всего приложения может занять в среднем от пяти до семи дней), он выявит наиболее вероятные уязвимости в ваших приложениях, которые могут использовать хакеры.

Определение интерактивного тестирования безопасности приложений

Интерактивное тестирование безопасности приложений (IAST) – это новая методология тестирования, которая сочетает в себе эффективность SAST и DAST и устраняет проблемы, связанные с этими более известными тестами.

IAST проводит непрерывное сканирование приложения в режиме реального времени на наличие ошибок и уязвимостей с помощью встроенного агента мониторинга. Несмотря на то, что IAST работает в работающем приложении, он считается ранним процессом тестирования SDLC.

Независимо от типа программного обеспечения, которое вы собираетесь тестировать, IAST лучше всего использовать в среде QA (Quality Assurance) или в среде, предназначенной для максимально точного воспроизведения рабочей среды без фактического доступа ваших клиентов или заказчиков к ней. .

Определение тестирования совместимости

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

Тестирование совместимости также позволяет определить, совместима ли текущая версия программного обеспечения с другими версиями программного обеспечения. Тестирование версий может быть обратным или прямым.

Примеры тестирования совместимости включают:

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

Помимо пирамиды тестирования программного обеспечения

Измененные версии пирамиды тестирования могут включать уровень, следующий за сквозным тестированием или выше него. Этот уровень состоит из тестов, ориентированных на пользователя приложения.

Определение тестирования производительности

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

Примером проверки производительности является нагрузочное тестирование, которое определяет максимальную нагрузку на систему во время сбоя.

Другой пример, такой как тестирование масштабируемости, с другой стороны, применяет постепенно увеличивающуюся нагрузку на систему, чтобы оценить способы справиться с дополнительными системными нагрузками.

Кроме того, пиковое тестирование оценивает влияние внезапных значительных изменений нагрузки на систему.

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

Определение юзабилити-тестирования

Тестирование фактического использования интерфейса приложения – важная задача. Одно дело понять, работает ли приложение так, как задумано. Другое дело понять, приемлем ли для пользователей сам дизайн. Вот тут-то и начинается юзабилити-тестирование.

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

Юзабилити-тестирование — это не столько косметические проблемы или исправление грамматических ошибок в любом письменном тексте (хотя обе эти проблемы, безусловно, важны сами по себе). Вместо этого речь идет о том, насколько просто конечным пользователем будет использовать готовое приложение.

Заключение

Тестирование — это не просто то, чем отдел контроля качества должен заниматься после того, как вы закончите разработку приложения. Это также важная часть процесса разработки программного обеспечения.

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

Читайте также: