Основные понятия

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

Цели тестирования - Повысить вероятность того, что приложение, предназначенное для тестирования, будет работать правильно при любых обстоятельствах.

Ссылки:

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

Терминология

Качество программного обеспечения (Software Quality)

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

Тест план (Test Plan)

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

Чек-лист (check list)

Документ, описывающий что должно быть протестировано

Тест дизайн

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

Тестовый сценарий (Test Case)

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

PreConditions

Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки

Test Case Description

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

PostConditions

Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста — initial state)

Дефект (он же баг)

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

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

Error

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

Bug (defect)

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

Failure

Сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы.

Severity vs Priority
Серьезность (Severity)

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

Приоритет (Priority)

Это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.

Верификация vs Валидация

Верификация (is the system correct to specification?)

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

Валидация (is this the right specification?)

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

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

Модульное тестирование (Unit Testing)

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

Интеграционное тестирование (Integration Testing)

Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

Системное тестирование (System Testing)

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

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

Операционное тестирование (Release Testing)

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

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

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

Приемочное тестирование (Acceptance Testing)

Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

  • определения удовлетворяет ли система приемочным критериям;

  • вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

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

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

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

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

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

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

  • Тестирование безопасности (Security and Access Control Testing)

  • Тестирование взаимодействия (Interoperability Testing)

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

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

В целом, это тестирование того, “Как” система работает

  • Все виды тестирования производительности:

    • нагрузочное тестирование (Performance and Load Testing)

    • стрессовое тестирование (Stress Testing)

    • тестирование стабильности или надежности (Stability / Reliability Testing)

    • объемное тестирование (Volume Testing)

  • Тестирование установки (Installation testing)

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

  • Тестирование на отказ и восстановление (Failover and Recovery Testing)

  • Конфигурационное тестирование (Configuration Testing)

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

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

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

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

  • Регрессионное тестирование (Regression Testing)

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

  • Повторное тестирование (Re-testing)

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

    Re-testing

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

    Regression testing

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

  • Тестирование сборки (Build Verification Test)

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

    По своим целям является аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию.

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

  • Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

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

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

Ссылки:

http://www.protesting.ru/testing/testtypes.html

TDD

TDD (test-driven development)

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

BDD - Behavior-driven development «разработка через поведение»

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

Ссылки:

Разработка через тестирование

F.I.R.S.T. Principles

Пять принципов чистых тестов (F.I.R.S.T. Principles)

Каждый модульный тест должен обладать следующими характеристиками:

Быстрота (Fast)

Тесты должны выполняться быстро

Независимость (Independent)

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

Повторяемость (Repeatable)

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

Очевидность (Self-Validating)

Результатом выполнения теста должно быть булево значение

Своевременность (Timely)

Тесты должны создаваться своевременно

Ссылки:

(F.I.R.S.T. Principles)

Coverage, other metrics

Покрытие кода тестами

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

Покрытие требований (из Требования к разрабатываемому ПО)

«Общее количество тестов» / «Общее количество требований»

Позволяет оценить степень полноты системы тестов по отношению к функциональности системы.

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

Степень взаимосвязанности требований (из Требования к разрабатываемому ПО)

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

Плотность дефектов (из Качество разрабатываемого продукта)

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

Коэффициент регрессии (из Качество разрабатываемого продукта)

«Количество дефектов в старом функционале» / «Общее количество дефектов, включая новый функционал»

Коэффициент повторно открытых дефектов (из Качество разрабатываемого продукта)

«Количество повторно обнаруженных дефектов» / «Общее количество ошибок, включая ранее исправленные и новые»

Среднее время жизни дефекта (из Возможности и эффективность команды QA)

«Суммарное время исправления найденных дефектов» / «Количество дефектов»

Эффективность тестов и тестовых наборов (из Качество работы команды тестирования)

«Количество обнаруженных ошибок» / «Количество кейсов в тестовом наборе»