Укажите те признаки по которым классифицируют виды тестирования в программировании

Различные виды тестирования ПО

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

Сравнение тестирования в ручном и в автоматическом режиме

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

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

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

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

Все виды работ проводимых тестировщиком можно условно разделить на два:

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

• защищенность
• соответствие стандартам
• способность к взаимодействию
• функциональная пригодность
• точность

1. Нефункциональное тестирование ПО — в первую очередь проверка на соответствие не функциональным требованиям:

• Удобство (В основном производиться оценка удобства для пользователей)
• Маштабируемость (проверяется как вертикальная так и горизонтальная маштабируемость тестируемого приложения)
• Производительность (Способность работы приложения при различных нагрузках)
• Безопасность (Защита пользовательских данных, защита данных приложения, стойкость на взлом)
• Портируемость (Совместимость и переносимость приложения для и под различные окружения, платформы и т.д.)
• Надежность (Поведение системы при различных непредвиденных ситуациях, способность обработки нестандартных действий пользователя)

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

Чтобы было немного проще понять все градации тестирования приведем небольшую табличку

По объектам которые подвергаются тестированию:

• Функциональное тестирование
• Тестирование локализации и интернационализации
• Тестирование взаимодействия
• Конфигурационное тестирование
• Тестирование производительности
  • Тестирование стабильности
  • Стресс-тестирование
  • Нагрузочное тестирование

  По степени знания тестируемой системы:

  • Тестирование чёрного ящика
  • Тестирование белого ящика
  • Тестирование серого ящика

  По степени автоматизации процесса тестирования:

  • Автоматизированное тестирование
  • Ручное тестирование

  По степени изолированности части компонентов тестируемого ПО:

  • Модульное тестирование
  • Интеграционное тестирование
  • Системное тестирование
  • Тестирование критического пути
  • Расширенное тестирование

  По времени когда проводится тестирование:

  • Альфа-тестирование
  • Дымовое тестирование (smoke testing)
    • Тестирование новой функции (new feature testing)
    • Регрессионное тестирование
    • Приёмочное тестирование

    По признакам позитивности сценариев

    • Негативное тестирование
    • Позитивное тестирование

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

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

    По степени подготовки к тестированию теcтировщиком:

    • Интуитивное тестирование ( ad hoc testing)
    • Тестирование по документации (формальное тестирование)
    • Исследовательское тестирование (exploratory testing)

    Все о тестировании и качестве ПО

    • Мобильное тестирование
    • Характеристики качества программного обеспечения
    • Виды нагрузочного тестирования
    • Расширенное тестирование
    • Тестирование файла загрузки

    I believe in QA, все о тестировании

    Январь 2024

    Пн	Вт	Ср	Чт	Пт	Сб	Вс
    1	2	3	4	5	6	7
    8	9	10	11	12	13	14
    15	16	17	18	19	20	21
    22	23	24	25	26	27	28
    29	30	31

    Больше о тестировании и качестве ПО

    • Тестирование стабильности
    • Характеристики качества программного обеспечения
    • Системное тестирование
    • Мобильное тестирование
    • Расширенное тестирование
    • Альфа тестирование

    Виды Тестирования ПО. Полный Список

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

    Ad-hoc тестирование

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

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

    Приемочное тестирование

    

    Приемочное тестирование – это формальный вид тестирования программного обеспечения, который выполняется конечным потребителем, когда разработчики предоставили запрашиваемые услуги. Целью этого тестирования является проверка соответствия ПО бизнес-требованиям потребителей и требованиям, представленным ранее. Приемочные тестирования обычно документируются в начале работы (в agile) и помогают тестировщикам и разработчикам улучшить свои знания и умения в данной области.

    Что такое приемочное тестирование в Agile?

    Тестирование доступности

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

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

    Agile Testing – это вид тестирования программного обеспечения, который учитывает гибкий подход и методы разработки программного обеспечения. В среде разработки Agile тестирование является неотъемлемой частью разработки ПО и выполняется параллельно с написанием кода. Agile тестирование позволяет проводить постепенное написание кода и его тестирование.

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

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

    Автоматизированное тестирование

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

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

    

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

    Бета-тестирование

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

    Тестирование Черного Ящика

    

    Тестирование черного ящика – это вид тестирования программного обеспечения, когда от тестировщиков не требуется знать кодировку или внутреннюю структуру программного обеспечения. Метод тестирования «черного ящика» основан на тестировании ПО с различными входами и сравнении результатов с ожидаемыми.

    Тестирование обратной совместимости

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

    Тестирование граничных значений

    Тестирование граничных значений – это вид тестирования, основанный на концепции «агрегации ошибок на границах». Тестирование проводится методом тщательного тестирования дефектов в граничных значениях. Если в поле принимается значение от 1 до 100, то тестирование выполняется для значений 0, 1, 2, 99, 100 и 101.

    Метод тестирования “большой взрыв”

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

    Интеграционное тестирование Снизу вверх (восходящее тестирование)

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

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

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

    Тестирование совместимости браузера

    

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

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

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

    Тестирование компонентов

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

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

    Тестирование покрытия условий – это методика тестирования, используемая во время модульного тестирования, где разработчик тестирует все условия, такие как if, if-else, case и т. д. в тестируемом модуле кода.

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

    

    Тестирование может быть выполнено методом статического тестирования и динамического тестирования. Динамическое тестирование – это подход к тестированию, когда тестирование может быть выполнено только при извлечении кода.

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

    Это методика тестирования, которая используется в модульном тестировании. Цель тестирования покрытия решения состоит в том, чтобы осуществить и проверить каждый блок принятия решения в коде, например. If, if-else, case.

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

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

    Исследовательское тестирование

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

    Эквивалентное разбиение

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

    Функциональное тестирование

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

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

    Fuzz testing или fuzzing – это методика тестирования программного обеспечения, которая включает тестирование с непредвиденными или случайными исходными данными. Программное обеспечение тестируется на предмет ошибок или сообщений об ошибках, которые появляются из-за ошибок при вводе данных.

    Тестирование графического интерфейса пользователя

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

    Тестирование методом “стеклянного ящика”

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

    Gorilla тестирование (хаотическое тестирование)

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

    Тестирование благоприятного пути

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

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

    

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

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

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

    Тестирование интернационализации

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

    Тестирование на основе ключевых слов

    Тестирование на основе ключевого слова – это скорее автоматизированный подход к тестированию программного обеспечения, чем сам вид тестирования. Тестирование на основе ключевых слов известно как тестирование на основе действий или тестирование на основе таблиц.

    Нагрузочное тестирование

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

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

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

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

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

    Нефункциональное тестирование

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

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

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

    Тестирование производительности

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

    Тестирование безопасности

    Является одним из видов тестирования безопасности. Тестирование проникновения проводится для проверки того, как защищенное программное обеспечение и его среда (оборудование, операционная система и сеть) подвергаются атакам со стороны внешнего или внутреннего злоумышленника. Нарушитель может быть человеком / хакером или вредоносными программами. Pentest использует методы насильственного вторжения (путем грубой силы атаки) или использования уязвимости для получения доступа к ПО или данным, или оборудованию с целью разоблачения способов кражи, манипулирования или повреждения данных, файлов ПО или конфигурации. Тестирование безопасности – это способ этичного взлома: опытный тестировщик безопасности будет использовать те же методы и инструменты, что и хакер, но намерение тестировщика – идентифицировать уязвимость и исправить ее до того, как настоящий хакер или вредоносная программа использует уязвимость в своих целях.

    Регрессионное тестирование

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

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

    

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

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

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

    Smoke тестирование (тестирование “на дым”)

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

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

    

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

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

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

    Тестирование масштабируемости

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

    Тестирование стабильности

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

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

    

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

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

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

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

    Включает в себя несколько видов тестирования ПО, которые позволят проверить программное обеспечение в целом (программное обеспечение, аппаратное обеспечение и сеть) в соответствии с требованиями, для которых он был создан. Для завершения тестирования системы выполняются различные виды тестов (GUI-тестирование, функциональное тестирование, регрессионное тестирование, тестирование дыма, нагрузочное тестирование, стресс-тестирование, тестирование безопасности, стресс-тестирование, ad-hoc тестирование и т. д.).

    Нагрузочное тестирование

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

    Тестирование интеграции системы

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

    Модульное тестирование

    

    Это вид тестирования, который выполняется разработчиками ПО. Модульное тестирование следует методу тестирования белых полей, где разработчик будет тестировать модули исходного кода, такие как операторы, ветви, функции, методы, интерфейс в ООП (объектно-ориентированное программирование). Модульное тестирование обычно включает в себя разработку драйверов. Модульные тесты – идеальные варианты для автоматизации. Автоматизированные тесты могут выполняться как единичные регрессионные тесты для новых версий или новых версий ПО. Существует множество полезных фреймов, таких как Junit, Nunit и т. д., которые могут сделать модульное тестирование более эффективным.

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

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

    Приемочное тестирование пользователя

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

    Тестирование объема

    Является нефункциональным видом тестирования, выполняемым группой инженеров по производительности. Тестирование объема – один из видов тестирования производительности. Тестирование объема выполняется для того, чтобы проверить ПО на надежность при работе с различными размерами данных, которые принимаются и обрабатываются программным обеспечением. Например, если вы собираетесь тестировать слово Microsoft, то проверка объема будет заключаться в том, чтобы увидеть, может ли MS Word открыть, сохранить и работать с файлами разных размеров (от 10 до 100 МБ).

    Тестирование уязвимости

    

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

    Тестирование методом “белого ящика”

    

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

    Хочу отметить, что помогут познакомиться с данными методами тестирования наши курсы Тестирования ПО в Минске .

    Запишитесь прямо сейчас или закажите звонок с бесплатной консультацией!

    Типы и виды тестирования. Уровни тестирования. методы тестирования

    

    Задача QC (Quality Control, контроль качества) — контроль и фиксация качества производимых артефактов, промежуточных и конечных результатов работы. Его цель заключается в поисках дефектов и обеспечении их исправления. Таким образом тестирование является неотъемлемой частью контроля качества.
    Здесь очень подходит термин Verification с вопросом «Are we building the product right?» — правильно ли мы делаем продукт, проверяется соответствие планам, спецификациям, дизайну, правилам составления кода, проход тест-кейсов. Проверяем CORRECTNESS.

    QA (Quality Assurance, обеспечение качества) = часть менеджмента качества, ориентированная на создание и настройку процессов, целью которых является обеспечение гарантии того, что требования к качеству будут выполнены (продукт будет соответствовать ожиданиям качества заказчика).
    Состоит из процессов/действий, направленных на обеспечение качества разработки продукта на каждом из его этапов. Эти действия, как правило, предшествуют развитию продукта и продолжаются, пока процесс пребывает в состоянии развития. На самом QA лежит ответственность за разработку и внедрение процессов и стандартов для улучшения жизненного цикла разработки ПО (SDLC), и обеспечение уверенности в том, что эти процессы выполняются. Фокусом QA является предотвращение дефектов на всех этапах его реализации и постоянное его совершенствование.
    Занимается вопросами «а какие виды и методы тестирования мы будем использовать?», «как будем измерять качество?» и т.п.
    Здесь очень подходит термин Validation с вопросом «Are we building the right product?» — правильный ли продукт мы делаем, удовлетворяет ли продукт нуждам пользователя. Проверяем COMPLETENESS.

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

    • значимы для Заказчиков/Пользователей
    • оказывают влияние на мнение пользователя о работе с системой
    • снижают потенциальные затратные риски

    Определения тестирования

    В разное время и в различных источниках тестированию давались различные определения, в том числе:

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

    

    

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

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

    По объекту тестирования

    • Функциональное тестирование
    • Тестирование производительности
      • Нагрузочное тестирование
      • Стресс-тестирование
      • Тестирование стабильности

      По знанию внутреннего строения системы

      • Тестирование черного ящика
      • Тестирование белого ящика
      • Тестирование серого ящика

      По степени автоматизации

      • Ручное тестирование
      • Автоматизированное тестирование
      • Полуавтоматизированное тестирование

      По степени изолированности

      • Тестирование компонентов
      • Интеграционное тестирование
      • Системное тестирование

      По времени проведения тестирования

      • Альфа-тестирование
        • Дымовое тестирование (англ. smoke testing)
        • Тестирование новой функции (new feature testing)
        • Подтверждающее тестирование
        • Регрессионное тестирование
        • Приемочное тестирование

        По признаку позитивности сценариев

        • Позитивное тестирование
        • Негативное тестирование

        По степени подготовленности к тестированию

        • Тестирование по документации (формальное тестирование)
        • Интуитивное тестирование (англ. ad hoc testing)

        

        ЦИКЛ ТЕСТИРОВАНИЯ

        Цикл тестирования (Testing Cycle) напоминает типичный производственный цикл , обычно проходя в несколько этапов:

        1. Тест-анализ — анализ требований (Requirement analysis) и (опционально) Тестирование требований.
           Результат: Матрица трассировки Требований и Тест-кейсов (Requirement Traceability Matrix, RTM), зарегистрированные дефекты документации и более качественная документация для разработчиков.
        2. Планирование (Test Management, Test Planning).
           Результат: тест-план (Test Plan) / стратегия тестирования, оценка трудозатрат (Effort Estimation)
        3. Проектирование тестов (Test Design, Test Development).
           Результат: набор тест-кейсов (test cases), которые необходимо пройти, тестовые данные (test data)
        4. Выполнение (Test Execution). Используются методы тестирования (methods of testing).
           Результат: отчет о тестировании (test reporting), багрепорты (bug report).
        5. Анализ результатов тестирования (Test Result Analysis). Используются метрики (QA metrics).
           Результат: выводы для исправления ошибок в планировании и контроле над процессом тестирования/разработки.

        Виды Тестирования Программного Обеспечения

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

        1. Функциональные
        2. Нефункциональные
        3. Связанные с изменениями

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

        Функциональные виды тестирования

        Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) и приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов:

        • Функциональное тестирование (Functional testing)
        • Тестирование безопасности (Security and Access Control Testing)
        • Тестирование взаимодействия (Interoperability Testing)

        Нефункциональные виды тестирования

        Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, «Как» система работает. Далее перечислены основные виды нефункциональных тестов:

        • Все виды тестирования производительности:
          • нагрузочное тестирование (Performance and Load Testing)
          • стрессовое тестирование (Stress Testing)
          • тестирование стабильности или надежности (Stability / Reliability Testing)
          • объемное тестирование (Volume Testing)

          Приемочное тестирование

          • Пользовательское тестирование (UAT)
          • Альфа-тестирование
          • Бета-тестирование

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

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

          Пользовательское тестирование (UAT)

          Пользовательское UAT тестирование проводят конечные пользователи системы, с целью определить пригодность системы для внедрения. Тестирование проходит на последнем этапе испытаний.

          Ключевые преимущества UAT тестирования

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

          Основные задачи

          Задача проведения пользовательского тестирования – оказать помощь конечным пользователям системы в подготовке и проведении испытаний.

          Для этого проводятся следующие работы:

          • Разработка плана и методики приемочного тестирования;
          • Разработка детального описания сценариев тестирования;
          • Организация и координация работ в ходе пользовательского тестирования.

          Альфа-тестирование

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

          Ключевые преимущества

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

          Основные задачи

          В рамках проведения альфа-тестирования наша компания решает следующие задачи:

          • подготовка расписания тестирования;
          • организация участников тестирования;
          • отбор и уточнение поступающих замечаний;
          • регистрация дефектов в багтрекинговой системе.

          Бета-тестирование

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

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

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

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

          • Дымовое тестирование (Smoke Testing)
          • Регрессионное тестирование (Regression Testing)
          • Тестирование сборки (Build Verification Test)
          • Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)
          • BlackBox, GreyBox и WhiteBox;
          • Принципы тестирования
          • уровни тестирования
          • Функциональное тестирование:
            • Степень глубины тестирования: Smoke, cover, full
            • Regression — что это и как составлять?
            • GUI и Usability — тестирование пользовательского интерфейса
            • Load, performance, stress-тестирование
            • Security тестирование
            • Цели и необходимость.
            • Обзор инструментария.

            Уровни Тестирования Программного Обеспечения

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

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

            1. Компонентное или Модульное тестирование (Component Testing or Unit Testing)
            2. Интеграционное тестирование (Integration Testing)
            3. Системное тестирование (System Testing)
            4. Приемочное тестирование (Acceptance Testing)

            

            

            Unit testing — Модульное тестирование

            Модульное тестирование (Unit testing) = тестирование одного модуля кода (обычно это одна функция или один класс в случае ООП-кода) в изолированном окружении. Об этом говорит сайт https://intellect.icu . Это значит, что:

            • если код использует какие-то сторонние классы, то вместо них подсовываются классы-заглушки: моки и стабы. Stub’ы предназначены для получения нужного состояния тестируемого объекта, а Mock’и применяются для проверки ожидаемого поведения тестируемого объекта.
            • код не должен работать с сетью (и внешними серверами), файлами, базой данных (иначе мы тестируем не саму функцию или класс, а еще и диск, базу, ит.д.)

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

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

            Интеграционное тестирование (Integration testing) = проверка связи между модулями (компонентами) кода, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами). Если проводить аналогии, например с тестированием авиадвигателя, то юнит-тесты — это тестирование отдельных деталей, клапанов, заслонок, а интеграционное тестирование — это запуск собранного двигателя на стенде.
            Выполняется разработчиками, зачастую методом автоматического тестирования.

            System testing — Системное тестирование

            Системное тестирование (System testing) = процесс тестирования системы в целом с целью проверки того, что она соответствует установленным Спецификациям к Требованиям к ПО (SRS).
            Удостовериться, что Система умеет принять какие-то данные от поставщиков, обработать их, передать данные потребителям, все это в правильной последовательности и формате. Дальнейшая судьба данных нас не волнует. Главное — наша система работает правильно в правильном окружении.
            При этом выявляются дефекты как: неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные варианты использования, отсутствующая или неверная функциональность, неудобство использования и т.д.
            Для минимизации рисков, связанных с особенностями поведения в системы в той или иной среде, во время тестирования рекомендуется использовать окружение максимально приближенное к тому, на которое будет установлен продукт после выдачи.
            Выполняется тестировщиками ручным и автоматическим методами.

            API testing — тестирование API

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

            Может включать в себя тестирование:

            

            RPC-взаимодействия с сервером, например, в виде java-call клиентской библиотеки, см. gRPC

            Тестирование CDC (consumer driven contract) для всех вышеуказанных разновидностей API в виде:

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

            Тестов для API сервисов-поставщиков. Они также могут генерироваться из контракта.

            Выполняется тестировщиками ручным и автоматическим методами.

            Инструменты для тестирования web-API

            Postman = GUI-инструмент для тестирования REST/SOAP. Поддерживает создание скриптов для автотестов (Javascript).

            SoapUI = GUI-инструмент для тестирования REST/SOAP. Поддерживает создание test-suit’ов со скриптами для автоматизации тестирования (разные ЯП).

            cURL = CLI-инструмент для для взаимодействия с серверами по протоколам с синтаксисом URL.

            behat tests Behat — это тестовая среда для поведенческой разработки, написанная на языке программирования PHP.

            Acceptance testing — Приемочное тестирование

            Приемочное тестирование (Acceptance testing) или Приемо-сдаточные испытания (ПСИ) — формальный процесс тестирования, который проверяет соответствие системы Бизнес/Пользовательским требованиям и проводится с целью: определения удовлетворяет ли система приемочным критериям, вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет. Выполняется на основании набора типичных тестовых случаев и сценариев, разработанных на основании требований к данному приложению.
            Выполняется тестировщиками ручным и автоматическим методами.

            End-to-End testing — Сквозное тестирование

            Сквозное тестирование (End-To-End, E2E или Chain testing) = проверять не только наше окружение, но и все взаимосвязанные системы, через которые проходят данные принимаемые или отправляемые нашей системой. А это, в свою очередь, означает, что мы должны будем совместить несколько таких «пирамид тестирования» между собой. E2E тестирование это не просто приемка (пользовательское тестирование), которое будет выполнять заказчик, это выстраивание мостика, с учетом всех возможных ситуаций, по которому пойдет заказчик и поведет за собой в ногу пользователей.
            Выполняется тестировщиками ручным и автоматическим методами.
            Для сквозных сценариев используются с большой долей вероятности уже ранее разработанные тесты для каждой из систем, входящей в цепочку (сценарий) Бизнес-процесса. Можно все полные тестовые наборы компании представить в виде разреженной матрицы, где по столбцам распределены тесты для каждой системы (для простоты — системные), а по строкам — бизнес-процессы. То есть для тех или иных бизнес-процессов надо выбрать\создать тесты, покрывающие бизнес-процесс, установить взаимосвязи. Если покрытия нет — это повод восполнить пробелы в тестовой модели, либо удостовериться, что качество обеспечивается другими уровнями тестирования (интеграционное тестирование, модульное тестирование, ревью кода и прогон его через анализаторы).

            

            рис Сквозное тестирование (End-To-End, E2E или Chain testing)

            Мартин Фаулер предупреждает о том, что написание и поддержка E2E-тестов достаточно дороги, а значит:

            • их не должно быть много
            • время прохода E2E-тестов должно исчисляться минутами, а не часами
            • E2E-тесты должны кореллировать с CJM
            • если какой-нибудь внешний сервис очень часто является причиной задержек в выполнении E2E-сценария, рекомендуется его исключить, организовав заглушку вместо него
            • нужно стараться делать E2E-тесты независимыми от предподготовленных данных, отсутствие или плохое качество которых часто является причиной ошибок. Если есть сервисы (воззможно, среди тестируемвых), которые предоставляют API по созданию объектов сущностей, то следует использовать его. Если такого нет, то нужные данные следует импортировать на уровне БД.

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

            • функциональное тестирование (Functional testing)
              (позитивное / негативное)
            • тестирование безопасности (Security and Access Control Testing)
            • нагрузочное тестирование (Performance and Load Testing)
            • стресс-тестирование (Stress Testing)
            • тестирование стабильности или надежности (Stability / Reliability Testing)
            • тестирование выносливости (Endurance testing)
            • объемное тестирование (Volume Testing)
            • тестирование установки (Installation testing)
            • тестирование удобства пользования (Usability Testing)
            • тестирование на отказ и восстановление (Failover and Recovery Testing)
            • тестирование конфигурации (Configuration Testing)
            • тестирование совместимости (Compatibility Testing)
            • Дымовое тестирование (Smoke testing)
            • Ре-тест (Re-test)
            • Санитарное тестирование (Sanity Check)
            • Регрессионное тестирование (Regression Testing)

            Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) и приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы.

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

            

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

            Функциональное тестирование (functional testing)

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

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

            Функциональное тестирование бывает:

            • «Позитивное» (positive testing) — это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению системы.
              Основной целью «позитивного» тестирования является проверка того, что при помощи системы можно делать то, для чего она создавалась.
            • «Негативное» (negative testing) — это тестирование на данных или сценариях, которые соответствуют нештатному поведению тестируемой системы — различные сообщения об ошибках, исключительные ситуации, «запредельные» состояния и т.п.
              Основной целью «негативного» тестирования является проверка устойчивости системы к воздействиям различного рода, валидация неверного набора данных, проверка обработки исключительных ситуаций (как в реализации самих программных алгоритмов, так и в логике бизнес-правил).

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

            Тестирование безопасности (security and access control testing)

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

            Сканирование на предмет наличия уязвимостей (Vulnerability Scanning): Выполняется с помощью специальных программ-сканеров уязвимостей.

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

            Тест на проникновение (Penetration testing): симулирует нападение злоумышленника. Это тестирование включает анализ конкретной системы с целью проверить потенциальную уязвимость к внешним попыткам взлома.

            Оценка риска (Risk Assessment): включает в себя анализ рисков безопасности, наблюдаемых в организации. Риски классифицируются как слабые (low), средние (medium) и высокие (high). Этот вид тестирования рекомендует методы контроля и снижения рисков.

            Тестирование производительности (performance testing) или нагрузочное тестирование (load testing)

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

            Стрессовое тестирование (stress testing) = тестирование приложения под экстремальными нагрузками, определение способности обрабатывать высокий уровень траффика или обработки данных. Целью является определить переломную точку приложения.

            Задачей тестирования стабильности (stability) / надежности (reliability) — является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Время выполнения операций может играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты влияющие именно на стабильность работы.

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

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

            Тестирование удобства использования (usability testing)

            Тестирование удобства пользования — это метод тестирования, направленный на установление степени удобства использования, «обучаемости», понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. [ISO 9126]

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

            Тестирование на отказ и восстановление (failover and recovery testing)

            Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основные функции систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.
            Тестирование на отказ и восстановление очень важно для систем, работающих по принципу «24×7», например интернет-магазины, ERP-системы.

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

            Тестирование графического пользовательского интерфейса (GUI testing)

            1. проверить для всех элементов GUI размеры, позицию и принятие букв и цифр. Например, во всех полях ввода возможно производить ввод
            2. удостовериться, что графический интерфейс позволяет полностью реализовать весь функции приложения
            3. проверить верность отображения предупреждающий сообщений и сообщений об ошибках
            4. проверить читабельность шрифтов, используемых приложением, их выравнивание, цвет
            5. проверить отображение и расположение изображений
            6. проверить расположение элементов интерфейса при различных разрешениях экрана
            7. .

            Тестирование совместимости (compatibility testing)

            Аппаратное обеспечение: совместимость с различными аппаратными конфигурациями.
            Операционные системы: совместимость с различными операционными системами: Windows, *nix, Mac OS и т.д.
            Программное обеспечение: совместимость с различным программным обеспечением. Например, MS Word совместим с MS Outlook, MS Excel, VBA и т.д.
            Сеть: Оценка производительности системы в сети с изменяющимися параметрами, такими как пропускная способность, рабочая скорость, емкость. Проверка возможности применения приложения при различных вариантах значений этих параметров.
            Браузер: проверка совместимости веб-сайта с основными по-популярности: Firefox, Google Chrome, Internet Explorer, Opera, Safari.
            Устройства: совместимость с различными устройствами: принтерами, сканерами, средствами беспроводной связи, USvoid-устройствами.
            Мобильные устройства: совместимость с мобильными платформами, такими как Android, iOS и т.д.
            Версии программного обеспечения: совместимость с различными версиями программного обеспечения. Например, совместимость Microsoft Word с Windows 10, Windows 8, Windows 7, Windows XP, Windows XP SP2 и т.д.

            Дымовое тестирование (Smoke testing)

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

            Ре-тест (Re-test)

            Проверка того, что ранее обнаруженный при тестировании дефект был успешно исправлен.

            Санитарная проверка (Sanity check)

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

            Регрессионное тестирование (regression testing)

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

            Пример, разъясняющий разницу между тестами после изменений

            У нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:

            • Что у него есть 10 точек входа, для простоты, в нашем случае расположенных на одном IP
            • все они принимают GET-запрос на вход, возвращая какие-либо данные в формате json

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

            • Выполнив один простой GET-запрос к одной из этих точек входа. Если от сервиса пришел ответ в формате JSON, т.е. не вернул ошибку 4хх или 5хх или что-то невнятное, то он не «задымился». На этом можно сказать что «дымный» тест пройден. Для проверки того, что работает так же и UI достаточно просто один раз открыть страницу в браузере.
            • Санитарное тестирование в данном случае будет состоять из выполнения запроса ко всем 10 точкам входа в API.
            • Ре-тест в данном примере это точечная проверка что, к примеру, сломавшаяся точка входа в API следующем билде отрабатывает как задумывалось.
            • Регрессионные тесты будут состоять из Smoke + Sanity + UI выполняемые вместе в одной куче:
              • Выполнения запроса ко всем 10 точкам входа в API, сверкой полученного JSON с ожидаемым, а так же наличием требуемых данных в нем
              • проверить что добавление 11-ой точки входа не поломало, к примеру, восстановление пароля.

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

              

              рис пример регрессионного тестирования
              МЕТОДЫ тестирования: РУЧНОЕ И АВТО

              Ручное (manual testing) = выполнение тестировщиком тестовых сценариев и тестовых случаев вручную.

              • тестирование на уровне кода — модульное тестирование (unit testing). Это тестирование одного модуля кода (обычно это одна функция или один класс в случае ООП-кода) в изолированном окружении. Это значит, что если код использует какие-то сторонние классы, то вместо них подсовываются классы-заглушки (моки и стабы). Код не должен работать с сетью (и внешними серверами), файлами, базой данных, иначе мы тестируем не саму функцию или класс, а еще и диск, базу, и т.д.
              • тестирование API. API — это набор функций, которые можно вызывать, чтобы получить какие-то данные.
                Например, у Яндекс.Карт есть API геокодера. Отправив к нему запрос с географическим адресом, ты можешь получить координаты точки (и наоборот), а у Центробанка есть API, которое возвращает официальный курс валют в заданный день.
                Если у твоего приложения есть API, то можно тестировать его, посылая заранее подготовленные запросы и сравнивая пришедший ответ с ожидаемым.
              • тестирование пользовательского интерфейса — (GUI-тестирование). Имитация действий пользователя с помощью специальных тестовых фреймворков.

              Некоторые инструменты для автоматизации тестов

              • серия программных продуктов Selenium
              • PhantomJS
              • JUnit
              • PhpUnit

              БАГ-РЕПОРТ

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

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

              Значимость/серьезность (severity) ошибок
              0	остановка системы	server down	остановка работы системы
              1	Потеря данных	data loss	Потеря пользовательских, операторских, системных данных
              2	Потеря функциональности	functional loss	Блокирование основной функциональности. Могут включать в себя нефункциональные проблемы, например связанные с производительностью, которые вызывает неприемлимые задержки в использовании функций
              3	Дыра в безопасности	security loss
              4	Потеря функциональности с наличием обходного пути	functional loss but alternate path exists	Блокирование основной функциональности, но для пользователя существует разумный обходной путь
              5	Частичная потеря функциональности	partial functionality loss	Блокирование использования некоторой несущественной функциональности
              6	Косметическая ошибка	cosmetic error	Значительные недостатки в пользовательском интерфейсе или в способности системы реагировать на запросы пользователя

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

              Правила оформления названия (subject) баг-репорта

              Catalog Editor: Copy — not all existing catalogs shown in «select catalog» combobox
              или Catalog Library -> Duplicate Catalog — If ‘Use audience’ option is marked, ‘Shared with’ data must be copied to the new catalog>
              это годные названия. Ради того чтобы понять насколько проблема велика и срочна — не нужно открывать этот issue.
              «Organizer», «Catalog properties page» — за такие названия тасков всего 400 лет назад отправляли на костер. Потому что из него не понятно в чем суть, «ну page, ну и что, в чем проблема-то??».

              Шаблон «тела» баг-репорта

              DO: («ДЕЙСТВИЯ», «ШАГИ ВОСПРОИЗВЕДЕНИЯ»)
              Укажите последовательность действий, поведайте — что именно было сделано вами для достижения того состояния системы, при котором вы столкнулись с ошибкой

              RESULT: («РЕЗУЛЬТАТ:»)
              Опишите последствия ваших действий, расскажите, что случилось, когда достигнута «точка невозвращения» и как баг проявляет себя

              EXPECTED RESULT: («ОЖИДАЕМЫЙ РЕЗУЛЬТАТ:»)
              Описание ожидаемого поведения системы при прохождении пользователем шагов, указанных в «DO». Ожидаемый результат должен соответствовать требованиям заказчика описанным документации либо здравому смыслу. Разработчик должен знать что ему надо сделать.

              ADDITIONAL INFO: («ДОПИНФО:»)
              Чтобы сделать хороший баг-репорт отличным — используйте любую возможность дополнить его, как то:

              • Добавьте скриншоты (отметив на них, если нужно, важные места).
              • Добавьте лог сервера или текст сообщения об ошибке (если эти сведения доступны).
              • Добавьте свои соображения и предположения по поводу встреченного бага (коротко, если таковые имеются).

              Пример баг-репорта

              

              ШАБЛОНЫ ДОКУМЕНТОВ

              • smartCAT web-app test procedures (отправлял им в качестве домашнего задания)
              • sample ATP document cropped
              • Пример User Guide sample
              • Наипримитивнейший пример технического документа для сайта
              • шаблон тест-плана — http://www.protesting.ru/documentation/test_plan_template_rup.zip

              JIRA & ADAPTAVIST
              Не забыть настроить

              в проекте JIRA:

              1. добавить пользователей
              2. распределить их по группам
              3. настройка workflow для Тасков
              4. настройка состава полей для Тасков
              5. настройка канбан-досок
              6. создание components для того, чтобы отмечать к каким сервисам какой Таск-ТК трассируются
              7. настройка ролевки для adaptavist по вышесозданным группам + включить трассировку Таск—ТК

              в Test Adaptavist, связанном с этим проектом:

              1. кастомные поля для ТК (кто автоматизатор, какие компоненты/сервисы используются)
              2. components для заполнения кастомного поля в ТК
              3. настройка предоставлений списка ТК
              4. посоздавать папки, раскидать ТК

              Способы уведомления о готовности тасков к автоматизации

              1. ассайном таска, связанного ссылкой с ТК;
              2. сменой статуса такого таска
              3. упоминанием в комменте таска
              4. голосом на дэйли
              5. письмом
              6. сменой статуса ТК в адаптависте

              Вау!! �� Ты еще не читал? Это зря!

              • Разработка через тестирование TDD
              • Проблемно-ориентированное проектирование
              • Качество программного обеспечения
              • Система отслеживания ошибок
              • Аутсорсинг тестирования программного обеспечения
              • Внесение неисправностей
              • тестировщик
              • Управление качеством
              • Тестирование программного обеспечения
              • Метрика программного обеспечения
              • Антипаттерны тестирования ПО
              • технический долг , долг кодинга , алгоритм страуса ,
              • баг
              • тестирование мобильных приложений , архитектура мобильных приложений , mobile-тестирование ,
              • web-тестирование , web тестирование , вебтестирование ,
              • компонентное тестирование , модульное тестирование , component testing , unit testing ,

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

              Похожие публикации:

              1. Host name lookup failure как исправить
              2. Как разогнать процессор amd fx 8320
              3. Как скачать плей маркет на телевизор самсунг
              4. Чем открыть mpp кроме project