какие виды типы классы методы тестирования вы знаете и чем они различаются

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

Блочное (модульное, 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 об этом говорится подробнее.

Источник

Виды тестирования ПО (в картинках)

В книге Growing Object-Oriented Software, Guided by Tests, мы описали различные виды тестов, которые мы используем при проектировании ПО и показали, как хорошо они сочетаются с архитектурным стилем Порты и Адаптеры (Ports and Adapters by Alistair Cockburn).

В Портах и Адапттерах центральное место приложения занимает доменная модель, не имеющая точек соприкосновения ни с какими частями инфраструктуры, будь то БД, очереди, UI, и т.д. Но модель содержит интерфейсы, которые определяют ее взаимоотношения с внешним миром в терминах домена. Cockburn называет эти интерфейсы портами. Эти интерфейсы реализуются в соответствующих объектах, осуществляющих взаимодействие с внешним миром — Cockburn назвал их адаптерами. В распределенных системах разные процессы, каждый со своей доменной моделью, взаимодействюут между собой с помощью портов и адаптеров.

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

Ниже я попытаюсь объяснить, как различные уровни тестирования вписываются в Порты и Адаптеры.

Модульные тесты

Модульные тесты тестируют отдельные объекты, или их небольшие группы внутри одного процесса. Например, при Test-Driven Development, мы пишем модульные тесты, результаты выполнения которых влияют на тестируемый код — мы редактируем его, когда он не проходит какие-то тест кейсы.

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

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

Приемочные тесты

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

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

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

Системные тесты

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

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

Источник

Тестирование или управление качеством? Часть 2. Типы тестирования

В предыдущей статье «Часть 1. Что такое тестирование?» я поделилась с читателями мыслями о том, в чем заключается суть тестирования. Во второй части моих рассуждений о тестировании и управлении качеством я подробно рассмотрю различные типы тестирования и проанализирую модели, которые помогают разработчикам визуализировать процесс тестирования, чтобы вовлечь в него всех участников команды.

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

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

Существуют разные способы разделения процессов тестирования на категории. Вот один из вариантов:

Постановка вопросов

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

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

Задание направления разработки

Разработка на основе приемочных испытаний (ATDD) или на основе поведения (BDD) — это две распространенные методологии ведения разработки на основе примеров.

Команда рассматривает какую-то пользовательскую историю (user story) — возможно, обсуждая в формате «трех амиго» на понятных примерах, чтобы донести ее суть до каждого участника дискуссии. Отталкиваясь от этих примеров, они составляют приемочные испытания и проводят дополнительные обсуждения. По мере детализации они продолжают составлять тесты для бизнес-правил в исполняемом формате под API или уровень служб.

Взяв получившиеся тесты, программист может вести разработку на основе тестирования (TDD) — писать модульные тесты, затем сам код и постепенно дорабатывать его, чтобы все тесты завершались успешно. Если организовать работу команды таким образом, тесты на уровне модулей и API будут автоматизироваться в процессе разработки кода, и в нужных местах будут предусмотрены проверки, удостоверяющие, что результаты работы системы соответствуют ожиданиям команды. Тестировщик сможет направлять в нужное русло процесс автоматизации, применяя свои навыки проектирования тестов, помогая создавать оптимальные тесты — не только для благоприятных сценариев, но и для нештатного поведения и других случаев «что, если?».

Углубленное тестирование

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

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

Проверка

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

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

Квадранты гибкого тестирования

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

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

Вот пример из моего личного опыта:

Во время встречи с разработчиком я сказала ему, что все автоматизированные тесты API внесены в систему и готовы к реализации. Он взял их из системы контроля версий, проглядел и сказал, что продукт не сможет пройти ни одного теста. Я посмотрела на него с удивлением, поскольку мы вместе присутствовали на всех встречах и вместе согласовывали метод тестирования. Почему же тесты оказались непригодными? Он ведь даже еще не написал код. Выяснилось, что у нас было разное представление о том, как должна работать функция поиска. Именно после этого случая я стала оперировать более конкретными примерами во время обсуждений. Но я хотела подчеркнуть другое: если бы я не написала эти тесты и мы бы их вместе не изучили, разработчик написал бы код с серьезной ошибкой. А поскольку нам удалось выяснить суть проблемы на раннем этапе, устранить ее было довольно легко. Код еще не был написан, и я помогла предотвратить появление бага.

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

Тестирование в различном контексте

Подобно тому, как существует множество видов тестирования, есть и множество контекстов тестирования. И один человек попросту не может учесть все комбинации этих двух факторов.

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

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

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

Итоги

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

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

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

В преддверии старта курса QA Lead приглашаем всех желающих на бесплатный двухдневный интенсив в рамках которого изучим теоретические основы методов тестирования требований. Рассмотрим использование User Story и критериев приемки для тестирования бизнес-требований. Изучим Example Mapping как способ протестировать технические требования. А также попрактикуемся в построении Example Mapping.

Источник

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

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

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

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

1. Цель

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Уровень

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

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

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

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

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

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

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

8. Важность

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

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

Источник