Lecture01 (Лекции в ПДФ), страница 3

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

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

В англоязычной литературе в этомсмысле чаще всего употребляется термин defect.•Часто ошибкой или сбоем называют наблюдаемое нарушение требований,проявляющееся при некотором сценарии работы рассматриваемой системы. Ванглийском языке этому значению соответствует термин failure.•Ошибка в коде программы, вызывающая наблюдаемое нарушение требований, исостоящаявнеправильномиспользованиикакой-токонструкцииязыкапрограммирования, употреблении лишней конструкции или в пропуске необходимой. Ванглоязычной литературе ошибка такого рода называется fault.Ошибка такого рода определена нечетко, в отличие от предыдущего, — неправильнаяработа некоторого кода часто может быть исправлена несколькими разными способами.Если есть несколько конструкций, исправление каждой из которых удаляет эту ошибку,тяжело определить, какая именно из них ошибочна.•Ошибка аналитика, архитектора или программиста, заключающаяся в неправильномпонимании определенного требования или ограничения, в том, что какое-то требованиезабыто, или, наоборот, используется лишнее требование.

По-английски такая ошибканазывается обычно error.Иногда в англоязычной литературе термин error употребляется еще и в другом смысле— так называют некорректные, не соответствующие требованиям данные,возвращаемые системой в ответ на какой-либо запрос, или некорректные данные,возникающие в ходе внутренних вычислений в системе.Основной смысл терминов failure, fault и error достаточно тесно связан с основнымиисточниками ошибок, которых тоже три.•Неправильное понимание задач.Очень часто люди не понимают или понимают неправильно то, что им пытаются сказатьдругие.

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

Корректному представлениюрешений в коде могут помешать как обычные опечатки, так и забывчивостьпрограммиста или его нежелание отказаться от привычных приемов, которые не даютвозможности аккуратно записать именно то, что нужно.С ошибками такого рода можно справиться при помощи инспектирования кода,взаимного контроля, при котором разработчики внимательно читают код друг друга,опережающей разработки модульных тестов и тестирования.Ошибки в программном обеспечении иногда приводят к серьезным инцидентам изначительным убыткам для организаций, использующим такое ПО. Гораздо чаще возникаютболее мелкие ошибки, не приводящие к серьезным последствиям. Зависимость междуколичеством ошибок и размером их последствий подчиняется закону Ципфа (Zipf) [9] —количество случающихся сбоев примерно обратно пропорционально величине наносимогоими ущерба.Далее рассматривается несколько примеров ошибок в программном обеспечении,имевших серьезные последствия.•Ошибка в системе управления космическим аппаратом Mariner 1 [10].Эта ошибка привела к уничтожению одного из первых кораблей, направлявшегося кВенере, через несколько минут после запуска 22 июля 1962 года.В ходе полета антенна связи вышла из строя, связь со службой управления былапотеряна, и управление полетом взял на себя бортовой компьютер.

Однако в одной изформул для расчета положения было забыто усреднение скорости по несколькимпоследовательным измеренным значениям — в результате небольшие перепадыскорости стали рассматриваться системой как серьезные, она стала предпринимать«корректирующие» действия, в результате чего корабль сошел с курса и был уничтожен.•••••Ошибка в программном обеспечении, управляющем аппаратом радиационной терапииTherac-25 [11].За 1985-1987 годы зафиксировано 6 инцидентов, связанных с этой ошибкой.

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

При эксплуатационномтестировании она не была обнаружена, поскольку операторы тогда еще не научилисьпереключать режимы достаточно быстро.Ошибка в системе управления космическим аппаратом Фобос 1 [12].Привела к потере связи с кораблем, уже находившимся на пути к Марсу, 2 сентября 1988года. Корабль перестал ориентироваться в пространстве, не смог сориентироватьсолнечные батареи и израсходовал аккумуляторы, поскольку были отключенынавигационные приборы для определения положения относительно Солнца.Команда отключения приборов была в тестовой подпрограмме, использовавшейся наЗемле для проверки работоспособности отдельных систем, удалить этот код не успелиперед вылетом, поскольку он был записан в памяти, предназначенной только для чтения,а для ее замены требовалось существенное время.

Казалось, однако, что в ходе полетаэта программа никогда не будет вызвана. Но при передаче команд по корректировкекурса 29 августа 1988 года была допущена ошибка — пропущен один символ, чтопривело к выполнению этой тестовой программы.Другой корабль этой серии, Фобос 2, был также потерян из-за какой-то ошибки всистеме управления 27 марта 1989 года, уже на орбите вокруг Марса.25 февраля 1991 года во время Первой войны в Персидском заливе американскаясистема ПВО Patriot не смогла сбить иракскую ракету Скад, которая в результате попалав барак американской армии, убив 28 человек и ранив около ста [13].Причиной промаха Patriot, как выяснилось, было накопление ошибок округления завремя работы системы.

Время в ней измерялось в десятых долях секунды, а числа былипредставлены в 24-битном двоичном формате с плавающей точкой. При представлении1/10 как двоичной дроби с 24-мя цифрами возникает небольшая ошибка.В рассматриваемом случае система Patriot работала без перезагрузки около 100 часов. Заэто время накопление погрешности определения времени дало ошибку около 1/3секунды. Поскольку ракета Скад летит со скоростью 1700 м/с, ошибка в 1/10 секундыпри расчете ее траектории уже не дает возможности ее сбить.Многочисленные ошибки в системе управления двигателями и навигационной системесчитаются наиболее вероятной причиной катастрофы вертолета Chinook ZD 576 [14],произошедшей 2 июня 1994 года на мысе Кинтайр.

В этой катастрофе погибли 25экспертов и высокопоставленных сотрудников отдела разведки Великобритании вСеверной Ирландии, что на значительное время парализовало работу этого отдела.Ошибка в системе управления ракеты Ариан-5 привела к ее уничтожению при первомзапуске этой ракеты 4 июня 1996 года [15].Долгое время эта ошибка, приведшая к убыткам в размере 500 миллионов долларовСША, считалась самой дорогостоящей ошибкой в программной системе.Ошибка состояла в том, что без изменений использовался модуль расчета траектории изсистемы управления ракетой Ариан-4. В нем горизонтальная составляющая скоростиракеты представлялась 16-битным числом. Ариан-5 могла выдерживать болеезначительные ускорения и большую кривизну траектории, из-за чего в ходе полетазначение горизонтальной скорости вышло за пределы представимых 16-ю битами чисел.Специальной процедуры обработки такой ситуации не было, поэтому возникшееисключение обрабатывалось модулем обработки общих сбоев, который остановилданный процесс и запустил новый с теми же исходными данными, что вновь привело ктой же ошибке.

В результате система не смогла вычислить правильное текущееположение ракеты и стала использовать ранее полученные данные. Это привело кпопытке «скорректировать» курс и «болтанию» ракеты, после чего она былауничтожена.•Ошибка в системе управления космическим аппаратом Mars Climate Orbiter [16].Привела к его выходу на слишком низкую орбиту вокруг Марса 23 сентября 1999 года ик последовавшему за этим разрушению.Необходимые корректировки к движению корабля рассчитывались специальнойпрограммой на Земле и после передавались в виде команд двигателям аппарата.