Восходящее и нисходящее тестирование

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

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

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

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

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

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

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

Методология быстрой разработки приложений (RAD)

Одним из подходов к разработке ПС в рамках спиральной модели ЖЦ является методоло­гия быстрой разработки приложений RAD (Rapid Appli­ca­tion Development). Для ее реализации требуются три составляющие:

· небольшая команда программистов (от 2 до 10 чел.);

· короткий (от 2 до 6 мес.), но тщательно проработанный произ­водст­вен­ный гра­фик;

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

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

Жизненный цикл ПС по методологии RAD состоит из четырех фаз.

1. На фазе анализа и планирования требований пользователи определяют функции, которые система должна выполнять, выделяют приоритетные, описывают информационные потреб­ности. Формулиро­ва­ние требований к сис­теме осуществляет­ся в основном силами поль­зователей под руковод­ст­вом спе­циалистов-разработчиков. Ограни­чивается масштаб проекта, уста­навливаются временные рамки для каждой последую­щей фазы. Кроме того, определяется сама возможность реали­зации проекта в заданных размерах финансирования, на име­ющихся аппаратных средствах и т.п. Результатом долж­ны быть список расстав­ленных по приоритету функ­ций будущей ИС, предварительные функциональные и информа­ционные модели ИС.

2. На фазе проектирования часть пользователей принимает учас­тие в техническом проектировании системы под руководством спе­циалистов-разработчиков. CASE-средства используются для быс­трого получения работающих прототипов приложений. Пользо­ватели, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, ко­то­рые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и при необходимости корректируется функциональная модель. Каждый процесс рассматривается детально. Если требуется, то для каждого элементарного процесса создает­ся частичный прототип: экран, диалог, отчет, устраняющий неяс­ности или неоднозначности. Устанавливаются требования разграничения доступа к данным. На этой же фазе происходит определение необходимой докумен­тации. После детального определения состава процессов оценивается ко­личество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающи­еся реализации одной командой разработчиков за приемлемое дляRAD-проектов время (60–90 дней). С использованием CASE-средств проект распределяется между различными командами (делится фун­кциональная модель). В результате на данной фазе формируются:

· общая информационная модель системы;

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

· точно определенные с помощью CASE-средств интерфейсы между автономно разрабатываемыми подсистемами;

· построенные прототипы экранов, отчетов, диалогов.

3. На фазе построения непосредственно происходит быст­рая раз­работка приложения. Разработчики производят интерактивное построение реальной системы на основе полу­ченных в предыдущей фазе моделей, а также требований нефунк­ционального характера. Прог­рам­мный код частич­но формируется при помощи автоматических гене­раторов, получающих информа­цию из репозитория CASE-средств. Поль­зо­ва­тели оценивают полученные результаты и вносят кор­рек­ти­вы, если в процессе разработки система перестает удовлетворять опреде­лен­ным ранее требова­ниям. Тестирование системы осуществля­ется в процессе разработки.

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

На завершающем этапе физического проектирования системы:

· определяется необходимость распределения данных;

· осуществляется анализ использования данных;

· производится физическое проектирование базы данных;

· определяются требования к аппаратным ресурсам;

· определяются способы увеличения производительности;

· завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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