книги / Надежность программного обеспечения систем обработки данных

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

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

Испытание документации. Проверка полноты и пра­ вильности документации пользователя является важной частью системного тестирования. Все тестовые комбина­ ции должны разрабатываться только с использованием документации пользователя.

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

Испытание средств взаимодействия с пользователем.

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

Приведенные рекомендации требуют, чтобы ход мысли испытателя и пользователя совпадал, а для этого необ­ ходимо тонкое понимание того, как будет использоваться система. Из этого вытекает вопрос о том, как будет прово­ диться тестирование и, в частности, кто будет разраба­ тывать тестовые комбинации. Системное тестирование должно проводиться не программистами и не органи­ зацией, отвечающей за разработку системы Группа, про­ водящая тестирование, должна быть самостоятельной

№

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

Системное тестирование — специфическая и ответст1венная операция, так что в будущем, возможно, будут созданы подразделения, специализирующиеся на систем­ ном тестировании ПО, разработанного другими организа­ циями.

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

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

Проведение тестирования. Одним из методов системно­ го тестирования является испытание системы в эксплуата­ ционных условиях на вычислительных центрах одной или нескольких организаций пользователя. Это выгодно для всех сторон: организация-разработчик уведомляется об ошибках проектирования и программирования, которые она могла не обнаружить, а организация-пользователь получает возможность изучать систему и эксперименти­ ровать с ней до того, как она будет официально передана.

Другой полезный метод — использовать систему в ра­ бочем режиме до того, как она будет официально исполь­ зована. Это может быть сделано не при всех, но при м-но- гнх обстоятельствах. Например, изготовитель вычисли­

182

тельных машин может установить новую операционную Систему в рабочем режиме в своем вычислительном центре перед тем, как официально использовать ее, а группа по программному обеспечению может использовать свои соб­ ственные компиляторы, программы обработки данных и т. д.

При системном тестировании наблюдается тенденция начинать испытания с простых тестов, кончая более слож­ ными. Такая Последовательность не рекомендуется, так ц&к системное тестирование приходится на самый конец !Кикла создания системы и в ходе его возникает проблема времени для отладки и исправления ошибок. Так как при реализации сложных тестов часто обнаруживаются ршнбки, которые трудно исправить, следует поменять последовательность — начать со сложных тестов и закон­ чить простыми.

На рис. 9.1 показаны зависимости между исправлен цием ошибок и временем наработки по графику. Первая зависимость, показывающая, что стоимость исправления ошибки резко возрастает на последних этапах цикла раз­ работки, должна быть очевидна для большинства читате­ лей. Вторая и менее известная зависимость тоже опре­ деляется этой кривой. Вероятность неправильной фикса­ ции замеченной ошибки тоже возрастает на последних стадиях. Этот случай представляет собой известный инте-

Рис 9 I Связь между стоимостью ошибки и вре меием ее обнаружения

I обзор проектирования 2 тестирование модуля 3 фуикцио нальное тестирование 4 системное тестирование 5 лриемо сдаточйое тестирование

183

pec, так как неправильная фиксация причиняет больше вреда, чем пропуск ошибки. Отсюда вытекает вопрос: может быть целесообразно намеренно не исправлять ошибку?

Перед тем как ответить на этот вопрос, рассмотрим следующую ситуацию. Предположим, что любая ошибка может быть ранжирована в интервале от 1 до 10 при ее попадании к пользователю. Заметим, что интервал ошибки и ее размер в виде числа операторов, которые должны быть исправлены, прямо не взаимосвязаны. Допустим, что исправление любой ошибки во время проведения теста имеет вероятность 0,2 быть не зафиксированным и вероятность 0,3 сделать новую ошибку, и эта новая ошибка имеет случайный интервал от 1 до 10. Отсюда следует, что лучше сознательно отказаться от исправления ошибок с левой границы интервала, так как их исправление ухуд­ шило бы работу системы.

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

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

Проектирование и управление. Весь процесс проекти­ рования, кодирования, единичного и функционального тестирования настраивает на то, что во время системного тестирования не может быть обнаружено ошибок. В связи

сэтим расчет ресурсов для проведения испытаний произ­ водится в предположении, что тесты пройдут безошибочно

спервого раза. Это приводит к тому, что имеют место грубая недооценка потребных ресурсов, включающих лю­ дей, машинное время, графики выполнения работ, и сни­ жение качества тестирования из-за недостатка ресурсов.

184

Как и в любом сложном деле, план проведения работ является важным компонентом процесса тестирования. Этот документ должен быть разработан задолго до начала тестирования и иметь по минимальной оценке следующие основные характеристики.

1. Цели. Цели тестирования должны быть определены по каждой из фаз проверки.

2. График работ С расписанием ответственности. Необ­ ходимо определить, кто разрабатывает тестовые комбина­ ции, схемы тестирования, выполнение на каждой фазе проверки, график выполнения работ.

3.Инструменты проведения работ. Описать необходи­ мые инструменты для проведения работ, а также то, как, кто и когда их использует.

4.Машинное время. Определить количество потреб­ ного машинного времени, а также то, когда, кем и кому это время выделяется.

5.Конфигурация вычислительной системы. Необходи­ мо дать описание потребной конфигурации вычислитель­ ной системы, а также специального оборудования для

проведения испытаний. Отражается информация по гра­ фику представления оборудования и распределению от­ ветственности.

6.Комплектование тестов. Необходимо определить требования к тестовым комбинациям, стандарты на их сос­ тавление, порядок их разработки и хранения, а также рас­ пределение ответственности.

7.Процесс отладки. Определить единую стратегию к сообщениям об ошибках и методах их исправления.

8.Критерии проведения работ. Определить критерии проведения работ по каждой фазе тестирования с целью оценки уровня достаточного тестирования по каждой из фаз.

9.Последовательность интеграции. В силу того, что

интеграция системы производится в процессе тестирова­ ния, необходимо определить последовательность и методи­ ку проведения работ, график и ответственность за его выполнение.

Наиболее трудной для исполнения позицией плана работ является определение критерия завершения тести­ рования. Обычно планируют, что 100% функциональных испытаний пройдут успешно. Это достаточно слабый кри­ терий, так как он не отражает глубину и нагрузку тести­ рования. Полагаться же только на добросовестность раз-

185

ве, эксплуатационное испытание, при котором система параллельно эксплуатируется вместе с существующей сис­ темой

После завершения приемо-сдаточных испытаний сис­ тема передается пользователям и может проходить так называемые установочные испытания Большие програм­ мные системы имеют сложную процедуру установки на вычислительных центрах пользователей, где должен быть выбран режим эксплуатации, размещены файлы и библио­ теки системы Цель установочных испытаний — выявить ошибки, сделанные в процессе установки

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

Завершая краткое изложение вопросов тестирования с целью достижения заданного Уровня надежности, нельзя не отметить еще раз необходимость серьезного отноше­ ния к проведению контроля, так как далее предстоит процесс сопровождения созданного ПО, где невыделенные элементы ненадежности могут проявить себя самым неожиданным образом

Вопросы к главе 9

1 В чем различие между отладкой и тестированием5

2Сущность и технология отладки

3Основные принципы тестирования модуля

4В чем причины того что тестирование модуля ие позволяет выявить •се ошибки5

5, Задачи и принципы функционального тестирования О Охарактеризуйте основные компоненты системных тестов

7Почему системное тестирование нецелесообразно поручать разр, бот чину?

ВЦели н принципы управления системным тестированием

9Назначение н характеристика приемо сдаточных испытаний.

J87

Р а з д е л III

ОРГАНИЗАЦИОННЫЕ МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ

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

Существенную роль при создании надежного програм­ много обеспечения играют принятые методы и средства документирования разработки, планирования выполнения работ и моделирования оценки надежности на различ­ ных этапах разработки.

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

Планирование разработки программного обеспечения включает распределение объемов работ между исполни­ телями, порядок и объемы финансирования по этапам разработки и срокам выхода на контрольные точки. Естественно, что при планировании должны быть учтены требования по надежности создаваемого программного обеспечения.

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

IM

количественными оценками достигнутого уровня надежно­ сти с тем, чтобы он имел возможность принять обоснован­ ное решение о состоянии разработки.

Именно этим проблемам и посвящен материал третьего раздела.

Г л а в а 10

ОБЕСПЕЧЕНИЕ НАДЕЖНОСТИ ПРИ ДОКУМЕНТИРОВАНИИ РАЗРАБОТКИ

Документальное обеспечение ПО важно не только для последующей эксплуатации разработанных систем ПО, но и для процесса проектирования. Документация долж­ на Создаваться по ходу проектирования, часть ее разраба­ тывается и используется непосредственно в процессе про­ ектирования персоналом групп разработки на различных этапах создания проекта. Вариант привязки комплекта документации к этапам разработки и тестирования систем ПО показан на рис. 10.1.

10.1. ЦЕЛИ ДОКУМЕНТИРОВАНИЯ

Целц документирования систем ПО достаточно разно­ образны, зависят от широкого круга технического персо­ нала, использующего документацию, и от этапа разработ­

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

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

В общем случае документация должна отвечать ряду существенных требований, среди которых основными яв­ ляются следующие:

1) соответствие запросам нескольких категорий технического персонала, связанного с проектированием и

18»

эксплуатацией разработанного ПО руководитель проекта, системный программист, аналитик, программист, пользо­ ватель и начинающий обучение,

2)возможность использования на различных этапах проектирования и эксплуатации продукта ПО;

3)обладание некоторыми качествами, способствующи­

ми обозримости построения и использования на любом этапе проектирования и эксплуатации, обновляемости по мере использования, автоматизации поиска н коррекции и т д

190