Решения на основе работы OLAP + SQL-база

OLAP-системы, разрабатываемые для среды “клиент-сервер”, как правило, состояли, с одной стороны, из OLAP-серверов, реализующих хранение и обработку многомерных массивов данных с использова­ нием так называемой OLAP-ьлгшты (MOLAP), а с другой из OLAP- клиентов, которые позволяют пользователям выполнять нужный им анализ на основе результатов запросов к OLAP-серверу. Стоимость одного рабочего места OZ^P-системы измерялась тысячами, а то и десятками тысяч долларов. Только крупные западные корпорации могли позволить себе такие расходы.

Однако, в последнее время ситуация изменилась: в области OLAP-технологии происходит технологический перелом. Во-первых, OLAP-серверы интегрируются в основные реляционные клиент-сер­ верные СУБД, становясь или бесплатными, или почти бесплатными дополнениями. Во-вторых, быстрое развитие рынка ОХЛР-клиентов со встроенной OZyiP-машиной позволяет эффективно реализовать ROLAP, что в конечном итоге ведет к полному отказу от OLAP- серверов.

6.8. Стратегия тестирования программного обеспечения

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

-определение источников тестовых данных;

-определение объема тестирования;

-контрольный лист тестирования программного модуля;

-проведение нисходящего тестирования;

-проведение восходящего тестирования;

-проведение комплексной отладки программы;

-локализацию и исправление ошибок.

Определение источников тестовых данных

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

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

Определение объема тестирования

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

Контрольный лист тестирования

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

-производится описание проверок всех логических конструк­ ций, представленных в спецификации;

-в конструкциях IF - THEN - ELSE проверяются как истинные, так и ложные условия;

-в конструкция DO WHILE проверяются как условия повто­ рения цикла, так и условия прекращения цикла;

-в конструкциях CASE проверятся каждое условие вы­

полнения.

Обычно контрольный лист имеет вид, представленный на рис. 6.12.

Рис. 6.12. Контрольный лист тестирования модуля

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

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

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

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

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

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

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

Проведение комплексной отладки программы

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

Принцип тестирования выбирают исходя из трудозатрат на проверку программы и расхода машинного времени.

Локализация и исправление ошибок

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