Тестирование информационных систем Ep.PP и Ep.DB

РОСТОВСКИЙ  ГОСУДАРСТВЕННЫЙ ЭКОНОМИЧЕСКИЙ  УНИВЕРСИТЕТ «РИНХ» 

Кафедра Экономической информатики

и автоматизации  управления 

КУРСОВОЙ  ПРОЕКТ 

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

на тему:  Тестирование информационных систем Ep.PP  и Ep.DB 

автор проекта _______________________________________ В. И. Быстрова

                                                                                                       А.М.  Воробьева

                                                                                                        М.А. Прохоров

специальность   351400   Прикладная информатика  в экономике

группа 351

Руководитель  проекта __________________________________ Г. Н. Хубаев 

Проект защищен __________________ Оценка _____________

                        дата     

Члены комиссии __________________       _____________

                          подпись, дата    Ф.И.О.

                     __________________  _____________             подпись, дата    Ф.И.О.

                     __________________  _____________

                         подпись, дата    Ф.И.О. 

Ростов-на-Дону

2008

РЕФЕРАТ 

        24 страниц,  4 рисунков,  3 библиографических записи,  5 таблицы. 

      ТЕСТИРОВАНИЕ, АНАЛИЗ, ИНФОРМАЦИОННАЯ СИСТЕМА, СЦЕНАРИЙ, ПРОГРАММНЫЙ ПРОДУКТ, БАЗА ДАННЫХ.  

      Цель  курсового проекта – тестирование информационных систем и обнаружение еще не выявленных ошибок для дальнейшего повышения функциональных характеристик систем.

      Используемые  методы решения – осуществление  тестирования функциональным методом или методом «черного ящика» (тестирование по «входу - выходу»)

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

      Содержание

                                                                                                                        c.

  Введение 4
1 Описание систем 5
1.1 Описание системы Ep[1].DB 5
1.2 Описание системы Ep[1].РР 6
2 Тестирование  программных продуктов 8
2.1 Принципы и  методы тестирования программных продуктов 8
2.2 Тестирование  систем  Ep[1].DB и Ep[1].PP 12
3 Сравнительный анализ работы информационных систем 15
4 Продвижение программных  продуктов 18
  Заключение 20
  Библиографические записи 21
  Приложения 22
 
        Приложение  А Главная форма  автоматизированной системы  «Ep[1].DB»
23
 
        Приложение  Б Главная форма  автоматизированной системы  «Ep[1].PP»
24
     
     
     
     
     
     
     
 
 
 
 

      Введение 

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

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

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

     Кроме того, в курсовой работе рассматриваются две системы оценки качества работы программных продуктов на основе СУБД, основные принципы и методы тестирования программного обеспечения. Также в работе приведен экспертный анализ функциональных характеристик систем Ep[1].DB и Ep[1].PP и выбранные средства продвижения программных средств. 
 
 
 
 
 
 

      1 Описание систем 

      1.1 Описание системы Ep[1].DB 

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

      Такая оценка позволяет проанализировать исследуемую систему с технической точки зрения и получить ряд значений времени отклика системы при увеличении объема данных. Система использует эвристические алгоритмы анализа структуры и наполнения исследуемой СУБД; допустимые величины для каждой из колонок таблицы выбираются исходя из анализа имеющихся данных; данные агрегируются с помощью методов математической статистики.

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

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

      Программная реализация выполнена в среде  Java 5 Standard Edition.

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

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

       Приложение является платформено-независимым и не использует низкоуровневые функции ОС.

       Главная форма  автоматизированной системы  «Ep.DB» представлена в приложении А. 
 

      1.2 Описание системы Ep[1].PP 
 
 

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

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

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

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

       Программная реализация выполнена в среде  Java 5 Standard Edition.

       Приложение  является платформено-независимым  и не  использует низкоуровневые функции ОС.

       Главная форма  автоматизированной системы  «Ep.РР» представлена в приложении Б. 
 
 
 
 
 
 

      2 Тестирование программных продуктов 

      2.1 Принципы и методы тестирования  программных продуктов 

    Тестирование  является одним из этапов жизненного цикла ПС, направленным на повышение качественных характеристик.

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

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

    Особенностями тестирования программных средств являются:

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

    Применительно к программному средству тестирование - процесс многократного выполнения программ с целью обнаружения ошибок.

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

    Существуют  следующие методы тестирования программ:

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

      Программное средство, предназначенное для работы в системах реального времени, должно проходить тестирование в реальном масштабе времени.

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

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

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

    Детерминированное тестирование или тестирование на определенных входных данных, основывается на двух подходах: структурное тестирование и функциональное тестирование.

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

    При построении наборов данных по принципу «белого ящика» руководствуются следующими критериями:

  1. покрытие операторов; предполагает выбор такого тестового набора данных, который вызывает выполнение каждого оператора в программе хотя бы один раз. Слабый критерий;
  2. покрытие узлов ветвления; предполагает разработку такого количества тестов, чтобы в каждом узле ветвления был обеспечен переход по веткам «истина» и «ложь» хотя бы один раз;
  3. покрытие условий; если узел ветвления содержит более одного условия, тогда нужно разработать число тестов, достаточное для того, чтобы возможные результаты каждого условия выполнялись, по крайней мере, один раз, каждой точке входа в программу должно быть передано управление при вызове, по крайней мере, один раз;
  4. комбинаторное покрытие условий; используется для выполнения ошибок в логических выражениях. Требует создания такого числа тестов, чтобы все возможные комбинации результатов условия в каждом решении и все точки входа выполнялись, по крайней мере, один раз.

     Функциональное  тестирование, или тестирование программ, как «черного ящика» (тестирование по «входу - выходу»), полностью абстрагируется от логики программы, предполагается, что логика программы неизвестна, а тестовые наборы подбираются на основании анализа функциональных входных спецификаций. Тестирование по методу "черного ящика" может обнаружить наличие ошибок в программе. Оно не доказывает, что таких ошибок в программе нет. Однако проведение такого тестирования значительно повышает уверенность в том, что приложение надежно и безопасно по отношению к непредвиденным входным данным. Если тестирование программы по этому методу проводилось в течение 24 часов, и она по-прежнему работает, то вряд ли дальнейшие атаки подобного рода вызовут ошибку. Если в результате тестирования были обнаружены ошибки, то их необходимо исправить. Вместо того, чтобы исправлять случайно обнаруженные ошибки по мере их появления, более продуктивным может быть фундаментальное исправление формата файла на предмет разумного использования контрольных сумм, XML, очистки памяти и/или форматов файлов на базе грамматики.

     Тестирование  по методу "черного ящика" является важным средством нахождения в программах реальных ошибок.

    К стратегии «черного ящика» относятся  методы:

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

     При этом технология тестирования программного средства может быть представлена следующим  набором действий:

    1. В спецификации программы выделяются причины и следствия. Причина - отдельное входное условие или класс эквивалентности входных условий. Следствие - выходное условие или результат преобразования системы. Каждой причине и следствию приписывается уникальный номер.
    2. Анализируется семантическое содержание спецификации, которая преобразуется в булевский граф, связывающий причины и следствия. Каждая вершина может находиться в состоянии «истина» или «ложь».
    3. Диаграмма снабжается примечаниями, задающими ограничения и описывающими комбинации причин и (или) следствий, которые являются невозможными из-за синтаксических или внешних ограничений.
    4. По полученной функциональной диаграмме строится таблица решений. Для этого поочередно для каждого следствия, значение которое условно устанавливается в «истину», прослеживается обратный путь (по диаграмме) ко всем причинам, связанным с этим следствием, и фиксируется их состояние. Каждый столбец таблицы решений соответствует тесту.
    5. Столбцы решений преобразуют в тесты.
 

      2.2 Тестирование систем Ep[1].DB и Ep[1].PP 

      При тестировании систем Ep[1].DB и Ep[1].PP был обнаружен ряд ошибок. Все ошибки можно разделить по важности на:

  1. критическую;
  2. высокую;
  3. среднюю;
  4. незначительную;
  5. ошибки подлежащие доработке.

      Ошибки, обнаруженные в ходе тестирования системы Ep[1].DB представлены в таблице 1. 

Таблица 1 – Ошибки, обнаруженные в ходе тестирования системы  Ep[1].DB

№№ Ошибка Важность
1 Некорректно заполнение русских строк в СУБД mySQL Высокая
2 Некорректное  заполнение текущей даты в поля типа  Date для СУБД Oracle 9i Критическая
3 Опечатка в  слове «заполнение» в форме выбора факторов эксперимента Незначительная
4 При количестве факторов > 6 количество экспериментов  очень велико. Целесообразно использовать дробный факторный эксперимент Доработка
5 Опечатка в  слове «реляционная» на форме  ввода параметров подключения к  СУБД Незначительная
6 При разрешении экрана 800х600 форма не помещается на экран Доработка
7 Ошибка заполнения колонок типа Clob на всех СУБД Средняя
8 Ошибка заполнения справочников с циклическими связями Средняя
9 Некорректное  заполнение таблиц со связями многие-ко-многим. В таблицу связки вставляется  некорректное число элементов (2N, вместо 2N ) Незначительная
10 При одновременном  запуске двух экземпляров программы на одной машине иногда появляется ошибка ConcurrentModificationException, при условии использования одного и того же профиля Незначительная

      Ошибки, обнаруженные в ходе тестирования системы Ep[1].PP представлены в таблице 2. 
 

Таблица 2 – Ошибки, обнаруженные в ходе тестирования системы Ep[1].PP

№№ Ошибка Важность
1 Опечатка в  слове «действие» на экране редактирования действия «ввод с клавиатуры» Незначительная
2 Опечатка в  слове «эксперимента» на экране редактирования плана эксперимента Незначительная
3 Ошибка сохранения скрипта при количестве действий > 5000. При большом количестве действий в одном скрипте проект не сохраняется  с ошибкой Numeric Overflow Высокая
4 Ошибка воспроизведения  скриптов для приложений в полноэкранном  режиме. Средняя
5 При вводе случайных  значений в поля, допускающие только цифры, могут быть сгенерированы  цифро-буквенные комбинации. Доработка
6 При незначительных изменениях в положении окна тестируемой  программы выполнение скрипта может  сбиваться. Необходимо ввести процедуру контроля правильности выполнения действий скриптом. Доработка
7 При загрузке проекта  с количеством скриптов более 10 вылетает ошибка Runtime Exception Критическая
 

      3 Сравнительный анализ работы информационных систем 

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

      Системы Ep[1].DB и Ep[1].PP являются схожими по своим функциональным характеристикам. Различие состоит в том, что первая система оценивает программные продукты по времени выполнения полного перечня функциональных операций в зависимости от объемов баз данных, количества одновременно работающих пользователей и других показателей, характеризующих условия функционирования ПП.