27. Пошаговое тестирование модульных программ. Достоинства и недостатки подходов.*

В тестирование многомодульных программ можно выделить 4 этапа :1 тест-ие отдельных модулей;2совместное тест-ие модулей;3 тест-ие спецификации программы;4 тест-ие всего комплекса в целом (т.е. поиск несоответствия созданного программного продукта сформулированным ранее целям проектирования, отраженным в ТЗ).На первых 2 этапах исп-ся прежде всего методы структурного тест-ия, тк на последующих этапах тест-я эти методы использовать сложнее из-за больших размеров проверяемого ПО; последующие этапы тест-я ориентированы на обнаружение ошибок различного типа, которые не обязательно связаны с логикой программы.Известны 2 подхода к тестированию модулей: монолитное и пошаговое тест-ие.При пошаговом тест-ии каж-й модуль для своего тест-я подключается к набору уже проверенных модулей ,модули проверяются не изолированно друг от друга, поэтому требуются либо только драйверы, либо только заглушки. При пошаговом тест-и возможны 2 стратегии подключения модулей: нисходящая и восходящя. Нисх-е тест-е начинается с главного (или верхнего) модуля программы, а выбор след-го подключаемого модуля происходит из числа м-ей, вызываемых из уже протестированных. 1 из осн-ых проблем, возникающих при нисх-м тест-и, - создание заглушек. Осн-е достоинства нисх-о тест-ия: уже на ранней стадии тес-я есть возм-сть получить работающий вариант разрабатываемой программы; быстро могут быть выявлены ошибки, связанные с организацией взаимодействие с пользователем При восходящем тес-и проверка программы начинается с терминальных модулей (тех, к-е не вызывают не какие другие модули программы). Эта стратегия во многом противоположна нисх-му тест-ю Преимущества:поскольку нет промежуточных модулей, нет проблем, связанных с возможностью или трудностью задания тестов;нет трудностей, вызывающих желание перейти к тестированию следующего модуля, не завершив проверки предыдущего.Недостатком ВТ яв-ся то , что проверка всей структуры разрабатываемого программного комплекса возможна только на завершающей стадии тест-я.

28. Стихийное программирование. Этапы совершенствования архитектуры программ.*

Суть его в том, чтобы из операторов языка программирования сконструировать программу, выполняющую некоторое (заданное) преобразование данных. Ни набор операторов, ни порядок их применения никак не регламентировался. В общем случае для такого программирования, чем больше операторов в языке программирования, тем лучше.

Главный недостаток разработанного таким образом ПО – большие трудности его сопровождения. Как правило, в таких программах может разобраться только автор, они плохо пригодны для тиражирования и превращения в товар.

Программирование фактически было искусством. Первые программы состояли из собственно программы на машинном языке и обрабатываемых ею данных. Появление ассемблеров позволило вместо двоичных или 16-ричных кодов использовать символические имена данных и мнемоники кодов операций. В результате программы стали более «читаемыми».

Создание языков программирования высокого уровня, таких, как FORTRAN и ALGOL, существенно упростило программирование вычислений, снизив уровень детализации операций. Это, в свою очередь, позволило увеличить сложность программ. Революционным было появление в языках средств, позволяющих оперировать подпрограммами. Подпрограммы можно было сохранять и использовать в других программах. В результате бы­ли созданы огромные библиотеки рас­четных и служебных подпрограмм, которые по мере надобности вызывались из разрабатываемой программы. Типичная программа того време­ни состояла из основной программы, области глобальных данных и набора подпрограмм (в основном библиотеч­ных), выполняющих обработку всех данных или их части. Слабым местом такой архитектуры было то, что при увеличении коли­чества подпрограмм возрастала вероятность искажения части глобальных данных какой-либо подпрограммой.

Кризис: 80% времени – отладка и тестирование В начале 60-х годов XX в. раз­разился «кризис программирова­ния». Он выражался в том, что фирмы, взявшиеся за разработку Подпрограммы с локальными данными сложного программного обеспече­ния, такого, как операционные системы, срывали все сроки завершения проектов. Проект устаревал раньше, чем был готов к внедрению, увеличивалась его стоимость, и в ре­зультате многие проекты так никогда и не были завершены. стихийно использовалась разработка «снизу-вверх» - подход.