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

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

Тестер должен убедиться, что ошибка произошла не из-за того, что он ввел некорректные значения, либо использовал неверное программное обеспечение для тестирования. Кроме того, тестер не должен устранять дефекты, он лишь составляет список несоответствий. Изменить работу приложения может только специалист или авторитетное лицо, хорошо знакомое с работой приложения [3].

Причины возникновения проблем могут быть различными. Среди них можно выделить следующие [18]:

Пропущенные требования.

Двусмысленные или непонятные требования.

Требования, которые не сообщили тестеру.

Неверное определение ожидаемых результатов.

Возникновение проблемы в ходе проведения теста.

Дефект в программном обеспечении.

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

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

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

Индивидуальная обработка каждого отдельного файла.

Обработка одного файла и генерация одного прерывания.

Обработка двух файлов.

Обработка двух файлов и генерация одного прерывания.

Обработка двух файлов и генерация двух прерываний.

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

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

Общее правило для тестирования границ заключается в создании трех тестовых примеров для охвата следующих значений [11]:

граничное значение;

граничное значение -1;

граничное значение +1

Седьмая стадия тестирования представляет собой ошибочные данные. На этой стадии тестирования делается попытка выведения приложения из строя путем создания критических условий работы пользователя. Рассмотрим создание тестов нескольких категорий [11]:

Данные не вводятся для того, чтобы отследить поведение приложения.

Данные вводятся в виде неправильных чисел.

Данные имеют формат, который считается недопустимым.

Данные используются в необычной комбинации.

Проверяется нулевое значение.

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

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

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

В некоторых случаях предыдущую стадию тестирования можно исключить и сосредоточиться на том, чтобы вывести систему из строя. У такого подхода есть свои преимущества. Самая лучшая тактика – это анализ риска для определения направления приложения усилий. Необходимо проанализировать риск и узнать, за счет чего система отказывается от работы. Когда тестированием продукта занимается сразу несколько человек, один из них может посвятить все свое время поиску серьезных ошибок [13].

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

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

Оценка рабочих характеристик включает в себя измерение времени на выполнение отдельных операций. Характерные времена изменяются если приложение запускается в загруженной или специализированной системе. Также главным аспектом влияния на рабочие характеристики системы является тестирование напряженности рабочей среды. Этот аспект включает в себя следующие тесты [10]:

Сокращение объема доступной памяти.

Использование доступного дискового пространства.

Параллельный запуск нескольких экземпляров приложения.

Запуск приложения в тот момент, когда система занимается резервированием.

Генерация множества асинхронных и управляемых событиями процессов.

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

Существуют и такие тесты, которые способны полностью прекратить работу приложения путем его повреждения. Таким образом, после тестирования пользователь будет постоянно «выпадать» из приложения. Кроме этого, тестер может использовать тактику отключения питания или кабеля при проверке [20].

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

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

2.1 Стратегия тестирования

Стратегия тестирования, или методы тестирования - это систематические методы, используемые для отбора и/или создания тестов, которые должны быть включены в тестовый комплект. Это могут быть случайные вводы, тест, направленный на проверку моих подозрений, тест, направленный на проверку ваших подозрений, тест, направленный на проверку соответствия требованиям, тест, направленный на проверку искаженности; тесты, который мы выполняли последний раз, тесты, которые отличаются от тестов, которые мы выполняли последний раз [7]. Мы выбираем стратегию, такую, что существуют правила, по которым мы можем определить, удовлетворяет данный тест стратегии или не удовлетворяет. В принципе, стратегия должна быть программируемой [16].

Стратегия является эффективной, если тесты, включенные в нее, с большой вероятностью обнаружат ошибки тестируемого объекта. Эффективность стратегии зависит от комбинации природы тестов и природы ошибок, на поиск которых эти тесты направлены. Как на войне и в бизнесе, здесь существуют эффективные и неэффективные стратегии. Более того, так как объект изменяется с целью исправления ошибок и увеличения его возможностей, типы ошибок, находимые у объекта, меняются со временем, и, следовательно, меняется эффективность стратегии. В то время как теоретически возможно, что стратегия по отношению к специфическим объектам совершенствуется во времени, на самом деле эффективность большинства стратегий со временем убывает [8].

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

Стратегия структурного теста определяется структурой тестируемого объекта [BASI87, BEIZ90, NTAF88, OSTR96]. Например: выполнение каждого оператора, по меньшей мере, один раз, выполнение каждой ветви, но меньшей мере один раз, тестирование использования всех объектов данных, выполнение каждой команды объектной программы, полученной при компиляции. Тестирование, выполненное с помощью стратегии структурного теста, называется также тестированием прозрачного ящика или тестированием белого ящика. Стратегия структурного теста требует полного доступа к структуре объекта - то есть к исходному коду [1].

Стратегия гибридного теста является комбинацией поведенческой и структурной стратегий [CLAR76, RICH81]. Поведенческая, структурная и гибридная стратегии не противоречат друг другу, и ни про одну из них нельзя сказать, что она лучше других. Модули и низкоуровневые компоненты часто тестируются с помощью структурной стратегии. Большие компоненты и системы в основном тестируются с помощью поведенческой стратегии. Гибридная стратегия полезна на всех уровнях. Не существует лучшей стратегии, так как полезность стратегии зависит от природы тестируемого объекта, природы ошибок объекта и уровня ваших знаний [5].

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

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

Драйверы – это своеобразные модули тестов, которые участвуют в запуске тестируемого элемента.

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

Отображают трассировочное сообщение и предлагают тестеру продолжить свое тестирование.

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

Возвращают постоянное значение или же предлагают тестеру самостоятельно ввести возвращаемое значение.

Имитируют аварийные и исключительные условия [1].

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

«Прозрачный» ящик базируется на структуре кода, а в основе «черного» ящика лежат функциональные возможности и поведенческие модели. Таким образом, и «черный», и «прозрачный» ящики представляют собой методы проектирования тестовых примеров. Каждый из них позволяет генерировать набор выходных и входных условий [17].

Метод «прозрачного» ящика дает возможность искать дефекты. Однако при его использовании существует риск того, что код будет проверяться по изначальному описанию. Это не гарантирует полной корректности при проведении проверки. При помощи метода «черного» ящика приложение проверяется исходя из конкретных требований. При этом подтверждается факт того, что специфические входные данные приведут к корректному ожидаемому исходу [6].