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

Обновлено: 07.07.2024

Уже готов стать тестировщиком или хочешь освежить базовые понятия? Тогда этот гайд – то, что нужно! Команда ПОИНТ и курса Jedi.Point структурированно делится теоретическими основами тестирования: от видов до полезных инструментов.

Что такое Тестирование ПО?

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

В чем разница между тестированием, QC и QA?

  • тестирование отвечает непосредственно за нахождение багов;
  • QC (контроль качества) – за выполнение процесса тестирования (написание/прохождение кейсов, поиск/заведение дефектов etc);
  • QA (обеспечения качества) – за создание системы контроля, которая будет предотвращать появление багов уже на этапе разработки ПО, сокращая количество выявленных дефектов на этапе тестирования; грубо говоря – построение самого процесса тестирования.

Зачем нужно тестирование и тестировщики?

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

Еще 5-6 лет назад такой вопрос обсуждался в ИТ-кругах и на просторах Интернета. Но в 2020 ясно: тестировщики без работы не останутся, а тестирование должны осуществлять специалисты в сфере QA.

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

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

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

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

Более того, периодически методы устаревают, и возникают новые термины.

С какими же основными классификациями и типами тестирования стоит ознакомиться начинающим тестировщикам?

Виды тестирования ПО по степени автоматизации

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

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

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

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

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

Разница между ручным и автоматизированным тестированием

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

Также рекомендуем:

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

Функциональное тестирование (functional testing) проверяет часть системы, которая необходима для того, чтобы пользователь мог выполнить бизнес-сценарий от начала до конца. Оно выполняется первым, до нефункционального тестирования. Примеры: переход по разделам форума, поиск по сайту.

Методы и техники функционального тестирования:

  • Модульное тестирование
  • Тестирование белого ящика
  • Пользовательское тестирование
  • Сессионное тестирование — компромисс между исследовательским и скриптовым тестированием.

Агеева Нина, автор курса Погружение в тестирование. Jedi Point, рассказывает о сессионном тестировании

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

Типы нефункционального тестирования:

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

Тестирование безопасности – это вид тестирования для выявления уязвимости программного обеспечения к различным атакам (SQL, XSS etc).

Рекомендуем ознакомиться:

  • Тестирование локализации (localization testing)

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

  • Юзабилити тестирование (usability testing)

Тестирование юзабилити – это метод тестирования, направленный на выявление удобства и понятности интерфейса.

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

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

Агеева Нина, автор курса Погружение в тестирование. Jedi Point, рассказывает о позитивном и негативном тестировании

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

Для описания процесса тестирования поэтапно существует несколько методик. Одна из самых понятных и простых моделей – STLC.

STLC (Software Testing Life Cycle) означает жизненный цикл тестирования программного обеспечения.

Модель жизненного цикла тестирования программного обеспечения (модель STLC) состоит из шести основных фаз.

6 фаз STLC (Software Testing Life Cycle):

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

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

По этой теме рекомендуем почитать:

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

Планирование тестирования. На данном этапе разрабатывается стратегия тестирования, выявляются риски, выбираются инструменты и распределяются роли в команде. Все это фиксируется в таких документах, как тест-план и тест-стратегия.

Агеева Нина, автор курса Погружение в тестирование. Jedi Point, подробно объясняет, что такое стратегия и как ее составить

Разработка тест-кейсов.

О том, почему мы пишем тест-кейсы, можно узнать в нашем видео:

Станислав Марков, тренер ПОИНТ и курса Погружение в тестирование. Jedi Point детально рассказывает о каждой фазе
А о том, как писать тест-кейсы, вы можете узнать на нашем Youtube-канале

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

Выполнение тестов. Команда QC начинает выполнение тест-кейсов в соответствии с планами тестирования и создает отчеты о багах. Также чаще всего на этом этапе происходит валидация багов. Она нужна для того, чтобы убедится, что дефекты, которые ты завёл ранее, ДЕЙСТВИТЕЛЬНО пофиксили.

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

Станислав Марков, тренер ПОИНТ и курса Погружение в тестирование. Jedi Point детально рассказывает о каждой фазе

Инструменты тестировщика

Инструменты тестирования – все продукты, которые помогают QA-инженерам организовывать свою работу на каждом этапе.

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

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

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

Инструменты для кросс-браузерного тестирования

Инструменты для нагрузочного тестирования

Инструменты для баг трекинга

Инструменты для автоматизации тестирования мобильных приложений

Для iPhone и iPad:

Мобильные эмуляторы

Инструменты для тестирования юзабилити

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

Инструменты тестирования безопасности

CSS Валидаторы

Также рекомендуем:

Надеемся, наш гайд помог вам в понимании основ тестирования. Успехов в карьере тестировщика!

А тем, кто хочет узнать о каждом аспекте тестирования на практике, рекомендуем пройти курсы тестирования ПО.

И обязательно скачайте чек-лист “Что должен знать и уметь джуниор-тестировщик”, заполнив небольшую анкету.

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


Что такое тестирование программного обеспечения (ПО)?

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

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

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

Тестирование можно классифицировать…

По критерию запуска программы:

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

    • Функциональности;
    • Безопасности;
    • Удобства использования;
    • Локализации; ;
    • Совместимости;
    • Отказоустойчивости*;
    • И т.д.

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

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

      :
      ;
    • Sanity тестирование;
    • Тестирование новой функциональности; ; ; .

    По степени подготовленности:

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

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

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

    По знанию системы:


    Можно ли выделить наиболее востребованные виды тестирования?

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

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

    Ручное тестирование применяется в регрессионном (тестирование изменений), интеграционном (связь с другими системами) и при тестировании нового функционала.

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

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

    Есть ли какие-то базовые принципы тестирования?

    Вот семь основных из них:

    Как понять, когда нужно начинать тестирование?

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

    Что такое баги?

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

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

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

    Базовые инструменты тестировщика:

    • Текстовый редактор для поиска, конвертации и сравнения файлов (Notepad++, PSPad и др.),
    • Xml-редактор (Altova XML Spy (работа с xml и xsd), XMLPad и др.),
    • Инструмент для работы со снимками экранов (Snipping Tool, Snagit, GreenShoot, ScreenHunter и др.),
    • Инструмент для записи видео с содержимым экрана (CamStudio, Ashampoo Snap, Free Screen Video Recorder и др.),
    • Инструмент для сравнения графических файлов (ImageDiscerner, FastStone Image Viewer, ImageDupeless, Graf2 Free rus),
    • Файловый менеджер (Total Commander, Far Manager, TrolCommander, Free Commander),
    • Планировщик задач (MS Outlook, Redmine и др.).

    Как можно оценить качество ПО?

    Оценка программного обеспечения производится согласно международному стандарту ISO 9126. ПО будет качественным, если можно обеспечить его функциональность, надежность, удобство использования, удобство сопровождения, производительность и переносимость. Чем больше атрибутов качества можно реализовать или поддержать (для производительности — это соответствие стандартам, временная эффективность и эффективность использования ресурсов и т.д.), тем выше будет качество ПО. У атрибутов есть и численные показатели — метрики, которые позволяют измерять прогресс в достижении качества.

    Что такое тест-план и что в нем должно быть написано?

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

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

    Основные разделы тест-плана:

    • Назначение,
    • Объект тестирования,
    • Тестовая стратегия,
    • Применяемые виды тестирования,
    • Условия проведения тестирования,
    • Критерии начала и завершения тестирования,
    • План-график проведения тестирования,
    • Ресурсы, необходимые для выполнения тестирования,
    • Возможные риски.

    Что такое тест-дизайн и зачем он нужен?

    Тест-дизайн — одна из наиболее творческих деятельностей в IT. Это этап процесса тестирования ПО, на котором, в соответствии с определенными ранее критериями качества и целями тестирования, проектируются и создаются тестовые случаи (тест-кейсы).

    Задачи тест-дизайна:

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

    Что является результатом работы инженера по тестированию?

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







    Что пишут в блогах

    Подписаться

    Онлайн-тренинги

    Конференции

    Heisenbug 2022 Spring
    Большая техническая конференция по тестированию
    12-14 апреля 2022, онлайн

    Что пишут в блогах (EN)

    • Aginext Conference 2022 Global
    • This content. " target="_blank" rel="nofollow">How far should you go in your investigation of a defect?
    • Is there such a thing as an Evil Tester? Poking holes is good.
    • 5 Software Testing Trends in 2022
    • Why Speak at conferences? write blogs? - To get your message out.
    • I’m independent!
    • How My Team Tests for Now
    • Lesson Learned - I'm not ready for that vs I could do but choose not.
    • Two Ways of Solo Programming
    • The Positive Negative Split Leads Us Astray

    Разделы портала

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


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

    В соответствие с IEEE Std 829-1983 Тестирование — это процесс анализа ПО, направленный на выявление отличий между его реально существующими и требуемыми свойствами (дефект) и на оценку свойств ПО.

    По ГОСТ Р ИСО МЭК 12207-99 в жизненном цикле ПО определены среди прочих вспомогательные процессы верификации, аттестации, совместного анализа и аудита. Процесс верификации является процессом определения того, что программные продукты функционируют в полном соответствии с требованиями или условиями, реализованными в предшествующих работах. Данный процесс может включать анализ, проверку и испытание (тестирование). Процесс аттестации является процессом определения полноты соответствия установленных требований, созданной системы или программного продукта их функциональному назначению. Процесс совместного анализа является процессом оценки состояний и, при необходимости, результатов работ (продуктов) по проекту. Процесс аудита является процессом определения соответствия требованиям, планам и условиям договора. В сумме эти процессы и составляют то, что обычно называют тестированием.

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

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

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

    Рис. 1. Жизненный цикл продукта по RUP

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

    Жизненный цикл программного продукта состоит из серии относительно коротких итераций (Рис. 2). Итерация — это законченный цикл разработки, приводящий к выпуску конечного продукта или некоторой его сокращенной версии, которая расширяется от итерации к итерации, чтобы, в конце концов, стать законченной системой.

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

    Рис. 2. Итерации жизненного цикла программного продукта

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

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

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

    • нагрузочное тестирование;
    • тестирование бизнес циклов;
    • стрессовое тестирование.
    • нагрузочное тестирование;
    • тестирование бизнес циклов;
    • стрессовое тестирование.

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

    • unit-тестирование (модульное тестирование);
    • функциональное тестирование;
    • тестирование интерфейса;
    • тестирование БД
    • unit-тестирование (модульное тестирование);
    • функциональное тестирование;
    • тестирование интерфейса;
    • тестирование БД.

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

    • unit-тестирование (модульное тестирование);
    • функциональное тестирование;
    • тестирование интерфейса;
    • тестирование БД.

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

    Unit-тестирование (модульное тестирование) — данный вид подразумевает тестирование отдельных модулей приложения. Для получения максимального результата тестирование проводится одновременно с разработкой модулей.

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

    Тестирование БД — проверка работоспособности БД при нормальной работе приложения, в моменты перегрузок и многопользовательском режиме.

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

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

    В выходную документацию данных тестов входят тестовые процедуры, входные данные, код, исполняющий тест, выходные данные. Далее представлен вид выходной документации.

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

    Функциональное тестирование объекта тестирования планируется и проводится на основе требований к тестированию, заданных на этапе определения требований. В качестве требований выступают бизнес-правила, диаграммы use-case, бизнес-функции, а также при наличии, диаграммы активности. Цель функциональных тестов состоит в том, чтобы проверить соответствие разработанных графических компонентов установленным требованиям.

    Данный вид тестирования не может быть полностью автоматизирован. Следовательно, он подразделяется на:

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

    Цель: протестировать ввод, обработку и вывод данных;

    Цель: тестируется правильность выполнения пользовательских требований.

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

    Тестирование БД

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

    Бесплатные курсы

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

    Это одна из техник QC, включающая в себя:

    планирование работ (Test Management)

    выполнение тестирования (Test Execution)

    анализ результатов (Test Analysis)

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

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

    Разработка стратегии тестирования и планирование QC

    Создание тестовой документации

    Качество программного обеспечения (Software Quality) — совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

    Верификация (verification) — процесс оценки системы (её компонентов) с целью понимания, удовлетворяет ли ее работоспособность условиям, сформированным в тест-плане/спецификации. Т.е. выполняются ли цели, сроки, заданные в этих документах.

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

    Верификация (verification)

    Валидация (validation)

    Соответствие продукта требованиям (спецификации)

    Соответствие продукта потребностям пользователей

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

    Требования к требованиям:

    Полнота набора требований

    Непротиворечивость набора требований

    Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.

    Следует уметь различать, что:

    Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

    Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).

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


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

    Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.

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

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

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

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

    Тривиальная (Trivial) - ошибка, не касающаяся бизнес-логики приложения, не оказывающая никакого влияния на общее качество продукта.

    Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.

    Тест дизайн

    Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

    Ответственные за тест дизайн:

    Техники тест дизайна

    Эквивалентное Разделение (Equivalence Partitioning — EP). Как пример, есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.

    Анализ Граничных Значений (Boundary Value Analysis — BVA). Если брать пример выше, в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

    Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).

    Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.

    Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных. Используется для тестирования сущностей с большими наборами входных данных (например, фильтры, сортировки). Преимущество данной техники в том, что она сокращает общее количество тест-кейсов, тем самым уменьшая время и расходы, затраченные на тестирование. Эта техника заслуживает отдельного внимания и более подробно рассматривается здесь. Также в конце данной статьи есть инструменты для автоматизации этой техники.

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

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


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

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

    Тестирование пользовательского интерфейса (GUI Testing) — функциональная проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).

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

    Тестирование установки (Installation testing) направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.

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

    Тестирование взаимодействия (Interoperability Testing) — это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование

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

    Нагрузочное тестирование — это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.

    Тестирование стабильности или надежности (Stability / Reliability Testing). Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

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

    Объемное тестирование (Volume Testing). Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения

    По виду Тестовых Сценариев:

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

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

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

    Модульное тестирование (Unit Testing) Компонентное - проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

    Интеграционное тестирование (Integration Testing) Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

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

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

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

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

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

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

    Исследовательское / ad-hoc тестирование

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

    Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками.

    Дымовое (Smoke) тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.

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

    Повторное тестирование — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок. В чем разница между regression testing и re-testing? Re-testing — проверяется исправление багов Regression testing — проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвало новых багов.

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

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

    Документация

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

    Что нужно тестировать?

    Как будет тестироваться?

    Когда будет тестироваться?

    Критерии начала тестирования.

    Критерии окончания тестирования.

    Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.

    Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для валидации покрытия продукта тестами.

    Читайте также: