Ошибки в программах по своему характеру делятся на

Обновлено: 07.07.2024

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

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

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

Блок 2. Как определить качество ПО (стандарты ISO, критерии качества, метрики)

Понятие «качество ПО» имеет множество трактовок. И тестировщик, и программист дадут свое толкование этого термина.

Если вкратце, то качество программы определяется следующим:

• возможностями, благодаря которым она понравится пользователю;

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

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

Характеристики качества ПО

1. Полнота реализации функций;

3. Отношение числа обнаруженных дефектов к прогнозируемому;

5. Отношение числа доступных проектных документов к указанному в их списке;

Как контролировать качество системы?

Как точно узнать, что программа делает именно то, что нужно, и ничего другого? Как определить, что она достаточно надежна, переносима, удобна в использовании? Ответы на этот вопрос можно получить с помощью процессов верификацииивалидации.

Блок 3. Категории программных ошибок

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

Это узкое определение, более подробную информацию вы получите на лекции, но стоит обратить внимание на то, что ошибка может возникнуть на любой стадии разработки проекта. Будьте бдительны, господа исследователи!

Коварные баги имеют свою категорийность, охватывающую все возможные варианты:

Ошибки пользовательского интерфейса

2. Взаимодействие программы с пользователем

3. Организация программы

4. Пропущенные команды

5. Производительность

Ошибки, связанные с обработкой граничных условий

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

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

Начальное и последующие состояния

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

Ошибки управления потоком

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

Ошибки передачи или интерпретации данных

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

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

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

Если программист допускает по полторы ошибки на каждую строку программного кода, то сколько их допускает тестировщик на каждый тест? Обнаружение ошибок, допущенных тестировщиками, — дело обычное. Конечно, если таких ошибок будет слишком много, вы быстро потеряете доверие остальных членов команды. Но нужно иметь в виду, что иногда ошибки тестировщика отражают проблемы пользовательского интерфейса: если программа заставляет пользователя делать ошибки, значит, с ней что- то не так. Конечно, многие ошибки тестирования вызваны просто неверными тестовыми данными.

И в заключение – в качестве бонуса на лекции вас ожидает тест для оценки себя как тестировщика :)

Некоторое время назад ряд компаний провел исследование оценки стоимости ошибок, возникающих на разных этапах создания программ. Каждая фирма действовала независимо, тем не менее результаты получены примерно одинаковые: если стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5–10 раз меньше, а стоимость обнаружения и устранения ошибки на стадии сопровождения – в 20 раз больше.

Откуда берется такая высокая стоимость ошибки (рис. 1.6)? Ко времени обнаружения ошибки в требованиях группа разработчиков уже могла потратить время и усилия на создание проекта по этим ошибочным требованиям. В результате проект, вероятно, придется отбросить или пересмотреть.

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

В зависимости от того, где и когда при работе над проектом разработки программного приложения был обнаружен дефект, цена его может разниться в 50–100 раз.

Рис. 1.6. Оценка стоимости ошибок на разных этапах создания программного обеспечения

Причина состоит в том, что для его исправления придется затратить средства на некоторые (или все) ниже перечисленные действия:

· Замена заказа – сообщить клиентам и операторам о необходимости заменить дефектную версию исправленной.

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

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

·Отзыв дефектных версий встроенного программного обеспечения и соответствующих руководств. Если принять во внимание, что программное обеспечение сегодня встраивается в различные изделия – от наручных часов и микроволновых печей до автомобилей – такая замена может коснуться как этих изделий, так и встроенного в них программного обеспечения.

·Выплаты по гарантийным обязательствам.

· Ответственность за изделие – если клиент через суд требует возмещение убытка, причиненного некачественным программным продуктом.

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

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

Виды программных ошибок

Способы их обнаружения

Статический контроль и диагностика компиляторами и компоновщиком

Ошибки выполнения, выявляемые автоматически:

а) переполнение, защита памяти;

б) несоответствие типов;

run-time системы программирования;

операционной системой – по превышению лимита времени

Программане соответствует спецификации

Спецификация не соответствует требованиям

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

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

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

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

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

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

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

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

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

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

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

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

Первое место в неформальном состязании за место "самой дорого обошедшейся ошибки в ПО " (см. [11,12]) долгое время удерживала ошибка, приведшая к неудаче первого запуска ракеты Ариан-5 4 июня 1996 года (см. [13]), стоившая около $500 000 000. После произошедшего 14 августа 2003 года обширного отключения электричества на северо-востоке Северной Америки, стоившего экономике США и Канады от 4 до 10 миллиардов долларов [14], это место можно отдать спровоцировавшей его ошибке в системе управления электростанцией. Широко известны также примеры ошибок в системах управления космическими аппаратами, приведшие к их потере или разрушению. Менее известны, но не менее трагичны, ошибки в ПО , управлявшем медицинским и военным оборудованием, некоторые из которых привели к гибели людей.

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

Даже если ограничиться рассмотрением только ПО , часто одно проявление ошибки ( failure ) может выявить несколько дефектов, находящихся в разных местах. Такие ошибки возникают, как показывает практика, в тех ситуациях, поведение в рамках которых неоднозначно или недостаточно четко определяется требованиями (а иногда и вообще никак не определяется — признак неполного понимания задачи). Поэтому разработчики различных модулей ПО имеют возможность по -разному интерпретировать те части требований, которые относятся непосредственно к их модулям, а также иметь разные мнения по поводу области ответственности каждого из взаимодействующих модулей в данной ситуации. Если различия в их понимании не выявляются достаточно рано, при разработке системы, то становятся "минами замедленного действия" в ее коде.

Например, анализ катастрофы Ариан-5 показал следующее [13].

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

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

Надо отметить, что обработка нескольких достаточно однородных величин производилась по-разному — семь переменных могли вызвать исключительную ситуацию данного вида, обработка четырех из них была защищена от этого, а три оставшихся, включая горизонтальную скорость, оставлены без защиты. Аргументом для этого послужило выдвинутое при разработке требование поддерживать загрузку процессора не выше 80%. "Нагружающие" процессор защитные действия для этих переменных не были использованы, поскольку предполагалось, что эти величины будут находиться в нужных пределах в силу физических ограничений на параметры движения ракеты. Обоснований для поддержки именно такой загрузки процессора и того, что отсутствие обработки переполнения выбранных величин будет способствовать этому, найдено не было.

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

Рассмотрим более подробно некоторые из вышеприведенных видов ошибок.

Синтаксические ошибки

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

Примерами синтаксических ошибок является:

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

Синтаксическая ошибка «Не задан идентификатор»:

Ошибки, которые не обнаруживает транслятор

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

Готовые работы на аналогичную тему

Получить выполненную работу или консультацию специалиста по вашему учебному проекту Узнать стоимость

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

Ошибки в циклах:

неправильно указано начало цикла;
неправильно указаны условия окончания цикла;
неправильно указано количество повторений цикла;
использование бесконечного цикла.

Ошибки ввода-вывода; ошибки при работе с данными:

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

Ошибки в использовании переменных:

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

Ошибки при работе с массивами:

пропущено предварительное обнуление массивов;
неправильное описание массивов;
индексы массивов следуют в ошибочном порядке.

Ошибки в арифметических операциях:

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

Ошибка в арифметических операциях «Деление на нуль»:

Все вышеописанные ошибки можно обнаружить методом тестирования.

Сопровождение программы

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

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

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

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

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

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

Ошибка (error) – это действие человека, которое порождает неправильный результат.

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

Дефект, Баг (Defect, Bug) – недостаток компонента или системы, который может привести к отказу определенной функциональности. Дефект, обнаруженный во время исполнения программы, может вызвать отказ отдельного компонента или всей системы.

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

Сбой (failure) – несоответствие фактического результата (actual result) работы компонента или системы ожидаемому результату (expected result).

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

Таким образом, баг существует при одновременном выполнении трех условий:

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

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

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

Всего существует несколько источников дефектов и, соответственно, сбоев:

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

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

Качество (Quality) – степень, в которой совокупность присущих характеристик соответствует требованиям.

Качество программного обеспечения (Software Quality) – это совокупность характеристик программного обеспечения, отражающих его способность удовлетворять установленные и предполагаемые потребности.

Требование (Requirement) – потребность или ожидание, которое установлено. Обычно предполагается или является обязательным.

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

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

Условно можно выделить пять причин появления дефектов в программном коде.

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