Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
11 / тп / Venchkovsky.doc
Скачиваний:
113
Добавлен:
19.05.2015
Размер:
515.07 Кб
Скачать

8.2.Кодирование модулей

Когда завершено проектирование каждого модуля и проведены его обзор и утверждение, можно начинать кодирование (написание программ). При этом также должны быть установлены и докумен­тированы требования кодирования, которые определяют правила:

• представления комментариев в программах;

• наименования программ, подпрограмм, файлов, переменных;

• ограничения размеров модулей;

• использования библиотек;

• определения констант; • использования специальных средств компилятора, которых нет в языке;

• обработки ошибок и т.п.

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

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

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

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

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

8.3.Тестирование программного изделия

Процесс тестирования проходит несколько этапов: поблочное, комплексное и системное.

Тестирование блоков показывает правильность реализации всех компонент программного изделия, начиная с само­го нижнего уровня, определенного в детальном проекте, вплоть до самого нижнего уровня архитектурного проекта (обычно на уровне задач). Модули, которые не вызывают другие модули, — модули нижнего уровня детального проекта.

При тестировании блоков обычно проверяется правильность не только того, что функционально выполняет модуль, но и того, как он это делает. Таким образом, при тестировании блоков использу­ется не только функциональное тестирование (тестирование "черно­го ящика"), но и структурное тестирование (тестирование "белого ящика").

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

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

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

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

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

Системное тестирование включает:

• передачу данных в систему, проверку корректности обработки данных и вывод результатов;

• прогон тестов с целью проверки выполнения требований поль­зователя;

• стрессовое тестирование для верификации предельных харак­теристик программного изделия;

• предварительную оценку надежности и пригодности к сопро­вождению;

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

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

Соседние файлы в папке тп