Сколько ошибок допущено в программе
Для того, чтобы найти ошибку, нужно поставить в соответствие друг другу все части условного оператора if и else.
Помним, что часть else относится к ближайшему if. При этом наличие части else не обязательно.
Кроме того, часто присутствует ошибка при вводе или выводе. Обязательно нужно проверить, та ли информация выводится на экран.
Особого внимания требует инициализация переменных.
Формат книги не позволяет рассмотреть все основные типы задач 2 части, рассмотрим лишь те, которые встречались на проверочных и экзаменационных работах последних двух лет.
На обработку поступает положительное целое число, не превышающее 10 9 . Нужно написать программу, которая выводит на экран сумму цифр этого числа, меньших 7. Если в числе нет цифр, меньших 7, требуется на экран вывести 0. Программист написал программу неправильно. Ниже эта программа для Вашего удобства приведена на пяти языках программирования.
Бейсик
Python
INPUT N
WHILE N > 0
DIGIT = N MOD 10
END IF
WEND
Паскаль
Алгоритмический язык
begin
readln(N);
while N > 0 do
begin
digit := N mod 10;
N := N div 10;
end;
writeln(digit)
нач
цел N, digit, sum
ввод N
нц пока N > 0
все
кц
вывод digit
Си
int main()
int N, digit, sum;
while (N > 0)
if (digit < 7)
Последовательно выполните следующее.
1. Напишите, что выведет эта программа при вводе числа 456.
2. Приведите пример такого трёхзначного числа, при вводе которого программа выдаёт верный ответ.
3. Найдите все ошибки в этой программе (их может быть одна или несколько). Известно, что каждая ошибка затрагивает только одну строку и может быть исправлена без изменения других строк. Для каждой ошибки:
1) выпишите строку, в которой сделана ошибка;
2) укажите, как исправить ошибку, т.е. приведите правильный вариант строки.
Достаточно указать ошибки и способ их исправления для одного языка программирования. Обратите внимание, что требуется найти ошибки в имеющейся программе, а не написать свою, возможно, использующую другой алгоритм решения. Исправление ошибки должно затрагивать только строку, в которой находится ошибка.
Решение использует запись программы на Паскале. Допускается использование программы на любом из четырёх других языков.
1. Программа выведет число 4.
2. Пример числа, при вводе которого программа выдаёт верный ответ: 835.
Программа работает неправильно из-за неверной выводимой на экран переменной и неверного увеличения суммы. Соответственно, программа будет работать верно, если в числе старшая цифра (крайняя левая) равна сумме цифр, меньших 7.
3. В программе есть две ошибки.
Первая ошибка. Неверное увеличение суммы.
Строка с ошибкой:
sum := sum + digit;
Вторая ошибка. Неверный вывод ответа на экран.
Строка с ошибкой:
Для заданного положительного вещественного числа A необходимо найти максимальное целое число K, при котором выполняется неравенство
(при K = 0 сумма считается равной 0).
Для решения этой задачи ученик написал такую программу.
Бейсик
Python
DIM K AS INTEGER
INPUT A
WHILE S < A
WEND
PRINT K
Алгоритмический язык
Паскаль
нач
вещ a, s
цел k
ввод a
нц пока s
кц
вывод k
k: integer;
begin
read(a);
end;
write(k);
Си
int main()
double a, s;
int k;
return 0;
Последовательно выполните следующее.
1. Напишите, что выведет эта программа при вводе числа 1.2.
2. Приведите пример числа, при вводе которого программа даст верный ответ.
3. Найдите в программе все ошибки (их может быть одна или несколько).
Для каждой ошибки выпишите строку, в которой она допущена, и приведите эту же строку в исправленном виде.
Обратите внимание: вам нужно исправить приведённую программу, а не написать свою. Вы можете только исправлять ошибочные строки; удалять строки или добавлять новые строки нельзя. Постарайтесь также не внести новые ошибки – за это оценка снижается.
Решение использует запись программы на Паскале. Допускается использование программы на других языках.
1. При вводе числа 1.2 программа выведет число 2.
2. Примеры чисел, при вводе которых программа выводит верный ответ: 1.6, 2.05.
Программа содержит две ошибки, одна из которых приводит к увеличению ответа, другая – к уменьшению.
В некоторых случаях эти ошибки компенсируют друг друга, и ответ оказывается правильным. Это происходит, если значение A попадает в один из следующих диапазонов: 1.5 < A < 1.83, 2 < A < 2.08.
3. Программа содержит две ошибки.
1) Неверная инициализация. Начальное значение S должно быть равно нулю.
В приведённом варианте вычисленная сумма оказывается на 1 больше правильного значения.
Строка с ошибкой:
2) Неверное определение ответа. Приведённая программа находит не максимальное K, при котором выполняется неравенство, а минимальное, при котором оно не выполняется, то есть увеличивает верное значение на 1.
Кроме того, использованный порядок действий в цикле (увеличение K после увеличения S) приводит к увеличению ещё на 1. Это можно было бы исправить, изменив порядок действий в цикле и уменьшив K после завершения цикла, но эти действия не разрешены по условию задачи.
Поэтому для исправления ошибки можно просто скорректировать значение при выводе.
Сколько ошибок в программе? Это вопрос, который волнует каждого программиста. Особую актуальность придает ему принцип кучкования ошибок, согласно которому нахождение в некотором модуле ошибки увеличивает вероятность того, что в этом модуле есть и другие ошибки. Точного ответа на вопрос о количестве ошибок в программе очень часто дать невозможно, а вот построить некоторую оценку — можно. Для этого существуют несколько статических моделей. Рассмотрим одну из них: Модель Миллса.
В 1972 г. суперпрограммист фирмы IBM Харлан Миллс предложил следущий способ оценки количества ошибок в программе. Пусть у нас есть программа. Предположим, что в ней N ошибок. Назовем их естественными. Внесем в нее дополнительно M искусственных ошибок. Проведём тестирование программы. Пусть в ходе тестирования было обнаружено n естественных ошибок и m искусственных. Предположим, что вероятность обнаружения для естественных и искусственных ошибок одинакова. Тогда выполняется соотношение:
Мы нашли один и тот же процент естественных и искусственных ошибок. Отсюда количество ошибок в программе:
Количество необнаруженных ошибок равно (N-n).
Например, пусть в программу внесено 20 искусственных ошибок, в ходе тестирования было обнаружено 12 искусственных и 7 естественных ошибок. Получим следущую оценку количества ошибок в программе:
Количество необнаруженных ошибок равно (N-n) = 12 — 7 = 5.
Легко заметить, что в описанном выше способе Миллса есть один существенный недостаток. Если мы найдем 100% искусственных ошибок, это будут означать, что и естественных ошибок мы нашли 100%. Но чем меньше мы внесем искусственных ошибок, тем больше вероятность того, что мы найдём их все. Внесем единственную исскуственную ошибку, найдем ее, и на этом основании объявим, что нашли все естесственные ошибки! Для решение такой проблемы Миллс добавил вторую часть модели, предназначенную для проверки гипотезы о величине N:
Предположим, что в программе N естественных ошибок. Внесём в неё M искусственных ошибок. Будем тестировать программу до тех пор, пока не найдем все искусственные ошибки. Пусть к этому моменту найдено n естественных ошибок. На основании этих чисел вычислим величину C:
Величина C выражает меру доверия к модели. Это вероятность того, что модель будет правильно отклонять ложное предположение. Например, пусть мы считаем, что естественных ошибок в программе нет (N=0). Внесем в программу 4 искусственные ошибки. Будем тестировать программу, пока не обнаружим все искусственные ошибки. Пусть при это мы не обнаружим ни одной естественной ошибки. В этом случае мера доверия нашему предположению (об отсутствии ошибок в программе) будет равна 80% (4 / (4+0+1)). Для того чтобы довести ее до 90% количество искусственных ошибок придется поднять до 9. Следущие 5% уверенности в отсутствии естественных ошибок обойдутся нам в 10 дополнительных искусственных ошибок. M придется довести до 19.
Если мы предположим, что в программе не более 3-х естественных ошибок (N=3), внесем в нее 6 искусственных (M=6), найдем все искусственные и одну, две или три (но не больше!) естественных, то мера доверия к модели будет 60% (6 / (6+3+1)).
Значения функции С для различных значений N и M, в процентах:
Таблица 1 — с шагом 1;
Таблица 2 — с шагом 5;
Из формул для вычисления меры доверия легко получить формулу для вычисления количества искусственных ошибок, которые необходимо внести в программу для получения нужной уверенности в полученной оценке:
Количество исскуственных ошибок, которые необходимо внести в программу, для достижения нужной меры доверия, для различных значений N:
Таблица 3 — с шагом 1;
Таблица 4 — с шагом 5;
Модель Миллса достаточно проста. Ее слабое место — предположение о равновероятности нахождения ошибок. Чтобы это предположение оправдалось, процедура внесения искусственных ошибок должна обладать определенной степенью «интеллекта». Ещё одно слабое место — это требование второй части миллсовой модели отыскать непременно все искусственные ошибки. А этого может не произойти долго, может быть, и никогда.
Современные программисты живут в интересное время, когда программное обеспечение проникает буквально во все сферы жизни человека и начинает существовать в бесчисленном количестве устройств, плотно вошедших в наш обиход. Сейчас уже никого не удивишь программами в холодильниках, часах и кофе-машинах. Однако, параллельно с торжеством удобства растет и зависимость людей от умной техники. Неизбежное последствие: на первый план выходит надежность программного обеспечения. Сложно кого-то напугать взбесившейся кофеваркой, хотя и она может натворить много бед (литры кипящего кофе стекают по вашей белоснежной мраморной столешнице. ). Но мысль о растущих требованиях к качеству ПО важна, поэтому поговорим об ошибках в коде, которые повлекли за собой существенные траты времени и денег.
Цель повествования — борьба с идеей, что к дефектам в программах можно относиться так же пренебрежительно, как и раньше. Теперь ошибки в программах — это не только неправильно нарисованный юнит в игре, сейчас от кода зависит сохранность имущества и здоровье людей. В этой статье я хочу привести несколько новых примеров необходимости трепетного отношения к коду.
Нельзя отрицать, что сложные программы все активнее входят в нашу жизнь: управляемая со смартфона бытовая техника, гаджеты, наделенные таким функционалом, о котором еще 10 лет назад не приходилось и мечтать и, конечно, более сложное ПО на заводах, в автомобилях и т.д. Любая программа создается человеком и, чем она умнее, тем опаснее ее сбой.
Поговорим о деньгах, потерянных из-за ошибок в программном обеспечении, и росте нашей зависимости от программного кода. Тема неоднократно обсуждаемая (в том числе моим коллегой — Андреем Карповым — "Большой Калькулятор выходит из-под контроля"), и каждый новый пример доказывает: качество кода — не то, чем можно пренебрегать.
Космос
Дорогой дефис
Ревизионная комиссия провела расследование, в ходе которого было выявлено: причиной аварии послужила программная ошибка, из-за которой поступали неверные управляющие сигналы.
Программист неправильно перевел написанную формулу в компьютерный код, пропустив макрон или надчёркивание (что значит "n-ое сглаживание значения производной радиуса R по времени").
Программа даже незначительные изменения скорости воспринимала как весьма существенные и проводила корректировку курса (источник).
Цена "пропущенного дефиса" — 18 млн долларов (на тот момент).
Российский GPS, опустившийся на дно
Ярким примером того, как из-за программной ошибки могут быть потеряны миллионы, является относительно недавний случай. Казалось бы, в 21 веке есть все необходимое для написания надёжных программ, особенно, если речь идет о космической отрасли. Опытные специалисты с отличным образованием, хорошее финансирование, возможность использования лучших инструментов для проверки программного обеспечения. Все это не помогло. 5 декабря 2010 года ракета-носитель "Протон-М" с тремя спутниками "Глонасс-М" — российский аналог GPS, упала в Тихий океан.
Причину аварии, после завершения расследования, озвучил официальный представитель Генпрокуратуры РФ Александр Куренной: "Установлено, что причиной аварии стало применение неверной формулы, в результате чего масса заправленного в бак окислителя разгонного блока жидкого кислорода на 1582 кг превысила максимально допустимую величину, что повлекло выведение ракеты-носителя на незамкнутую орбиту и его падение в акваторию Тихого океана" (источник).
Интересный момент в этой истории — документ о необходимости корректировки формулы был, но его списали как исполненный. Руководство же не удосужилось проверить выполнение своих указаний. Все причастные к аварии лица были привлечены к уголовной ответственности и крупным штрафам. Но это не компенсирует потери, составившие 138 миллионов долларов.
Автомобили
Еще в 2009 году профессор информатики в Техническом университете Мюнхена, эксперт по программному обеспечению в автомобилях Манфред Бра, сказал: "Программное обеспечение автомобиля премиум-класса содержит около 100 миллионов строк кода" (источник). С того момента прошло уже восемь лет, и совсем не обязательно быть поклонником передачи Top Gear, чтобы заметить: современные автомобили — это настоящие интеллектуальные машины.
По заявлению все того же эксперта, стоимость программного обеспечения и электроники в автомобиле составляет порядка 40% от его цены на рынке. И это касается бензиновых моторов, что же говорить о гибридах и электрокарах, где это значение равно примерно 70%!
Когда электронная начинка становится сложнее механической, то возрастает ответственность разработчиков программного обеспечения. Баг в одной из ключевых систем, например, торможения, представляет гораздо большую опасность, чем порвавшийся тормозной шланг.
Садиться за руль современных комфортных и "умных" авто или ездить на олдскульных, но понятных машинах? Решать вам, я же предлагаю небольшую подборку багов в программном обеспечении автомобилей.
И снова Toyota
Японские автомобили Toyota имеют положительную репутацию, но периодически в СМИ попадает информация об отзыве некоторого количества машин. В нашем блоге уже есть статья о программной ошибке в Toyota — "Toyota: 81 514 нарушений в коде", но этот случай, к сожалению, не единичный.
В 2005 году было отозвано 160 тыс. гибридов Toyota Prius 2004 года выпуска и начала 2005. Проблема заключалась в том, что машина могла в любой момент остановиться и заглохнуть. На устранение бага было затрачено около 90 минут на одно транспортное средство или около 240 тыс. человеко-часов.
Chrysler и Volkswagen
В мае 2008 года Chrysler отозвал 24535 автомобилей Jeep Commanders 2006 года выпуска. Причина — программная ошибка в модуле управления автоматической трансмиссией. Сбой приводил к неконтролируемой остановке двигателя.
В июне того же года Volkswagen отзывает около 4000 Passat и 2500 Tiguans. Здесь ошибка в программном обеспечении оказывала воздействие на увеличение оборотов двигателя. Показания тахометра начинали ползти вверх при включенном кондиционере.
Стоит ли говорить о том, что процесс отзыва автомобилей связан с огромными финансовыми затратами. Но для таких крупных компаний-производителей гораздо страшнее не денежные потери, а упадок доверия потребителей. При огромной конкуренции на автомобильном рынке, одна такая оплошность может обернуться очень и очень негативными последствиями. Восстановление репутации надежного производителя — дело нелегкое.
Tesla
Выше речь шла об обычных автомобилях, причем не самых последних годов выпуска. Как видите, даже в них возможны программные ошибки, что уж говорить об активно популяризируемых экологически безопасных электрокарах.
Поговорим, конечно же, о Tesla Model S. 7 мая 2016 Джошуа Браун, прославившийся благодаря своим роликам на YouTube, посвященным восхвалениям электромобиля, попал в автокатастрофу. Он находился за рулем Tesla Model S. Будучи на 100% уверенным в интеллекте машины, он доверился автопилоту. Результат доверия трагичный — от полученных травм Джошуа скончался на месте.
Катастрофа получила широкую огласку. Началось расследование. Удалось установить, что, по всей видимости, Браун самостоятельно не следил за дорогой, а автопилот столкнулся с ситуацией, которая не нашла отражение в его программном коде. Перед Tesla Джошуа двигался грузовик с прицепом. Автомобиль планировал выполнить маневр — левый поворот, соответственно, требовалось сбавить скорость. Но Tesla, едущий позади, не начал тормозить, т.к. системы автопилота не распознали находящийся впереди объект.
Произошло это, скорее всего, из-за яркого солнца. Лучи отражались от прицепа и автопилот воспринял грузовик единым целым с небом. В официальном докладе это объяснялось следующим образом: "Системы автоматического торможения Теслы являются технологией избегания столкновения в редких случаях и не спроектированы для надежного выполнения во всех режимах аварии, включая столкновения в результате пересечения путей" (источник). Полный отчет об аварии находится в свободном доступе.
Иными словами, автопилот призван помогать водителю (более совершенный круиз-контроль, грубо говоря), а не заменять его функции. Конечно, репутацию Tesla такое оправдание не сильно спасло. Работы над совершенствованием программного обеспечения продолжились, но Tesla Model S с дорог отозваны не были.
Представители компании привели следующую дорожную статистику: "На каждые 90 млн. миль пройденного пути умирает один человек. В противоположность, люди проезжали 130 млн. миль на автопилоте Тесла перед тем, как была подтверждена первая смерть. Сейчас эта цифра поднялась до 200 млн." (источник)
С одной стороны, такая статистика свидетельствует о том, что электрокар безопаснее, но готовы ли вы доверить свою жизнь, жизнь пассажиров и других участников дорожного движения программе?
И это не риторический вопрос. Судя по новостям биржи, вопреки нашумевшей аварии, акции Tesla выросли на 50% с начала 2017 года. Способствуют этому два значимых фактора: популярность движений, выступающих за улучшение экологии в мире, и высокий личный рейтинг главы Tesla — Илона Маска.
Всеобщий масштаб — Беда 2038 года
Не могла не привести в завершении статьи этот пример. Подробно о Беде 2038 года вы можете прочитать в статье "2038: остался всего 21 год", я же остановлю внимание на одном важном моменте.
Оборудование для заводов: всевозможные станки, конвейеры; бытовая техника и другие сложные агрегаты, оснащенные специализированным программным обеспечением, имеют достаточно продолжительный срок службы. Вероятность того, что выпущенный в 2017 году станок будет функционировать и в 2038 очень и очень велика. Отсюда логично сделать вывод: проблема, когда 32-битные значения типа time_t больше не смогут корректно отображать даты, уже актуальна!
Если сейчас разработчики программного обеспечения не будут брать ее в расчет, то что же ждет программистов в 2038 году?! Есть все шансы на то, что ПО для встроенных систем устроит немало сюрпризов. Но, думаю, мы будем тому свидетелями.
Заключение
Возможно, приведенные в статье примеры покажутся слишком эпичными. Безусловно, широкую огласку получают только трагические случаи. Но я уверена, что в каждой компании, занимающейся разработкой программного обеспечения, есть история о том, как всего одна ошибка повлекла за собой множество проблем, пусть и в локальном масштабе.
Можно ли найти виновного? Иногда да, иногда — нет. Но смысл не в том, чтобы найти крайнего и каким-то образом покарать его. Идея в другом — программы усложняются, они все больше входят в нашу жизнь, а значит и требования к надежности кода растут. Увеличивается цена типовых ошибок, ответственность за качество кода тяжелой ношей ложится на плечи разработчиков.
Какой же выход? Модернизировать процесс разработки. Дать программистам помощников — специальные программы для выявления и устранения ошибок. Комплексное использование современных методик существенно снижает вероятность того, что баг в коде не будет обнаружен на этапе разработки.
Желаю вам не допускать промахов, а вашим проектам никогда не попасть в подборку, аналогичную той, что приведена в этой статье.
Я учусь на своих ошибках. Ругаю себя за это, но продолжаю ошибаться. С другой стороны - это всё-таки лучше, чем не учиться совсем, и наступать на одни и те же грабли бесконечно.
При создании программ, даже простых, ошибки неизбежны. Поэтому для поиска ошибок во всех средствах разработки имеются особые инструменты для отладки. Но сегодня не об отладке и не о поиске ошибок. Сегодня о видах ошибок, которые встречаются в программах.
Итак, основных вида всего три:
Синтаксические ошибки в программах
Синтаксические ошибки - это ошибки синтаксиса (а то бы вы не догадались))). То есть ошибки правил языка. Например, для Паскаля это будет синтаксической ошибкой:
Потому что после первой строки нет точки с запятой.
что можно перевести как
То есть компилятор говорит нам: я ожидал увидеть точку с запятой, а нашёл идентификатор READLN .
Логические ошибки в программах
Это самые противные и самые труднонаходимые ошибки. Программа может быть написана совершенно правильно с точки зрения синтаксиса языка, и при этом она будет неправильно работать. Потому что программист допустил где-то логическую ошибку.
И компилятор вам ничего об этой ошибке не расскажет, потому что правила языка не нарушены.
Поиски таких ошибок могут занять много времени и отнять у вас немало здоровья. Поэтому при разработке программ лучше не торопиться и стараться не допускать логических ошибок.
Пример логической ошибки:
Эта ошибка довольно безобидная. Здесь мы имеем просто бессмысленный код, который не причинит никакого вреда. Однако представьте, что программа должна выдавать какой-то сигнал тревоги, если i = 15 . Тогда получится, что никакого сигнала пользователь никогда не услышит, даже если случилось что-то страшное. А всё потому, что программист немного ошибся. Вот так вот и падают ракеты и самолёты…
Распространённые логические ошибки в С++ вы можете посмотреть здесь.
Ошибки времени выполнения программы
Даже если исходный код не содержит ни логических, не синтаксических ошибок, это ещё не означает, что ваша программа безупречна. Потому что ошибки могут возникнуть в ходе выполнения программы. Например, случайно будет удалён файл, который должна читать программа, и она не сможет его найти. Если не принять мер, то программа может завершиться аварийно. А пользователям такое поведение программ очень не нравится.
Одна из самых рапространённых ошибок времени выполнения - это неожиданное деление на ноль. Пример:
Что здесь такого? Всё правильно и с точки зрения логики, и с точки зрения синтаксиса. И в большинстве случаев программа отработает без каких-либо неожиданностей.
Но представьте, что пользователь введёт ноль. Что тогда будет? Правильно - попытка деления на ноль. А на ноль делить нельзя. Поэтому во время выполнения этой программы произойдёт ошибка, которая очень расстроит пользователя. Потому что в случае, например, с консольным приложением программа просто закроется, и пользователь не поймёт, что это было. Но зато поймёт, что программа - говно, и программы от этого разработчика лучше больше никогда не использовать.
В данном случае, если вы не уверены на 100%, что y будет отличаться от нуля, надо всегда делать проверку на ноль. И хороший код должен быть хотя бы таким:
Ну что же. На этом с видами ошибок пока всё. Изучайте программирование и поменьше ошибайтесь.
Сколько ошибок допущено в программе? Найдите все ошибки и исправьте их (В Паскале)
Program zadacha;
Var a: integer;
begin
writeln('введите число а')
readln(a);
if a>0 then a:=a+1;
writeln (' Полученное число ' a)
end.
Ответы
writeln('введите число а'); // Точка с запятой
writeln (' Полученное число ', a) // запятая
writeln('введите число а'); - точка с запятой в конце оператора
writeln (' Полученное число ', a); - запятая перед выводом значения переменной и точка с запятой в конце оператора
вони можуть знаходитися в бібліотечному файлі : сstdlib .
ай скористатися функцією : rand .
Другие вопросы по Информатике
Ваня придумал новый алгоритм сортировки и сейчас тренируется на кубиках с цифрами, чтобы понять, как он работает. перед ним на столе лежат кубики с числами от 1 до 10 (на каждом кубике записано одно число), выложенные в таком порядке: 5 4 10 1 6 7 8 9 2 3 за одну операцию ваня берет несколько рядом стоящих кубиков как одну конструкцию, переворачивает и кладет на прежнее место. например, если бы кубики лежали в таком порядке: 1 2 3 4 5 6 7 8 9 10, а ваня взял бы кубики начиная с кубика с цифрой 4 и заканчивая кубиком с цифрой 9 и перевернул бы, то получилась бы такая последовательность: 1 2 3 9 8 7 6 5 4 10. то, что какие-то кубики после выполнения подобных операций окажутся лежащими вверх ногами, ваню не смущает. кроме того, ваня различает кубик с цифрой 6 и кубик с цифрой 9 (они разного цвета, поэтому невозможно одну цифру получить из другой при перевороте). ване понять, какое наименьшее количество таких операций потребуется, чтобы кубики стали лежать в порядке возрастания: 1 2 3 4 5 6 7 8 9 10. комментарий. если бы у него было всего 4 кубика и они лежали в таком порядке: 4 1 3 2, то наименьшее количество операций было бы равно двум: сначала переворачиваем кусок из первых двух кубиков слева, получаем 1 4 3 2, затем переворачиваем кусок из трех кубиков справа, получаем 1 2 3 4.
Паскальнаписать программу для вычисления всех сторон прямоугольного треугольника с катетом лежащим в против угла 30 градусов
Читайте также: