В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Атрибуты требований:
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Техники тест-дизайна
Автор книги "A Practitioner’s Guide to Software Test Design", Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Тестирование системы
Если в общем случае рассматривать жизненный цикл системы (например, V-образный), то наша задача лежит где-то справа (рис.2.21.
Рис. 2.2. Обобщенный V-образный жизненный цикл разработки и верификации программных систем
Применительно к нашей системе, жизненный цикл можно представить согласно рис.2.3. Сначала необходимо проверить код, затем архитектуру и требования.
Рис. 2.3. V-образный жизненный цикл разработки и верификации системы «Калькулятор»
Проверка программного кода
На этом этапе необходимо проверить корректность работы написанного кода. Для этого предлагается проводить тестирование каждого модуля отдельно. То есть, мы будем тестировать модули по отдельности, подменяя используемые методы других модулей «заглушками».
Например, при тестировании модуля анализа и вычислений выражений модуль, отвечающий за вычисления простых математический функций, можно заменить на модуль, содержащий стандартные методы области Math. Так мы будем точно знать, что все ошибки, выявленные при тестировании, не имеют отношения к нашей заглушке. Таким образом, заменив все модули, кроме тестируемого, заглушками, мы сможем утверждать, что все ошибки, обнаруженные при тестировании, будут относиться к «настоящему» (тестируемому) модулю.
Более того, заглушки дают нам дополнительное преимущество в тестировании. Мы можем написать заглушки, возвращающие пользователю дополнительную информацию во время тестирования. Например, нам необходимо узнать значение определенной переменной во время выполнения программы. Для этого мы можем написать
Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения
заглушку, которая будет записывать значение этой переменной в лог — файл или на консоль.
Немного о тестировании конкретных модулей.
GUI. На примере этого модуля можно было бы узнать, какие подходы существуют для тестирования современного графического интерфейса. В рамках данного курса этот вид тестирования рассматриваться не будет.
Математические функции. Этот модуль мы будем исследовать как «черный ящик» и выяснять, действительно ли реализованные в нем математические функции работают корректно.
Вычисление выражений. При тестировании этого модуля нам предстоит проверить корректность алгоритмов разбора и компиляции математических выражений.
При тестировании будет использоваться следующая последовательность действий.
Сначала мы познакомимся с методами ручного тестирования в среде разработки при ручном тестировании модуля анализа и вычисления выражений. Затем мы перейдем к модульному тестированию. В завершении тестирования компонент мы проведем формальные инспекции кода. После этого мы узнаем, что такое покрытия и как они используются в процессе тестирования.
Проверка архитектуры
После проверки каждого модуля по отдельности мы проведем интеграционное тестирование. На этом этапе проверяется, как модули взаимодействуют друг с другом. При условии, что все модули протестированы и ошибок в них не выявлено, все ошибки на этом этапе будут относиться именно к взаимодействию модулей между собой.
Проверка требований
Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения
После прохождения всех этапов тестирования необходимо провести проверку требований Системы в целом, то есть провести системное тестирование. Но в рамках данного курса этот вид тестирования рассматриваться не будет.
https://habr. com/ru/post/549054/
https://bstudy. net/705765/informatika/testirovanie_sistemy