Файл: Принципы и понятия теста ПО.pdf

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

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

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

Методы теста, основывающиеся на белом ящике:

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

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

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

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

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

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

Анализ покрытия. В выборе аналитического инструмента нужно, чтобы группа тестирования изучила сам тип покрытия, нужный приложению. Метод покрытия операторов еще называют С1, что еще и может означать покрытие узлов. Такие тестирования определят, все ли исполняемые операторы были протестированы. Метод такого тестирования зачастую использует программу протокола (profiler – профайлер) производительности.

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

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

2.3 Стратегия «черной коробки»

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

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

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

Неверная или пропущенная функциональность

Ошибки интерфейса

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

Методы тестирования на основе Автоматизированные инструменты

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

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

Ошибки загрузки

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

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

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

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

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

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

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

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

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

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

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

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

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

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