Файл: Отладка и тестирование программ: основные подходы и ограничения.pdf

Разработка драйверов и заглушек при восходящем интеграционном тестировании представлена в Приложении.

Однако, у восходящего метода тестирования есть существенный недостаток - необходимость в разработке драйвера и заглушек для модульного тестирования перед проведением интеграционного тестирования и необходимость в разработке драйвера и заглушек при интеграционном тестировании части модулей системы [18].

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

1.3. Организация процесса тестирования

Тестирование программной системы одновременно проводится по нескольким направлениям:

1. Проверка кода (review): в процессе которой тестер просматривает визуально исходный код программной системы и ищет в нём имеющиеся ошибки, а так же выполняет поиск различных несоответствий программного кода и требований, предъявляемых к нему. Под требованиями к программному коду понимается определенный стандарт, которого должны придерживаться разработчики программной системы, реакция на те или иные действия со стороны среды воздействия на программную систему, поведение программной системы в различных ситуациях [16].

2. Тестирование высокого уровня: в процессе которого главной целью тестирования является определение удовлетворяет ли программная системы всем заявленным требованиям определенного заказчика. Для программной системы разрабатываются специальные эмуляторы, при помощи которых тестер наблюдает за работой программной системы в роли определенного оператора. Он может увидеть, как программная система выполняет свой диалог с пользователями, какие сообщения программная система выдаёт, как она реагирует на различные события, каким образом сохраняет полученную информацию и т.д. Большинство найденных ошибок на данном этапе связанно с ошибками по взаимодействию программной системы с пользователями - вывод ошибочных сообщений, не правильная реакция на запрос от оператора и т.п. [20].

3. Тестирование низкого уровня: тестировщик выполняет проверку, на сколько логически полным является исходный код, и насколько он покрывает всё возможные варианты непосредственной работы программной системы, для которой он был разработан.

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

Стандарт ISO 9001.

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

Стандарт ISO/IEC 12207 и IEEE/EIA 12207.

ISO/IEC 12207 - это международный стандарт, описывающий структуру процессов жизненного цикла ПО от концепции до изъятия из обращения. Стандарт IEEE/EIA 12207 - адаптация ISO/IEC 12207 для США.

В соответствии с этими стандартами в той или иной отрасли производства выдвигаются требования к тестированию ПО. Например в авиации США на основе ISO/IEC 12207 был выработан стандарт RTCA( Requirements and Technical Concepts for Aviation). В нём перечислены следующие требования к тестированию верхнего и нижнего уровня. Тестирование верхнего уровня:

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

– предъявляемые требования высокого уровня должны формулироваться с учётом архитектуры определенной программной системы;

– программный код должен удовлетворять определенной архитектуре программной системы и требованиям низкого уровня ее исполнения в определенной операционной системе;

– откомпилированный и готовый к использованию программный код должен удовлетворять требованиям, которые предъявляются к определенной программной системе;

– используемые значения должны технически соответствовать поставленным целям и выполнять их для всех уровней разрабатываемой программной системы [11].

Тестирование нижнего уровня предполагает:

– выполнение проверки (Verification) требований нижнего уровня к программной системе;

– выполнение полной проверки архитектуры некоторой программной системы;

– выполнение полной проверки логического покрытия для всех имеющихся функций, которые были реализованы в определенной программной системе;

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

– проверка независимости программной системы от тестирования. Т.е. программная система не должно перестраиваться особым образом под выполняемые тесты;

– выполнение тестирования должно несколько раз покрывать исходный код программной системы, для обнаружения определённого класса возможных ошибок;

– тестирование на предмет косвенного обнаружения ошибок [14]. Например: соответствие стандартам разработки определенной программной системы.

2. Финишные этапы разработки программных систем

Согласно ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» можно выделить такие стадии создания и этапы непосредственной разработки программной системы:

– формирование комплекса требований к программной системе;

– разработка концепции программной системы;

– техническое задание;

– эскизный проект программной системы;

– технический проект программной системы;

– рабочая документация программной системы;

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

– сопровождение программной системы [5].

Рассмотрим более подробно финишные этапы разработки программных систем.

2.1. Рабочая документация

Разработка рабочей документации на программную систему и на её программные части регламентируется следующими документами:

– ведомость эксплуатационных документов программной системы;

– ведомость машинных носителей оперативной информации;

– паспорт программной системы;

– общее описание программной системы;

– технологическая инструкция на программную систему;

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

– описание технологического процесса обработки оперативных данных;

– инструкция по непосредственному формированию и ведению базы данных программной системы (набора данных программной системы);

– состав выходных данных (выдаваемых программной системой сообщений);

– каталог базы данных программной системы;

– программа и методика практических испытаний;

– спецификация на программную систему;

– описание программной системы;

– текст программной системы.

Разработка или адаптация программной системы:

– развернуты экземпляры программной системы. Созданы необходимые объекты базы данных;

– разработаны процессы ETL и процессы обеспечения качества данных. Выставлено расписание запуска процессов;

– реализованы дополнительные приложения;

– реализованы витрины данных и отчетность;

– настроены профили пользователей и прав доступа.

Согласованная и утвержденная рабочая документация.

2.2. Ввод в действие

Детализируем основные этапы работ и результат их выполнения на стадии ввода в действие программной системы.

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

На этапе подготовки персонала будет организовано обучение администраторов и пользователей системы.

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

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

Рисунок 1 – Схема используемого оборудования

В этом случае предлагается стандартная схема резервирования каналов связи:

– резервирование через терминалы различных операторов мобильной связи;

– резервирование основного GPRS-соединения резервным - через GSM;

– резервирование по коммутируемой телефонной линии (для неподвижных объектов).

В процессе пусконаладочных работ будет выполнена наладка программных и технических средств. Разрабатываемое программное средство будет перенесено в зону промышленной эксплуатации. Выполнены мероприятия по настройке системы резервного копирования. Выполнены мероприятия по загрузке исходных данных в систему и запущен процесс по извлечению данных из дополнительных систем, рис. 2 – рис. 3.

Рисунок 2 – Технология выполнения пусконаладочных работ

Рисунок 3 – Технология выполнения пусконаладочных работ

На стадии проведения предварительных испытаний будет выполнен тест системы на ее полное соответствие заданию и работоспособность в соответствии с техническим заданием. Будут выполнены мероприятия по устранению неисправностей и внесению необходимых изменений в документацию с учетом проведенных испытаний. Результатом данной стадии будет заполнен акт приемки системы в опытную эксплуатацию. Например, настройка системы документооборота 1С: Предприятие может быть настроено при помощи специальной панели, рис. 4.

Рисунок 4 – Настройка системы

В процессе проведения опытной эксплуатации будет выполнено устранение выявленных неисправностей, будут проведены работы по доработке программных средств и мероприятия по дополнительной наладке технических и программных средств.

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

Рисунок 5 – Интерфейс конфигуратора системы

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

2.3. Сопровождение

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

Рисунок 6 – Схема взаимодействия с клиентом

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

Для обеспечения данной стадии может быть использован программный продукт «AS Система Опроса Абонентов v4» представляющая собой программную систему, предназначенную для выполнения опросов абонентов (клиентов) / наличие системы обратной связи и предназначена в основном для:

– выполнения автоматизированного сбора оценок и выполнения проведения различных опросов о качестве обслуживания и предоставляемых услуг компании, при обращении в контакт-центры, салоны фирменной розницы и салоны партнёров по всему миру;

– ведение централизованного хранения оценок качества и отзывов клиентов компании;

– формирования необходимых статистических отчётов о деятельности компании,

– выполнение контроля проведенных опросов и оперативного сравнительного анализа полученных отзывов [19].

Программная система «AS Система Опроса Абонентов v4»:

– включает полностью автоматизированные процедуры опросов клиентов посредством технологий SMS/IVR/WEB-опросов (с возможностью выбора на основе предпочтений клиента) и возможности формирования различных отчётов о пользовательских оценках работы операторов компании;