В.В. Кулямин - Тестирование на основе моделей, страница 4
Описание файла
PDF-файл из архива "В.В. Кулямин - Тестирование на основе моделей", который расположен в категории "". Всё это находится в предмете "тестирование на основе моделей" из 9 семестр (1 семестр магистратуры), которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .
Просмотр PDF-файла онлайн
Текст 4 страницы из PDF
Время в ней измерялось в десятых долях секунды, а числа былипредставлены в 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 года ик последовавшему за этим разрушению.Необходимые корректировки к движению корабля рассчитывались специальнойпрограммой на Земле и после передавались в виде команд двигателям аппарата.
Ошибкасостояла в том, что управляющая программа на Земле использовала значения импульсовв фунтах силы на секунду, а бортовая система передавала ей значения, измеренные вНьютонах на секунду. В результате были использованы неправильные командыкорректировки.•Наконец, одной из причин сбоя в электроснабжении северо-востока Северной Америки,произошедшего 14 августа 2003 года, на несколько часов оставившего без электричестваоколо 50 миллионов человек и приведшего к потерям на сумму около 6 миллиардовдолларов США, была ошибка в программной системе оповещения о сбоях наэлектростанции [17].Можно отметить, что в большинстве примеров ошибок, имевших тяжелые последствия,нельзя однозначно приписать всю вину за случившееся ровно одному недочету или дефекту,одному месту в коде.
К тяжелым последствиям чаще всего приводят ошибки системногохарактера, затрагивающие многие элементы системы и различные аспекты ее устройства.Это значит, что при анализе такого происшествия обычно выявляется множество частныхошибок, нарушений действующих правил, недочетов в инструкциях и требованиях, которыесовместно привели к создавшейся ситуации.Даже если ограничиться рассмотрением только ПО, часто одно проявление ошибки(failure) может выявить несколько дефектов, находящихся в разных местах. Такие ошибкивозникают, как показывает практика, в тех ситуациях, в которых поведение системынеоднозначно или недостаточно четко определяется требованиями (а иногда и вообще никакне определяется, что является признаком неполного понимания задачи). Поэтомуразработчики различных модулей ПО имеют возможность по-разному интерпретировать течасти требований, которые относятся непосредственно к их модулям, а также иметь разныемнения по поводу области ответственности каждого из взаимодействующих модулей вданной ситуации.
Если различия в их понимании не выявляются достаточно рано, приразработке системы, то становятся «минами замедленного действия» в ее коде, приводя вдальнейшем к сбоям системы.При подготовке и проведении тестирования эти закономерности распределения ошибокпомогают находить их быстрее и с меньшими трудозатратами.Литература[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17]ISO/IEC 9126-1:2001. Software engineering — Software product quality — Part 1: Qualitymodel, 2001.ISO/IEC TR 9126-2:2003 Software engineering — Product quality — Part 2: Externalmetrics, 2003.ISO/IEC TR 9126-3:2003 Software engineering — Product quality — Part 3: Internal metrics,2003.ISO/IEC TR 9126-4:2004 Software engineering — Product quality — Part 4: Quality in usemetrics, 2003.IEEE 830-1998.
Recommended Practice for Software Requirements Specifications. NewYork: IEEE, 1998.IEEE 1233-1998. Guide for Developing System Requirements Specifications. New York:IEEE, 1998.ANSI/IEEE 610.12-1990. Glossary of Software Engineering Terminology.
NY:IEEE, 1987.IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004.Статья Wikipedia о законе Ципфа http://en.wikipedia.org/wiki/Zipf%27s_law.http://nssdc.gsfc.nasa.gov/nmc/tmp/MARIN1.html.N. Levenson, C. S. Turner. An Investigation of the Therac-25 Accidents. IEEE Computer,26(7):18-41, July 1993.R. Z. Sagdeev, A. V. Zakharov. Brief history of the Phobos mission.
Nature 341:581-585,1989.G. N. Lewis, S. Fetter, L. Gronlund. Casualties and Damage from Scud Attacks in the 1991Gulf War, 1993.http://web.mit.edu/ssp/Publications/working_papers/wp93-2.pdf.http://www.publications.parliament.uk/pa/ld200102/ldselect/ldchin/25/2501.htm.http://www.ima.umn.edu/~arnold/disasters/ariane5rep.html.Mars Climate Orbiter Mishap Investigation Board Phase I Report, 1999.ftp://ftp.hq.nasa.gov/pub/pao/reports/1999/MCO_report.pdf.http://www.nyiso.com/public/webdocs/newsroom/press_releases/2005/blackout_rpt_final.pdf.Тестирование на основе моделейВ.
В. КуляминЛекция 2. Основные задачи и виды тестированияВ прошлой лекции тестирование было определено как проверка соответствия поведенияпрограммной системы требованиям, выполняемая по результатам реальной работы этойсистемы в некотором конечном наборе заранее определенных ситуаций [1].Таким образом, основная задача тестирования — проверка требований. Ее решение чащевсего сводится к последовательному решению ряда промежуточных задач. Кроме того, длярешения этих задач в различных обстоятельствах необходимы разные подходы.Данная лекция посвящена основным задачам тестирования, различным способам егопроведения и подходам к организации набора тестов.Цели тестированияТестирование является одним из видов деятельности в рамках жизненного циклапрограммного обеспечения и по отношению к другим видам деятельности в нем имеетследующие цели.•Наиболее очевидная цель тестирования — поиск ошибок, то есть расхождений междунаблюдаемым поведением ПО и требованиями к нему.Даже весьма опытные разработчики ПО часто считают, что это — его единственнаяцель.
Классическая фраза Дейкстры «тестирование может использоваться длядемонстрации наличия ошибок в программе, но не может использоваться длядемонстрации их отсутствия» часто почему-то интерпретируется именно в том смысле,что единственная польза от тестирования — найденные ошибки.•Менее очевидная и более сложная для понимания цель тестирования — общая оценкакачества ПО. Помимо прямого обнаружения ошибок, оно должно давать информациюо том, где, скорее всего, находятся еще не найденные ошибки, насколько они могут бытьсерьезны, насколько тестируемая система надежно и корректно работает в целом,насколько корректны и стабильны ее отдельные функции и компоненты.Если единственной целью тестирования считать нахождение ошибок, то терпеливое,аккуратное и систематическое тестирование, в ходе которого ошибок не обнаруживается— бесполезно.
Это не так, просто потому, что результатом такой работы являетсяценная информация о свойствах системы, недоступная из других источников, если,конечно, не относиться серьезно к уверенности разработчиков в собственнойнепогрешимости или к их словам о том, что «уж в основном-то все правильно, так,мелочи всякие могут еще не работать». Такое тестирование, если оно действительноаккуратное и систематическое, показывает, что тестируемая система — достаточнохороша. Даже если в ней и есть ошибки (что их нет, доказать при помощи тестированияневозможно), они достаточно редки и случаются в очень специфических ситуациях.Однако проведение подобного тестирования — непростая задача, основная трудностькоторой — достижение такого уровня аккуратности и систематичности, которыйпозволяет обоснованно делать соответствующие выводы.Другой возможной проблемой при понимании тестирования как деятельности,нацеленной только на поиск ошибок, является отсутствие рациональных аргументов дляопределения момента, когда нужно прекратить тестирование.
Если тестировщикизанимаются только поиском ошибок, они не могут предоставить руководству проектаобоснованную информацию о том, что «в системе еще очень много недоделок» или,наоборот, «система уже достаточно надежна». В этом случае решение об остановкетестирования принимается только на основе наличия ресурсов, то есть по остаточномупринципу: есть еще есть время и деньги — продолжаем тестировать, нет — прекращаем.Такого рода решения не связаны с реальным качеством системы, и поэтому способныпринести большой урон репутации организации-разработчика ПО. Кроме того, онизакрепляют плохую практику управления проектами, способствуя перемещению всебольшей и большей части ресурсов проектов в разработку без тестирования, ведь оттестирования «нет прямой пользы» и его можно проводить на «остатки» ресурсов.Если руководитель проекта принимает подобные решения, это может означать либо, чтоон недостаточно компетентен и не воспринимает поступающую от тестировщиковинформацию, либо, что тестировщики сами недостаточно компетентны, чтобы такуюинформацию предоставить, и тестирование проводится хаотичным, недостаточноэффективным образом.Методом проб и ошибок были выработаны рекомендации по организации тестирования,согласно которым ресурсы для проведения разработки тестов и тестированиянеобходимо выделять заранее.