17Этап разработки программного продукта. Модульное тестирование.

1.1. Основные этапы технологического процесса разработки программ.

1. Постановка задачи.

2. Построение математической модели.

3. Разработка (выбор и адаптация) алгоритма.

4. Составление программы.

5. Тестирование и отладка.

6. Сдача в эксплуатацию.

Постановка задачи.  На этом этапе раскрывается организационно-экономическая сущность задачи:

• формулируется цель ее решения

• определяется взаимосвязь с другими задачами

• указывается периодичность ее решения

• раскрывается состав и форма представления входной, промежуточной и выходной информации

• характеризуются формы и методы контроля достоверности информации

• описываются формы взаимодействия пользователя с ЭВМ

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

• форма представления отдельных данных

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

• источник возникновения данных

Кроме того, для цифровой информации указывается:

• целочисленный или дробный характер данных (для дробных указывается количество 10-х знаков) и допустимый диапазон изменения величин.

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

1. Анализ существующих аналогов задачи.

2. Анализ технических и программных средств.

3. Разработка математической модели.

4. Разработка структур данных.

Естественный язык, на котором осуществляется постановка задачи, имеет свойство неоднозначности. Создание математической модели позволяет формализовать описание задачи. При этом устанавливается и формируется средствами языка математики логико-математической зависимости между исходными и результатными данными.  Математическая модель - это система математических соотношений (формул, уравнений, неравенств и т.д.), отражающих существенные свойства объекта или явления.  Математическая запись постановки задачи отличается высокой точностью отображения ее сущности, лаконичностью записи, однозначностью понимания, но она может быть выполнена не для всех задач.  При выборе метода решения предпочтение отдается методу, который:

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

2. Позволяет использовать уже готовые стандартные программы.

3. Ориентирован на минимальный объем информации.

4. Наиболее быстрое получение результатов.

План написания постановки задачи (ПЗ).

1. Наименование задачи.

2. Назначение.

3. Достигаемая цель.

4. Для кого предназначена.

5. Технические средства.

6. Периодичность использования.

7. Входная информация.

8. Выходная информация (формируется по запросам).

9. Метод проверки правильности (сравнивается с контрольным примером).

10. Организация внедрения задачи.

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

12. Методы защиты.

тестирование На этапе кодирования программист пишет программы и сам их тестирует. Такое тестирование называется модульным. Эта технология называется тестированием «стеклянного ящика» (glass box); иногда ее еще называют тестиро¬ванием «белого ящика» (white box) в противоположность класси¬ческому понятию «черного ящика» (black box). При тестировании «черного ящика» программа рассматривает¬ся как объект, внутренняя структура которого неизвестна. Тестировщик вводит данные и анализирует результат, но он не знает, как именно работает программа. Подбирая тесты, специалист ищет интересные с его точки зрения входные данные и условия, кото¬рые могут привести к нестандартным результатам. Интересны для него прежде всего те представители каждого класса входных дан¬ных, при которых с наибольшей вероятностью могут проявиться ошибки тестируемой программы. При тестировании «стеклянного ящика» ситуация совершенно иная. Тестировщик (в данном случае сам программист) разраба¬тывает тесты, основываясь на знании исходного кода, к которому он имеет полный доступ. В результате он получает следующие пре¬имущества: • Направленность тестирования. Программист может тестиро¬вать программу по частям, разрабатывать специальные тестовые подпрограммки, которые вызывают тестируемый модуль и пере¬дают ему интересующие программиста данные. Отдельный модуль гораздо легче протестировать именно как «стеклянный ящик». • Полный охват кода. Программист всегда может определить, какие именно фрагменты кода работают в каждом тесте. Он видит, какие еще ветви кода остались непротестированными, и может подобрать условия, в которых они будут протестированы.  • Возможность управления потоком команд. Программист все¬гда знает, какая функция должна выполняться в программе следующей и каким должно быть ее текущее состояние.   • Возможность отслеживания целостности данных. Програм¬мисту известно, какая часть программы должна изменять каждый элемент данных. Отслеживая состояние данных, он может выявить такие ошибки, как изменение данных не теми модулями, их неверная интерпретация или неудачная организация.   • Видение внутренних граничных точек. В исходном коде видны те граничные точки программы, которые скрыты от взгляда извне. Например, для выполнения определенного действия может быть использовано несколько совершенно различных алгоритмов, и, не заглянув в код, невозможно определить, какой из них выбрал программист.   • Возможность тестирования, определяемого выбранным алго¬ритмом. Для тестирования обработки данных, использующей очень сложные вычислительные алгоритмы, могут понадобиться специальные технологии. В качестве классических примеров можно привести преобразование матрицы и сортировку данных. Тести- ровщику, в отличие от программиста, нужно точно знать, какие алгоритмы используются, поэтому приходится обращаться к специальной литературе. Тестирование «стеклянного ящика» — часть процесса програм¬мирования. Программисты выполняют эту работу постоянно, они тестируют каждый модуль после его написания, а затем еще раз после интеграции его в систему. При выполнении модульного тестирования можно использо¬вать технологию либо структурного, либо функционального тес¬тирования или и ту, и другую. Структурное тестирование является одним из видов тестиро¬вания «стеклянного ящика». Его главной идеей является правиль¬ный выбор тестируемого программного пути. В противоположность ему функциональное тестирование относится к категории тестиро¬вания «черного ящика». Каждая функция программы тестируется путем ввода ее входных данных и анализа выходных. При этом внутренняя структура программы учитывается очень редко. Хотя структурное тестирование имеет гораздо более мощную теоретическую основу, большинство тестировщиков предпочи¬тают функциональное тестирование. Структурное тестирование лучше поддается математическому моделированию, но это со¬всем не означает, что оно эффективнее. Каждая из технологий позволяет выявить ошибки, пропускаемые в случае использова¬ния другой. С этой точки зрения их можно назвать одинаково эффективными. Любая система разрабатывается по частям — как набор про¬цессов или модулей. Можно ее так и тестировать, т. е. сначала про¬верять отдельные части, а потом уже их взаимодействие. Такое тестирование называется восходящим (bottom-up). Выяснив, что отдельные элементы программы в порядке, спе¬циалист приступает к тестированию их совместной работы. И туз может оказаться, что вместе они работать отказываются. Напри¬мер, если программист случайно поменяет местами параметры вызываемой функции, то при выполнении вызова произойдет ошибка. И выявлена она будет только при проверке совместной работы обеих функций — вызывающей и вызываемой. Тестирование совместной работы программных модулей назы¬вают интеграционным. В ходе такого тестирования модули сначала объединяют в пары, потом в большие блоки, пока, наконец, все модули не будут объединены в единую систему. Интеграционное тестирование всей системы выполняет тестировщик, но интегра¬ционное тестирование какой-либо подзадачи — разрабатывающий ее программист. Восходящее тестирование — это прекрасный способ локализа¬ции ошибок. Если ошибка обнаружена при тестировании един¬ственного модуля, то очевидно, что она содержится именно В нем, и для поиска ее источника не нужно анализировать код всей системы. Если же ошибка проявляется при совместной работе двух предварительно протестированных модулей, значит, дело в их интерфейсе. Еще одним преимуществом восходящего тестирова¬ния является то, что выполняющий его программист концентри¬руется на очень узкой области (единственном модуле, передаче данных между парой модулей и т.п.).  Благодаря этому тестирова¬ние проводится более тщательно и с большей вероятностью вы¬являет ошибки. Главным недостатком восходящего тестирования является не¬обходимость написания специального кода-оболочки, вызыва¬ющего тестируемый модуль. Если тот, в свою очередь, вызывает другой модуль, то для него нужно написать заглушку. Заглушка — это имитация вызываемой функции, возвращающая те же дан¬ные, но ничего больше не делающая. Написание оболочек и заглушек замедляет работу, а для ко¬нечного продукта они абсолютно бесполезны, но созданные од¬нажды, эти элементы могут использоваться повторно при каждом изменении программы. Хороший набор оболочек и заглушек — это очень эффективный инструмент тестирования. В противоположность стратегии восходящего тестирования стра¬тегия целостного тестирования предполагает, что до полной ин¬теграции системы ее отдельные модули не проходят особо тща¬тельного тестирования. Преимуществом такой стратегии является отсутствие необходимости написания дополнительного кода. Мно¬гие программисты выбирают этот способ тестирования из сообра¬жений экономии времени, считая, что лучше разработать один обширный набор тестов и с его помощью за один раз проверить всю систему. Но такое представление совершенно ошибочно по следующим причинам. • Очень трудно выявить источник ошибки. Это главная проблема. Поскольку ни один из модулей не проверен как следует, в большинстве из них есть ошибки. Поэтому вопрос не столько в том, в каком модуле произошла обнаруженная ошибка, сколько в том, какая из ошибок во всех вовлеченных в процесс модулях привела к полученному результату. Когда накладываются ошибки нескольких модулей, бывает гораздо труднее локализовать источник ошибки. • Трудно организовать исправление ошибок. Если программу пишут несколько программистов (а именно так и бывает в случае больших систем) и при этом неизвестно, в каком модуле ошибка, кто же должен ее искать и исправлять? Первый программист будет указывать на второго, тот, выяснив, что его код ни при чем, переложит ответственность на первого, а в результате силь¬но снизится скорость разработки. • Процесс тестирования трудно автоматизировать. То, что на первый взгляд кажется преимуществом целостного тестирования, а именно отсутствие необходимости создавать оболочки и заглуш¬ки, на самом деле оборачивается его недостатком. В процессе раз¬работки программа ежедневно меняется и ее приходится тестировать снова и снова, а оболочки и заглушки помогают автоматизи¬ровать этот однообразный труд. Существует еще один принцип организации тестирования, когда программа, как и при восходящем способе, тестируется не цели¬ком, а по частям, только направление движения меняется — сна¬чала тестируется самый верхний уровень иерархии модулей, а от него тестировщик постепенно спускается вниз. Такое тестирова¬ние называется нисходящим (top-down). И нисходящее и восходя¬щее тестирования называют также инкрементальными. При нисходящем тестировании отпадает необходимость в на¬писании оболочек, но заглушки остаются. По мере тестирования заглушки по очереди заменяются на реальные модули.  При статическом тестировании программный код вообще не выполняется — он тестируется только путем логического анализа. Для статического анализа существует множество инструмен¬тальных средств. Самое известное из них — компилятор. Встретив синтаксическую ошибку или недопустимую операцию, компиля¬тор выдает соответствующее сообщение. Статический анализ программы может выполняться и людьми. Они читают исходный код, возможно, обсуждают его, и, как правило, находят достаточно много ошибок.