ГОСТ Р 56922-2016/ISO/IEC/IEEE 29119-3:2013. Национальный стандарт Российской Федерации. Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования

Приложение F

(справочное)

 

ПЛАН ТЕСТИРОВАНИЯ

 

F.1 Пример 1 - Корпорация Agile

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

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

 

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

- Использовать методики проектирования тестирования, наиболее подходящие к критериям приемки, учитывая то, что истории с более высокими рисками требуют более тщательного тестирования, чем истории с рисками ниже. - Обеспечить и удостовериться, что покрытие тестированием операторов достигает, по крайней мере, 90% всего кода, а покрытие ветвления - 80% для историй с высоким риском и 60% для историй с низким риском. - Перед интеграцией гарантировать, что в реализации истории отсутствуют невыясненные дефекты с уровнем серьезности 1 или 2. - Определить тестирование с участием потребителя ATDD (приемку) в итерации с соглашением и участием потребителя/пользователя. - Перед встречей для презентации протестировать результат итерации в формальных средах тестирования и презентации. - Представлять покрытие элементов тестирования на ежедневных встречах, включая действия низкого уровня по Плану Тестирования и документирование рисков на доске обсуждения. - Сохранять все сценарии тестирования в инструменте ABC таким образом, чтобы они, по мере необходимости, были доступны для повторного тестирования и регрессионного тестирования. - В конце каждой итерации создавать краткий отчет о тестировании и размещать его на портале проекта.

 

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

F.2 Пример 2 - Traditional Ltd

Этот пример включает в себя два примера Плана Тестирования, а именно:

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

- План Тестирования Системы.

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

Traditional Ltd - небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).

 

 

Журнал изменений

 

&Дата&	&Версия&	&Изменения&	&Автор&
10.10.03	0.1	Первый выпуск документа	amj
12.10.03	0.2	Описание нового элемента тестирования	cnj
16.01.04	1.0	Коррекция опечаток после проверки	cnj
20.01.04	1.1	Новая идентификация рисков	amj
05.02.04	1.2	Незначительное изменение структуры текста	cnj
11.03.05	1.3	Обновление после сквозного просмотра	amj

 

1 Введение

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

Цель этого документа состоит в том, чтобы предоставить информацию и основы для планирования и выполнения всех процессов тестирования, необходимых для проверки продукта - блока для ПК UV/TIT-14 33a.

1.2 Ссылки

[PP] План Проекта

[PRS] Спецификация Требований Проекта

[OTS] Организационная Стратегия Тестирования Traditional Ltd

[KD] Спецификация требований к блоку для ПК UV/TIT-14 33a. Vers. 1.8

[HW/SW-spec] Спецификация аппаратных и программных средств

1.3 Глоссарий

В этом документе действительны термины, определенные в [PP].

Используются следующие сокращения:

TBD - Требует уточнения.

2 Содержание плана

2.1 Проект

Продукт UV/TIT состоит из следующих аппаратных модулей:

- ультрафиолетовый спектрометр;

- спектрометр IR;

- автоматическая бюретка;

- конвейер;

- компьютер (сервер);

- ПК.

Архитектура показана на рисунке.

 

┌───────────────────┐  ┌───────────────────┐  ┌────────────────────────┐

│   УФ-спектрометр  │  │   ИК-спектрометр  │  │ Автоматическая бюретка │

└─────────┬─────────┘  └─────────┬─────────┘  └─────────┬──────────────┘

┌────────┴──┬───────────────────┴──────────────────────┴──────

│  ┌────────┴────────┐                       ┌─────────────────┐

│  │    Компьютер    │<─────────────────────>│       ПК        │

│  └─────────────────┘          Сеть         └─────────────────┘

│Шина

│  ┌─────────────────┐

├──┤    Конвейер     │

│  └─────────────────┘

 

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

- ультрафиолетовый модуль;

- модуль IR;

- модуль бюретки;

- модуль конвейера;

- сетевой модуль.

В систему входят следующие программные модули на ПК:

- калибровочный модуль;

- модуль идентификации компонента и концентрации;

- модуль установки;

- модуль контроля и отчетности;

- сетевой модуль.

2.2 Элемент(ы) тестирования

Тестирование для этого проекта включает в себя тестирование:

- каждого из модулей программного обеспечения ПК, перечисленных выше (см. 2.1);

- каждого компонента программных модулей ПК, перечисленных выше (см. 2.1);

- функциональности полной программной системы.

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

2.3 Область применения тестирования

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

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

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

2.4 Предположения и ограничения

Нет.

2.5 Заинтересованные стороны

См. анализ заинтересованной стороны в [PP].

3 Обмен информацией о тестировании

См. [PP].

4 Реестр рисков

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

P - вероятность или возможность риска;

I - влияние или воздействие, если риск осуществляется;

E - воздействие = вероятность "на" влияние.

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

4.1 Риски продукта

 

&Риск&	&P&	&I&	&E&	&Действия по обработке&
1 Калибровка некорректна	2	5	10	Анализ проекта и кода. Дополнительное полное покомпонентное тестирование. Рассмотреть возможность автоматизированной записи тестирования (сравнить фактические результаты с ожидаемыми, возможно использовать тестовый оракул)
2 Идентификация компонента некорректна	2	6	12	Анализ проекта. Контроль кода. Дополнительное полное покомпонентное тестирование
3 Определение концентрации некорректно	1	6	6	Анализ проекта. Контроль кода. Дополнительное полное покомпонентное тестирование
4 Вычисление "дрейфует", если машина время от времени не отключается	3	5	15	Контроль кода. Динамический анализ для идентификации каких-либо утечек памяти. Стресс-тест, позволяющий машине работать в течение нескольких дней без выключения
5 Идентификация компонента слишком медленная	3	1	3	Тест производительности при различных условиях
6 Отчеты некорректны	2	5	10	Анализ проекта и кода. Дополнительное полное покомпонентное тестирование. Рассмотреть возможность автоматизированной записи тестирования (сравнить фактические результаты с ожидаемыми, возможно использовать тестовый оракул)
7 Катастрофические отказы программного обеспечения посреди анализа дают ненадежные результаты	2	2	4	Стресс-тест, вынуждающий машину отказать во время анализа
8 Руководства пользователя непонятны лабораторному техническому персоналу	4	3	12	Оценка удобства использования руководств пользователя. Проверка руководств пользователя
9 Трудно понять установку	4	2	8	Оценка удобства использования прототипа интерфейса. Дополнительная работа со спецификацией требований. Анализ требований. Анализ проекта. Дополнительное скрупулезное покомпонентное тестирование
10 Имеются проблемы с текстом в локализованных отчетах	5	3	15	Анализ отчетов на всех языках, которые вызывают создание более длинных текстов

 

4.2 Риски проекта

 

&Риск&	&P&	&I&	&E&	&Действия по обработке&
1 Недостаточный доступный персонал	2	4	8	Быть чрезвычайно осторожным при оценке трудоемкости проекта. Выполнить полный анализ рисков продукта и составлять планы в строгом соответствии с ним. Внимательно следить за ходом тестирования. Четко докладывать о проблемах выполнения и ресурсов при каждом удобном случае
2 Доступный персонал не обладает достаточными знаниями и опытом	2	3	6	Выполнить гэп-анализ потребностей относительно того, что доступно. Подготовить учебный план для каждого отдельного участника. Включить учебное время в расписание. Найти наставников, если это возможно. Выделить дополнительное время для анализа работ, выполняемых людьми с минимальным опытом
3 Некоторые из доступных людей, не будут/не могут работать вместе	5	2	10	Попытаться идентифицировать, в чем проблема. Устроить арбитраж, если необходимо/возможно. По необходимости, использовать анализ Belbin для улучшения понимания между различными типами. Распределить действия так, чтобы было как можно меньше контактов между рассматриваемыми людьми
4 Слишком мало доступных лицензий для инструментов выполнения теста	3	2	6	Попытаться убедить ответственных за утверждение дополнительных лицензий, что это необходимо. Распределить и подробно спланировать действия с целью уменьшения времени ожидания в максимально возможной степени. Выполнить тщательный контроль прогресса. Доложить о соответствующих проблемах на максимально раннем этапе и максимально ясно
5 Менеджер по тестированию не знаком с инструментами управления поддержкой проекта тестирования	4	1	4	Получить финансирование и запланировать обучение, если это возможно. Найти кого-то из компании, имеющего опыт использования инструмента. Выделить дополнительное время для оценки действий по управлению тестированием. Доложить о соответствующих проблемах на максимально раннем этапе и максимально ясно
6 Предыдущий опыт показывает, что субподрядчик не всегда предоставляет ожидаемый материал вовремя и ожидаемого качества	3	4	12	Требовать точного выполнения договорных обязательств. Установить конкретные критерии качества поставляемых компонентов. Определить последствия нарушений качества и плана поставки. Тщательно следить за прогрессом и качеством. Реализовать по необходимости воздействие
7 На отчеты об инцидентах затрачивается больше 30% времени выполнения теста	4	5	20	Приостановить тестирование до тех пор, пока не сделано тестирование единицы

 

5 Стратегия тестирования

5.1 Подпроцессы тестирования

Тестирование продукта - блока для ПК UV/TIT-14 33a должно включать в себя следующие подпроцессы тестирования:

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

- тестирование интеграции компонентов;

- тестирование системы.

5.2 Практические результаты тестирования

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

- план подпроцесса тестирования;

- спецификация тестирования;

- журнал тестирования;

- отчет о завершении подпроцесса тестирования.

5.3 Методы проектирования тестирования

Определяются для каждого подпроцесса тестирования согласно соответствующему разделу [OTS].

5.4 Критерии завершения тестирования

Определяются для каждого подпроцесса тестирования согласно соответствующему разделу [OTS].

5.5 Требуемые метрики

Определяются для каждого подпроцесса тестирования согласно соответствующему разделу [OTS].

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

Определяются для каждого подпроцесса тестирования согласно соответствующему разделу [OTS].

Конкретные требования инструментов тестирования:

- Ant;

- JIRA;

- JBoss;

- Test link 1.8 RC2.

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 Персонал

7.1 Роли, действия и ответственность

Высокоуровневые действия - это подпроцессы, которые будут выполняться. Подробные действия и ответственность будут документированы в планах подпроцессов тестирования.

7.2 Потребность в дополнительном персонале

См. конкретные Планы Подпроцессов Тестирования.

7.3 Потребности в обучении

См. конкретные Планы Подпроцессов Тестирования.

8 Расписание

График тестирования, соответствующего этому плану, включен в диаграмму Ганта для проекта.

F.2.2 План Тестирования Системы

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

Титульная страница и спецификация документа в этом примере опущены.

1 Введение

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

2 Содержание плана

2.1 Проект

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

2.2 Элемент(ы) тестирования

Элемент(ы) тестирования - интегрированное программное обеспечение ПК для блока для ПК UV/TIT-14.

2.3 Область применения тестирования

Функции, которые будут проверены, могут быть подразделены на следующие группы:

- установка системы;

- идентификация компонентов (IR + UV);

- концентрация компонентов (UV + управление бюреток);

- калибровка UV, IR и бюреток;

- отчеты по идентификации, концентрации и калибровке;

- отчеты по установке;

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

- статистика.

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

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

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

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

2.4 Предположения и ограничения

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

2.5 Заинтересованные стороны

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

3 Обмен информацией о тестировании

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

4 Реестр рисков

4.1 Риски продукта

См. План Тестирования Проекта относительно рисков продукта.

4.2 Риски проекта

D - Разработка.

T - Тестирование.

 

&Риск&	&Последствия&	&Предотвращение&	&Действия по обработке&
1 Зависимость разработки	Если разработка будет задержана, то соответственно будет задержано тестирование. Могут быть трудности с соблюдением графика	D: Выполнить реалистичную переоценку и планирование. T: Нет	D: Существенно переоценить планы в целом, не по частям. T: Нет
2 Кажется, мы не можем автоматизировать столько процедур тестирования, сколько предполагалось	Больше процедур тестирования должно быть выполнено вручную. Могут быть трудности с соблюдением графика	D: Нет. T: Исследовать этот вопрос во время разработки процедур тестирования	D: Нет. T: Добавить ресурсы
3 Наличие блокирующих дефектов	Некоторые этапы тестирования откладываются. Могут быть трудности с соблюдением графика	D: Позаботиться о тщательном тестировании модулей и интеграции. T: Нет	D: Исправить дефекты. T: Нет
4 Все время продолжают поступать изменения	Большая часть трудозатрат уходит на обновление документации вместо тестирования	D: Установить базовые спецификации и придерживаться их. T: Нет	D: Нет. T: Нет

 

5 Стратегия тестирования

5.1 Практические результаты тестирования

Практические результаты тестирования всей системы включают:

- настоящий план в актуальной версии на момент поставки;

- полный набор спецификаций тестирования;

- отчет о завершении тестирования полной системы блока для ПК UV/TIT-14 33a.

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

- журнал тестирования, подписанный менеджером по тестированию. Журнал тестирования должен включать идентификационные номера отчетов по инцидентам, выявленным во время выполнения тестирования, если таковые имеются;

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

5.2 Методы проектирования тестирования

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

- разбиение эквивалентности и анализ граничных значений;

- метод дерева классификации;

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

- тестирование переходов состояний;

- тестирование по сценариям использования.

5.3 Критерии завершения тестирования

Тестирование системы должно обеспечить 80% покрытия требований, и все процедуры тестирования должны быть выполнены без отказов с уровнем серьезности 1 ("Высокий"),

5.4 Требуемые метрики

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

- количество выполненных контрольных примеров;

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

- количество повторно выполненных контрольных примеров;

- количество разрешенных инцидентов по категориям;

- количество затраченного времени.

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

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

- [PRS];

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

- руководство пользователя по UV/TIT-14 33a;

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

Все аппаратные средства, операционная система и сеть описаны в спецификации [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 Персонал

7.1 Роли, действия и ответственность

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

 

&Роль/действие&	&1&	&2&	&3&	&4&
Руководитель тестирования	A	A	A	A
Аналитик тестирования	R	R	R	C
Разработчик тестирования	R	R	R	I
Эксперт по тестовой среде	-	R	-	I
Исполнитель тестирования	I	I	I	R

 

Где:

R - ответственный;

A - отчитывается;

C - консультирует;

I - получает информацию.

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

 

&Инициалы&	&Имя&	&Описание&
LN	Лейла Нельсон	Аналитик тестирования
CBB	Кристина Багг	Аналитик/разработчик тестирования
CD	Карстен Доминик	Эксперт по тестовой среде
T1 - T2	Требует уточнения	Выполнение теста

 

7.2 Потребность в дополнительном персонале

Для выполнения тестирования нам нужны два студента (или другие специалисты с достаточной квалификацией). Они будут наняты в соответствии с правилами найма HR.

7.3 Потребности в обучении

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

8 Расписание

Полный график тестирования показан ниже на рисунке.