Инструкция по тестированию гост

Доступно детальных карточек: 1 из 2
Следующий пробный период начнётся: 31 мая 2025 в 01:05

Снять ограничение

ГОСТ Р 56922-2016 / ГОСТ Р 56922-2016/ ISO/IEC/IEEE 29119-3:2013

Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования

Информация

Название Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования
Название английское Software and systems engineering.Software testing. Part 3. Test documentation
Дата актуализации текста 01.01.2021
Дата актуализации описания 01.07.2023
Дата издания 18.07.2016
Дата введения в действие 01.06.2017
Область и условия применения Настоящий стандарт определяет шаблоны документации тестирования программного обеспечения, которые могут использоваться в любой организации, любом проекте или каком-либо действии тестирования проекта
Опубликован Официальное издание. М.: Стандартинформ, 2016 год
Утверждён в Росстандарт

Расположение в каталоге ГОСТ

Общероссийский классификатор стандартов

  • Информационные технологии. Машины конторские

    • Программное обеспечение

      • ГОСТ Р 56922-2016  —  Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования

Классификатор государственных стандартов

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

    • Средства вычислительной техники и автоматизированные системы управления

      • Виды представления информации и математическое обеспечение машин

        • ГОСТ Р 56922-2016  —  Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования

ГОСТ Р 56922-2016/
ISO/IEC/IEEE 29119-3:2013

     

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

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

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

Часть 3

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

Software and systems engineering. Software testing. Part 3. Test documentation

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

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

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

________________

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

Введение

Международная организация по стандартизации (ИСО) и Международная электротехническая комиссия (МЭК) образуют специализированную систему всемирной стандартизации. Национальные органы по стандартизации, которые являются членами ИСО или МЭК, участвуют в разработке международных стандартов через технические комитеты, созданные соответствующей организацией для определенных областей технической деятельности. Технические комитеты ИСО и МЭК сотрудничают в сферах, представляющих взаимный интерес. Другие международные правительственные и неправительственные организации, связанные с ИСО и МЭК, также принимают участие в деятельности по разработке стандартов. В сфере информационной технологии ИСО и МЭК учредили совместный технический комитет ИСО/МЭК СТК 1.
Стандарты Института инженеров по электротехнике и радиоэлектронике (ИИЭР) разработаны в сообществах и комитетах по координации стандартов ИИЭР, входящих в состав бюро стандартов ассоциации стандартов ИИЭР. ИИЭР разрабатывает свои стандарты на основе одобренного Американским национальным институтом стандартов консенсусного процесса разработки, который для достижения конечного результата объединяет различные точки зрения и интересы добровольцев. Добровольцы не обязательно являются сотрудниками института и работают на безвозмездной основе. При том что ИИЭР курирует процесс и устанавливает правила обеспечения справедливости в консенсусном процессе разработки, он не проводит независимые оценку, испытание или проверку точности какой-либо информации, входящей в состав своих стандартов.
Международные стандарты разрабатываются в соответствии с правилами, приведенными в Директивах ИСО/МЭК, часть 2.
Основная задача совместного технического комитета состоит в подготовке международных стандартов. Проекты международных стандартов, принятые совместным техническим комитетом, распространяются среди национальных органов по стандартизации для вынесения решения. Для публикации в качестве международного стандарта требуется одобрение по крайней мере 75% национальных органов по стандартизации, участвующих в голосовании.
Следует обратить внимание на возможность того, что при внедрении этого стандарта может потребоваться использование документа, защищенного патентными правами. При публикации настоящего стандарта не рассматривались вопросы наличия или соответствия каких-либо связанных со стандартом патентных прав. ИСО/ИИЭР не несет ответственность ни за идентификацию существенных для стандарта патентов или патентных заявок, для которых может требоваться лицензия, ни за расследование юридической правильности или области применения патентов либо патентных заявок, ни за определение каких-либо условий лицензирования или условий предоставления гарантийных писем либо патентных заявлений и форм лицензирования, если таковые имеются, ни за какие-либо приемлемые недискриминационные лицензионные соглашения. Пользователи этого стандарта должны принять во внимание то, что определение действия каких-либо патентных прав и риска нарушения таких прав полностью лежит на их собственной ответственности. Дополнительная информация может быть получена в ИСО или Ассоциации стандартов ИИЭР.
ИСО/МЭК/ИИЭР 29119-3 подготовлен Подкомитетом 7 «Системная и программная инженерия» совместного технического комитета ИСО/МЭК СТК 1 «Информационные технологии» в сотрудничестве с комитетом по стандартам системной и программной инженерии компьютерного сообщества ИИЭР в соответствии с организационным соглашением о партнерском сотрудничестве по разработке стандартов между ИСО и ИИЭР.
Серия стандартов ИСО/МЭК/ИИЭР 29119 под общим названием «Системная и программная инженерия. Тестирование программного обеспечения» состоит из следующих частей:
— Часть 1. Понятия и определения;
— Часть 2. Процессы тестирования;
— Часть 3. Документация тестирования;
— Часть 4. Методики тестирования.
Цель создания серии стандартов тестирования программного обеспечения ИСО/МЭК/ИИЭР 29119 состоит в том, чтобы определить общую модель тестирования программного обеспечения, которая может использоваться любой организацией при выполнении различных форм тестирования программного обеспечения. В настоящем стандарте представлены шаблоны и примеры документации тестирования, которая создается в ходе процесса тестирования. Шаблоны, приведенные в приложениях, отражают полную структуру процесса тестирования, описанного в ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования», то есть процесса тестирования, для которого создается документация. В приложении A изложены основы содержания каждого документа.
Приложение B содержит список всех информационных элементов, определенных в разделах 5, 6 и 7 настоящего стандарта, с соответствующим уровнем требования соответствия (необходимо/следует/можно) ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования». Приложение C содержит общие сведения о примерах. В приложениях D-S приводятся примеры применения шаблонов. Приложение T показывает взаимосвязь с существующими стандартами. Библиография приводится в конце настоящего стандарта.
Понятия и терминология документации тестирования программного обеспечения определены в ИСО/МЭК/ИИЭР 29119-1 «Понятия и определения».
Актуальная модель процесса тестирования определена в ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования». В этом стандарте представлено описание процессов тестирования, которые определяют процессы тестирования программного обеспечения на организационном уровне, уровне управления тестированием и уровне динамического тестирования. Кроме того, там представлены информативные диаграммы, описывающие процессы.
Методы проектирования тестирования программного обеспечения, которые могут быть использованы в разработке тестирования, определены в ИСО/МЭК/ИИЭР 29119-4 «Методики тестирования».
Серия международных стандартов ИСО/МЭК/ИИЭР 29119 дает возможность всем заинтересованным лицам контролировать и выполнять тестирование программного обеспечения в любой организации.

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

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

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

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

     2.1 Предполагаемое соответствие

Требования настоящего стандарта, содержащиеся в разделах 5, 6 и 7, устанавливают требования для многих документов тестирования, приемлемых для использования в течение полного жизненного цикла программного обеспечения. Допускается, что в конкретных проектах или организациях может не возникать потребности в использовании всех документов, определенных в настоящем стандарте. Поэтому практическая реализация настоящего стандарта обычно заключается в выборе совокупности документов, пригодных для организации или проекта. Существуют два типа соответствия условиям настоящего стандарта: полное и адаптированное. Соответствие может быть заявлено для организаций, проектов, проектов с несколькими исполнителями и услуг, как это определено в заявлении о соответствии.
Информационные элементы, определенные в разделах 5, 6 и 7, соответствуют выходным данным ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования». Приложение В является справочным и представляет обзор нормативных требований к разделам ИСО/МЭК/ИИЭР 29119-2, в которых описано создание информационных элементов, определенных в разделах 5, 6 и 7.
Для простоты ссылок в настоящем стандарте на каждый документ ссылаются как на опубликованный в виде отдельного печатного документа. Названия и содержание документов могут быть изменены (дополнены, объединены или переименованы), и использование номенклатуры конкретных документов, определенных в разделах 5, 6 и 7, не должно требовать соответствия. Документы считаются соответствующими, если они не опубликованы, а доступны в электронной форме, если они разделены на отдельные части или тома или объединены с другими документами в один документ.

     2.2 Типы соответствия

Возможны заявления о соответствии двух типов. Выбранный тип соответствия должен быть идентифицирован в заявлении о соответствии документации.
2.2.1 Полное соответствие
Минимальная совокупность требуемых информационных элементов — это все информационные элементы, которые определены в разделах 5, 6 и 7.
Примечание — Может быть заявлено полное соответствие необходимых выбранных документов, даже если не декларируется полное соответствие всему настоящему стандарту.
2.2.2 Адаптированное соответствие
Содержание документов тестирования, определенных в разделах 5, 6 и 7, может быть адаптировано на базе адаптированного соответствия ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования» и/или на основе конкретных потребностей организации или проекта. В каждом случае адаптации, если не представлен информационный элемент, определенный в разделах 5, 6 и 7, необходимо предоставить обоснование. Все решения по адаптации должны быть документированы с их обоснованием, включая учет любых применимых рисков.
Решения по адаптации должны быть согласованы с соответствующими заинтересованными сторонами.
Адаптированное соответствие может быть достигнуто в следующих случаях:
a) Минимальная совокупность требуемой документации тестирования определена адаптацией процессов и действий в соответствии с разделом 2 ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования».
b) Минимальная совокупность требуемой документации тестирования определена в соответствии с конкретными потребностями организации и/или проекта.
c) Минимальная совокупность требуемых информационных элементов в документах определена в соответствии с конкретными потребностями организации и/или проекта.
1 В отдельных проектах, особенно в тех, которые следуют методике динамичной разработки, адаптация может быть применена ко всем документам настоящего стандарта, допуская их краткую форму или представление в альтернативном формате (например, устном или формате слайдов).
2 Возможно использование различных названий документов, но в таких случаях для облегчения оценки соответствия обычно представляют соответствие локально используемых названий настоящему стандарту.

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

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

_______________

* Таблицу соответствия национальных стандартов международным см. по ссылке. — Примечание изготовителя базы данных.     
ИСО/МЭК/ИИЭР 15289:2011 Системная и программная инженерия. Содержание информационных продуктов жизненного цикла (документация)
(ISO/IEC/IEEE 15289:2011, Systems and software engineering — Content of life-cycle information products (documentation);
ИСО/МЭК/ИИЭР 29119-1 Системная и программная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения
(ISO/IEC/IEEE 29119-1, Software and systems engineering — Software testing — Part 1: Concepts and definitions)
ИСО/МЭК/ИИЭР 29119-2 Системная и программная инженерия. Тестирование программного обеспечения. Часть 2. Процессы тестирования
(ISO/IEC/IEEE 29119-2:2013, Software and systems engineering — Software testing — Part 2: Test processes)
Другие стандарты, полезные для реализации и интерпретации настоящего стандарта, приведены в разделе «Библиография».

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

В настоящем стандарте применены термины и определения, приведенные в ИСО/МЭК/ИИЭР 24765, а также следующие термины с соответствующими определениями.
Примечание — Терминология в настоящем стандарте используется для простоты цитирования, и ее применение не требуется для соответствия настоящему стандарту. Нижеследующий список терминов и определений представлен для обеспечения правильного понимания и удобочитаемости настоящего стандарта. В него включены только критически важные для понимания настоящего стандарта термины. Составление полного списка терминов тестирования не является целью данного раздела. Для терминов, не определенных в этом разделе, следует пользоваться словарем системной и программной инженерии ИСО/МЭК/ИИЭР 24765. Он доступен на веб-сайте: http://www.computer.org/sevocab. Все термины, определенные в данном разделе, преднамеренно включены в ИСО/МЭК/ИИЭР 29119-1, поскольку в этот стандарт входят все термины, использованные в частях 1, 2, 3 и 4 серии стандартов ИСО/МЭК/ИИЭР 29119.
4.1 фактические результаты (actual results): Совокупность поведения или условий элемента тестирования либо совокупность условий связанных данных или тестовой среды, полученных в результате выполнения теста.
Пример — Вывод на аппаратные средства, изменения в данных, отчеты и отправленные информационные сообщения.
4.2 элемент покрытия (coverage item): См. термин «элемент тестового покрытия» согласно 4.15.
4.3 ожидаемые результаты (expected results): Характерное предсказанное поведение элемента тестирования при указанных условиях на основе его спецификации или другого источника.
4.4 набор функций (feature set): Логическое подмножество элемента(ов) тестирования, которое может быть обработано независимо от других наборов функций в последующих действиях проекта тестирования.
Примечание — Это может быть набор всех функций элемента (полный набор его функций) или подмножество, определенное для конкретной цели (совокупность функциональных возможностей и т.д.).
4.5 Отчет об Инциденте (Incident Report): Документация по инциденту о его проявлении, природе и состоянии.
Примечание — Отчеты об инцидентах также могут называться отчетами об аномалиях, отчетами об ошибках, дефектными отчетами, сообщениями об ошибке, проблемами, проблемными отчетами и отчетами об отказе и т.д.
4.6 Организационная Спецификация Тестирования (Organizational Test Specification): Документ, в котором представлена информация о тестировании для организации, то есть информация, которая не специфична для проекта.
Пример — Наиболее общими примерами Организационной Спецификации Тестирования являются Организационная Политика Тестирования и Организационная Стратегия Тестирования.
4.7 Организационная Стратегия Тестирования (Organizational Test Strategy): Документ, в котором изложены универсальные требования к тестированию, которое будет выполняться для всех проектов организации, а также подробности того, как должно производиться тестирование.
1 Организационная Стратегия Тестирования согласована с Организационной Политикой Тестирования.
2 Для покрытия существенно различных контекстов проектов у организации может быть более одной Организационной Стратегии Тестирования.
3 В случае отсутствия Политики Тестирования в Организационную Стратегию могут входить положения Политики Тестирования.
4.8 риск продукта (product risk): Риск того, что продукт может иметь дефект в некотором определенном аспекте его функций, качества или структуры.
4.9 риск проекта (project risk): Риск, относящийся к менеджменту проекта.
Пример — Отсутствие комплектности персонала, строгие крайние сроки, изменение требований.
4.10 регрессионное тестирование (regression testing): Тестирование после изменений элемента тестирования или его рабочей среды для определения, происходят ли регрессивные отказы.
Примечание — Достаточное количество регрессионных тестов зависит от тестируемого элемента и от изменений этого элемента или его рабочей среды.
4.11 повторное тестирование (retesting): Повторное выполнение контрольных примеров, для которых ранее был получен результат «сбоя», для оценки эффективности произведенных корректирующих действий.
Примечание — Используется также термин «тестирование подтверждения».
4.12 контрольный пример (test case): Совокупность предварительных условий контрольного примера, входов (включая действия, где это применимо) и ожидаемых результатов, разработанных для управления выполнением элемента тестирования для достижения целей тестирования, включая корректную реализацию, идентификацию ошибок, проверку качества и получение другой значимой информации.
1 Для подпроцесса тестирования, для которого он предназначен, контрольный пример — это самый низкий уровень входа тестирования (то есть контрольные примеры не состоят из других контрольных примеров).
2 Исходные условия контрольного примера включают тестовую среду, существующие данные (например, базы данных), программное обеспечение для тестирования, аппаратные средства и т.д.
3 Входы — это информация о данных, используемых для начала выполнения теста.
4 Ожидаемые результаты включают в себя критерии успеха, отказы в проверке и т.д.
4.13 Спецификация Контрольных Примеров (Test Case Specification): Документация одного или большего количества контрольных примеров.
4.14 Отчет о Завершении Тестирования (Test Completion Report): Отчет, в котором представлена сводка выполненного тестирования.
Примечание — Иногда также называют сводным отчетом тестирования.
4.15 элемент тестового покрытия (test coverage item): Атрибут или комбинация атрибутов, которые являются производными одного или более тестовых условий, полученными посредством методики проектирования тестирования, позволяющей оценить основательность выполнения теста.
4.16 тестовые данные (test data): Созданные или отобранные данные, удовлетворяющие входным требованиям для выполнения одного или более контрольных примеров, которые могут быть определены в плане тестирования, контрольном примере или процедуре тестирования.
Примечание — Тестовые данные могут храниться в тестируемом продукте (например, в массивах, плоских файлах или базе данных), или быть доступны из внешних источников, или предоставлены такими источниками, как другие системы, другие компоненты системы, устройства либо операторский персонал.
4.17 Отчет о готовности Тестовых Данных (Test Data Readiness Report): Документ, описывающий состояние каждого Требования к Тестовым Данным.
4.18 Спецификация Проекта Тестирования (Test Design Specification): Документ, определяющий функции, которые будут проверены, и соответствующие тестовые условия.
4.19 методика проектирования тестирования (test design technique): Действия, понятия, процессы и шаблоны, необходимые для создания модели тестирования, которая используется для определения тестовых условий для элемента тестирования, для получения соответствующих элементов тестового покрытия, а далее для разработки или выбора контрольных примеров.
4.20 тестовая среда (test environment): Различные средства, аппаратное и программное обеспечение, встроенное микропрограммное обеспечение, процедуры и документация, предназначенные или используемые для выполнения тестирования программного обеспечения.
Примечание — Тестовая среда может содержать в себе другие среды, необходимые для выполнения конкретных подпроцессов тестирования (например, тестовая среда объекта, среда теста производительности и т.д.).
4.21 Отчет о готовности Тестовой Среды (Test Environment Readiness Report): Документ, который описывает состояние каждого требования к среде.
4.22 Требования к Тестовой Среде (Test Environment Requirements): Описание необходимых свойств тестовой среды.
Примечание — Все или часть требований к тестовой среде могут иметь ссылки, необходимые для поиска информации, например, ссылку на соответствующую Организационную Стратегию тестирования, План Тестирования и/или Спецификацию Тестирования.
4.23 Журнал Выполнения Теста (Test Execution Log): Документ, в который записываются детали выполнения одной или более процедур тестирования.
4.24 элемент тестирования (test item): Рабочий продукт, который является объектом тестирования.
Пример — Система, элемент программного обеспечения, документ требований, разрабатываемая спецификация, руководство пользователя.
4.25 План Тестирования (Test Plan): Подробное описание требуемых целей тестирования, средств и расписания их достижения, предназначенное для координации тестирующих действий для отдельного элемента тестирования или совокупности элементов тестирования.
1 В проект может входить более одного Плана Тестирования, например, может быть План Тестирования проекта (также именуемый основным планом тестирования), который охватывает все тестирующие действия для проекта, а более подробная информация об определенных действиях тестирования может быть определена в одном или более планах подпроцессов тестирования (то есть План Тестирования системы или план теста производительности).
2 Обычно План Тестирования представляет собой печатный документ, хотя возможны и другие форматы плана, определяемые локально для организации или проекта.
3 Планы тестирования могут содержать деятельность, выходящую за рамки проекта, например, План Тестирования обслуживания.
4.26 Политика Тестирования (Test Policy): Руководящий документ, в котором описаны назначение, цели и полная предметная область применения тестирования в организации.
1 Политика Тестирования определяет, какое тестирование должно выполняться и чего от него ожидают, но не детализирует, как тестирование должно быть выполнено.
2 Политика Тестирования может обеспечить основы для разработки, анализа и постоянного улучшения тестирования в организации.
4.27 Спецификация Процедур Тестирования (Test Procedure Specification): Документ, определяющий одну или более процедур тестирования, представляющих собой наборы контрольных примеров, которые будут выполняться с конкретной целью.
1 Контрольные примеры в наборе тестов перечислены в порядке, требуемом в процедуре тестирования.
2 Также имеет название сценария ручного тестирования. Спецификацию процедуры тестирования для автоматизированного тестового прогона обычно называют сценарием тестирования.
4.28 результат тестирования (test result): Индикатор того, прошел ли определенный контрольный пример успешно или нет, то есть соответствует ли фактический результат элемента тестирования ожидаемому результату или наблюдались отклонения.
4.29 набор тестов (test set): Набор контрольных примеров в целях тестирования конкретной цели тестирования.
1 В наборах тестов обычно отражаются совокупности функций, однако они могут содержать контрольные примеры для многих совокупностей функций.
2 Контрольные примеры для набора тестов могут быть выбраны на основе идентифицированных рисков, базиса тестирования, повторного тестирования и/или регрессионного тестирования.
4.30 спецификация тестирования (test specification): Подробная документация проекта тестирования, контрольных примеров и процедур тестирования для определенного элемента тестирования.
Примечание — Спецификация тестирования может быть представлена в одном документе, набором документов или другими способами, например, записями базы данных и документами.
4.31 Отчет о Ходе Тестирования Test Status Report): Отчет, который предоставляет информацию о состоянии тестирования, которое выполняется в указанный отчетный период.
4.32 стратегия тестирования (test strategy): Часть Плана Тестирования, в которой описан подход к тестированию определенного проекта тестирования или процессам и подпроцессам тестирования.
1 Стратегия тестирования — это производная от Организационной Стратегии Тестирования.
2 Стратегия тестирования обычно определяет некоторые или все из следующих аспектов: используемые методики тестирования, реализуемые тестовые подпроцессы, повторное тестирование и регрессионное тестирование, которые будут использоваться, методы проектирования тестирования, соответствующие критерии завершения тестирования, тестовые данные, тестовую среду и требования к инструментам тестирования и ожидаемые результаты тестирования.
4.33 матрица прослеживаемости тестирования (test traceability matrix): Документ, электронная таблица или другой автоматизированный инструмент, используемый для идентификации в документации и программном обеспечении связанных элементов, таких как требования соответствующего тестирования.
1 Также известен как матрица перекрестных ссылок верификации, матрица проверки требований, таблица верификации требований и др.
2 Различные матрицы прослеживаемости тестирования могут отличаться содержащейся информацией, форматами и уровнями детализации.
4.34 тестирование (testing): Набор операций, проводимых для обеспечения выявления и/или оценки свойств одного или более элементов тестирования.
Примечание — Действия тестирования могут включать в себя планирование, подготовку, выполнение, создание отчетов и менеджмент, поскольку все они направлены на тестирование.

     5 Документация Организационного Процесса Тестирования

     5.1 Общие сведения

Организационные Спецификации Тестирования представляют информацию о тестировании на уровне организации и не зависимы от проекта. Типичными примерами Организационных Спецификаций Тестирования, разработанных в организационном процессе тестирования, являются:
— Организационная Стратегия Тестирования.
Полные шаблоны документов с пояснением представлены в 5.2 «Политика Тестирования» и 5.3 «Организационная Стратегия Тестирования». В приложении A представлены краткие общие сведения о каждом документе. В приложениях D и E приводятся примеры Политики Тестирования и Организационной Стратегии Тестирования для конкретных проектов.

     5.2 Политика Тестирования

Политика Тестирования определяет цели и принципы тестирования программного обеспечения, которые будут использоваться в организации. Она определяет, что должно быть достигнуто тестированием, но не указывает в деталях, как тестирование должно выполняться. Политика обеспечивает основу для установления, пересмотра и постоянного совершенствования Политики Тестирования организации.
В A.2.2 (приложение A) представлен макет Организационной Политики Тестирования, а в D.1 и D.2 (приложение D) приведены примеры, которые демонстрируют, как могут быть разработаны Организационные Политики Тестирования для двух различных проектов.
Содержание Политики Тестирования описано ниже.
5.2.2 Спецификация документа
Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.
Примечание — Информация может быть помещена в начало документа или в середину, если документ хранится в электронной форме, например, в базе данных.
5.2.2.2 Уникальная идентификация документа
Однозначно определяет версию документа.
Пример — Уникальный идентификатор может содержать название документа, дату выпуска, версию и/или состояние документа (например, рассмотренный проект, исправленный или окончательный).
5.2.2.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда могут также быть включены имена авторов (автора).
5.2.2.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда могут также быть включены рецензенты и соответствующие менеджеры.
5.2.2.5 История изменений
Сюда входит журнал всех изменений, которые произошли с документом, начиная с момента его создания.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящим изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
5.2.3.1 Область применения
Идентифицирует степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации.
Пример — Нормативными документами могут быть политики, планы, процедуры и другие.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение или в нем могут быть ссылки на другой документ, обеспечивающий общий глоссарий. Весь глоссарий или его часть, и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию или включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
5.2.4 Положения Политики Тестирования
5.2.4.1 Цели тестирования
Определяет назначение, цели и полную область применения тестирования в организации. Устанавливает позицию организации, почему выполняется тестирование и какую цель преследует.
5.2.4.2 Процесс тестирования
Идентифицирует процесс тестирования, которому будет следовать организация. Это может быть ссылкой на конкретный документ, предоставляющий подробную информацию о процессе тестирования.
Пример — Таким документом может быть ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования». Детали процесса тестирования могут быть представлены в более подробной документации процесса тестирования.
5.2.4.3 Организационная структура тестирования
Идентифицирует роли и структуру организации тестирования. Для того чтобы показать организационную иерархию тестирования можно использовать схему или табличное представление.
5.2.4.4 Подготовка тестеров
Определяет потребность в обучении и сертификации персонала, работающего в организации тестирования.
Определяет организационный кодекс этики, которого должны придерживаться тестеры.
Устанавливает, какие стандарты применимы в организации тестирования.
5.2.4.7 Другие соответствующие политики
Определяет политики, оказывающие влияние на организацию тестирования.
Пример — Одним из положений политики может быть требование соответствия тестирования политике в области качества.
5.2.4.8 Оценка стоимости тестирования
Устанавливает, как организация определяет возврат инвестиций в тестирование. Определяет цели оценки затрат на тестирование.
5.2.4.9 Архивация и повторное использование актива тестирования
Устанавливает позицию организации по архивации и повторному использованию активов тестирования.
5.2.4.10 Совершенствование процесса тестирования
Определяет методику обеспечения непрерывного совершенствования процесса тестирования.

     5.3 Организационная Стратегия Тестирования

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

Рисунок 2 — Пример структуры Организационной Стратегии Тестирования

Содержание Организационной Стратегии Тестирования описано ниже.
5.3.2 Спецификация документа
Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.
Примечание — Если документ хранится в электронной форме, например, в базе данных, то информация может быть помещена в начало или середину документа.
5.3.2.2 Уникальная идентификация документа
Однозначно определяет версию документа.
Пример — Уникальный идентификатор может содержать название документа, дату выпуска, версию и/или состояние документа (например, рассмотренный проект, исправленный или окончательный).
5.3.2.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда могут также быть включены имена авторов (автора).
5.3.2.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда могут также быть включены рецензенты и соответствующие менеджеры.
5.3.2.5 История изменений
Сюда входит журнал всех изменений, которые произошли с документом, начиная с момента его создания.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящим изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
5.3.3.1 Область применения
Определяет степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации.
Пример — Нормативными документами могут быть политики, планы, процедуры и другое.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение либо может ссылаться на другой документ, обеспечивающий общий глоссарий. Весь глоссарий или его часть и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию либо могут быть включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
5.3.4 Положения Организационной Стратегии Тестирования в масштабах проекта
Стратегия определяется для заданной области применения. В данный раздел включаются положения, подходящие для всех подпроцессов тестирования, которые будут выполняться в данном проекте в рамках стратегии. В этот раздел в случае необходимости могут быть включены подразделы политики.
5.3.4.1 Общий менеджмент рисков
Определяет общий подход к менеджменту рисков, который, как ожидается, будет использован для управления тестированием.
5.3.4.2 Выбор тестирования и приоритетов
Определяет подход организации к выбору теста и приоритетов выполнения теста в виде приоритетных процедур тестирования. Процедуры тестирования состоят из приоритетных контрольных примеров, полученных из приоритетных наборов функций через приоритетные тестовые условия и элементы покрытия.
5.3.4.3 Документация тестирования и создание отчетов
Идентифицирует документы, которые ожидается произвести во время тестирования в рамках всего проекта тестирования. Описывает подготовку каждого документа и соответствующего процесса утверждения. Это тесно связано с определенным в политике процессом тестирования.
5.3.4.4 Автоматизация и инструменты тестирования
Определяет подход к автоматизации тестирования в организации. Идентифицирует инструменты тестирования, которые будут использоваться в Ходе Тестирования.
Пример — Сюда могут входить инструменты управления тестированием, инструменты выполнения теста, инструменты тестирования производительности, инструменты тестирования защищенности, инструменты тестирования удобства пользования.
5.3.4.5 Менеджмент конфигурации рабочих продуктов тестирования
Определяет менеджмент конфигурации, который будет применяться для рабочих продуктов тестирования; определяет, как эти рабочие продукты должны быть идентифицированы, прослеживаться, храниться и обеспечивать доступность для заинтересованных сторон.
5.3.4.6 Управление инцидентами
Определяет, как нужно управлять инцидентами во время тестирования или ссылаются на описание в другом документе.
5.3.4.7 Подпроцессы тестирования
Идентифицирует конкретные подпроцессы тестирования, которые будут выполняться как часть тестирования в рамках стратегии.
5.3.5 Положения организационной стратегии тестирования для конкретных подпроцессов
5.3.5.1 Критерии входа и выхода
Определяет используемые критерии запуска и остановки действий тестирования для конкретного подпроцесса тестирования.
Подпроцесс тестирования состоит из следующих процессов:
— проектирование и реализация тестирования;
— установка и поддержка тестовой среды;
— отчетность об инцидентах тестирования.
Различные критерии входа и выхода могут быть определены для каждого из них индивидуально, или для отдельных отобранных процессов, или для всего подпроцесса в целом.
5.3.5.2 Критерии завершения тестирования
Определяет, когда с точки зрения организации должны быть завершены действия тестирования подпроцесса тестирования.
5.3.5.3 Документация тестирования и создание отчетов
Идентифицирует документирование тестирования, включая создание отчетов, используемое в ходе действий тестирования в подпроцессе тестирования. Определяет, когда должен быть подготовлен каждый документ или отчет, а также соответствующий процесс утверждения. Это тесно связано с определенным в политике процессом тестирования.
5.3.5.4 Степень независимости
Устанавливает уровень независимости лиц, выполняющих тестирование, то есть состояние технической, организационной и финансовой независимости этой группы тестирования.
5.3.5.5 Методика проектирования тестирования
Идентифицирует конкретные методы проектирования тестирования, которые будут использоваться во время разработки и реализации тестирования в подпроцессе тестирования.
Определяет тестовую среду для подпроцесса тестирования. Может определять, где должны быть выполнены тестирования конкретных типов и идентифицирует группы или организации, ответственные за тестовую среду. Может идентифицировать источник тестовых данных, указать, где расположены определенные типы тестовых данных и какие группы или организации ответственны за тестовые данные.
5.3.5.7 Требуемые метрики
Определяет метрики, значения которых должны быть собраны в ходе действий тестирования в подпроцессе тестирования.
5.3.5.8 Повторное тестирование и регрессионное тестирование
Определяет стратегию, условия и действия повторного тестирования и регрессионного тестирования в подпроцессе тестирования.

     6 Документация Процессов Управления Тестированием

     6.1 Общие сведения

Документы, разработанные в процессах управления тестированием, включают в себя следующие:
— Отчет о Ходе Тестирования;
— Отчет о Завершении Тестирования.
Полные шаблоны документов с пояснением приведены ниже. В приложении A представлены краткие общие сведения о каждом документе. В приложениях F и G приведены примеры Планов Тестирования, Отчетов о Ходе Тестирования и Отчетов о Завершении Тестирования для конкретных проектов.

     6.2 План Тестирования

План Тестирования представляет собой документ для планирования тестирования и управления тестированием. Некоторые из проектов могут иметь один План Тестирования, в то время как для больших проектов может быть создано несколько планов тестирования. Планы Тестирования могут создаваться для ряда проектов (на уровне программы), для единственного проекта (План Тестирования проекта/основной План Тестирования) или для конкретного подпроцесса тестирования (План Тестирования системы, План Тестирования комплексирования программного обеспечения, План Тестирования подсистемы, План Тестирования программного обеспечения субподрядчика, План Тестирования единицы программного обеспечения, план теста производительности или план определенной итерации тестирования). Если создается большое количество Планов Тестирования программного обеспечения, то, чтобы помочь документировать взаимосвязи и информацию, содержащуюся в каждом из них, можно построить дерево отображения.
В Плане Тестирования описаны решения, принятые во время начального планирования, и он развивается, поскольку в составе управляющих действий осуществляется перепланирование.
В A.2.4 (приложение A) представлен макет Плана Тестирования, а в F.1 и F.2 (приложение F) приведены примеры, демонстрирующие разработку Планов Тестирования для двух различных проектов.
Далее приводится содержание Плана Тестирования.
6.2.2 Спецификация документа
Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.
Примечание — Если документ хранится в электронной форме, например в базе данных, то информация может быть помещена в начало или середину документа.
6.2.2.2 Уникальная идентификация документа
Однозначно определяет версию документа.
Пример — Уникальный идентификатор может содержать название документа, дату выпуска, версию и/или состояние документа (например, рассмотренный проект, исправленный или окончательный).
6.2.2.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда могут также быть включены имена авторов (автора).
6.2.2.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда могут также быть включены рецензенты и соответствующие менеджеры.
6.2.2.5 История изменений
Сюда входит журнал всех изменений, которые произошли с документом, начиная с момента его создания.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящем изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
6.2.3.1 Область применения
Определяет степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации
Пример — Ссылки на документацию элемента тестирования, относящуюся к конкретному подпроцессу тестирования, могут включать в себя ссылки на:
— руководство пользователя;
— руководство по работе и/или
— инструкцию по установке.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение или ссылаться на другой документ, обеспечивающий общий глоссарий. Весь глоссарий или его часть и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию либо включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
6.2.4 Контекст тестирования
6.2.4.1 Проект(ы)/подпроцесс(ы) тестирования

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

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

6.2.4.2 Элемент(ы) тестирования
Определяет элемент(ы) тестирования для тестирования по этому плану, включая их версию/пересмотр или ссылку на эту информацию.
В этом разделе возможно описание назначения элемента(ов) тестирования или приводится ссылка на эту информацию.
Примечание — Эта информация может быть определена в документе, определяющем концепцию работы системы.
Пример — Элементом тестирования может быть программный блок, интерфейс между единицами, подсистема или полная система.
Здесь также могут быть идентифицированы все процедуры переноса элемента(ов) тестирования из других сред в тестовую среду.
6.2.4.3 Область применения тестирования
Обобщает все функции элемента(ов) тестирования, подлежащие проверке. Также идентифицирует все функции элемента(ов) тестирования, которые должны быть исключены из тестирования, и предоставляет обоснования их исключения.
Пример — Функции, подлежащие проверке, могут быть определенными атрибутами программного обеспечения, функций, интерфейсов или бизнес-процессов.
6.2.4.4 Предположения и ограничения
Определяет любые предположения и ограничения для действий тестирования, предусмотренных этим планом. Сюда могут входить нормативные требования, требования Политики Тестирования и Организационной Стратегии Тестирования, договорные требования, сроки проекта, бюджетные ограничения и готовность соответствующего квалифицированного штата, инструментов и/или сред.
6.2.4.5 Заинтересованные стороны
Перечисляет заинтересованные стороны и их отношение к тестированию. Описывает как должен осуществляться обмен информацией с каждой заинтересованной стороной.
6.2.5 Обмен информацией о тестировании
Определяет связи между тестированием и другими действиями жизненного цикла и в организации.
Пример — Сюда могут быть включены полномочия для решения проблем, выявленных в результате действий тестирования, и полномочия для утверждения продуктов и процессов тестирования.
Эта информация может быть представлена в визуальной форме.
Примечание — Визуальное представление может представлять собой организационную схему или диаграмму потоков информации и данных.
Идентифицирует риски, которые охватывают тестирование по этому плану. Сюда должны быть включены любые соответствующие риски, которые могут быть определены в Организационной Стратегии Тестирования. Для каждого риска на основе его влияния и вероятности приводится уровень воздействия. Представляет рекомендации по обработке рисков. В этом разделе допускается предоставить ссылку на конкретный реестр рисков.
Пример — Рекомендациями по обработке рисков могут быть: устранить риск, уменьшить его или игнорировать риск.
Примечание — Реестр рисков может быть приведен в плане проекта или плане менеджмента рисков.
Идентифицирует связанные с тестированием риски продукта и предоставляет рекомендации по обработке каждого риска.
Пример — Связанные с тестированием риски продукта могут включать в себя дефекты функциональных или нефункциональных аспектов, таких как производительность.
Идентифицирует связанные с тестированием риски проекта продукта и предоставляет рекомендации по обработке каждого риска.
Пример — Связанные с тестированием риски проекта могут включать в себя риски, связанные с графиком или ресурсами.
6.2.7 Стратегия тестирования
Устанавливает подход к тестированию для определенного проекта тестирования или подпроцесса тестирования, как описано в следующих разделах. Документ может ссылаться на Организационную Стратегию Тестирования, указывая лишь отличия от нее.
6.2.7.1 Подпроцессы тестирования
Для Плана Тестирования проекта определяются надлежащие для выполнения подпроцессы тестирования.
6.2.7.2 Практические результаты тестирования
Идентифицирует все документы, которые должны быть получены в результате выполнения тестирования, или эквивалентную документальную информацию в электронной форме, например, в базах данных либо специализированных инструментах тестирования.
Пример — К результатам тестирования могут относиться следующие документы:
— Спецификация Проекта Тестирования;
— Спецификация Контрольного Примера;
— Спецификация Процедур Тестирования;
— Отчет о Готовности Тестовых Данных;
— Отчет о Готовности Тестовой Среды;
— Отчеты о Ходе Тестирования;
— Отчет о Завершении Тестирования.
Входные и выходные данные тестирования могут быть идентифицированы как компоненты результатов тестирования. Кроме того, могут быть включены инструменты тестирования, создаваемые как часть действия тестирования. В случаях объединения или исключения документов этот список соответственно изменяется.
Возможно включение информации о сроках представления документов и об адресате (желательно указывать должность, а не имя).
6.2.7.3 Методика проектирования тестирования
Определяет, какие методы проектирования тестирования должны применяться.
6.2.7.4 Критерии завершения тестирования
Определяет условия, при которых соответствующая организация тестирования предполагает завершение выполнения.
Пример — Это может быть при достижении конкретного покрытия, когда число выявленных дефектов меньше указанного предела.
6.2.7.5 Требуемые метрики
Определяет метрики, значения которых должны быть собраны во время выполнения тестирования.
6.2.7.6 Требования к Тестовым Данным
Определяет все соответствующие Требования к Тестовым Данным для проекта или подпроцесса тестирования (определенным образом).
Пример — Может быть идентифицирован источник тестовых данных и решено, где располагаются определенные тестовые данные, указано должны ли данные быть замаскированы по причинам конфиденциальности и/или перечислены ответственные за тестовые данные.
Определение этих требований к тестовым данным по необходимости может быть отложено до создания документа «Требования к Тестовым Данным» (см. 7.5).
6.2.7.7 Требования к Тестовой Среде
Определяет необходимые и желательные свойства тестовой среды.
Пример — В тестовую среду могут входить аппаратные средства, программное обеспечение, инструменты тестирования, базы данных и персонал (соответственно идентифицируя организации).
Включает в себя информацию о выборе, оценке, приобретении и поддержке каждого инструмента. Сюда также могут входить требования к тестовой среде для подготовки к тестированию, выполнению теста (включая сбор данных) и любых действий после выполнения.
Пример — Действием после выполнения теста может быть анализ данных.
Такие требования к тестовой среде при необходимости могут быть сформулированы позднее в документе «Требования к Тестовой Среде» (см. 7.6), однако ссылка на этот отдельный документ должна присутствовать в Плане Тестирования.
6.2.7.8 Повторное тестирование и регрессионное тестирование
Определяет условия, при которых будут выполняться повторное тестирование и регрессионное тестирование. Сюда может быть включено предполагаемое число циклов тестирования.
6.2.7.9 Критерии приостановки и возобновления
Определяет критерии, используемые для приостановки и возобновления всех или части действий тестирования Плана Тестирования. Определяет, кто ответственен за приостановку и возобновление действий тестирования. Определяет действия тестирования, которые, вероятно, придется повторить при возобновлении тестирования.
6.2.7.10 Отклонения от организационной стратегии тестирования
Должен быть указан каждый пункт Плана Тестирования, в котором имеются отклонения от Организационной Стратегии Тестирования. Когда это применимо, определяет лиц, ответственных за утверждение отклонений.
6.2.8 Действия и оценка тестирования
Определяет все необходимые действия тестирования на базе процесса тестирования, который будет использоваться. Необходимо рассмотреть итеративную стратегию действий при повторном выполнении тестирования, а также все зависимости.
Примечание — Действия тестирования могут быть описаны в терминах структурной схемы работ по операциям или карты действий в динамичных проектах.
Пример — Действия, которые могут быть рассмотрены, включают в себя и те из них, которые относятся к повторному тестированию и регрессионному тестированию.
Определяет оценку для каждого из идентифицированных действий тестирования, которые в соответствии с планом тестирования будут выполняться как часть тестирования. Кроме того, в соответствующих случаях описывает выделенные на тестирование бюджетные сметы расходов или представляет ссылку на эту информацию.
Примечание — Бюджетные сметы расходов могут быть приведены в плане проекта.
6.2.9 Комплектность персонала
Определяет требования к комплектности персонала для тестирования, соответствующего этому плану.
6.2.9.1 Роли, действия и ответственность
Обеспечивает общие сведения об основном персонале (лидерах деятельности) и вторичном персонале (не лидерах, а персонале поддержки) — лицах, исполняющих связанные с тестированием роли, с их соответствующими действиям тестирования ответственностями и полномочиями. Кроме того, определяет ответственных за предоставление элемента(ов) тестирования. Люди могут быть заняты полностью или частично.
Пример — К ответственным лицам могут быть отнесены менеджер проекта, менеджеры тестирования, разработчики, аналитики и исполнители тестирования, обслуживающий персонал, представители пользователя, персонал технической поддержки, администраторы данных и персонал поддержки качества.
В случае необходимости для каждого занятого тестированием лица должен быть определен период(ы).
6.2.9.2 Потребность в дополнительном персонале
Определяет конкретные потребности в дополнительных сотрудниках для тестирования, требуемых для проекта или подпроцесса тестирования. Указывает, когда сотрудники необходимы (временно, на полный или неполный рабочий день), и определяет желаемый набор навыков. Это может быть записано в контракте и бизнес-требованиях.
Примечание — Комплектность персонала может быть обеспечена внутренними переводами, наймом извне, консультантами, субподрядчиками, деловыми партнерами и/или аутсорсингом.
6.2.9.3 Потребность в обучении
Определяет для тестирования потребность в обучении и идентифицирует уровни квалификации и варианты обучения для обеспечения нужного персонала необходимыми навыками.
Пример — Обучение может иметь разные формы, включая такие варианты, как традиционное обучение в классе, рассчитанное на индивидуальную скорость обучения, компьютерное обучение, обучение через Интернет, посещение будущего сайта пользователя и наставничество более опытных сотрудников.
Идентифицирует этапы тестирования, определенные в графике проектных работ и в стратегии тестирования. Предоставляет обобщенное полное расписание действий тестирования, определяя, когда по результатам действия необходимо вернуться к процессам разработки, организационным и вспомогательным процессам. Определяет расписание для каждого действия тестирования и каждого этапа тестирования на основе оценки действия, имеющихся ресурсов и других ограничений.
Пример — Вспомогательными процессами могут быть процессы обеспечения качества и менеджмента конфигурации.

     6.3 Отчет о Ходе Тестирования

Отчет о Ходе Тестирования предоставляет информацию о состоянии тестирования, выполненного за определенный отчетный период времени.
Примечание — В случае динамичного проекта Отчет о Ходе Тестирования может быть в форме, отличной от печатного документа. Например, его содержание может обсуждаться на итеративных встречах и дополняться информацией, хранящейся в картах действий и диаграммах выполнения задач.
В A.2.5 (приложение A) представлен макет Отчета о Ходе Тестирования, а в G.1 и G.2 (приложение G) приводятся примеры создания Отчетов о Ходе Тестирования для двух различных проектов.
Содержание Отчета о Ходе Тестирования представлено ниже.
6.3.2 Спецификация документа
Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.
Примечание — Если документ хранится в электронной форме, например, в базе данных, то информация может быть помещена в начало или середину документа.
6.3.2.2 Уникальная идентификация документа
Однозначно определяет версию документа.
Пример — Уникальный идентификатор может содержать название документа, дату выпуска, версию и/или состояние документа (например, рассмотренный проект, исправленный или окончательный).
6.3.2.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда могут также быть включены имена авторов (автора).
6.3.2.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда могут также быть включены рецензенты и соответствующие менеджеры.
6.3.2.5 История изменений
Включает журнал всех изменений, которые произошли с документом, начиная с его начала.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящим изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
6.3.3.1 Область применения
Определяет степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение или в нем могут содержаться ссылки на другой документ, обеспечивающий общий глоссарий. Весь глоссарий или его часть и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию либо могут быть включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
Предоставляет информацию о состоянии тестирования в течение отчетного периода.
Определяет период времени, охваченный отчетом.
6.3.4.2 Прогресс относительно Плана Тестирования
Определяет прогресс выполнения Плана тестирования. Должны быть отмечены любые заметные отклонения от плана с объяснениями причин отклонения, описанием любых восстановительных действий, учетом влияния и анализа последствий для запланированных целей проекта.
6.3.4.3 Факторы, блокирующие прогресс
Идентифицирует факторы, препятствовавшие прогрессу в течение отчетного периода, и соответствующие реализованные решения их устранения. Должны быть документированы выясненные (нерешенные) проблемы, все еще препятствующие прогрессу, и определены возможные решения.
6.3.4.4 Показатели тестирования
Представляет собранные за отчетный период показатели тестирования.
Пример — Сюда могут входить показатели контрольных примеров, дефектов, инцидентов, тестового покрытия, прогресса и потребления ресурсов.
6.3.4.5 Новые и измененные риски
Перечисляет новые риски, которые были идентифицированы в результате мониторинга и управления тестированием, а также изменения в существующих рисках в течение отчетного периода.
6.3.4.6 Запланированное тестирование
Определяет тестирование, запланированное для следующего отчетного периода.

     6.4 Отчет о Завершении Тестирования

Отчет о Завершении Тестирования предоставляет собой сводку выполненного тестирования. Отчет может быть для проекта/программы в целом или для определенного подпроцесса тестирования.
В A.2.6 (приложение A) представлен макет Отчета о Завершении Тестирования, а в H.1 и H.2 (приложение H) приведены примеры создания Отчетов о Завершении Тестирования для двух различных проектов.
Содержание Отчета о Завершении Тестирования представлено ниже.
6.4.2 Спецификация документа
Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.
Примечание — Если документ хранится в электронной форме, например, в базе данных, то информация может быть помещена в начало или середину документа.
6.4.2.2 Уникальная идентификация документа
Однозначно определяет версию документа.
Пример — Уникальный идентификатор может содержать название документа, дату выпуска, версию и/или состояние документа (например, рассмотренный проект, исправленный или окончательный).
6.4.2.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда могут также быть включены имена авторов (автора).
6.4.2.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда также могут быть включены рецензенты и соответствующие менеджеры.
6.4.2.5 История изменений
Здесь представлен журнал всех изменений, которые произошли с документом, начиная с момента его создания.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящим изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
6.4.3.1 Область применения
Определяет степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение или в нем могут содержаться ссылки на другой документ, обеспечивающий общий глоссарий. Весь глоссарий или его часть и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию либо включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
6.4.4 Выполненное тестирование
Предоставляет описание выполненного тестирования.
6.4.4.1 Сводка выполненного тестирования
Суммирует в области применения этого отчета тестирование, выполненное в проекте и/или в подпроцессах тестирования.
Предоставляет подробную информацию о том, что было проверено и описывает все ограничения для выполнения тестирования.
Пример — Сюда могут входить ограничения на готовность тестовой среды.
6.4.4.2 Отклонения от Плана Тестирования
Описывает отклонения от Плана Тестирования, если таковые имеются. Для всех рисков, которые вызываются отклонениями тестирования, этот раздел может также ссылаться на раздел по остаточным рискам и их соответствующей обработке.
6.4.4.3 Оценка завершения тестирования
Определяет степень удовлетворения заданным критериям завершения тестирования и, по необходимости, объясняет, почему критерии не были достигнуты. Для всех рисков, которые вызываются не достижением критериев завершения, этот раздел может также ссылаться на раздел по остаточным рискам и их соответствующей обработке.
6.4.4.4 Препятствующие факторы
Описывает препятствующие прогрессу факторы и соответствующие решения, реализованные для их устранения.
6.4.4.5 Показатели тестирования
Представляет сопоставленные показатели тестирования.
Пример — Сюда могут входить показатели для контрольных примеров, дефектов, инцидентов, тестового покрытия, прогресса действия и потребления ресурсов.
Перечисляет риски, которые по завершении тестирования остались необработанными. Это могут быть риски, которые не были полностью обработаны тестированием и/или любые новые риски, идентифицированные в результате заключительного мониторинга и закрытия тестирования.
6.4.4.7 Практические результаты тестирования
Список всех результатов тестирования, полученных в результате тестовых испытаний, и их местонахождение.
Пример — Сюда могут входить План Тестирования, Спецификации Контрольных Примеров и Спецификации Процедур Тестирования.
6.4.4.8 Активы тестирования, допускающие повторное использование
Списки всех допускающих повторное использование активов тестирования и их местонахождение.
Пример — Сюда могут входить процедуры тестирования и тестовые данные, которые были произведены в результате тестовых испытаний.
Результаты обсуждения накопленного опыта.

     7 Документация Процессов Динамического Тестирования

     7.1 Общие сведения

Документы, разработанные в процессах динамического тестирования, разделяются на две категории:
— Спецификацию тестирования, в которую входят:
— Спецификация Проекта Тестирования;
— Спецификация Контрольных Примеров;
— Спецификация Процедур Тестирования;
Примечание — Это могут быть отдельные документы или отдельные главы Спецификации тестирования, а в зависимости от размера и характера проекта тестирования могут быть и главами проекта.
— Требования к Тестовым Данным;
— Требования к Тестовой Среде;
— Отчет о Готовности Тестовых Данных;
— Отчет о Готовности Тестовой Среды.
— Документацию выполнения теста, в которую входят:
— фактические результаты;
— практические результаты тестирования;
— Журнал Выполнения Теста;
Полные шаблоны документов с пояснением приводятся далее. В приложении А представлены схемы всех документов. В приложениях с I до S приведены примеры документации процесса динамического тестирования для организации.
Примечание — Существует множество стилей и названий документации, например, в динамичной разработке списки сеансов и главы с идеями тестирования. Предполагается, что при адаптированном соответствии, определенном в 2.2.2, названия документов могут быть изменены. Можно представить соответствие названий. В приложениях к настоящему стандарту приводятся примеры двух различных типов проекта с возможностью адаптации имен. В приложениях не приведены все возможные названия, форматы документов и методы тестирования. Назначение приложений — показать некоторые возможные варианты.

     7.2 Спецификация Проекта Тестирования

Спецификация Проекта Тестирования определяет функции, которые будут проверяться, и тестовые условия, полученные из базиса тестирования для каждой из функций в качестве первого шага для определения контрольных примеров и процедур тестирования, которые будут выполняться.
В A.2.7 (приложение A) представлен макет Спецификации Проекта Тестирования, а в I.1 и I.2 (приложение I) приводятся примеры, демонстрирующие, как для двух различных проектов могут быть разработаны Спецификации Проектов Тестирования.
Содержание Спецификации Проекта Тестирования представлено ниже.
7.2.2 Спецификация документа
Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.
Примечание — Если документ хранится в электронной форме, например, в базе данных, то информация может быть помещена в начало или середину документа.
7.2.2.2 Уникальная идентификация документа
Однозначно определяет версию документа.
Пример — Уникальный идентификатор может содержать название документа, даты выпуска, версии и/или состояния документа (например, рассмотренный проект, исправленный или окончательный).
7.2.2.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда могут также быть включены имена авторов (автора).
7.2.2.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда также могут быть включены рецензенты и соответствующие менеджеры.
7.2.2.5 История изменений
Сюда входит журнал всех изменений, которые произошли с документом, начиная с момента его создания.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящим изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
7.2.3.1 Область применения
Определяет степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации.
7.2.3.3 Условные обозначения
Определяет и объясняет все схемы идентификации или нумерации, используемые в наборах тестов и тестовых условиях, если это не определено в другом документе.
Примечание — Это может быть помещено в Плане Менеджмента Конфигурации.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение или в нем могут содержаться ссылки на другой документ, обеспечивающий общий глоссарий. Весь глоссарий или его часть и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию либо включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
Набор функций — это логическая группа функций, которые будут проверены в элементах тестирования в соответствии с Планом Тестирования. Функции, которые будут проверены, могут представлять собой один набор функций или множество наборов функций, возможно, расположенных в порядке иерархии. Наборы функций могут непосредственно соответствовать архитектуре элемента(ов) тестирования или отличаться, если это обеспечивает более эффективное тестирование. Набор функций может также быть бизнес-процессом, который состоит из ряда функций. В последующих действиях проекта тестирования каждый набор функций может быть обработан независимо от других наборов функций.
Наборы функций могут быть описаны в виде списков или таблиц в отдельном документе либо в составе инструмента.
Пример — Наборы функций могут храниться в базе данных или специализированном инструменте тестирования.
Содержание описания набора функций представлено ниже.
7.2.4.2 Уникальный идентификатор
Определяет уникальный идентификатор для набора функций, такой, чтобы он отличался от идентификатора любого другого набора функций. Генерацию идентификаторов может производить автоматизированный инструмент или это можно сделать вручную согласно соответствующей схеме нотации. Поскольку уникальный идентификатор используется для прослеживаемости, то он не должен меняться на протяжении времени жизни набора функций.
Определяет и кратко описывает особый акцент или цель набора функций.
Определяет при необходимости приоритет тестирования определенного набора функций.
7.2.4.5 Конкретная стратегия
Определяет реализацию стратегии тестирования набора функций.
Пример — Сюда в случае необходимости могут войти конкретные методы, использованные при проектировании тестирования, определенные в соответствующем Плане Тестирования.
Перечисляет ссылки на соответствующие функции базиса тестирования.
Примечание — Прослеживаемость может быть документирована в Матрице Прослеживаемости Тестирования или заложена в инструмент.
Пример — Функции могут представлять собой требования и/или описания разработки.
Обобщает тестовые условия для набора функций. Тестовое условие — отдельный элемент или событие, определенные в базисе тестирования, которые могут быть проверены одним или несколькими контрольными примерами.
Примечание — Тестовое условие может представлять собой простую ссылку на требование (если требование выражено поддающимся проверке способом, то есть если в него входит идентифицируемый критерий допустимости) или на текст проекта. Тестовое условие может также быть перефразированием требования, набором требований или описанием конструкции, созданной для тестирования, например, суммированием нескольких требований в модели таблицы решений или в модели состояния.
Этот раздел Спецификации Проекта Тестирования может быть оформлен таким образом, чтобы тестовые условия были перечислены под соответствующими наборами функций.
Примечание — Тестовые условия могут быть определены в виде списков или таблиц в документе или в используемом инструменте, например, в базе данных или специализированном инструменте тестирования. Тестовые условия формально документируются не всегда, поскольку их можно рассматривать как первый проект элементов тестового покрытия и/или контрольных примеров.
Содержание описания тестовых условий представлено ниже.
7.2.5.2 Уникальный идентификатор
Определяет уникальный идентификатор для тестового условия — такой, чтобы он отличался от идентификатора любого другого тестового условия. Генерацию идентификаторов может производить автоматизированный инструмент или это можно сделать вручную согласно соответствующей схеме нотации. Поскольку уникальный идентификатор используется для прослеживаемости, то он не должен меняться на протяжении времени жизни тестового условия.
Если количество или волатильность тестовых условий настолько высоки, что требования уникальности идентификаторов становятся непрактичными, то для прослеживаемости между контрольными примерами и тестовыми условиями вместо этого используются другие средства, обычно на базе автоматизированных инструментов.
Определяет тестовое условие, которое может быть проверено. Оно может быть записано на естественном языке и/или, по необходимости, выражено в виде табличной или графической модели. Может представлять собой простую ссылку на требование, которое является тестовым условием.
Определяет приоритет тестирования данного конкретного тестового условия в наборе функций. Тестовые условия с высоким приоритетом будут проверяться раньше и более экстенсивно, чем тестовые условия с приоритетом ниже.
Определяет прослеживаемость с набором функций или предоставляет список ссылок на соответствующие требования и/или описание конструкции в базисе тестирования. Может быть документировано в Матрице Прослеживаемости Тестирования.

     7.3 Спецификация Контрольных Примеров

Спецификация Контрольных Примеров определяет элементы тестового покрытия и соответствующие контрольные примеры, полученные из базиса тестирования для одного или более наборов функций.
В A.2.8 (приложение A) представлен макет Спецификации Контрольных Примеров, а в J.1 и J.2 (приложение J) приводятся примеры двух различных проектов, в которых показано, как могут быть разработаны Спецификации Контрольных Примеров.
Содержание Спецификации Контрольных Примеров представлено ниже.
7.3.2 Спецификация документа
Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.
Примечание — Если документ хранится в электронной форме, например, в базе данных, то информация может быть помещена в начало или середину документа.
7.3.2.2 Уникальная идентификация документа
Однозначно определяет версию документа.
Пример — Уникальный идентификатор может содержать название документа, дату выпуска, версию и/или состояние документа (например, рассмотренный проект, исправленный или окончательный).
7.3.2.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда могут также быть включены имена авторов (автора).
7.3.2.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда также могут быть включены рецензенты и соответствующие менеджеры.
7.3.2.5 История изменений
Сюда входит журнал всех изменений, которые произошли с документом, начиная с момента его создания.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящим изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
7.3.3.1 Область применения
Определяет степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации.
7.3.3.3 Условные обозначения
Определяет и объясняет любую идентификацию или нумерации, необходимые для элементов тестового покрытия и контрольных примеров, если это не определено в другом месте.
Примечание — Может быть размещено в Плане Менеджмента Конфигурации.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение или в нем могут содержаться ссылки на другой документ, обеспечивающий общий глоссарий. Весь глоссарий или его часть и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию либо включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
7.3.4 Элементы тестового покрытия
Обобщает элементы тестового покрытия для тестовых условий. Элементы тестового покрытия получаются путем применения методики проектирования тестирования к тестовому условию.
Пример — Разбиение эквивалентности определяет элементы тестового покрытия с точки зрения действительных и недопустимых разделов эквивалентности.
Этот раздел Спецификации Контрольных Примеров может быть оформлен в виде списков элементов тестового покрытия под соответствующими наборами функций и/или тестовыми условиями.
Примечание — Элементы тестового покрытия могут быть определены в виде списков или таблиц в документе либо в используемом инструменте, например, в базе данных или специализированном инструменте тестирования. Элементы тестового покрытия формально документируются не всегда, поскольку их можно рассматривать как проект контрольных примеров.
Содержание описания элемента тестового покрытия приводится далее.
7.3.4.2 Уникальный идентификатор
Определяет уникальный идентификатор для элемента тестового покрытия такой, чтобы его можно было отличить от идентификаторов всех других элементов тестового покрытия. Генерацией идентификаторов может управлять автоматизированный инструмент или это может быть сделано вручную соответственно применяемой схеме нотации. Уникальный идентификатор не должен быть изменен в течение времени жизни элемента тестового покрытия, потому что он необходим для обеспечения прослеживаемости.
Если количество или волатильность тестовых условий настолько высоки, что требования уникальности идентификаторов становятся непрактичными, то для прослеживаемости между контрольными примерами и тестовыми условиями вместо таких идентификаторов используются другие средства, обычно на базе автоматизированных инструментов.
Определяет элемент тестового покрытия, который, как ожидается, будет охвачен контрольным примером в соответствии с методикой проектирования тестирования, использованной для его получения. Сюда может также быть включена дополнительная информация об элементе покрытия.
Пример — Является ли раздел эквивалентности действительным или недействительным разделом.
Определяет в случае необходимости приоритет тестирования конкретного элемента тестового покрытия в тестовом условии. Элементы тестового покрытия с более высоким приоритетом будут проверяться раньше элементов тестового покрытия с приоритетами ниже.
Определяет прослеживаемость с тестовыми условиями либо набором функций, к которому принадлежит элемент тестового покрытия, или же предоставляет список ссылок на соответствующий базис тестирования. Может быть документировано в Матрице Прослеживаемости Тестирования.
Пример — Базис тестирования может представлять собой требования или конструкцию.
7.3.5 Контрольные примеры
Определяет контрольные примеры, полученные из элементов тестового покрытия. Контрольный пример показывает, как осуществляются один или несколько элементов тестового покрытия, чтобы помочь определить корректность реализации элемента тестирования.
Число контрольных примеров, полученных из элементов тестового покрытия, будет зависеть от критерия тестового покрытия, определенного в Плане Тестирования.
Этот раздел Спецификации Проекта Тестирования может быть оформлен таким образом, чтобы контрольные примеры были перечислены под соответствующими наборами функций и/или тестовыми условиями.
Примечание — Контрольные примеры могут быть определены в виде списков либо таблиц в документе или в используемом инструменте, например, в базе данных или специализированном инструменте тестирования.
Содержание описания контрольного примера приводится ниже.
7.3.5.2 Уникальный идентификатор
Определяет уникальный идентификатор для контрольного примера — такой, чтобы его можно было отличить от идентификаторов всех других контрольных примеров. Генерацией идентификаторов может управлять автоматизированный инструмент или это может быть сделано вручную соответственно применяемой схеме нотации. Уникальный идентификатор не должен быть изменен в течение времени жизни контрольного примера, потому что он необходим для обеспечения прослеживаемости.
Определяет и кратко описывает особый акцент или цель контрольного примера. Это обычно оформляется в заголовке.
Определяет в случае необходимости приоритет тестирования данного конкретного контрольного примера. Контрольные примеры с высоким приоритетом будут выполнены раньше контрольных примеров с приоритетом ниже.
Определяет прослеживаемость с элементом тестового покрытия, который реализуется контрольным примером, или предоставляет список ссылок на соответствующие требования либо описание конструкции в базисе тестирования. Может быть документировано в Матрице Прослеживаемости Тестирования.
Определяет требуемое состояние тестовой среды и любые специальные ограничения, имеющие отношение к выполнению контрольного примера.
Пример — Состояние, в котором должен быть элемент тестирования перед запуском выполнения, включая наличие конкретных тестовых данных и текущих активных форм или экранов.
Исходные условия могут быть заданы явно или представлять собой ссылки на другие контрольные примеры, при выполнении которых будут установлены исходные условия.
Необходимые условия могут быть описаны для одного или более наборов функций. Они могут быть не представлены в этой спецификации, если достаточно их описания в Плане Тестирования.
Определяет каждое действие, требуемое для приведения элемента тестирования в состояние, при котором ожидаемые результаты можно сравнить с фактическими результатами. Описание подробностей должно быть соответственно адаптировано к уровню подготовки исполнителей тестирования.
Примечание — Это может потребовать предоставления для элемента тестирования входных данных и/или событий, например нажатия кнопок. Некоторые входные данные могут быть определены значениями, а другие — наименованиями. Необходимо учесть таблицы констант, файлы транзакций, базы данных, файлы, терминальные сообщения, резидентные области и значения, переданные операционной системой.
Должны быть описаны все требуемые отношения между входными событиями.
Пример — Отношение может быть синхронизацией.
Действия, в случае необходимости, могут быть пронумерованы в контрольном примере.
7.3.5.8 Ожидаемые результаты
Определяет ожидаемые выходные данные и поведение элемента тестирования, требуемые в ответ на входные данные, поступившие в элемент тестирования в состоянии исходных условий. Представляет ожидаемые величины (с допусками, где это необходимо) для всех требуемых выходов.
Пример — Требуемое поведение элемента тестирования может быть временем отклика.
Здесь также могут быть определены действия, необходимые для сравнения ожидаемых результатов с фактическими. Например, анализ выхода в поле, не активное после поступления входных данных, ожидание запуска пакетного задания, распечатки и анализа отчета или закрытие элемента тестирования и его перезапуск для анализа сохраненных данных.
7.3.5.9 Фактические результаты и результат тестирования
В описание контрольного примера могут быть включены пустые поля для записи фактических результатов и/или результата выполнения контрольного примера. Кроме того, такие поля могут также быть внесены в Спецификацию Процедур Тестирования (см. 7.4), или раздельно в Фактические результаты (см. 7.9), и/или в результат тестирования (см. 7.10).

     7.4 Спецификация Процедур Тестирования

Спецификация Процедур Тестирования представляет в порядке выполнения контрольные примеры в заданных наборах тестов вместе со всеми соответствующими действиями, которые могут потребоваться для установки начальных исходных условий, и всеми необходимыми действиями после выполнения примеров.
Примечание — Процедуры тестирования могут быть определены в виде списков или таблиц в документе или в используемом инструменте, например, в базе данных или специализированном инструменте тестирования.
В A.2.9 (приложение A) представлен макет Спецификации Процедур Тестирования, а в K.1 и K.2 (приложение K) приводятся примеры двух различных проектов, в которых показано, как могут быть разработаны Спецификации Процедур Тестирования.
Содержание Спецификации Процедур Тестирования представлено далее.
7.4.2 Спецификация документа
Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.
Примечание — Если документ хранится в электронной форме, например, в базе данных, то информация может быть помещена в начало или середину документа.
7.4.2.2 Уникальная идентификация документа
Однозначно определяет версию документа.
Пример — Уникальный идентификатор может содержать название документа, дату выпуска, версию и/или состояние документа (например, рассмотренный проект, исправленный или окончательный).
7.4.2.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда также могут быть включены имена авторов (автора).
7.4.2.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда также могут быть включены рецензенты и соответствующие менеджеры.
7.4.2.5 История изменений
Сюда входит журнал всех изменений, которые произошли с документом, начиная с момента его создания.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящим изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
7.4.3.1 Область применения
Определяет степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации.
7.4.3.3 Условные обозначения
Определяет и объясняет все схемы идентификации или нумерации, используемые в наборах тестов и процедурах тестирования, если это не определено в другом документе.
Примечание — Может быть размещено в Плане Менеджмента Конфигурации.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение или в нем могут содержаться ссылки на другой документ, обеспечивающий общий глоссарий. Весь глоссарий или его часть и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию либо включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
Определяет объединение контрольных примеров в наборы тестов для тестирования с конкретной целью тестирования. Как правило, наборы тестов обычно отражают наборы функций, однако в них могут входить контрольные примеры для нескольких наборов функций. Контрольные примеры для набора тестов могут отбираться на основе идентифицированных рисков, базиса тестирования, повторного тестирования и/или регрессионного тестирования.
Примечание — Наборы тестов могут быть определены в виде списков или таблиц в документе либо в используемом инструменте, например, в базе данных или специализированном инструменте тестирования. Наборы тестов формально документируются не всегда, поскольку их можно рассматривать как промежуточный шаг создания процедур тестирования.
Содержание описания набора тестов приводится ниже.
7.4.4.2 Уникальный идентификатор
Определяет уникальный идентификатор для набора тестов — такой, чтобы его можно было отличить от идентификатора любого другого набора тестов. Генерацией идентификаторов может управлять автоматизированный инструмент или это может быть сделано вручную соответственно применяемой схеме нотации. Уникальный идентификатор не должен быть изменен в течение времени жизни набора тестов, потому что он необходим для обеспечения прослеживаемости.
Определяет и кратко описывает особый акцент или цель для набора тестов.
Пример — «Этот набор тестов предназначен для повторного тестирования коррекций по инцидентам IN301 и IN56».
Определяет, в случае необходимости, приоритет тестирования для данного конкретного набора тестов.
7.4.4.5 Содержание (Прослеживаемость)
Обобщает содержание набора тестов. Обычно это представлено списком уникальных идентификаторов отобранных контрольных примеров.
7.4.5 Процедуры тестирования
Описывает процедуры тестирования, которые были получены для наборов тестов. Процедура тестирования определяет порядок, в котором должны быть выполнены контрольные примеры соответствующего набора тестов согласно зависимостям, описанным в исходных условиях и постусловиях, и другим требованиям тестирования.
Примечание — Процедуры тестирования могут быть определены в виде списков или таблиц в документе либо в используемом инструменте, например, в базе данных или специализированном инструменте тестирования.
Содержание описания процедуры тестирования приводится ниже.
7.4.5.2 Уникальный идентификатор
Определяет уникальный идентификатор для процедуры тестирования — такой, чтобы его можно было отличить от идентификаторов всех других процедур тестирования. Генерацией идентификаторов может управлять автоматизированный инструмент или это может быть сделано вручную соответственно применяемой схеме нотации. Уникальный идентификатор не должен быть изменен в течение времени жизни процедуры тестирования, потому что он необходим для обеспечения прослеживаемости.
Идентифицирует и кратко описывает особый акцент или цель процедуры тестирования. Идентична цели соответствующего набора тестов.
Определяет, в случае необходимости, приоритет данной конкретной процедуры тестирования. Идентичен приоритету соответствующего набора тестов.
Определяет необходимые действия подготовки к выполнению контрольных примеров, определенных в процедуре тестирования. Обычно это действия по установлению исходных условий для первого выполняемого контрольного примера.
7.4.5.6 Выполняемые контрольные примеры (Прослеживаемость)
Перечисляет контрольные примеры в том порядке, в котором они должны быть выполнены. Контрольные примеры могут быть пронумерованы в процедуре тестирования последовательно. Может быть определена степень возможного изменения процедуры.
Этот список может представлять собой ссылку на контрольные примеры или может быть копией списка контрольных примеров.
Если выполнение одного или более контрольных примеров в процедуре не устанавливает исходные условия для следующего контрольного примера, то между контрольными примерами могут быть определены дополнительные действия для установки исходных условий.
В описание процедуры тестирования могут быть включены пустые поля для записи фактических результатов и/или результата тестирования во время выполнения контрольного примера. Кроме того, фактические результаты и/или результат тестирования могут быть также записаны в Фактические Результаты (см. 7.9) и/или в Результат Тестирования (см. 7.10).
7.4.5.7 Связь с другими процедурами
Определяет зависимости, которые данная процедура тестирования может иметь с любыми другими процедурами тестирования.
Примерами зависимостей от других процедур тестирования являются: «они выполняются перед этой», «одновременно с этой» или «после этой».
7.4.5.8 Остановка и заключительные действия
Определяет действия, необходимые для осуществления правильной остановки и после завершения выполнения процедуры.
Пример — Действия могут быть завершением записи протокола или сбросом базы данных тестирования.

     7.5 Требования к Тестовым Данным

Требования к Тестовым Данным описывают свойства тестовых данных, необходимые для выполнения процедур тестирования, определенных в Спецификации Процедур Тестирования.
В A.2.10 (приложение A) представлен макет Требований к Тестовым Данным, а в L.1 и L.2 (приложение L) приводятся примеры двух различных проектов, в которых показано, как могут быть разработаны Требования к Тестовым Данным.
Содержание Требований к Тестовым Данным представлено далее.
7.5.2 Спецификация документа
Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.
Примечание — Если документ хранится в электронной форме, например, в базе данных, то информация может быть помещена в начало или середину документа.
7.5.2.2 Уникальная идентификация документа
Однозначно определяет версию документа.
Пример — Уникальный идентификатор может содержать название документа, дату выпуска, версию и/или состояние документа (например, рассмотренный проект, исправленный или окончательный).
7.5.2.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда могут также быть включены имена авторов (автора).
7.5.2.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда также могут быть включены рецензенты и соответствующие менеджеры.
7.5.2.5 История изменений
Сюда входит журнал всех изменений, которые произошли с документом, начиная с момента его создания.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящим изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
7.5.3.1 Область применения
Идентифицирует степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение или в нем могут содержаться ссылки на другой документ, обеспечивающий общий глоссарий. Весь глоссарий либо его часть и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию либо включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
7.5.4 Подробные Требования к Тестовым Данным
Определяет данные, необходимые для выполнения процедур тестирования, определенных в Спецификации Процедур Тестирования. Сюда могут быть включены любые требования по обезличиванию данных.
Пример — Тестовые данные могут содержать смоделированные производственные данные, такие как данные об учетной записи пользователя и данные о клиентах.
Данные могут быть разделены на части, отражающие структуру данных элемента тестирования.
Пример — Данные могут быть определены в диаграмме классов или диаграмме сущностей и связей.
Содержание описания требований к тестовым данным приводится далее.
7.5.4.2 Уникальный идентификатор
Определяет уникальный идентификатор для Требования к Тестовым Данным — такой, чтобы его можно было отличить от идентификаторов всех других требований к тестовым данным. Генерацией идентификаторов может управлять автоматизированный инструмент или это может быть сделано вручную соответственно применяемой схеме нотации. Уникальный идентификатор не должен быть изменен в течение времени жизни Требования к Тестовым Данным, потому что он необходим для обеспечения прослеживаемости.
Определяет конкретное имя и требуемые значения или диапазоны значений для каждого элемента тестовых данных. Здесь также может быть определено, что данные должны быть сделаны анонимными или ими нужно управлять другими способами.
Пример — «По крайней мере 10 потребителей должны быть в базе данных с полным и корректным идентификатором и всей другой обязательной информацией о потребителе».
Определяет, кто ответственен за предоставление доступа к тестовым данным.
7.5.4.5 Необходимый период
Идентифицирует, когда и как долго необходимы тестовые данные. Тестовые данные могут быть необходимы в течение одного неразделенного периода или в течение нескольких отдельных периодов.
7.5.4.6 Необходимость сброса
Определяет, должны ли тестовые данные быть сброшены в ходе тестирования.
7.5.4.7 Архивация или утилизация
Идентифицирует, когда и как тестовые данные нужно заархивировать или необходимо избавиться от них после завершения тестирования.

     7.6 Требования к Тестовой Среде

Требования к Тестовой Среде описывают свойства тестовой среды, необходимые для выполнения процедур тестирования, определенных в Спецификации Процедур Тестирования. По необходимости в этом документе может быть приведена ссылка на документ с соответствующей информацией.
Пример — Информация может быть представлена в Организационной Стратегии Тестирования, Плане Тестирования или Спецификации Тестирования.
В A.2.11 (приложение A) представлен макет Требований к Тестовой Среде, а в M.1 и M.2 (приложение M) приводятся примеры двух различных проектов, в которых показано, как могут быть разработаны Требования к Тестовой Среде.
Содержание документа «Требования к Тестовой Среде» представлено далее.
7.6.2 Спецификация документа
Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.
Пример — Если документ хранится в электронной форме, например, в базе данных, то информация может быть помещена в начало или середину документа.
7.6.2.2 Уникальная идентификация документа
Однозначно определяет версию документа.
Пример — Уникальный идентификатор может содержать название документа, дату выпуска, версию и/или состояние документа (например, рассмотренный проект, исправленный или окончательный).
7.6.2.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда могут также быть включены имена авторов (автора).
7.6.2.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда также могут быть включены рецензенты и соответствующие менеджеры.
7.6.2.5 История изменений
Сюда входит журнал всех изменений, которые произошли с документом, начиная с момента его создания.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящим изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
7.6.3.1 Область применения
Идентифицирует степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение или в нем могут содержаться ссылки на другой документ, обеспечивающий общий глоссарий. Весь глоссарий или его часть и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию либо включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
7.6.4 Подробные Требования к Тестовой Среде
Идентифицирует элементы среды, необходимые для выполнения процедур тестирования, определенные в Спецификации Процедур Тестирования. Сюда входит установка для выполнения процедур тестирования перед их выполнением и для любых действий после выполнения теста.
Пример — Элементы среды можно разделить на следующие виды, хотя в зависимости от конкретных требований могут потребоваться и другие виды:
— промежуточное программное обеспечение;
— программное обеспечение;
— периферийные устройства, например, принтеры;
— средства обмена информацией, например, веб-доступ;
— место проведения, например, размер помещения и уровень фонового шума;
— аксессуары, например, специальные предпечатные бумажные формы.
Примечание — Элементы среды могут быть сгруппированы по другим критериям, например, WindowsXP/Vista/Windows7 или различные входные интерфейсы, подключенные к ПК, если это лучше подходит. Сюда могут быть включены описания конкретных конфигураций, в которых должны использоваться и/или повторно использоваться эти элементы.
На практике тестовая среда обычно не является идеальным представлением рабочей среды, и подробные требования должны отразить степень представления рабочей среды тестовой средой.
Содержание описания элемента тестовой среды приводится далее.
7.6.4.2 Уникальный идентификатор
Определяет уникальный идентификатор для элемента среды — такой, чтобы его можно было отличить от идентификаторов всех других элементов среды. Генерацией идентификаторов может управлять автоматизированный инструмент или это может быть сделано вручную соответственно применяемой схеме нотации. Уникальный идентификатор не должен быть изменен в течение времени жизни элемента тестовой среды, потому что он необходим для обеспечения прослеживаемости.
Идентифицирует элемент среды в достаточных для него деталях для того, чтобы получить его в соответствии с ожиданием.
Пример — Сюда могут входить точно определенные аппаратные средства или программное обеспечение в конкретных версиях и конкретных конфигурациях. Здесь также могут быть перечислены требуемые пакетные задания, которые должны быть выполнены во время тестирования в определенные моменты для обеспечения процесса тестирования.
Определяет, кто ответственен за предоставление доступа к элементу среды.
7.6.4.5 Необходимый период
Идентифицирует, когда и как долго необходим элемент среды. Элемент среды может быть необходим в течение одного неразделенного периода или в течение нескольких отдельных периодов.

     7.7 Отчет о Готовности Тестовых Данных

Отчет о Готовности Тестовых Данных описывает выполнение каждого Требования к Тестовым Данным.
В A.2.12 (приложение A) представлен макет Отчета о Готовности Тестовых Данных, а в N.1 и N.2 (приложение N) приводятся примеры двух различных проектов, в которых показано, как могут быть разработаны Отчеты о Готовности Тестовых Данных для двух различных проектов.
Содержание Отчета о Готовности Тестовых Данных представлено ниже.
7.7.2 Спецификация документа
Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.
Пример — Если документ хранится в электронной форме, например в базе данных, то информация может быть помещена в начало или середину документа.
7.7.2.2 Уникальная идентификация документа
Однозначно определяет версию документа.
Пример Уникальный идентификатор может содержать название документа, даты выпуска, версии и/или состояния документа (например, проект, рассмотренный, исправленный, финал).
7.7.2.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда могут также быть включены имена авторов (автора).
7.7.2.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда также могут быть включены рецензенты и соответствующие менеджеры.
7.7.2.5 История изменений
Сюда входит журнал всех изменений, которые произошли с документом, начиная с момента его создания.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящим изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
7.7.3.1 Область применения
Идентифицирует степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение или в нем могут содержаться ссылки на другой документ, обеспечивающий общий глоссарий. Весь глоссарий или его часть и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию либо включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
7.7.4 Состояние Тестовых Данных
Обеспечивает состояние для каждого Требования к Тестовым Данным. Это может быть отмечено в заполнителе в документе Требований к Тестовым Данным.
Содержание описания каждого элемента данных включает в себя:
7.7.4.2 Уникальный идентификатор
Уникальный идентификатор используется в документе Требования к Тестовым Данным.
7.7.4.3 Описание состояния
Определяет состояние требуемого элемента тестовых данных. Состояние может содержать описание того, как фактические тестовые данные отклоняются от требований, например с точки зрения значений или объема.

     7.8 Отчет о Готовности Тестовой Среды

Отчет о Готовности Тестовой Среды описывает выполнение каждого требования к тестовой среде.
В A.2.13 (приложение A) представлен макет Отчета о Готовности Тестовой Среды, а в O.1 и O.2 (приложение O) приведены примеры, которые демонстрируют, как Отчеты о Готовности Тестовой Среды могут быть разработаны для двух различных проектов.
Содержание Отчета о Готовности Тестовой Среды представлено ниже.
7.8.2 Спецификация документа
Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.
Пример — Если документ хранится в электронной форме, например, в базе данных, то информация может быть помещена в начало или середину документа.
7.8.2.2 Уникальная идентификация документа
Однозначно определяет версию документа.
Пример — Уникальный идентификатор может содержать название документа, дату выпуска, версию и/или состояние документа (например, рассмотренный проект, исправленный или окончательный).
7.8.2.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда также могут быть включены имена авторов (автора).
7.8.2.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда также могут быть включены рецензенты и соответствующие менеджеры.
7.8.2.5 История изменений
Включает журнал всех изменений, которые произошли с документом, начиная с его начала.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящим изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
7.8.3.1 Область применения
Идентифицирует степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение или в нем могут содержаться ссылки на другой документ, обеспечивающий общий глоссарий. Весь глоссарий или его часть и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию либо включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
7.8.4 Готовность тестовой среды
Представляет подтверждения выполнения каждого требования к тестовой среде. Это может быть отмечено в соответствующих отведенных полях документа «Требования к Тестовой Среде».
Содержание описания каждого элемента среды включает в себя:
7.8.4.2 Уникальный идентификатор
Уникальный идентификатор используется в документе «Требования к Тестовой Среде».
7.8.4.3 Описание состояния
Определяет выполнение пункта Требований к Тестовой Среде.
Пример — Подтверждение выполнения может включать в себя описание отклонений фактической тестовой среды от требований, например, с точки зрения версий или конфигурации.
Примечание — Этот раздел также может быть использован для того, чтобы отметить готовность конкретных элементов тестовой среды (например, других приложений, которые интегрированы с элементом тестирования), поскольку в случае недоступности они могут повлиять на тестирование.

     7.9 Фактические Результаты

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

     7.10 Результат Тестирования

Результат тестирования — это запись о том, прошло ли успешно выполнение конкретного контрольного примера или нет, то есть соответствуют ли фактические результаты ожидаемым либо наблюдались отклонения или запланированное выполнение контрольного примера невозможно.
Результат тестирования для контрольного примера обычно документируется непосредственно в процедуре тестирования в специальном зарезервированном для этого поле, поэтому результат тестирования обычно не рассматривается как независимый документ.
Пример — Если контрольный пример выполнен удачно, то это может быть отмечено галочкой или подобным знаком, однако в случае, если контрольный пример выполнен неудачно, это можно отметить номером отчета об инцидентах, создаваемого в результате такого отклонения. Если контрольный пример не может быть выполнен, это отмечается пометкой «блокировано» с описанием блокирования, если это возможно.
Иногда этот процесс полностью автоматизирован посредством инструмента, сравнивающего фактические результаты с ожидаемыми результатами и предоставляющего отчет о прошедших контрольных примерах, отказах или случаях невозможности выполнения.
Примечание — Иногда в качестве результата тестирования употребляют альтернативу «Прошел/Не прошел».

     7.11 Журнал Выполнения Теста

Детали записей выполнения одной или более процедур тестирования.
Процедуры тестирования могут быть определены в виде списков или таблиц в документе или в используемом инструменте, например, в базе данных или специализированном инструменте тестирования.
В A.2.14 (приложение А) представлен макет Журнала Выполнения Теста, а в R.1 и R.2 (приложение R) приводятся примеры двух различных проектов, в которых показано, как может быть разработан Журнал Выполнения Теста.
Содержание Журнала Выполнения Теста представлено ниже.
7.11.2 Спецификация документа
Здесь представлена информация, которая идентифицирует документ, определяет его источники и историю.
Пример — Если документ хранится в электронной форме, например, в базе данных, то информация может быть помещена в начало или середину документа.
7.11.2.2 Уникальная идентификация документа
Однозначно определяет версию документа.
Пример — Уникальный идентификатор может содержать название документа, дату выпуска, версию и/или состояние документа (например, рассмотренный проект, исправленный или окончательный).
7.11.2.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда также могут быть включены имена авторов и тестеров, если они не совпадают.
7.11.2.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда также могут быть включены рецензенты и соответствующие менеджеры.
7.11.2.5 История изменений
Сюда входит журнал всех изменений, которые произошли с документом, начиная с момента его создания.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящим изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
7.11.3.1 Область применения
Идентифицирует степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение или в нем могут содержаться ссылки на другой документ, обеспечивающий общий глоссарий. Весь глоссарий или его часть и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию либо включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
Перечисляет значительные события, происходящие во время выполнения одной или более процедур тестирования.
Пример — Первым событием может быть запуск сеанса выполнения теста и последним — заключительное закрытие сеанса выполнения теста.
Кроме того, примеры событий, которые должны быть записаны, включают в себя:
— внезапное понижение производительности компьютера, на котором выполняется тестирование;
— отказ, делающий невозможным дальнейшее выполнение тестирования;
— перебои в тестовой среде, приводящие к ненадежности фактических результатов.
Содержание описания каждого события, зарегистрированного в Журнале Выполнения Теста, представлено ниже.
7.11.4.2 Уникальный идентификатор
Определяет порядковый номер записи в Журнале Выполнения Теста.
Определяет точное время, включая, по необходимости, дату, когда произошло событие.
Описывает то, что произошло. По необходимости, может содержать ссылку на процедуру тестирования и контрольный пример, при выполнении которых произошло событие.
Там, где применимо, описывает влияние на выполнение теста и/или фактический результат.

     7.12 Отчетность об Инцидентах Тестирования

Инцидент тестирования — это любая проблема, которая возникла во время тестирования, требующего регистрации действий. Инциденты тестирования регистрируются в Отчетах по Инцидентам. Для каждого уникального инцидента создается Отчет об Инциденте (Отчеты об Инцидентах могут называться отчетами о дефектах, ошибках, сбоях и т.д.).
Отчеты об Инцидентах могут быть представлены в виде списков или таблиц, помещенных в документе или в используемом инструменте, например, базе данных или специализированном инструменте отслеживания ошибок.
Формат Отчета об Инциденте может быть определен в другом документе организации, например, как в составе Процессов Управления Инцидентами, в таком случае нужно использовать именно его.
7.12.2 Отчет об Инциденте
В данном контексте Отчет об Инциденте документирует инцидент, выявленный во время тестирования.
1 Инциденты могут происходить и быть выявлены и в других условиях, например, неоднозначности в спецификации бизнес-требований, обнаруженные во время проектирования программного обеспечения, или программные ошибки, возникшие во время производства.
2 Приведенная здесь информация является только такой информацией, которая необходима для создания первого Отчета об Инциденте. Для обработки посредством более широкого процесса управления инцидентами к Отчету об Инциденте может быть добавлено больше информации.
В A.2.15 (приложение A) представлен макет Отчета об Инциденте, а в S.1 и S.2 (приложение S) приводятся примеры двух различных проектов, в которых показано, как может быть разработан Отчет об Инциденте.
Содержание Отчета об Инциденте представлено ниже.
7.12.3 Спецификация документа
Здесь представлена информация, которая идентифицирует документ, определяет его источники и историю.
1 Если документ хранится в электронной форме, например, в базе данных, то информация может быть помещена в начало или середину документа.
2 Уникальный идентификатор может включать название документа, даты выпуска, версии и/или состояния документа (например, проект, рассмотренный, исправленный, финал).
7.12.3.2 Уникальная идентификация документа
Однозначно определяет версию документа.
7.12.3.3 Оформляющая организация
Определяет организацию, ответственную за подготовку и выпуск документа. Сюда также могут быть включены имена авторов.
7.12.3.4 Полномочия по утверждению
Идентифицирует назначенное лицо (лиц), которое несет ответственность за рассмотрение и утверждение (подпись) документа (возможно в электронном виде). Сюда также могут быть включены рецензенты и соответствующие менеджеры.
7.12.3.5 История изменений
Сюда входит журнал всех изменений, которые произошли с документом, начиная с момента его создания.
1 Сюда может входить список, который содержит текущую версию документа и все предшествующие документы, уникальную идентификацию каждого документа, описание изменений документа относительно предыдущего документа в списке, причины изменений, авторство и роль лица, вносящего изменения.
2 К причинам изменений могут относиться замечания аудита, анализ разработчиков, изменения системы. Лицом, вносящим изменения, может быть автор документа, менеджер проекта, владелец системы.
Предоставляет разъясняющую информацию о содержании и структуре документа.
7.12.4.1 Область применения
Идентифицирует степень покрытия предметной области документом и указывает все включения, исключения, предположения и/или ограничения.
Перечисляет нормативные ссылки и определяет хранилища для систем, программного обеспечения и информации о тестировании. Ссылки могут быть разделены на «внутренние» ссылки организации и «внешние» ссылки, которые не относятся к организации.
Представляет собой словарь терминов, сокращений и аббревиатур, если таковые используются в документе.
Примечание — Этот раздел может быть оформлен как приложение или в нем могут содержаться ссылки на другой документ, обеспечивающий общий глоссарий. Весь глоссарий или его часть и/или список аббревиатур могут быть в составе онлайнового отдельного глоссария по тестированию либо включены в больший организационный глоссарий, содержащий большое количество терминов, не связанных с тестированием.
Содержание описания впервые выявленного инцидента приводится далее.
7.12.5.1 Информация о времени
Записываются даты (и возможно время), когда инцидент первый раз был выявлен.
Определяет имена и должности лиц, идентифицировавших инцидент.
Идентифицирует контекст, в котором выявлен инцидент.
Пример — Сюда могут входить:
— Элемент конфигурации, включая его уникальную идентификацию, в котором произошел инцидент. В контексте тестирования таким элементом обычно будет элемент тестирования, но это может быть и другой элемент конфигурации, например, Спецификация Тестирования;
— Процедура Тестирования и Контрольный Пример с их уникальными идентификаторами, при выполнении которых произошел инцидент;
— Любая релевантная информация о тестовой среде и/или тестовых данных, не включенная в другие документы и сочтенная тестером заслуживающей внимания;
— Процесс или подпроцесс тестирования, в котором наблюдался инцидент.
7.12.5.4 Описание инцидента
Предоставляет подробное описание инцидента. Отмечается, воспроизводим ли инцидент, и если да, то предоставляется информация, достаточная для того, чтобы его воспроизвести.
Могут быть включены соответствующая информация и результаты измерений, которые помогли бы изолировать и устранить причину инцидента.
В описание также допустимо включить ссылки на дополнительное свидетельство инцидента или на вспомогательную информацию, которая поможет в диагностике инцидента.
Пример — Такими свидетельствами могут быть снимки экрана, журналы системы и выходные файлы.
7.12.5.5 Оценка серьезности (инициатора)
Указывает, с точки зрения инициатора, глубину и ширину воздействия этого инцидента на технические факторы и факторы бизнеса. Здесь может приводиться оценка времени и усилий на устранение соответствующего дефекта.
Пример — Техническими и бизнес-факторами может быть возможность пользователя выполнения задач и системных операций.
Кроме того, здесь идентифицируется наличие каких-либо известных обходных решений.
7.12.5.6 Оценка приоритета (инициатора)
Обеспечивает оценку безотлагательности для исправления. В большинстве организаций имеется от трех до пяти категорий.
Пример — Оценка системы классификации может состоять в том, что самая серьезная категория, например «Исправить немедленно» означает, что продукт неприменим, а наименее серьезная, например «Исправить в поддержке» означает, что это косметический инцидент.
Предоставляет, если это применимо, информацию о введении новых рисков или изменениях состояния существующих рисков.
7.12.5.8 Состояние инцидента
Идентифицирует текущий статус инцидента, который в данном контексте будет «Открыт».
Примечание — Общая последовательность состояний инцидентов в ходе своих жизненных циклов может быть следующей: «Открыт», «Утвержден для разрешения», «Назначен для разрешения», «Фиксирован», «Повторно проверен с фиксацией, подтвержден» и «Закрыт». Другие возможные значения состояния — «Отклонен» или «Отозван».

Приложение A
(справочное)

     
Обзор и Схемы Документов

На рисунке A.1 показано содержание документации тестирования, установленное Организационной Политикой Тестирования. Документация Динамического Тестирования разрабатывается для конкретного проекта в контексте документации управления тестированием.
На рисунке A.2 показана иерархия документов, получаемых при выполнении Процесса Разработки и Реализации Тестирования, определенного в ИСО/МЭК/ИИЭР 29119-2.
Базовое содержание каждого из определенных документов представлено ниже.
Все документы включают в себя следующее:
i) Уникальная идентификация документа.
ii) Оформляющая организация.
iii) Полномочия по утверждению.
Перечисленные разделы могут быть расположены по-разному в разных документах в зависимости от организации и документа.
Обычно конкретные разделы документа помещаются после введения.
A.2.2 Организационная Политика Тестирования
Специфическая информация Политики Тестирования включает в себя:
a) Положения Политики Тестирования:
ii) Процесс тестирования.
iii) Организационная структура тестирования.
vii) Другие соответствующие политики.
viii) Оценка стоимости тестирования.
ix) Архивация и повторное использование актива тестирования.
x) Совершенствование процесса тестирования.
A.2.3 Организационная Стратегия Тестирования
Специфическая информация Организационной Стратегии Тестирования включает в себя:
a) Положения Организационной Стратегии Тестирования в масштабах проекта:
i) Общий менеджмент рисков.
ii) Выбор тестирования и приоритетов.
iii) Документация тестирования и создание отчетов.
iv) Автоматизация и инструменты тестирования.
v) Менеджмент конфигурации рабочих продуктов тестирования.
vi) Управление инцидентами.
vii) Подпроцессы тестирования.
b) Положения Организационной Стратегии Тестирования для конкретных подпроцессов:
i) Критерии входа и выхода.
ii) Критерии завершения тестирования.
iii) Документация тестирования и создание отчетов.
iv) Степень независимости.
v) Методика проектирования тестирования.
viii) Повторное тестирование и регрессионное тестирование.

Рисунок A.1 — Иерархия документации тестирования

     
Рисунок A.2 — Иерархия документации разработки и реализации тестирования

Специфическая информация Плана Тестирования включает в себя:
a) Контекст тестирования:
i) Проект/Подпроцесс тестирования.
ii) Элемент(ы) тестирования.
iii) Область применения тестирования.
iv) Предположения и ограничения.
v) Заинтересованные стороны.
b) Обмен информацией о тестировании.
d) Стратегия тестирования:
i) Подпроцессы тестирования.
ii) Практические результаты тестирования.
iii) Методы проектирования тестирования.
iv) Критерии завершения тестирования.
vi) Требования к Тестовым Данным.
vii) Требования к Тестовой Среде.
viii) Повторное тестирование и регрессионное тестирование.
ix) Критерии приостановки и возобновления.
х) Отклонения от Организационной Стратегии Тестирования
e) Действия и оценка тестирования.
f) Комплектность персонала:
i) Роли, действия и ответственность.
ii) Потребность в дополнительном персонале.
iii) Потребности в обучении.
A.2.5 Отчет о Ходе Тестирования
Специфическая информация Отчета о Ходе Тестирования включает в себя:
ii) Прогресс относительно Плана Тестирования.
iii) Факторы, блокирующие прогресс.
iv) Показатели тестирования.
v) Новые и измененные риски.
vi) Запланированное тестирование.
A.2.6 Отчет о Завершении Тестирования
Специфическая информация Отчета о Завершении Тестирования включает в себя:
a) Выполненное тестирование:
i) Сводка выполненного тестирования.
ii) Отклонения от Плана Тестирования.
iii) Оценка завершения тестирования.
iv) Препятствующие факторы.
v) Показатели тестирования.
vii) Практические результаты тестирования.
viii) Активы тестирования, допускающие повторное использование.
A.2.7 Спецификация Проекта Тестирования
Специфическая информация Спецификации Проекта Тестирования включает в себя:
i) Уникальный идентификатор.
iv) Конкретная стратегия.
i) Уникальный идентификатор.
A.2.8 Спецификация Контрольного Примера
Специфическая информация Спецификации Контрольных Примеров включает в себя:
a) Элементы тестового покрытия:
i) Уникальный идентификатор.
i) Уникальный идентификатор.
vii) Ожидаемые результаты.
viii) Фактические результаты и результат тестирования.
A.2.9 Спецификация Процедур Тестирования
Специфическая информация Спецификации Процедур Тестирования включает в себя:
i) Уникальный идентификатор.
iv) Содержание (Прослеживаемость).
b) Процедуры тестирования:
i) Уникальный идентификатор.
v) Выполняемые контрольные примеры (Прослеживаемость).
vi) Связь с другими процедурами.
vii) Остановка и заключительные действия.
A.2.10 Требования к Тестовым Данным
Специфическая информация Требований к Тестовым Данным включает в себя:
a) Подробные Требования к Тестовым Данным:
i) Уникальный идентификатор.
vi) Архивация или утилизация.
A.2.11 Требования к Тестовой Среде
Специфическая информация Требований к Тестовой Среде включает в себя:
a) Подробные требования к тестовой среде:
i) Уникальный идентификатор.
A.2.12 Отчет о Готовности Тестовых Данных
Специфическая информация Отчета о Готовности Тестовых Данных включает в себя:
a) Состояние тестовых данных:
i) Уникальный идентификатор.
A.2.13 Отчет о Готовности Тестовой Среды
Специфическая информация Отчета о Готовности Тестовой Среды включает в себя:
a) Состояние тестовой среды:
i) Уникальный идентификатор.
A.2.14 Журнал Выполнения Теста
Специфическая информация Журнала Выполнения Теста включает в себя:
i) Уникальный идентификатор.
A.2.15 Отчет об Инциденте
Специфическая информация Отчета об Инциденте (состояние обнаружения) включает в себя:
v) Оценка серьезности (инициатора).
vi) Оценка приоритета (инициатора).
viii) Состояние инцидента.

Приложение B
(справочное)

     
Связь нормативных требований ИСО/МЭК/ИИЭР 29119-2 с информационными элементами ИСО/МЭК/ИИЭР 29119-3

Данное приложение на высоком уровне представляет соответствие действий, определенных в ИСО/МЭК/ИИЭР 29119-2, информационным элементам шаблонов документации, определенным в ИСО/МЭК/ИИЭР 29119-3. Для пользователей ИСО/МЭК/ИИЭР 29119-3, которые не применяют ИСО/МЭК/ИИЭР 29119-2, это приложение является дополнительным.
В таблице B.1 сведены нормативные требования для разделов ИСО/МЭК/ИИЭР 29119-2, в которых определено создание информационных элементов ИСО/МЭК/ИИЭР 29119-3.
Таблица B.1 — Сводка нормативных требований ИСО/МЭК/ИИЭР 29119-2, в котором определены информационные элементы ИСО/МЭК/ИИЭР 29119-3

Приложение C
(справочное)

     
Общие Сведения о Примерах

Приложения D-S содержат примеры использования шаблонов как для проекта динамичной разработки, так и для традиционного проекта, чтобы продемонстрировать применимость настоящего стандарта к проектам обоих типов. Необходимо отметить, что это всего лишь примеры, а в реальной жизни возможны и вероятны многочисленные отличия.
В частности, это имеет место в динамичных проектах. Усеченные (более динамичные) информационные элементы, представленные в динамичных примерах, являются «облегченными» версиями информационных элементов. Такой подход приемлем из-за низких предполагаемых рисков разработки, тогда как «тяжелые» версии в других примерах связаны с более высокими требованиями к гарантии жизненного цикла.
Для любого проекта может быть выбран свой комплект документации в диапазоне от полного комплекта (все документы) до минимальной совокупности документов тестирования (состав определяется конкретным проектом).
Примечание — Следует отметить, что в некоторых примерах документации используется словосочетание «должно быть». Его следует трактовать, как относящееся только к примеру, а не как нормативное требование.
Пример — документация базируется на двух примерах проектов:
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. У корпорации есть внутренний отдел ИТ, который ответственен за все продукты ИТ, используемые организацией для поддержки ее бизнеса. Проекты выполняются одной динамичной командой, так что проекты, выполняемые с использованием традиционных методов разработки, не реализуются. Организация имеет несколько лет опыта подобной работы и считает, что она действительно хорошо работает со своими потребностями в новых и расширенных ИТ-системах поддержки бизнеса.
Проект, который рассматривается в этом примере, является разработкой нового веб-решения системы подписки, позволяющей привлечь новых подписчиков и позволить существующим подписчикам изменить их персональные данные и заказать новые или расширить старые подписки.
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Некоторые их продукты критически важны в том смысле, что неправильные результаты анализа могли вызвать внесение неправильных доз удобрения (или слишком много, или слишком мало). Следовательно, организация должна производить продукт в соответствии с определенным стандартом, который устанавливает требования к производству и обеспечению качества конкретных документов и прослеживаемости между элементами рабочего продукта.
Проект, который рассматривается в этом примере, является разработкой блока ПК, называемого UV/TIT-14 33а. Это — аппарат для определения компонентов удобрения и их концентрации в пробах почвы. Аппарат снабжен пользовательским интерфейсом, работающим на ПК с беспроводным соединением с измерительной системой.
Не во всех примерах документов включены разделы «Специфическая информация документа» или «Введение»; это вызвано тем, что такая информация специфична для компании, а внимание в примерах сосредоточено на содержании документов тестирования.
Примеры могут быть внутренне противоречивыми. Каждый раздел должен рассматриваться как независимый пример информации, связанной с темой, указанной в заголовке.

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

.

.

Текст, пропущенный внутри абзаца, отмечен многоточием: «…».

Приложение D
(справочное)

     
Политика Тестирования

D.1 Пример 1 — Корпорация Agile
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).
Политика Тестирования корпорации Agile, V1.2 (02/13/2009)
Разработано: Урсула Мейерс, ответственный разработчик.
Утверждено: Стефан Блэксмит, глава отдела качества.
Область применения: Эта Политика Тестирования определяет корпоративное представление тестирования в корпорации Agile и служит основой для выполнения всех тестирований для всех внутренних проектов организации.
Введение: Корпорация Agile признает необходимость тестирования ее внутренних продуктов. Затраты на разработку высококачественных программных систем можно разделить на четыре категории: затраты на предотвращение, затраты на тестирование, затраты на внутренние отказы и затраты на внешние отказы. Обычно дешевле предотвратить дефекты, чем обнаружить и устранить их (затраты на тестирование, плюс затраты на внутренние отказы), а дороже всего обходится внешний отказ, обнаруженный пользователями. Чтобы избежать этого, корпорация Agile использует методики «Разработка через тестирование» (TDD) и «Разработка через приемочное тестирование» (ATDD), которые являются методиками разработки программного обеспечения. В своей реализации TDD корпорация Agile использует метод белого ящика, определенный в ИСО/МЭК/ИИЭР 29119-4.
Цели тестирования: Цель тестирования состоит в получении информации, достаточной для оценки текущего уровня качества тестируемой системы, поскольку все действия, направленные на достижение этого, считаются действиями тестирования программного обеспечения (например, тестирование комплексирования, тестирование системы, приемочные испытания и регрессионное тестирование).
Процесс тестирования: Тестирование программного обеспечения будет базироваться на процессах тестирования, определенных в ИСО/МЭК/ИИЭР 29119-2 и будет согласовано с подходом к разработке.
Организационная структура тестирования: Тестирование будет производиться ресурсами корпорации Agile из центрального пула тестеров, назначенных проекту. Кроме того, по мере необходимости, центральный «опытный» ресурс тестирования программного обеспечения под руководством Главы Тестирования обеспечит консультационные услуги по тестированию проектов. Организационная структура тестирования в проекте будет соответствовать общему руководству проектом.
Подготовка тестера: Все члены команд тестирования должны иметь надлежащее университетское образование или, по крайней мере, минимальный уровень отраслевой сертификации в тестировании программного обеспечения. Кроме того, ожидается, что тестеры будут иметь опыт в динамичных разработках или получат его в течение трех месяцев после присоединения к команде тестирования.
Стандарты: Документация тестирования будет основываться на ИСО/МЭК/ИИЭР 29119-3 «Документация тестирования», адаптированном к использованию в динамичных проектах.
Другие соответствующие политики: Политика разработки программного обеспечения корпорации Agile, V4.3 (12/12/2008).
Совершенствование процесса тестирования и определение стоимости: Результатами итераций станут накопленный опыт, метрики и концепции улучшения, которые будут представлены в центральную организацию тестирования.
D.2 Пример 2 — Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).
Эта политика опубликована в корпоративной интрасети Traditional Ltd под заголовком «Управление» >>»Политики». Она не предоставляет всю информацию о документе и не имеет версию, однако есть дата публикации.

Политика Тестирования

Цель и определение тестирования
В Traditional Ltd тестирование рассматривают как средство достижения доверия к нашим продуктам со стороны пользователя и потребителя. Тестирование — это одно из многих средств достижения этой цели.
В любой проект программного обеспечения должен входить проект тестирования. Другими словами, проект тестирования должен быть подпроектом соответствующего проекта программного обеспечения.
Упомянутые два проекта должны быть запущены одновременно. Процесс тестирования включает следующие действия: планирование, анализ и проектирование тестовых материалов, выполнение и документирование тестирования, включая регистрацию любых инцидентов, завершение тестирования и создание отчетов. Тестирование влияет на что-то (объект тестирования), и наблюдая эффект воздействия, можно решить, считать этот эффект правильным или неправильным поведением.
Каждый проект должен быть укомплектован аналитиками, разработчиками, программистами и аналитиками тестирования. Они все подчиняются менеджеру проекта. Для выполнения тестирования можно нанимать студентов.
Менеджмент для каждого продукта должен определить, какой уровень качества необходимо достигнуть в терминах максимального количества отчетов по инцидентам от потребителей за установленный срок.
При выпуске продукта группа тестирования должна представить отчет об ожидаемом поведении продукта. Спустя один год после выпуска менеджмент рассматривает этот отчет и сравнивает его с обратной связью рынка (число отчетов об инцидентах, число отказов.)
Мы следуем за соответствием нашим собственным стандартам, опубликованным в нашей сети, которые базируются на ИСО/МЭК/ИИЭР 29119-3 «Документация тестирования».
Политики в Traditional Ltd
Политики разработки программного обеспечения и обеспечения качества формируют базу для всех разработок и тестирования программного обеспечения в Traditional Ltd.
Подход к совершенствованию процесса тестирования
При выпуске продукта группа тестирования должна представить отчет, в котором проект анализируется с точки зрения тестирования. Любые улучшения, предложенные в этом отчете, обсуждаются с менеджментом для решения по реализации совершенствования.
Спустя один год после оценки тестирования менеджмент анализирует возможность внедрения улучшения.

Приложение E
(справочное)

     
Организационная Стратегия Тестирования

E.1 Пример 1 — Корпорация Agile
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).
Организационная Стратегия Тестирования корпорации Agile, V1.1 (03/23/2009).
Разработано: Урсула Мейерс, ответственный разработчик.
Утверждено: Стефан Блэксмит, глава отдела качества.
Оформляющая организация: За подготовку Организационной Стратегии Тестирования в корпорации Agile ответственен руководитель тестирования. Высшее руководство корпорации Agile ответственно за анализ, утверждение и распространение Организационной Стратегии Тестирования.
Область применения: Эта Организационная Стратегия Тестирования определяет общий подход корпорации к тестированию. Мы разработали и реализовали несколько руководств, которые применимы для всех проектов. Мы стремимся обеспечивать тестирование в каждой точке жизненного цикла программного обеспечения и систем. Это выполняется путем привлечения нашей группы тестирования на ранних этапах процессов жизненного цикла к участию в разработках и работе с историями пользователя даже в черновом исполнении. На основе этих артефактов разрабатываются планы тестирования и определяются объемы тестовых испытаний. В дополнение к разработке планов тестирования организация будет использовать такие динамичные действия тестирования, как участие заинтересованных сторон в проекте тестирования, подготовка автоматизации тестирования, экспертные оценки, различные методы проектирования тестирования (применимо к проекту), поверхностное отслеживание дефектов и создание отчетов.
Ссылки: Манифест динамичной разработки (Agile Manifesto).
Общий менеджмент рисков: Менеджмент всех рисков должен соответствовать предписанному корпоративному Процессу Менеджмента Рисков, как это определено в Корпоративной Политике-RM56, где идентифицирован общий реестр рисков. Любые отклонения и исключения должны быть утверждены высшим руководством.
Степень независимости: Организация тестирования корпорации возглавляется руководителем тестирования, у которого нет прямой связи с руководителем разработки. Организация тестирования технически, организационно и финансово независима от организации разработки корпорации Agile; однако назначенные в проект тестеры могут участвовать непосредственно в разработках в составе самоорганизующихся команд.
Организационная структура тестирования: Организация тестирования корпорации Agile имеет пул независимых профессионалов тестирования, из которого тестеры назначаются в динамичные команды, например, в команды Scrum, где они являются полноправными членами.
Стратегия документации тестирования: Организация тестирования должна соответствовать документации тестирования, определенной в ИСО/МЭК/ИИЭР 29119-3 и принципам динамичной разработки. Любые отклонения требуют утверждения руководителем тестирования.

Подпроцессы тестирования документированы в планах тестирования проекта: В обеспечение гарантии выбора самого эффективного типа тестирования корпорация опирается на компетентность своего руководителя тестирования. Это осуществляется через программу наставничества тестеров в командах Scrum и включает в себя функциональные и нефункциональные методы, методы проектирования тестирования и инструменты тестирования, адаптированные из ИСО/МЭК/ИИЭР 29119-1, -2 и -4. Дополнительно для каждого проекта определяется выбор тестирования, приоритет и менеджмент. Далее для проекта должны быть выбраны свои собственные тестовые среды, методы повторного тестирования/регрессии и методы управления инцидентами. Эти элементы согласовываются в ходе непрерывного прямого взаимодействия с заинтересованными сторонами в течение жизни каждого проекта. Уровень документирования Плана Тестирования (объем и формат) также согласовывается с заинтересованными сторонами проекта.
E.2 Пример 2 — Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).
У Traditional Ltd есть Организационная Стратегия Тестирования, разделенная на части для проекта в целом и для каждого подпроцесса тестирования. В этот пример включены часть для проекта в целом, части для тестирования компонентов и тестирования системы.

Организационная Стратегия Тестирования

 Приложение F
(справочное)

     
План Тестирования

F.1 Пример 1 — Корпорация Agile
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).

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

План Тестирования: Новая система подписки (NSS).
Охватывает: Результаты и истории итерации NSS 3, включая результаты предыдущих итераций.
Участники: Каждая итерация выполняется командой, состоящей из разработчиков, представителей пользователя и тестеров. Разработчики в конечном счете подчиняются руководителю разработки (Урсула), а тестеры руководителю департамента качества (Стефан).
Риски: Конкретные риски для этой итерации перечислены в картах историй. Общий риск состоит в том, что у итеративной команды нет доступа к живым данным в базах данных поддержки.
Стратегия тестирования: Нужно помнить, что необходимо:
— Создать автоматизированные тестирования на основе историй, прежде чем начать кодирование, проверить новый код и интеграцию с текущей версией системы перед тем, как отметить завершение истории.
— Повторно тестировать каждый раз, когда что-то было изменено в результате предыдущих итераций, а также в результате текущей итерации, и применить регрессионное тестирование всего результата этой итерации перед встречей для презентации.
— Оценивать усилия и стоимость тестирования и разработки, чтобы соответствовать договоренности по данной итерации в начале итерации и возвращать в портфель все незавершенные элементы, которые не могут быть завершены, включая любой накопленный технический долг (ошибки), который не может быть разрешен в данной итерации.
— Использовать методики проектирования тестирования, наиболее подходящие к критериям приемки, учитывая то, что истории с более высокими рисками требуют более тщательного тестирования, чем истории с рисками ниже.
— Обеспечить и удостовериться, что покрытие тестированием операторов достигает, по крайней мере, 90% всего кода, а покрытие ветвления — 80% для историй с высоким риском и 60% для историй с низким риском.
— Перед интеграцией гарантировать, что в реализации истории отсутствуют невыясненные дефекты с уровнем серьезности 1 или 2.
— Определить тестирование с участием потребителя ATDD (приемку) в итерации с соглашением и участием потребителя/пользователя.
— Перед встречей для презентации протестировать результат итерации в формальных средах тестирования и презентации.
— Представлять покрытие элементов тестирования на ежедневных встречах, включая действия низкого уровня по Плану Тестирования и документирование рисков на доске обсуждения.
— Сохранять все сценарии тестирования в инструменте ABC таким образом, чтобы они, по мере необходимости, были доступны для повторного тестирования и регрессионного тестирования.
— В конце каждой итерации создавать краткий отчет о тестировании и размещать его на портале проекта.
Действия и оценка тестирования: Тестирование, как ожидается, потребует одной трети от общих трудозатрат команды, необходимых для итерации. На данный момент оценка времени тестирования презентации составляет 3 часа.
F.2 Пример 2 — Traditional Ltd
Этот пример включает в себя два примера Плана Тестирования, а именно:
— План Тестирования Проекта;
— План Тестирования Системы.
F.2.1 План Тестирования Проекта
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).

Цель этого документа состоит в том, чтобы предоставить информацию и основы для планирования и выполнения всех процессов тестирования, необходимых для проверки продукта — блока для ПК UV/TIT-14 33а.
[PRS] Спецификация Требований Проекта
[OTS] Организационная Стратегия Тестирования Traditional Ltd
[KD] Спецификация требований к блоку для ПК UV/TIT-14 33а. Vers. 1.8
[HW/SW-spec] Спецификация аппаратных и программных средств
В этом документе действительны термины, определенные в [PP].
Используются следующие сокращения:
Продукт UV/TIT состоит из следующих аппаратных модулей:
— ультрафиолетовый спектрометр;
— автоматическая бюретка;
Архитектура показана на рисунке.

В состав системы входят следующие программные модули на компьютере (сервер):
— ультрафиолетовый модуль;
В систему входят следующие программные модули на ПК:
— модуль идентификации компонента и концентрации;
— модуль контроля и отчетности;
2.2 Элемент(ы) тестирования
Тестирование для этого проекта включает в себя тестирование:
— каждого из модулей программного обеспечения ПК, перечисленных выше (см. 2.1);
— каждого компонента программных модулей ПК, перечисленных выше (см. 2.1);
— функциональности полной программной системы.
Точные версии различных элементов тестирования нужно получать из системы менеджмента конфигурации во время определения тестирования и необходимо контролировать до выполнения любого тестирования.
2.3 Область применения тестирования
Система на ПК состоит из упомянутых выше программных модулей. В качестве сетевого модуля был приобретен стандартный продукт, проверенный таким количеством организаций, что он не нуждается в тестировании. Все другие модули должны быть протестированы при предположении, что операционная система на ПК и сеть работают правильно.
Функциональность, непосредственно связанная с сетевым соединением с компьютером, не будет проверяться, кроме как косвенно, когда эти функции будут использоваться в некотором другом тестировании.
Нефункциональные характеристики качества, такие как производительность, защищенность, безопасность и удобство использования не будут проверяться в этом проекте тестирования, потому что такое тестирование будет передано другой компании, которая и выполнит эту часть тестирования. Отдельный План Тестирования для них будет разрабатываться сторонней компанией, ответственной за это тестирование.
2.4 Предположения и ограничения
2.5 Заинтересованные стороны
См. анализ заинтересованной стороны в [РР].
3 Обмен информацией о тестировании
В таблицах рисков используются следующие сокращения:
P — вероятность или возможность риска;
I — влияние или воздействие, если риск осуществляется;
E — воздействие = вероятность «на» влияние.
Шкала для вероятности и влияния будет иметь диапазон значений от 1 до 6, где 6 — максимальные вероятность или влияние.

5.1 Подпроцессы тестирования
Тестирование продукта — блока для ПК UV/TIT-14 33а должно включать в себя следующие подпроцессы тестирования:
— покомпонентное тестирование;
— тестирование интеграции компонентов;
5.2 Практические результаты тестирования
Для каждого подпроцесса тестирования должна быть разработана следующая документация:
— план подпроцесса тестирования;
— спецификация тестирования;
— отчет о завершении подпроцесса тестирования.
5.3 Методы проектирования тестирования
Определяются для каждого подпроцесса тестирования согласно соответствующему разделу [OTS].
5.4 Критерии завершения тестирования
Определяются для каждого подпроцесса тестирования согласно соответствующему разделу [OTS].
Определяются для каждого подпроцесса тестирования согласно соответствующему разделу [OTS].
5.6 Тестовые данные и требования к тестовой среде
Определяются для каждого подпроцесса тестирования согласно соответствующему разделу [OTS].
Конкретные требования инструментов тестирования:
5.7 Повторное тестирование и регрессионное тестирование
Определяется для каждого подпроцесса тестирования согласно соответствующему разделу [OTS].
5.8 Критерии приостановки и возобновления
Критерии приостановки перечислены в реестре рисков проекта выше (см. риск за номером 7).
5.9 Отклонения от Организационной Стратегии Тестирования
См. конкретные планы подпроцессов тестирования.
6 Действия и оценки тестирования
Эта информация доступна в инструментах Mpower и Organization Dashboard корпоративной сети: https:// mpower.Traditional.com/irj/portal.
Для получения информации о соответствующих показателях стоимости и ежемесячном отслеживании доступна следующая ссылка:
https://processnet.masked.com/projectdashboard/Dashboardhome_new.asp.
Эта информация доступна только менеджерам проектов и рангом выше.
7.1 Роли, действия и ответственность
Высокоуровневые действия — это подпроцессы, которые будут выполняться. Подробные действия и ответственность будут документированы в планах подпроцессов тестирования.
7.2 Потребность в дополнительном персонале
См. конкретные Планы Подпроцессов Тестирования.
7.3 Потребности в обучении
См. конкретные Планы Подпроцессов Тестирования.
График тестирования, соответствующего этому плану, включен в диаграмму Ганта для проекта.
F.2.2 План Тестирования Системы
UV/TIT-14 33а Блок для ПК, План Тестирования Системы
Титульная страница и спецификация документа в этом примере опущены.
См. План Тестирования Проекта.
См. План Тестирования Проекта.
2.2 Элемент(ы) тестирования
Элемент(ы) тестирования — интегрированное программное обеспечение ПК для блока для ПК UV/TIT-14.
2.3 Область применения тестирования
Функции, которые будут проверены, могут быть подразделены на следующие группы:
— идентификация компонентов (IR+UV);
— концентрация компонентов (UV + управление бюреток);
— калибровка UV, IR и бюреток;
— отчеты по идентификации, концентрации и калибровке;
— управление системой конвейера (скорость, корректный запуск, позиции остановок и т.д.);
Кроме тестирования системы План Тестирования не касается других подпроцессов тестирования, например, тестирования компонентов и приемочных испытаний.
Функции, непосредственно связанные с сетевым соединением с компьютером, не будут проверяться, кроме как косвенно, когда эти функции будут использоваться в некотором другом тестировании.
Нефункциональные характеристики качества, такие как производительность, защищенность, безопасность и удобство использования, не будут проверяться в этом проекте тестирования, потому что такое тестирование будет передано другой компании, которая и выполнит эту часть тестирования.
Тестирование охватывает все программное обеспечение для ПК, разработанное для этой системы. Это означает, что другие элементы, такие как операционная система и сеть, явно не проверяются.
2.4 Предположения и ограничения
См. План Тестирования Проекта.
2.5 Заинтересованные стороны
См. План Тестирования Проекта.
3 Обмен информацией о тестировании
См. План Тестирования Проекта.
См. План Тестирования Проекта относительно рисков продукта.

5.1 Практические результаты тестирования
Практические результаты тестирования всей системы включают:
— настоящий план в актуальной версии на момент поставки;
— полный набор спецификаций тестирования;
— отчет о завершении тестирования полной системы блока для ПК UV/TIT-14 33а.
Практические результаты тестирования для каждой выполняемой процедуры тестирования включают:
— журнал тестирования, подписанный менеджером по тестированию. Журнал тестирования должен включать идентификационные номера отчетов по инцидентам, выявленным во время выполнения тестирования, если таковые имеются;
— обновленную версию спецификации тестирования или обновленный список известных дефектов в спецификации тестирования.
5.2 Методы проектирования тестирования
Необходимо применять следующие методики проектирования контрольных примеров:
— разбиение эквивалентности и анализ граничных значений;
— метод дерева классификации;
— тестирование таблицы решений;
— тестирование переходов состояний;
— тестирование по сценариям использования.
5.3 Критерии завершения тестирования
Тестирование системы должно обеспечить 80% покрытия требований, и все процедуры тестирования должны быть выполнены без отказов с уровнем серьезности 1 («Высокий»).
В ходе тестирования системы должны быть собраны следующие метрики:
— количество выполненных контрольных примеров;
— количество инцидентов по категориям;
— количество повторно выполненных контрольных примеров;
— количество разрешенных инцидентов по категориям;
— количество затраченного времени.
5.5 Требования к Тестовой Среде
Тестер (человек, ответственный за выполнение теста) во время выполнения тестирования должен иметь в наличии следующие документы:
— руководство пользователя по ПК UV/TIT-14 33а;
— копии процедур тестирования для каждого из выполняемых тестирований для записи хода тестирования.
Все аппаратные средства, операционная система и сеть описаны в спецификации [HW/SW-spec].
При выполнении тестирования другой ПК будет использоваться в качестве средства моделирования для того, чтобы команды, переданные в компьютер, могли быть проанализированы и в ответ на них могли быть моделированы простые ответы. Это позволит сократить ручную обработку, но потребует разработки средства моделирования. Таким образом, имеется потребность в средстве моделирования, которое работает на обычном ПК и идентично ПК-системе.
5.6 Повторное тестирование и регрессионное тестирование
Для выполнения критериев завершения должны быть выполнены необходимые повторное тестирование и регрессионное тестирование. По предварительной оценке будет выполнено по крайней мере три цикла тестирования, в составе последнего из них — полный регрессионный тест.
5.7 Критерии приостановки и возобновления
Если выполнение тестирования невозможно из-за внешних причин, то оно должно быть отложено до их устранения. В журнале тестирования должно быть записано, что произошло и на какое время было приостановлено тестирование. При возобновлении тестирования на основе оценки степени риска необходимо минимизировать повторение уже сделанного тестирования.
Если завершение набора тестов невозможно из-за отказа, об этом должно быть доложено через систему управления инцидентами, а отказу должен быть присвоен уровень серьезности тестирования «Высокий». При возобновлении тестирования затронутая процедура тестирования должна быть повторена.
5.8 Отклонения от Организационной Стратегии Тестирования
Организационная Стратегия Тестирования требует 100%-ного покрытия требований, однако оно было уменьшено до 80% для тестирования этой системы из-за относительно небольшого количества рисков продукта и из-за того, что запланировано скрупулезное покомпонентное тестирование.
6 Действия и оценки тестирования
Работа по тестированию в соответствии с [OTS] будет разбита на следующие основные виды деятельности:
1) Определение полной структуры тестирования в форме наборов проверяемых функций.
2) Подробная спецификация контрольных примеров и процедур тестирования.
3) Установление тестовой среды.
4) Первый цикл выполнения процедур тестирования.
5) Второй цикл выполнения процедур тестирования (повторное тестирование и регрессионный тест из первого цикла).
6) Третий цикл выполнения процедур тестирования (повторное тестирование и регрессионный тест из второго цикла и всех оставшихся из первого цикла).
7) Еженедельный отчет о состоянии выполнения тестирования.
8) Создание отчетов о завершении тестирования.
Подробные действия тестирования и их оценки можно найти в файле SYS-TEST.xls на портале проекта.
7.1 Роли, действия и ответственность
Таблица, приведенная ниже, иллюстрирует участие ролей в действиях и степень участия. Номер столбца действия соответствует номеру в вышеуказанном списке действий.

7.2 Потребность в дополнительном персонале
Для выполнения тестирования нам нужны два студента (или другие специалисты с достаточной квалификацией). Они будут наняты в соответствии с правилами найма HR.
7.3 Потребности в обучении
Для двух тестеров необходимо введение в систему. По оценке это займет 1 час в первый день.
Полный график тестирования показан ниже на рисунке.

Приложение G
(справочное)

     
Отчет о Ходе Тестирования

G.1 Пример 1 — Корпорация Agile

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

Сводный Отчет о Ходе Тестирования для: Новая система подписки (NSS).
Покрытие: Результаты завершенной итерации NSS 3.
Прогресс по сравнению с Планом Тестирования: Тестирование было сделано в итерации на пяти историях пользователя для этой итерации.
Для одного высокого риска покрытие операторов достигло 90% истории, и для других было достигнуто в среднем 68% покрытия операторов.
Неразрешенных дефектов с уровнем серьезности 1 и 2 нет, но презентация показала, что продукт имеет 16 дефектов с уровнем серьезности 3.
Факторы, блокирующие прогресс: Нет
Показатели тестирования: Были разработаны 6 новых процедур тестирования, а 2 другие процедуры тестирования были изменены.
Тестирование в итерации заняло приблизительно 30% времени. Тестирование заняло приблизительно 2 часа.
Новые и измененные риски: Риски для историй были обработаны удовлетворительно. Новых рисков не идентифицировано.
Запланированное тестирование: Согласно Плану Тестирования.
В портфель добавлено: 16 дефектов (серьезность 3).
G.2 Пример 2 — Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).
Проект продукта — Блок для ПК UV/TIT-14 33а
Отчет о Ходе Тестирования системы V 1.0, 22.03.2004
Ход тестирования 22 марта 2004 г.
Отчетный период: 15-21 марта 2004 г.
Прогресс по сравнению с Планом Тестирования: Были проверены функциональности «XX» модуля приложения.
Мы почти достигли цели плана, выполнив 2/3 контрольных примеров. Мы ожидаем наверстать маленькую задержку на следующей неделе. Кажется, что большинство обнаруженных отказов происходят из-за простых дефектов в отдельных модулях. Детали приводятся ниже.
Числа записей в блоке: Нет
Примечание — Графики, возможно, не соответствуют данным, представленным в таблицах в этом примере; они включены только для того, чтобы продемонстрировать возможность включения в отчет графиков и таблиц.

В нижеследующих таблицах приводятся полученные показатели, где обозначены: P1, P2…P6 — приоритеты. P1 является самым высоким.
Ежедневные показатели выполнения контрольных примеров

Накопительные показатели выполнения контрольных примеров

Ежедневная сводка дефектов

Накопительная сводка дефектов

Новые и измененные риски: Нет
Запланированное тестирование: Команда выполняет тестирование и тратит много времени на выявление дефектов, которые, как предполагалось, должны были обнаружиться в подпроцессе покомпонентного тестирования. Если бы группой разработчиков были приняты меры по точной настройке примеров для покомпонентного тестирования, то команда обеспечения качества могла бы сэкономить много времени и сконцентрироваться на других аспектах эффективного тестирования приложения. Тем не менее, полная сводка тестирования показывает отсутствие ошибок P1. Если открытые ошибки P2 будут устранены в следующей сборке, то команда обеспечения качества может иметь время для полного цикла регрессионного тестирования и обеспечить выполнение графика разработки.
На основании накопительной сводки тестирования, приведенной выше, можно предположить, что положение становится действительно стабильным ко второму циклу тестирования. После завершения второго цикла можно предсказать успешное прохождение всех контрольных примеров модуля «XX».

Приложение H
(справочное)

     
Отчет о Завершении Тестирования

H.1 Пример 1 — Корпорация Agile
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).

Этот отчет доступен на портале проекта, и новейшая версия также вывешена в правом нижнем углу доски истории в комнате разработки, где это разрабатывается и обновляется.

Отчет тестирования для: Новая система подписки (NSS) Vers.: Итерация 3361.
Покрытие: Результат заключительной итерации NSS, включая результаты предыдущих итераций, в рамках подготовки к основной поставке потребителю (для использования).
Риски: Риск живых данных был устранен путем создания модельной базы данных с использованием исторических живых данных, «подчищенных» командой тестирования и потребителем.
Результаты тестирования: Заказчик принимает эту версию продукта на основе следующего:
16 историй пользователя были реализованы успешно, включая одну добавленную после последнего отчета о состоянии.
100% покрытия операторов было достигнуто при технологическом тестировании с одной историей высокого риска, а для других было достигнуто в среднем 72% покрытия операторов.
Команда приняла портфель с четырьмя дефектами серьезности 3.
Презентация была принята потребителем без обнаруженных проблем. Итеративные функции презентации взаимодействовали через интерфейс с «живыми» данными.
Производительность итеративных функций, по мнению команды и потребителя, была приемлема.
Новые, измененные и остаточные риски: Защищенность системы может стать проблемой в будущих реализациях на основании информации о действиях, полученной от потребителей.
Примечания для будущей работы из ретроспективы:
Итеративная команда ощущает потребность в новом члене команды для обработки возможных новых рисков, по которым ни у кого нет знаний.
Дефекты серьезности 3, помещенные в портфель, нужно рассмотреть в следующей версии, чтобы уменьшить технический долг.
Измененные живые данные работали хорошо и должны быть сохранены.
Автоматизация тестирования и исследовательское тестирование работают, однако необходимо рассмотреть дополнительные методики проектирования тестирования, например, методики тестирования защищенности и комбинаторного тестирования.
H.2 Пример 2 -Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).
Продукт-блок для ПК проекта UV/TIT-14 33а
Отчет о завершении тестирования системы, V 1.0, 08.11.2004
Записано менеджером по Тестированию Кайро Тайтлефсеном, утверждено менеджером проекта Бенедиктом Райтергом.
Сводка выполненного тестирования:
— Была создана спецификация тестирования; она включала в себя 600 процедур тестирования.
— Тестовая среда была установлена согласно плану.
— Выполнение теста и его запись выполнялись согласно плану.
Отклонения от запланированного тестирования: Спецификация требований была обновлена во время тестирования к V5.6. Это вызвало перезапись нескольких контрольных примеров, но не оказало влияние на график.
Оценка завершения тестирования: Все процедуры тестирования должны выполняться без отказов с уровнем серьезности 1 («Высокий»). Это не было выполнено, потому что одна процедура тестирования не выполнялась. Однако требование, к которому относится эта процедура тестирования, имеет настолько низкий уровень риска, что тестирование было принято владельцем продукта.
Факторы, которые блокировали прогресс: Нет.
Одна из 600 запланированных процедур тестирования (процедура тестирования 4.7) не выполнялась вообще из-за отсутствия времени. Все выполненные 599 процедур тестирования успешно прошли в конце этих трех недель.
Во время тестирования было обнаружено 83 инцидента и 83 было разрешено. Эти инциденты, о которых докладывалось, имели номера от 107 до 189.
Затраченное рабочее время:
— 164 часа затрачено на разработку спецификации тестирования;
— 10 часов затрачено на установление тестовой среды;
— 225 часов затрачено на выполнение теста и запись;
— полчаса затрачено на этот отчет.
Новые, измененные и остаточные риски: Все риски, перечисленные в плане тестирования, были устранены, кроме вышеупомянутого риска за номером 19 с самым низким воздействием.
Практические результаты тестирования: Все практические результаты, определенные в плане, были согласно процедуре представлены в общую систему контроля.
Допускающие повторное использование активы тестирования: Спецификация тестирования и связанные тестовые данные и требования к тестовой среде могут быть снова использованы для тестирования обслуживания в случае необходимости.
Накопленный опыт: Исполнителей тестирования пришлось ознакомить с введением в систему, поскольку незнание системы задерживало выполнение контрольного примера. Помощь была обеспечена аналитиком в течение периода тестирования.

Приложение I
(справочное)

     
Спецификация Проекта Тестирования

I.1 Пример 1 — Корпорация Agile
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).

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

2) Новые и расширенные подписки.
3) Общий доступ на веб-сайте.
Для тестирования презентации истории должны быть отсортированы по темам. Должны быть покрыты тестовые условия на обратной стороне карт истории, которые описывают критерии принятия истории.
I.2 Пример 2 — Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).

Спецификация Проекта Тестирования

Для лучшего понимания основы Спецификации Проекта Тестирования далее приводится фрагмент системных требований для блока для ПК UV/TIT-14 33а.
Спецификация системных требований для блока для ПК UV/TIT-14 33а (фрагмент)
4.1.1 [22] Система должна иметь установочное меню со следующими пунктами меню:
— калибровочная установка;
4.2.1 [34] Должны быть установлены следующие параметры (числа в скобках — допустимые диапазоны):
— максимальная скорость (5-50 мм/с);
— минимальная рабочая скорость (2-10 мм/с) для конвейера (0 — для остановки).
4.2.2 [36] После завершения новой установки система должна вывести одно из следующих сообщений:
— «Максимальная скорость выше допустимой»;
— «Минимальная скорость ниже допустимой».

4.2.3 [37] Система должна позволять пользователю выйти из функциональной установки, ничего не изменяя.

.

.

4.8.1 [324] Система должна позволять пользователю устанавливать требуемый тип анализа концентрации. Типы анализа, известные системе, представлены в таблице 6.
4.8.2 [325] Система должна принимать образцы в показанных ниже диапазонах измерений. Величины, выходящие за пределы диапазонов, недопустимы. Диапазоны также приведены в таблице 6.
4.8.3 [326] На основе результатов система должна вывести на экран одно из следующих сообщений: «Принято», «Предупреждение» или «Тревога». Значения порогов даны в таблице 6.
Таблица 6 — Стандартная аналитическая таблица типов

.

.

4.8.10 [339] Перед обработкой образца система должна гарантировать, что формат номера образца будет таким, как представлено ниже.
Номер образца =»T»-«n [n]» — «nnn» — «dd».»мм».»yy»,
T — буква «A» | «S» | «M»;
4.8.11 [341] Система должна принимать номера образцов, состоящие из четырех частей, разделенных дефисами, а именно:
— тип действия (A, S или M);
— тип образца (одна или две цифры);
— идентификатор образца (три цифры);
Примечание — При вводе образца в машину система воспринимает цифры, но игнорирует дату.
Метод обработки машиной образца определяется типом действия: A означает автоматически, S — полуавтоматически и M — вручную.
Обработка образца зависит от типа действия. В случае автоматической обработки «1» определяет печать отчета, а «2» — без печати отчета. При полуавтоматической обработке образца тип действия определяет, какой анализ должен быть выполнен. Для ручного анализа тип действия не имеет значения.
При автоматической обработке образца выполняется анализ, и результат сохраняется под именем идентификатора образца. Если идентификатор образца не будет найден в базе данных, то анализ не будет выполняться и будет выведено сообщение об ошибке, показывающее, что выборка не зарегистрирована. Этапы автоматического анализа должны быть также найдены в базе данных.
Для выполнения полуавтоматического анализа идентификатор образца должен быть найден в базе данных. Также должны быть найдены этапы и при этом определено, какие из этапов можно пропустить, если пользователь выбирает этот режим. По завершении анализа распечатывается отчет, в который включаются выполненные и пропущенные этапы.

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

.

.

4.13.1 [581] Один из вариантов продукта должен быть оборудован крышкой для защиты выполняющего исследования технического персонала.
Крышка закрывает карусель во время движения. Крышка должна быть заблокирована, прежде чем карусель запущена. Не должно быть возможности открыть ее до полной остановки карусели. Имеются два датчика, определяющие блокировку крышки и движение карусели.
Если крышка заблокирована, то можно запустить карусель вперед или назад. Чтобы изменить направление, необходимо сначала остановить карусель, но не нужно открывать крышку.

Панели маневрирования имеет* следующие кнопки:

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

Спецификация Проекта Тестирования блока для ПК UV/TIT-14 33а

     
Версия 1.0

1 Введение

.

.

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

PCUV — блок для ПК UV/TIT-14 33а;
UC — вариант использования;
CRUD — создать, читать, обновить, удалить;
TBD — подлежит уточнению то, что еще неизвестно, но должно быть определено.
В этой главе описывается общая структура тестирования системы PCUV, в которой тестирование разделено по общим наборам функций.

Для каждого набора функций предоставляется следующая информация:

(nn):
Уникальный номер, который никогда не должен изменяться. Он используется для прослеживаемости.
ns:
Раздел или число сортировки, используемые для удобочитаемости документа.
Описание:
Краткое описание того, что нужно проверить.
Подход:
Описание методов проектирования тестирования, которые будут использоваться в проекте тестирования.
Прослеживаемость:
Ссылка на требования в наборе функций. Прослеживаемость будет содержать список уникальных идентификаторов, ссылающихся на требования в [1].
Это тестирование разделено для следующих наборов функций:
1) (FS1) Установка системы.
2) (FS4) Калибровка UV, IR и бюреток.
3) (FS2) Идентификация компонентов.
4) (FS3) Концентрация компонентов (UV + управление бюреток).
5) (FS6) Управление системой конвейера.
Набор функций (FS1). Установка системы
Цель: Проверить установку системы, включая представленные данные и сообщения о калибровке.
Приоритет: Выше среднего.
Подход: Структурное тестирование меню, простые тестирования требований (да/нет), разбиение эквивалентности и анализ граничных значений.
Прослеживаемость: [22], [34], [35], [36], [37], …
Набор функций (FS2). Идентификация компонентов
Цель: Проверить идентификацию и создание отчетов по компонентам.
Подход: Простое тестирование требований (да/нет), разбиение эквивалентности, анализ граничных значений, тестирование синтаксиса и тестирование дерева классификации.
Прослеживаемость: [324], [325], [326], [339], [341], ….
Набор функций (FS3): TBD (пока не завершено).
Набор функций (FS4): TBD (пока не завершено).
Набор функций (FS5): TBD (пока не завершено).
Набор функций (FS6): Управление системы конвейера.
Цель: Проверить систему конвейера, включая скорость, корректный запуск, позиции остановки, работу крышки и т.д.
Приоритет: Ниже среднего.
Подход: …, тестирование изменения состояния, …
Прослеживаемость: [581], …

В этой главе документированы тестовые условия для каждого набора функций.

.

.

3.3 Набор функций (FS2). Идентификация компонентов

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

.

.

3.3.7 Тестовые условия для диапазона измерений

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

Покрываемые требования: [324-NCS], [325-NCS]

Приоритет: Выше среднего

Тестовое условие

Аспект

Область

Замечание

Вход

(FS2).5.1

<2

Вне диапазона

(FS2).5.2

2-315 (включая границы)

Действительно

(FS2).5.3

>315

Вне диапазона

Покрываемые требования: [324-NCS], [325-NCS]

Приоритет: Выше среднего

Тестовое условие

Тип границы

Значение

Замечание

(FS2).5.1.a

L

Неизвестно

Вне диапазона

(FS2).5.1.b

U

1

Вне диапазона

(FS2).5.2.a

L

2

Действительно

(FS2).5.2.b

U

315

Действительно

(FS2).5.3.a

L

316

Вне диапазона

(FS2).5.3.b

U

Неизвестно

Вне диапазона

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

.

.

3.5 Набор функций (FS6). Управление системой конвейера

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

.

.

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

Покрываемое требование: [581]

Приоритет: Выше среднего

Тестовое условие

(FS6).11.1

Крышка работает согласно конечному автомату

(FS6).11.2

Все недопустимые (непоказанные) переходы — нулевые переходы

Приложение J
(справочное)

     
Спецификация Контрольного Примера

J.1 Пример 1 — Корпорация Agile
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).

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

214

1 Секретарь может создать новый тип подписки.
2 Секретарь может задать название, допустимые продолжительности, соответствующие цены и замечания для нового типа подписки.
3 Секретарь может сохранить новый тип подписки.
4 Секретарь видит подписки существующих типов.
5 Секретарь может изменить название, допустимые продолжительности, соответствующие цены для конкретного типа до тех пор, пока для него нет ни одной подписки.
6 Секретарь может отменить изменения типа подписки, прежде чем они будут сохранены.
7 Секретарь может сохранить изменения в типе подписки.
а. История секретаря для «удаления» подписки может отсутствовать, таким образом, мы должны рассмотреть это с потребителем. В противном случае — все в порядке.
J.2 Пример 2 -Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).

Спецификация Контрольного Примера для части

PC UV/TIT-1

4 33а
Версия 1.0

1 Введение

.

.

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

PCUV — блок для ПК UV/TIT-14 33а;
UC — вариант использования;
CRUD — создать, читать, обновить, удалить;

TBD — подлежит уточнению то, что еще неизвестно, но должно быть определено.

.

.

2 Элементы тестового покрытия

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

.

.

2.3 Набор функций (FS2). Идентификация компонентов

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

.

.

2.3.7 Элементы покрытия для диапазона измерений
Есть три действительных раздела эквивалентности и шесть действительных границ (из которых две неизвестны: одна меньше 0, а другая — больше 315).
Элементы покрытия могут быть сокращены, чтобы в соответствии с 3.3.7 [2] образовать тестовые условия:
(FS2).5.2, (FS2).5.1.b, (FS2).5.2.a, (FS2).5.2.b, (FS2).5.3.a.
2.3.8 Элементы покрытия для метода анализа
Элементы покрытия являются листьями дерева классификации в 3.3.8 [2], то есть областями, отмеченными полужирным шрифтом.

Есть 10 действительных листьев (элементов покрытия).

.

.

2.5 Набор функций (FS6). Управление системы конвейера

.

.

2.5.2 Элементы покрытия для работы крышки

Чтобы получить покрытие Джоу с 0-переключателями конечного автомата в (FS6).11.1 в [2], имеются следующие 6 переходов (элементов покрытия):

CI1

CI2

CI3

CI4

CI5

CI6

SS (TC)

S1

S2

S4

S2

S3

S2

Вход

P «L»

P «F»

P «S»

P «B»

P «S»

P «O»

Внешн. Выход

L I

C m f

C s

C m b

C s

L o

ES (TC)

S2

S4

S2

S3

S2

S1

В следующей таблице определены нулевые переходы, выделенные полужирным курсивом.

P «L»

P «F»

P «S»

P «B»

P «O»

S1

S2/LI

S1/N

S1/N

S1/N

S1/N

S2

S2/N

S4/C m f

S2/N

S3/C m b

S1/Lo

S3

S3/N

S3/N

S/C s

S4

S4/N

S4/N

S/C s

Имеется 14 нулевых переходов (элементов покрытия).

.

.

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

.

.

3.3 Набор функций (FS2). Идентификация компонентов

.

.

3.3.7 Диапазон измерений

Идентификатор контрольного примера: 17-1

Приоритет: Am

Трассировка: (FS2).5.1.b

Цель: проверить реакцию на значение образца, которое находится вне диапазона

Исходные условия:

Аппарат должен быть готов к анализу образца.

Должен быть подготовлен образец NCS со значением 1

Вход:

Вставьте образец и начните анализ

Ожидаемый результат:

Дисплей показывает «Недопустимый образец»

.

.

.

Идентификатор контрольного примера: 17-4

Приоритет: Am

Трассировка: (FS2).5.2.b

Цель: проверить реакцию на значение образца, которое находится на верхней границе диапазона

Исходные условия:

Аппарат должен быть готов к анализу образца.

Должен быть подготовлен образец NCS со значением 315

Вход:

Вставьте образец и запустите анализ

Ожидаемый результат:

Дисплей показывает «Предупреждение»

.

.

3.3.8 Метод анализа

.

.

.

Идентификатор контрольного примера: 21-3

Приоритет: Am

Трассировка: (FS2).8.1

Цель: Проверить автоматический анализ типа 1

Исходные условия:

База данных должна включать:

— Тип образца «1» с надлежащими этапами;

— Идентификатор образца «314».

Форма, куда вводится идентификатор образца, должна быть текущей

Вход:

Введите образец с идентификатором образца: А-1-314-221204

Ожидаемый результат:

Анализ выполняется без какого-либо взаимодействия.

Отчет распечатан.

Этапы, связанные с типом образца «1», выполняются (отметить в отчете)

.

.

.

Идентификатор контрольного примера: 21-16

Приоритет: Am

Трассировка: (FS2).8.1

Цель: Проверить ручной анализ

Исходные условия:

Форма, куда вводится идентификатор образца, должна быть текущей

Вход:

Введите образец с идентификатором образца: M-2-518-240604

Ожидаемый результат:

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

Отчет распечатан.

В отчете отражены выполненные шаги

3.5 Набор функций (FS6). Управление системой конвейера

.

.

Приложение K
(справочное)

     
Спецификация Процедур Тестирования

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

K.1.2 Пример 1.2 — Корпорация Agile
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).
В этом примере показано документации больше, чем при обычной динамичной разработке.
Процедура тестирования: Создание Секретарем Нового типа Подписки.
Цель (касательно спецификации): Подтверждение 214.
Запуск: Секретарь уже зарегистрирован и находится на странице поддержки подписки.

Взаимодействие: Предполагается, что процедуры тестирования обеспечения доступа секретаря к системе и т.д. были выполнены успешно.
Завершение и последующие действия: Сбросить базу данных в среде QA в состояние «Готова к тестированию».
Примечание — В зависимости от решений команды во время тестирования вышеупомянутая информация о процедуре тестирования может быть размещена в комментариях автоматизированного сценария тестирования или среди информации, связанной с исследовательским тестированием.
K.2 Пример 2 — Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).

Спецификация Процедур Тестирования

.

.

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

2.1 (FS1) Установка системы

.

.

2.3 (FS2) Идентификация компонентов

.

.

3.3 Процедуры тестирования

Приложение L
(справочное)

     
Требования к Тестовым Данным

L.1 Пример 1 — Корпорация Agile
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).

Тестовые данные:

Модифицированная совокупность фактических данных должна быть заполнена, однако данные не должны включать в себя критические данные клиентов: кредитные карты, адреса или телефонные номера. Такие данные будут «вычищены» командой тестирования и потребителем при запуске проекта. Тестирования будут выполняться на основе данных, используемых во время итераций.
L.2 Пример 2 — Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).

Требования к Тестовым Данным для блока для ПК UV/TIT-14 33а

.

.

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

PCUV — блок для ПК UV/TIT-14 33a;
A/D — архивируется (A) или удаляется (D);
TBD — подлежит уточнению, что еще неизвестно, но должно быть определено.
2 Подробные Требования к Тестовым Данным
Обратите внимание на то, что все данные необходимы в течение всего периода тестирования системы (см. [РТР]).

«Сброс» означает, что отдел ИТ должен быть в состоянии по запросу восстановить исходную базу данных.

Приложение M
(справочное)

     
Требования к Тестовой Среде

M.1 Пример 1 — Корпорация Agile
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в разделе C.1 (приложение C).

Тестовая среда:

Тестовая среда представляет собой среду IBM-совместимого ПК с логином/паролем входа в систему и с «измененными живыми» тестовыми данными, доступными в конфигурации системы тестирования. Тестирование конфигурации в этой среде не запланировано, но в ней будет выполнено функциональное тестирование и тестирование производительности.
M.2 Пример 2 — Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).

Требования к Тестовой Среде

Для тестирования необходимы три машины, работающие с операционной системой MS Windows. Администратор тестирования ответственен за приобретение и конфигурирование машин. Машины необходимы к 15 марта 2008 г., и они будут использоваться в течение двух недель.
2 Программное обеспечение
На трех машинах MS Windows должна быть установлена операционная система MS Windows ХР. Все актуальные патчи и пакеты обновления для машин должны быть установлены. Администратор тестирования ответственен за приобретение и установку программного обеспечения. К 15 марта 2008 г. полностью загруженное программное обеспечение для каждой машины должно быть готово.
Меры безопасности определены в Протоколе Безопасности Корпорации. Менеджер безопасности и Руководитель тестирования отвечают за меры безопасности.
Соответствующие инструменты тестирования определены в Плане Тестирования.

Приложение N
(справочное)

     
Отчет о Готовности Тестовых Данных

N.1 Пример 1 — Корпорация Agile
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).
Сообщение на доске информации: На встрече Scrum доложено о готовности данных.
N.2 Пример 2 — Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).

Отчет о Готовности Тестовых Данных

Кратко: Тестовые данные не готовы. К 22 марта 2008 г. миграция данных в тестовую среду будет завершена.
Состояние тестовых данных: В следующей таблице показано состояние каждого Требования к Тестовым Данным.

Ограничения: После завершения тестирования база данных тестирования будет обновлена. База данных подготовлена только для этого тестирования, и после тестирования данные будут содержать ограничения и находиться в состоянии системы, требующей обновления.
Заключения и рекомендации: Тестовые данные не готовы. Как было сказано ранее, данные будут готовы к 22 марта 2008 г.

Приложение O
(справочное)

     
Отчет о Готовности Тестовой Среды

O.1 Пример 1 — Корпорация Agile
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).
Сообщение на доске информации: На встрече Scrum доложено о готовности среды. Никакого другого отчета о готовности тестовой среды не представлено.
O.2 Пример 2 — Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).

Отчет о Готовности Тестовой Среды

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

Приложение P
(справочное)

     
Фактические Результаты

P.1 Пример 1 — Корпорация Agile
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).

Фактические результаты:

Группа разработчиков, менеджмент и представители местных потребителей на демонстрации системы согласились, что эта версия продукта готова для производственной поставки (10 голосов отдано «за»). Далее было согласовано, что в продукте не осталось никаких рисков или недоделок, которые не могут быть устранены в следующей версии. Предмет поставки корпорации Agile потребителю с кодом и требуемыми продуктами будет отправлен через электронную доставку (электронная почта).
P.2 Пример 2 — Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C). Документирование фактических результатов произведено непосредственно в форме процедуры тестирования и выделено далее курсивом.

Приложение Q
(справочное)

     
Результаты Тестирования

Q.1 Пример 1 — Корпорация Agile

Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).

Ниже приводятся конкретные результаты клиентского тестирования. Снимки экранов фактических результатов и данных доступны на веб-странице проекта (www.xxx.test.agiffie.org).
Тестирование 7: прошло, однако отмечены 4 проблемы уровня 3.
Тестирования 8-16: прошло (автоматизированное выполнение с регрессией прошлых итераций)
Примечание — Эта информация может быть представлена во множестве различных форматов, например, в отчетах, слайдовых презентациях или устно.
Q.2 Пример 2 — Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).
Документирование фактических результатов тестирования произведено непосредственно в форме процедуры тестирования и выделено далее курсивом.

Приложение R
(справочное)

     
Журнал Выполнения Теста

R.1 Пример 1 — Корпорация Agile
Корпорация Agile — большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).
Между корпорацией Agile и потребителем было заключено соглашение о том, что не требуется создания журнала выполнения теста.
R.2 Пример 2 — Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).
Ниже приведена выдержка из Журнала Выполнения Тестирования системы блока для ПК UV/TIT-14 33а.

Следует обратить внимание на следующие отклонения от Журнала Выполнения Теста, определенного в 7.11:
— вместо уникального идентификатора используется дата;
— «Время» названо «Дата» и регистрируется только дата;
— «Описание» называется «Запись в журнале»;
— отсутствует столбец «Влияние».

Приложение S
(справочное)

     
Отчет об Инциденте

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

S.2 Пример 2 — Traditional Ltd
Traditional Ltd — небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).
Ниже приводится отчет об инциденте, используемый в Traditional Ltd. Он охватывает только признание (или установку) статуса, и в нем не представлено никакой фактической информации об инциденте.

Приложение T
(справочное)

     
Взаимосвязь с существующими стандартами

T.1 Связь с ИИЭР 829:2008

T.2 Связь с ИСО/МЭК 15289: 2011

T.3 Связь с BS 7925-2:1998

T.4 Связь с ИСО/МЭК 25051:2006

Приложение ДА
(справочное)

     
Сведения о соответствии ссылочных международных стандартов национальным стандартам Российской Федерации

Таблица ДА.1

Обозначение ссылочного международного стандарта

Степень соответствия

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

ISO/IEC/IEEE 29119-1:2013

*

ISO/IEC/IEEE 29119-2:2012

*

ISO/IEC/IEEE 15289:2015

**

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

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

[1]

BS 7925-1:1998, Software testing — vocabulary

[2]

BS 7925-2:1998, Software testing — software component testing

[3]

EC 60300-3-9:1995, Risk Analysis of technological systems

[4]

IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology

[5]

IEEE Std 829-2008, IEEE Standard for Software Test Documentation

[6]

IEEE Std 1008-1987, IEEE Standard for Software Unit Testing

[7]

IEEE Std 1012:2012, IEEE Standard for Software Verification and Validation

[8]

IEEE Std 1028-2008, IEEE Standard for Software Reviews and Audits

[9]

ISO/IEC 12207:2008, Systems and software engineering — Software life cycle processes

[10]

ISO/IEC 16085:2006, IT — Systems and software Engineering — Lifecycle Processes — Risk Management

[11]

ISO/IEC/IEEE 24765:2010, Systems and Software Engineering Vocabulary

[12]

ISO/IEC 25000:2005, Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE

[13]

ISO/IEC 25010:2011, Systems and Software Engineering — Systems and Software Quality Requirements and Evaluation (SQuaRE) — System and Software quality models

[14]

ISO/IEC 25051:2006, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing

[15]

ISO/IEC 90003:2004, Software engineering — Guidelines for the application of ISO 9001:2000 to computer software

[16]

International Software Testing Qualifications Board (ISTQB), Standard glossary of terms used in Software Testing [online]. 2010. Updated 1 April 2010 [viewed 11 April 2011]. Available from:http://www.istqb.org/
УДК 006.034:004.054:004.01:006.354

ОКС 35.080

Ключевые слова: тестирование программного обеспечения, процесс планирования тестирования, подпроцесс, План Тестирования, Организационная Стратегия Тестирования, риск, менеджмент, валидация, верификация
Идут торги/работа комиссии

Для продолжения необходимо войти в систему

Подождите, идет загрузка..

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

Обозначение ГОСТ ГОСТ Р 56920-2024
Наименование на русском языке Системная и программная инженерия. Тестирование программного обеспечения. Общие положения
Наименование на английском языке System and software engineering. Software testing. General provisions
Дата введения в действие 30.09.2024
Код ОКС 35.080
Количество страниц 32
Статус Принят

Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования

Статус:
Действует  
Дата введения в действие: 01.06.2017

  • Библиография

Обозначение

ГОСТ Р 56922-2016

Полное обозначение

ГОСТ Р 56922-2016/ISO/IEC/IEEE 29119-3:2013

Заглавие на русском языке

Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования

Заглавие на английском языке

Software and systems engineering.Software testing. Part 3. Test documentation

Дата введения в действие

01.06.2017

ОКС

35.080

Аннотация (область применения)

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

Ключевые слова

тестирование программного обеспечения;процесс планирования тестирования;подпроцесс;План Тестирования;Организационная Стратегия Тестирования;риск;менеджмент;валидация;верификация

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

Раздел стандарта

Вид стандарта

Стандарты на процессы

Аутентичный текст с ISO

ISO/IEC/IEEE 29119-3:2013

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

ISO/IEC/IEEE 15289:2011;ISO/IEC/IEEE 29119-1;ISO/IEC/IEEE 29119-2:2013

Управление Ростехрегулирования

1 — Управление технического регулирования и стандартизации

Технический комитет России

22 — Информационные технологии

Дата последнего издания

18.07.2016

Количество страниц (оригинала)

114

Организация — Разработчик

Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ)

Статус

Действует

Код цены

6

Номер ТК за которым закреплен документ

022

Номер приказа о закреплении документа за ТК

151

Дата приказа о закреплении документа за ТК

26.01.2023

     ГОСТ Р 58143-2018

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

Информационная технология

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ

Детализация анализа уязвимостей программного обеспечения в соответствии с ГОСТ Р ИСО/МЭК 15408 и ГОСТ Р ИСО/МЭК 18045

Часть 2

Тестирование проникновения

Information technology. Security techniques. Refining software vulnerability analysis under GOST R ISO/IEC 15408 and GOST R ISO/IEC 18045. Part 2. Penetration testing

ОКС 35.020

Дата введения 2018-11-01

 Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Центр безопасности информации» (ООО «ЦБИ»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 «Защита информации»

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

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ISO/IEC TR 20004:2015* «Информационная технология. Методы и средства обеспечения безопасности. Детализация анализа уязвимостей программного обеспечения в соответствии с ИСО/МЭК 15408 и ИСО/МЭК 18045» (ISO/IEC TR 20004:2015 «Information technology — Security techniques — Refining software vulnerability analysis under ISO/IEC 15408 and ISO/IEC 18045», NEQ)

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

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

 Введение

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

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

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

Настоящий стандарт может использоваться следующим образом:

— оценщиками — при разработке тестов проникновения (как часть действий по оценке, требуемых в соответствии с ГОСТ Р ИСО/МЭК 15408 и ГОСТ Р ИСО/МЭК 18045;

— разработчиками — при разработке своих тестов проникновения (как часть процесса разработки объекта оценки);

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

— разработчиками профилей защиты/заданий по безопасности — для четкого определения потенциалов нападения и шаблонов атак.

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

Настоящий стандарт содержит руководство по планированию, выполнению и составлению отчетности тестирования проникновения объекта оценки на базе требований «Анализ уязвимостей» из ГОСТ Р ИСО/МЭК 15408 и ГОСТ Р ИСО/МЭК 18045. В частности, данный стандарт уточняет действия по тестированию проникновения, предусмотренные компонентами требований доверия к безопасности из семейства доверия AVA_VAN «Анализ уязвимостей» и описанные в ГОСТ Р ИСО/МЭК 18045, и обеспечивает более полное руководство по их выполнению. Настоящий стандарт включает процесс-ориентированное руководство и процедуры тестирования, необходимые для получения согласованных воспроизводимых результатов при идентификации, оценке и описании уязвимостей.

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

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

ГОСТ Р ИСО/МЭК 15408-3-2013 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности

ГОСТ Р ИСО/МЭК 18045-2013 Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий

ГОСТ Р 56545-2015 Защита информации. Уязвимости информационных систем. Правила описания уязвимостей

ГОСТ Р 56546-2015 Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем

ГОСТ Р 58142-2018 Информационная технология. Методы и средства обеспечения безопасности. Детализация анализа уязвимостей программного обеспечения в соответствии с ГОСТ Р ИСО/МЭК 15408 и ГОСТ Р ИСО/МЭК 18045. Часть 1. Использование доступных источников для идентификации потенциальных уязвимостей

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

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

В настоящем стандарте применены термины по ГОСТ Р 58142, а также следующий термин с соответствующим определением:

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

      4 Обозначения и сокращения

В настоящем стандарте применены следующие обозначения:

ИФБО — интерфейс ФБО;

ОО — объект оценки;

ТДБ — требование доверия к безопасности;

ТОО — технический отчет по оценке;

ФБО — функциональные возможности безопасности ОО;

ФТБ — функциональное требование безопасности.

      5 Общие положения

Подраздел 15.1 ГОСТ Р ИСО/МЭК 15408-3 определяет «уязвимости, возникающие при разработке», как уязвимости, внесенные в ходе процесса разработки ОО, связанные с возможностью преодоления некоторых его свойств. В том же подразделе ГОСТ Р ИСО/МЭК 15408-3 определяется, что оценка уязвимостей, возникающих при разработке, охвачена семейством доверия «Анализ уязвимостей» (AVA_VAN). В соответствии с ГОСТ Р ИСО/МЭК 15408-3 ожидается, что данный анализ определит, могут ли идентифицированные потенциальные уязвимости нарушить выполнение ФТБ; при анализе учитывается угроза того, что нарушитель может выполнять поиск недостатков [как идентифицированных потенциальных уязвимостей] (ГОСТ Р ИСО/МЭК 15408-3, пункт 15.2.1).

Компоненты семейства доверия AVA_VAN ранжированы следующим образом:

— AVA_VAN.1 «Обзор уязвимостей» (ГОСТ Р ИСО/МЭК 15408-3, пункт 15.2.3);

— AVA_VAN.2 «Анализ уязвимостей» (ГОСТ Р ИСО/МЭК 15408-3, пункт 15.2.4);

— AVA_VAN.3 «Фокусированный анализ уязвимостей» (ГОСТ Р ИСО/МЭК 15408-3, пункт 15.2.5);

— AVA_VAN.4 «Методический анализ уязвимостей» (ГОСТ Р ИСО/МЭК 15408-3, пункт 15.2.6);

— AVA_VAN.5 «Усиленный методический анализ» (ГОСТ Р ИСО/МЭК 15408-3, пункт 15.2.7).

Компонент AVA_VAN.1 — младший по иерархии компонент в семействе доверия AVA_VAN, компонент AVA_VAN.5 — старший.

Детализация действий, предусмотренных компонентами ТДБ семейства AVA_VAN, связанных с идентификацией потенциальных уязвимостей, приведена в ГОСТ Р 58142.

В настоящем стандарте приводится детализация действий оценщика в соответствии с ГОСТ Р ИСО/МЭК 15408 и ГОСТ Р ИСО/МЭК 18045 при тестировании проникновения.

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

— базовым потенциалом нападения в AVA_VAN.1.3.E (ГОСТ Р ИСО/МЭК 15408-3, подпункт 15.2.3.4.3);

— базовым потенциалом нападения в AVA_VAN.2.4.E (ГОСТ Р ИСО/МЭК 15408-3, подпункт 15.2.4.4.4);

— усиленным базовым потенциалом нападения в AVA_VAN.3.4.E (ГОСТ Р ИСО/МЭК 15408-3, подпункт 15.2.5.4.4);

— умеренным потенциалом нападения в AVA_VAN.4.4.E (ГОСТ Р ИСО/МЭК 15408-3, подпункт 15.2.6.4.4);

— высоким потенциалом нападения в AVA_VAN.5.4.E (ГОСТ Р ИСО/МЭК 15408-3, подпункт 15.2.7.4.4).

ГОСТ Р ИСО/МЭК 18045 устанавливает конкретные шаги оценивания, связанные с действием «Тестирование проникновения» (в подпунктах 14.2.1.6, 14.2.2.7, 14.2.3.7, 14.2.4.7) следующим образом.

AVA_VAN.1-5, AVA_VAN.2-6, AVA_VAN.3-6, AVA_VAN.4-6

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

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

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

— базовый потенциал нападения (в случае AVA_VAN.1-5);

— базовый потенциал нападения (в случае AVA_VAN.2-6);

— усиленный базовый потенциал нападения (в случае AVA_VAN.3-6); или

— умеренный потенциал нападения (в случае AVA_VAN.4-6).

AVA_VAN.1-6, AVA_VAN.2-7, AVA_VAN.3-7, AVA_VAN.4-7

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

Для каждой потенциальной уязвимости оценщик должен определить наиболее подходящий способ тестирования ОО. При этом должны быть рассмотрены:

а) ИФБО или другой интерфейс ОО, который будет использован для инициирования выполнения ФБО и наблюдения за результатом;

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

в) специальное оборудование для тестирования, которое потребуется либо для инициирования ИФБО, либо для наблюдения за ИФБО;

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

AVA_VAN.1-7, AVA_VAN.2-8, AVA_VAN.3-8, AVA_VAN.4-8

Оценщик должен провести тестирование проникновения.

Оценщик использует документацию для тестов проникновения, подготовленную на шаге оценивания:

— AVA_VAN.1-5 (в случае AVA_VAN.1-7);

— AVA_VAN.2-6 (в случае AVA_VAN.2-8);

— AVA_VAN.3-6 (в случае AVA_VAN.3-8); или

— AVA_VAN.4-6 (в случае AVA_VAN.4-8)

как основу для выполнения тестов проникновения по отношению к ОО, но это не препятствует оценщику выполнить дополнительные специальные тесты проникновения.

AVA_VAN.1-8, AVA_VAN.2-9, AVA_VAN.3-9, AVA_VAN.4-9

Оценщик должен зафиксировать фактические результаты выполнения тестов проникновения.

AVA_VAN.1-9, AVA_VAN.2-10, AVA_VAN.3-10, AVA_VAN.4-10

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

AVA_VAN.1-10 и AVA_VAN.2-11

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

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

Руководство, представленное в приложении В.4 ГОСТ Р ИСО/МЭК 18045, необходимо использовать для определения потенциала нападения, требуемого для использования конкретной уязвимости, и установления возможности использования уязвимости в предполагаемой среде функционирования.

AVA_VAN.3-11

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

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

Руководство, представленное в приложении В.4 ГОСТ Р ИСО/МЭК 18045, необходимо использовать для определения потенциала нападения, требуемого для использования конкретной уязвимости, и установления возможности использования уязвимости в предполагаемой среде функционирования.

AVA_VAN.4-11

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

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

Руководство, представленное в приложении В.4 ГОСТ Р ИСО/МЭК 18045, необходимо использовать для определения потенциала нападения, требуемого для использования конкретной уязвимости, и установления возможности использования уязвимости в предполагаемой среде функционирования.

AVA_VAN.1-11, AVA_VAN.2-12, AVA_VAN.3-12, AVA_VAN.4-12

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

а) ее источник (например, стала известна при выполнении действий ГОСТ Р ИСО/МЭК 18045; известна оценщику; прочитана в публикации);

б) связанные с ней невыполненные ФТБ;

в) описание;

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

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

Примечание — Как указано в подпункте 14.2.5 ГОСТ Р ИСО/МЭК 18045, ГОСТ Р ИСО/МЭК 18045 не определяет шаги оценивания для компонента AVA_VAN.5.

Краткое изложение содержания действия оценщика «Тестирование проникновения приведено на рисунке 1.

Рисунок 1 — Описание действия оценщика «Тестирование проникновения»

      6 Стадии тестирования проникновения

Выделяются следующие стадии проведения тестирования проникновения:

— планирование тестирования проникновения;

— разработка тестов проникновения;

— проведение тестирования проникновения;

— разработка отчетности по результатам тестирования проникновения.

6.1 Планирование тестирования проникновения

Планирование тестирования проникновения включает:

— определение профиля нападения;

— идентификацию потенциальных уязвимостей;

— описание возможностей и мотивации нарушителя;

— идентификацию шаблонов атак.

6.1.1 Определение профиля нападения

Определение профиля нападения является первым этапом при тестировании проникновения. На этом этапе необходимо:

— определить исследуемую архитектуру;

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

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

— идентифицировать интерфейс ФБО, доступный потенциальному нарушителю;

— классифицировать интерфейсы, способы их использования и степень доступности потенциальному нарушителю;

— идентифицировать параметры, которые нарушитель может определить с использованием интерфейса.

На данном этапе обеспечивается сбор информации для определения профиля атаки.

6.1.2 Идентификация потенциальных уязвимостей:

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

— фаззинг;

— документирование потенциальных уязвимостей.

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

В соответствии с ГОСТ Р ИСО/МЭК 18045 определяются лица, ответственные за реализацию действия «Идентификация потенциальной уязвимости».

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

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

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

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

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

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

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

Потенциальные уязвимости (недостатки) должны быть задокументированы. Документация должна включать характеристику следующих элементов:

— исследуемая система(ы) или компонент(ы) ОО;

— уязвимый интерфейс ФБО в рамках оцененной конфигурации ОО;

— типы уязвимостей (недостатков);

— описание уязвимостей (недостатков);

— потенциальное воздействие эксплуатации уязвимостей (недостатков).

6.1.3 Описание возможностей и мотивации нарушителя

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

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

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

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

Раскрытие действий нарушителя возможно путем моделирования действий нарушителя и определения способов реализации шаблонов атак.

6.1.4 Идентификация шаблонов атак

Идентификация шаблонов атак основана на наблюдениях за успешными реализациями атак на различные автоматизированные системы.

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

ИСО/МЭК ТО 20004 определяет механизм идентификации применимых шаблонов атак.

6.2 Разработка тестов проникновения

Разработка тестов проникновения включает:

— разработку тестов проникновения, используя идентифицированные шаблоны атак;

— разработку тестов проникновения с использованием метода гипотез (предположений) о недостатках;

— документирование тестов проникновения.

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

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

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

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

Документирование может выполняться как для отдельного тестирования компонента ОО, так и для комплексного тестирования ОО в целом.

6.3 Проведение тестирования проникновения

Проведение тестирования проникновения включает:

— выполнение тестов проникновения;

— анализ результатов тестов;

— уточнение тестов с учетом полученных результатов;

— документирование результатов тестирования проникновения.

При выполнении тестов проникновения оценщик должен осуществлять их в тестовой среде, соответствующей условиям эксплуатации ОО (моделированная, виртуальная, эксплуатационная);

При выполнении тестов проникновения оценщик должен использовать инструментальные средства.

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

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

— было ли проникновение успешным, не успешным или невыполнимым;

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

Результаты должны быть задокументированы и должны отражать соответствие спецификации ОО.

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

— тестирование одного и того же интерфейса с различными параметрами для получения доступа к ОО выбранным при тестировании способом;

— тестирование других или дополнительных интерфейсов для получения доступа к ОО выбранным при тестировании способом;

— тестирование одних и тех же интерфейсов для проверки с использованием метода гипотез (предположений) о недостатках.

Все результаты тестирования, а также действия оценщика должны быть задокументированы.

6.4 Разработка отчетности по результатам тестирования проникновения

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

— условия проведения тестирования проникновения;

— обобщенные результаты тестирования проникновения;

— детализацию результатов тестирования проникновения по отношению к каждой потенциальной уязвимости.

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

— описание модели профиля нападения;

— покрытие ОО тестами проникновения;

— изложение идентифицированных уязвимостей с указанием их опасности.

Покрытие ОО тестами проникновения включает описание:

— сопоставления гипотез (предположений) о недостатках и выполненных шаблонов атак;

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

— сопоставления гипотез (предположений) о недостатках и шаблонов атак, которые были признаны нереализуемыми по отношению к рассматриваемому ОО;

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

Детализация результатов по отношению к каждой потенциальной уязвимости включает:

— изложение результатов тестирования;

— описание подтвержденных уязвимостей;

Примечание — Описание подтвержденных уязвимостей рекомендуется выполнять с учетом ГОСТ Р 56545 и ГОСТ Р 56546.

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

— оценку опасности уязвимости;

— рекомендации для каждого недостатка (уязвимости).

Рекомендации для каждого недостатка (уязвимости) могут включать:

— описание недостатков (уязвимостей) и назначенного времени их устранения, предшествующего сертификации ОО;

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

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

      7 Действия по тестированию проникновения

ГОСТ Р ИСО/МЭК 18045 определяет шаги оценивания при тестировании проникновения:

7.1 Подвид деятельности по оценке (AVA_VAN.1)

Действие AVA_VAN.1.3Е

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

Шаг оценивания AVA_VAN.1-5

В соответствии с ГОСТ Р ИСО/МЭК 18045

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

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

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

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

Детализация в соответствии с ИСО/МЭК ТО 20004

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

Тесты проникновения разрабатываются на основе шаблонов атак. В качестве перечня шаблонов атак могут использоваться доступные национальные источники или, как вспомогательные, зарубежные источники (например, САРЕС).

Примечание — Общий перечень шаблонов атак и их классификация (Common Attack Pattern Enumeration and Classification, САРЕС) является доступным источником и предназначен для более объективного описания потенциала атаки в отношении актуальных потенциальных уязвимостей и описания актуальных тестов проникновения.

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

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

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

Шаг оценивания AVA_VAN.1-6

В соответствии с ГОСТ Р ИСО/МЭК 18045

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

а) идентификацию тестируемой потенциальной уязвимости ОО;

б) инструкции по подключению и настройке всего требуемого тестового оборудования в соответствии с требованиями к проведению конкретного теста проникновения;

в) инструкции по установке всех предварительных (начальных) условий выполнения теста проникновения;

г) инструкции по инициированию тестируемых ФБО;

д) инструкции по наблюдению режима выполнения ФБО;

е) описание всех ожидаемых результатов и содержания анализа, который необходимо выполнить в отношении наблюдаемого режима выполнения ФБО для сравнения с ожидаемыми результатами;

ж) инструкции по завершению теста и установке требуемого послетестового состояния ОО.

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

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

Для каждой потенциальной уязвимости оценщик должен определить наиболее подходящий способ тестирования ОО. При этом должны быть рассмотрены:

а) ИФБО или другой интерфейс ОО, который будет использован для инициирования выполнения ФБО и наблюдения за результатом выполнения;

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

в) специальное оборудование для тестирования, которое потребуется либо для инициирования ИФБО, либо для наблюдения за ИФБО (при необходимости);

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

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

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

Детализация в соответствии с ИСО/МЭК ТО 20004

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

В дополнение к информации, определенной в подпункте 14.2.1.6.2 ГОСТ Р ИСО/МЭК 18045, тестовая документация должна включать следующую информацию для каждого тестового случая:

а) идентификацию недостатка, наличие которого тестируется в ОО;

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

в) подробное описание выполнения атаки в данном тестовом случае.

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

Шаг оценивания AVA_VAN.1-7

В соответствии с ГОСТ Р ИСО/МЭК 18045

Оценщик должен провести тестирование проникновения.

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

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

Детализация в соответствии с ИСО/МЭК ТО 20004

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

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

Шаг оценивания AVA_VAN.1-8

В соответствии с ГОСТ Р ИСО/МЭК 18045

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

Детализация в соответствии с ИСО/МЭК ТО 20004

Шаг не детализируется.

Шаг оценивания AVA_VAN.1-9

В соответствии с ГОСТ Р ИСО/МЭК 18045

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

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

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

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

б) перечень ИФБО, применительно к которым осуществлялось тестирование проникновения (краткий перечень ИФБО и других интерфейсов ОО, на которых было сосредоточено тестирование проникновения);

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

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

Детализация в соответствии с ИСО/МЭК ТО 20004

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

Шаг оценивания AVA_VAN.1-10

В соответствии с ГОСТ Р ИСО/МЭК 18045

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

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

Руководство из приложения В.4 ГОСТ Р ИСО/МЭК 18045 необходимо использовать для вынесения заключения о потенциале нападения, требуемом для использования конкретной уязвимости, и возможности использования этой уязвимости в предполагаемой среде функционирования. Вычисление потенциала нападения для каждого случая может не требоваться, за исключением случаев, когда у оценщика остается сомнение относительно того, может ли уязвимость использоваться нарушителем, обладающим потенциалом нападения меньшим, чем Усиленный базовый.

Детализация в соответствии с ИСО/МЭК ТО 20004

Шаг не детализируется.

Шаг оценивания AVA_VAN.1-11

В соответствии с ГОСТ Р ИСО/МЭК 18045

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

а) источник уязвимости (например, стала известна при выполнении действий ГОСТ Р ИСО/МЭК 18045, известна оценщику, прочитана в публикации);

б) связанные с уязвимостью невыполненные ФТБ;

в) описание уязвимости;

г) пригодна ли уязвимость для использования в среде функционирования (т.е. пригодна ли уязвимость для использования или является остаточной уязвимостью);

д) количество времени, уровень компетентности, уровень знания ОО, необходимый уровень доступа к ОО, оборудование, требуемые для использования идентифицированных уязвимостей, а также соответствующие значения, полученные на основе таблиц В.2 и В.З приложения В.4 ГОСТ Р ИСО/МЭК 18045.

Детализация в соответствии с ИСО/МЭК ТО 20004

В дополнение к информации, изложенной в подпункте 14.2.1.6.7 ГОСТ Р ИСО/МЭК 18045, оценщик должен включить в ТОО следующую подробную информацию обо всех пригодных для использования уязвимостях и остаточных уязвимостях:

а) соответствующие идентификаторы уязвимостей (идентификатор, наименование, краткое описание);

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

7.2 Подвиды деятельности по оценке (AVA_VAN.2-AVA_VAN.5)

Действие AVA_VAN.X.4E

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

Шаг оценивания AVA_VAN.X-6

В соответствии с ГОСТ Р ИСО/МЭК 18045

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

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

Оценщику необходимо помнить, что при рассмотрении «Описания архитектуры безопасности» для поиска уязвимостей (как детализировано в AVA_VAN.X-4), необходимо выполнить тестирование с целью подтверждения архитектурных свойств безопасности, в связи с чем может потребоваться проведение тестов проникновения, направленных на нарушение свойств безопасности архитектуры. При разработке стратегии тестирования проникновения оценщик обеспечивает покрытие тестами каждой из основных характеристик в «Описании архитектуры безопасности» либо при функциональном тестировании (как рассмотрено в разделе 13 ГОСТ Р ИСО/МЭК 18045), либо при тестировании проникновения, проведенном оценщиком.

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

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

Руководство по определению необходимого для использования потенциальной уязвимости потенциала нападения представлено в приложении В.4 ГОСТ Р ИСО/МЭК 18045.

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

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

Детализация в соответствии с ИСО/МЭК ТО 20004

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

Тесты проникновения разрабатываются на основе шаблонов атак. В качестве перечня шаблонов атак могут использоваться доступные источники (например, САРЕС).

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

Шаг оценивания AVA_VAN.X-7

В соответствии с ГОСТ Р ИСО/МЭК 18045

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

а) идентификацию тестируемой потенциальной уязвимости оцениваемого ОО;

б) инструкции по подключению и настройке всего требуемого тестового оборудования в соответствии с требованиями к проведению конкретного теста проникновения;

в) инструкции по установке всех предварительных начальных условий выполнения теста проникновения;

г) инструкции по инициированию тестируемых ФБО;

д) инструкции по наблюдению режима выполнения ФБО;

е) описание всех ожидаемых результатов и содержания анализа, который необходимо выполнить в отношении наблюдаемого режима выполнения ФБО для сравнения с ожидаемыми результатами;

ж) инструкции по завершению теста и установке требуемого послетестового состояния ОО.

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

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

Для каждой потенциальной уязвимости оценщик должен определить наиболее подходящий способ тестирования ОО. При этом должны быть рассмотрены:

а) ИФБО или другой интерфейс ОО, который будет использован для инициирования выполнения ФБО и наблюдения за результатом их выполнения (возможно, что оценщику потребуется использование иного интерфейса ОО, помимо ИФБО, для демонстрации свойств ФБО, в частности, приведенных в «Описании архитектуры безопасности» (в соответствии с требованиями семейства ADV_ARC). Необходимо отметить, что, хотя интерфейсы ОО предоставляют средства тестирования свойств ФБО, сами эти интерфейсы не являются предметом тестирования);

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

в) специальное оборудование для тестирования, которое потребуется либо для инициирования ИФБО, либо для наблюдения за ИФБО (при необходимости);

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

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

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

Детализация в соответствии с ИСО/МЭК ТО 20004

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

В дополнение к информации, определенной в подпунктах 14.2.2.7.2, 14.2.3.7.2 и 14.2.4.7.2 ГОСТ Р ИСО/МЭК 18045, тестовая документация должна включать следующую информацию для каждого тестового случая:

а) идентификацию недостатка, наличие которого тестируется в ОО;

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

в) подробное описание выполнения атаки в данном тестовом случае.

Перечень факторов, определенных в подпунктах 14.2.2.7.2, 14.2.3.7.2 и 14.2.4.7.2 ГОСТ Р ИСО/МЭК 18045, который используется оценщиком при определении наиболее подходящего способа протестировать восприимчивость ОО, должен применяться в контексте множества актуальных шаблонов атак.

Шаг оценивания AVA_VAN.X-8

В соответствии с ГОСТ Р ИСО/МЭК 18045

Оценщик должен провести тестирование проникновения.

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

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

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

Детализация в соответствии с ИСО/МЭК ТО 20004

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

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

Шаг оценивания AVA_VAN.X-9

В соответствии с ГОСТ Р ИСО/МЭК 18045

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

Детализация в соответствии с ИСО/МЭК ТО 20004

Шаг не детализируется.

Шаг оценивания AVA_VAN.X-10

В соответствии с ГОСТ Р ИСО/МЭК 18045

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

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

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

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

б) перечень ИФБО, применительно к которым осуществлялось тестирование проникновения (краткий перечень ИФБО и других интерфейсов ОО, на которых было сосредоточено тестирование проникновения);

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

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

Детализация в соответствии с ИСО/МЭК ТО 20004

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

Шаг оценивания AVA_VAN.X-11

В соответствии с ГОСТ Р ИСО/МЭК 18045

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

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

Руководство из приложения В.4 ГОСТ Р ИСО/МЭК 18045 необходимо использовать для вынесения заключения о потенциале нападения, требуемом для использования конкретной уязвимости, и возможности использования этой уязвимости в предполагаемой среде функционирования. Вычисление потенциала нападения для каждого случая может не требоваться, за исключением случаев, когда у оценщика остается сомнение относительно того, может ли уязвимость использоваться нарушителем, обладающим потенциалом нападения меньшим, чем Усиленный базовый.

Детализация в соответствии с ИСО/МЭК ТО 20004

Шаг не детализируется.

Шаг оценивания AVA_VAN.X-12

В соответствии с ГОСТ Р ИСО/МЭК 18045

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

а) источник уязвимости (например, стала известна при выполнении действий ГОСТ Р ИСО/МЭК 18045, известна оценщику, прочитана в публикации);

б) связанные с уязвимостью невыполненные ФТБ;

в) описание уязвимости;

г) пригодна ли уязвимость для использования в среде функционирования (т.е. пригодна ли уязвимость для использования или является остаточной уязвимостью);

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

Детализация в соответствии с ИСО/МЭК ТО 20004

В дополнение к информации, изложенной в подпунктах 14.2.2.7.7, 14.2.3.7.7 и 14.2.4.7.7 ГОСТ Р ИСО/МЭК 18045, оценщик должен включить в ТОО следующую подробную информацию обо всех пригодных для использования уязвимостях и остаточных уязвимостях:

а) соответствующие идентификаторы уязвимостей (идентификатор, наименование, краткое описание);

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

УДК 004.622:006.354

ОКС 35.020

Ключевые слова: информационная технология, объект оценки, анализ уязвимостей, недостаток, программное обеспечение, тестирование проникновения

Текст ГОСТ Р 56922-2016 Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования

ГОСТ Р 56922-2016/
ISO/IEC/IEEE 29119-3:2013

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

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

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

Часть 3

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

Software and systems engineering. Software testing. Part 3. Test documentation

ОКС 35.080

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

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту ISO/IEC/IEEE 29119-3:2013* «Программная и системная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования» (ISO/IEC/IEEE 29119-3:2013 «Software and systems engineering — Software testing — Part 3: Test documentation»).
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . — .

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

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

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

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

Введение

Введение

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

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

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

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

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

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

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

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

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

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

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

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

Приложение B содержит список всех информационных элементов, определенных в разделах 5, 6 и 7 настоящего стандарта, с соответствующим уровнем требования соответствия (необходимо/следует/можно) ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования». Приложение C содержит общие сведения о примерах. В приложениях D-S приводятся примеры применения шаблонов. Приложение T показывает взаимосвязь с существующими стандартами. Библиография приводится в конце настоящего стандарта.

Понятия и терминология документации тестирования программного обеспечения определены в ИСО/МЭК/ИИЭР 29119-1 «Понятия и определения».

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

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

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

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

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

Настоящий стандарт применим к тестированию всех моделей жизненного цикла разработки программного обеспечения.

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

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

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

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

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

2.1 Предполагаемое соответствие

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

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

Для простоты ссылок в настоящем стандарте на каждый документ ссылаются как на опубликованный в виде отдельного печатного документа. Названия и содержание документов могут быть изменены (дополнены, объединены или переименованы), и использование номенклатуры конкретных документов, определенных в разделах 5, 6 и 7, не должно требовать соответствия. Документы считаются соответствующими, если они не опубликованы, а доступны в электронной форме, если они разделены на отдельные части или тома или объединены с другими документами в один документ.

2.2 Типы соответствия

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

2.2.1 Полное соответствие

Минимальная совокупность требуемых информационных элементов — это все информационные элементы, которые определены в разделах 5, 6 и 7.

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

2.2.2 Адаптированное соответствие

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

Решения по адаптации должны быть согласованы с соответствующими заинтересованными сторонами.

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

a) Минимальная совокупность требуемой документации тестирования определена адаптацией процессов и действий в соответствии с разделом 2 ИСО/МЭК/ИИЭР 29119-2 «Процессы тестирования».

b) Минимальная совокупность требуемой документации тестирования определена в соответствии с конкретными потребностями организации и/или проекта.

c) Минимальная совокупность требуемых информационных элементов в документах определена в соответствии с конкретными потребностями организации и/или проекта.

Примечания

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

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

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

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

ИСО/МЭК/ИИЭР 15289:2011 Системная и программная инженерия. Содержание информационных продуктов жизненного цикла (документация)

(ISO/IEC/IEEE 15289:2011, Systems and software engineering — Content of life-cycle information products (documentation);

ИСО/МЭК/ИИЭР 29119-1 Системная и программная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения

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

ИСО/МЭК/ИИЭР 29119-2 Системная и программная инженерия. Тестирование программного обеспечения. Часть 2. Процессы тестирования

(ISO/IEC/IEEE 29119-2:2013, Software and systems engineering — Software testing — Part 2: Test processes)

Другие стандарты, полезные для реализации и интерпретации настоящего стандарта, приведены в разделе «Библиография».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

3 В случае отсутствия Политики Тестирования в Организационную Стратегию могут входить положения Политики Тестирования.

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.21 Отчет о готовности Тестовой Среды (Test Environment Readiness Report): Документ, который описывает состояние каждого требования к среде.

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

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

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

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

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

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

Примечания

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

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

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

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

Примечания

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

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

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

Примечания

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

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

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

4.29 набор тестов (test set): Набор контрольных примеров в целях тестирования конкретной цели тестирования.

Примечания

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

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

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

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

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

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

Примечания

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

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

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

Примечания

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

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

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

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

5 Документация Организационного Процесса Тестирования

5.1 Общие сведения

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

— Политика Тестирования;

— Организационная Стратегия Тестирования.

Полные шаблоны документов с пояснением представлены в 5.2 «Политика Тестирования» и 5.3 «Организационная Стратегия Тестирования». В приложении A представлены краткие общие сведения о каждом документе. В приложениях D и E приводятся примеры Политики Тестирования и Организационной Стратегии Тестирования для конкретных проектов.

5.2 Политика Тестирования

5.2.1 Общие сведения

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

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

Содержание Политики Тестирования описано ниже.

5.2.2 Спецификация документа

5.2.2.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.

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

5.2.2.2 Уникальная идентификация документа

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

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

5.2.2.3 Оформляющая организация

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

5.2.2.4 Полномочия по утверждению

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

5.2.2.5 История изменений

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

Примеры

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

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

5.2.3 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

5.2.3.2 Ссылки

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

Пример — Нормативными документами могут быть политики, планы, процедуры и другие.

5.2.3.3 Глоссарий

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

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

5.2.4 Положения Политики Тестирования

5.2.4.1 Цели тестирования

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

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

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

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

5.2.4.3 Организационная структура тестирования

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

5.2.4.4 Подготовка тестеров

Определяет потребность в обучении и сертификации персонала, работающего в организации тестирования.

5.2.4.5 Этика тестера

Определяет организационный кодекс этики, которого должны придерживаться тестеры.

5.2.4.6 Стандарты

Устанавливает, какие стандарты применимы в организации тестирования.

5.2.4.7 Другие соответствующие политики

Определяет политики, оказывающие влияние на организацию тестирования.

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

5.2.4.8 Оценка стоимости тестирования

Устанавливает, как организация определяет возврат инвестиций в тестирование. Определяет цели оценки затрат на тестирование.

5.2.4.9 Архивация и повторное использование актива тестирования

Устанавливает позицию организации по архивации и повторному использованию активов тестирования.

5.2.4.10 Совершенствование процесса тестирования

Определяет методику обеспечения непрерывного совершенствования процесса тестирования.

5.3 Организационная Стратегия Тестирования

5.3.1 Общие сведения

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

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

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

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

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

В A.2.3 (приложение A) представлен макет Организационной Стратегии Тестирования, а в E.1 и E.2 (приложение E) приведены примеры, которые демонстрируют разные Организационные Стратегии Тестирования для двух различных проектов.

Рисунок 2 — Пример структуры Организационной Стратегии Тестирования

Рисунок 2 — Пример структуры Организационной Стратегии Тестирования

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

5.3.2 Спецификация документа

5.3.2.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.

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

5.3.2.2 Уникальная идентификация документа

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

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

5.3.2.3 Оформляющая организация

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

5.3.2.4 Полномочия по утверждению

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

5.3.2.5 История изменений

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

Примеры

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

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

5.3.3 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

5.3.3.2 Ссылки

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

Пример — Нормативными документами могут быть политики, планы, процедуры и другое.

5.3.3.3 Глоссарий

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

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

5.3.4 Положения Организационной Стратегии Тестирования в масштабах проекта

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

5.3.4.1 Общий менеджмент рисков

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

5.3.4.2 Выбор тестирования и приоритетов

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

5.3.4.3 Документация тестирования и создание отчетов

Идентифицирует документы, которые ожидается произвести во время тестирования в рамках всего проекта тестирования. Описывает подготовку каждого документа и соответствующего процесса утверждения. Это тесно связано с определенным в политике процессом тестирования.

5.3.4.4 Автоматизация и инструменты тестирования

Определяет подход к автоматизации тестирования в организации. Идентифицирует инструменты тестирования, которые будут использоваться в Ходе Тестирования.

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

5.3.4.5 Менеджмент конфигурации рабочих продуктов тестирования

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

5.3.4.6 Управление инцидентами

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

5.3.4.7 Подпроцессы тестирования

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

5.3.5 Положения организационной стратегии тестирования для конкретных подпроцессов

5.3.5.1 Критерии входа и выхода

Определяет используемые критерии запуска и остановки действий тестирования для конкретного подпроцесса тестирования.

Подпроцесс тестирования состоит из следующих процессов:

— проектирование и реализация тестирования;

— установка и поддержка тестовой среды;

— выполнение теста;

— отчетность об инцидентах тестирования.

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

5.3.5.2 Критерии завершения тестирования

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

5.3.5.3 Документация тестирования и создание отчетов

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

5.3.5.4 Степень независимости

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

5.3.5.5 Методика проектирования тестирования

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

5.3.5.6 Тестовая среда

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

5.3.5.7 Требуемые метрики

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

5.3.5.8 Повторное тестирование и регрессионное тестирование

Определяет стратегию, условия и действия повторного тестирования и регрессионного тестирования в подпроцессе тестирования.

6 Документация Процессов Управления Тестированием

6.1 Общие сведения

Документы, разработанные в процессах управления тестированием, включают в себя следующие:

— План Тестирования;

— Отчет о Ходе Тестирования;

— Отчет о Завершении Тестирования.

Полные шаблоны документов с пояснением приведены ниже. В приложении A представлены краткие общие сведения о каждом документе. В приложениях F и G приведены примеры Планов Тестирования, Отчетов о Ходе Тестирования и Отчетов о Завершении Тестирования для конкретных проектов.

6.2 План Тестирования

6.2.1 Общие сведения

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

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

В A.2.4 (приложение A) представлен макет Плана Тестирования, а в F.1 и F.2 (приложение F) приведены примеры, демонстрирующие разработку Планов Тестирования для двух различных проектов.

Далее приводится содержание Плана Тестирования.

6.2.2 Спецификация документа

6.2.2.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.

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

6.2.2.2 Уникальная идентификация документа

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

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

6.2.2.3 Оформляющая организация

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

6.2.2.4 Полномочия по утверждению

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

6.2.2.5 История изменений

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

Примеры

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

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

6.2.3 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

6.2.3.2 Ссылки

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

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

— требования;

— проект;

— руководство пользователя;

— руководство по работе и/или

— инструкцию по установке.

6.2.3.3 Глоссарий

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

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

6.2.4 Контекст тестирования

6.2.4.1 Проект(ы)/подпроцесс(ы) тестирования

Идентифицирует проект(ы) или подпроцесс(ы) тестирования, для которых создается план, и содержит другую соответствующая информацию* о контексте.
_________________

* Текст документа соответствует оригиналу. — .

6.2.4.2 Элемент(ы) тестирования

Определяет элемент(ы) тестирования для тестирования по этому плану, включая их версию/пересмотр или ссылку на эту информацию.

В этом разделе возможно описание назначения элемента(ов) тестирования или приводится ссылка на эту информацию.

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

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

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

6.2.4.3 Область применения тестирования

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

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

6.2.4.4 Предположения и ограничения

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

6.2.4.5 Заинтересованные стороны

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

6.2.5 Обмен информацией о тестировании

Определяет связи между тестированием и другими действиями жизненного цикла и в организации.

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

Эта информация может быть представлена в визуальной форме.

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

6.2.6 Реестр рисков

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

Пример — Рекомендациями по обработке рисков могут быть: устранить риск, уменьшить его или игнорировать риск.

Примечание — Реестр рисков может быть приведен в плане проекта или плане менеджмента рисков.

6.2.6.1 Риски продукта

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

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

6.2.6.2 Риски проекта

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

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

6.2.7 Стратегия тестирования

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

6.2.7.1 Подпроцессы тестирования

Для Плана Тестирования проекта определяются надлежащие для выполнения подпроцессы тестирования.

6.2.7.2 Практические результаты тестирования

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

Пример — К результатам тестирования могут относиться следующие документы:

— План Тестирования;

— Спецификация Проекта Тестирования;

— Спецификация Контрольного Примера;

— Спецификация Процедур Тестирования;

— Отчет о Готовности Тестовых Данных;

— Отчет о Готовности Тестовой Среды;

— Отчеты по Инциденту;

— Отчеты о Ходе Тестирования;

— Отчет о Завершении Тестирования.

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

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

6.2.7.3 Методика проектирования тестирования

Определяет, какие методы проектирования тестирования должны применяться.

6.2.7.4 Критерии завершения тестирования

Определяет условия, при которых соответствующая организация тестирования предполагает завершение выполнения.

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

6.2.7.5 Требуемые метрики

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

6.2.7.6 Требования к Тестовым Данным

Определяет все соответствующие Требования к Тестовым Данным для проекта или подпроцесса тестирования (определенным образом).

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

Определение этих требований к тестовым данным по необходимости может быть отложено до создания документа «Требования к Тестовым Данным» (см. 7.5).

6.2.7.7 Требования к Тестовой Среде

Определяет необходимые и желательные свойства тестовой среды.

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

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

Пример — Действием после выполнения теста может быть анализ данных.

Такие требования к тестовой среде при необходимости могут быть сформулированы позднее в документе «Требования к Тестовой Среде» (см. 7.6), однако ссылка на этот отдельный документ должна присутствовать в Плане Тестирования.

6.2.7.8 Повторное тестирование и регрессионное тестирование

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

6.2.7.9 Критерии приостановки и возобновления

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

6.2.7.10 Отклонения от организационной стратегии тестирования

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

6.2.8 Действия и оценка тестирования

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

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

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

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

Примечание — Бюджетные сметы расходов могут быть приведены в плане проекта.

6.2.9 Комплектность персонала

Определяет требования к комплектности персонала для тестирования, соответствующего этому плану.

6.2.9.1 Роли, действия и ответственность

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

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

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

6.2.9.2 Потребность в дополнительном персонале

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

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

6.2.9.3 Потребность в обучении

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

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

6.2.10 Расписание

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

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

6.3 Отчет о Ходе Тестирования

6.3.1 Общие сведения

Отчет о Ходе Тестирования предоставляет информацию о состоянии тестирования, выполненного за определенный отчетный период времени.

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

В A.2.5 (приложение A) представлен макет Отчета о Ходе Тестирования, а в G.1 и G.2 (приложение G) приводятся примеры создания Отчетов о Ходе Тестирования для двух различных проектов.

Содержание Отчета о Ходе Тестирования представлено ниже.

6.3.2 Спецификация документа

6.3.2.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.

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

6.3.2.2 Уникальная идентификация документа

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

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

6.3.2.3 Оформляющая организация

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

6.3.2.4 Полномочия по утверждению

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

6.3.2.5 История изменений

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

Примеры

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

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

6.3.3 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

6.3.3.2 Ссылки

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

6.3.3.3 Глоссарий

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

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

6.3.4 Ход тестирования

Предоставляет информацию о состоянии тестирования в течение отчетного периода.

6.3.4.1 Отчетный период

Определяет период времени, охваченный отчетом.

6.3.4.2 Прогресс относительно Плана Тестирования

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

6.3.4.3 Факторы, блокирующие прогресс

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

6.3.4.4 Показатели тестирования

Представляет собранные за отчетный период показатели тестирования.

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

6.3.4.5 Новые и измененные риски

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

6.3.4.6 Запланированное тестирование

Определяет тестирование, запланированное для следующего отчетного периода.

6.4 Отчет о Завершении Тестирования

6.4.1 Общие сведения

Отчет о Завершении Тестирования предоставляет собой сводку выполненного тестирования. Отчет может быть для проекта/программы в целом или для определенного подпроцесса тестирования.

В A.2.6 (приложение A) представлен макет Отчета о Завершении Тестирования, а в H.1 и H.2 (приложение H) приведены примеры создания Отчетов о Завершении Тестирования для двух различных проектов.

Содержание Отчета о Завершении Тестирования представлено ниже.

6.4.2 Спецификация документа

6.4.2.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.

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

6.4.2.2 Уникальная идентификация документа

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

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

6.4.2.3 Оформляющая организация

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

6.4.2.4 Полномочия по утверждению

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

6.4.2.5 История изменений

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

Примеры

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

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

6.4.3 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

6.4.3.2 Ссылки

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

6.4.3.3 Глоссарий

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

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

6.4.4 Выполненное тестирование

Предоставляет описание выполненного тестирования.

6.4.4.1 Сводка выполненного тестирования

Суммирует в области применения этого отчета тестирование, выполненное в проекте и/или в подпроцессах тестирования.

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

Пример — Сюда могут входить ограничения на готовность тестовой среды.

6.4.4.2 Отклонения от Плана Тестирования

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

6.4.4.3 Оценка завершения тестирования

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

6.4.4.4 Препятствующие факторы

Описывает препятствующие прогрессу факторы и соответствующие решения, реализованные для их устранения.

6.4.4.5 Показатели тестирования

Представляет сопоставленные показатели тестирования.

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

6.4.4.6 Остаточные риски

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

6.4.4.7 Практические результаты тестирования

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

Пример — Сюда могут входить План Тестирования, Спецификации Контрольных Примеров и Спецификации Процедур Тестирования.

6.4.4.8 Активы тестирования, допускающие повторное использование

Списки всех допускающих повторное использование активов тестирования и их местонахождение.

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

6.4.4.9 Накопленный опыт

Результаты обсуждения накопленного опыта.

7 Документация Процессов Динамического Тестирования

7.1 Общие сведения

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

— Спецификацию тестирования, в которую входят:

— Спецификация Проекта Тестирования;

— Спецификация Контрольных Примеров;

— Спецификация Процедур Тестирования;

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

— Требования к Тестовым Данным;

— Требования к Тестовой Среде;

— Отчет о Готовности Тестовых Данных;

— Отчет о Готовности Тестовой Среды.

— Документацию выполнения теста, в которую входят:

— фактические результаты;

— практические результаты тестирования;

— Журнал Выполнения Теста;

— Отчет об Инцидентах.

Полные шаблоны документов с пояснением приводятся далее. В приложении А представлены схемы всех документов. В приложениях с I до S приведены примеры документации процесса динамического тестирования для организации.

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

7.2 Спецификация Проекта Тестирования

7.2.1 Общие сведения

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

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

Содержание Спецификации Проекта Тестирования представлено ниже.

7.2.2 Спецификация документа

7.2.2.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.

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

7.2.2.2 Уникальная идентификация документа

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

Пример — Уникальный идентификатор может содержать название документа, даты выпуска, версии и/или состояния документа (например, рассмотренный проект, исправленный или окончательный).

7.2.2.3 Оформляющая организация

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

7.2.2.4 Полномочия по утверждению

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

7.2.2.5 История изменений

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

Примеры

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

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

7.2.3 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

7.2.3.2 Ссылки

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

7.2.3.3 Условные обозначения

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

Примечание — Это может быть помещено в Плане Менеджмента Конфигурации.

7.2.3.4 Глоссарий

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

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

7.2.4 Наборы функций

7.2.4.1 Общие сведения

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

Наборы функций могут быть описаны в виде списков или таблиц в отдельном документе либо в составе инструмента.

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

Содержание описания набора функций представлено ниже.

7.2.4.2 Уникальный идентификатор

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

7.2.4.3 Цель

Определяет и кратко описывает особый акцент или цель набора функций.

7.2.4.4 Приоритет

Определяет при необходимости приоритет тестирования определенного набора функций.

7.2.4.5 Конкретная стратегия

Определяет реализацию стратегии тестирования набора функций.

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

7.2.4.6 Прослеживаемость

Перечисляет ссылки на соответствующие функции базиса тестирования.

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

Пример — Функции могут представлять собой требования и/или описания разработки.

7.2.5 Тестовые условия

7.2.5.1 Общие сведения

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

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

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

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

Содержание описания тестовых условий представлено ниже.

7.2.5.2 Уникальный идентификатор

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

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

7.2.5.3 Описание

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

7.2.5.4 Приоритет

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

7.2.5.5 Прослеживаемость

Определяет прослеживаемость с набором функций или предоставляет список ссылок на соответствующие требования и/или описание конструкции в базисе тестирования. Может быть документировано в Матрице Прослеживаемости Тестирования.

7.3 Спецификация Контрольных Примеров

7.3.1 Общие сведения

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

В A.2.8 (приложение A) представлен макет Спецификации Контрольных Примеров, а в J.1 и J.2 (приложение J) приводятся примеры двух различных проектов, в которых показано, как могут быть разработаны Спецификации Контрольных Примеров.

Содержание Спецификации Контрольных Примеров представлено ниже.

7.3.2 Спецификация документа

7.3.2.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.

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

7.3.2.2 Уникальная идентификация документа

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

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

7.3.2.3 Оформляющая организация

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

7.3.2.4 Полномочия по утверждению

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

7.3.2.5 История изменений

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

Примеры

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

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

7.3.3 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

7.3.3.2 Ссылки

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

7.3.3.3 Условные обозначения

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

Примечание — Может быть размещено в Плане Менеджмента Конфигурации.

7.3.3.4 Глоссарий

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

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

7.3.4 Элементы тестового покрытия

7.3.4.1 Общие сведения

Обобщает элементы тестового покрытия для тестовых условий. Элементы тестового покрытия получаются путем применения методики проектирования тестирования к тестовому условию.

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

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

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

Содержание описания элемента тестового покрытия приводится далее.

7.3.4.2 Уникальный идентификатор

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

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

7.3.4.3 Описание

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

Пример — Является ли раздел эквивалентности действительным или недействительным разделом.

7.3.4.4 Приоритет

Определяет в случае необходимости приоритет тестирования конкретного элемента тестового покрытия в тестовом условии. Элементы тестового покрытия с более высоким приоритетом будут проверяться раньше элементов тестового покрытия с приоритетами ниже.

7.3.4.5 Прослеживаемость

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

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

7.3.5 Контрольные примеры

7.3.5.1 Общие сведения

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

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

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

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

Содержание описания контрольного примера приводится ниже.

7.3.5.2 Уникальный идентификатор

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

7.3.5.3 Цель

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

7.3.5.4 Приоритет

Определяет в случае необходимости приоритет тестирования данного конкретного контрольного примера. Контрольные примеры с высоким приоритетом будут выполнены раньше контрольных примеров с приоритетом ниже.

7.3.5.5 Прослеживаемость

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

7.3.5.6 Исходные условия

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

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

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

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

7.3.5.7 Входы

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

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

Должны быть описаны все требуемые отношения между входными событиями.

Пример — Отношение может быть синхронизацией.

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

7.3.5.8 Ожидаемые результаты

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

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

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

7.3.5.9 Фактические результаты и результат тестирования

В описание контрольного примера могут быть включены пустые поля для записи фактических результатов и/или результата выполнения контрольного примера. Кроме того, такие поля могут также быть внесены в Спецификацию Процедур Тестирования (см. 7.4), или раздельно в Фактические результаты (см. 7.9), и/или в результат тестирования (см. 7.10).

7.4 Спецификация Процедур Тестирования

7.4.1 Общие сведения

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

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

В A.2.9 (приложение A) представлен макет Спецификации Процедур Тестирования, а в K.1 и K.2 (приложение K) приводятся примеры двух различных проектов, в которых показано, как могут быть разработаны Спецификации Процедур Тестирования.

Содержание Спецификации Процедур Тестирования представлено далее.

7.4.2 Спецификация документа

7.4.2.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.

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

7.4.2.2 Уникальная идентификация документа

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

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

7.4.2.3 Оформляющая организация

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

7.4.2.4 Полномочия по утверждению

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

7.4.2.5 История изменений

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

Примеры

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

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

7.4.3 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

7.4.3.2 Ссылки

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

7.4.3.3 Условные обозначения

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

Примечание — Может быть размещено в Плане Менеджмента Конфигурации.

7.4.3.4 Глоссарий

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

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

7.4.4 Наборы тестов

7.4.4.1 Общие сведения

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

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

Содержание описания набора тестов приводится ниже.

7.4.4.2 Уникальный идентификатор

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

7.4.4.3 Цель

Определяет и кратко описывает особый акцент или цель для набора тестов.

Пример — «Этот набор тестов предназначен для повторного тестирования коррекций по инцидентам IN301 и IN56».

7.4.4.4 Приоритет

Определяет, в случае необходимости, приоритет тестирования для данного конкретного набора тестов.

7.4.4.5 Содержание (Прослеживаемость)

Обобщает содержание набора тестов. Обычно это представлено списком уникальных идентификаторов отобранных контрольных примеров.

7.4.5 Процедуры тестирования

7.4.5.1 Общие сведения

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

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

Содержание описания процедуры тестирования приводится ниже.

7.4.5.2 Уникальный идентификатор

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

7.4.5.3 Цель

Идентифицирует и кратко описывает особый акцент или цель процедуры тестирования. Идентична цели соответствующего набора тестов.

7.4.5.4 Приоритет

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

7.4.5.5 Запуск

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

7.4.5.6 Выполняемые контрольные примеры (Прослеживаемость)

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

Этот список может представлять собой ссылку на контрольные примеры или может быть копией списка контрольных примеров.

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

В описание процедуры тестирования могут быть включены пустые поля для записи фактических результатов и/или результата тестирования во время выполнения контрольного примера. Кроме того, фактические результаты и/или результат тестирования могут быть также записаны в Фактические Результаты (см. 7.9) и/или в Результат Тестирования (см. 7.10).

7.4.5.7 Связь с другими процедурами

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

Примерами зависимостей от других процедур тестирования являются: «они выполняются перед этой», «одновременно с этой» или «после этой».

7.4.5.8 Остановка и заключительные действия

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

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

7.5 Требования к Тестовым Данным

7.5.1 Общие сведения

Требования к Тестовым Данным описывают свойства тестовых данных, необходимые для выполнения процедур тестирования, определенных в Спецификации Процедур Тестирования.

В A.2.10 (приложение A) представлен макет Требований к Тестовым Данным, а в L.1 и L.2 (приложение L) приводятся примеры двух различных проектов, в которых показано, как могут быть разработаны Требования к Тестовым Данным.

Содержание Требований к Тестовым Данным представлено далее.

7.5.2 Спецификация документа

7.5.2.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.

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

7.5.2.2 Уникальная идентификация документа

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

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

7.5.2.3 Оформляющая организация

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

7.5.2.4 Полномочия по утверждению

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

7.5.2.5 История изменений

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

Примеры

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

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

7.5.3 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

7.5.3.2 Ссылки

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

7.5.3.3 Глоссарий

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

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

7.5.4 Подробные Требования к Тестовым Данным

7.5.4.1 Общие сведения

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

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

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

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

Содержание описания требований к тестовым данным приводится далее.

7.5.4.2 Уникальный идентификатор

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

7.5.4.3 Описание

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

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

7.5.4.4 Ответственность

Определяет, кто ответственен за предоставление доступа к тестовым данным.

7.5.4.5 Необходимый период

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

7.5.4.6 Необходимость сброса

Определяет, должны ли тестовые данные быть сброшены в ходе тестирования.

7.5.4.7 Архивация или утилизация

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

7.6 Требования к Тестовой Среде

7.6.1 Общие сведения

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

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

В A.2.11 (приложение A) представлен макет Требований к Тестовой Среде, а в M.1 и M.2 (приложение M) приводятся примеры двух различных проектов, в которых показано, как могут быть разработаны Требования к Тестовой Среде.

Содержание документа «Требования к Тестовой Среде» представлено далее.

7.6.2 Спецификация документа

7.6.2.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.

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

7.6.2.2 Уникальная идентификация документа

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

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

7.6.2.3 Оформляющая организация

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

7.6.2.4 Полномочия по утверждению

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

7.6.2.5 История изменений

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

Примеры

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

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

7.6.3 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

7.6.3.2 Ссылки

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

7.6.3.3 Глоссарий

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

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

7.6.4 Подробные Требования к Тестовой Среде

7.6.4.1 Общие сведения

Идентифицирует элементы среды, необходимые для выполнения процедур тестирования, определенные в Спецификации Процедур Тестирования. Сюда входит установка для выполнения процедур тестирования перед их выполнением и для любых действий после выполнения теста.

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

— аппаратные средства;

— промежуточное программное обеспечение;

— программное обеспечение;

— периферийные устройства, например, принтеры;

— средства обмена информацией, например, веб-доступ;

— инструменты;

— защищенность;

— место проведения, например, размер помещения и уровень фонового шума;

— аксессуары, например, специальные предпечатные бумажные формы.

Примечание — Элементы среды могут быть сгруппированы по другим критериям, например, WindowsXP/Vista/Windows7 или различные входные интерфейсы, подключенные к ПК, если это лучше подходит. Сюда могут быть включены описания конкретных конфигураций, в которых должны использоваться и/или повторно использоваться эти элементы.

На практике тестовая среда обычно не является идеальным представлением рабочей среды, и подробные требования должны отразить степень представления рабочей среды тестовой средой.

Содержание описания элемента тестовой среды приводится далее.

7.6.4.2 Уникальный идентификатор

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

7.6.4.3 Описание

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

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

7.6.4.4 Ответственность

Определяет, кто ответственен за предоставление доступа к элементу среды.

7.6.4.5 Необходимый период

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

7.7 Отчет о Готовности Тестовых Данных

7.7.1 Общие сведения

Отчет о Готовности Тестовых Данных описывает выполнение каждого Требования к Тестовым Данным.

В A.2.12 (приложение A) представлен макет Отчета о Готовности Тестовых Данных, а в N.1 и N.2 (приложение N) приводятся примеры двух различных проектов, в которых показано, как могут быть разработаны Отчеты о Готовности Тестовых Данных для двух различных проектов.

Содержание Отчета о Готовности Тестовых Данных представлено ниже.

7.7.2 Спецификация документа

7.7.2.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.

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

7.7.2.2 Уникальная идентификация документа

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

Пример Уникальный идентификатор может содержать название документа, даты выпуска, версии и/или состояния документа (например, проект, рассмотренный, исправленный, финал).

7.7.2.3 Оформляющая организация

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

7.7.2.4 Полномочия по утверждению

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

7.7.2.5 История изменений

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

Примеры

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

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

7.7.3 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

7.7.3.2 Ссылки

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

7.7.3.3 Глоссарий

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

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

7.7.4 Состояние Тестовых Данных

7.7.4.1 Общие сведения

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

Содержание описания каждого элемента данных включает в себя:

7.7.4.2 Уникальный идентификатор

Уникальный идентификатор используется в документе Требования к Тестовым Данным.

7.7.4.3 Описание состояния

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

7.8 Отчет о Готовности Тестовой Среды

7.8.1 Общие сведения

Отчет о Готовности Тестовой Среды описывает выполнение каждого требования к тестовой среде.

В A.2.13 (приложение A) представлен макет Отчета о Готовности Тестовой Среды, а в O.1 и O.2 (приложение O) приведены примеры, которые демонстрируют, как Отчеты о Готовности Тестовой Среды могут быть разработаны для двух различных проектов.

Содержание Отчета о Готовности Тестовой Среды представлено ниже.

7.8.2 Спецификация документа

7.8.2.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ и определяет его источники и историю.

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

7.8.2.2 Уникальная идентификация документа

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

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

7.8.2.3 Оформляющая организация

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

7.8.2.4 Полномочия по утверждению

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

7.8.2.5 История изменений

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

Примеры

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

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

7.8.3 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

7.8.3.2 Ссылки

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

7.8.3.3 Глоссарий

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

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

7.8.4 Готовность тестовой среды

7.8.4.1 Общие сведения

Представляет подтверждения выполнения каждого требования к тестовой среде. Это может быть отмечено в соответствующих отведенных полях документа «Требования к Тестовой Среде».

Содержание описания каждого элемента среды включает в себя:

7.8.4.2 Уникальный идентификатор

Уникальный идентификатор используется в документе «Требования к Тестовой Среде».

7.8.4.3 Описание состояния

Определяет выполнение пункта Требований к Тестовой Среде.

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

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

7.9 Фактические Результаты

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

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

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

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

7.10 Результат Тестирования

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

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

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

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

Примечание — Иногда в качестве результата тестирования употребляют альтернативу «Прошел/Не прошел».

7.11 Журнал Выполнения Теста

7.11.1 Общие сведения

Детали записей выполнения одной или более процедур тестирования.

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

В A.2.14 (приложение А) представлен макет Журнала Выполнения Теста, а в R.1 и R.2 (приложение R) приводятся примеры двух различных проектов, в которых показано, как может быть разработан Журнал Выполнения Теста.

Содержание Журнала Выполнения Теста представлено ниже.

7.11.2 Спецификация документа

7.11.2.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ, определяет его источники и историю.

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

7.11.2.2 Уникальная идентификация документа

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

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

7.11.2.3 Оформляющая организация

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

7.11.2.4 Полномочия по утверждению

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

7.11.2.5 История изменений

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

Примеры

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

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

7.11.3 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

7.11.3.2 Ссылки

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

7.11.3.3 Глоссарий

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

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

7.11.4 События

7.11.4.1 Общие сведения

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

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

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

— внезапное понижение производительности компьютера, на котором выполняется тестирование;

— отказ, делающий невозможным дальнейшее выполнение тестирования;

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

Содержание описания каждого события, зарегистрированного в Журнале Выполнения Теста, представлено ниже.

7.11.4.2 Уникальный идентификатор

Определяет порядковый номер записи в Журнале Выполнения Теста.

7.11.4.3 Время

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

7.11.4.4 Описание

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

7.11.4.5 Влияние

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

7.12 Отчетность об Инцидентах Тестирования

7.12.1 Общие сведения

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

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

Формат Отчета об Инциденте может быть определен в другом документе организации, например, как в составе Процессов Управления Инцидентами, в таком случае нужно использовать именно его.

7.12.2 Отчет об Инциденте

В данном контексте Отчет об Инциденте документирует инцидент, выявленный во время тестирования.

Примечания

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

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

В A.2.15 (приложение A) представлен макет Отчета об Инциденте, а в S.1 и S.2 (приложение S) приводятся примеры двух различных проектов, в которых показано, как может быть разработан Отчет об Инциденте.

Содержание Отчета об Инциденте представлено ниже.

7.12.3 Спецификация документа

7.12.3.1 Общие сведения

Здесь представлена информация, которая идентифицирует документ, определяет его источники и историю.

Примеры

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

2 Уникальный идентификатор может включать название документа, даты выпуска, версии и/или состояния документа (например, проект, рассмотренный, исправленный, финал).

7.12.3.2 Уникальная идентификация документа

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

7.12.3.3 Оформляющая организация

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

7.12.3.4 Полномочия по утверждению

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

7.12.3.5 История изменений

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

Примеры

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

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

7.12.4 Введение

Предоставляет разъясняющую информацию о содержании и структуре документа.

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

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

7.12.4.2 Ссылки

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

7.12.4.3 Глоссарий

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

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

7.12.5 Детали инцидента

Содержание описания впервые выявленного инцидента приводится далее.

7.12.5.1 Информация о времени

Записываются даты (и возможно время), когда инцидент первый раз был выявлен.

7.12.5.2 Инициатор

Определяет имена и должности лиц, идентифицировавших инцидент.

7.12.5.3 Контекст

Идентифицирует контекст, в котором выявлен инцидент.

Пример — Сюда могут входить:

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

— Процедура Тестирования и Контрольный Пример с их уникальными идентификаторами, при выполнении которых произошел инцидент;

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

— Процесс или подпроцесс тестирования, в котором наблюдался инцидент.

7.12.5.4 Описание инцидента

Предоставляет подробное описание инцидента. Отмечается, воспроизводим ли инцидент, и если да, то предоставляется информация, достаточная для того, чтобы его воспроизвести.

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

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

Пример — Такими свидетельствами могут быть снимки экрана, журналы системы и выходные файлы.

7.12.5.5 Оценка серьезности (инициатора)

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

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

Кроме того, здесь идентифицируется наличие каких-либо известных обходных решений.

7.12.5.6 Оценка приоритета (инициатора)

Обеспечивает оценку безотлагательности для исправления. В большинстве организаций имеется от трех до пяти категорий.

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

7.12.5.7 Риск

Предоставляет, если это применимо, информацию о введении новых рисков или изменениях состояния существующих рисков.

7.12.5.8 Состояние инцидента

Идентифицирует текущий статус инцидента, который в данном контексте будет «Открыт».

Примечание — Общая последовательность состояний инцидентов в ходе своих жизненных циклов может быть следующей: «Открыт», «Утвержден для разрешения», «Назначен для разрешения», «Фиксирован», «Повторно проверен с фиксацией, подтвержден» и «Закрыт». Другие возможные значения состояния — «Отклонен» или «Отозван».

Приложение A (справочное). Обзор и Схемы Документов

Приложение A
(справочное)

A.1 Общие сведения

На рисунке A.1 показано содержание документации тестирования, установленное Организационной Политикой Тестирования. Документация Динамического Тестирования разрабатывается для конкретного проекта в контексте документации управления тестированием.

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

A.2 Макеты документов

A.2.1 Общие сведения

Базовое содержание каждого из определенных документов представлено ниже.

Все документы включают в себя следующее:

Спецификация документа:

i) Уникальная идентификация документа.

ii) Оформляющая организация.

iii) Полномочия по утверждению.

iv) История изменений.

Введение:

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

ii) Ссылки.

iii) Глоссарий.

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

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

A.2.2 Организационная Политика Тестирования

Специфическая информация Политики Тестирования включает в себя:

a) Положения Политики Тестирования:

i) Цели тестирования.

ii) Процесс тестирования.

iii) Организационная структура тестирования.

iv) Подготовка тестера.

v) Этика тестера.

vi) Стандарты.

vii) Другие соответствующие политики.

viii) Оценка стоимости тестирования.

ix) Архивация и повторное использование актива тестирования.

x) Совершенствование процесса тестирования.

A.2.3 Организационная Стратегия Тестирования

Специфическая информация Организационной Стратегии Тестирования включает в себя:

a) Положения Организационной Стратегии Тестирования в масштабах проекта:

i) Общий менеджмент рисков.

ii) Выбор тестирования и приоритетов.

iii) Документация тестирования и создание отчетов.

iv) Автоматизация и инструменты тестирования.

v) Менеджмент конфигурации рабочих продуктов тестирования.

vi) Управление инцидентами.

vii) Подпроцессы тестирования.

b) Положения Организационной Стратегии Тестирования для конкретных подпроцессов:

i) Критерии входа и выхода.

ii) Критерии завершения тестирования.

iii) Документация тестирования и создание отчетов.

iv) Степень независимости.

v) Методика проектирования тестирования.

vi) Тестовая среда.

vii) Требуемые метрики.

viii) Повторное тестирование и регрессионное тестирование.

Рисунок A.1 — Иерархия документации тестирования

Рисунок A.1 — Иерархия документации тестирования

Рисунок A.2 — Иерархия документации разработки и реализации тестирования

Рисунок A.2 — Иерархия документации разработки и реализации тестирования

A.2.4 План Тестирования

Специфическая информация Плана Тестирования включает в себя:

a) Контекст тестирования:

i) Проект/Подпроцесс тестирования.

ii) Элемент(ы) тестирования.

iii) Область применения тестирования.

iv) Предположения и ограничения.

v) Заинтересованные стороны.

b) Обмен информацией о тестировании.

c) Реестр рисков:

i) Риски продукта.

ii) Риски проекта.

d) Стратегия тестирования:

i) Подпроцессы тестирования.

ii) Практические результаты тестирования.

iii) Методы проектирования тестирования.

iv) Критерии завершения тестирования.

v) Требуемые метрики.

vi) Требования к Тестовым Данным.

vii) Требования к Тестовой Среде.

viii) Повторное тестирование и регрессионное тестирование.

ix) Критерии приостановки и возобновления.

х) Отклонения от Организационной Стратегии Тестирования

e) Действия и оценка тестирования.

f) Комплектность персонала:

i) Роли, действия и ответственность.

ii) Потребность в дополнительном персонале.

iii) Потребности в обучении.

g) Расписание.

A.2.5 Отчет о Ходе Тестирования

Специфическая информация Отчета о Ходе Тестирования включает в себя:

a) Ход тестирования:

i) Отчетный период.

ii) Прогресс относительно Плана Тестирования.

iii) Факторы, блокирующие прогресс.

iv) Показатели тестирования.

v) Новые и измененные риски.

vi) Запланированное тестирование.

A.2.6 Отчет о Завершении Тестирования

Специфическая информация Отчета о Завершении Тестирования включает в себя:

a) Выполненное тестирование:

i) Сводка выполненного тестирования.

ii) Отклонения от Плана Тестирования.

iii) Оценка завершения тестирования.

iv) Препятствующие факторы.

v) Показатели тестирования.

vi) Остаточные риски.

vii) Практические результаты тестирования.

viii) Активы тестирования, допускающие повторное использование.

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Должностная инструкция врача по радиационной гигиене
  • Кальция борглюконат для животных инструкция по применению для бройлеров
  • Радевит витамины в таблетках инструкция по применению
  • Натурсептин витамакс инструкция по применению
  • Подключить ватсап на телефон самсунг пошаговая инструкция как правильно