Тестирование программ зародилось практически одновременно с программированием. Машинное время стоило дорого, поэтому предприятия с повышенными требованиями к надежности программ (например, авиакосмическая промышленность) стали активно разрабатывать методики тестирования.
Долгое время было принято считать, что целью тестирования является доказательство отсутствия ошибок в программе. Однако этот тезис не выдерживает критики, т. к. полный перебор всех возможных вариантов выполнения программы находится за пределами вычислительных возможностей даже для очень небольших программ. Поэтому никакое тестирование не может гарантировать отсутствия ошибок.
Со временем понимание целей тестирования изменилось, и один из основоположников тестирования Гленфорд Майерс предложил следующее определение: «Тестирование – это процесс выполнения программ с целью обнаружения ошибок».
Сегодня дается следующее определение понятия "тестирование":
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Отладка (debugging) не является разновидностью тестирования. Отладка направлена на установление точной природы известной ошибки, а затем – на исправление этой ошибки.
Баг (bug, дефект) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result).
Отчет о дефекте (bug report, баг-репорт, отчет об ошибке) — это документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.
Система отслеживания ошибок (bug tracking system) — это программа учета и/или контроля багов. Ее обычно называют баг-трекер или баг-трекинг. Это могут быть как специально разработанные программы, так и обычные гугл-таблицы. Суть в том, что в одном месте собраны все наши отчеты об ошибках и в любое время можно получить доступ к любому отчету.
Билд — это продукт или часть продукта, который можно тестировать.
Релиз или RTM (англ. Release to manufacturing — промышленное издание) — это издание продукта, готового к тиражированию.
Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Чек-лист (check list) — это документ, который описывает что должно быть протестировано. Чек-лист может быть абсолютно разного уровня детализации.
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Тестовое покрытие — это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.
Тестирование в жизненном цикле разработки программного обеспечения
До начала 80-х годов процесс тестирования программного обеспечения был разделен с процессом разработки: вначале программисты реализовывали заданную функциональность, а затем тестировщики приступали к проверке качества созданных программ. Такая модель жизненного цикла разработки ПО называется каскадной (или водопадной) и состоит из 5 основных этапов: разработка требований к программе, проектирование, реализация, тестирование и сопровождение. Однако описанный выше подход создает множество проблем. Например, разработка программ может оказаться достаточно длительной (скажем, несколько месяцев), чем тогда в это время должны заниматься тестировщики? Другая, более серьезная проблема заключается в плохой предсказуемости результатов такого процесса разработки. Ключевым вопросом здесь может быть: какое количество времени потребуется на завершение продукта, в котором существует 500 известных ошибок? На самом деле, предугадать это совершенно невозможно, так как разные ошибки будут требовать разного количества времени на исправление, а исправление известных ошибок будет неизбежно связано с внесением новых. Существует следующая мрачная статистика: даже однострочное изменение в программе с вероятностью 55 % либо не исправляет старую ошибку, либо вносит новую. Если же учитывать изменения любого объема, то в среднем менее 20 % изменений корректны с первого раза.
В связи с этим, в 90-х годах появилась другая методика разработки, которую вслед за компанией Microsoft называют zero-defect mindset. Основная идея этой методики заключается в том, что качество программ проверяется не post factum, а постоянно в процессе разработки. Например, программист не может перейти к разработке новой функциональности, если существуют известные ошибки высокого приоритета в частях, разработанных им ранее. Так появились шарнирно-каскадная (или V-образная), а также спиралевидная модели разработки ПО.
При такой постановке вопроса тестирование становится центральной частью каждого этапа жизненного цикла разработки программ: тестированию подвергаются требования к программному продукту, алгоритмы, исходные коды, модули, программные сборки, функциональность программ и т. д. Практика показывает, что, чем раньше найдена ошибка, тем дешевле ее исправить. Частым примером в литературе является следующий: стоимость незамеченной ошибки в документе требований, которую можно оценить в 2 $, вырастает в 200 $ на этапе сопровождения, поскольку были затрачены силы и время на все предыдущие этапы.
На разных этапах жизненного цикла ПО тестирование проводится в разных формах:
- на этапе определения требований: их анализ и верификация также могут считаться тестированием;
- контроль процесса проектирования на этапе разработки дизайна системы – это тоже форма тестирования;
- как уже упоминалось, разработчики тоже участвуют в тестировании на уровне модульного тестирования.
Труднее определить критерий окончания тестирования, поскольку, согласно принципам тестирования, мы никогда не можем быть уверены в том, что программа на 100% свободна от дефектов. Поэтому используются другие условия:
- граничные сроки, установленные заранее;
- выполнение всех предусмотренных тест-кейсов;
- достижение определенного уровня тестового покрытия;
- когда после определенного момента, мы практически не находим новых багов или критических дефектов;
- решение менеджмента.
Уровни тестирования
Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
Цель: проверка правильности реализации функциональных / нефункциональных требований в модуле, раннее обнаружение ошибок
Объект: модуль / компонент / unit
Базис: дизайн системы, код, спецификация компонента
Типичные ошибки: ошибка в реализации требований, ошибка в коде
Ответственный: разработчик (редко тестировщик)
На этом уровне тестирования создаются модульные тесты (unit тесты), которые проверяют правильность работы модуля в тестовых условиях. Эти проверки всегда автоматизированы и выполняются очень быстро (несколько тысяч тестов в минуту).
Unit тесты, кроме поиска ошибок, также помогают оценивать качество кода, измерять покрытие кода тестами, сокращать время и затраты на тестирование.
Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
Цель: проверка правильности реализации взаимодействия между компонентами / модулями / частями системы
Объект: модули, состоящие из нескольких компонентов; под-системы, API, микросервисы
Базис: дизайн системы, архитектура системы, описание связей компонентов
Типичные ошибки: отсутствие / неправильные связи между элементами системы, неправильные передаваемые данные, отсутствие обработки ошибок, отказы и падения при обращениях к API
Ответственный: разработчик и тестировщик
Интеграционные тесты выполняются дольше (несколько десятков в минуту), чем модульные интеграционные тесты (несколько сотен-тысяч в минуту) и являются более творческими.
Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
Цель: проверка работы системы в целом
Объект: система, конфигурации системы, рабочее окружение
Базис: системные требования, бизнес требования, сценарии использования, User Stories, системные руководства, инструкции
Типичные ошибки: невозможность выполнять функциональные задачи, для которых создавалась система, неправильная передача данных внутри системы, неспособность системы работать правильно в среде эксплуатации, нефункциональные сбои (уязвимости, зависания, выключения)
Ответственный: тестировщик
Системное тестирование может включать в себя различные типы тестирования. Эти тесты все чаще автоматизируется и именно этот вид автоматизации сейчас очень востребован (JAVA, Python, JavaScript, C#, Selenium и т.п.)
Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
Существуют несколько форм приемочного тестирования:
Пользовательское приемочное тестирование (User Acceptance testing, UAT) — проверяет пригодность системы к эксплуатации конечными пользователями.
Контрактное приемочное тестирование — проводится в соответствии с критериями, указанными в контракте приемки специального ПО.
Альфа-тестирование (alpha testing) и бета-тестирование (beta-testing) — используются для получения обратной связи от потенциальных или существующих клиентов.
Альфа-тестирование проводится “внутри” компании, без участия разработчиков / тестировщиков продукта.
Бета-тестирование проводится реальными пользователями системы.
Цель: проверка готовности системы
Объект: система, конфигурация системы, бизнес процессы, отчеты, аналитика
Базис: системные требования, бизнес требования, сценарии использования, User Stories
Типичные ошибки: бизнес-требования неправильно реализованы, система не соответствует требованиям контракта
Ответственный: заказчик / клиент / бизнес-аналитик / product owner и тестировщик.
Количество тестов на приемочном уровне намного меньше, чем на других уровнях, потому что в этот момент времени вся система уже проверена. Приемочные тесты практически никогда не автоматизируются.
Источники:
