Отчет о научно-исследовательской и опытно-конструкторской работе (стр. 16 )

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

Для проверки работоспособности и правильности функционирования официального сайта применялись две общеизвестные на практике стратегии тестирования:

стратегия тестирования, называемая стратегией «черного ящика».. При использовании этой стратегии сама программа рассматривалась как «черный ящик». Тестовые данные используются в соответствии с требованиями к функционированию программы, без учета ее внутренней структуры; стратегия белого ящика, когда методика тестирования учитывает и определяется логикой программы, что позволяет исследовать качество реализации внутренней структуры кода.

Разработанные тесты представляют собой набор операций, предназначенных для получения одного или большего числа ожидаемых результатов. Если были получены все ожидаемые результаты, считается, что тест прошел (т. е. выполнен успешно). Если фактический результат отличался от ожидаемого, считается, что тест не прошел (т. е. завершился неудачно, функционал отправлялся на исправление ошибок).

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

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

Процесс каждой итерации тестирования состоял из трёх этапов:

проектирование тестов (перечень тестируемых на данной итерации функций программы и описание выполняемых шагов и ожидаемых результатов); исполнение тестов; анализ полученных результатов.

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

Совокупность всех тестов, подготовленных в ходе процессов разработки и тестирования информационной системы, составила основу документов «Программа и методика испытаний предварительных испытаний», «Программа опытной эксплуатации», «Программа и методика приемочных испытаний».

Каждый тест включает в себя следующие компоненты:

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

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

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

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

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

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

Все выявленные ошибки и ход их исправления, а также процессы компоновки версий и релизов фиксировались в BugTracker исполнителя Jira и Confluence.

Проектирование и реализация ИАС

При проектировании ИАС использовался иной подход, чем при проектировании и реализации официального сайта, в силу различий их архитектурной и программной реализации. ИАС построена на базе единой и функционально полной платформы программных продуктов Oracle.

В основе архитектуры ИАС лежат три ее технологических слоя:

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

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

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

В качестве среды хранения информации в хранилище данных ИАС используется сервер Oracle Database.

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

Для обработки этих данных применяются средства анализа Oracle Business Intelligence Standard Edition. Он представляет собой набор встроенных элементов для управления функциями предоставления хранимых данных в удобной для пользователя форме отчетов.

Центральным компонентом этого программного комплекса является репозиторий – база данных специального назначения, в которой хранится метаинформация о структуре и объектах хранилища данных. Встроенные средства и инструменты, входящие в состав этой среды, обеспечивают доступ к репозитарию и ориентированы на выполнение различных задач, возникающих в процессе проектирования модернизации ИАС.

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

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

В репозитории для каждой таблицы  содержится различная метаинформация: различные тонкости хранения таблицы, характеристики столбцов.  Перечень этих характеристик является избыточным, как правило, в  соответствующую программу создания базы данных включается не весь возможный набор. Следующим этапом работ является детальное проектирование отчетных форм, как для вновь создаваемых, так и для существующих отчетов, которые должны подвергнуться модернизации. Для этой цели используются встроенные механизмы Oracle Business Intelligence, включающие широкий спектр различных инструментальных средств для отчетности, нерегламентированных запросов, многомерного анализа, построения и использования интерактивных информационных панелей, поддержки режима off-line и др. Эти средства уже были опробованы в рамках работ прошлого года по созданию и модернизации ИАС и хорошо себя зарекомендовали.