СОПРОВОЖДЕНИЕ И ОБСЛУЖИВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ КОМПЬЮТЕРНЫХ СИСТЕМ. Методические указания по выполнению практических и лабораторных работ по пм. 04
 Скачать 1.92 Mb.
|
|
Автономная отладка программного средства При автономной отладке ПС каждый модуль на самом деле тестируется в некотором программном окружении, кроме случая, когда отлаживаемая программа состоит только из од- ного модуля. Это окружение состоит из других модулей, часть которых является модулями отлаживаемой программы, которые уже отлажены, а часть - модулями, управляющими отлад- кой. Таким образом, при автономной отладке тестируется всегда некоторая программа (тести- руемая программа), построенная специально для тестирования отлаживаемого модуля. Эта программа лишь частично совпадает с отлаживаемой программой, кроме случая, когда отлажи- вается последний модуль отлаживаемой программы. В процессе автономной отладки ПС про- изводится наращивание тестируемой программы отлаженными модулями: при переходе к от- ладке следующего модуля в его программное окружение добавляется последний отлаженный модуль. Такой процесс наращивания программного окружения отлаженными модулями назы- вается интеграцией программы. Отладочные модули, входящие в окружение отлаживаемого модуля, зависят от порядка, в каком отлаживаются модули этой программы, от того, какой мо- дуль отлаживается и, возможно, от того, какой тест будет пропускаться. При восходящем тестировании это окружение будет содержать только один отладочный модуль (кроме случая, когда отлаживается последний модуль отлаживаемой программы), кото- рый будет головным в тестируемой программе. Такой отладочный модуль называют веду- щим (или драйвером). Ведущий отладочный модуль подготавливает информационную среду для тестирования отлаживаемого модуля (т. е. формирует ее состояние, требуемое для тестиро- вания этого модуля, в частности, путем ввода некоторых тестовых данных), осуществляет об- ращение к отлаживаемому модулю и после окончания его работы выдает необходимые сооб- щения. При отладке одного модуля для разных тестов могут составляться разные ведущие от- ладочные модули. При нисходящем тестировании окружение отлаживаемого модуля в качестве отладоч- ных модулей содержит отладочные имитаторы (заглушки) некоторых еще не отлаженных мо- дулей. К таким модулям относятся, прежде всего, все модули, к которым может обращаться отлаживаемый модуль, а также еще не отлаженные модули, к которым могут обращаться уже отлаженные модули (включенные в это окружение). Некоторые из этих имитаторов при отладке одного модуля могут изменяться для разных тестов. На практике в окружении отлаживаемого модуля могут содержаться отладочные модули обоих типов, если используется смешанная стратегия тестирования. Это связано с тем, что как восходящее, так и нисходящее тестирование имеет свои достоинства и свои недостатки. К достоинствам восходящего тестирования относятся: простота подготовки тестов, возможность полной реализации плана тестирования модуля. Это связано с тем, что тестовое состояние информационной среды готовится непосред- ственно перед обращением к отлаживаемому модулю (ведущим отладочным модулем). Недостатками восходящего тестирования являются следующие его особенности: тестовые данные готовятся, как правило, не в той форме, которая рассчитана на пользо- вателя (кроме случая, когда отлаживается последний, головной, модуль отлаживаемой программ); большой объем отладочного программирования (при отладке одного модуля приходится составлять много ведущих отладочных модулей, формирующих подходящее состояние информационной среды для разных тестов); 54 необходимость специального тестирования сопряжения модулей. К достоинствам нисходящего тестирования относятся следующие его особенности: большинство тестов готовится в форме, рассчитанной на пользователя; во многих случаях относительно небольшой объем отладочного программирования (имитаторы модулей, как правило, весьма просты и каждый пригоден для большого числа, нередко - для всех, тестов); отпадает необходимость тестирования сопряжения модулей. Недостатком нисходящего тестирования является то, что тестовое состояние инфор- мационной среды перед обращением к отлаживаемому модулю готовится косвенно - оно явля- ется результатом применения уже отлаженных модулей к тестовым данным или данным, выда- ваемым имитаторами. Это, во-первых, затрудняет подготовку тестов и требует высокой квали- фикации тестовика (разработчика тестов), а во-вторых, делает затруднительным или даже не- возможным реализацию полного плана тестирования отлаживаемого модуля. Указанный недо- статок иногда вынуждает разработчиков применять восходящее тестирование даже в случае нисходящей разработки. Однако чаще применяют некоторые модификации нисходящего тести- рования, либо некоторую комбинацию нисходящего и восходящего тестирования. Исходя из того, что нисходящее тестирование, в принципе, является предпочтительным, остановимся на приемах, позволяющих в какой-то мере преодолеть указанные трудности. Прежде всего, необходимо организовать отладку программы таким образом, чтобы как можно раньше были отлажены модули, осуществляющие ввод данных, - тогда тестовые данные можно готовить в форме, рассчитанной на пользователя, что существенно упростит подготовку последующих тестов. Далеко не всегда этот ввод осуществляется в головном модуле, поэтому приходится в первую очередь отлаживать цепочки модулей, ведущие к модулям, осуществля- ющим указанный ввод. Пока модули, осуществляющие ввод данных, не отлажены, тестовые данные поставляются некоторыми имитаторами: они либо включаются в имитатор как его часть, либо вводятся этим имитатором. При нисходящем тестировании некоторые состояния информационной среды, при кото- рых требуется тестировать отлаживаемый модуль, могут не возникать при выполнении отла- живаемой программы ни при каких входных данных. В этих случаях можно было бы вообще не тестировать отлаживаемый модуль, так как обнаруживаемые при этом ошибки не будут про- являться при выполнении отлаживаемой программы ни при каких входных данных. Однако так поступать не рекомендуется, так как при изменениях отлаживаемой программы (например, при сопровождении ПС) не использованные для тестирования отлаживаемого модуля состояния ин- формационной среды могут уже возникать, что требует дополнительного тестирования этого модуля (а этого при рациональной организации отладки можно было бы не делать, если сам данный модуль не изменялся). Для осуществления тестирования отлаживаемого модуля в ука- занных ситуациях иногда используют подходящие имитаторы, чтобы создать требуемое состо- яние информационной среды. Чаще же пользуются модифицированным вариантом нисходя- щего тестирования, при котором отлаживаемые модули перед их интеграцией предварительно тестируются отдельно (в этом случае в окружении отлаживаемого модуля появляется ведущий отладочный модуль, наряду с имитаторами модулей, к которым может обращаться отлаживае- мый модуль). Однако, представляется более целесообразной другая модификация нисходящего тестирования: после завершения нисходящего тестирования отлаживаемого модуля для дости- жимых тестовых состояний информационной среды следует его отдельно протестировать для остальных требуемых состояний информационной среды. Часто применяют также комбинацию восходящего и нисходящего тестирования, кото- рую называют методом сандвича . Сущность этого метода заключается в одновременном осу- ществлении как восходящего, так и нисходящего тестирования, пока эти два процесса тестиро- вания не встретятся на каком-либо модуле где-то в середине структуры отлаживаемой про- граммы. Этот метод при разумном порядке тестирования позволяет воспользоваться достоин- ствами как восходящего, так и нисходящего тестирования, а также в значительной степени нейтрализовать их недостатки. 55 Весьма важным при автономной отладке является тестирование сопряжения модулей. Дело в том, что спецификация каждого модуля программы, кроме головного, используется в этой программы в двух ситуациях: во-первых, при разработке текста (иногда говорят: тела) этого модуля и, во-вторых, при написании обращения к этому модулю в других модулях программы. И в том, и в другом случае в результате ошибки может быть нару- шено требуемое соответствие заданной спецификации модуля. Такие ошибки требуется обна- руживать и устранять. Для этого и предназначено тестирование сопряжения модулей. При нис- ходящем тестировании тестирование сопряжения осуществляется попутно каждым пропускае- мым тестом, что считают достоинством нисходящего тестирования. При восходящем тестиро- вании обращение к отлаживаемому модулю производится не из модулей отлаживаемой про- граммы, а из ведущего отладочного модуля. В связи с этим существует опасность, что послед- ний модуль может приспособиться к некоторым "заблуждениям" отлаживаемого модуля. По- этому, приступая (в процессе интеграции программы) к отладке нового модуля, приходится те- стировать каждое обращение к ранее отлаженному модулю с целью обнаружения несогласо- ванности этого обращения с телом соответствующего модуля (и не исключено, что виноват в этом ранее отлаженный модуль). Таким образом, приходится частично повторять в новых усло- виях тестирование ранее отлаженного модуля, при этом возникают те же трудности, что и при нисходящем тестировании. Автономное тестирование модуля целесообразно осуществлять в четыре последова- тельно выполняемых шага. Шаг 1. На основании спецификации отлаживаемого модуля подготовьте тесты для каж- дой возможности и каждой ситуации, для каждой границы областей допустимых значений всех входных данных, для каждой области изменения данных, для каждой области недопустимых значений всех входных данных и каждого недопустимого условия. Шаг 2. Проверьте текст модуля, чтобы убедиться, что каждое направление любого раз- ветвления будет пройдено хотя бы на одном тесте. Добавьте недостающие тесты. Шаг 3. Проверьте текст модуля, чтобы убедиться, что для каждого цикла существуют тесты, обеспечивающие, по крайней мере, три следующие ситуации: тело цикла не выполняется ни разу, тело цикла выполняется один раз и тело цикла выполняется максимальное число раз. Добавьте недостающие тесты. Шаг 4. Проверьте текст модуля, чтобы убедиться, что существуют тесты, проверяющие чувствительность к отдельным особым значениям входных данных. Добавьте недостающие те- сты. Комплексная отладка программного средства. Как уже было сказано выше, при комплексной отладке тестируется ПС в целом, причем тесты готовятся по каждому из документов ПС. Тестирование этих документов производится, как правило, в порядке, обратном их разработке. Исключение составляет лишь тестирование документации по применению, которая разрабатывается по внешнему описанию параллельно с разработкой текстов программ - это тестирование лучше производить после завершения те- стирования внешнего описания. Тестирование при комплексной отладке представляет собой применение ПС к конкретным данным, которые в принципе могут возникнуть у пользователя (в частности, все тесты готовятся в форме, рассчитанной на пользователя), но, возможно, в мо- делируемой (а не в реальной) среде. Например, некоторые недоступные при комплексной от- ладке устройства ввода и вывода могут быть заменены их программными имитаторами. Тестирование архитектуры ПС. Целью тестирования является поиск несоответствия между описанием архитектуры и совокупностью программ ПС. К моменту начала тестирования архитектуры ПС должна быть уже закончена автономная отладка каждой подсистемы. Ошибки реализации архитектуры могут быть связаны, прежде всего, с взаимодействием этих подсистем, в частности, с реализацией архитектурных функций (если они есть). Поэтому хотелось бы про- верить все пути взаимодействия между подсистемами ПС. При этом желательно хотя бы про- тестировать все цепочки выполнения подсистем без повторного вхождения последних. Если 56 заданная архитектура представляет ПС в качестве малой системы из выделенных подсистем, то число таких цепочек будет вполне обозримо. Тестирование внешних функций. Целью тестирования является поиск расхождений между функциональной спецификацией и совокупностью программ ПС. Несмотря на то, что все эти программы автономно уже отлажены, указанные расхождения могут быть, например, из-за несоответствия внутренних спецификаций программ и их модулей (на основании которых производилось автономное тестирование) функциональной спецификации ПС. Как правило, те- стирование внешних функций производится так же, как и тестирование модулей на первом шаге, т.е. как черного ящика. Тестирование качества ПС. Целью тестирования является поиск нарушений требова- ний качества, сформулированных в спецификации качества ПС. Это наиболее трудный и наименее изученный вид тестирования. Ясно лишь, что далеко не каждый примитив качества ПС может быть испытан тестированием (об оценке качества ПС см. лекцию 14). Завершенность ПС проверяется уже при тестировании внешних функций. На данном этапе тестирование этого примитива качества может быть продолжено, если требуется получить какую-либо вероятност- ную оценку степени надежности ПС. Однако, методика такого тестирования еще требует своей разработки. Могут тестироваться такие примитивы качества, как точность, устойчивость, за- щищенность, временная эффективность, в какой-то мере - эффективность по памяти, эффек- тивность по устройствам, расширяемость и, частично, независимость от устройств. Каждый из этих видов тестирования имеет свою специфику и заслуживает отдельного рассмотрения. Мы здесь ограничимся лишь их перечислением. Легкость применения ПС (критерий качества, включающий несколько примитивов качества, см. лекцию 4) оценивается при тестировании до- кументации по применению ПС. Тестирование документации по применению ПС. Целью тестирования является поиск несогласованности документации по применению и совокупностью программ ПС, а также вы- явление неудобств, возникающих при применении ПС. Этот этап непосредственно предше- ствует подключению пользователя к завершению разработки ПС (тестированию определения требований к ПС и аттестации ПС), поэтому весьма важно разработчикам сначала самим вос- пользоваться ПС так, как это будет делать пользователь. Все тесты на этом этапе готовятся исключительно на основании только документации по применению ПС. Прежде всего, должны тестироваться возможности ПС как это делалось при тестировании внешних функций, но только на основании документации по применению. Должны быть протестированы все неясные места в документации, а также все примеры, использованные в документации. Далее тестиру- ются наиболее трудные случаи применения ПС с целью обнаружить нарушение требований относительности легкости применения ПС. Тестирование определения требований к ПС. Целью тестирования является выяснение, в какой мере ПС не соответствует предъявленному определению требований к нему. Особен- ность этого вида тестирования заключается в том, что его осуществляет организация-покупа- тель или организация-пользователь ПС как один из путей преодоления барьера между разра- ботчиком и пользователем. Обычно это тестирование производится с помощью контрольных задач - типовых задач, для которых известен результат решения. В тех случаях, когда разраба- тываемое ПС должно придти на смену другой версии ПС, которая решает хотя бы часть задач разрабатываемого ПС, тестирование производится путем решения общих задач с помощью как старого, так и нового ПС (с последующим сопоставлением полученных результатов). Иногда в качестве формы такого тестирования используют опытную эксплуатацию ПС - ограниченное применение нового ПС с анализом использования результатов в практической деятельности. По существу, этот вид тестирования во многом перекликается с испытанием ПС при его атте- стации, но выполняется до аттестации, а иногда и вместо аттестации. Ход работы 1. С помощью системы создания инсталляторов создайте из программы установочный файл. 2. Выполните тестирование удобства установки. 57 3. Выполните тестирование конфигурации оборудования. 4. Выполните тестирование восстановления. 5. Выполните тестирование удобства эксплуатации. 6. Результаты выполнения практического задания запишите в отчет. Практическая работа № 4.13. Сравнение результатов тестирования с требовани- ями технического задания и/или спецификацией Цель работы: описать и проанализировать информационную систему, распределить роли в группе разработчиков. Ход работы Процесс создания профессионального ПО всегда является субъектом бюджетной поли- тики организации, где оно разрабатывается, и имеет временные ограничения. Работа руководи- теля программного проекта по большому счету заключается в том, чтобы гарантировать выпол- нение этих бюджетных и временных ограничений с учетом бизнес-целей организации относи- тельно разрабатываемого ПО. Руководители проектов призваны спланировать все этапы разработки программного продукта. Они также должны контролировать ход выполнения работ и соблюдения всех требу- емых стандартов. Постоянный контроль за ходом выполнения работ необходим для того, чтобы процесс разработки не выходил за временные и бюджетные ограничения. Хорошее управление не гарантирует успешного завершения проекта, но плохое управление обязательно приведет к его провалу. Это может выразиться в задержке сроков сдачи готового ПО, в превышении смет- ной стоимости проекта и в несоответствии готового ПО спецификации требований. Процесс разработки ПО существенно отличается от процессов реализации технических проектов, что порождает определенные сложности в управлении программными проектами: Программный продукт нематериален. Программное обеспечение нематериально, его нельзя увидеть или потрогать. Руководитель программного проекта не видит процесс "роста" разрабатываемого ПО. Он может полагаться только на документацию, которая фиксирует про- цесс разработки программного продукта. Не существует стандартных процессов разработки ПО. На сегодняшний день не суще- ствует четкой зависимости между процессом создания ПО и типом создаваемого программного продукта. Другие технические дисциплины имеют длительную историю, процессы разработки технических изделий многократно опробованы и проверены. Процессы создания большинства технических систем хорошо изучены. Изучением же процессов создания ПО специалисты за- нимаются только последнее время. Поэтому пока нельзя точно предсказать, на каком этапе про- цесса разработки ПО могут возникнуть проблемы, угрожающие всему программному проекту. Большие программные проекты - это часто "одноразовые" проекты. Большие программ- ные проекты, как правило, значительно отличаются от проектов, реализованных ранее. По- этому, чтобы уменьшить неопределенность в планировании проекта, руководители проектов должны обладать очень большим практическим опытом. Но постоянные технологические из- менения в компьютерной технике и коммуникационном оборудовании обесценивают предыду- щий опыт. Знания и навыки, накопленные опытом, могут не востребоваться в новом проекте. Перечисленные отличия могут привести к тому, что реализация проекта выйдет из вре- менного графика или превысит бюджетные ассигнования. Программные системы зачастую ока- зываются новинками как в "идеологическом", так и в техническом плане. Поэтому, предвидя возможные проблемы в реализации программного проекта, следует всегда помнить, что многим из них свойственно выходить за рамки временных и бюджетных ограничений. |