ISTQB_CTFL_Syllabus_2018-RU_3 — копия. Программа обучения Базового уровня Версия 2018 International Software Testing Qualifications Board
 Скачать 1.3 Mb.
|
|
2.2. Уровни тестирования FL-2.2.1. (К2) Сравнить различные уровни тестирования с точки зрения целей, базиса тестирования, объектов тестирования, типичных дефектов и отказов, а также подходов и обязанностей. 2.3. Типы тестирования FL-2.3.1. (К2) Сравнить функциональное, нефункциональное и тестирование методом белого ящика. FL-2.3.2. (К1) Осознать, что функциональные, нефункциональные, а также тесты, исполняемые методом белого ящика, выполняются на любом уровне тестирования. FL-2.3.3. (К3) Сравнить цели подтверждающего и регрессионного тестирования. 2.4. Тестирование в период сопровождения FL-2.4.1. (К2) Обобщить предпосылки для тестирования в период сопровождения. FL-2.4.2. ( К2) Объяснить значение анализа влияния для тестирования в период сопровождения. Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 29 of 94 24 февраля 2019 © International Software Testing Qualifications Board 2.1 Модели жизненного цикла разработки ПО Модель жизненного цикла разработки программного обеспечения описывает виды активностей, выполняемых на каждом этапе процесса разработки программного обеспечения, а также то, как эти активности связаны друг с другом логически и хронологически. Существует несколько различных моделей жизненного цикла разработки программного обеспечения, каждый из которых требует различных подходов к тестированию. 2.1.1 Разработка и тестирование программного обеспечения Важной частью работы тестировщика является знание распространенных моделей жизненного цикла разработки ПО, на основании которых происходит выбор соответствующих активностей по тестированию. Для любой модели жизненного цикла разработки существуют несколько показателей качественного тестирования: Для каждой активности разработки существует соответствующая активность тестирования. У каждого уровня тестирования есть цели, характерные для данного уровня. Анализ и проектирование тестов для определенного уровня тестирования начинаются на стадии соответствующих активностей разработки. Тестировщики должны участвовать в обсуждениях для определения и уточнения требований и дизайна, а также вовлекаться в рецензирование рабочих продуктов (например, требований, дизайна, пользовательских историй и т.п.), как только будут доступны первые их черновые версии. Независимо от того, какая модель жизненного цикла разработки выбрана, активности тестирования следует начинать на ранних стадиях жизненного цикла, придерживаясь принципа раннего тестирования. Эта программа обучения классифицирует распространенные модели жизненного цикла разработки следующим образом: Последовательные модели разработки Итерационные и инкрементальные модели разработки Последовательная модель разработки описывает процесс разработки программного обеспечения в качестве линейного, последовательного потока активностей. Это означает, что любую фазу процесса разработки следует начинать после того, как предыдущая фаза завершена. Теоретически фазы не пересекаются друг с другом, но на практике бывает полезным получать раннюю обратную связь от следующей фазы. При работе по модели «Водопад», активности разработки (например, анализ требований, дизайн, написание кода, тестирование) выполняются каждая по окончании предыдущей. В данной модели активности тестирования осуществляются только после того, как все активности разработки выполнены. В отличие от модели «Водопад», V-модель интегрирует тестовый процесс на протяжении процесса разработки, реализуя принцип раннего тестирования. Более того, V-модель включает уровни тестирования, относящиеся к соответствующей фазе разработки, что также поддерживает раннее тестирование (смотрите раздел 2.2 для рассмотрения уровней тестирования). В этой модели выполнение тестов, связанных с каждым уровнем тестирования, продолжается последовательно, но в некоторых случаях происходят пересечения. Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 30 of 94 24 февраля 2019 © International Software Testing Qualifications Board Результатом работы с применением последовательных моделей разработки является ПО, которое содержит полный набор функциональности, но для его поставки заказчику и пользователям зачастую уходят месяцы и даже годы разработки. Инкрементальная разработка подразумевает определение требований, дизайн, сборку и тестирование системы по частям. Это приводит к тому, что функциональность ПО растет постепенно. Размер таких функциональных приращений разнится в большую или меньшую сторону в зависимости от выбранных методов работы. Приращение функциональности может включать всего одно изменение в пользовательском интерфейсе или новую опцию запроса. Итеративная разработка используется в случае, когда разрабатываемый функционал должен быть определен, спроектирован, построен и протестирован в течение нескольких этапов, зачастую с фиксированной продолжительностью каждого из них. Итерации могут включать в себя как набор изменений функционала, реализованного в предыдущих итерациях, так и изменения всего разрабатываемого продукта в целом. На выходе каждой итерации получается рабочий программный продукт, который, по сути, является растущим набором общего функционала, и продолжается это до тех пор, пока не будет выпущена финальная версия этого продукта или разработка не будет остановлена. В качестве примера можно привести следующие методологии: RUP (Rational Unified Process ): методология: каждая итерация может быть относительно долгой (например, от двух до трех месяцев), а приращения функциональности соответственно большими, к примеру, две или три группы связанных функциональностей. Скрам: каждая итерация может быть относительно короткой (например, часы, дни или несколько недель), а приращения функциональности соответственно небольшими, как, например, несколько улучшений и/или две или три новые функции. Канбан: осуществляется с использованием или без использования итераций фиксированной продолжительности, по завершению которых выпускается либо единственная доработка или функциональность, либо группа функциональностей, объединенных вместе. Спиральная модель разработки (прототипирование): подразумевает создание экспериментальных приращений, некоторые из которых могут быть значительно переработаны или даже отвергнуты в последующей работе по разработке. Компоненты или системы, разрабатываемые с использованием этих моделей, часто подразумевают пересечение и повторение уровней тестирования на протяжении процесса разработки. В идеале, каждая функциональность тестируется на нескольких уровнях тестирования по мере приближения к выпуску продукта. В некоторых случаях, команды используют непрерывную поставку или непрерывное развертывание, которые подразумевают существенную автоматизацию многих уровней тестирования в процессе поставки. Предпринимаемые усилия по разработке ПО с использованием этих методов, также включают концепцию самоорганизующихся команд, что может изменить как организацию работ по тестированию, так и взаимоотношения между тестировщиками и разработчиками. Применение этих методов в итоге формирует готовый продукт, который может быть выпущен конечным пользователям на основе постепенного приращения функциональности или более традиционным способом изготовления основного релиза. Независимо от того, поставлялись ли приращения конечным пользователям, важность регрессионного тестирования растет с ростом разрабатываемой системы. В отличие от результатов работы с применением последовательных моделей разработки, результатом работы с применением итеративных и инкрементальных моделей является ПО, готовое к использованию через недели или даже дни, но до поставки полного набора требований продукта могут уйти многие месяцы и даже годы. Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 31 of 94 24 февраля 2019 © International Software Testing Qualifications Board Для получения дополнительной информации о тестировании в контексте гибких методологий разработки предлагаем изучить ISTQB Базовый уровень. Тестировщик в сфере Гибких методологий, [Black 2017], [Crispin 2008] и [Gregory 2015]. 2.1.2 Выбор модели жизненного цикла разработки в зависимости от ситуации Модели жизненного цикла разработки программного обеспечения должны выбираться и быть адаптированы к контексту характеристик проекта и продукта. Соответствующая модель жизненного цикла разработки должна быть выбрана и адаптирована на основе цели проекта, типа разрабатываемого продукта, бизнес-приоритетов (например, срок вывода продукта на рынок), и выявленных рисков продукта и проекта. Например, небольшую внутреннюю административную систему следует разрабатывать и тестировать иначе, нежели критически важную для безопасности систему, например, систему управления тормозами автомобиля. Как другой пример, в некоторых случаях организационные и культурные аспекты могут осложнять общение между членами команды, что может препятствовать итеративной разработке. В зависимости от контекста проекта может потребоваться объединение или реорганизация уровней тестирования и/или тестовых активностей. Например, для интеграции готового коммерческого решения в более крупную систему покупатель этого решения может выполнить тестирование возможности взаимодействия на уровне системного интеграционного тестирования (например, интеграцию с инфраструктурой и другими системами) и на уровне приемочного тестирования (функциональное и/или нефункциональное, наряду с пользовательским приемочным и эксплуатационным приемочным тестированием). Смотрите раздел 2.2 для рассмотрения уровней тестирования и раздел 2.3 для рассмотрения типов тестирования. Кроме этого, сами модели жизненного цикла разработки могут сочетаться одна с другой. Например, V-модель может быть использована для разработки и тестирования систем серверного уровня и их интеграции, тогда как методология гибкой разработки может быть использована для разработки и тестирования пользовательского интерфейса (ПИ) и функциональности. На ранних стадиях проекта может быть использовано прототипирование, с переходом на инкрементальную модель разработки после завершения экспериментальной фазы. Системы с общим названием «Интернет вещей», которые состоят из множества различных объектов, таких как устройства, продукты и сервисы, часто разрабатываются с применением разных моделей жизненного цикла разработки для каждого объекта. Это ведет к определенной сложности для разработки версий таких систем. Кроме того, сильный акцент делается уже на поздние фазы жизненного цикла, после внедрения (например, фазы использования, обновления и вывода из эксплуатации). 2.2 Уровни тестирования Уровни тестирования – это группы активностей тестирования, которые организуются и управляются как единое целое. Каждый уровень тестирования — это реализация процесса тестирования, состоящего из мероприятий, описанных в разделе 1.4, и исполняемого в отношении ПО, находящегося на конкретном уровне разработки, начиная с отдельных модулей и компонентов и заканчивая целыми системами или, где применимо, группами систем. Уровни тестирования связаны с другими активностями в рамках жизненного цикла разработки. Уровни, используемые в данной программе обучения, следующие: Компонентное тестирование Интеграционное тестирование Системное тестирование Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 32 of 94 24 февраля 2019 © International Software Testing Qualifications Board Приемочное тестирование Уровни тестирования характеризуются следующими признаками: Конкретные цели Базис тестирования, на который ссылаются для получения тестовых сценариев Объект тестирования (то есть то, что будет протестировано) Типичные дефекты и отказы Специфические подходы и зоны ответственности Для каждого уровня тестирования требуется подходящая среда тестирования. Например, при приемочном тестировании идеально использовать окружение, максимально приближенное к реальному. В тоже время при компонентном тестировании разработчики обычно используют собственную среду разработки. 2.2.1 Компонентное тестирование Цели компонентного тестирования Компонентное тестирование (также известное как модульное тестирование) фокусируется на компонентах, которые могут быть проверены отдельно. Цели компонентного тестирования включают: Снижение риска Проверку, соответствует ли функциональное и нефункциональное поведение компонентов установленным проектным требованиям Укрепление уверенности в качестве компонента Обнаружение дефектов в компоненте Предотвращение пропуска дефектов на более высокие уровни тестирования В некоторых случаях, особенно в инкрементных и итеративных моделях разработки (например, гибкой методологии разработки), где изменения кода происходят непрерывно, автоматизированные регрессионные компонентные тесты играют ключевую роль в создании уверенности в том, что изменения не повредили существующий функционал. Компонентное тестирование часто выполняется изолированно от остальной системы, в зависимости от модели жизненного цикла разработки программного обеспечения и системы, для которой могут потребоваться макеты разрабатываемых объектов, виртуализация служб, стенды, заглушки и драйверы. Компонентное тестирование может охватывать как функциональные (например, правильность вычислений), так и нефункциональные характеристики (например, поиск утечек памяти) и структурные свойства (например, тестирование решений). Базис тестирования Примеры рабочих продуктов, которые могут использоваться в качестве базиса тестирования для компонентного тестирования, включают: Детальный дизайн Код Модель данных Спецификации компонента Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 33 of 94 24 февраля 2019 © International Software Testing Qualifications Board Объекты тестирования Типичными объектами для компонентного тестирования являются: Компоненты, модули Код и структуры данных Классы Модули БД Типичные дефекты и отказы Примеры типичных дефектов и отказов при компонентном тестировании включают: Неправильная работа функциональности (например, не так, как описано в спецификации) Проблемы с потоками данных Неправильные код и логика Дефекты обычно исправляются, как только они обнаруживаются, часто без оформления, в соответствующей системе управления дефектами. Однако, когда разработчики оформляют отчеты о дефектах, создается важная информация для анализа первопричин дефектов и улучшения процесса. Специфические подходы и зоны ответственности Компонентное тестирование обычно выполняется разработчиком, который написал код, но это как минимум требует доступа к тестируемому коду. Разработчики могут чередовать разработку компонентов с обнаружением и устранением дефектов. Разработчики часто пишут и выполняют тесты после написания кода для компонента. Тем не менее, написание автоматизированных тестовых сценариев для компонентов может предшествовать написанию кода приложения, особенно в методологии гибкой разработки. Например, рассмотрим разработку на основе тестов. Разработка на основе тестов является высоко итеративной, и основана на циклах разработки автоматизированных тестов, затем построении и интеграции небольших фрагментов кода, а уже после – выполнении компонентного тестирования, исправлении проблем и рефакторинга кода. Этот процесс продолжается до тех пор, пока компонент не будет полностью собран и все компонентные тесты не пройдут успешно. Разработка на основе тестов является примером подхода «сначала тестирование». Хотя разработка на основе тестов берет начало в методологии экстремального программирования, она распространилась на другие формы гибких методологий разработки, а также на последовательные жизненные циклы (см. программу ISTQB Базовый уровень. Тестировщик в сфере Гибких методологий). 2.2.2 Интеграционное тестирование Цели интеграционного тестирования Интеграционное тестирование фокусируется на взаимодействии между компонентами или системами. Цели интеграционного тестирования включают: Снижение риска Проверка, соответствует ли функциональное и нефункциональное поведение интерфейсов установленным проектным требованиям Повышение уверенности в качестве интерфейсов Сертифицированный тестировщик Программа обучения базового уровня International Software Testing Qualifications Board Версия 2018 Страница 34 of 94 24 февраля 2019 © International Software Testing Qualifications Board Обнаружение дефектов (которые могут быть в самих интерфейсах или внутри компонентов или систем) Предотвращение пропуска дефектов на более высокие уровни тестирования Как и при компонентном тестировании, в некоторых случаях автоматизированные регрессионные интеграционные тесты поддерживают уверенность в том, что изменения не повредили существующие интерфейсы, компоненты или системы. В этой учебной программе описаны два разных уровня интеграционного тестирования, которые могут выполняться на тестовых объектах различного размера следующим образом: Компонентное интеграционное тестирование фокусируется на взаимодействиях и интерфейсах между интегрированными компонентами. Оно выполняется после компонентного и, как правило, автоматизируется. При итеративной и инкрементальной разработке компонентное интеграционное тестирование обычно является частью процесса непрерывной интеграции Системное интеграционное тестирование фокусируется на взаимодействиях и интерфейсах между системами, пакетами и микросервисами. Системное интеграционное тестирование также может охватывать взаимодействия и интерфейсы, предоставляемые сторонними организациями (например, веб-сервисы). В этом случае организация-разработчик не контролирует внешние интерфейсы, которые могут создавать различные сложности для тестирования (например, проверяя, что блокирующие тесты дефекты устранены в коде сторонней организации, подготавливая тестовые среды и т. д.). Системное интеграционное тестирование может быть выполнено после системного тестирования или параллельно с выполняемыми активностями по системному тестированию (как в последовательной разработке, так и в итеративной и инкрементальной разработке). |