Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование и разработка информационных систем. Учебное пособие для СПО
.pdf
41
– Достаточно ли он реалистичен? Удовлетворяют ли
имеющиеся системные ресурсы (как аппаратные, так и программные) потребностям проекта? Сможет ли программный
продукт работать достаточно быстро, достаточно быстро извлекать информацию из баз данных и ее обрабатывать? Удачно ли
выбраны инструментальные средства разработчиков?
– Хорошо ли описана в проекте подсистема обработки
ошибок? При нисходящем проектировании особенно велико
искушение оставить вопросы обработки ошибок на потом — как
самые незначительные. И когда наступает это «потом», о подобных элементах часто вообще забывают, или же из-за нехватки
времени они проектируются наспех, поверхностно и в результате — плохо. Все возможные условия возникновения ошибок
должны быть самым тщательным образом продуманы и описаны
в проекте. Важно правильно определить уровень, на котором
обрабатывается каждая из ошибок, чтобы ее возникновение в
одном модуле не вело к ошибкам в других.
1.4.3. Тестирование на этапе кодирования
На этом этапе к работе по тестированию привлекается
специальная группа — тестировщики.
Программный код ИС невозможно протестировать как
единый цельный программный элемент (исключение — небольшие программы)
На рис. 1.5 показан поэтапный процесс тестирования, где:
– сначала тестируются отдельные программные компоненты и подсистемы;
– затем собранная система;
– система с данными, предоставленными заказчиком.
42
Рис. 1.5. Процесс тестирования при кодировании
Процесс тестирования состоит из нескольких этапов:
1. Тестирование процедур. Тестируются отдельные ком-
поненты для проверки правильности их функционирования.
Каждый компонент тестируется независимо от других.
2. Тестирование модулей. Программный модуль — это
совокупность зависимых компонентов, таких, как описание
класса объектов, декларирование абстрактных типов данных и
набор процедур и функций.
3. Тестирование подсистем. Тестируются наборы моду-
лей, которые составляют отдельные подсистемы.
4. Тестирование системы. Из подсистем собирается ко-
нечная система. И проверяется совместимость интерфейсов подсистем
5. Приемочные испытания. Это конечный этап процесса
тестирования, после которого система принимается к эксплуатации. Выявляются ошибки в системных требованиях, поскольку
испытания с реальными данными могут дать иной результат,
чем тестирование со специально подобранными тестовыми данными.
Приемочные испытания иногда называют альфатестиро-
ванием. Сделанные на заказ системы предназначены для одного
заказчика. Для таких систем процесс альфа-тестирования продолжается до тех пор, пока разработчики и заказчик не удосто-
43
верятся в том, что разработанная система полностью соответствует системным требованиям.
Если система разрабатывается для продажи на рынке программных продуктов, используется так называемое бетатести-
рование. Для бетатестирования система рассылает большому
числу потенциальных пользователей и заказчиков. Они отсылают разработчикам отчеты о выявленных проблемах в эксплуатации системы. Бетатестирование позволяет проверить систему в
реальных условиях эксплуатации и найти ошибки, пропущенные
разработчиками. После получения отчетов об испытаниях система модернизируется и снова передается на бетатестирова-
ние либо сразу поступает в продажу.
Методы «стеклянного» и «черного» ящика
И вот, наконец, наступает этап кодирования: программист
пишет программы и сам их тестирует. Поскольку курс «проектирование информационных систем» не предполагает получение
навыков написания программ, этап кодирования не рассмотрен в
этом пособии.
Однако следует ознакомиться с технологией тестирования,
которая применяется на этом этапе. Эта технология называется
тестированием «стеклянного ящика» (glass box) — иногда ее еще
называют тестированием «белого ящика» (white box) в противоположность классическому понятию «черного ящика» (black box).
При тестировании «черного ящика» программа рассматривается как объект,чс внутренняя структура которого неизвестна.
Тестировщик вводит данные и анализирует результат, но, как
именно работает программа, он не знает. Подбирая тесты, специалист ищет интересные с его точки зрения входные данные и
условия, которые могут привести к нестандартным результатам.
Интересны для него, прежде всего, те представители каждого
класса входных данных, на которых с наибольшей вероятностью
могут проявиться ошибки тестируемой программы.
При тестировании «стеклянного ящика» ситуация совершенно иная. Тестировщик (как правило, это программист) разрабатывает тесты, основываясь на знании исходного кода, к которому он имеет полный доступ. В результате он получает следующие преимущества.
44
– Направленность тестирования. Программист может тестировать программу по частям, разработать специальные тестовые подпрограммки, которые вызывают тестируемый модуль и
передают ему интересующие программиста данные. Отдельный
модуль гораздо легче протестировать именно как "стеклянный
ящик".
– Полный охват кода. Программист всегда может определить, какие именно фрагменты кода работают в каждом тесте.
Он видит, какие еще ветви кода остались непротестированными,
и может подобрать условия, в которых они будут выполнены
– Управление потоком. Программист всегда знает, какая
функция должна выполняться в программе следующей и каким
должно быть ее текущее состояние. Чтобы выяснить, работает
ли программа так, как он думает, программист может включить
в нее отладочные команды, отображающие информацию о ходе
ее выполнения, или воспользоваться для этого специальным
программным средством, называемым отладчиком. (Отладчик
может делать очень много полезных вещей: отслеживать и менять последовательность выполнения команд программы, показывать содержимое ее переменных и их адреса в памяти и многое другое.)
– Отслеживание целостности данных. Программисту известно, какая часть программы должна изменять каждый элемент данных. Отслеживая состояние данных (с помощью того
же отладчика), он может выявить такие ошибки, как изменение
данных не теми модулями, их неверная интерпретация или неудачная организация. Программист может и самостоятельно автоматизировать тестирование.
– Внутренние граничные точки. В исходном коде видны
те граничные точки программы, которые скрыты от взгляда
"извне". Например, для выполнения определенного действия
может быть использовано несколько совершенно различных алгоритмов, и, не заглянув в код, невозможно определить, какой из
них выбрал программист. Еще одним типичным примером может быть проблема переполнения буфера, используемого для
временного хранения входных данных. Программист сразу может сказать, при каком количестве данных буфер переполнится,
и ему не нужно при этом проводить тысячи тестов.
45
– Тестирование, определяемое выбранным алгоритмом.
Для тестирования обработки данных, использующей очень
сложные вычислительные алгоритмы, могут понадобиться специальные технологии. В качестве классических примеров можно
привести преобразование матрицы и сортировку данных. Тестировщику нужно точно знать, какие алгоритмы используются, и
обратиться к специальной литературе.
Тестирование «стеклянного ящика» мы рассматриваем как
часть процесса программирования. Программисты выполняют
эту работу постоянно, тестируют каждый модуль после его
написания, а затем еще раз после интеграции его в систему.
Однако не менее важно тестирование методом «черного
ящика», и именно ему посвящают большую часть времени все
профессиональные тестировщики. (Отдельную и достаточно
специфическую область тестирования представляют собой
СУБД для мэйнфреймов.)
Тестировщик «черного ящика» не изучает исходный код
программы — он исследует ее извне, работая с ней так, как это
будет делать пользователь. И так же, как исследование программы изнутри позволяет выявить проблемы и критические точки,
которых не видно извне, так и тестирование методом «черного
ящика» выявляет ошибки и недостатки, которые программист
упускает.
Тестирование частей против тестирования целого
Любая система разрабатывается по частям — как набор
процессов или модулей. Можно ее так и тестировать — сначала
отдельные части, а потом их взаимодействие. Такая стратегия
называется восходящей (bottom-up).
Выяснив, что отдельные элементы программы находятся в
порядке, специалист приступает к тестированию их совместной
работы. И тут может оказаться, что вместе они работать отказываются. Например, если программист случайно поменяет местами параметры вызываемой функции, при выполнении вызова
произойдет ошибка. И выявлена она будет только при проверке
совместной работы обеих функций — вызывающей и вызываемой.
Тестирование совместной работы программных модулей
называют интеграционным. В ходе такого тестирования модули
46
сначала объединяются в пары, потом в большие блоки, пока,
наконец, все модули не будут объединены в единую систему.
Восходящее тестирование — это прекрасный способ локализации ошибок. Если ошибка обнаружена при тестировании
единственного модуля, то очевидно, что она содержится именно
в нем — для поиска ее источника не нужно анализировать код
всей системы. А если ошибка проявляется при совместной работе двух предварительно протестированных модулей, значит, дело в их интерфейсе. Еще одним преимуществом восходящего
тестирования является то, что выполняющий его программист
концентрируется на очень узкой области (единственном модуле,
передаче данных между парой модулей и т. п.). Благодаря этому
тестирование проводится более тщательно и с большей вероятностью выявляет ошибки.
Главный недостаток восходящего тестирования — необходимость написания специального кода-оболочки, вызывающего тестируемый модуль. Если он, в свою очередь, вызывает другой модуль, для него нужно написать заглушку. Заглушка — это
имитация вызываемой функции, возвращающая те же данные,
но ничего больше не делающая.
Понятно, что написание оболочек и заглушек замедляет
работу, а для конечного продукта они абсолютно бесполезны.
Но написанные однажды, эти элементы могут использоваться
повторно при каждом изменении программы. Хороший набор
оболочек и заглушек — это очень эффективный инструмент тестирования.
В противоположность восходящему тестированию, стратегия целостного тестирования предполагает, что до полной ин-
теграции системы ее отдельные модули не проходят особо тщательного тестирования.
Преимуществом такой стратегии является то, что нет
необходимости в написании дополнительного кода. Поэтому
многие руководители выбирают этот способ из соображений
экономии времени, они считают, что лучше разработать один
обширный набор тестов и с его помощью за один раз проверить
всю систему. Но такое представление совершенно ошибочно, и
вот почему.
47
– Очень трудно выявить источник ошибки. Это главная
проблема. Поскольку ни один из модулей не проверен, как следует, в большинстве из них есть ошибки. Получается, что вопрос
не столько в том, в каком модуле произошла обнаруженная
ошибка, сколько в том, какая из ошибок во всех вовлеченных в
процесс модулях привела к полученному результату. И когда
накладываются ошибки нескольких модулей, ситуацию может
быть гораздо труднее локализовать и повторить.
Кроме того, ошибка в одном из модулей может блокировать тестирование другого. Как протестировать функцию, если
вызывающий ее модуль не работает? Если не написать для этой
функции программу-оболочку, придется ждать отладки модуля,
а это может затянуться надолго.
– Трудно организовать исправление ошибок. Если программу пишут несколько программистов (а именно так и бывает
в больших системах), и при этом неизвестно, в каком модуле
ошибка, кто же будет ее искать и исправлять. Один программист
будет указывать на другого, тот, выяснив, что его код ни при
чем, снова обратится к первому, а в результате будет сильно
страдать скорость разработки.
– Процесс тестирования плохо автоматизирован. То, что
на первый взгляд кажется преимуществом целостного тестирования — отсутствие необходимости писать оболочки и заглушки
на самом деле оборачивается его недостатком. В процессе разработки программа ежедневно меняется и ее приходится тестировать снова и снова. А оболочки и заглушки помогают автоматизировать этот однообразный труд.
Поскольку большинство руководителей проектов отнюдь
не глупы, когда кто-нибудь из них выбирает целостное тестирование, можно предположить, что в своем конкретном случае он
видит такие преимущества этого подхода, которые отнюдь не
очевидны. Есть и такие руководители, которые не слишком заботятся об эффективности тестирования. Главное для них — как
можно скорее отрапортовать начальству о завершении работ,
даже если на самом деле ничего не работает. Если после этого с
проектом возникнут проблемы, они будут обвинять законы
Мэрфи, тестировщиков, невезение, но только не самих себя —
48
собственную часть работы они будут считать выполненной
успешно и в срок.
Тестирование нисходящее и восходящее
Существует и еще один принцип организации тестирования, при котором программа так же, как и при восходящем способе, тестируется не целиком, а по частям. Только направление
движения меняется — сначала тестируется самый верхний уровень иерархии модулей, а от него тестировщик постепенно спускается вниз. Такая технология называется нисходящей (topdown). Обе технологии — и нисходящую, и восходящую —
называют также инкрементальными.
При нисходящем тестировании отпадает необходимость в
написании оболочек, но заглушки остаются. По мере тестирования «заглушки» по очереди заменяются на реальные модули.
Мнения специалистов о том, какая из двух инкрементальных стратегий тестирования более эффективна, сильно расходятся. Йордан (Yourdon, 1975) доказывает, что гораздо лучше
нисходящее тестирование, а Майерс (Myers, 1976) утверждает,
что, хотя у обоих подходов есть свои преимущества и недостатки, в целом восходящее тестирование лучше. По мнению же
Данна (Dunn, 1984), эти способы примерно эквивалентны.
На практике вопрос выбора стратегии тестирования обычно решается просто: каждый модуль по возможности тестируется сразу после его написания, в результате последовательность
тестирования одних частей программы может оказаться восходящей, а других — нисходящей.
При статическом тестировании программный код вообще
не выполняется — он тестируется только путем логического
анализа.
Две описанные выше базовые стратегии — тестирование
«черного ящика» и тестирование «стеклянного ящика» — являются динамическими. Программа запускается, вводятся данные,
и программист или тестировщик анализирует результат. Разница
только в том, на какой информации основывается подбор тестов.
Для статического анализа существует множество инструментальных средств. Самое известное из них — компилятор.
Встретив синтаксическую ошибку или недопустимую операцию,
компилятор выдает соответствующее сообщение. Ряд полезных
49
сообщений выдает и компоновщик — о повторяющихся именах
переменных и других объектов, ссылках на необъявленные переменные и функции.
Статический анализ программы может выполняться и
людьми. Они читают исходный код, возможно, обсуждают его,
и, как правило, находят достаточно много ошибок. Вот примеры
такой работы.
– Обзорные, инспекционные и рецензионные совещания.
Это точно такие же совещания, какие проводятся для анализа
проекта программного продукта.
– Работа за столом. Статический анализ программного кода может выполняться и в одиночку. Специалист читает и анализирует программный код. Если он не может понять, что делает
конкретный фрагмент программы, он может поработать и за
компьютером, но большую часть времени проводит за столом.
Он работает дольше, чем обычно длятся совещания, и, как правило, анализирует гораздо большие объемы кода. Этот вид тестирования может выполнять как сам автор программного кода,
так и кто-то другой, в любом случае оно будет очень полезным.
1.5. Внедрение
Задача разработчиков на этапе внедрения обучить персонал работе с помощью ИС, подготовить АО и поставить ИС на
компьютеры заказчика.
Стадия «Внедрение проекта» — это подготовка и постепенное освоение разработанной проектной документации заказчиками. Выявляются частные и принципиальные недоработки в
ПО.
Внедрение может осуществляться:
– последовательно, когда последовательно внедряется одна подсистема за другой и одна задача следует за другой задачей;
– когда все задачи внедряются во всех подсистемах одновременно;
– смешанно, при котором проектировщики, внедрив несколько подсистем первым методом, накопив опыт, приступают
к параллельному внедрению остальных.
50
Недостатком первого подхода является увеличение длительности внедрения, что ведет за собой рост стоимости проекта. При использовании второго подхода сокращается время
внедрения, но возникает возможность пропуска ошибок в проектной документации, поэтому чаще всего используют смешанный метод внедрения проекта ИС.
Внедрение проекта осуществляется в три этапа:
1) подготовка объекта к внедрению;
2) опытное внедрение;
3) сдача проекта в промышленную эксплуатацию.
Первый этап «Подготовка объекта к внедрению». На
этом этапе осуществляются следующие операции:
– изменяется организационная структура объекта (предприятия);
– набираются кадры соответствующей квалификации в области обработки информации и эксплуатации системы и сопровождения проектной документации;
– оборудуется здание под установку вычислительной техники;
– выполняются закупка и установка вычислительной техники с периферией;
– в цехах, отделах устанавливаются средства сбора, регистрации первичной информации и передачи по каналам связи;
– осуществляется установка каналов связи; проводится
разработка новых документов и классификаторов;
– осуществляется создание файлов информационной базы
с нормативно-справочной информацией.
В результате выполнения этапа составляется акт готовности объекта к внедрению. Затем формируется состав приемной
комиссии, разрабатывается программа проведения опытного
внедрения и издается приказ о начале опытного внедрения.
Второй этап «Опытное внедрение». В процессе опытного
внедрения выполняются работы по решению с помощью внедряемого ПО реальных задач заказчика и анализ результата на
предмет наличия ошибок.
В случае обнаружения ошибок осуществляются поиск
причин и источников ошибок, внесение исправлений. Кроме то-
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]