Лекция
Привет, сегодня поговорим про типы тестирования, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое типы тестирования, уровни тестирования , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..
Тестирование программного обеспечения — процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранных определенным образом.
Тестирование ПО = процесс исследования/испытания ПО, имеющий своей целью проверку соответствия между реальным и ожидаемым поведением ПО на конечном наборе тестов, выбранных определенным образом (ISO/IEC TR 19759:2005).
Цель тестирования или цель разработки и выполнения тестов:
рис 1 ТЕСТИРОВАНИЕ: QC И QA
Задача 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.
Чтобы предоставляемые услуги имели ценность, необходимо, чтобы тестирование было нацелено на проверку функций, которые:
В разное время и в различных источниках тестированию давались различные определения, в том числе:
Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие:
По объекту тестирования
По знанию внутреннего строения системы
По степени автоматизации
По степени изолированности
По времени проведения тестирования
По признаку позитивности сценариев
По степени подготовленности к тестированию
Цикл тестирования (Testing Cycle) напоминает типичный производственный цикл, обычно проходя в несколько этапов:
Все виды тестирования программного обеспечения, в зависимости от преследуемых целей, можно условно разделить на следующие группы:
Далее, мы постараемся более подробно рассказать о каждом отдельном виде тестирования, его назначении и использовании при тестировании программного обеспечения.
Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) и приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов:
Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает. Далее перечислены основные виды нефункциональных тестов:
Как правило, данный вид тестирования реализуется конечными пользователями системы, однако привлечение опытных тестировщиков сократит время на подготовку к тестированию и позволит повысить качество и надежность проводимых испытаний.
Пользовательское UAT тестирование проводят конечные пользователи системы, с целью определить пригодность системы для внедрения. Тестирование проходит на последнем этапе испытаний.
Задача проведения пользовательского тестирования – оказать помощь конечным пользователям системы в подготовке и проведении испытаний.
Для этого проводятся следующие работы:
Заказывая услугу у IBS AppLine вы сокращение трудозатраты на проведение тестирования, так как, во-первых, работу по организации мы берем на себя, во-вторых, поступающие дефекты фильтруются, уточняются и передаются разработчикам с подробным описанием, что значительно сокращает время, а также трудозатраты разработчиков на поиск причины дефекта и его исправление.
В рамках проведения альфа-тестирования наша компания решает следующие задачи:
Бета-тестирование проводится после альфа-тестирования и может использоваться как приемочное тестирование внешними пользователями. Бета-версия системы передается группе пользователей вне команды разработки, чтобы снизить количество дефектов. Иногда версия передается нескольким командам, чтобы получить обратную связь от как можно большего количества будущих пользователей.
Ключевые преимущества
Основные задачи
После проведения необходимых изменений, таких как исправление бага/дефекта, программное обеспечение должно быть пере тестировано для подтверждения того факта, что проблема была действительно решена. Ниже перечислены виды тестирования, которые необходимо проводить после установки программного обеспечения, для подтверждения работоспособности приложения или правильности осуществленного исправления дефекта:
Тестирование на разных уровнях производится на протяжении всего жизненного цикла разработки и сопровождения программного обеспечения. Уровень тестирования определяет то, над чем производятся тесты: над отдельным модулем, группой модулей или системой, в целом. Проведение тестирования на всех уровнях системы - это залог успешной реализации и сдачи проекта.
Чаша тестов
Модульное тестирование (Unit testing) = тестирование одного модуля кода (обычно это одна функция или один класс в случае ООП-кода) в изолированном окружении. Об этом говорит сайт https://intellect.icu . Это значит, что:
Обычно юнит-тест передает функции различные входные данные и проверяет, что она вернет ожидаемый результат. Например, если у нас есть функция проверки правильности номера телефона, мы даем ей заранее подготовленные номера и проверяем, что она определит их правильно. Если у нас есть функция решения квадратного уравнения, мы проверяем, что она возвращает правильные корни (для этого мы заранее делаем список уравнений с ответами).
Выполняется разработчиками, зачастую методом автоматического тестирования.
Интеграционное тестирование (Integration testing) = проверка связи между модулями (компонентами) кода, а также взаимодействия с различными частями системы (операционной системой, оборудованием либо связи между различными системами). Если проводить аналогии, например с тестированием авиадвигателя, то юнит-тесты - это тестирование отдельных деталей, клапанов, заслонок, а интеграционное тестирование - это запуск собранного двигателя на стенде.
Выполняется разработчиками, зачастую методом автоматического тестирования.
Системное тестирование (System testing) = процесс тестирования системы в целом с целью проверки того, что она соответствует установленным Спецификациям к Требованиям к ПО (SRS).
Удостовериться, что Система умеет принять какие-то данные от поставщиков, обработать их, передать данные потребителям, все это в правильной последовательности и формате. Дальнейшая судьба данных нас не волнует. Главное - наша система работает правильно в правильном окружении.
При этом выявляются дефекты как: неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные варианты использования, отсутствующая или неверная функциональность, неудобство использования и т.д.
Для минимизации рисков, связанных с особенностями поведения в системы в той или иной среде, во время тестирования рекомендуется использовать окружение максимально приближенное к тому, на которое будет установлен продукт после выдачи.
Выполняется тестировщиками ручным и автоматическим методами.
Тестирование API (API testing) = процесс тестирования API приложения с целью проверки того, что реализация внешних интерфейсов соответствует установленным требованиям.
Тестирование API можно отнести и к интеграционному тестированию и к системному, в зависимости от того что мы в рамках своей задачи считаем тестируемой системой (SUT, system under testing) -- отдельный сервис или некую платформу как совокупность сервисов.
Может включать в себя тестирование:
RPC-взаимодействия с сервером, например, в виде java-call клиентской библиотеки, см. gRPC
Тестирование CDC (consumer driven contract) для всех вышеуказанных разновидностей API в виде:
Тестов клиентов сервисов-поставщиков. Обычное используется заглушка, которая автоматически формируется из контракта. Это позволяет избежать развертывания окружения в виде Сервисов-Поставщиков.
Тестов для API сервисов-поставщиков. Они также могут генерироваться из контракта.
Выполняется тестировщиками ручным и автоматическим методами.
Postman = GUI-инструмент для тестирования REST/SOAP. Поддерживает создание скриптов для автотестов (Javascript).
SoapUI = GUI-инструмент для тестирования REST/SOAP. Поддерживает создание test-suit'ов со скриптами для автоматизации тестирования (разные ЯП).
cURL = CLI-инструмент для для взаимодействия с серверами по протоколам с синтаксисом URL.
behat tests Behat - это тестовая среда для поведенческой разработки, написанная на языке программирования PHP.
Приемочное тестирование (Acceptance testing) или Приемо-сдаточные испытания (ПСИ) - формальный процесс тестирования, который проверяет соответствие системы Бизнес/Пользовательским требованиям и проводится с целью: определения удовлетворяет ли система приемочным критериям, вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет. Выполняется на основании набора типичных тестовых случаев и сценариев, разработанных на основании требований к данному приложению.
Выполняется тестировщиками ручным и автоматическим методами.
Сквозное тестирование (End-To-End, E2E или Chain testing) = проверять не только наше окружение, но и все взаимосвязанные системы, через которые проходят данные принимаемые или отправляемые нашей системой. А это, в свою очередь, означает, что мы должны будем совместить несколько таких "пирамид тестирования" между собой. E2E тестирование это не просто приемка (пользовательское тестирование), которое будет выполнять заказчик, это выстраивание мостика, с учетом всех возможных ситуаций, по которому пойдет заказчик и поведет за собой в ногу пользователей.
Выполняется тестировщиками ручным и автоматическим методами.
Для сквозных сценариев используются с большой долей вероятности уже ранее разработанные тесты для каждой из систем, входящей в цепочку (сценарий) Бизнес-процесса. Можно все полные тестовые наборы компании представить в виде разреженной матрицы, где по столбцам распределены тесты для каждой системы (для простоты -- системные), а по строкам - бизнес-процессы. То есть для тех или иных бизнес-процессов надо выбрать\создать тесты, покрывающие бизнес-процесс, установить взаимосвязи. Если покрытия нет - это повод восполнить пробелы в тестовой модели, либо удостовериться, что качество обеспечивается другими уровнями тестирования (интеграционное тестирование, модульное тестирование, ревью кода и прогон его через анализаторы).
Мартин Фаулер предупреждает о том, что написание и поддержка E2E-тестов достаточно дороги, а значит:
| Основные группы тестирования | |
|---|---|
| функциональная группа | нефункциональная группа |
|
|
| тестирование связанное с изменениями (включают и функциональные и нефункциональные тесты) | |
|
|
Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) и приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы.
Нефункциональное тестирование описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает.
Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде вариантов использования системы (use cases).
Функциональное тестирование бывает:
Позитивное тестирование является гораздо более важным, но это не означает, что "негативными" тестами можно пренебречь.
Сканирование на предмет наличия уязвимостей (Vulnerability Scanning): Выполняется с помощью специальных программ-сканеров уязвимостей.
Сканирование безопасности (Security Scanning): Включается в себя идентификацию сетевых и системных недостатков (слабых мест), а затем предоставляет решения для сокращения таких рисков. Сканирование может выполняться как в ручном так и автоматическом режимах.
Тест на проникновение (Penetration testing): симулирует нападение злоумышленника. Это тестирование включает анализ конкретной системы с целью проверить потенциальную уязвимость к внешним попыткам взлома.
Оценка риска (Risk Assessment): включает в себя анализ рисков безопасности, наблюдаемых в организации. Риски классифицируются как слабые (low), средние (medium) и высокие (high). Этот вид тестирования рекомендует методы контроля и снижения рисков.
Стрессовое тестирование (stress testing) = тестирование приложения под экстремальными нагрузками, определение способности обрабатывать высокий уровень траффика или обработки данных. Целью является определить переломную точку приложения.
Задачей тестирования стабильности (stability) / надежности (reliability) - является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Время выполнения операций может играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты влияющие именно на стабильность работы.
Тестирование выносливости (endurance testing) = убеждение в том, что приложение может безопасно находиться под высокими нагрузками долгий период времени.
Объемное тестирование (volume testing) = получение оценки производительности при увеличении объемов данных в базе данных приложения.
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основные функции систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.
Тестирование на отказ и восстановление очень важно для систем, работающих по принципу "24x7", например интернет-магазины, ERP-системы.
Дымовые тесты выполняются каждый раз, когда мы получаем новый билд (версию), проекта (системы) на тестирование, при этом считая ее относительно нестабильной. Нам нужно убедиться что критически важные функции Приложения/Системы работают согласно ожиданиям. Идея данного вида тестирования заключается в том, чтобы выявить серьезные проблемы как можно раньше, и отклонить этот билд (вернуть на доработку) на раннем этапе тестирования, чтобы не углубляться в долгие и сложные тесты, не затрачивая тем самым время на заведомо бракованное ПО.
Проверка того, что ранее обнаруженный при тестировании дефект был успешно исправлен.
Используется каждый раз, когда мы получаем относительно стабильный билд ПО, чтобы определить работоспособность в деталях. Иными словами, здесь проходит валидация того, что важные части функциональности системы работают согласно требованиям на низком уровне.
Проводится для того, чтобы убедиться что добавленные/измененные функции приложения и исправленные дефекты не оказали негативного влияния на уже успешно действующую в Проме функциональность.
РТ занимает львиную долю времени, и как раз для сокращения затрат и существует автоматизация тестирования.
У нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:
Тогда можно сделать ряд утверждений о том, какие типы тестов нужно использовать в какой момент времени:
Ручное (manual testing) = выполнение тестировщиком тестовых сценариев и тестовых случаев вручную.
К автоматизации тестирования (automation testing) существуют следующие основные подходы:Баг репорт (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 | Значительные недостатки в пользовательском интерфейсе или в способности системы реагировать на запросы пользователя |
Тестировщики должны защищать качество и мнение пользователей о системе. Но они не должны это делать, выступая в качестве соперников программистов, выдвигая претензии личного характера или в неконструктивной манере. Предпочтительнее, если мы будем это делать путем, объединяющим реалии бизнеса с системной разработкой и сопровождением.
Структура понятного названия таска:
<Где (название страницы)> : <Какой элемент/функция страницы> - <суть ошибки/задания>
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: ("ДОПИНФО:")
Чтобы сделать хороший баг-репорт отличным - используйте любую возможность дополнить его, как то:
в проекте JIRA:
в Test Adaptavist, связанном с этим проектом:
Надеюсь, эта статья об увлекательном мире типы тестирования, была вам интересна и не так сложна для восприятия как могло показаться. Желаю вам бесконечной удачи в ваших начинаниях, будьте свободными от ограничений восприятия и позвольте себе делать больше активности в изученном направлени . Надеюсь, что теперь ты понял что такое типы тестирования, уровни тестирования и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.
Комментарии
Оставить комментарий
Качество и тестирование программного обеспечения. Quality Assurance.
Термины: Качество и тестирование программного обеспечения. Quality Assurance.