Отладка и тестирование приложений в среде Visual Studio 2005. Евсеева О.Н - 8 стр.

UptoLike

Составители: 

8
С технической точки зрения тестирование заключается в выполнении
приложения на некотором множестве исходных данных и сверке получаемых
результатов с заранее известными (эталонными) с целью установить соответст-
вие различных свойств и характеристик приложения заказанным свойствам.
Классический подход проектирования программных продуктов выделяет
три основные фазы процесса разработки программ, это такие фазы, как:
1. Дизайн приложения – 2. Разработка кода – 3. Тестирование. Как одна из ос-
новных фаз процесса разработки программного продукта тестирование харак-
теризуется достаточно большим вкладом в суммарную трудоемкость разработ-
ки продукта. Широко известна оценка распределения трудоемкости между фа-
зами создания программного продукта: 40% – 20% – 40% [4], из чего следует,
что наибольший эффект в снижении трудоемкости может быть получен прежде
всего на фазах 1 и 3. Поэтому основные вложения в автоматизацию или генера-
цию кода следует осуществлять, прежде всего, на этих фазах. Хотя в современ-
ном индустриальном программировании автоматизация тестирования является
широко распространенной практикой, в то же время технология верификации
требований и спецификаций пока делает только свои первые шаги.
Задачей ближайшего будущего является движение в сторону такого рас-
пределения трудоемкости (60% – 20% – 20%), чтобы суммарная цена обнару-
жения большинства дефектов стремилась к минимуму за счет обнаружения пре-
имущественного числа на наиболее ранних фазах разработки программного
продукта.
Правила и законы разработки программных продуктов
Жизненный цикл программной системы
Под «жизненным циклом» понимается период от замысла программного
продукта до его «кончины». Обычно рассматриваются следующие этапы этого
процесса:
I. Проектирование
II. Разработка
III. Развертывание
IV. Сопровождение
Все это называется циклом, поскольку на каждом этапе возможен возврат
к предыдущим этапам. В объектной технологии этот процесс является бесшов-
ным, все этапы которого тесно переплетены. Не следует рассматривать его как
однонаправленныйот проектирования к сопровождению. Чаще всего, ситуа-
ция обратная: уже существующая реализация системы, прошедшая сопровож-
дение, и существующие библиотеки компонентов оказывают решающее влия-
ние на то, какой будет новая система, каковы будут ее спецификации.
Обратите внимание на следующие типовые правила, характерные для
процесса разработки программного обеспечения [1,14]: