ALMELN.ru

Хранилище текстов, отзывов и закладок о тестировании, обеспечении качества и литературе

View the Project on GitHub

Обоснование потребности в тестировании

В учебных программах по дисциплине “Обеспечение качества и тестирование программ” есть вопрос “Обоснование потребности в тестировании”. В программе обучения базового уровня International Software Testing Qualifications Board “Сертифицированный тестировщик” тема детализируется пунктами: “Используя примеры, объяснить, почему возникновение дефекта может нанести ущерб человеку, оборудованию или компании”, “Определить различие между первопричиной дефекта и его эффектом” и “Используя примеры, привести причины, почему тестирование необходимо”. Прошелся по доступной литературе и составил конспект, который содержит примеры и может быть использован для ответа на указанные вопросы.

«Надежность программного обеспечения», Гленфорд Майерс, 1980. 20, 28-30 страницы:

В 1971 году во Франции проводился крупный метеорологический эксперимент. Было запущено 115 шаров-зондов с измерительными приборами в верхние слои атмосферы, а также спутник для пересылки данных между шарами и наземными станциями. Шары умели реагировать на две команды: команду чтения, по которой данные пересылались от шара к спутнику, и команду ликвидации для взрыва помещенного в шаре заряда, если шар собьётся с курса. К несчастью, в программном обеспечения системы была ошибка. В результате вместо команды чтения была послана команда ликвидации, уничтожившая семь 72 шара, находившихся в поле зрения спутника.

В профессиональных журналах по обработке данных часто публикуются весёлые (для всех, кроме их участников) истории о классических ошибках в программном обеспечении. Страховая компания без всяких видимых причин аннулировала полис и отказалась его восстановить. Программа регистрации подписчиков направила все экземпляры журнала по одному адресу. Банковская система учёта займов представила к оплате месячный счёт в 212 958 долларов 72 центра, в то время как баланс по займу составлял всего 2 342 доллара 55 центов. Железнодорожная система потеряла товарные вагоны. Вследствие ошибок в системах обработки результатов голосования голоса избирателей подавались не за тех кандидатов, просто терялись, а в одном случае даже были отданы все одному кандидату (только последняя ошибка была без труда обнаружена). Ошибка в системе управления базой данных большого склада привела к разрушению записей, благодаря чему, помимо прочего, затерялись следы 15 тонн замороженной печени, помещенной в отсек без холодильника. Школьная система учёта успеваемости воспринимала только двухзначные числа, так что учащиеся, набравшие более 100 баллов, оказались неуспевающими. Программист, только что закончивший перенос программы начисления зарплаты для своей фирмы с IBM 1401 на IBM 360, открывает конверт c очередной выплатой и обнаруживает, что его оклад сокращен до 0 долларов 00 центов.

К счастью, почти все эти ошибки не имели серьезных последствий. Однако есть и другой классический свод ошибок, закончившихся катастрофами или почти катастрофами. Ошибка в программном обеспечении бортовой ЭВМ космического корабля “Аполлон-8” уничтожила содержимое части памяти машины. За 10 дней полёта “Аполлон-14” было обнаружено 18 ошибок. Беспокойство по поводу ошибок в программном обеспечении программы “Аполлон” выражает следующее заявление: “Самое тщательно спланированное и щедро финансированное программное обеспечение в мире было разработано для серии полётов на Луну по программе “Апполон”. К работе в двух соперничающих группах были привлечены лучшие программисты страны. Проверка программного обеспечения велась со всей полнотой, которую только могли представить себе специалисты. В общей сложности около шести 660 млн. долларов было затрачено на это программное обеспечение. И всё-таки почти все крупные неудачи программы “Аполлон”, от ложных тревог до реальных неприятностей, были прямым результатом ошибок в программном обеспечении ЭВМ”.

Apollo 14

Серьезные ошибки в программном обеспечении не ограничивались только программой “Аполлон”. Вследствие ошибки в программе информация с радаров была послана не по назначению, и таким образом были уничтожены все результаты учений ПВО США NORAD в 1963 году. Частота сбоев из-за ошибок в программном обеспечении командной системы 465 L стратегического командования ВВС США, функционирующей уже 12 лет, до сих пор равна одному в среднем одному сбою в день. Ошибка в единственном операторе программы на Фортране привела к неудаче при первом запуске американского исследовательского корабля на Венеру. Что хуже всего, ошибки медицинском программном обеспечении явились причиной нескольких смертельных случаев, а ошибка в программе проектирования самолёта вызвала несколько серьезных авиакатастроф, хотя имеющаяся информация об этих ошибках, как и следовало ожидать, весьма неполна.

«Наука отладки», Мэтт Тэллес, Юань Хсих. Пер. с англ. С. Лунин, науч. ред. С. Брудков. Кудиц-образ, 2003 г. — 560 с.:

Ошибка аппарата Therac-25 была, пожалуй, самой дорогой ошибкой в современной истории. Как известно, с июня 1985 по январь 1987 года шесть пациентов получили передозировку радиации, что привело к гибели троих из них… Therac­-25 представлял собой компьютеризированную машину для радиационной терапии, построенную, компанией Atomic Energy of Canada Limited (AECL). Предшественниками Therac­-25 были Therac­-6, который представлял собой ускоритель на 6 миллионов электрон­вольт (МэВ), способный испускать, только рентгеновские лучи, и Therac­-20, рентгеновский излучатель и ускоритель электронов на 20 МэВ… Therac­-25 поступил в продажу в конце 1982 года, и 11 таких машин были установлены в Северной, Америке, 5 ­ в США и 6 ­ в Канаде. Шесть несчастных случаев с большими передозировками произошли, между 1985 и 1987 годами…

Therac-25

Kennestone Regional Oncology Center, г. Кенстоун, округ Мариетта, штат Джорджия (Kennestone, Marietta, Georgia), июнь 1985. Женщина в возрасте 61 года была направлена в онкологический центр для дополнительного лечения аппаратом Therac­-25 после хирургического удаления молочной железы. Как считается, пациентка, получила одну или две дозы радиации от 15 000 до 20 000 рад (поглощенная доза радиации). Для, сравнения, типичная разовая терапевтическая доза радиации составляет до 200 рад. Кенстоунская клиника, использовала Therac­-25 с 1983 года без происшествий. Техники и фирма AECL не поверили, что эта, проблема может быть вызвана Therac­-25. В конечном итоге пациентка потеряла грудь, а также, возможность пользоваться руками и плечами из­-за радиационного поражения.

Ontario Cancer Foundation, Хемилтон, провинция Онтарио, Канада (Hamilton, Ontario, Canada). Клиника в Хэмилтоне использовала Therac­-25 в течение шести месяцев до инцидента с передозировкой. Сорокалетняя женщина поступила в клинику на 24­-в й сеанс лечения аппаратом Therac­-25. Аппарат, отключился через пять секунд после того, как оператор запустил его. Операторы были знакомы с частыми, неполадками машины. Эти неполадки, вероятно, не имели серьезных последствий для пациента., Поскольку машина показывала, что облучение не было произведено, оператор попытался повторить его. Были произведены пять попыток. После пятой попытки был вызван техник, не обнаруживший проблем в аппарате. Об инциденте сообщили в AECL, но воспроизвести неполадку и сделать заключение о причинах такого поведения Therac­-25 не удалось. Однако благодаря этому сообщению фирма AECL обнаружила некоторые слабости конструкции и потенциальные механические проблемы в позиционировании поворотной платформы Therac­-25 и были сделаны исправления. Пациентка умерла через пять месяцев. Результаты, вскрытия показали, что смерть наступила от рака, а не от передозировки радиации. Однако вскрытие, также выявило серьезные поражения бедра, вызванные радиационным воздействием. Как было позже, определено, пациентка получила дозу порядка 13 000 ­ 17 000 рад.

East Texas Cancer Center (Восточно­техасский онкологический центр), г. Тайлер, штат Техас (Tyler, Texas), и арт 1986. Восточно­техасский онкологический центр использовал аппарат Therac­-25 с 1984 года и применял его при, лечении более 500 пациентов. 21 марта 1986 года пациент (мужчина) был направлен на дополнительное, лечение. Оператор, которая осуществляла лечение, была знакома с Therac­-25 и хорошо разбиралась в его свойствах и в процессе использования. Когда она вводила данные пациента и врачебные предписания, она допустила ошибку, которую быстро исправила и начала лечение. Спустя мгновение машина отключилась и дисплей отобразил сообщения об ошибках. Как обычно происходит в программных системах сообщение об ошибке представляло собой код, который никто не смог бы расшифровать. «Ошибка 54», расшифровывалась в печатном перечне ошибок как «ввод дозы 2». Восточно­техасский онкологический центр не располагал другой документацией, которая объясняла бы смысл выражения «ввод дозы 2». Дисплей показал также очень малую дозу облучения и, поскольку оператор была знакома с капризами, Therac­25, она немедленно запустила повторное лечение. Машина снова отключилась с теми же, сообщениями об ошибках. Клиника связалась с AECL по поводу этой проблемы. Техники фирмы, направленные в Восточно­техасский онкологический центр, не смогли воспроизвести неисправность, и AECL все так же считала, что передозировка на Therac-25 невозможна. Пациент умер от осложнений передозировки через пять месяцев после этих событий.

East Texas Cancer Center (Восточнотехасский онкологический центр), г. Тайлер, штат Техас (Tyler, Texas), апрель 1986. Три недели спустя другой мужчина поступил для лечения с помощью Therac-25. Та же женщина-оператор, которая участвовала в прошлом инциденте, была ответственной за лечение. Как и в предыдущем случае, она сделала ошибку при вводе данных, и, почти столь же быстро исправив ошибку, она запустила лечение. Машина ответила сообщением «ошибка 54» и отключилась. Однако пациент уже получил передозировку, и оператор побежала за помощью. Therac-25 был отключен, и клиника проинформировала AECL о втором случае передозировки. Физик клиники, Фриц Хэгер (Fritz Hager), совместно с оператором научились воспроизводить сообщение «ошибка 54» произвольно. Оказалось, что передозировка возникала, если данные врачебного предписания редактировались в быстром темпе. Люди из AECL наконец смогли воспроизвести ошибку и признали, что передозировка была возможна.

Yakima Valley Memorial Hospital, г. Якима, штат Вашингтон (Yakima, Washington). Январь 1987… случился шестой инцидент. В данном случае пациент должен был получить три дозы облучения. Первые две дозы составляли 4 и 3 рад. Следующая доза составляла 79 рад в фотонном режиме. Первые два сеанса прошли без осложнений. После второй дозы оператор вошел в комнату облучения, чтобы повернуть поворотную платформу, чтобы проверить положение лучевого пучка относительно тела пациента. Оператор нажал кнопку возле поворотной платформы для указания того, что контроль произведен. Установив платформу, оператор запустил процесс лечения. Машина остановилась через 5-6 секунд, и поэтому оператор запустил лечение снова. И снова машина отключилась и отобразила «маловразумительную» причину остановки. Возникло предположение о передозировке, однако дисплей показал только облучение в 7 рад от двух первых сеансов.

Через неделю AECL обнаружила недостаток в программном обеспечении, который смог объяснить это поведение. Этот программный дефект отличался от того, который был обнаружен в Восточно-техасском онкологическом центре в деталях. Однако оба дефекта были вызваны неожиданными зависимостями от скорости в программных модулях. В данном случае существовала разделяемая переменная, названная Class3, содержащая однобайтовое значение. Это значение указывало, соответствуют ли параметры машины параметрам лечения. Если значение Class3 было ненулевым, параметры считались несоответствующими, и пучок лучей подавлялся. Эта переменная инициализировалась в модуле, который готовил машину к лечению. Однако инициализация заканчивалась инкрементированием данной переменной. Поскольку переменная была однобайтовой, через каждые 256 итераций значение ее доходило до нуля, программный модуль, проводивший инициализацию, запускался все время в зависимости от других событий в системе. Если кнопка на поворотной платформе была нажата именно в тот момент, когда переменная Class3 была равна нулю, проверка соответствия не производилась, и машина могла облучить пациента электронным пучком дозой до 25МеV. Пациент умер в апреле 1987 году от осложнений, вызванных передозировкой. Машина была отозвана вскоре после этого…

Ariane 5

Ракета-носитель Ariane 5 была ответом попыткам Европейского космического агентства (European Space Agency) стать лидером в запусках ракет на коммерческом космическом рынке. Стоившая 7 миллиардов долларов и строившаяся в течение 10 лет, Arian 5 могла вывести на орбиту два трехтонных спутника. При своем первом полете ракета Ariane 5 взорвалась через 40 секунд после старта утром 4 июня 1996 года. Анализ данных полета быстро показал, что ракета вела себя нормально до того момента, когда она вдруг отклонилась от курса и самоуничтожилась… Команда Ariane 5 решила не защищать некоторые переменные от возможной ошибки операнда, поскольку они считали, что значения этих переменных либо ограничены физическими факторами, либо имеют существенный запас по максимальной величине. Команда Ariane 5 решила не включать данные о траектории в функциональные требования для Инерционной системы ориентировки. Следовательно, данные о траектории Ariane 5 не использовались при тестировании. Из-за физических законов трудно осуществить реалистичный полетный тест Инерционной системы ориентировки. При функциональном имитационном тестировании полетных программ было решено не включать в тест эту систему главным образом по той причине, что она должна быть проверена при тестировании аппаратного уровня, а также потому, что было бы трудно достигнуть необходимой точности при имитационном тестировании, если бы была использована реальная Инерционная система ориентировки…

Аппарат для исследования климата Марса Mars Climate Orbiter является частью программы Mars Surveyor по изучению и картографированию Марса. Ожидалось, что программа Mars Surveyor продлится в течение 10 лет и в рамках программы будет запускаться одна экспедиция в год. Первыми двумя экспедициями были миссии аппаратов Mars Pathfinder и Mars Global Surveyor в 1996 году. Аппарат Mars Climate Orbiter был запущен 11 декабря 1998 года. Следом за ним был также запущен Mars Polar Lander - 3 января 1999. Оба аппарата были потеряны вскоре после того, как они достигли красной планеты. Эти два космических корабля стоили NASA около 327,6 миллиона долларов, потраченных на их создание и функционирование. Эти аварии заставили NASA пересмотреть свои цели и методы в Марсианской программе, чтобы быть уверенными в успехе будущих миссий. Причину аварии Mars Polar Lander определить все еще нельзя. Однако причина потери Mars Climate Orbiter выяснена.

Согласно спецификации модуль… должен формировать данные… используя метрические единицы, то есть ньютон-секунды. Однако по тем или иным причинам модуль на наземной станции выводил данные, используя английские единицы (фунт-секунды) (в официальном отчете причина не указывалась, и мы не будем строить предположения по этому поводу). Программный модуль, который рассчитывал изменение скорости с использованием данных…, ожидал, что они будут в метрических единицах, согласно спецификации. На борту аппарата модуль… использовал метрические единицы. Это привело к различию между траекториями, вычисленными космическим аппаратом и наземной станцией, а именно параметры траектории, вычисленные наземной станцией, были в 4,45 раза меньше, поскольку 1 фунт-секунда равен 4,45 ньютон-секундам.

«Люди иногда делают ошибки», - заявил доктор Эдвард Уэйлер (Edward Weiler), первый заместитель главы NASA по науке о космосе. «Данная проблема - это не ошибка, это неудача системотехники и систем проверки в наших технологиях, предназначенных для обнаружения ошибки. Вот почему мы потеряли космический аппарат». Три главных составляющих аварии Mars Climate Orbiter: 1. Если бы было проведено соответствующее тестирование, такая ошибка могла быть быстро обнаружена и исправлена. 2. Однако, поскольку программное обеспечение наземной станции не было хорошо протестировано, после запуска космического аппарата проявились дополнительные ошибки. Эти ошибки отсрочили наблюдения над проблемой. Вместо девяти месяцев из-за дополнительных ошибок персонал имел только пять месяцев на выяснение причины несоответствий. 3. Когда несоответствие в итоге было обнаружено, оно так и не было правильно объяснено. Первоначальная причина так и не была выяснена, а это дало бы персоналу информацию о надвигающейся катастрофе.

В отчете комиссии по расследованию первой фазы ее работы также были указаны следующие факторы неудачи и сделаны некоторые дополнительные рекомендации… 1. Обмен информацией. Команда наземного обслуживания не сообщала о своем беспокойстве по поводу различия траекторий команде управления космическим аппаратом и органам управления проектом. Важная информация от одной команды не передавалась другим командам, что внесло свой вклад в аварию. 2. Обучение и переход от стадии разработки к стадии функционирования… Обслуживающий персонал не был полностью обучен. Переход от разработки к функционированию не был тщательно спланирован и осуществлен. В разработке программного обеспечения это можно приравнять к тому, как если бы команда разработчиков перебросила готовую систему команде сетевых операторов, не снабдив их соответствующими инструментами и не проведя обучение особенностям и поведению системы. 3. Самоуверенность. Комиссия по расследованию обнаружила, что персонал проекта считал посылку космического аппарата на орбиту вокруг Марса легкой задачей, поскольку JPL имела тридцатилетний опыт безошибочной межпланетной навигации. Эта самоуверенность может объяснить недостаток соответствующего тестирования в программных модулях…

В ходе всей разработки и процессов тестирования существовало много стадий, на которых данный дефект мог быть выявлен: 1). Программный модуль был повторно использован в новой среде, где условия функционирования отличались от требований программного модуля. Эти требования не были пересмотрены. 2). Система выявила и распознала ошибку. К несчастью, спецификация механизма обработки ошибок была несоответственной и вызвала окончательное разрушение. 3). Ошибочный модуль никогда должным образом не тестировался в новом окружении - ни на уровне оборудования, ни на уровне системной интеграции. Следовательно, ошибочность разработки и реализации не была обнаружена.

К 15 января 1990 года в компании AT&T произошла авария, охватившая всю страну и продолжавшаяся девять часов. Причина состояла в ошибке в программном обеспечении, которое должно было сделать эту систему более эффективной… В 1990 году телефонная сеть AT&T состояла из 114 соединенных между собой систем коммутирования вызовов… В середине декабря 1989 года AT&T произвела обновление программного обеспечения на коммутаторах 4ESS с целью увеличения производительности системы и введения быстрого процесса восстановления после ошибки. Приблизительно в 14:40 15 января 1990 года на 4ESS коммутаторе в Нью-Йорке возникла небольшая аппаратная проблема, и коммутатор начал процесс восстановления… Обновление программ, проведенное в середине декабря, внесло в действия ошибку. Эта ошибка проявилась, когда коммутатор получил два IAM сообщения с интервалом 1/100 секунды. Некоторые данные в коммутаторе оказались искажены, и он прекратил обслуживание, перейдя к инициализации. Когда соседние узлы выходили из строя, они запускали тот же самый процесс восстановления. Поскольку все коммутаторы были одинаковы, та же последовательность событий каскадом распространялась от одного коммутатора к другому и вывела из строя всю систему… В течение дня инженеры AT&T смогли стабилизировать сеть, уменьшив нагрузку на нее. К 23:30 EST они смогли очистить все звенья сети, и система практически вернулась к нормальному состоянию… Во вторник, 16 января 1990 года, инженеры AT&T смогли идентифицировать и выделить ошибку, которая была отслежена до набора ошибочных кодов… Один из операторов приводил к исполнению части кода, которая не входила в намерения программиста. В официальном отчете AT&T говорилось: “Мы считаем, что процессы планирования, разработки и тестирования программ, которые мы используем, базируются на прочных и качественных основах. Все будущие программы будут также скрупулезно тестироваться. Мы используем опыт, приобретенный при решении этой проблемы, для дальнейшего улучшения наших методов”.

Stratacom-BPX

13 апреля 1998 года, на AT&T произошла другая крупная авария в сети ретрансляции кадров (frame relay network) Cisco Stratacom BPX, которая затронула банкоматы, операции с кредитными картами и другие службы, связанные с передачей бизнес-данных. Авария длилась 26 часов. И опять ошибка была внесена при обновлении программного обеспечения… Когда техник прибыл на место, он посчитал, что коммутатор, которому требуется обновление, не подключен к сети, поскольку казалось, что через него не проходил никакой сетевой трафик. Однако коммутатор был подключен к сети и активен. К несчастью для техника и для AT&T, обе карты имели дефекты. Как только карты были установлены и активированы, они немедленно выслали коммутатору поток сообщений об ошибках. Эти сообщения от транк-карт активировали ошибку в программном модуле коммутатора. Этот дефект вызвал распространение передачи сообщений об ошибках к другим коммутаторам сети, ко всем 145. Объем этих посланий был достаточно велик, для того чтобы быстро перегрузить все коммутаторы, что очень действенно вывело из строя всю систему приблизительно к 15:00… Компания AT&T смогла быстро изолировать аварийный коммутатор, к 23:00 он был отключен от сети. Оставшаяся задача состояла в том, чтобы просто перестроить всю сеть, одну часть за другой. К 2:00 пополудни 14 апреля 1998 года 99,9 % сети ретрансляции кадров были снова работоспособны… Программные дефекты в обоих случаях представляли собой проблемы со скрытыми граничными условиями, которые было трудно протестировать и которые, по всей вероятности, так и не были протестированы.

… Цена ошибки может быть астрономической. Миллионы долларов, затраченные на оборудование и работу, исчезают без следа. Человеческая боль и страдания, даже смерть могу быть вызваны простой ошибкой в программе.

Эта заметка является ответом на экзаменационный вопрос “Обоснование потребности в тестировании” по учебной дисциплине “Обеспечение качества и тестирование программ”. Полный перечень вопросов привел в заметке Учебные программы, экзаменационные вопросы и литература по обеспечению качества и тестированию программ.

Перевод главы из книги “Наука отладки” Книга “Надежность программного обеспечения”

25.05.2017. Перейти на Главную страницу