Лента новостей. Сколько стоят ошибки? Ошибки бывают разные.
Всемирно известными примерами таких ошибок являются следующие.
1) Неудача при запуске первого американского спутника к Венере случилась вероятнее всего, из-за ошибки в программе - вместо требуемой в операторе точки была поставлена запятая.
Вот так был записан
DO 50 I = 12,525, а нужно
DO 50 I = 12.525.
2) Потеря связи с космической станцией "Фобос-1" (СССР) произошла из-за ошибочной команды, переданной с Земли на бортовой компьютер.
3) Причиной осложнений, возникших при возвращении на Землю советско-афганского и советско-французского экипажей, явились ошибки, допущенные в программном обеспечении бортовых компьютеров.
В 1983 г. произошло наводнение в юго-западной части США. Причина заключалась в том, что в компьютер были введены неверные данные о погоде, в результате чего он дал ошибочный сигнал шлюзам, перекрывающим реку Колорадо.
Досточно свежие примеры:
1) Программа виновна в гибели самолета (osp.ru Сводка новостей от 30.06.2000)
Федеральный суд Майами, рассмотревший дело о крушении самолета Boeing 757 авиакомпании American Airlines в Колумбии в 1995 году, вынес частное определение в отношении компании Honeywell Air Transport Systems и производителя программного обеспечения - Jeppesen Sanderson. Во время полета из Майами в Колумбию пилоты ввели в бортовой компьютер некорректный код, а тот выдал неправильную команду, из-за чего лайнер врезался в гору.
Жертвами катастрофы стали 159 человек.
2) Из-за хакера могли погибнуть астронавты
Сенсационное заявление сделала 3 июля 2000 года генеральный инспектор НАСА Roberta Gross в интервью программе "Панорама" телекомпании BBC.
Оказывается, в 1997 году из-за действий некоего хакера под угрозой оказались жизни астронавтов
на корабле "Шаттл", летевшем к российской космической станции "Мир". В результате неких манипуляций хакеру удалось вызвать перегрузку информационной системы, которая непрерывно передает информацию о состоянии здоровья космонавтов, что в итоге могло сказаться на
функционировании всей системы связи с космическим кораблем.
К счастью, удалось быстро переключить связь на резервную систему, так что обошлось без серьезных последствий.
Тестирование - способ обеспечения качества.Недостаточно выполнить проектирование и кодирование ПО, необходимо также обеспечить его соответствие требованиям и спецификациям.
С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными) с целью установить соответствие различных свойств и характеристик приложения заказанным свойствам.
Многократно проводимые исследования показали, что чем раньше обнаруживаются те или иные несоответствия или ошибки, тем больше вероятность их правильного исправления (рис. 9.1, а) и ниже его стоимость (рис. 9.1, б) [7].
Современные технологии разработки ПО предусматривают раннее обнаружение ошибок за счет выполнения контроля результатов всех этапов и стадий разработки.
На начальных этапах такой контроль осуществляют в основном вручную или с использованием CASE-средств, на последних - он принимает форму тестирования.
Тестирование - это процесс выполнения программы, целью которого является выявление ошибок.
Никакое тестирование не может доказать отсутствие ошибок в хоть сколько-нибудь сложном программном обеспечении. Для такого программного обеспечения выполнение полного тестирования, т. е. задания всех возможных комбинаций исходных данных, становится невозможным, а, следовательно, всегда имеется вероятность того, что в программном обеспечении остались не выявленные ошибки. Однако соблюдение основных правил тестирования и научно обоснованный подбор тестов может уменьшить их количество.
Примечание. Обычно на вопрос о цели тестирования начинающие программисты отвечают, что целью тестирования является «доказательство правильности программы». Это абсолютно неверное мнение. Г. Майерс [47] предлагает очень удачную аналогию для пояснения этого положения.
Представьте себе, что вы пришли на прием к врачу и пожаловались на боль в боку. Врач выслушал вас и направил на обследование. Через некоторое время вы возвращаетесь к врачу с ворохом заключений и результатов анализов, и во всех этих бумагах написано, что все исследуемые
параметры у вас в норме. Но бок то болит, значит, что-то не в порядке, хотя анализы этого и не показывают... Так и сложное программное обеспечение, безошибочно работающее на всех тестовых наборах, может содержать и обычно содержит некоторое количество ошибок.
Процесс разработки программного обеспечения, в том виде, как он определяется в современной модели жизненного цикла программного обеспечения, предполагает три стадии тестирования:
• автономное тестирование компонентов программного обеспечения;
• комплексное тестирование разрабатываемого программного обеспечения;
• системное или оценочное тестирование на соответствие основным критериям качества.
Для повышения качества тестирования рекомендуется соблюдать следующие основные принципы:
• предполагаемые результаты должны быть известны до тестирования;
• следует избегать тестирования программы автором;
• необходимо досконально изучать результаты каждого теста;
• необходимо проверять действия программы на неверных данных;
• необходимо проверять программу на неожиданные побочные эффекты
на неверных данных.
Следует также иметь в виду, что вероятность наличия необнаруженных ошибок в части программы пропорциональны количеству ошибок уже найденных в этой части.
Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения и входит в набор эффективных средств современной системы обеспечения качества программного продукта.
Сущность тестирования состоит в том, что пользователь готовит систему тестов, с помощью которых проверяется работа программы во всех возможных режимах. Каждый тест содержит набор исходных данных, для которых известен результат. Если в результате работы программы с данным тестом получаются результаты, отличные от ожидаемых, то это говорит о наличии ошибок.
Формирование тестовых наборов.В соответствии с определением тестирования удачным следует считать тест, который обнаруживает хотя бы одну ошибку.
С этой точки зрения хотелось бы использовать такие наборы тестов, каждый из которых с максимальной вероятностью может обнаружить ошибку.
Формирование набора тестов имеет большое значение, поскольку тестирование является одним из наиболее трудоемких этапов (от 30 до 60 % общей трудоемкости) создания программного продукта. Причем доля стоимости тестирования в общей стоимости разработки имеет тенденцию возрастать при увеличении сложности программного обеспечения и
повышении требований к их качеству.
Реализация тестирования разделяется на три этапа:
1. Создание тестового набора (test suite) путем ручной разработки или автоматической генерации для конкретной среды тестирования (testing environment).
2. Прогон программы на тестах, управляемый тестовым монитором (test monitor, test driver [IEEE Std 829-1983]) с получением протокола результатов тестирования (test log).
3. Оценка результатов выполнения программы на наборе тестов с целью принятия решения о продолжении или остановке тестирования.
Основная проблема тестирования - определение достаточности множества тестов для истинности вывода о правильности реализации программы, а также нахождения множества тестов, обладающего этим свойством.
Отсюда вывод: тестирование программы на всех входных значениях невозможно.
Невозможно тестирование и на всех путях.
Следовательно, надо отбирать конечный набор тестов, позволяющий проверить программу на основе наших интуитивных представлений
Задача о выборе конечного набора тестов (X,Y) для проверки программы в общем случае неразрешима. Поэтому для решения практических задач остается искать частные случаи решения этой задачи.
Существуют два принципиально различных подхода к формированию тестовых наборов: структурный и функциональный.
Структурный подход базируется на том, что известка структура тестируемого программного обеспечения, в том числе его алгоритмы («белый ящик»). В этом случае тесты строят так, чтобы проверить правильность реализации заданной логики в коде программы.
Функциональный подход основывается на том, что структура программного обеспечения неизвестна («черный ящик»). В этом случае тесты строят, опираясь на функциональные спецификации. Этот подход называют также подходом, управляемым данными, так как при его использовании тесты строят на базе различных способов декомпозиции множества данных.
Наборы тестов, полученные в соответствии с методами этих подходов, обычно объединяют, обеспечивая всестороннее тестирование программного обеспечения.
Более подробное рассмотрение перечисленных вопросов начнем с обсуждения методов ручного контроля.
10.1 Ручной контроль программного обеспечения (самостоятельно)
