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

Ошибки... Любой программист, хоть раз в жизни выпустивший из-под своего пера "Hello, world!", знает, что ошибки - его верные спутники и симбионты. Разве можно представить современное программное обеспечение без них? Операционные системы, текстовые процессоры, системы управления производством, да, пожалуй, любая крупная программа управления предприятием может быть нашпигована ими как булка изюмом. Около пятнадцати лет назад было высказано предположение, что алгоритмы, точнее, их правильность (соответствие поставленным условиям), можно доказывать как, например, теоремы в математике. Актуальность и необходимость фундаментальных разработок к этой области нет смысла отстаивать с пеной у рта. Автоматическое управление процессами (АУП) вторгается в нашу жизнь с каждым днем все настойчивей и уверенней. Конечно, если при АУП пришивания пуговиц вред в случае сбоя или ошибки не велик, то когда речь заходит о системах жизнеобеспечения или управления химическим производством, эффект может быть ошеломляющим. Вспомним фильм, которым бредили все подростки восьмидесятых, - "Терминатор". Мировой катаклизм случился именно из-за несовершенства программного обеспечения ЭВМ.

Найти и обезвредить

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

Математический аппарат

Такой подход далек от совершенства, самые губительные ошибки зачастую оказываются в логике. Давайте вспомним "червяка Морриса". Это было довольно громкое дело. Воспользовавшись известной ошибкой, программа выделяет в стеке буфера для вводимых данных и не проверяет выход за его границы, например, fingerd в BSD "червяк" перековал кусок кода и поддельный стековый кадр, передававший управление на этот код. Код, в свою очередь, запускал на целевой системе копию командного интерпретатора с привилегиями суперпользователя, затем "червь" использовал командный интерпретатор для втягивания в систему своего тела. "Червь", фактически, "вывел из строя шесть тысяч компьютеров более чем в 700 университетах, лабораториях, фирмах и федеральных агентствах. Ущерб, нанесенный вирусом, составил сто миллионов долларов, а затраты на ликвидацию последствий превысили 250 тысяч долларов. Скажем, исследовательскому центру НАСА пришлось на два дня закрыть свою сеть для восстановления нормального обслуживания 52000 пользователей". На судебном разбирательстве была предпринята попытка объяснить деструктивное действие "червя" в сети из-за постоянного размножения ошибкой в программе, то есть снять с себя ответственность. Как в таком случае можно доказать, что виновата не ошибка в алгоритме, а именно злоумышленные действия автора?

Строгость и закон

Идеальный вариант - это когда мы могли бы доказывать правильность программы, а не ссылаться на тестирование как вариант проверки ее пригодности. Конечно, любое доказательство не даст абсолютной гарантии правильности работы, ведь и в нем могут быть ошибки и неточности. Тем не менее, усилия, потраченные на доказательство, окупятся с лихвой. Ведь уже одна попытка привести алгоритм к какой-то формальной модели заслуживает похвалы. Формализация такого подхода позволит в будущем переложить этот процесс "на плечи" программного обеспечения. В настоящее же время в области доказательства правильности программ проводятся интенсивные исследования. Выделим три основные направления: 1. Методы доказательства (частичной) правильности или конечности. 2. Проблемы разработок программ и создания языков программирования. 3. Механизация процесса доказательства правильности. Все эти направления перекрываются и тесно взаимодействуют между собой. Мы рассмотрели наиболее простой и тривиальный способ, более популярен метод индуктивных утверждений и структурной индукции. Метод индуктивных утверждений впервые был предложен Флойдом и Науром. Барстелл в 1969 году предложил метод структурной индукции. Желание создавать программы, для которых было бы легко удостовериться в их правильности, привлекло внимание к проблеме конструирования программ и разработки языков программирования. После знаменитого письма Дейкстра об операторе перехода (GO TO) появились работы, где прослеживается влияние проблемы доказательства правильности на разработку языка программирования. Среди языков, в которых слышны отголоски доказательства правильности, можно выделить Alphard, Pascal, Clu и Nucleus. Теория доказательства правильности программ еще слишком юна, она ждет своих героев и героинь. Как знать, может быть, двадцать первый век сдвинет этот камень с мертвой точки.

Корпоративный подход

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

Rational Robot (www.rational.com) - средство функционального тестирования, базирующееся на объектно-ориентированной технологии, и этим оно отличается от традиционных средств тестирования GUI (Graphics User Interface). Этот продукт позволяет тестировать множество свойств различных элементов интерфейса, в том числе и не отображаемых. Проверка возможна как для всех объектов, так и для каждого в отдельности. Продукт предоставляет два режима работы: автоматический и ручной (создание собственных скриптов для тестирования). В автоматическом режиме Rational Robot записывает последовательность действий, которые тестировщик выполняет с "подопытной" программой, а затем генерирует необходимый скрипт. В ручном режиме пользователь сам задает на специальном языке сценарий тестирования. Скрипты, создаваемые в Rational Robot, обеспечивают поиск ошибок в приложении, оставаясь виртуально независимыми от внесенных изменений и платформы. Без дополнительных изменений скрипты могут использоваться в различных версиях OS Windows. Объектное тестирование обеспечивает быстрое создание скриптов, которые в дальнейшем можно легко изменять, создавать заново и воспроизводить. Rational Robot также допускает тестирование сложных систем клиент/сервер на платформе Windows. Внедрение подобного универсального инструмента для всеобъемлющего GUI тестирования даст существенный прирост в эффективности проводимого тестирования.

WinRunner и LoadRunner (www.mercuryinteractive.com). WinRunner поддерживает работу с протоколом мобильного интернета WAP, обладает функцией подтверждения транзакций и позволяет протестировать беспроводные приложения, а также упростить процесс создания тестов. В LoadRunner будет добавлена усовершенствованная система отладки транзакций, корпоративное тестирование JavaBeans и новые возможности для отлаживания XML-данных.

Visual Test (www.rational.com) - это еще один флагман от компании Rational. Ставка при проталкивании на рынок этого продукта делалась на его визуальную среду. Тесное партнерство с Microsoft дало продукту приставку в названии и среду, сходную с VisualStudio. Инструмент позволяет производить тестирование, начиная от 32-битного Windows-приложения, компонентов ActiveX, DLL, сервер автоматизации OLE (OLE Automation Server) или приложение на основе Web. В качестве скрипт-языка используется TestBasic, созвучность с VisualBasic и тут не случайна, расширенный множеством функций для тестирования специализированных конструкций TestBasic - прямой наследник VisualBasic. По словам компьютерной прессы, "TestBasic предоставляет простой доступ к Windows API и открытой архитектуре, которая делает этот язык расширяемым. Данный продукт обеспечит надежное функциональное тестирование".

Андрей ЛАПОУХОВ,
alapouhov@yahoo.com