Что такое вид тестирования

Виды тестирования и подходы к их применению

Блочное (модульное, unit testing) тестирование наиболее понятное для программиста. Фактически это тестирование методов какого-то класса программы в изоляции от остальной программы.

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

Для осуществления unit тестирования существуют специальные фреймворки. Например, NUnit или тестовый фреймфорк из Visual Studio 2008. Для возможности тестирования классов в изоляции существуют специальные Mock фреймворки. Например, Rhino Mocks. Они позволяют по интерфейсам автоматически создавать заглушки для классов-зависимостей, задавая у них требуемое поведение.

По unit тестированию написано много статей. Мне очень нравится MSDN статья Write Maintainable Unit Tests That Will Save You Time And Tears, в которой хорошо и понятно рассказывается как создавать тесты, поддерживать которые со временем не становится обременительно.

Интеграционное тестирование

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

Если к нему подходить как к unit-тестированию, у которого в тестах зависимости не заменяются mock-объектами, то получаем проблемы. Для хорошего покрытия нужно написать много тестов, так как количество возможных сочетаний взаимодействующих компонент — это полиномиальная зависимость. Кроме того, unit-тесты тестируют как именно осуществляется взаимодействие (см. тестирование методом белого ящика). Из-за этого после рефакторинга, когда какое-то взаимодействие оказалось выделенным в новый класс, тесты рушатся. Нужно применять менее инвазивный метод.

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

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

Понятно, что для проверки подобных спецификаций потребуется движок, который бы считывал спецификации и проверял их соответствие поведению программы. Я такой движок написал и остался доволен данным подходом. Скоро выложу движок в Open Source. (UPD: Выложил)

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

Системное тестирование

Системное — это тестирование программы в целом. Для небольших проектов это, как правило, ручное тестирование — запустил, пощелкал, убедился, что (не) работает. Можно автоматизировать. К автоматизации есть два подхода.

Первый подход — это использовать вариацию MVC паттерна — Passive View (вот еще хорошая статья по вариациям MVC паттерна) и формализовать взаимодействие пользователя с GUI в коде. Тогда системное тестирование сводится к тестированию Presenter классов, а также логики переходов между View. Но тут есть нюанс. Если тестировать Presenter классы в контексте системного тестирования, то необходимо как можно меньше зависимостей подменять mock объектами. И тут появляется проблема инициализации и приведения программы в нужное для начала тестирования состояние. В упомянутой выше статье Scenario Driven Tests об этом говорится подробнее.

Источник

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

Учил студентов предмету «Тестирование и отладка программного обеспечения» в ИжГТУ. Структуру курса обучения построил на основе классификации видов тестирования.

Карту можно скачать тут.

Карта с видами тестирования на каждое занятие

Пословица разных народов мира.

Каждый раз для выбора вида тестирования использовалась карта. Каждый раз использовался опорный список видов работ.

Попарное сравнение

Всё познаётся только в правильно выполненном сравнении.

Автор мне неизвестен, возможно, Фридрих Ницше или Рене Декарт.

На конкретных примерах рассматривали, какая техника тест-дизайна при подготовке сценариев более применима к функциональному тестированию, а какая к конфигурационному. Разбирали в чём отличия выполнения тестов для основного функционального исследовательского тестирования, от основного функционального тестирования по тестам. Чем будут отличаться планы тестирования. Как при этом, выглядят проекты тестов (чеклист или mind-карта, против инструкций с порядком действий и ожидаемым результатом). Что является общим — процесс отслеживания дефектов.

Рассматривали, чем отличаются отчёты по конфигурационному тестированию и тестрованию масшабируемости, или отчёты по нагрузочному и объёмному.

Приносил примеры отчётов, несекретных и старых, сокращал их до 3-х страниц, удалив конфиденциальную информацию. Разбирали, что в отчётах общего (структура: цели, основа, краткие результаты, детали). В чём отличия. Как их читать. Как составлять. Как формировать автоматически.

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

Список работ по тестированию взял из SWEBOK (v3), глава 4 «Software Testing», раздел «Test Process», подраздел «Test Activities».

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

Зачем карта

Фёдор Иванович Тютчев, 27 февраля 1869.

Карта является опорным конспектом для преподавателя. Напоминает о чём, надо успеть сказать. Помогает не сказать лишнего. Ведь времени так мало, а рассказать надо так много.

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

Особенность этой карты с видами тестирования — наличие определений для каждого узла. Если сохранить карту в формате html, получится объёмное чтиво.

Есть ограничения использования mind-карт в подготовке темы занятия. При большом количестве узлов, карта плохо читается на формате альбомного листа. И тогда лучше использовать доску и мел — дублировать части схемы на доске.

О доске и меле

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

Потом стал стараться писать и рисовать, как в начальных классах. Ровно, красиво, чётко («как слоги в пионерской речёвке»). Студенты стали задавать больше вопросов. Стало понятнее, что занятия стали понятнее.

О преподавании

Готовился основательно. Случались технические сбои и заминки, не всё удавалось показать и объяснить. О каждом случае можно отдельную историю рассказать. Так подготовка лабораторных работ по тестированию — дорога на Эверест, уложенная граблями. Отладить работу автоматического теста в идеальном окружении, бывает, непросто. А если окружение неидеальное, на каждом учебном компьютере оно своё, и тест написан студентом на скорую руку, то лишь телепатия и «эффект разработчика», в которого ты перевоплощаешься, могут помочь.

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

Источник

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

Вы решили дать новый виток своей карьере и попробовать силы в QA? Это отличная идея! И начать своё знакомство с тестированием ПО стоит с основ.

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

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

1. Цель

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

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

Функциональное тестирование направлено на проверку того, какие функции ПО реализованы, и того, насколько верно они реализованы.

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

2. Степень автоматизации

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

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

3. Позитивность сценария

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

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

4. Доступ к коду программного продукта

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

Проверка программного продукта по каждому из сценариев требует достаточно глубоких знаний. К примеру, об особенностях тестирования «чёрного ящика» в своей книге подробно рассказал Борис Бейзер. Это фундаментальная работа, с которой полезно ознакомиться каждому на старте работы в QA. Об этой и других полезных книгах мы рассказали в статье.

5. Уровень

Этот пункт определяет объект тестирования.

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

6. Исполнитель

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

7. Формальность

Этот пункт определяет подготовленность тестировщика перед началом проверки.

Начинающие тестировщики редко работают на свободном уровне. А вот опытные QA-специалисты могут позволить себе проверку без дополнительной подготовки. Мастерство растёт со временем, как и оплата труда тестировщика. О том, сколько получают инженеры, читайте в нашем блоге.

8. Важность

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

Надеемся, с этой статьёй вам будет проще ориентироваться в самом начале пути в тестировании программного обеспечения. А что ещё поможет на старте карьеры? Обучение на курсе QA Academy. Записывайтесь прямо сейчас!

Источник

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

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

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

Для чего проводится тестирование ПО?

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

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

К задачам обеспечения качества относятся:

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

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

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

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

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

Этапы тестирования:

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

Требования

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

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

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

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

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

Градация Приоритета дефекта (Priority):

Тестовые среды

Основные фазы тестирования

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

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

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

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

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

Согласно ISTQB, тестирование белого ящика — это:

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

Согласно ISTQB, тестирование черного ящика — это:

Тестовая документация

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

Тест план должен отвечать на следующие вопросы:

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

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

Атрибуты тест кейса:

Источник

Какие тесты вам нужны? Часть 2. Матрица видов тестирования

Аннотация

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

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

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

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

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

Принадлежность к одной категории не исключает принадлежность к другой.

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

Смотрите какой милый майнд мап с видами вина:

Казалось бы, он полностью охватывает все виды вин. А теперь посмотрите на него еще раз и перечислите вина по странам производства, как они расставлены в супермаркете или в меню ресторана. Не получается? А как же тогда выбирать? Эта карта не подходит для выбора по производителям. Если присмотреться внимательнее — там есть приписка «по стилю и вкусу».

Вот так же и с видами тестов.

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

А критерий группировки может является ключевым критерием выбора.

Карта видов тестирования

Мне нравится подход, что использовался в статье про тестирование ПО на Википедии, поскольку рассмотрено большое множество разрезов.

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

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

Цветокоды

Про желтые блоки в карте знаний

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

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

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

Про зелёные блоки в карте знаний

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

Зеленые блоки отличаются от голубых тем, что редко вообще упоминаются в русскоязычных обзорах видов тестирования. Однако если вы, к примеру, поищите словосочетание «suitability testing» вы найдете много полезного.

Как пользоваться картой

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

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

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

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

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

Критерии классификации

Приступим, пробежимся в ширину по верхнему уровню дерева.

1. Вид требований

Все тесты зависят от того, что требуется от разрабатываемого ПО.

Если нам есть что разрабатывать, значит есть что тестировать. Наличие формально описанных требований — вещь очень важная, но не является обязательной. Не важно, есть ли у вас бумажка, называемая «ТЗ»/«SRS» или нет — требования, на основе которых вы проводите проверку, всегда есть.

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

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

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

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

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

Вам нужны все виды тестов из первой группы

Если вам нужны только «минимально необходимые», а не «необходимые и достаточные» — используйте функциональные suitability и accuracy тесты.

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

На этом шаге многие останавливаются. «Нам нужны функциональные тесты«. Но надо идти дальше.

2. Объект тестирования

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

Приложу эту группу отдельно:

Справа я написала три группировки, они условны, поэтому не являются родительскими узлами. Потому что эти требования могут быть и функциональными, и не функциональными, в зависимости от того, что разрабатываем. В общем случае инфраструктурные мы будем проводить до и для передачи в production. А эксплуатационные мы будем проводить на prod-like среде, когда уже будет определено, на каком железе будет жить наша система.

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

Очень важно понимать, что

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

Как и тесты производительности, отказоустойчивости и т.п. — не всегда виды NFR.

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

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

Пример 3. Разработка приложения Jmeter. Это — популярный инструмент для проведения нагрузочного тестирования. Его функционалом является нагрузочное тестирование. Это — случай, когда субъект тестирования стал объектом тестирования. Рекурсивненько, да? Тесты нагрузочного тестирования JMeter являются функциональными.

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

Вот из-за таких случаев не уместно разделять функциональные тесты по видам функционала (только по видам требований). И не уместно относить сами функциональные тесты к объектам при категоризации «по объекту тестирования».

3. Знание системы

В зависимости от знания системы тесты бывают тестами черного, серого и белого ящика. Эти термины идут из Теории Управления, и я надеюсь, что они вам знакомы в более широком смысле, чем как виды тестов.

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

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

Распространено заблуждение, что проведение таких тестов необходимо и достаточно, а если не приводит к повышению качества продукта — то тестировщики плохо поработали.

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

Подробно о влиянии знания системы на проведение тестирования я напишу отдельно.

4. Степень автоматизации

Про автоматизацию пишут везде и много. Я сама очень люблю эту тему.

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

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

Об автоматизации надо задуматься, отвечая на вопрос:

думайте об автоматизации заранее.

5. Степень изолированности компонентов

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

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

End-To-End тестирование может быть black box, например, на приёмочных испытаниях при первичной сдаче в эксплуатацию. А до передачи — grey box, когда тестировщики знают, как устроена система и где у нее узкие места. Заливают данные на самый передний вход и ждут течь из всех щелей и ожидаемый результат из самого заднего выхода. От знания системы зависит подготовка тестовых данных. Зная, где может прорвать, можно подсунуть то, что в нужную щель пролезет. При этом может быть так, что потенциально дефектный компонент не доступен сам по себе — поэтому речь не идет о тестировании компонента. Заводится вся машина, и дефекты могут быть обнаружены не только там, где ожидаются.

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

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

6. Время проведения тестирования

«Тестируйте от критичного дефекта и до релиза».

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

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

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

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

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

7. Степень подготовленности тестов

Как бы то ни было, даже если по началу по всем пунктам вы ответили «нет», это не значит, что на вашем проекте будет проводиться только исследовательское тестирование. Можно взять ТЗ и проверить, выполнено ли то, что в нем написано — это будет вполне подготовленное тестирование. Когда ты знаешь, что искать.

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

Подробнее — в другой части.

8. Глубина тестирования

There are two fundamental approaches to testing software: test-to-pass and test-to-fail. When you test-to-pass, you really assure only that the software minimally works. You don’t push its capabilities. You don’t see what you can do to break it. You treat it with kid gloves, applying the simplest and most straightforward test cases.

Паттон пишет, что тесты, которые должны пройти успешно (Test-to-pass), должны проверяться в первую очередь. Если они не прошли, то остальные можно не проверять.

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

Позитивные и негативные бывают тест кейсы. Метками «test-to-pass» и «test-to-fail» можно сгруппировать тестовые наборы для smoke, acceptance и regression тестов, которые могут содержать в себе как негативные, так и позитивные сценарии.

Tets-to-pass — это тесты в нормальном, наиболее часто используемом режим эксплуатации.

Test-to-fail — это тесты на неизведанной территории, которая может оказаться минными полем. Эти тесты вы не будете проводить после каждой сборки. Они нужны только для поиска особых состояний системы, в которых возможно возникновение ранее не обнаруженного дефекта или вообще сбой всей системы. Такие тесты могут быть ad hock, а негативные тесты — это могут быть случаи, которые проверяются при принятии баг фикса, и они должны пройти успешно.

Цель негативного теста — убедиться, что система правильно реагирует на неправильное действие. Цель test-to-fail наверняка сломать систему.

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

Первая порция тестов должна позволить обнаружить некоторое количество show-stopper дефектов. Когда первая порция Test-To-Pass пройдет успешно, переходим ко второй — Test-To-Fail, которая должна выявить как можно большее количество дефектов всех степеней критичности. А после проведения последней порции тестов дефекты не должны возникнуть вообще — они должны быть снова Test-To-Pass.

9. Сценарии

Иначе вы упустите дефекты.

10. Динамичность

Если при тестировании происходят манипуляции с приложением — оно динамическое. Если состояние системы не меняется — это статическое тестирование.
Статические тестирование часто упускается. Как можно тестировать, ничего не меняя?
Ответ — на схеме. Code review и тестирование документации помогают выявить солидную долю ошибок, не тратя время на приведение системы в движение.

На этом просмотр в ширину закончен. Просмотр в глубину оставим на следующий раз.

Составление матрицы тестов

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

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

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

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

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

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

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

Заключение

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

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

Источник