Файл: ОТЛАДКА И ТЕСТИРОВАНИЕ ПРОГРАММ: ОСНОВНЫЕ ПОДХОДЫ И ОГРАНИЧЕНИЯ ( Теоретические аспекты отладки и тестирования программ).pdf

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 Разработка и отладка АСУ ТП

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

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

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

Наиболее подходящим инструментом для решения этой проблемы является имитационное моделирование. Для автоматизации процесса отладки и тестирования программ управления АСУ ТП имитационная модель должна быть интегрирована с тестируемой системой. Интеграция заключается в генерации в модели входных сигналов в формате тестируемой системы, посылке сигналов в тестируемую систему вместо реальных входных сигналов от технологического оборудования и получения обратной связи от тестируемой системы. Такой подход был успешно опробован при разработке АСУ ТП Северо-Муйского тоннеля^[6] и Системы мониторинга технологической инфраструктуры нефтегазодобывающего предприятия^[7].

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

2.2 Тестирование программного комплекса