Лекции. Тестирование ПО (all in one) (Лекции), страница 4

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

Ошибкасостояла в том, что управляющая программа на Земле использовала значения импульсовв фунтах силы на секунду, а бортовая система передавала ей значения, измеренные вНьютонах на секунду. В результате были использованы неправильные командыкорректировки.•Одной из причин сбоя в электроснабжении северо-востока Северной Америки 14 августа2003 года, на несколько часов оставившего без электричества 50 миллионов человек иприведшего к потерям на сумму около 6 миллиардов долларов США, была ошибка впрограммной системе оповещения о сбоях на электростанции, связанная с неаккуратнойсинхронизацией параллельно работающих процессов [17].Можно отметить, что в большинстве примеров ошибок, имевших тяжелые последствия,нельзя однозначно приписать всю вину за случившееся ровно одному недочету или дефекту,одному месту в коде.

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

Если различия в их понимании невыявляются достаточно рано, при разработке системы, то становятся «минами замедленногодействия» в ее коде.При подготовке и проведении тестирования эти закономерности стоит учитывать, этопомогает как находить ошибки быстрее и с меньшими трудозатратами, так и более аккуратноанализировать их последствия и устранять все возможные связанные с ними эффекты.Литература[1][2][3]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.[4][5][6][7][8][9][10][11][12][13][14][15][16][17]ISO/IEC TR 9126-4:2004 Software engineering — Product quality — Part 4: Quality in usemetrics, 2003.ISO/IEC 25010:2011 Systems and software engineering — Systems and software QualityRequirements and Evaluation (SQuaRE) — System and software quality models, 2011.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.В. В. Кулямин, Н. В. Пакулин, О. Л. Петренко, А. А. Сортов, А. В. Хорошилов.Формализация требований на практике. Препринт 13, ИСП РАН, Москва, 2006.http://panda.ispras.ru/~kuliamin/docs/Req-2006-ru.pdf.Статья 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.Как защититься от ошибокВ прошлой лекции шла речь о качестве программного обеспечения (ПО) и его возможныхдефектах — ошибках.

Каким образом можно обеспечить качество и, тем самым, защититьсяот ошибок в ПО? Эту задачу решают виды деятельности в рамках разработки исопровождения ПО, связанные с обеспечением качества. Любой систематический подход кобеспечению качества должен включать следующие три пункта.• Методы предотвращения ошибок• Методы обнаружения ошибок• Методы исправления ошибокЕсли ошибки не обнаружить или не исправить, то они не исчезнут, поэтому последние двапункта необходимы. Методы предотвращения ошибок нужны для снижения нагрузки наработу по оставшимся пунктам — иначе в сложных случаях можно оказаться в ситуации, вкоторой количество обнаруживаемых ошибок значительно превышает возможности ихисправления (на практике так тоже бывает, но величину этого превышения стараютсядержать ограниченной).

Также, стоит помнить, что самые совершенные методыпредотвращения ошибок не способны справиться со всеми их видами — все равно ошибкивозникают и их надо уметь находить, т.е., наличие высокоэффективных технологийпредотвращения ошибок не делает работу по их обнаружению и исправлению ненужной.Примеры методов предотвращения ошибок.• Стандартизация интерфейсов широко используемых библиотек, протоколоввзаимодействия и создание хорошей документации по их интерфейсам.Примерами таких стандартов являются POSIX, стандартная библиотека Java JDK.Хорошая, соответствующая реальной работе описываемыхого ПО и одновременнолишенная неполноты, двусмысленностей и рассогласованности документация постандартам позволяет разработчикам, участвующим в реализации билиотек точнее иполнее понимать, какую функциональность нужно обеспечить и избегать ошибок в еереализации и несогласованностей при реализации одного стандарта разнымиразработчиками.

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

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

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

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

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