что такое функциональные тесты
Юнит тесты Vs функциональные тесты — взгляд руководителя и разработчика
Современную разработку программного обеспечения тяжело представить без автоматического тестирования — по сути это единственный способ защитить продукт от разрушительных изменений (то есть изменений, повреждающих существующий функционал).
Обычно используют два вида автоматических тестов:
Модульное тестирование (тестирование отдельных частей продукта, обычно отдельных функций/методов)
Функциональное тестирование — тестирование некого функционала продукта, при этом продукт воспринимается как единый «чёрный ящик».
Но давайте зададим интересный вопрос — действительно ли нужны оба вида тестирования сразу, и если нет — то какое из них важнее?
Итак, для начала модульное тестирование.
Кто пишет? Как правило автор модуля/метода/функции, т. к. обычно только он знает, что данная функция ДОЛЖНА делать. Как правило, это разработчик, и его цель — покрытие кода юнит-тестами. А это значит, что скорее всего, юнит-тест будет весьма не полным (как правило разработчики проверяют лишь работу с корректными данными, либо добавляют небольшой набор некорректных данных, т. к. у них не стоит задачи «сломать» свой код), либо, если разработчик действительно ответственно подойдёт к процессу написания юнит-теста, то разработка займёт вдвое больше времени. Не верите? А ведь только качественное покрытие функции «является ли аргумент числом» требует более 10 проверок. К тому же, существует огромное число функций, проверить которые модульным тестированием невозможно, либо очень сложно (это функции, поведение которых зависит от состояния системы в целом).
И даже правильная работа всех модулей системы, отнюдь не гарантирует их правильное взаимодействие.
Ещё один момент, если у вы хотите ввести модульное тестирование в продукт, на котором оно раньше не использовалось — то это очень серьёзные трудо-затраты, и покрытие небольшого числа функций абсолютно ничего не даёт.
Самое главное — даже успешное прохождение всех юнит-тестов не гарантирует правильной работы продукта: ведь одна и та же функция может быть использована в различных частях системы, в то время как юнит-тест писался для неё с оглядкой лишь на один вариант использования.
Простой пример: допустим у нас есть функция checkInt(a)
checkInt(a)
В моей практике даже был вариант комментирования моего юнит-теста, т. к. он завершался неудачно, после изменения моей функции.
Однако, следует признать, что модульное тестирование великолепный инструмент, если вы пишите некую библиотеку, предназначенную для использования многими разработчиками — в этом случае модульные тесты будут выполнять и роль документации к функциям (ведь не секрет, что мы часто пропускаем описание функции и сразу смотрим примеры использования). Впрочем, в данном случае, сама библиотека является продуктом, и модульные тесты не отличимы от функциональных.
Теперь вернёмся к функциональным тестам. Как правило, они пишутся тестерами. У которых стоит задача найти ошибку (по крайней мере своим тестерам мы всегда ставим такую задачу). А значит будет больше проверок на нестандартные данные — что согласитесь, просто великолепно! К тому же, мы можем разделить правами доступов код продукта и тестов, что позволит избежать изменений тестов «чтоб он был зелёный, потому что надо релизиться»
К тому же, функциональными тестами гораздо проще покрывать готовый продукт, чем модульными — т. к. гораздо проще понять что конкретно должна и не должна делать определённая часть пользовательского интерфейса, чем определить что ДОЛЖНА делать данная функция. И самая большая прелесть — вы можете начать покрывать функциональными тестами только самые важные части продукта — и они будут исправно гарантировать их работоспособность.
Функциональное тестирование современных web-приложений
Для своевременного обнаружения таких ситуаций и выполнения непрерывной интеграции необходимо функциональное тестирование web-приложения. В статье пойдет речь о двух бесплатных open-source решениях:
Рассматриваемые решения обеспечивают похожий, на первый взгляд, ряд возможностей.
Пример функционального теста
Примером для тестирования будет web-приложение вида TodoMVC, с сервером на node.js и клиентской SPA-страницей на React+Redux-е. Для приближения условий тестирования к реальным, во все redux-овские action-ы добавлены случайные задержки, эмулирующие сетевое взаимодействие с backend-ом (за основу взято это).
В дальнейшем будет предполагаться, что тестовое web-приложение запущено по адресу http://localhost:4000/. Функциональный тест будет простым и включать в себя добавление todo-элемента, правку его содержимого, отметку как выполненное/невыполненное задание и удаление.
Языком для написания тестов в обоих фреймворках является JS (ES2016 и ES5 соответственно для TestCafe и Nightwatch), однако это прекрасно подходит для web-приложений, написанных на любом языке. Если Вы давно не разрабатывали на JS, то необходимо учитывать, что современные редакции ушли очень далеко от старого ES3, и включают удобные средства для написания кода, объектно-ориентированного и функционального программирования и многое другое.
Исходный код функционального теста, проверяющего изложенный выше use-case-сценарий, может быть таким:
Адрес тестируемой web-страницы определяется в fixture-части, за которыми следуют функциональные тесты, по завершении каждого из которых web-страница автоматически восстанавливается в исходное состояние. Для поиска DOM-элементов на странице используются testcafe-специфические Selector-ы, использующиеся в качестве обертки для функции, которая будет выполнять запрос к DOM-модели, возможно используя аргументы.
В этом примере первый селектор представляет обертку над document.querySelector, а второй — над document.querySelectorAll с callback-функцией, помогающей выбрать нужный элемент из списка. Обертка Selector принимает опции, здесь в частности устанавливается максимальное время, в течении которого testcafe будет ожидает появление элемента с заданными характеристиками в DOM-модели.
Сам функциональный тест представляет собой набор асинхронных вызовов Selector-ов, между которыми производятся действия посредством test controller-а, инстанцированного переменной t. Назначение большинства его методов очевидно из названий (click, typeText и т.д.), а t.setNativeDialogHandler используется для предотвращения генерации alert-подобных окон, которые могут “подвесить” тест — что очень удобно.
Для запуска тестов сначала надо создать конфигурационный файл nightwatch.json, описывающий расположение тестов, пути и настройки для selenium-server и webdriver-ов, а далее использовать простую команду nightwatch в текущей директории.
Если использовать Microsoft Web Driver (Edge), то nightwatch.json может выглядеть примерно так:
Исходный код функционального теста, проверяющий аналогичный рассмотренному выше use-case-сценарий, может выглядеть так:
Среди особенностей кода легко заметить, что Nightwatch не поддерживает эмуляцию двойного щелчка по элементу — вместо этого приходится реализовывать обходной путь с inject-функцией на клиенте, выполняющую dispatchEvent на целевом элементе управления.
Удобной возможностью Nightwatch является поддержка XPath, который предоставляет значительно более широкие возможности по селекции элементов DOM-модели, по сравнению с CSS-селекторами — взять хотя бы извлечение элемента по его текстовому наполнению, что довольно часто встречается в функциональном тесте.
Сравнение функциональности TestCafe и Nightwatch
Язык написания тестов:
T: Из коробки предоставляется возможность написания тестов непосредственно на языке ES2016, что позволяет писать простой и читабельный код тестов на том же языке, что и само web-приложение Это также удобно в случаях, когда требуется импортировать определенный модуль из тестируемого проекта.
N: Устаревший ES5-синтаксис и exports-конструкции в исходном коде функционального теста (Возможность прикрутить ES6 все-таки есть, но на костылях)
Поддержка асинхронных операций:
T: Все API-функции основаны на Promise-ах, что позволяет описывать произвольную асинхронную логику работы теста, и при этом интегрировать собственные функции со стороны node.js. Благодаря поддержке ES2016, этот код можно записывать при помощи async и await конструкций в последовательном стиле.
N: В тесте можно реализовать последовательность команд по анализу и управлению содержимым web-страницы, однако они складываются во внутреннюю очередь событий, и интегрировать собственные асинхронные функции с ними проблематично.
Вставка клиентского кода на лету:
T: Легко осуществляется при помощи соответствующего API, поддерживается создание и последующее выполнение клиентских функций, однократное исполнение injected-кода, замена существующих функций в исходной web-странице, а также исполнение клиентских функций в callback-ах node.js-функций с привязкой к тестовому контроллеру.
N: Есть функциональность для выполнение JS-кода на клиентской стороне, или даже вставки целого script-блока, но средств интеграции с тест-контроллером не предоставляется. Подходит для простого синхронного интегрируемого JS-кода, но в более общем случае интеграция проблематична.
Работа с курсором мыши:
T: Предоставляется виртуальный курсор, посредством которого осуществляются hover, click и drag-события для целевым визуальных элементов страницы. В процессе выполнения теста можно наблюдать за перемещением курсора и выполняемыми действиями.
N: Средства для работы с курсором вообще есть — это функции из webdriver api, однако работать с действиями, сложнее одиночного левого клика, довольно проблематично — взять хотя бы двойной щелчок.
Реализация взаимодействия с браузером в TestCafe и NightWatch
Фреймворк NightWatch основывается на известной, в некоторой мере уже традиционной, библиотеке Selenium webdriver, преимущества которой включают устоявшееся API, высокую степень документированности и обширное Q&A в интернете, а также универсальный и достаточно низкоуровневый доступ к браузеру… Взаимодействие с браузерами организуется посредством webdriver-ов, по одному на каждый обозреватель.
Основной недостаток — webdriver-ы существуют далеко не для всех браузеров, а также требуют отдельного обновления при смене версии самого браузера, а еще для работы необходимо наличие внешней зависимости от Java. Более подробно о технологии webdriver можно прочесть в http://www.w3.org/TR/webdriver/
Фреймворк TestCafe основан на подходе, в котором взаимодействие с приложением браузера сведено к минимуму — используются только функции открытия окна/вкладки, изменения размера окна, перехода по URL-адресу и некоторые другие.
Взаимодействие с web-страницей производится посредством web-proxy сервера testcafe-hammerhead, осуществляющего загрузку удаленной web-страницы и модификацию исходного JS-кода таким образом, чтобы выполнить шаги функционального теста, посредством интеграции с DOM-моделью, поиска и управления визуальными элементами, выполнение произвольного JS-кода и так далее. (https://github.com/DevExpress/testcafe-hammerhead/)
Метод TestCafe более универсален, поскольку может потенциально работать с любым браузером, поддерживающим HTML5 и ES 5+, в то время как NightWatch требует соответствующий webdriver. Кроме того, это позволяет прогонять тесты не только на локальном браузере, но на любом браузере в сети, включая любые мобильные — без установки какого-либо ПО на телефоне.
Пример тестирования вышерассмотренного web-приложения в браузере на Android показан в следующем видео: https://youtu.be/2na5jkqvUx0
Однако testcafe-hammerhead имеет и потенциальные недостатки: накладные расходы на анализ и модификацию исходного JS-кода тестируемой страницы, производимые в свою очередь JS-коде ядра Testcafe, а также теоретически некорректная работа тестируемой web-страницы или интеграции теста, если исходный код был проксирован неверно. (К примеру, замещение alert-окна в testcafe можно обойти таким примером http://pastebin.com/p6gLWA75 — и неумешленно или специально “подвесить” его выполнение)
Выводы
Конечно, selenium-webdriver, на котором основан Nightwatch, является популярным и широко известным решением, имеющем стандартный API-интерфейс, что несомненно является его достоинством. Кроме того, в смежных областях задач, например автоматизации целевого web-ресурса в заданном браузере — фактически написании бота для удаленного web-сайта — selenium-webdriver подходит лучше.
Однако для функционального тестирования разрабатываемого или поддерживаемого web-приложения TestCafe несомненно впереди по широкому ряду причин:
1) Запуск тестов в любом браузере, в том числе мобильных телефонах и планшетах, причем это может производиться пакетным образом для всех интересуемых браузеров и не требует установки никакого дополнительного ПО.
2) Удобство написания теста на ES2016, включающее async/await-конструкции для последовательной записи кода, импорт программных элементов из самого проекта, передачу функций в клиент и обратно и так далее — широкие возможности по интеграции и управлению клиентским web-приложением.
3) Широкая поддержка selector-ов для визуальных элементов, легкое взаимодействие с DOM-моделью, виртуальный курсор мыши, эмуляция разнообразных и сложных взаимодействий пользователя со страницей.
Таким образом, среди существующих open-source решений для функционального тестирования web-приложений, TestCafe выглядит очень привлекательным вариантом, к тому же при сочетании легковесности и функциональности.
Теория тестирования ПО просто и понятно
Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).
ОСНОВНЫЕ ТЕРМИНЫ
Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:
планированием работ (Test Management)
проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.
анализом результатов (Test Analysis)
Основные цели тестирования
техническая: предоставление актуальной информации о состоянии продукта на данный момент.
коммерческая: повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.
Верификация (verification)
Валидация (validation)
Соответствие продукта требованиям (спецификации)
Соответствие продукта потребностям пользователей
Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.
Следует уметь различать, что:
Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).
Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).
Жизненный цикл бага
Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.
Градация Серьезности дефекта
Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.
НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА
Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.
Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.
Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.
Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT ).
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.
Пример таблицы принятия решений
ВИДЫ ТЕСТИРОВАНИЯ
Классификация по целям
Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.
Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).
Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».
Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения.
Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).
Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.
Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.
Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
Классификация по позитивности сценария
Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.
Классификация по знанию системы
Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.
Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
Тестирование чёрного ящика (Black Box) — метод тестирования ПО, также известный как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, которая не предполагает доступа (полного или частичного) к системе, т.е. основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по исполнителям тестирования
Альфа-тестирование — является ранней версией программного продукта, тестирование которой проводится внутри организации-разработчика; может быть вероятно частичное привлечение конечных пользователей.
Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.
Классификация по уровню тестирования
Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Подходы к интеграционному тестированию
Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.
Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.
Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.
Классификация по исполнению кода
Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки. Например, путем анализа кода (code review). Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к этому виду относится тестирование требований, спецификаций и прочей документации.
Динамическое тестирование проводится на работающей системе, т.е. с осуществлением запуска программного кода приложения.
Классификация по хронологии выполнения
Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.
Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.
Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
ДОКУМЕНТАЦИЯ
Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Основные атрибуты требований:
Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
Недвусмысленность — требование должно содержать однозначные формулировки.
Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).
Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:
Что нужно тестировать?
Как будет проводиться тестирование?
Когда будет проводиться тестирование?
Критерии начала тестирования.
Критерии окончания тестирования.
Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.
Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.