Как мы научили машины считать и думать за нас? Часть 21: Как бороться с программными ошибками?

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

Как мы научили машины считать и думать за нас? Часть 21: Как бороться с ошибками в программе ?» /> </p><p class= В задачи испытателей входит выявление ошибок, не замеченных авторами ПО

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

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

Тестирование или борьба с ошибками

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

В ранний период развития информатики (до 1956 г.) упомянутая выше отладка (направленная на выявление очевидных ошибок, допущенных программистом) и тестирование программы трактовались как одно и то же действие. Это была просто эмпирическая проверка пригодности к использованию созданной программы. В 1957 г. Чарльз Л. Бейкер (корпорация RAND) провел различие между отладкой, т. е. отладкой, и тестированием, которое всесторонне исследует свойства (преимущества и недостатки) программ.

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

Помните: обычно вы не видите свою собственную ошибку!

Профессиональные тестировщики

Первым, кто организовал специальную испытательную группу, был Джеральд М. Вайнберг в 1958 году. У Вайнберга были причины беспокоиться о высоком качестве программ, написанных его командой, потому что эта команда разрабатывала программное обеспечение для проекта «Меркурий» — первого в Америке пилотируемого полета «Космос». Было очевидно, что любая ошибка в программе могла стоить космонавту жизни и стать позором перед всем миром. Благодаря настойчивости Вайнберга программное обеспечение миссии «Меркурий» работало безупречно, и 5 мая 1961 года первый американец (Алан Шепард) благополучно полетел в космос.

Тестирование программного обеспечения стало обязательной процедурой для большинства крупных ИТ-проектов — и продолжается по сей день. С другой стороны, хорошие софтверные компании имеют команды любознательных и даже профессионально злонамеренных тестировщиков, которые проверяют программу при любых обстоятельствах. Программисты иногда называют таких тестировщиков «профессиональными идиотами», потому что они пытаются проверить, как поведет себя программа, когда использующий ее человек отдает даже самые идиотские команды. Конечно, на глупый вопрос компьютер не даст мудрого ответа, потому что это невозможно, но он должен вести себя как боксер после сильного удара — может покачнуться, но не упасть! Методологическая основа этого действия была определена в 1975 году Томом Гилбом, который в своей работе «Законы ненадежности» точно описал взаимосвязь между ошибкой человека и ошибкой системы.

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

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

Не следует, однако, забывать, что еще в 1976 году один из пионеров информатики Эдсгер В. Дейкстра сформулировал один из важнейших принципов тестирования: «Тестирование выявляет наличие дефектов, а не их отсутствие». Иными словами, если проверка показала, что в программе есть какие-то «баги», значит, они действительно были (и их, конечно, нужно удалить). Но если тест прошел успешно и ничего не нашел, это не обязательно означает, что в программе нет ошибок. Они могут быть — просто не обнаружены!

Теоретический подход

Тот факт, что при тестировании программного обеспечения никогда нельзя быть уверенным в том, что программа не содержит ошибок, привел к попытке использовать сложную теорию для решения проблемы. Были попытки создать методы, которые позволяли бы математически доказывать правильность программ так же, как доказывали бы истинность математических теорем. Поскольку искусственный интеллект также разработал автоматические методы доказательства теорем, казалось, что сам компьютер может проверить программу, написанную человеком. Он должен был использовать подход, который Аллен Ньюэлл и Герберт Саймон впервые применили в 1956 году для создания программы Logic Theorist, которая стала одной из вех в исследованиях искусственного интеллекта. Он очень эффективно доказывал теоремы в области математической логики и прославился доказательством всех теорем из монументального труда Бертрана Рассела под названием «Принципы математики». Мало того, что программа сама предоставила необходимые доказательства, она также нашла доказательства лучше, чем те, которые дал Рассел в нескольких случаях, что сделало ее создателей очень известными.

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

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

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

Могла ли проблема «тысячелетнего клопа» возвращается???

В предыдущей колонке я рассказывал об ИТ-баге, который мог сильно потрясти мир из-за неудачного способа записи дат в ИТ-системах. Было много бед, но кризис был преодолен. Пользователи операционных систем Unix и смоделированных на ее основе Linux смеялись над проблемой «ошибки тысячелетия» (о них обоих я напишу в следующих эпизодах этой серии), потому что время в этих системах определяется подсчетом количества секунд. которые прошли с «начала эры Unix». Эта эпоха началась 1 января 1970 года, ровно в 00:00:00. Во всяком случае, все программы Unix и Linux работают, считая эти секунды. Но это также «сломит» их. Причина проста: эти подсчитанные секунды хранятся как 32-битные целые числа. Казалось бы, таких чисел можно записать много, а именно 2 147 483 647. Более 2 миллиардов! Но всему есть конец… и запись бегущих секунд закончится 19 января 2038 года в 03:14:07 UTC. В следующую секунду счетчик переполнится и установит дату… 13 декабря 1901 года в 18:30. 20:4:52 МСК.

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

Хорошая шутка в конце

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

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

Пользователь звонит в службу: — Я использую Windows, и мой компьютер дымит!

Техник терпеливо объясняет, что проблема связана не с программой, а с электроникой. Блок питания просто сломался. Но пользователь настаивает на том, что все, что ему нужно, это пароль, чтобы проблема исчезла. После долгого разговора измученный техник говорит: — Открою секрет. Ну и есть эта нигде не описанная команда Windows, которую мы используем в таких случаях. Приходится заходить в панель управления и вводить команду: «Не курить!»…

— Я знал, знал, знал! — взволнованно кричит пользователь.

Он звонит снова через мгновение:

— Я набрал «Не курить!», а компьютер все еще дымит!

— Ах да, потому что это новая команда, а ваш блок питания устарел и несовместим с нашими новыми командами. Вы должны заменить блок питания на новый и заказать «Не курить!» будет работать.

— Хорошо, сделаю! — говорит довольный пользователь.

И идет замена блока питания…

Автор — профессор AGH в Кракове

Оцените статью
( Пока оценок нет )

В профессии с 2008 года. Профиль - международные отношения и политика. Почта: andreykozlov07@gmail.com

Последние новости 24 часа
Как мы научили машины считать и думать за нас? Часть 21: Как бороться с программными ошибками?
Йоанна Чвик: Экзамен на аттестат зрелости по польскому языку. Каштаны опаздывают