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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 14.03.2024

Просмотров: 19

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Agile Model - эта методика основана на избирательном сочетании последовательного и итеративного подхода, в дополнение к довольно большому разнообразию новых методов развития. Быстрое и поступательное развитие является одним из ключевых принципов этой методологии. Акцент делается на получение быстрых, практичных, и видимых выходов. Непрерывное взаимодействие с клиентами и участие является неотъемлемой частью всего процесса разработки.

Rapid Application Development (RAD). Методология быстрой разработки приложений Название говорит само за себя. В этом случае методология принимает стремительный эволюционный подход, используя принцип компонентной конструкции. После понимания различных требований данного проекта, готовится быстрый прототип, а затем сравнивается с ожидаемым набором выходных условий и стандартов. Необходимые изменения и модификации вносятся после совместного обсуждения с заказчиком или группой разработчиков (в контексте тестирования программного обеспечения). Хотя этот подход имеет свою долю преимуществ, он может быть неподходящим, если проект большой, сложный, или имеет чрезвычайно динамический характер, в котором требования постоянно меняются.

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

Rational Unified Process (RUP). Рациональный унифицированный процесс Методика RUP также похожа на спиральную модель, в том смысле, что вся процедура тестирования разбивается на несколько циклов. Каждый цикл состоит из четырех этапов - создание, разработка, строительство, и переход. В конце каждого цикла продукт/выход пересматривается, и далее цикл (состоящий из тех же четырех фаз) следует при необходимости. Применение информационных технологий растет с каждым днем, также и важность правильного тестирования программного обеспечения выросло в разы. Многие фирмы содержат для этого штат специальных команд, возможности которых находятся на уровне разработчиков.

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


Перейдем к видам тестирования, в которых применяется автоматизация.

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

Рассмотрим положительные и затем отрицательные стороны автоматизации тестирования.

    1. При автоматизации тестирования исключается так называемый "человеческий фактор", так как людям время от времени свойственно допускать ошибки и неточности, а скрипт выполнит все необходимые проверки и безошибочно зарегистрирует результаты.
    2. Быстрота выполнения, скрипту для работы не нужно заглядывать в документацию или сверять значения со справочниками.
    3. Отсутствие необходимости постоянно следить за процессом проверки. Специалист по тестированию может запустить скрипт и на время его выполнения заняться другими делами.
    4. Меньшие затраты ресурсов на поддержку актуальности тестовых скриптов. Стоит один раз написать скрипт и после этого на его обновления необходимо затрачивать меньше сил, нежели на тестирование вручную.
    5. Автоматическая отчетность. Автоматическое сохранение результатов и внесение их в отчет.

К недостаткам автоматизации тестирования можно отнести следующее.

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

      • Затраты на разработку. Так как разработка автоматизированных тестов - это сложный и ресурсоемкий процесс.
      • Стоимость инструментов для автоматизации. Стоимость ПО достаточно высока.
      • Автоматический скрипт будет пропускать ошибки, на которые он не запрограммирован.

Выбор инструмента для автоматизации тестирования зависит от требований к объекту тестирования, требований к тестовым сценариям и бюджету. Для примера инструмента рассмотрим - IBM Rational Functional Tester. Это инструмент автоматического функционального и регрессионного тестирования. Это ПО предоставляет функции автоматического тестирования для функционального, регрессионного тестирования, тестирования графических пользовательских интерфейсов и тестирования, ориентированного на данные. Rational Function Tester поддерживает ряд приложений, таких как веб-приложения, приложения для .Net, Java, Siebel, SAP, приложения на основе эмулятора терминала, PowerBuilder, Ajax, Adobe Flex, Dojo Toolkit, GEF, документы Adobe PDF, zSeries, iSeries и pSeries. Пример использования[5].

  • Сначала в среде создается новый проект.
  • Выполняется запись пользовательских действий в тестируемом предложении.
  • Создается проверочная точка в процессе выполнения записи.
  • Далее необходимо сохранить результаты записи.
  • Сформировываем bat - файл, который будет вызывать скрипт тестирования. Bat - файл вызывается IBM Rational Functional Tester с необходимыми параметрами.
  • IBM Rational Functional Tester записывает результаты в отчет в формате HTML.
  • Далее мы анализируем полученный результат.

1.3 Ограничения тестирования

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

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


Можно выделить следующие, наиболее распространенные и обоснованные цели (а, соответственно, виды) тестирования:

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

Установочное тестирование (Installation testing). Из названия следует, что данные тесты проводятся с целью проверки процедуры инсталляции системы в целевом окружении.

Альфа- и бета-тестирование (Alpha and beta testing). Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадии альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в соответствии с определенными процедурами, включающими подтверждающие тесты (любого уровня), проводимые специалистами группы разработки. Данный вид тестирования не может быть заранее спланирован.

Функциональные тесты/тесты соответствия (Conformance testing/Functional testing/Correctness testing). Эти тесты могут называться по разному, однако, их суть проста — проверка соответствия системы, предъявляемым к ней требованиям, описанным на уровне спецификации поведенческих характеристик.

Достижение и оценка надежности (Reliability achievement and evaluation). Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение надежности программных систем. Случайно генерируемые сценарии тестирования могут применяться для статистической оценки надежности. Обе цели — повышение и оценка надежности — могут достигаться при использовании моделей повышения надежности.

Регрессионное тестирование (Regression testing). Определение успешности регрессионных тестов (IEEE 610-90 «Standard Glossary of Software Engineering Terminology») гласит: «повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам». На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходить и после внесения таковых.

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


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

Сравнительное тестирование (Back-to-back testing). Единичный набор тестов, позволяющих сравнить две версии системы.

Восстановительные тесты (Recovery testing). Цель — проверка возможностей рестарта системы в случае непредусмотренной катастрофы, влияющей на функционирование операционной среды, в которой выполняется система.

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

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

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

ГЛАВА 2. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ОТЛАДКИ И ТЕСТИРОВАНИЯ ПРОГРАММ УПРАВЛЕНИЯ АСУ ТП

2.1 Разработка и отладка АСУ ТП

Для повышения безопасности и производительности работы шахт и рудников в Конструкторско-технологическом институте вычислительной техники СО РАН (КТИ ВТ СО РАН) разрабатываются Автоматизированные системы управления технологическими процессами (АСУ ТП) для подземных выработок шахт и рудников Кемеровской области, опасных по газу, пыли и внезапным выбросам.