ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР

56920-

2016/

ISO/IEC/IEEE

29119-1:2013

СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ

Тестирование программного обеспечения

Часть 1

Понятия и определения

ISO/IEC/IEEE 29119-1:2013 Software and systems engineering — Software testing — Part 1: Concepts and definitions (IDT)

Издание официальное

Предисловие

1    ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 мая 2016 г. № 331-ст

4    Настоящий стандарт идентичен международному стандарту ISO/IEC/IEEE 29119-1:2013 «Программная и системная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения» (ISO/IEC/IEEE 29119-1:2013 «Software and systems engineering — Software testing — Part 1: Concepts and definitions»).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (пункт 3.5)

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2016

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

4.57    Процесс Разработки и Реализации Тестирования (Test Design and Implementation Process): Процесс тестирования для получения и определения контрольных примеров и процедур тестирования.

4.58    Спецификация Проекта Тестирования (Test Design Specification): Документ, определяющий функции, которые будут проверены, и соответствующие тестовые условия.

4.59    методика проектирования тестирования (test design technique): Действия, понятия, процессы и шаблоны, необходимые для создания модели тестирования, которая используется при определении тестовых условий элемента тестирования, для получения соответствующих элементов тестового покрытия, а далее для разработки или выбора контрольных примеров.

4.60    тестовая среда (test environment): Различные средства, аппаратное и программное обеспечение, встроенное микропрограммное обеспечение, процедуры и документация, предназначенные или используемые для выполнения тестирования программного обеспечения.

Примечание — Тестовая среда может содержать в себе другие среды, необходимые для выполнения конкретных подпроцессов тестирования (например, тестовая среда объекта, среда теста производительности и т. д.).

4.61    Отчет о Готовности Тестовой Среды (Test Environment Readiness Report): Документ, описывающий выполнение всех требований к тестовой среде.

4.62    Требования к Тестовой Среде (Test Environment Requirements): Описание необходимых свойств тестовой среды.

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

4.63    Процесс Установки Тестовой Среды (Test Environment Set-up Process): Процесс динамического тестирования для установки и поддержания требуемой тестовой среды.

4.64    выполнение теста (test execution): Процесс выполнения теста на элементе тестирования, приводящий к фактическим результатам.

4.65    Журнал Выполнения Теста (Test Execution Log): Документ, в который записываются детали выполнения одной или более процедур тестирования.

4.66    Процесс Выполнения Теста (Test Execution Process): Процесс динамического тестирования для выполнения процедур тестирования, созданных в процессе разработки и реализации тестирования в подготовленной тестовой среде, и записи результатов.

4.67    Процесс Отчетности об Инцидентах Тестирования (Testlncident Reporting Process): Процесс динамического тестирования для создания отчетов для соответствующих заинтересованных сторон о проблемах, требующих дальнейших действий, которые были идентифицированы во время процесса выполнения теста.

4.68    элемент тестирования (test item): Рабочий продукт, который является объектом тестирования.

Пример — Система, элемент программного обеспечения, документ требований, спецификация проекта, руководство пользователя.

4.69    уровень тестирования (test level): Конкретная реализация подпроцесса тестирования.

Пример — Как подпроцессы тестирования можно рассматривать следующие общие уровни тестирования: уровень/подпроцесс покомпонентного тестирования, уровень/подпроцесс интеграционного теста, уровень/подпроцесс тестирования системы, уровень/подпроцесс приемочного испытания.

Примечание — Синонимом уровня тестирования является фаза тестирования.

4.70    менеджмент тестирования (test management): Планирование, составление графика, оценка, мониторинг, отчетность, управление и выполнение действий по тестированию.

4.71    Процесс Менеджмента Тестирования (Test Management Process): Процесс тестирования, содержащий подпроцессы, необходимые для менеджмента проекта тестирования.

Примечание — См. процесс планирования тестирования, процесс мониторинга и управления тестированием, процесс завершения тестирования.

4.72    Процесс Мониторинга и Управления Тестированием (Test Monitoring and Control Process): Процесс менеджмента тестирования для обеспечения соответствия выполнения тестирования плану тестирования и организационным спецификациям тестирования.

4.73    объект тестирования (test object): См. термин «элемент тестирования» согласно 4.68.

6

ГОСТ Р 56920-2016

4.74    фаза тестирования (test phase): Определенная реализация подпроцесса тестирования.

Примечание — Фазы тестирования означают то же, что и уровни тестирования, поэтому в примерах фазы тестирования совпадают с уровнями тестирования (например, фаза/подпроцесс тестирования системы).

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

Примечания

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

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

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

4.76    Процесс Планирования Тестирования (Test Planning Process): Процесс менеджмента тестирования, используемый для выполнения планирования тестирования и разработки планов тестирования.

4.77    методика тестирования (test practice): Концептуальная основа, применимая к организационным процессам тестирования, процессам менеджмента тестирования и/или процессам динамического тестирования,чтобы упростить тестирование.

Примечание — Методики тестирования иногда называются подходом к тестированию.

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

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

4.79    Спецификация Процедуры Тестирования (Test Procedure Specification): Документ, определяющий одну или более процедур тестирования, представляющих собой наборы контрольных примеров, которые будут выполняться с определенной целью.

Примечания

1    Контрольные примеры в наборе тестов перечислены в порядке, требуемом в процедуре тестирования.

2    Ее также называют сценарием ручного тестирования. Спецификацию процедуры тестирования для автоматизированного тестового прогона обычно называют сценарием тестирования.

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

Пример — Процесс тестирования для определенного проекта может состоять из множества подпроцессов, например подпроцесса тестирования системы, подпроцесса планирования тестирования (часть большего процесса менеджмента тестирования) или подпроцесса статического тестирования.

4.81    тестовое требование (test requirement): См. термин «тестовое условие» согласно 4.52.

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

4.83    сценарий тестирования (test script): Спецификация процедуры тестирования для ручного или автоматизированного тестирования.

4.84    набор тестов (test set): Один или совокупность нескольких контрольных примеров с общими ограничениями на их выполнение.

Пример — Определенная тестовая среда, специализированные знания проблемной области или определенная цель.

7

4.85    спецификация тестирования (test specification): Подробная документация проекта тестирования, контрольных примеров и процедур тестирования для конкретного элемента тестирования.

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

4.86    Отчет о Ходе Тестирования (Test Status Report): Отчет, предоставляющий информацию о состоянии тестирования, которое выполняется в указанный отчетный период.

4.87    стратегия тестирования (test strategy): Часть Плана Тестирования, в которой описан подход к тестированию определенного проекта тестирования или процессам и подпроцессам тестирования.

Примечания

1    Стратегия тестирования — это производная от Организационной Стратегии Тестирования.

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

4.88    подпроцесс тестирования (test sub-process): Процессы менеджмента тестирования и процессы динамического (и статического) тестирования, используемые для выполнения определенного уровня тестирования (например, тестирование системы, приемочные испытания) или определенного типа тестирования (например, тестирование удобства использования, тестирование производительности) обычно в контексте полного процесса тестирования для проекта тестирования.

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

4.89    методика тестирования (test technique): См. термин «метод проектирования тестирования» согласно 4.59.

4.90    матрица прослеживаемости тестирования (test traceability matrix): Документ, электронная таблица или другой автоматизированный инструмент, используемые для идентификации в документации и программном обеспечении связанных элементов, таких как требования соответствующего

тестирования.

Примечания

1    Также известна как матрица перекрестных ссылок верификации, матрица проверки требований, таблица верификации требований и др.

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

4.91    тип тестирования (test type): Совокупность тестирующих действий, которая фокусируется на определенных показателях качества.

Примечание — Тип тестирования может быть выполнен одиночным подпроцессом тестирования или несколькими подпроцессами тестирования (например, тестирование производительности, выполненное в ходе подпроцесса покомпонентного тестирования и также выполненное в ходе подпроцесса тестирования системы).

Примеры — Тестирование защищенности, функциональное тестирование, тестирование удобства использования и тестирование производительности.

4.92    тестирование (testing): Набор операций, проводимых для обеспечения выявления и/или оценки свойств одного или более элементов тестирования.

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

4.93    средства тестирования (testware): Артефакты, произведенные во время процесса тестирования, требуемые для планирования, разработки и выполнения тестирования.

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

4.94    тестирование без сценария (unscripted testing): Динамическое тестирование, в котором действия тестера определены инструкциями, записанными в контрольном примере.

8

ГОСТ Р 56920-2016

4.95    объемное тестирование (volume testing): Тип тестирования уровня производительности, проводимого для оценки способности элемента тестирования обработать определенные объемы данных (обычно равных или близких к максимальным указанным потенциальным возможностям) с точки зрения потенциальных возможностей пропускной способности, емкости памяти или того и другого.

4.96    тестирование методом «белого ящика» (white box testing): См. термин «тестирование на основе структуры» согласно 4.45.

5 Понятия тестирования программного обеспечения

5.1 Введение в тестирование программного обеспечения

Необходимость тестирования программного обеспечения может быть продиктована следующими условиями:

-    лица, принимающие решения, запрашивают информацию о показателях качества элемента(ов) тестирования;

-    проверяемый(ые) элемент(ы) тестирования не всегда делает то, что от него (них) ожидается;

-    необходимо произвести верификацию проверяемого(ых) элемента(ов) тестирования;

-    необходимо произвести валидацию проверяемого(ых) элемента(ов) тестирования и/или

-    необходимо провести оценку элемента(ов) тестирования по всему жизненному циклу разработки программного обеспечения и систем.

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

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

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

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

Вышеупомянутая информация может использоваться в нескольких целях, включая:

-    улучшение элемента тестирования путем устранения дефектов;

-    улучшение управленческих решений, предоставляя как основание для решений информацию о качестве и рисках;

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

Качество продукта имеет много аспектов, включая соответствие спецификациям, отсутствие дефектов и удовлетворение продукта требованиям пользователей. В ИСО/МЭК 25010 «Модели качества систем и программного обеспечения» определено восемь показателей качества, которые могут быть измерены или оценены путем тестирования (см. 5.5.3).

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

9

Основные положения тестирования заключаются в следующем:

-    тестирование — это процесс, представляющий собой совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы. Цель настоящего стандарта состоит в том, чтобы представить и описать общие процессы тестирования (дополнительная информация доступна в ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования»);

-    Организационный Процесс Тестирования устанавливает и поддерживает политики тестирования и стратегии тестирования, которые повсеместно применяются в проектах и функциях организации;

-    тестирование необходимо планировать, контролировать и управлять им. Процессы тестирования, описанные в ИСО/МЭК/ИИЭР 29119-2, включают в себя процесс менеджмента тестирования и могут быть применены к тестированию во всех жизненных циклах разработки и менеджменте исследовательского тестирования;

-    процессы и подпроцессы тестирования применимы для любой фазы или уровня тестирования (например, тестирование системы) и для любого типа тестирования (например, тестирование производительности);

-    тестирование предполагает исследование элемента тестирования;

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

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

-    динамическое тестирование представляет собой нечто большее, чем «просто» выполнение исполнимых элементов тестирования, сюда входят также как действия подготовки, так и последующие действия. Процессы динамического тестирования, описанные в ИСО/МЭК/ИИЭР 29119-2, охватывают каждое из действий, которые будут выполняться в ходе динамического тестирования;

-    верификация — это подтверждение путем представления объективных доказательств выполнения данным рабочим элементом установленных требований;

-    валидация демонстрирует, что рабочий элемент может использоваться пользователями для решения определенных ими задач;

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

5.1.1    Роль тестирования в верификации и валидации

В настоящем стандарте рассматриваются только некоторые действия верификации и валидации. В частности, рассматривается тестирование программного обеспечения, которое является основным действием при верификации и валидации. Такие стандарты, как ИСО/МЭК 12207 и ИИЭР 1012, рассматривают и другие действия верификации или валидации. Настоящий стандарт ориентирован только на тестирование и в нем не рассматриваются другие действия валидации и верификации (например, анализ валидации и верификации, формальные методы). Для обеспечения полной валидации и верификации продукта организация в составе своей комплексной технической программы должна использовать настоящий стандарт совместно с другими стандартами. Иерархия действий верификации и валидации приводится в приложении А.

5.1.2    Исчерпывающее тестирование

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

ГОСТ Р 56920-2016

5.1.3 Тестирование как эвристика

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

5.2 Тестирование программного обеспечения в организационном контексте и контексте

проекта

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

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

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

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

11

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

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

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

План Тестирования Проекта описывает общую стратегию тестирования и процессы тестирования, которые будут использоваться. Он устанавливает контекст тестирования проекта, определяя цели, методы, ресурсы и расписание. Кроме того, он идентифицирует применимые подпроцессы тестирования (например, тестирование системы, тестирование производительности). Идентифицированные подпроцессы далее расписываются в плане тестирования подпроцесса (например, План

Ограничения Тестирование руководствуется    Разработано

Рисунок 1 — Иерархическая схема тестирования

ГОСТ Р 56920-2016

Тестирования Системы, План Теста Производительности). План тестирования также определяет надлежащий метод проектирования тестирования (статическое или динамическое), необходимый для выполнения подпроцесса тестирования, требуемого конкретным планом. Более подробно методы проектирования тестирования описаны в 5.5.6 и ИСО/МЭК/ИИЭР 29119-4.

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

План тестирования включает в себя стратегию тестирования (см. раздел 6). Стратегии тестирования настраиваются на конкретный контекст проекта тестирования. Стратегии тестирования должны соотноситься конкретными элементами, показанными на рисунке 1 и определенными в других частях серии стандартов ИСО/МЭК/ИИЭР 29119. Каждый план тестирования (и стратегия) будет уникален, отличаясь от других: подпроцессами тестирования, уровнями автоматизации, совокупностью методик проектирования тестирования, критериями завершения теста, их планированием и выделением ресурсов. Планирование и выбор этих аспектов начинаются на ранней стадии проекта и будут продолжаться в течение жизненного цикла тестирования, влияя как фактор на изменение риска. Следует ожидать, что многие части плана и стратегии тестирования изменятся, хотя изменения будут, очевидно, в пределах ограничений проекта, организации или регулирующих норм.

Взаимосвязи между общим процессом тестирования, общими подпроцессами тестирования, уровнями/фазами тестирования и типами тестирования более подробно показаны на рисунке 2. Рисунок показывает реализацию общих подпроцессов тестирования на определенных уровнях тестирования и в соответствии с типом тестирования. Общий подпроцесс тестирования может быть реализован:

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

Процесс тестирования
Г
1_
	Подпроцесс тестирования

Тестирование Тестирование компонентов производительности Тестирование Тестирование интеграции защищенности Тестирование Функциональное системы тестирование Приемочное Тестирование тестирование удобства использования

Рисунок 2 — Взаимосвязи между общим подпроцессом тестирования, уровнями тестирования и типами тестирования

13

-    как тестирование определенного типа. То есть каждый тип тестирования представляет собой определенное приложение общего подпроцесса тестирования (например, тестирование производительности, тестирование удобства использования);

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

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

На рисунке 2 в деталях показаны связи между типами тестирования и показателями качества (как определено в ИСО/МЭК 25010 «Модели качества систем и программного обеспечения»). Каждый тип тестирования ориентирован на один определенный показатель качества. Более подробно связи между типами тестирования и показателями качества рассматриваются в 5.5.3.

5.2.1 Процесс тестирования

В настоящем стандарте используется трехуровневая модель процесса, подробно описанная в ИСО/МЭК/ИИЭР 29119-2 и показанная в общем виде на рисунке 3. Модель процесса начинается с организационного управления спецификациями тестирования высокого уровня (организационными спецификациями), такими как Организационная Политика Тестирования и Организационная Стратегия Тестирования. Средний уровень показывает менеджмент тестирования (менеджмент тестирования проекта, менеджмент фазы тестирования, менеджмент типа тестирования), в то время как нижний уровень определяет множество процессов тестирования, используемых в динамическом тестировании.

Трехуровневая модель процесса показана на рисунке 3.

Рисунок 3 — Многоуровневая связь процессов тестирования

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

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

Менеджмент выполняемого тестирования определяется Процессами Менеджмента Тестирования. На основе анализа идентифицированных рисков и ограничений проекта и с учетом Организационной Стратегии Тестирования разрабатывается связанная с проектом стратегия тестирования. Эта стратегия разрабатывается с точки зрения определения необходимого статического и динамического тестирования, укомплектованности персоналом, баланса заданных ограничений (ресурсы и время) с

ГОСТ Р 56920-2016

Содержание

1    Область применения............................................1

2    Соответствие................................................1

3    Нормативные ссылки............................................1

4    Термины и определения..........................................1

5    Понятия тестирования программного обеспечения...........................9

5.1    Введение в тестирование программного обеспечения.......................9

5.2    Тестирование программного обеспечения в организационном контексте и контексте

проекта................................................11

5.3    Общие процессы тестирования    в жизненном цикле программного обеспечения........16

5.4    Тестирование на базе рисков....................................20

5.5    Подпроцесс тестирования......................................21

5.6    Методики тестирования.......................................26

5.7    Автоматизация в тестировании...................................29

5.8    Управление дефектами.......................................29

Приложение А (справочное) Роль тестирования в верификации и валидации.............30

Приложение В (справочное) Метрики и показатели............................31

Приложение С (справочное) Тестирование в различных моделях жизненного цикла.........32

Приложение D (справочное) Примеры подпроцессов тестирования в деталях.............38

Приложение Е (справочное) Роли и обязанности в тестировании....................46

Библиография................................................48

5.3 Общие процессы тестирования в жизненном цикле программного обеспечения

Программное обеспечение имеет ожидаемый жизненный цикл от начальной его концепции до возможного прекращения его использования. Тестирование программного обеспечения имеет место в более широком контексте разработки и сопровождения программного обеспечения. В 5.3 в качестве примера рассмотрен жизненный цикл разработки программного обеспечения и некоторые связи между его подпроцессами и процессами тестирования. В ИСО/МЭК 12207:2008 подробно рассмотрены жизненные циклы программного обеспечения. В ИСО/МЭК 15288 подробно рассмотрены процессы жизненного цикла системы. Пример жизненного цикла системы показан на рисунке 6.

> ' >

Текущая поддержка

Проект разработки (начальный) Проект разработки Проект разработки (обновление) Проект разработки

Рисунок 6 — Пример жизненного цикла программного обеспечения

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

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

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

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

Тестирование может выполняться для оценки удовлетворения бизнес-требований к приобретаемому программному обеспечению. Основы оценки и тестирования приобретаемого готового коммерческого программного обеспечения (COTS) можно найти в ИСО/МЭК 25051.

5.3.1 Подпроцессы проекта разработки и их результаты

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

Введение

Международная организация по стандартизации (ИСО) и Международная электротехническая комиссия (МЭК) образуют специализированную систему для всемирной стандартизации. Национальные органы по стандартизации, которые являются членами ИСО или МЭК, участвуют в разработке международных стандартов через технические комитеты, созданные соответствующей организацией для определенных областей технической деятельности. Технические комитеты ИСО и МЭК сотрудничают в сферах, представляющих взаимный интерес. Другие международные правительственные и неправительственные организации, связанные с ИСО и МЭК, также принимают участие в работе по разработке стандартов. В сфере информационной технологии ИСО и МЭК учредили совместный технический комитет ИСО/МЭК СТК 1.

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

Международные стандарты разрабатывают в соответствии с правилами, приведенными в Директивах ИСО/МЭК, часть 2.

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

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

ИСО/МЭК/ИИЭР 29119-1 был подготовлен Подкомитетом 7 «Системная и программная инженерия» совместного технического комитета ИСО/МЭК СТК 1 «Информационные технологии» в сотрудничестве с комитетом по стандартам системной и программной инженерии компьютерного сообщества ИИЭР в соответствии с организационным соглашением о партнерском сотрудничестве по разработке стандартов между ИСО и ИИЭР.

Серия стандартов ИСО/МЭК/ИИЭР 29119 под общим названием «Системная и программная инженерия. Тестирование программного обеспечения» состоит из следующих частей:

-    Часть 1. Понятия и определения;

-    Часть 2. Процессы тестирования;

-    Часть 3. Документация тестирования;

-    Часть 4. Методики тестирования.

Цель создания серии стандартов ИСО/МЭК/ИИЭР 29119 «Тестирование программного обеспечения» состоит в том, чтобы определить на международном уровне согласованную совокупность стандартов, которая может использоваться любой организацией при выполнении различных форм тестирования программного обеспечения.

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

ГОСТ Р 56920-2016

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

Настоящий стандарт предоставляет словарь терминов, используемых в серии стандартов ИСО/МЭК/ИИЭР 29119, который упрощает применение других стандартов этой серии, и приводит примеры применения их на практике. Настоящий стандарт предоставляет понятия тестирования программного обеспечения и способы применения тестирования программного обеспечения и является руководством для других частей ИСО/МЭК/ИИЭР 29119.

В настоящем стандарте представлены общие понятия тестирования программного обеспечения. Описывается роль тестирования программного обеспечения в организационном контексте и контексте проекта. Тестирование программного обеспечения рассматривается в контексте общего жизненного цикла программного обеспечения. Представлен способ, который позволяет устанавливать процессы и подпроцессы тестирования программного обеспечения для определенных элементов тестирования или с определенными целями. Рассматривается, как тестирование программного обеспечения вписывается в различные модели жизненного цикла. Демонстрируется использование различных методов планирования тестирования, а также то, как может быть использована автоматизация для поддержки тестирования. Обсуждается роль тестирования в управлении дефектами. Приложение А описывает роль тестирования в более широкой предметной области верификации и валидации. Приложение В представляет краткое введение в метрики, используемые для мониторинга и управления тестированием. Приложение С содержит ряд примеров, показывающих, как применить настоящий стандарт в различных моделях жизненного цикла. Приложение D предоставляет примеры подпроцессов тестирования в деталях. Приложение Е предоставляет дополнительную информацию о ролях и обязанностях, с которыми обычно имеют дело группы тестирования и независимые тестеры. В конце стандарта представлен элемент «Библиография».

Следует обратить внимание на то, что заглавные буквы используются в настоящем стандарте в названиях процессов и документов, которые определены в ИСО/МЭК/ИИЭР 29119-2 и ИСО/МЭК/ИИЭР 29119-3 (например, Процесс Планирования Тестирования, План Тестирования), тогда как строчные буквы используются для документов, являющихся частями других документов (например, стратегия тестирования проекта — элемент Плана Тестирования Проекта).

Модель процесса тестирования, на которой основывается серия стандартов ИСО/МЭК/ИИЭР 29119 «Тестирование программного обеспечения», подробно описана в ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования». ИСО/МЭК/ИИЭР 29119-2 рассматривает процессы тестирования программного обеспечения на организационном уровне, уровне управления тестированием и уровнях динамического тестирования. Тестирование — это основной подход к обработке рисков в разработке программного обеспечения. Этот стандарт определяет подход к тестированию, базирующийся на рисках. Тестирование на базе рисков — это рекомендуемый подход к разработке стратегии и менеджмента тестирования, который позволяет расставлять приоритеты и акценты в тестировании.

ИСО/МЭК/ИИЭР 29119-3 «Документация тестирования» определяет шаблоны и примеры документации тестирования. ИСО/МЭК/ИИЭР 29119-4 «Методики тестирования» определяет методы тестирования программного обеспечения, которые могут быть использованы входе тестирования.

В целом серия стандартов ИСО/МЭК/ИИЭР 29119 дает возможность заинтересованным сторонам контролировать и выполнять тестирование программного обеспечения в любой организации.

V

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ

Тестирование программного обеспечения Часть 1 Понятия и определения

Software and systems engineering. Software testing. Part 1. Concepts and definitions

Дата введения — 2017—06—01

1    Область применения

В настоящем стандарте представлены определения и понятия тестирования программного обеспечения. Это представление обеспечивает идентификацию терминов и ключевых концепций тестирования, необходимых для правильного толкования серии стандартов ИСО/МЭК/ИИЭР 29119.

2    Соответствие

Настоящий стандарт носит информативный характер и не требует какого-либо соответствия.

Серия стандартов ИСО/МЭК/ИИЭР 29119 «Тестирование программного обеспечения» содержит три стандарта, которые могут потребовать соответствия:

-    Процессы тестирования:

-    Документация тестирования:

-    Методики тестирования.

Соответствие рассмотрено в ИСО/МЭК/ИИЭР 29119-2, ИСО/МЭК/ИИЭР 29119-3 и ИСО/МЭК/ИИЭР 29119-4.

3    Нормативные ссылки

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

4    Термины и определения

В настоящем стандарте используются термины и определения, приведенные в ИСО/МЭК/ИИЭР 24765, а также перечисленные ниже термины с соответствующими определениями.

Примечание — Нижеследующие термины и определения представлены для понимания и удобства восприятия частей 1,2, 3 и 4 серии стандартов ИСО/МЭК/ИИЭР 29119 «Тестирование программного обеспечения». Некоторые термины, определенные в настоящем стандарте, не используются непосредственно в нем, а применяются только в других частях серии ИСО/МЭК/ИИЭР 29119. В этом разделе представлены только термины, критически важные для понимания этих стандартов. Представление полного списка терминов тестирования не является целью данного раздела. Для терминов, не определенных в этом разделе, следует пользоваться словарем системной и программной инженерии ИСО/МЭК/ИИЭР 24765. Он доступен на веб-сайте: http://www.computer.org/sevocab.

Издание официальное

4.1    тестирование доступности (accessibility testing): Тип тестирования удобства использования, предназначенный для оценки степени возможности управления элементом тестирования пользователями с самыми разными характеристиками и способностями.

4.2    фактические результаты (actual results): Совокупность поведения или условий элемента тестирования, или совокупность условий, связанных данных или тестовой среды, полученные в результате выполнения теста.

Пример — Вывод на аппаратные средства, изменения в данных, отчеты и отправленные информационные сообщения.

4.3    тестирование копирования и восстановления (backup and recovery testing): Тип тестирования надежности, который измеряет степень состояния системы, до которой в случае отказа может быть произведено восстановление из резервной копии при указанных параметрах времени, стоимости, полноты и точности.

4.4    тестирование методом «черного ящика» (black-box testing): См. термин «тестирование на основе спецификации» согласно 4.39.

4.5    тестирование потенциальных возможностей (capacity testing): Тип тестирования уровня производительности для оценки уровня, при котором с увеличением нагрузки (числа пользователей, транзакций, элементов данных и т.д.) элемент тестирования подвергается угрозе не обеспечивать требуемую производительность.

4.6    тестирование совместимости (compatibility testing): Тип тестирования, который измеряет степень того, насколько удовлетворительно элемент тестирования может функционировать параллельно с другими независимыми продуктами в общей среде (сосуществование) и, по мере необходимости, обменивается информацией с другими системами или компонентами (функциональная совместимость).

4.7    элемент покрытия (coverage item): См. термин «элемент тестового покрытия» согласно 4.54.

4.8    решение (decision): Тип оператора выбора одного из двух или более возможных результатов для определения выбора конкретного набора действий.

4.9    динамическое тестирование (dynamic testing): Тестирование, при котором требуется выполнение элемента тестирования.

4.10    тестирование износостойкости (endurance testing): Тип тестирования уровня производительности для определения того, может ли элемент тестирования постоянно выдерживать требуемую загрузку в течение установленного периода времени.

4.11    раздел эквивалентности (equivalence partition): Подмножество области значений переменной или совокупности переменных внутри элемента тестирования или на его интерфейсах такое, что можно обоснованно ожидать того, что все значения подмножества будут обработаны элементом тестирования подобным образом (то есть они могут считаться «эквивалентными»),

4.12    покрытие раздела эквивалентности (equivalence partition coverage): Доля идентифицированных разделов эквивалентности элемента тестирования, которая покрывается набором тестов.

Примечание — В большинстве случаев идентификация разделов эквивалентности субъективна (особенно в разбиении «недопустимых» разделов); таким образом, окончательный подсчет числа разделов эквивалентности для элемента тестирования может быть невозможен.

4.13    разбиение эквивалентности (equivalence partitioning): Метод проектирования тестирования, при котором контрольные примеры разработаны таким образом, чтобы проверить разделы эквивалентности с помощью одного или более представительных элементов каждого раздела.

4.14    предположение об ошибках (error guessing): Метод проектирования тестирования, в котором контрольные примеры получены на основе знаний тестера о прошлых отказах или общих знаний о видах отказа.

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

4.15    ожидаемые результаты (expected results): Характерное предсказанное поведение элемента тестирования при указанных условиях на основе его спецификации или другого источника.

4.16    исследовательское тестирование (exploratory testing): Тестирование, основанное на опыте, при котором тестер спонтанно разрабатывает и выполняет тестирования на основе существующих соответствующих знаний тестера, предшествующих исследований элемента тестирования (включая и результаты предыдущих тестирований) и эвристических «эмпирических правил» для общего поведения программного обеспечения и типов отказа.

2

ГОСТ Р 56920-2016

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

4.17    набор функций (feature set): Совокупность, в которую входят тестовые условия проверяемого элемента и могут быть включены риски, требования, функции, модели и т. д.

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

4.18    Отчет об Инциденте (Incident Report): Документация по инциденту о его проявлении, природе и состоянии.

4.19    тестирование устанавливаемости (installability testing): Тип тестирования переносимости для оценки того, могут ли должным образом элемент тестирования или совокупность элементов тестирования быть установлены во всех указанных средах.

4.20    нагрузочное тестирование (load testing): Тип тестирования уровня производительности, проводимого для оценки поведения элемента тестирования при ожидаемых условиях переменной загрузки, обычно для ожидаемых условий низкого, типичного и пикового использования.

4.21    тестирование сопровождаемости (maintainability testing): Тип тестирования, проводимого для оценки степени эффективности и продуктивности возможных изменений элемента тестирования.

4.22    Организационная Политика Тестирования (Organizational Test Policy): Руководящий документ, в котором описаны назначение, цели, полная предметная область применения тестирования в организации и определено, почему выполняется тестирование и что ожидается получить в результате.

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

4.23    Организационный Процесс Тестирования (Organizational Test Process): Процесс тестирования для разработки и управления организационными спецификациями тестирования.

4.24    Организационная Спецификация Тестирования (Organizational Test Specification): Документ, в котором представлена информация о тестировании для организации, то есть информация, которая не специфична для проекта.

Пример — Наиболее общими примерами Организационной Спецификации Тестирования являются Организационная Политика Тестирования и Организационная Стратегия Тестирования.

4.25    Организационная Стратегия Тестирования (Organizational Test Strategy): Документ, в котором изложены универсальные требования к тестированиям, которые будут выполняться для всех проектов организации, а также подробности того, как должно производиться тестирование.

Примечания

1    Организационная Стратегия Тестирования согласована с Организационной Политикой Тестирования.

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

4.26    критерий успешного/неуспешного прохождения (pass/fail criteria): Правила решения, используемые для определения того, прошли ли тестирование элемент тестирования или функция элемента тестирования или перестали работать после тестирования.

4.27    тестирование производительности (performance testing): Тип тестирования, проводимого для оценки степени, в которой элемент тестирования выполняет свои определенные функции при заданных ограничениях времени и других ресурсах.

4.28    тестирование переносимости (portability testing): Тип тестирования, проводимого для оценки простоты переноса элемента тестирования из одних аппаратных средств или программной среды в другие, включая уровень его изменений, необходимых для выполнения в средах различных типов.

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

4.30    риск продукта (product risk): Риск того, что продукт может иметь дефект в некотором определенном аспекте его функций, качества или структуры.

4.31    риск проекта (project risk): Риск, относящийся к менеджменту проекта.

3

Пример — Отсутствие укомплектования персоналом, строгие крайние сроки, изменения требований.

4.32    регрессионное тестирование (regression testing): Тестирование после изменений элемента тестирования или его рабочей среды для определения того, происходят ли регрессивные отказы.

Примечани е — Достаточное количество регрессионных тестов зависит от тестируемого элемента и от изменений этого элемента или его рабочей среды.

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

4.34    повторное тестирование (retesting): Повторное выполнение контрольных примеров, для которых ранее был получен результат «сбоя» для оценки эффективности произведенных корректирующих действий.

Примечание — Используется также термин «тестирование подтверждения».

4.35    тестирование на базе рисков (risk-base testing): Тестирование, для которого менеджмент, выбор, расстановка приоритетов и использование действий и ресурсов тестирования преднамеренно основаны на базе проанализированных рисков соответствующих типов и уровней.

4.36    тестирование на основе сценария (scenario testing): Класс методик проектирования тестирования, при которых разрабатываются тестирования для выполнения конкретных сценариев.

Примечание — Сценарий может быть историей пользователя, примером использования, операционным понятием или последовательностью событий, с которыми программное обеспечение может встретиться и т. д.

4.37    тестирование по сценарию (scripted testing): Динамическое тестирование, в котором действия тестера предписаны записанными в контрольном примере инструкциями.

Примечание — Этот термин обычно применяется для тестирования, выполняемого вручную, а не для выполнения автоматизированного сценария.

4.38    тестирование защищенности (security testing): Тип тестирования, проводимый для оценки степени защищенности элемента тестирования и связанных с ним данных и информации от доступа посторонних лиц или систем для использования, чтения или изменения их при том, что доверенным лицам или системам доступ к ним обеспечивается.

4.39    тестирование на основе спецификации (specification-based testing): Тестирование, основным базисом которого являются внешние вводы и выводы элемента тестирования, обычно на основе спецификации, а не ее реализация в исходном коде или исполнимом программном обеспечении.

Примечание — Синонимами тестирования на основе являются тестирование методом «черного ящика» и тестирование закрытого ящика.

4.40    покрытие операторов (statement coverage): Процент совокупности всех исполнимых операторов элемента тестирования, которые покрываются набором тестов.

4.41    тестирование операторов (statement testing): Метод проектирования тестирования, при котором создаются контрольные примеры для выполнения отдельных операторов элемента тестирования.

4.42    статическое тестирование (static testing): Тестирование, при котором элемент тестирования анализируется с использованием совокупности критериев качества или других свойств без выполнения кода.

Пример — Ревизия, статический анализ.

4.43    стрессовое тестирование (stress testing): Тип тестирования уровня производительности, проводимого для оценки поведения элемента тестирования при условиях загрузки, выше ожидаемой или указанной в требованиях к производительности, или при доступности ресурсов, ниже минимальной, указанной в требованиях.

4.44    структурное тестирование (structure-based testing): См. термин «тестирование на основе структуры» согласно 4.45.

4.45    тестирование на основе структуры (structure-based testing): Динамическое тестирование, для которого тесты являются результатом анализа структуры элемента тестирования.

4

ГОСТ Р 56920-2016

Примечания

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

2    Методика включает в себя тестирование ветвей, тестирование альтернатив и тестирование операторов.

3    Синонимами тестирования на основе структуры являются структурное тестирование, тестирование стеклянного ящика и тестирование методом «белого ящика».

4.46    критерии приостановки (suspension criteria): Критерии, используемые для того, чтобы (временно) остановить все или часть тестирующих действий.

4.47    базис тестирования (test basis): Свод знаний, используемых в качестве базы проекта тестирования и контрольных примеров.

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

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

Примечания

1    Для подпроцесса тестирования, для которого он предназначен, контрольный пример — это самый низкий уровень входа тестирования (то есть контрольные примеры не состоят из других контрольных примеров).

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

3    Входы — это информация о данных, используемых для начала выполнения теста.

4    Ожидаемые результаты включают в себя критерии успеха, отказы в проверке и т. д.

4.49    Спецификация Контрольного Примера (Test Case Specification): Документация ряда одного или большего количества контрольных примеров.

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

4.51    Отчет о Завершении Тестирования (Test Completion Report): Отчет, в котором представлена сводка выполненного тестирования.

Примечание — Иногда также называют сводным отчетом тестирования.

4.52    тестовое условие (test condition): Тестируемый аспект компонента или системы, такой как функция, транзакция, возможность, атрибут качества или структурный элемент, идентифицированные как базис тестирования.

Примечание — Тестовые условия могут быть использованы для получения элементов покрытия или же могут сами по себе образовывать элементы покрытия.

4.53    тестовое покрытие (test coverage): Степень, выраженная в процентах, в которой специфицированные элементы тестового покрытия были проверены контрольным примером или контрольными примерами.

4.54    элемент тестового покрытия (test coverage item): Атрибут или комбинация атрибутов, которые являются производными одного или более тестовых условий, полученными посредством методики проектирования тестирования, которая позволяет оценить основательность выполнения теста.

4.55    тестовые данные (test data): Созданные или отобранные данные, удовлетворяющие входным требованиям для выполнения одного или более контрольных примеров, которые могут быть определены в плане тестирования, контрольном примере или процедуре тестирования.

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

4.56    Отчет о Готовности Тестовых Данных (Test Data Readiness Report): Документ, описывающий состояние каждого требования к тестовым данным.

5