Файл: отладка и тестирование программного обеспечения.pdf

ISO 15939: 2002 - Процесс измерения программных средств.

IEC 61508:1-6: 1998-2000. Функциональная безопасность электрических / электронных и программируемых электронных систем. 4асть 3. Требования к программному обеспечению. 4асть 6. Руководство по применению стандартов IEC 61508-2 и IEC 61508-3.

ISO 15408 -1-3. 1999. (ГОСТ Р - 2002). Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. 4.1. Введение и общая модель.

РД 50-34.698-90. Методические указания. Информационная технология. Автоматизированные системы. Требования к содержанию документов.

ГОСТ Р 51901-2002. Управление надежностью. Анализ риска технологических систем.

DO-178 В-1995. Соглашение по сертификации бортовых систем и оборудования в части программного обеспечения.

ISO 14102:1995. Оценка и выбор CASE- средств.

ISO 14471:1995. Руководство по адаптации CASE- средств.

ISO 14143: 1-5: 1998 - 2004. ИТ. Измерение программных средств. Измерение функционального размера. 4.1. 1998.

Определение концепции. 4.2. 2002. Оценивание соответствия методов измерения размера программных средств стандарту ISO 14143:1:1998. 4.3. 2003. Верификация методов измерения функционального размера. 4.4. 2002. Эталонная модель. 4.5. 2004. Определение функциональных доменов для использования при измерении функционального размера.

ISO 20926:2003. Руководство по практическому методу измерения функционального размера программных средств.

ISO 20968:2002. Руководство по расчетам на основе анализа функциональных точек - Марк II.

Глава 2. Анализ методов откладки и тестирования программного обеспечения

2.1 Анализ методов тестирования программного обеспечения

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

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

Существуют два основных метода тестирования: метод «черного ящика» и метод «белого ящика» [1].

Стратегия по принципу «белого ящика» (white-box testing) предусматривает наличие у тестировщика доступа к структуре и исходному коду тестируемой программы. Это позволяет выбирать входные данные, опираясь на знание структуры программы, которая будет их обрабатывать, что дает возможность проводить более эффективное тестирование, на ранних стадиях разработки, с покрытием большого количества вариантов выполнения программы. Тестировщик, использующий тест White Box, взглянув на код, может определить, какой блок кода работает неправильно.

Стратегия по принципу «черного ящика» (black-box testing) позволяет тестировать ПО только через внешние интерфейсы программы, доступные обычному пользователю или заказчику [2]. Тестировщик не знает о внутренней структуре программе. Для тестирования черным ящиком нужно лишь знание требований и функциональной спецификации программы. Тест Black Box позволяет находить неправильно реализованные или недостающие функции и ошибки в интерфейсе.

В таблице 1 проведено сравнение вышеописанных методов тестирования программного обеспечения.

Таблица 1

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

Рассмотренные методы включают в себя уровни тестирования, определяющие, над чем будет выполняться тест: над отдельным модулем, группой модулей или системой в целом [3].

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

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

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

Приемочное тестирование (Acceptance Testing) - происходит после успешного завершения всех предыдущих уровней. Цель данного этапа тестирования: определение соответствия продукта всем установленным заказчиком требованиям. Приемочное тестирование разделяется на два вида: внутреннее (альфа-тестирование), которое производится командой разработчиков, и внешнее (бета-тестирование), осуществляемое на стороне конечного пользователя или заказчика [4].

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

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

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

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

•ошибки, связанные с нарушением допустимых ограничений на работу ЭВМ;

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

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

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

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

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

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

•аварийная печать:

•печать в узлах;

•слежение;

•прокрутка:

•контроль индексов элементов массивов.

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

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

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

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

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

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

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

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

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

•прослеживание по схеме алгоритма:

•обратное отслеживание идентификаторов:

•ручная прокрутка программы.

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

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

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