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

Проверяются все логические решения на предмет истинности или ложности.

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

Исследуются внутренние структуры данных с целью проверки их достоверности.

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

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

Методы тестирования на основе белого ящика (рис. 3.)^[30]:

Рис. 4. Методы тестирования на основе белого ящика

Ввод неправильных значений. При вводе неправильные значения, тестировщик приводит к тому что, коды возврата отображают ошибки и смотрит на реакцию кода. Это хороший способ смоделировать определенные события, такие как переполнение диска, недостаточность памяти и тому подобное. Популярным методом является в замена функции Alloc (), которая возвращает значение NULL в 10% случаев по причине определить, сколько отказов будет в результате. Такой подход называется тестирование ошибочных входных данных. С помощью этого теста проверяется обработка, как правильных так и неправильные входные данные. Тестировщики могут выбрать значения, которые проверяют параметры ввода / вывода, а также значения вне пограничного диапазона^[31].

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

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

Утечка памяти^[33]. При проверке утечки памяти, приложение^[34] рассматривается для обнаружения ситуаций, когда приложение не освобождает выделенную память, что приводит к снижению производительности или тупиковой ситуации. Эта технология используется для тестовой версии приложения, а также для тестирования готового программного продукта. Возможно использование инструментов тестирования. Они могут контролировать использование памяти приложения в течение нескольких часов или даже дней, чтобы проверить, будет ли расти память. Они могут быть использованы для идентификации тех операторов программы, которые не освобождают распределенную память.

Комплексное тестирование^[35]. Цель комплексного тестирования состоит в проверке, что каждый модуль программного продукта правильно согласуется с другими модулями продукта. Если в комплексном тесте может быть использована технология обработки сверху вниз и снизу вверх, где каждый модуль представляет собой лист в системе дерева и интегрируется со следующим модулем ниже или выше, пока вы не создадите дерево программного продукта. Этот методика теста направлена ​​на тестирование не только параметров, которые передаются между двумя компонентами, но и проверяются глобальные параметры в случае объектно-ориентированного приложения всех классов верхнего уровня.

Тестирование цепочек. Тестирование цепочек включает в себя проверку группы модулей, составляющие функционирование программного обеспечения. Эти шаги, известны ещё как модульное тестирование, оно обеспечивает адекватное тестирование компонентов системы. Это тестирование показывает, достаточна ли надежность работы модулей, чтобы сформировать единый модуль, который делает точные и согласующиеся расчёты для программного продукта. При выборе инструмента для исследования покрытия важно, что команда тестирования проанализировала тип покрытия, необходимого для приложения. Изучение покрытия может быть осуществлено с использованием различных технологий. Метод покрытия операторов часто называют С1, что также означает охват узлов. Эти измерения показывают, проверен ли каждый исполняемый оператор^[36]. Такой способ тестирования обычно использует программу протоколирования производительности.

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

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

3. Метод «черного ящика^[37]»

Стратегия тестирования, черного^[38] ящика возможна только при наличии установленных общедоступных интерфейсов, таких как пользовательский интерфейс или интерфейс прикладного программирования (API). Если стратегия тестирования белого ящика исследует внутренние работы программы, методы тестирования черного ящика сравнивают поведение приложения с соответствующими требованиями. Кроме того, эти методы, как правило, направлены на выявление трех основных типов ошибок: функциональность поддерживания программным продуктом; производимых расчетов; допустимого диапазона или области действия данных, которые могут быть обработаны с помощью программного обеспечения. На этом уровне тестировщики не исследуют внутренние работы программного продукта, однако они проходят в неявном виде. Команда тестирования анализирует входные и выходные данные программного продукта. С этой точки зрения, тестирование с использованием методов черного ящика рассматривается как синоним тестирования на системном уровне, хотя методы черного ящика могут быть также использованы в процессе модульного и компонентного тестирования.

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

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

Неправильные или отсутствующие функциональные возможности

Ошибки интерфейса^[39]

Проблемы простоты использования

Методы тестирования на основе автоматизированных инструментов^[40]

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

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

Ошибка^[41] загрузки

Ошибка многопользовательского доступа

Ошибки инициализации и завершения

Проблемы сохранения резервных копий и возможности восстановления

Проблемы с безопасностью^[42]

Методы тестирования на основе стратегии чёрного ящика (рис.5).

Рис. 5. Методы тестирования на основе стратегии чёрного ящика

Эквивалентное разбиение. Комплексное тестирование входных данных, как правило, не представляется возможным. Таким образом, вы должны выполнить тестирование с использованием подмножества входных данных.

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

Анализ граничных значений. Анализ граничных значений может быть применен на структурно-функциональном уровне тестирования^[43]. Границы указывают данные трех типов: правильные, неправильные и лежащих на границе. Тестирование границ использует значения, лежащие внутри или на границе (например, крайние точки), а так же максимальное / минимальное значение (например, длины полей). Такие исследования должны всегда принимать во внимание значение на единицу больше и меньше крайнего. При тестировании вне границы используется репрезентативная выборка данных, выходящая за границы, т.е. недопустимых значений.

Диаграммы причинно-следственных связей^[44]. Составление диаграммы причинно-следственных связей является метод, который дает четкое представление о логических условиях и соответствующих действиях. Способ включает в себя четыре этапа. Первый шаг заключается в создании списка причин (входные условия) и следствий (действий) для модуля в назначении идентификатора для каждого модуля. На втором этапе разрабатывается диаграммы причинно-следственных связей. На третьем этапе диаграмма преобразуется в таблицу решений. Четвертый этап предполагает установление причинно-следственных связей в процессе чтения спецификации функций. Каждой причине и следствию присваивается свой собственный идентификатор. Причины перечисляются в колонке с левой стороны листа бумаги, а следствие справа. Затем причины и следствия соединяются линиями, чтобы показать фактическое соответствие между ними. На диаграмме проставляются логические выражения, которые сочетают в себе две или более причины связанных с исследованием^[45]. Кроме этого правила таблицы решений преобразуются в тестовые процедуры.

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

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

Регрессионное тестирование^[46]. Смысл тестирования для выявления дефектов, их документирования и отслеживания вплоть до разрешения проблем. Тестировщик должен быть уверен в том, что меры, принятые для устранения обнаруженных проблем, не приведут в свою очередь к новым ошибкам в других областях системы. Регрессионное тестирование позволяет выяснить, существует ли какая-либо ошибка в результате устранения ранее обнаруженных ошибок. Для регрессионного тестирования использование автоматизированных средств тестирования дает наибольшую отдачу. Все ранее созданные скрипты могут быть использованы для подтверждения, что в результате внесённых изменений, когда проблема будет устранена, никаких новых дефектов не возникнет. Эта цель легко достижима, поскольку скрипты могут выполняться без ручного вмешательства и использоваться столько раз, сколько необходимо для обнаружения ошибок.