ISTQB_CTFL_Syllabus_2018-RU_3 — копия. Программа обучения Базового уровня Версия 2018 International Software Testing Qualifications Board
 Скачать 1.3 Mb.
|
|
3. Статические методы тестирования – 135 мин Ключевые слова свободное рецензирование, рецензирование на основе чек-листов, динамическое тестирование, формальное рецензирование, неформальное рецензирование, инспекция, прочтение, основанное на точке зрения, рецензирование, ролевое рецензирование, рецензирование, основанное на сценарии, статический анализ, статическое тестирование, технический анализ, разбор Цели обучения для главы «Статические методы тестирования» 3.1 Основы статического тестирования FL-3.1.1 (K 1) Распознавать типы программных продуктов, которые можно исследовать различными статическими методами FL-3.1.2 (K 2) Использовать примеры для описания значимости использования статических методов FL-3.1.3 (K 2) Объяснять разницу между статическими и динамическими методами, учитывая цели, типы выявляемых дефектов, и роль этих методов в жизненном цикле программного обеспечения 3.2 Процесс анализа FL-3.2.1 (K 2) Подведение итогов анализа рабочего продукта FL-3.2.2 (K 1) Распознавать разные роли и ответственность в формальном анализе FL-3.2.3 (K 2) Объяснять разницу между различными видами анализа: неформальный анализ, пошаговый разбор, технический анализ и инспекция FL-3.2.4 (K 3) Применение техники анализа для обнаружения дефектов в рабочем продукте FL-3.2.5 (K 2) Объяснять факторы, способствующие успешному анализу Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 48 of 94 24 февраля 2019 © International Software Testing Qualifications Board 3.1 Основы статического тестирования В отличие от динамического тестирования, которое требует исполнения кода, статическое тестирование опирается на выполняемую человеком экспертизу рабочих продуктов (например, рецензирование) или инструментальную оценку кода или других рабочих продуктов (например, статический анализ). Оба типа статического тестирования оценивают работу тестируемого продукта без фактического исполнения кода или работы тестируемого продукта. Статический анализ, безусловно, необходим для критически важных систем (например, для программного обеспечения в авиации, медицине или атомной энергетике), но статический анализ также стал важен и распространен в других областях. Например, статический анализ является важной частью тестирования безопасности. Проведение статического анализа также часто включается в автоматизированный процесс сборки и поставки систем, например, в разработке по гибкой методологии присутствуют непрерывные поставка и развертывание. 3.1.1 Рабочие продукты, которые могут быть проверены с помощью статических методов Практически любой продукт может быть исследован с использованием статического тестирования (рецензирования или статического анализа), например: Спецификации, включая бизнес-требования, функциональные требования и требования безопасности Эпики, пользовательские истории, критерии приемки Архитектура и проектные спецификации Код Тестовая документация, включая тест-планы, тест-кейсы, тестовые процедуры и автоматизированные тестовые сценарии Руководства пользователя Веб-страницы Контракты, проектные планы, графики и бюджеты Модели, такие как диаграммы действий, которые могут использоваться для тестирования на основе моделей (см. ISTQB-MBT Базовый уровень. Тестирование на основе моделей, [Kramer 2016]). Рецензирование может быть применено к любому рабочему продукту, который участники анализа понимают и могут прочесть. Статический анализ может быть эффективно применен к любому рабочему продукту с формальной структурой (обычно код или модели), для которого существует соответствующий инструмент статического анализа. Статический анализ может использовать инструменты, оценивающие рабочие продукты, написанные на естественном языке, такие как требования (например, инструменты проверки орфографии, грамматики, удобочитаемости). 3.1.2 Преимущества статических методов Статические методы обеспечивают множество преимуществ. При применении на ранней стадии разработки программного обеспечения статическое тестирование позволяет обнаруживать дефекты до проведения динамического тестирования (например, в требованиях или проектных спецификациях, актуализация списка требований к продукту и т.д.). Дефекты, обнаруженные на ранней стадии, гораздо дешевле исправить, чем дефекты, обнаруженные на более поздней стадии жизненного цикла, особенно в сравнении с дефектами, найденными после поставки и активного использования программного обеспечения. Использование методов Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 49 of 94 24 февраля 2019 © International Software Testing Qualifications Board статического тестирования для обнаружения дефектов и затем их быстрое исправление почти всегда намного дешевле для компании, чем использование динамического тестирования для обнаружения дефектов в тестовом объекте, а затем их исправление, особенно при рассмотрении дополнительных расходов, связанных с обновлением других продуктов и регрессионным тестированием. Дополнительные преимущества статического тестирования: Обнаружение и исправление дефектов более эффективно, до проведения динамического тестирования Идентификация дефектов, которые сложно обнаружить при динамическом тестировании Предотвращение дефектов дизайна или кодирования путем выявления несоответствий, неоднозначностей, противоречий, упущений, неточностей и избыточности требований Повышение производительности разработки, включая улучшение дизайна и сопровождаемости кода Сокращение затрат и времени на разработку Сокращение затрат и времени на тестирование Снижение общей стоимости качества в течение всего срока службы программного обеспечения из-за меньшего количества сбоев в жизненном цикле после поставки в эксплуатацию Улучшение коммуникации между членами команды в процессе участия в рецензировании 3.1.3 Различия между статическими и динамическими методами Статическое и динамическое тестирование могут иметь одни и те же цели (см. раздел 1.1.1), например, предоставление оценки качества продукта и выявление дефектов как можно раньше. Статическое и динамическое тестирование дополняют друг друга, обнаруживая различные типы дефектов. Одно из основных отличий заключается в том, что статическое тестирование обнаруживает дефекты в рабочих продуктах напрямую, а не идентифицирует сбои, вызванные дефектами при запуске программного обеспечения. Дефект может находиться в рабочем продукте очень долгое время, не вызывая сбоя. Путь, в котором находится дефект, может выполняться редко или быть труднодоступен, поэтому создать и выполнить динамический тест, который обнаружит этот дефект, может быть непросто. Статическое тестирование может найти дефект гораздо меньшими усилиями. Другое отличие состоит в том, что статическое тестирование может быть использовано для улучшения согласованности и внутреннего качества, а динамическое тестирование обычно фокусируется на видимом поведении программного обеспечения. Типичные дефекты, которые легче и дешевле найти и исправить с помощью статического тестирования: Дефекты требований (например, несоответствия, неоднозначности, противоречия, упущения, неточности, избыточность) Конструктивные дефекты (например, неэффективные алгоритмы или структуры базы данных, сильные связи, низкая связность) Отклонения от стандартов (например, несоблюдение стандартов кодирования) Неправильные спецификации интерфейса (например, различные единицы измерения) Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 50 of 94 24 февраля 2019 © International Software Testing Qualifications Board Уязвимость системы (например, уязвимость переполнения буфера) Пробелы или неточности в отслеживаемости и охвате тестовой базы (например, отсутствие тестов для критериев приемки) Более того, большинство типов дефектов ремонтопригодности можно найти только при статическом тестировании (например, неправильная модуляризация, плохое повторное использование компонентов, код, который трудно анализировать и модифицировать, не получая новые дефекты). 3.2 Процесс рецензирования Рецензирование может быть формальными и неформальными. Неформальное рецензирование характеризуется отсутствием необходимости соблюдения конкретного процесса и отсутствием формальной документации. Формальное рецензирование характеризуются участием команды, документированием результата рецензирования и документированием процесса рецензирования. Формальность процесса рецензирования связана с такими факторами, как модель жизненного цикла разработки программного обеспечения, зрелость процесса разработки, сложность рассматриваемого рабочего продукта, любые юридические или нормативные требования и/или необходимость проведения аудита. Фокус рецензирования зависит от согласованных целей (например, поиск дефектов, получение понимания, обучение тестировщиков и новых членов команды, или обсуждение и принятие решения путем консенсуса). Стандарт ИСО (ISO/IEC 20246) содержит более подробное описание процесса рецензирования работы продукта, включая роли и методы рецензирования. 3.2.1 Процесс рецензирования рабочего продукта Процесс рецензирования включает следующие основные мероприятия Планирование Определение объема работы, который включает цель рецензирования, какие документы или части документа подлежат рассмотрению и характеристики качества, подлежащие оценке Оценка длительности и трудозатрат Определение характеристик рецензирования, таких как тип рецензирования, роли, действия и чек-листы Выбор людей для участия в рецензировании и распределение ролей Определение критериев входа и выхода для более формальных типов рецензирования (например, инспекций) Проверка соответствия критериев входа (для более формальных типов рецензирования) Инициирование рецензирования Распространение рабочего продукта (физически или электронным способом) и таких материалов, как бланки описания дефектов, чек-листы и связанные с ними рабочие продукты Объяснение охвата, целей, процессов, ролей и рабочего продукта участникам процесса Ответы на любые вопросы, возникшие у участников при рецензировании Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 51 of 94 24 февраля 2019 © International Software Testing Qualifications Board Индивидуальное рецензирование (то есть индивидуальная подготовка) Рецензирование всего или части рабочего продукта Определение потенциальных недостатков, рекомендаций и вопросов Коммуникация по вопросам и анализ Сообщение выявленных потенциальных дефектов (например, на совещании по рецензированию) Анализ потенциальных дефектов, назначение их и установление статуса Оценка и документирование характеристик качества Оценка результатов рецензирования по критериям выхода для принятия решения по результатам обзора (отклонен; необходимы изменения; принять, возможно с незначительными изменениями) Внесение изменений и отчетность Создание отчетов о дефектах для тех результатов, которые требуют изменений Исправления обнаруженных при рецензировании дефектов (как правило, сделанные автором) Обсуждение дефектов с соответствующим лицом или командой (когда найдены в рабочем продукте, обсуждаемом на рецензировании) Регистрация обновленного состояния дефектов (в официальном рецензировании), включающих соглашение автора комментария Сбор метрик (для формальных типов рецензирования) Проверка выполнения критериев выхода (для формальных типов рецензирования) Принятие рабочего продукта при достижении критериев выхода Результаты рецензирования рабочего продукта различаются в зависимости от типа и формальности, что описано в разделе 3.2.3. 3.2.2 Роли и ответственности в формальном рецензировании Типичное формальное рецензирование включает в себя следующие роли: Автор Создает рассматриваемый рабочий продукт Исправляет дефекты в рассматриваемом продукте Менеджер Отвечает за планирование рецензирования Принимает решение о проведении рецензирования Определяет персонал, бюджет и время Отслеживает текущую экономическую эффективность Принимает управленческие решения в случае неадекватных результатов Ведущий (часто называется модератором) Обеспечивает эффективное проведение рецензирования Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 52 of 94 24 февраля 2019 © International Software Testing Qualifications Board При необходимости обеспечивает посредничество между различными точками зрения Часто это именно тот человек, от которого зависит успех рецензирования Руководитель рецензирования Берет на себя общую ответственность за рецензирование Решает, кто будет участвовать, организует время и место проведения Рецензенты Могут быть предметными экспертами, лицами, работающими в проекте, заинтересованными сторонами, заинтересованными в рабочем продукте лицами и/или лицами с узкими техническими или бизнес-знаниями Определяют потенциальные дефекты в рассматриваемом продукте Могут представлять различные взгляды на продукт (например, тестировщик, программист, пользователь, оператор, бизнес-аналитик, эксперт по используемости и т.д.) Секретарь (или регистратор) Собирает потенциальные дефекты, обнаруженные в ходе индивидуальной проверки Записывает новые потенциальные дефекты, открытые вопросы и решения на совещании по рецензированию (во время проведения) В некоторых типах рецензирования один человек может играть более, чем одну роль, а действия, связанные с одной ролью, также могут варьироваться в зависимости от типа рецензирования. Кроме того, с появлением инструментов поддержки процессов рецензирования, особенно для регистрации дефектов, открытых вопросов и решений, часто нет необходимости в секретаре. Также возможны более подробно описанные роли, как в стандарте ИСО (ISO/IEC 20246). 3.2.3 Типы рецензирования Хотя рецензирование может использоваться по-разному, одна из основных целей – выявление дефектов. Все типы рецензирования могут помочь в обнаружении дефектов, а выбранный тип рецензирования среди других критериев должен основываться на потребностях проекта, доступных ресурсах, типе продукта и рисках, области бизнеса и корпоративной культуре. Типы рецензирования могут быть классифицированы в соответствии с различными параметрами. Ниже перечислены четыре наиболее распространенных типа обзора и связанных с ними параметрами. Неформальное рецензирование (например, партнерская проверка, парное рецензирование) Основная цель: выявление потенциальных дефектов Возможны дополнительные цели: генерация новых идей и решений, быстрое решение мелких проблем Не основан на формальном (документированном) процессе Может не включать обзорную встречу Может быть выполнен коллегой автора (партнерская проверка) или другими людьми Результаты могут быть задокументированы Полезность зависит от рецензентов Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 53 of 94 24 февраля 2019 © International Software Testing Qualifications Board Необязательное использование чек-листов Очень часто используется в гибких методологиях Пошаговый разбор Основные цели: найти дефекты, улучшить программный продукт, рассмотреть альтернативные варианты реализации, оценить соответствие стандартам и спецификациям Возможные дополнительные цели: обмен идеями о техниках и вариантах стиля, обучение участников, достижение консенсуса Индивидуальная подготовка перед совещанием по рассмотрению необязательна Обзорное собрание обычно проводится автором программного продукта Секретарь обязателен Использование чек-листов необязательно Может принимать форму сценариев, пробных прогонов или имитаций Могут быть получены записи потенциальных дефектов и отчеты по рецензированию На практике варьируется от довольно неформального до очень формального Техническое рецензирование Основные цели: достижение консенсуса, выявление потенциальных дефектов Возможные дальнейшие цели: оценка качества и укрепление доверия к рабочему продукту, генерация новых идей, мотивация авторов, предоставление возможности авторам улучшить будущий рабочий продукт, рассмотрение альтернативных вариантов реализации Рецензенты должны быть специалистами той же отрасли, что и автор, а технические эксперты – специалистами в той же или другой дисциплине Требуется индивидуальная подготовка перед собранием по рецензированию Совещание по рецензированию – необязательно, в идеале проводится подготовленным ведущим (обычно не автором) Секретарь обязателен, в идеале – не автор Использование чек-листов необязательно Обычно получаются записи потенциальных дефектов и отчеты по рецензированию Инспекция Основные цели: выявление потенциальных дефектов, оценка качества и укрепление доверия к рабочему продукту, предотвращение аналогичных дефектов в будущем с помощью обучения автора и анализа основных причин появления дефектов Возможные дальнейшие цели: мотивировать авторов, дать авторам возможность улучшить рабочий продукт и процесс разработки в будущем, достижение консенсуса Выполняется конкретный процесс с формальными документами на основе правил и чек- листов Используются четко определенные роли, указанные в разделе 3.2.2. Роли являются обязательными и могут включать специального чтеца (который читает рабочий продукт во время обзорного собрания) Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 54 of 94 24 февраля 2019 © International Software Testing Qualifications Board Требуется индивидуальная подготовка перед собранием по обзору Рецензенты – специалисты той же отрасли, что и автор или эксперты в других дисциплинах, имеющих отношение к рабочему продукту Указаны критерии входа и выхода Секретарь обязателен Совещание по рецензированию проводится специальным ведущим (не автором) Автор не может выступать в качестве руководителя рецензирования, чтеца или секретаря Создаются записи о дефектах и отчеты о рецензировании Собираются критерии и используются для улучшения всего процесса разработки программного обеспечения, включая процесс проверки Один рабочий продукт может быть предметом более одного типа рецензирования. Если используется более, чем один тип рецензирования, порядок может отличаться. Например, неформальное рецензирование может быть проведено до технического рецензирования для того, чтобы убедиться, что продукт готов к техническому обзору. Типы рецензирования, описанные выше, могут быть выполнены специалистами одной области, то есть проведены коллегами по аналогии с приблизительным организационным уровнем. Типы дефектов, обнаруженных при рецензировании, различаются, в частности зависят от рассматриваемого рабочего продукта. См. раздел 3.1.3, где рассматриваются примеры дефектов, которые можно найти при рецензировании разных рабочих продуктов и см. [Glib 1993 ] для получения информации о формальном рецензировании. 3.2.4 Применение методов рецензирования Существует ряд методов рецензирования, которые применяются для индивидуальных проверок (то есть для индивидуальной подготовки) для выявления дефектов. Эти методы могут использоваться во всех описанных выше типах рецензирования. Эффективность метода может отличаться в зависимости от типа используемого рецензирования. Примеры различных методов индивидуального рецензирования перечислены ниже. |