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

Виды тестирования по запуску кода

Можем ли мы протестировать только работающий продукт или можем начать его тестирование еще до запуска?

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

По критерию запуска программы (исполняется ли программный код) выделяют 2 вида тестирования: статическое и динамическое.

Статическое тестирование

Статическое тестирование (static testing) — тестирование без запуска кода на исполнение.

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

Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации.

Можно поделить статическое тестирование на 2 типа:
1. Обзоры (Review)
2. Статический анализ (Static Analysis)

Обзоры

Обзоры (Review) – проверка обычно используется для поиска и устранения ошибок или неясностей в документах. Это могут быть требования, дизайн, тестовые случаи и так далее.

В свою очередь обзоры делятся на:

Статический анализ

Статический анализ (Static Analysis) – код, написанный разработчиками, анализируется на наличие структурных дефектов, которые могут привести к ошибкам.

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

Статический анализ состоит из 3-х частей:

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

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

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

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

В рамках этого подхода тестированию могут подвергаться:

Плюсы и минусы

Преимущества статического тестирования

Недостатки статического тестирования

Динамическое тестирование

Динамическое тестирование (dynamic testing) — тестирование с запуском кода на исполнение. Запускаться на исполнение может как код всего приложения целиком (системное тестирование), так и код нескольких взаимосвязанных частей (интеграционное тестирование), отдельных частей (модульное или компонентное тестирование) и даже отдельные участки кода.

Основная идея этого вида тестирования состоит в том, что проверяется реальное поведение (части) приложения.

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

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

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

Плюсы и минусы

Преимущества динамического тестирования

Недостатки динамического тестирования

Сравнение

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

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

Было полезно? Не забудь поставить 💚 этой статье.

Есть вопросы по тестированию? Задавай тут.
Если что, то я всегда на связи✌

Источник

говориМ о тестировании
простым языком

Виды тестирования по запуску кода

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

По критерию запуска программы (исполняется ли программный код) выделяют 2 вида тестирования: статическое и динамическое.

Статическое тестирование

Статическое тестирование (static testing) — тестирование без запуска кода на исполнение.

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

Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации.

Можно поделить статическое тестирование на 2 типа:
1. Обзоры (Review)
2. Статический анализ (Static Analysis)

Обзоры

Обзоры (Review) – проверка обычно используется для поиска и устранения ошибок или неясностей в документах. Это могут быть требования, дизайн, тестовые случаи и так далее.

В свою очередь обзоры делятся на:

Статический анализ

Статический анализ (Static Analysis) – код, написанный разработчиками, анализируется на наличие структурных дефектов, которые могут привести к ошибкам.

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

Статический анализ состоит из 3-х частей:

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

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

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

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

В рамках этого подхода тестированию могут подвергаться:

Плюсы и минусы

Преимущества статического тестирования

Недостатки статического тестирования

Динамическое тестирование

Динамическое тестирование (dynamic testing) — тестирование с запуском кода на исполнение. Запускаться на исполнение может как код всего приложения целиком (системное тестирование), так и код нескольких взаимосвязанных частей (интеграционное тестирование), отдельных частей (модульное или компонентное тестирование) и даже отдельные участки кода.

Основная идея этого вида тестирования состоит в том, что проверяется реальное поведение (части) приложения.

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

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

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

Плюсы и минусы

Преимущества динамического тестирования

Недостатки динамического тестирования

Сравнение

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

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

Источник

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

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

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

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

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

Источник

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

Блочное (модульное, 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-карт в подготовке темы занятия. При большом количестве узлов, карта плохо читается на формате альбомного листа. И тогда лучше использовать доску и мел — дублировать части схемы на доске.

О доске и меле

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

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

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

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

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

Источник