что такое матрица покрытия в тестировании

Матрица трассабилити

Когда требования на проекте меняются “на лету” и у вас нет под рукой средства контроля за реализацией каждого отдельного требования по фиче или модулю, перед вами встает вопрос: как проводить анализ покрытия? Одним из таких инструментов, который использует наша команда QA на подобных проектах — матрица трассируемости (traceability matrix).

На данный момент мы используем матрицы более 2,5 лет. За это время мы смогли оценить преимущества этого инструмента, а также адаптировать его под наш проект.

Что же такое матрица трассируемости?

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

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

Таким образом, таблица дает визуальное отображение двух параметров:

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

Поэтому матрица имеет вид таблицы, каждая строка которой содержит:

Так как мы используем таск трекер Jira, Zephyr by Jira для тестовой документации и систему управления требованиями Сonfluence, все сущности синхронизируются и такая трассируемость позволяет нам:

Варианты связей в матрице трассируемости

Привязка требования и тест-кейса может быть:

Специфика оценки покрытия с помощью матриц трассируемости

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

Пример. Имеем неатомарное требование: “Пользователь должен иметь возможность изменять и форматировать письмо в текстовом редакторе”. Одного тест-кейса явно будет недостаточно, но если в матрице будет прилинкован только один артефакт, визуально будет представление, что требование покрыто.

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

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

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

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

При таком подходе мы можем использовать метрику, описанную выше: “количество требований к количеству тестовых артефактов”. Даже если у нас есть связи 1 к n, n к n, у нас есть несколько компонентов, каждый из которых может быть использован в нескольких модулях. Требования и приемочные критерии описываются в каждой матрице, а тестовый артефакт используется один.

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

Создание и ведение матрицы

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

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

И здесь можно выделить следующие этапы составления Traceability Matrix:

Сложности в работе с матрицей трассируемости

Если все QA-специалисты заняты тестированием приоритетных задач, мы переносим создание матрицы по конкретной фиче. Максимально он переносится на момент тестирования первой задачи по этой фиче и в таком случае матрица заполняется тест-кейсами по мере тестирования задач, в которых реализована фича.

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

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

Источник

Оценка тестового покрытия на проекте

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

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

Зачем оценивать?

Как оценивать?

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

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

Допустим, у вас в команде есть аналитики, и они не зря тратят своё рабочее время. По результатам их работы созданы требования в RMS (Requirements Management System) – HP QC, MS TFS, IBM Doors, Jira (с доп. плагинами) и т.д. В эту систему они вносят требования, соответствующие требованиям к требованиям (простите за тавтологию). Эти требования атомарны, трассируемы, конкретны… В общем, идеальные условия для тестирования. Что мы можем сделать в таком случае? При использовании скриптового подхода – связывать требования и тесты. Ведём в той же системе тесты, делаем связку требование-тест, и в любой момент можем посмотреть отчёт, по каким требованиям тесты есть, по каким – нет, когда эти тесты были пройдены, и с каким результатом.
Получаем карту покрытия, все непокрытые требования покрываем, все счастливы и довольны, ошибок не пропускаем…

Ладно, давайте вернёмся с небес на землю. Скорее всего, детальных требований у вас нет, они не атомарны, часть требований вообще утеряны, а времени документировать каждый тест, ну или хотя бы каждый второй, тоже нет. Можно отчаяться и поплакать, а можно признать, что тестирование – процесс компенсаторный, и чем хуже у нас с аналитикой и разработкой на проекте, тем больше стараться должны мы сами, и компенсировать проблемы других участников процесса. Разберём проблемы по отдельности.

Проблема: требования не атомарны.

Аналитики тоже иногда грешат винегретом в голове, и обычно это чревато проблемами со всем проектом. Например, вы разрабатываете текстовый редактор, и у вас могут быть в системе (в числе прочих) заведены два требования: «должно поддерживаться html-форматирование» и «при открытии файла неподдерживаемого формата, должно появляться всплывающее окно с вопросом». Сколько тестов требуется для базовой проверки 1-го требования? А для 2-го? Разница в ответах, скорее всего, примерно в сто раз. Мы не можем сказать, что при наличии хотя бы 1-го теста по 1-му требованию, этого достаточно – а вот про 2-е, скорее всего, вполне.

Конечно, такой процесс согласования требует немало ресурсов и времени, особенно поначалу, до наработки практики. Поэтому проводите по нему только высокоприоритетные требования, и новые доработки. Со временем и остальные требования подтянете, и все будут счастливы! Но… а если требований нет вообще?

Проблема: требований нет вообще.

Они на проекте отсутствуют, обсуждаются устно, каждый делает, что хочет/может и как он понимает. Тестируем так же. Как результат, получаем огромное количество проблем не только в тестировании и разработке, но и изначально некорректной реализации фич – хотели совсем другого! Здесь я могу посоветовать вариант «определите и задокументируйте требования сами», и даже пару раз в своей практике использовала эту стратегию, но в 99% случаев таких ресурсов в команде тестирования нет – так что пойдём значительно менее ресурсоёмким путём:

Но… Что делать, если требования ведутся, но не в трассируемом формате?

Проблема: требования не трассируемы.

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

Но… Ненадолго… Кажется, за прошлую неделю аналитики по обращениям заказчиков обновили 4 разные спецификации.

Проблема: требования всё время меняются.

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

В этом случае мы получаем все бенефиты оценки тестового покрытия, да ещё и в динамике! Все счастливы. Но…
Но вы так много внимания уделяли работе с требованиями, что теперь вам не хватает времени либо на тестирование, либо на документирование тестов. На мой взгляд (и тут есть место религиозному спору!) требования важнее тестов, и уж лучше так! Хотя бы они в порядке, и вся команда в курсе, и разработчики делают именно то, что нужно. НО НА ДОКУМЕНТИРОВАНИЕ ТЕСТОВ ВРЕМЕНИ НЕ ОСТАЁТСЯ!

Проблема: не хватает времени документировать тесты.

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

Но… Какое ещё «но»? Какое.

Говорите, все обойдём, и да пребудут с нами качественные продукты!

Источник

Тестирование

Раздел: Тестирование > Тест дизайн > Тестовое Покрытие

Тестовое Покрытие (Test Coverage)

Если рассматривать тестирование как «проверку соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов», то именно этот конечный набор тестов и будет определять тестовое покрытие:

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

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

Существуют следущие подходы к оценке и измерению тестового покрытия:

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

Покрытие требований (Requirements Coverage)

Расчет тестового покрытия относительно требований проводится по формуле:

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

Покрытие кода (Code Coverage)

Расчет тестового покрытия относительно исполняемого кода программного обеспечения проводится по формуле:

В настоящее время существует инструментарий (например: Clover), позволяющий проанализировать в какие строки были вхождения во время проведения тестирования, благодаря чему можно значительно увеличить покрытие, добавив новые тесты для конкретных случаев, а также избавиться от дублирующих тестов. Проведение такого анализа кода и последующая оптимизация покрытия достаточно легко реализуется в рамках тестирования белого ящика (white-box testing) при модульном, интеграционном и системном тестировании; при тестировании же черного ящика (black-box testing) задача становится довольно дорогостоящей, так как требует много времени и ресурсов на установку, конфигурацию и анализ результатов работы, как со стороны тестировщиков, так и разработчиков.

Тестовое покрытие на базе анализа потока управления

Фундаментом для тестирования потоков управления является построение графов потоков управления (Control Flow Graph), основными блоками которых являются:

Для тестирования потоков управления определены разные уровни тестового покрытия:

Таблица 1. Уровни тестового покрытия

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

[1] A practitioner’s Guide to Software Test Design. Lee Copeland

[2] Стандартный глоссарий терминов, используемых в тестировании программного обеспечения Версия 2.0 (от 4 декабря 2008), Подготовлен ‘Glossary Working Party’ International Software Testing Qualifications Board

Источник

Что такое матрица покрытия в тестировании

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Градация Серьезности дефекта

Приоритет (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) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.

Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.

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

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

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

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

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

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

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

Тестирование производительности (performance 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). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.

Источник