Какие приложение могут выступать в качестве матрицы соответствия

Обновлено: 22.01.2025

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

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

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

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

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

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

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

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

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

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

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

3.2. Объектно-ориентированная инженерия требований

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

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

3.2.1. Сценарный подход

Одним из методов построения проектной модели системы, логической и физической моделей являются сценарии use case, используемые для визуального представления требований в проектной модели системы. Эта модель уточняется и дополняется новыми сценариями для получения логической и физической моделей. Термин сценарий обозначает некоторый вариант представления модели выполнения системы [3.1, 3.5].

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

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

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

Т.е. имеем цепочку трансформаций:

проблема цель сценарий объект.

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

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

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

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

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

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

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

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

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

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

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

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

ОСНОВНЫЕ ТЕРМИНЫ

Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:

планированием работ (Test Management)

проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.

анализом результатов (Test Analysis)

Основные цели тестирования

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

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

Верификация (verification)

Валидация (validation)

Соответствие продукта требованиям (спецификации)

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

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

Следует уметь различать, что:

Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).

Жизненный цикл бага

Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.

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

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

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

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

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

НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА

Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.

Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

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

Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).

Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.

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

Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.

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

ВИДЫ ТЕСТИРОВАНИЯ

Основные виды тестирования ПО

Классификация по целям

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

Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).

Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».

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

Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения.

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

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

Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.

Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).

Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

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

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

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

Классификация по позитивности сценария

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

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

Классификация по знанию системы

Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.

Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).

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

Классификация по исполнителям тестирования

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

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

Классификация по уровню тестирования

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

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

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

Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.

Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.

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

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

Классификация по исполнению кода

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

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

Классификация по хронологии выполнения

Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.

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

Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

ДОКУМЕНТАЦИЯ

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

Основные атрибуты требований:

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

Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

Недвусмысленность — требование должно содержать однозначные формулировки.

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

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

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:

Что нужно тестировать?

Как будет проводиться тестирование?

Когда будет проводиться тестирование?

Критерии начала тестирования.

Критерии окончания тестирования.

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

Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.

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

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

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

Процесс определения покрытия кратко картинкой:

Итак, вы прошли этап определения причастных сторон, ознакомились с документацией по Проекту, получили описание архитектуры Продукта/Системы, требования к ней, критерии приёмки.
Теперь надо определиться с объёмом тестирования и видами тестирования.

сущности (задействованные чаще всего, самые важные), связи сущностей, состояния сущностей и правила перехода между ними, действия с сущностями (CRUD, фильтрация, сортировка, поиск, экспорт, импорт, валидация, парсинг, копирование). , use cases (user scenarios, system scenarios), проходящие в продукте.
входящую и исходящую интеграции, каким способом она происходит (ETL, RPC, REST API, file, MQ и т.д.) и с кем. -- какие роли с какими правами; на какие бизнес-процессы, use cases и на работу с какими сущностями она распространяется.
UI как те или иные виды экранных форм в web-, desktop-, mobile-приложении.
CLI (command-line interface) и возможные команды.
поддерживаемые конфигурации.

Тесты на основе уже определённых и описанных системными и бизнес-аналитиками критериев приёмки

Позитивные проверки всего и вся:

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

UI-тесты

состояние и содержимое UI-элементов на странице
логика отображения и поведения UI-элементов
маски на полях, допустимая длина вводимых данных

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

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

негативные тесты на безопасности:

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

Тесты на основе уже определённых и описанных системными и бизнес-аналитиками критериев приёмки
обычные нагрузочные тесты, стресс-тесты, тесты на отказоустойчивость и т.п.
обычные тесты на корректную работу (запуск) в различных предусмотренных конфигурациях
обычные тесты на корректный запуск приложения в различном environment и ОС
обычные тесты на установку приложения с соблюдением SLA
симуляция недоступности БД в процессе работы
симуляция потери данных в процессе работы (удаление файлов, сущностей в БД)
симуляция потери доступа к транспорту
симуляция недоступности портов и ресурсов
симуляция стопора в очереди в транспорте (недоступность Kafka/RabbitMQ, снижение пропускной способности)

Матрица трассируемости требований (Requirement Traceability Matrix) = двумерная таблица, содержащая соответствие требований (user/business requirements, software requirements) и подготовленных тест-кейсов (test cases).
Основное её предназначение в отображении степени покрытия требований тест-кейсами.

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

ID Бизнес-Требования (BR, Business Requirement) или Бизнес Варианта Использования (Business Use Case);
суть Бизнес-Требования;
(опционально) приоритет Бизнес-Требования;
(опционально) приёмочный критерий Требования (acceptance criteria);
(опционально) ID Функционального требования (FR, functional requirement) из Спецификации к Требованиям ПО (SRS) или ID Варианта Использования (UC, Use Case);
(опционально) описание Функционального требования или Варианта Использования;
ID тестового артефакта (Тест-кейса);
(опционально) ожидаемый результат Тест-кейса (expected result);
(опционально) номер Задачи на разработку из таск-трекера + её описание;
(опционально) логический блок / модуль, к которому принадлежит Задача/Требование;

В соответствии с лучшими практиками, Бизнес-Требования следует максимально декомпозировать и нумеровать в соответствии со следующим правилом: BR001, BR002 и т.д.
Для каждого Бизнес-Требования будет одно или несколько Функциональных Требований, которые должны соответствовать соглашению по нумерации для соответствующего бизнес-требования: FR001.01, FR001.02, FR001.03, FR002 и т.д. Функциональные требования также должны быть максимально декомпозированы.

Пример рабочего процесса, в котором присутствует создание Матрицы Трассировки:

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

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

( очень платное ) IBM Rational DOORS
( платное )( есть trial на 14 дней ) Cradle
( платное ) DevProm Requirements. Один из функциональных блоков программного продукта Devprom ALM
( платный ) плагин RMsis для Atlassian JIRA
( платный ) плагин R4J для Atlassian JIRA

Проектные - связанные с коммуникациями участников команды, инфраструктурой:
- изменение скоупа тестирования после проверки основных тест-кейсов
.
Продуктовые - связанные только с тестируемыми функциями и тестовыми средам:
- отсутствие тестовых зон с заданной конфигурацей (медленные БД, (не)обезличенные БД, отсутствие каких-то тестовых данных)
- недопустимое время на ожидание подготовки тестовых зон со стороны Администраторов / DevOps
.

Проектирование тестов (test design) = процесс проектирования и создания тест-кейсов (тестовых случаев/сценариев/дел, case - юр. "дело"), в соответствии с определёнными ранее критериями качества, целями тестирования, критериями приёмки.

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

Формат тест-кейса

Название (subject)
(опционально) Описание (description) -- что проверяем, некие важные подробности
(опционально) Трассировка (tracing) -- ссылки на таск и страницу с требованиями к проверяемой тест-кейсом функциональности, юзкейс, юзерстори ссылки на бегрепорты по тест-кейсу
Предусловия (preconditions), например:
- Окружение: развёрнуто то-то и сё-то, ссылка на скрипты деплоя и инструкции при наличии, перечисление важных атрибутов конфигурации
- Объект тестирования: тестируемая Система развёрнута так-то и там-то, ссылка на репозиторий, ссылка на регистр с контейнерами при наличии, ссылка на скрипты деплоя и инструкции при наличии, перечисление важных атрибутов конфигурации
- Данные: в БД такой-то имеются такие-то данные

"Тело" тест-кейса, обычно в виде таблицы такого вида:

№ п/п	Действие	Ожидаемый результат	Результат
1	Делаем вот это	Видим вот это, это и это	<успех / неудача, комментарий с подробностями фактического результата при неудаче>
N	.	.	.

Определение классов эквивалентности (Equivalence Partitioning)
и Анализ Граничных Значений (Boundary Value Analysis)

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

Попарное тестирование (Pairwise Testing)

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

Причина / Следствие (Cause/Effect)

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

Тестирование смены состояний (State Transition Testing)

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

Таблица решений (Decision Table Testing)

Способ компактного представления модели со сложной логикой. Устанавливает связь между условиями (входными параметрами) и результатом (действиями Системы). Определить/записать все условия. Просчитать возможное количество комбинаций условий. Заполнить комбинации. Записать действия. Убрать лишние комбинации.
Например:

Тестирование путей (Path Testing)

Однако, его же можно использовать для покрытия тестами логики тестируемой системы, если у нас имеются BPMN-диаграммы и UML activity-диаграммы, описывающие процессы, проходящие в ней.
Количество сценариев будет зависеть от количества логических узлов ветвлений. Если условия ветвлений зависят от значений каких-то данных, то скорее всего, для каждого тест-сценария необходимо, опираясь на диаграмму, определить набор входных данных.
Очень упрощённо:

Посмотреть/послушать о такого рода применении метода можно здесь Где логика?! История тестирования одного микросервиса (Денис Кудряшов, Leroy Merlin, 2020), где докладчик скомбинировал этот метод с вышеупомянутой таблицей решений (Decision Table Testing).

Предугадывание ошибки (Error Guessing)

Это когда тест-аналитик/тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест-аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки.

Исчерпывающее тестирование (Exhaustive Testing)

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

QA ( aнгл. Quality assurance — обеспечение качества) — это процесс или результат формирования требуемых свойств и характеристик продукции по мере её создания.

Баг ( англ. Bug — насекомое ) — ошибка в ПО из-за которой программа не выдает пользователю ожидаемый конечный результат.

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

Система отслеживания ошибок ( англ. bug tracking system ) — программа учета и/или контроля багов:

•HP ALM ( HP Application Lifecycle Management )

Приоритет багов ( англ. Bug priority ) — важность той или иной ошибки в ПО:

•Trivial — косметическая малозаметная проблема

•Minor — очевидная, незначительная проблема

•Major — значительная проблема

•Critical — проблема, нарушающая работу c ключевыми функциями ПО

•Blocker — проблема, нарушающая функционирование ПО

Очень часто тривиальные ошибки относятся к минорным и поэтому тривиальные не так часто используются.

Error — ошибка пользователя, то есть он пытается использовать программу иным способом.

Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы.

UX ( англ. User eXperience — опыт пользователя ) — ощущение, испытываемое пользователем во время использования цифрового продукта

UI ( англ. User Interface — пользовательский интерфейс ) — это инструмент, позволяющий осуществлять взаимодействие «пользователь — приложение».

Анализ Граничных Значений ( англ. Boundary Value Analysis — BVA ). Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

Баг Репорт ( англ. Bug Report — отчет об ошибке ) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

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

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

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

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

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

Матрица соответствия требований ( англ. Traceability matrix ) — это двумерная таблица, содержащая соответсвие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases).

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

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

Причина / Следствие ( англ. Cause/Effect — CE ). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Из этого состоят тест-кейсы.

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

Альфа-тестирование ( англ. Alpha testing ) — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования.

Бета-тестирование ( англ. Beta testing ) — интенсивное использование почти готовой версии продукта с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (релизом) продукта на рынок, к массовому потребителю.

Релиз-кандидат или RC ( англ. Release candidate ), Пре-релиз или Pre, иногда «гамма-версия» — стадия-кандидат на то, чтобы стать стабильной.

Релиз или RTM ( англ. Release to manufacturing — промышленное издание ) — издание продукта, готового к тиражированию.

Пост-релиз или Post-RTM ( англ. post-release to manufacturing ), издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта.

Тест дизайн ( англ. Test design ) — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы).

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

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

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

Чек-лист ( англ. Check list ) — это документ, описывающий что должно быть протестировано. Обычно составляется на те или иные требования. И очень часто по чек-листу составляется тест план. С чек-листа начинается наша работа. Мы составляем список того, чем мы собираемся заниматься и отдаем его, обычно, менеджеру для подтверждения и далее на его основе начинаем делать тестовый план.

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

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

Определение матрицы прослеживаемости требований

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

Почему требуется матрица прослеживаемости требований?

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

Типы матрицы прослеживаемости требований

Давайте посмотрим на другую матрицу прослеживаемости.

Прямая трассировка

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

Обратное отслеживание

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

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

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

Примеры матрицы прослеживаемости требований

Бизнес-требование №

Описание

БР1

BR2

BR3

BR4

Скажем, TS1 (BR1) - предоставляется возможность мониторинга в реальном времени.

Контрольные примеры

Контрольный пример 1: опция TS1.TC1 (BR1) выполнена успешно.

Контрольный пример 2: опция TS1.TC2 (BR1) отключена.

дефекты

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

Скажем, X01, поэтому этот идентификатор отображается в матрице, чтобы показать дефект.

Матрица покрытия и отслеживания требований

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

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

Типы спецификаций требований

1. Спецификация требований к программному обеспечению
2. Бизнес-требования
3. Использование прецедентного документа
4. Документ с требованиями проекта
5. Документы для проверки дефектов

Преимущества

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

Как создать матрицу прослеживаемости требований?

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

Кроме того, знание Excel весьма полезно, потому что для создания матрицы используются разные инструменты, а также существуют различные формулы, поэтому, если человек знает об этом, он легко создает матрицу и выполняет то же самое. Вот пример RTM:

Важные моменты для запоминания

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

Вывод

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