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

Существует несколько оснований, по которым принято производить классификацию видов тестирования.

1. По объекту тестирования

• Функциональное тестирование
• Нагрузочное тестирование
• Тестирование удобства использования
• Тестирование интерфейса пользователя
• Тестирование безопасности
• Тестирование локализации
• Тестирование совместимости

1. По знаниям о тестируемой системе

• Тестирование методом «черного ящика»
• Тестирование методом «белого ящика»
• Тестирование методом «серого ящика»

1. По уровню автоматизации

• Ручное тестирование
• Автоматизированное тестирование

1. По степени изолированности

• Модульное тестирование
• Интеграционное тестирование
• Системное тестирование

1. По уровню готовности

• Альфа-тестирование
• Бета-тестирование
• Приемосдаточные испытания

1.4 Функциональное тестирование и тестирование качества

Функциональное тестирование проводится для проверки выполнения системой функциональных требований.

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

Одним из главных показателем производительности информационной системы, в ходе тестирования, являются:

• Время отклика
• Число операций, выполняемых в единицу времени

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

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

Тестирование удобства использования имеет целью оценить оптимальность пользовательского интерфейса приложения.

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

• Тестирование на соответствие стандартам графических интерфейсов;
• Тестирование с различными разрешениями экрана;
• Тестирование локализованных версий: проверка длины названий элементов интерфейса и т.п.;
• Тестирование графического интерфейса пользователя на различных целевых устройствах.

В ходе тестирования безопасности производится проверка на уязвимость к атакам. Тестирование безопасности проверяет систему на попытки взлома и обхода. Во время тестирования безопасности проверяются следующие аспекты безопасности системы:

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

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

В процессе тестирования локализации проверяются различные аспекты, связанные с региональными особенностями (Языковые данные, системное время, дата и т.д.).

Тестирование совместимости - проверка совместимости системы с различными вариантами программно-аппаратного окружения.

1.5 Виды тестирования

Отмечают три уровня тестирования: модульное, интеграционное и системное.

Модульное тестирование - тестирование, имеющее целью проверить работоспособность отдельных модулей. Модульное тестирование распространено для систем малого и среднего размера. Тестирование выполняется независимо для каждого программного модуля. Стандарт IEEE 1008-1987 определяет содержание фаз процесса модульного тестирования.

Модульные тесты проверяют, что определенные воздействия на модуль приводят к желаемому результату. Модульные тесты делаются с использованием метода «белого ящика». При наличии зависимостей тестируемого модуля от других модулей вместо них используются так называемые mock-объекты, предоставляющие фиктивную реализацию их интерфейсов. С использованием mock-объектов могут быть протестированы такие аспекты функционирования, которые невозможно проверить с использованием реальных зависимых модулей.

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

В большей части известных ЯП высокого уровня существуют инструменты и библиотеки модульного тестирования (например, NUnit, JUnit, CppUnit).

Интеграционное тестирование - одна из стадий тестирования программного обеспечения, при котором некоторые программные модули объединяются и тестируются в комплексе. Чаще всего, интеграционное тестирование используют после модульного и перед системным тестированием. Целью данного вида тестирования является нахождение проблем взаимодействия модулей. Тестирование выполняется через интерфейс модулей с использованием метода «черного ящика».

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

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

1.6 Этапы тестирования программного обеспечения 

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

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

Существуют разные подходы к построению стратегии тестирования:

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

Определение масштаб тестовых работ

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

Вот несколько вариантов по стратегии тестирования, которые помогут найти оптимальную золотую середину:

Тестировать в первую очередь запросы с наивысшим приоритетом.

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

Использовать разбиение на эквивалентные классы и анализ граничных значений для понижения затрат на тестирование

Тестировать те участки, в которых вероятнее всего присутствие проблем

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

Определение подхода к тестированию

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

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

Стадия формулирования требований

Системные испытания

Стадии тестирования проектов программ, программных кодов, модульного тестирования и комплексных испытаний

Регрессионное тестирование

Приемочные испытания

Определение критериев тестирования и точек контроля качества

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

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

Критерий выхода. Описывает то, что вы считается необходимым для завершения испытаний.

Критерий входа. Описывает, что нужно сделать перед началом тестирования.

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

Критерий приостановки/возобновления. Описывает, что произойдет, если из-за дефектов продолжение тестирования окажется невозможным.

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

Установление стратегии автоматизации.

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