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

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

1. Одной из наиболее активно используемых техник анализа требований является просмотр или рецензирование. Данная техника может быть реализована в форме: - беглого просмотра (показ автором своей работы коллеге; самый быстрый, самый дешёвый и наиболее широко используемый вид просмотра); - технического просмотра (выполняется группой специалистов, каждый из которых представляет свою область знаний: просматриваемый продукт не может считаться достаточно качественным, пока хотя бы у одного просматривающего остаются замечания); - формальной инспекцией (структурированный, систематизированный и документируемый подход к анализу документации, для выполнения которого привлекается большое количество специалистов, само выполнение занимает достаточно много времени, и потому этот вариант просмотра используется достаточно редко).

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

Если хоть что-то в требованиях вызывает непонимание или подозрение – задавайте вопросы.

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

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

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

1.4 Модульное тестирование

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

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

На уровне модульного тестирования проще всего обнаружить дефекты, связанные с алгоритмическими ошибками и ошибками кодирования алгоритмов, типа работы с условиями и счетчиками циклов, а также с использованием локальных переменных и ресурсов. Ошибки, связанные с неверной трактовкой данных, некорректной реализацией интерфейсов, совместимостью, производительностью и т.п. обычно пропускаются на уровне модульного тестирования и выявляются на более поздних стадиях тестирования. Именно эффективность обнаружения тех или иных типов дефектов должна определять стратегию модульного тестирования, то есть расстановку акцентов при определении набора входных значений. У организации, занимающейся разработкой программного обеспечения, как правило, имеется историческая база данных (Repository) разработок, хранящая конкретные сведения о разработке предыдущих проектов: о версиях и сборках кода (build) зафиксированных в процессе разработки продукта, о принятых решениях, допущенных просчетах, ошибках, успехах и т.п.

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

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

Являясь по способу исполнения структурным тестированием или тестированием "белого ящика", модульное тестирование характеризуется степенью, в которой тесты выполняют или покрывают логику программы (исходный текст). Интеграционное тестирование Интеграционное тестирование – это тестирование части системы, состоящей из двух и более модулей. Основная задача интеграционного тестирования - поиск дефектов, связанных с ошибками в реализации и интерпретации интерфейсного взаимодействия между модулями. С технологической точки зрения интеграционное тестирование является количественным развитием модульного, поскольку так же, как и модульное тестирование, оперирует интерфейсами модулей и подсистем и требует создания тестового окружения, включая заглушки (Stub) на месте отсутствующих модулей. Основная разница между модульным и интеграционным тестированием состоит в целях, то есть в типах обнаруживаемых дефектов, которые, в свою очередь, определяют стратегию выбора входных данных и методов анализа. В частности, на уровне интеграционного тестирования часто применяются методы, связанные с покрытием интерфейсов, например, вызовов функций или методов, или анализ использования интерфейсных объектов, таких как глобальные ресурсы, средства коммуникаций, предоставляемых операционной системой.

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

Известны два метода сборки модулей:

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

Инкрементальный, характеризующийся пошаговым (помодульным) наращиванием комплекса программ с пошаговым тестированием собираемого комплекса. В инкрементальном методе выделяют две стратегии добавления модулей: o "Сверху вниз" и соответствующее ему нисходящее тестирование. o "Снизу вверх" и соответственно восходящее тестирование.

Глава 2. Отладка и тестирование программы

2.1 Тест – модуль

Тест-план Тест-план (test plan) – документ, описывающий цели, подходы, ресурсы и график запланированных тестовых активностей. Он определяет объекты тестирования, свойства для тестирования, задания, ответственных за задания, степень независимости каждого тестировщика, тестовое окружение, метод проектирования тестов, определяет используемые критерии входа и критерии выхода и причины их выбора, а также любые риски, требующие планирования на случай чрезвычайных обстоятельств. К низкоуровневым задачам планирования в тестировании относятся: - оценка объёма и сложности работ; - определение необходимых ресурсов и источников их получения; - определение расписания, сроков и ключевых точек; - оценка рисков и подготовка превентивных контрмер; - распределение обязанностей и ответственности; - согласование работ по тестированию с деятельностью участников проектной команды, занимающихся другими задачами.

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

- Реалистичность (запланированный подход реально выполним).

- Гибкость (качественный тест-план не только является модифицируемым с точки зрения работы с документом, но и построен таким образом, чтобы при возникновении непредвиденных обстоятельств допускать быстрое изменение любой из своих частей без нарушения взаимосвязи с другими частями). - Согласованность с общим проектным планом и иными отдельными планами (например, планом разработки). Тест-план создаётся в начале проекта и дорабатывается по мере необходимости на протяжении всего времени жизни проекта при участии наиболее квалифицированных представителей проектной команды, задействованных в обеспечении качества. Ответственным за создание тестплана, как правило, является ведущий тестировщик («тест-лид»). В общем случае тест-план включает следующие разделы: - Цель (purpose). Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования, но здесь информация подаётся в ещё более сжатом виде и в контексте того, на что следует обращать первостепенное внимание при организации тестирования и повышения качества). - Области, подвергаемые тестированию (features to be tested).

Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. - Области, не подвергаемые тестированию (features not to be tested). Перечень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключения той или иной области из списка тестируемых могут быть самыми различными — от предельно низкой их важности для заказчика до нехватки времени или иных ресурсов.

Этот перечень составляется, чтобы у проектной команды и иных заинтересованных лиц было чёткое единое понимание, что тестирование таких-то особенностей приложения не запланировано — такой подход позволяет исключить появление ложных ожиданий и неприятных сюрпризов. - Тестовая стратегия (test strategy) и подходы (test approach). Описание процесса тестирования с точки зрения применяемых методов, подходов, видов тестирования, технологий, инструментальных средств и т.д. - Критерии (criteria). Этот раздел включает следующие подразделы:

• Приёмочные критерии, критерии качества (acceptance criteria) — любые объективные показатели качества, которым разрабатываемый продукт должен соответствовать с точки зрения заказчика или пользователя, чтобы считаться готовым к эксплуатации.

• Критерии начала тестирования (entry criteria) — перечень условий, при выполнении которых команда приступает к тестированию. Наличие этого критерия страхует команду от бессмысленной траты усилий в условиях, когда тестирование не принесёт ожидаемой пользы.

• Критерии приостановки тестирования (suspension criteria) — перечень условий, при выполнении которых тестирование приостанавливается. Наличие этого критерия также страхует команду от бессмысленной траты усилий в условиях, когда тестирование не принесёт ожидаемой пользы.

• Критерии возобновления тестирования (resumption criteria) — перечень условий, при выполнении которых тестирование возобновляется (как правило, после приостановки).

• Критерии завершения тестирования (exit criteria) — перечень условий, при выполнении которых тестирование завершается. Наличие этого критерия страхует команду как от преждевременного прекращения тестирования, так и от продолжения тестирования в условиях, когда оно уже перестаёт приносить ощутимый эффект.

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