Общее понимание тестирования

Тестирование ПО (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

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

Для чего проводится тестирование ПО?

  • Для проверки соответствия требованиям

  • Для обнаружение проблем на более ранних этапах разработки и предотвращение повышения стоимости продукта

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

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

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

  • Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects). Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия.

  • Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible). Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).

  • Принцип 3 — Раннее тестирование (Early testing). Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше.

  • Принцип 4 — Скопление дефектов (Defects clustering). Большая часть дефектов находится в ограниченном количестве модулей.

  • Принцип 5 — Парадокс пестицида (Pesticide paradox). Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.

  • Принцип 6 — Тестирование зависит от контекста (Testing is context depending). Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.

  • Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям. Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) — эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть. QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта. К задачам контроля качества относятся:

    • проверка готовности ПО к релизу;

    • проверка соответствия требований и качества данного проекта.

QA (Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества. К задачам обеспечения качества относятся:

  • проверка технических характеристик и требований к ПО;

  • оценка рисков;

  • планирование задач для улучшения качества продукции;

  • подготовка документации, тестового окружения и данных;

  • тестирование;

  • анализ результатов тестирования, а также составление отчетов и других документов.

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

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

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

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

  1. Анализ продукта

  2. Работа с требованиями

  3. Разработка стратегии тестирования и планирование процедур контроля качества

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

  5. Тестирование прототипа

  6. Основное тестирование

  7. Стабилизация

  8. Эксплуатация

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

  1. анализ требований к проекту;

  2. проектирование;

  3. реализация;

  4. тестирование продукта;

  5. внедрение и поддержка.

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

Требования

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

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

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

  3. Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.

  4. Недвусмысленность — требование должно содержать однозначные формулировки.

  5. Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

  6. Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.

  7. Атомарность — требование нельзя разбить на отдельные части без потери деталей.

  8. Модифицируемость — в каждое требование можно внести изменение.

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

Last updated