ISTQB CTFL Syllabus 2011 RU

Терминология

Динамическое тестирование, статическое тестирование.

Введение

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

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

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

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

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

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

© International Software Testing Qualifications Board

Терминология

Критерий входа, формальнаое рецензирование, неформальное рецензирование, инспекция, метрика, модератор, равноправный анализ, эксперт, секретарь, технический анализ, сквозной контроль.

Введение

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

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

3.2.1 Действия (шаги) формального рецензирования (K1)

Типичное формальное рецензирование включает следующие действия:

1.Планирование:

•определение критерия рецензирования,

•выбор участников,

•распределение ролей

•Определение критериев входа и выхода для более формальных типов рецензирования (например, инспекций)

•Отбор частей документации для рецензирования

•Проверка критерия входа (для более формальных типов рецензирования)

2.Старт:

•Распределение документов

•Объяснение целей, процесса участникам

3.Индивидуальная подготовка:

•Подготовка к экспертному собранию - анализ документов

•Конспектирование потенциальных дефектов, вопросов и комментариев

4.Изучение/оценка/запись результатов (встреча экспертов)

© International Software Testing Qualifications Board

•Обсуждение или формирование списка, с документированием результатов или времени (для более формальных типов рецензирования)

•Конспектирование дефектов, создание рекомендаций по управлению дефектами, принятие решений о дефектах.

•Изучение/оценка и запись во время любых реальных встреч или отслеживание виртуального группового общения

5.Повторная обработка:

•Исправление найденных дефектов (обычно исполняется автором)

•Запись обновленного статуса дефектов (в формальных рецензированиях)

6.Отслеживание:

•Проверка того, что дефекты были назначены

•Сбор метрик

•Проверка критерия выхода (для более формальных рецензирований)

3.2.2 Роли и Обязанности (K1)

Обычно формальное рецензирование включает следующие роли:

•Менеджер: принимает решение о проведении рецензирования, выделяет время в графике проекта и определяет, были ли достигнуты цели рецензирования

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

•Автор: автор или главный ответственный за документ(ы) для рецензирования

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

•Секретарь: документирует все проблемы и открытые вопросы, которые были определены во время экспертной встречи

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

© International Software Testing Qualifications Board

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

3.2.3 Типы рецензирований (K2)

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

Основное характеристики, опции и цели основных типов рецензирования:

Неформальное рецензирование

•Отсутствие формального процесса

•Может принимать форму парного программирования или рецензирования дизайна или кода техническим руководителем

•Результаты могут быть документированы

•Эффективность зависит от экспертов

•Главные цели: результат при минимуме затрат

Сквозной контроль

•Встреча проводится автором

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

•Не ограниченные по времени сессии

oНеобязательно - подготовка экспертов перед встречей,

oНеобязательно - подготовка отчета по рецензированию с записью найденных проблем вопросов

•Наличие секретаря (не автора) необязательно

•На практике могут варьироваться от неформальных до строго формальных

•Главные цели: обучение, достижение понимания, поиск дефектов

Технический анализ

•Документированный процесс определения и нахождения дефектов, который включает участников команды, технических экспертов и, возможно, руководство

•Может проводиться как равноправный анализ без участия руководства

•В идеале проводится обученным модератором (не автором)

•Предварительная подготовка экспертов

•Использование контрольных списков необязательно

© International Software Testing Qualifications Board

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

•На практике могут варьироваться от сильно до строго формальных

•Главные цели: обсуждение, принятие решений, оценка альтернатив, нахождение дефектов, решение технических проблем и проверка соответствия требованиям, планам, нормам и стандартам

Инспекция

•Проводится обученным модератором

•Обычно сопровождается равноправным исследованием

•Роли определены

•Включает сбор метрик

•Формальный процесс основан на правилах и контрольных списках

•Определены критерии входы и выхода для приемки программного продукта

•Предварительная подготовка перед встречей

•Инспекционный отчет включает список найденных проблем и вопросов

•Формальный процесс отслеживания

oНеобязательно - процесс улучшения компонентов

•Наличие рецензента необязательно

•Главная цель: поиск дефектов

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

3.2.4 Факторы успешного проведения (K2)

Факторы успешного проведения рецензирования:

•Каждое рецензирование должно иметь четкие, определенные заранее цели

•Вовлечение правильных людей в соответствии с целями рецензирования

•Тестировщики - ценные эксперты, которые вносят свой вклад в рецензирование, а также изучают продукт, что позволяет создавать тесты раньше

•Найденные дефекты ожидаемы и выражены объективно

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

•Рецензирование должно проводиться в атмосфере доверия, результаты не должны использоваться для оценки участников

© International Software Testing Qualifications Board

•Должны применяться те методы рецензирования, которые подходят для достижения поставленных целей, соответствуют типу и уровню программного продукта и экспертов

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

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

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

•Акцент на изучении и улучшении процесса

© International Software Testing Qualifications Board

Компилятор, коэффициент сложности, поток управления, поток данных, статический анализ

Введение

Цель статического тестирования - нахождение дефектов в коде или моделях ПО. Фактически статический анализ – это исследование ПО с помощью специального инструмента без его запуска, при динамическом тестировании ПО требуется запуск кода. Статический анализ выявляет дефекты, которые сложно найти при динамическом тестировании. Так же, как и рецензирования, статический анализ больше находит дефекты, чем сбои. Инструментальные средства статического анализа анализируют код программы (например, потоки управления и поток данных), а так же сгенерированный код, например, HTML или XML.

Преимущества статического анализа:

•Раннее обнаружение дефектов до исполнения тестов

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

•Определение дефектов, которые сложно обнаружить с помощью динамического тестирования

•Определение зависимостей и нарушений целостности в моделях ПО, например ссылок

•Улучшение пригодности к сопровождению кода и дизайна

•Предотвращение дефектов путем усвоения уроков, полученных во время разработки

Типичные дефекты, которые могут быть найдены при статическом анализе:

•Обращение к переменной, которой не присвоено значение

•Несоответствие интерфейсов между модулями и компонентами

•Переменные, которые не используются или некорректно объявлены

•Невыполняемые ветки кода

•Пропущенная или неверная логика (например, бесконечные циклы)

•Излишне сложные конструкции

•Отклонение от стандартов программирования

•Уязвимость в безопасности

•Нарушение синтаксиса в коде или моделях ПО

© International Software Testing Qualifications Board

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

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

Ссылки:

3.2IEEE 1028

3.2.2 Gilb, 1993, van Veenendaal, 2004

3.2.4 Gilb, 1993, IEEE 1028

3.3Van Veenendaal, 2004

© International Software Testing Qualifications Board

Цели изучения методов проектирования тестов:

Цели определяют Ваши возможности после завершения работы с каждым модулем.

4.1Процесс разработки тестов (K2)

LO-4.1.1 Различия между спецификациями проектирования тестов, спецификациями тестовых сценариев и спецификациями процедур тестирования. (К2)

LO-4.1.2 Сравнение терминов тестовое условие, тестовый сценарий и процедура тестирования. (K2)

LO-4.1.3 Оценка качества тестовых сценариев. Могут ли они:

-Показать четкую трассируемость к требованиям

-Содержать ожидаемый результат. (K2)

LO-4.1.4 Перевести тестовые сценарии в хорошо структурированную спецификацию процедуры тестирования на уровне детализации, соответствующей знаниям тестировщиков

4.2Категории методов проектирования тестов (К2)

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

LO-4.2.2 Объяснить характеристики и различия между методом разработки тестов на основе спецификаций, методом, основанным на структуре и методом на основе опыта. (К2)

4.3 Метод разработки тестов на основе спецификаций, или метод черного ящика (К3)

LO-4.3.1 Создать тестовые сценарии для приведенных моделей программного обеспечения при помощи следующих методов проектирования тестов: (К3)

-эквивалентное разбиение;

-анализ граничных значений;

-тестирование таблицы решений;

-тестирование таблицы переходов.

LO-4.3.2 Объяснить назначение каждого из четырех методов, какие уровни и типы тестирования могут использовать данные методы, и каким

© International Software Testing Qualifications Board

образом может быть измерено покрытие при использовании данных методов. (К2)

LO-4.3.3 Понять принцип тестирования по сценарииям использования и его выгоды. (К2)

4.4Методы, основанные на структуре, или методы белого ящика (К3)

LO-4.4.1 Описать принцип и важность покрытия кода. (К2)

LO-4.4.2 Объяснить принципы покрытия операторов и альтернатив и понять, что данные принципы также могут быть использованы в уровнях тестирования, отличных от компонентного тестирования (например, в тестировании бизнес-процессов на системном уровне). (К2)

LO-4.4.3 Написать тестовые сценарии для приведенных потоков управления с использованием следующих методов проектирования тестов:

-тестирование операторов;

-тестирование альтернатив. (K3)

LO-4.4.4 Оценить покрытие операторов и альтернатив в отношении критериев выхода (K3)

4.5Методы создания тестов на основе опыта (К2)

LO-4.5.1 Вспомнить мотивы для создания тестовых сценариев, основанных на интуиции, опыте и знаниях об обычных дефектах. (K1)

LO-4.5.2 Сравнить методы создания тестов на основе опыта с методами разработки тестов на основе спецификаций. (K2)

4.6Выбор методов тестирования. (K2)

LO-4.6.1 Классифицировать методы проектирования тестов по их соответствию данному контексту, исходя из базиса тестирования, соответствующих моделей и характеристик программного обеспечения. (K2)

© International Software Testing Qualifications Board