Файл: Вид работы Курсовая работа Название дисциплины Информационное обеспечение, программировани Тема Тестирование и отладка программного средства Фамилия студента Имя студента.doc

Основные данные о работе

Версия шаблона	3.1
Вид работы	Курсовая работа
Название дисциплины	Информационное обеспечение, программировани
Тема	Тестирование и отладка программного средства
Фамилия студента
Имя студента
Отчество студента
№ контракта

Содержание

Введение

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

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

---

Целью данной работы является проведение исследования тестирования и отладка программного средства. Для достижения поставленной цели необходимо решить ряд задач:

1) рассмотреть стратегию проектирования тестов,

2) проанализировать заповеди отладки,

3) рассмотреть автономную отладку и тестирование программного модуля,

4) исследовать особенности комплексной отладки и тестирование программного средства.

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

Основная часть

1 Стратегия проектирования тестов

Стратегия тестирования (test strategy): высокоуровневое описание уровней тестирования, которые должны быть выполнены, и тестирования, входящего в эти уровни, для организации или программы из одного или более проектов. (ISTQB)

Стратегия тестирования - это статический документ высокого уровня, обычно разрабатываемый менеджером проекта. Это документ, который отражает подход к тестированию продукта и достижению целей, и дает четкое представление о том, что команда тестирования будет делать для всего проекта. Обычно он выводится из Спецификации бизнес-требований (BRS). Как только стратегия тестирования готова, группа тестирования начинает писать подробный план тестирования и продолжает дальнейшие этапы тестирования. В мире Agile некоторые компании не тратят время на подготовку плана тестирования из-за минимального времени для каждого выпуска, но они поддерживают документ стратегии тестирования. Это один из важных документов в test deliverables, которым команда тестирования делится с заинтересованными сторонами для лучшего понимания объема проекта, рисков, подходов к тестированию и других важных аспектов.

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

- Обзор и объем (Scope and overview): объем работ по тестированию (что тестировать и зачем тестировать) и обзор тестируемого продукта;

- Подход к тестированию (Test Approach);

- Уровни тестирования (Test levels);

- Виды тестирования (Test Types);

- Роли и обязанности (Roles and responsibilities);

- Требования к окружениям (Environment requirements);

- Инструменты тестирования (Testing tools): инструменты, необходимые для проведения тестов (TMS, багтрекинговая система, стек автоматизации);

Отраслевые стандарты, которым необходимо следовать (Industry standards to follow) В этом разделе описывается:

---

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

- Результаты тестирования (Test deliverables): документация, которую необходимо создать до, во время и по окончании тестирования;

- Метрики тестирования (Testing metrics): метрики, которые следует использовать в проекте для анализа статуса проекта;

- Матрица отслеживания требований (RTM);

- Риски и способы их снижения (Risk and mitigation): все риски тестирования и план по их снижению;

- Инструмент отчетности (Reporting tool): как будут отслеживаться дефекты и проблемы;

- Результаты тестов (Test Summary): виды сводных отчетов о тестах, которые будут создаваться, с указанием периодичности. Сводные отчеты о тестах будут генерироваться ежедневно, еженедельно или ежемесячно, в зависимости от критичности проекта.

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

При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду программ (см. открытое программное обеспечение) и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.

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

---

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

2 Заповеди отладки

Отладка, или debugging, — это поиск (локализация), анализ и устранение ошибок в программном обеспечении, которые были найдены во время тестирования.

Рассмотрим основные виды ошибок

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

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

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

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

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

- сообщение об ошибке, которую зафиксировала операционная система. Она же, как правило, и документирует ошибку. Это нарушение защиты памяти, отсутствие файла с заданным именем, попытка записи на устройство, защищенное от записи;

- прекращение работы компьютера или зависание. Это и простые ошибки, которые не требуют перезагрузки компьютера, и более сложные, когда нужно выключать ПК;

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

Ошибки выполнения можно разделить на три большие группы.

---

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

К ним относятся:

- ошибки преобразования;

- ошибки данных;

- ошибки перезаписи.

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

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

В эту группу входят:

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

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

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

- неправильная реализация логики при программировании.

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

Рассмотрим основные методы отладки программного обеспечения.

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

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

---