Тестирование программного обеспечения — это процесс проверки того, соответствует ли программное обеспечение ожиданиям.
Тестирование программного обеспечения может предоставить пользователю или спонсору объективную, независимую информацию о качестве программного обеспечения и риске его сбоя . [1]
Тестирование программного обеспечения может определить правильность программного обеспечения для определенных сценариев , но не может определить правильность для всех сценариев. [2] [3] Оно не может найти все ошибки .
Основываясь на критериях измерения правильности от оракула , тестирование программного обеспечения использует принципы и механизмы, которые могут распознать проблему. Примерами оракулов являются спецификации , контракты , [4] сопоставимые продукты, прошлые версии того же продукта, выводы о предполагаемой или ожидаемой цели, ожиданиях пользователя или клиента, соответствующих стандартах и применимых законах.
Тестирование ПО часто носит динамический характер; запуск ПО для проверки соответствия фактического вывода ожидаемому. Оно также может быть статическим по своей природе; рассмотрение кода и связанной с ним документации .
Тестирование программного обеспечения часто используется для ответа на вопрос: выполняет ли программное обеспечение то, что оно должно делать, и то, что оно должно делать?
Информация, полученная в результате тестирования программного обеспечения, может быть использована для улучшения процесса разработки программного обеспечения. [5] : 41–43
Тестирование программного обеспечения должно следовать «пирамидальному» подходу, при котором большинство ваших тестов должны быть модульными , за ними следуют интеграционные тесты , и, наконец, сквозные (e2e) тесты должны иметь наименьшую долю. [6] [7] [8]
Исследование, проведенное NIST в 2002 году, показало, что ошибки в программном обеспечении обходятся экономике США в 59,5 млрд долларов в год. Более трети этих расходов можно было бы избежать, если бы проводилось лучшее тестирование программного обеспечения. [9] [ dubious – discussion ]
Аутсорсинг тестирования программного обеспечения из-за его стоимости очень распространен, причем предпочтительными странами являются Китай, Филиппины и Индия. [ необходима цитата ]
Гленфорд Дж. Майерс впервые ввел разделение отладки и тестирования в 1979 году. [10] Хотя его внимание было сосредоточено на тестировании на наличие сбоев («Успешный тестовый случай — это тот, который обнаруживает еще не обнаруженную ошибку». [10] : 16 ), он проиллюстрировал желание сообщества разработчиков программного обеспечения отделить фундаментальные действия по разработке, такие как отладка, от проверки.
Тестирование программного обеспечения обычно ориентировано на достижение цели.
Тестирование программного обеспечения обычно включает в себя обработку ошибок программного обеспечения — дефектов в коде , которые приводят к нежелательным результатам. [11] : 31 Ошибки, как правило, замедляют ход тестирования и требуют помощи программиста для отладки и исправления.
Не все дефекты вызывают сбой. Например, дефект в мертвом коде не будет считаться сбоем.
Дефект, который не приводит к отказу в определенный момент времени, может позже возникнуть из-за изменений в окружающей среде. Примерами изменений в окружающей среде являются запуск на новом компьютерном оборудовании , изменения в данных и взаимодействие с другим программным обеспечением. [12]
Один дефект может привести к появлению нескольких признаков неисправности.
Тестирование программного обеспечения может включать пробел в требованиях — упущение в проекте требования. [5] : 426 Пробелы в требованиях часто могут быть нефункциональными требованиями, такими как тестируемость , масштабируемость , удобство обслуживания , производительность и безопасность .
Фундаментальным ограничением тестирования программного обеспечения является то, что тестирование при всех комбинациях входных данных и предварительных условий (начальное состояние) нецелесообразно, даже с простым продуктом. [3] : 17–18 [13] Дефекты, которые проявляются в необычных условиях, трудно обнаружить при тестировании. Кроме того, нефункциональные измерения качества (каким оно должно быть по сравнению с тем, что оно должно делать ) — удобство использования , масштабируемость , производительность , совместимость и надежность — могут быть субъективными; то, что представляет достаточную ценность для одного человека, может не иметь ее для другого.
Хотя тестирование для всех возможных входных данных не представляется возможным, тестирование может использовать комбинаторику для максимального покрытия при минимизации тестов. [14]
Тестирование можно классифицировать по-разному. [15]
Тестирование программного обеспечения можно разделить на уровни в зависимости от того, какая часть программной системы находится в центре внимания при тестировании. [18] [19] [20] [21]
Существует множество подходов к тестированию программного обеспечения. Обзоры , пошаговые инструкции или инспекции называются статическим тестированием, тогда как выполнение запрограммированного кода с заданным набором тестовых случаев называется динамическим тестированием . [23] [24]
Статическое тестирование часто неявное, как вычитка, плюс когда программные инструменты/текстовые редакторы проверяют структуру исходного кода или компиляторы (прекомпиляторы) проверяют синтаксис и поток данных как статический анализ программы . Динамическое тестирование происходит, когда запускается сама программа. Динамическое тестирование может начинаться до того, как программа будет завершена на 100%, чтобы протестировать определенные разделы кода и применяются к дискретным функциям или модулям. [23] [24] Типичные методы для этого — либо использование заглушек /драйверов, либо выполнение из среды отладчика . [24]
Статическое тестирование включает в себя проверку , тогда как динамическое тестирование также включает в себя проверку . [24]
Пассивное тестирование означает проверку поведения системы без какого-либо взаимодействия с программным продуктом. В отличие от активного тестирования, тестировщики не предоставляют никаких тестовых данных, а просматривают системные журналы и трассировки. Они ищут шаблоны и определенное поведение, чтобы принять какие-то решения. [25] Это связано с проверкой автономного выполнения и анализом журналов .
Тип стратегии тестирования, которая будет выполнена, зависит от того, следует ли определять тесты, которые будут применяться к IUT, до начала выполнения плана тестирования (предварительное тестирование [28] ), или каждый ввод, который будет применяться к IUT, может динамически зависеть от выходных данных, полученных в ходе применения предыдущих тестов (адаптивное тестирование [29] [30] ).
Тестирование программного обеспечения часто можно разделить на «белый ящик» и «черный ящик». Эти два подхода используются для описания точки зрения, которую тестер занимает при разработке тестовых случаев. Гибридный подход, называемый «серый ящик», который включает аспекты обоих ящиков, также может применяться к методологии тестирования программного обеспечения. [31] [32]
Тестирование методом белого ящика (также известное как тестирование прозрачного ящика, тестирование стеклянного ящика, тестирование прозрачного ящика и структурное тестирование) проверяет внутренние структуры или работу программы, в отличие от функциональности, доступной конечному пользователю. При тестировании методом белого ящика внутренняя перспектива системы (исходный код), а также навыки программирования используются для разработки тестовых случаев. Тестировщик выбирает входные данные для проверки путей через код и определяет соответствующие выходные данные. [31] [32] Это аналогично тестированию узлов в схеме, например, внутрисхемному тестированию (ICT).
Хотя тестирование методом белого ящика может применяться на уровнях модуля , интеграции и системы процесса тестирования программного обеспечения, обычно оно выполняется на уровне модуля. [33] Оно может тестировать пути внутри модуля, пути между модулями во время интеграции и между подсистемами во время теста на уровне системы. Хотя этот метод проектирования тестов может выявить множество ошибок или проблем, он может не обнаружить нереализованные части спецификации или отсутствующие требования.
Методы, используемые при тестировании методом белого ящика, включают: [32] [34]
Инструменты покрытия кода могут оценить полноту набора тестов, созданного любым методом, включая тестирование черного ящика. Это позволяет команде разработчиков программного обеспечения изучать части системы, которые редко тестируются, и гарантирует, что наиболее важные функциональные точки были протестированы. [35] Покрытие кода как метрика программного обеспечения может быть представлено в процентах для: [31] [35] [36]
100% покрытие операторов гарантирует, что все пути кода или ветви (в терминах потока управления ) выполняются по крайней мере один раз. Это полезно для обеспечения правильной функциональности, но недостаточно, поскольку один и тот же код может обрабатывать разные входные данные правильно или неправильно. [37]
Тестирование методом черного ящика (также известное как функциональное тестирование) описывает проектирование тестовых случаев без знания реализации, без чтения исходного кода. Тестировщики знают только то, что должно делать программное обеспечение, а не то, как оно это делает. [38] Методы тестирования методом черного ящика включают: эквивалентное разбиение , анализ граничных значений , тестирование всех пар , таблицы переходов состояний , тестирование таблиц решений , тестирование методом нечеткого поиска , тестирование на основе моделей , тестирование вариантов использования , исследовательское тестирование и тестирование на основе спецификаций. [31] [32] [36]
Тестирование на основе спецификаций направлено на проверку функциональности программного обеспечения в соответствии с применимыми требованиями. [39] Этот уровень тестирования обычно требует предоставления тестировщику подробных тестовых случаев , который затем может просто проверить, что для заданного ввода выходное значение (или поведение) либо «является», либо «не является» тем же самым, что и ожидаемое значение, указанное в тестовом случае. Тестовые случаи строятся вокруг спецификаций и требований, т. е. того, что приложение должно делать. Оно использует внешние описания программного обеспечения, включая спецификации, требования и проекты, для получения тестовых случаев. Эти тесты могут быть функциональными или нефункциональными , хотя обычно функциональными. Тестирование на основе спецификаций может быть необходимо для обеспечения правильной функциональности, но его недостаточно для защиты от сложных или высокорисковых ситуаций. [40]
Тестирование методом черного ящика может применяться на любом уровне тестирования, хотя обычно не на уровне блока. [33]
Тестирование интерфейса компонентов
Тестирование интерфейса компонента является разновидностью тестирования черного ящика , с акцентом на значениях данных, выходящих за рамки связанных действий компонента подсистемы. [41] Практика тестирования интерфейса компонента может использоваться для проверки обработки данных, передаваемых между различными блоками или компонентами подсистемы, за пределами полного интеграционного тестирования между этими блоками. [42] [43] Передаваемые данные можно рассматривать как «пакеты сообщений», а диапазон или типы данных могут быть проверены на наличие данных, сгенерированных одним блоком, и проверены на достоверность перед передачей в другой блок. Одним из вариантов тестирования интерфейса является ведение отдельного файла журнала передаваемых элементов данных, часто с регистрируемой меткой времени, что позволяет анализировать тысячи случаев передачи данных между блоками в течение дней или недель. Тесты могут включать проверку обработки некоторых экстремальных значений данных, в то время как другие переменные интерфейса передаются как нормальные значения. [42] Необычные значения данных в интерфейсе могут помочь объяснить неожиданную производительность в следующем блоке.
Цель визуального тестирования — предоставить разработчикам возможность изучить, что происходило в момент сбоя программного обеспечения, представив данные таким образом, чтобы разработчик мог легко найти необходимую ему информацию, и чтобы эта информация была выражена наглядно. [44] [45]
В основе визуального тестирования лежит идея о том, что демонстрация проблемы (или провала теста), а не просто ее описание, значительно повышает ясность и понимание. Таким образом, визуальное тестирование требует записи всего процесса тестирования — захвата всего, что происходит в тестовой системе, в видеоформате. Выходные видео дополняются вводом тестировщика в реальном времени через веб-камеру «картинка в картинке» и аудиокомментариями с микрофонов.
Визуальное тестирование дает ряд преимуществ. Качество коммуникации резко повышается, поскольку тестировщики могут показать разработчику проблему (и события, приведшие к ней), а не просто описать ее, и необходимость в воспроизведении сбоев теста во многих случаях отпадет. Разработчик получит все необходимые ему доказательства сбоя теста и сможет вместо этого сосредоточиться на причине сбоя и способах его устранения.
Тестирование ad hoc и исследовательское тестирование являются важными методологиями проверки целостности программного обеспечения, поскольку они требуют меньше времени на подготовку для внедрения, в то время как важные ошибки могут быть быстро обнаружены. [46] При тестировании ad hoc, когда тестирование происходит импровизированным экспромтом, способность тестировщика(ов) основывать тестирование на документированных методах, а затем импровизировать вариации этих тестов может привести к более строгой проверке исправлений дефектов. [46] Однако, если не поддерживается строгое документирование процедур, одним из ограничений тестирования ad hoc является отсутствие повторяемости. [46]
Тестирование методом серого ящика (американское написание: gray-box testing) подразумевает использование знаний о внутренних структурах данных и алгоритмах для целей проектирования тестов при выполнении этих тестов на уровне пользователя или черного ящика. Тестировщик часто будет иметь доступ как к «исходному коду, так и к исполняемому двоичному файлу». [47] Тестирование методом серого ящика может также включать обратную разработку (с использованием динамического анализа кода) для определения, например, граничных значений или сообщений об ошибках. [47] Манипулирование входными данными и форматирование выходных данных не квалифицируются как тестирование методом серого ящика, поскольку входные и выходные данные явно находятся за пределами «черного ящика», который мы называем тестируемой системой. Это различие особенно важно при проведении интеграционного тестирования между двумя модулями кода, написанными двумя разными разработчиками, где для теста открыты только интерфейсы.
Зная основные концепции того, как работает программное обеспечение, тестер делает более обоснованный выбор тестирования при тестировании программного обеспечения извне. Обычно тестеру серого ящика разрешается настраивать изолированную среду тестирования с такими действиями, как заполнение базы данных . Тестер может наблюдать за состоянием тестируемого продукта после выполнения определенных действий, таких как выполнение операторов SQL в отношении базы данных, а затем выполнение запросов, чтобы убедиться, что ожидаемые изменения были отражены. Тестирование серого ящика реализует интеллектуальные тестовые сценарии, основанные на ограниченной информации. Это будет особенно применимо к обработке типов данных, обработке исключений и т. д. [48]
С появлением концепции тестирования методом серого ящика это «произвольное различие» между тестированием методом черного и белого ящика несколько сошло на нет. [33]
Большинство систем программного обеспечения имеют процедуры установки, которые необходимы, прежде чем их можно будет использовать по их основному назначению. Тестирование этих процедур для достижения установленной системы программного обеспечения, которая может быть использована, известно как тестирование установки . [49] : 139 Эти процедуры могут включать в себя полные или частичные обновления и процессы установки/удаления.
Распространенной причиной сбоя программного обеспечения (реального или предполагаемого) является его несовместимость с другим прикладным программным обеспечением , операционными системами (или версиями операционной системы , старыми или новыми) или целевыми средами, которые сильно отличаются от оригинала (например, терминал или приложение с графическим интерфейсом пользователя , предназначенное для запуска на рабочем столе, теперь должны стать веб-приложением , которое должно отображаться в веб-браузере ). Например, в случае отсутствия обратной совместимости это может произойти из-за того, что программисты разрабатывают и тестируют программное обеспечение только в последней версии целевой среды, которую могут использовать не все пользователи. Это приводит к непреднамеренным последствиям, когда последняя работа может не работать в более ранних версиях целевой среды или на старом оборудовании, которое более ранние версии целевой среды могли использовать. Иногда такие проблемы можно устранить путем упреждающего абстрагирования функциональности операционной системы в отдельный программный модуль или библиотеку .
Проверка на работоспособность определяет, целесообразно ли продолжать дальнейшие испытания.
Тестирование дыма состоит из минимальных попыток работы программного обеспечения, призванных определить, есть ли какие-либо базовые проблемы, которые могут помешать его работе. Такие тесты можно использовать в качестве теста проверки сборки .
Регрессионное тестирование фокусируется на поиске дефектов после того, как произошло крупное изменение кода. В частности, оно стремится обнаружить регрессии программного обеспечения , как ухудшенные или потерянные функции, включая старые ошибки, которые вернулись. Такие регрессии происходят всякий раз, когда функциональность программного обеспечения, которая ранее работала правильно, перестает работать так, как предполагалось. Обычно регрессии происходят как непреднамеренное следствие изменений программы, когда недавно разработанная часть программного обеспечения сталкивается с ранее существующим кодом. Регрессионное тестирование, как правило, является крупнейшим тестовым усилием в коммерческой разработке программного обеспечения [50] из-за проверки многочисленных деталей в предыдущих функциях программного обеспечения, и даже новое программное обеспечение может быть разработано с использованием некоторых старых тестовых случаев для тестирования частей нового дизайна, чтобы убедиться, что предыдущая функциональность все еще поддерживается.
Обычные методы регрессионного тестирования включают повторный запуск предыдущих наборов тестовых случаев и проверку того, не возникли ли повторно ранее исправленные ошибки. Глубина тестирования зависит от фазы в процессе выпуска и риска добавленных функций. Они могут быть либо полными, для изменений, добавленных в конце выпуска или считающихся рискованными, либо очень поверхностными, состоящими из положительных тестов для каждой функции, если изменения вносятся в начале выпуска или считаются малорискованными.
Приемочное тестирование — это тестирование на уровне системы, призванное гарантировать, что программное обеспечение соответствует ожиданиям клиентов. [51] [52] [53] [54]
Приемочные испытания могут проводиться как часть процесса передачи между любыми двумя фазами разработки. [ необходима ссылка ]
Тесты часто группируются по этим уровням в зависимости от того, где они выполняются в процессе разработки программного обеспечения, или по уровню специфичности теста. [54]
Иногда UAT выполняется заказчиком в его среде и на его собственном оборудовании.
OAT используется для проведения эксплуатационной готовности (предварительного выпуска) продукта, услуги или системы как части системы управления качеством . OAT — это распространенный тип нефункционального тестирования программного обеспечения, используемый в основном в проектах по разработке и обслуживанию программного обеспечения . Этот тип тестирования фокусируется на эксплуатационной готовности системы к поддержке или к включению ее в производственную среду. Поэтому его также называют тестированием эксплуатационной готовности (ORT) или тестированием эксплуатационной готовности и обеспечения (OR&A). Функциональное тестирование в рамках OAT ограничивается теми тестами, которые требуются для проверки нефункциональных аспектов системы.
Кроме того, тестирование программного обеспечения должно гарантировать, что переносимость системы, а также ее работа в соответствии с ожиданиями не повредит или частично не испортит ее операционную среду или не приведет к неработоспособности других процессов в этой среде. [55]
Контрактное приемочное тестирование выполняется на основе критериев приемки контракта, определенных во время соглашения о контракте, в то время как нормативное приемочное тестирование выполняется на основе соответствующих правил для программного продукта. Оба эти теста могут быть выполнены пользователями или независимыми тестерами. Нормативное приемочное тестирование иногда включает в себя проверку результатов тестирования регулирующими органами. [54]
Альфа-тестирование — это имитация или фактическое эксплуатационное тестирование потенциальными пользователями/клиентами или независимой группой тестирования на сайте разработчиков. Альфа-тестирование часто применяется для готового программного обеспечения как форма внутреннего приемочного тестирования перед тем, как программное обеспечение переходит на бета-тестирование. [56]
Бета-тестирование следует за альфа-тестированием и может считаться формой внешнего пользовательского приемочного тестирования . Версии программного обеспечения, известные как бета-версии , выпускаются для ограниченной аудитории за пределами команды программистов, известной как бета-тестеры. Программное обеспечение выпускается для групп людей, чтобы дальнейшее тестирование могло гарантировать, что продукт имеет мало ошибок или багов . Бета-версии могут быть доступны для широкой публики, чтобы увеличить поле обратной связи до максимального числа будущих пользователей и предоставить ценность раньше, в течение длительного или даже неопределенного периода времени ( бессрочная бета-версия ). [57]
Функциональное тестирование относится к действиям, которые проверяют определенное действие или функцию кода. Обычно они находятся в документации по требованиям к коду, хотя некоторые методологии разработки работают с вариантами использования или историями пользователей. Функциональные тесты, как правило, отвечают на вопрос «может ли пользователь сделать это» или «работает ли эта конкретная функция».
Нефункциональное тестирование относится к аспектам программного обеспечения, которые могут не быть связаны с определенной функцией или действием пользователя, например, масштабируемостью или другой производительностью , поведением при определенных ограничениях или безопасностью . Тестирование определит точку разрыва, точку, в которой крайности масштабируемости или производительности приводят к нестабильному выполнению. Нефункциональные требования, как правило, отражают качество продукта, особенно в контексте перспективы пригодности его пользователей.
Непрерывное тестирование — это процесс выполнения автоматизированных тестов в рамках конвейера поставки программного обеспечения для получения немедленной обратной связи по бизнес-рискам, связанным с кандидатом на выпуск программного обеспечения. [58] [59] Непрерывное тестирование включает в себя проверку как функциональных , так и нефункциональных требований ; область тестирования простирается от проверки восходящих требований или пользовательских историй до оценки системных требований, связанных с общими бизнес-целями. [60] [61]
Деструктивное тестирование пытается вызвать сбой программного обеспечения или подсистемы. Оно проверяет, что программное обеспечение функционирует должным образом, даже если оно получает недопустимые или неожиданные входные данные, тем самым устанавливая надежность процедур проверки входных данных и управления ошибками. [ требуется ссылка ] Введение сбоев программного обеспечения в форме фаззинга является примером тестирования сбоев. Различные коммерческие нефункциональные инструменты тестирования связаны со страницей введения сбоев программного обеспечения ; также доступно множество инструментов с открытым исходным кодом и бесплатных программных средств, которые выполняют деструктивное тестирование.
Тестирование производительности обычно выполняется для определения того, как система или подсистема работает с точки зрения отзывчивости и стабильности при определенной рабочей нагрузке. Оно также может служить для исследования, измерения, проверки или верификации других качественных атрибутов системы, таких как масштабируемость, надежность и использование ресурсов.
Нагрузочное тестирование в первую очередь касается проверки того, может ли система продолжать работать при определенной нагрузке, будь то большие объемы данных или большое количество пользователей . Это обычно называется масштабируемостью программного обеспечения . Связанная с этим деятельность по нагрузочному тестированию, выполняемая как нефункциональная деятельность, часто называется тестированием на выносливость . Объемное тестирование — это способ проверки функций программного обеспечения, даже когда определенные компоненты (например, файл или база данных) радикально увеличиваются в размере. Стресс-тестирование — это способ проверки надежности при неожиданных или редких рабочих нагрузках. Тестирование стабильности (часто называемое нагрузочным или выносливым тестированием) проверяет, может ли программное обеспечение непрерывно хорошо функционировать в течение приемлемого периода или выше.
Мало кто согласен с тем, каковы конкретные цели тестирования производительности. Термины «нагрузочное тестирование», «тестирование производительности», «тестирование масштабируемости » и «объемное тестирование» часто используются как взаимозаменяемые.
Системы программного обеспечения реального времени имеют строгие временные ограничения. Для проверки соблюдения временных ограничений используется тестирование в реальном времени .
Тестирование удобства использования заключается в проверке того, является ли пользовательский интерфейс простым в использовании и понятным. Оно касается в основном использования приложения. Это не тот тип тестирования, который можно автоматизировать; нужны реальные пользователи-люди, за которыми будут наблюдать опытные дизайнеры пользовательского интерфейса .
Тестирование доступности проводится для того, чтобы убедиться, что программное обеспечение доступно для лиц с ограниченными возможностями. Некоторые из распространенных тестов доступности веб-сайтов:
Тестирование безопасности необходимо для программного обеспечения, обрабатывающего конфиденциальные данные, чтобы предотвратить вторжение в систему со стороны хакеров .
Международная организация по стандартизации (ИСО) определяет это как «тип тестирования, проводимого для оценки степени защиты тестового элемента, а также связанных с ним данных и информации, с тем, чтобы неавторизованные лица или системы не могли использовать, читать или изменять их, а авторизованным лицам или системам не было отказано в доступе к ним». [62]
Тестирование на интернационализацию и локализацию подтверждает, что программное обеспечение может использоваться с различными языками и географическими регионами. Процесс псевдолокализации используется для проверки возможности перевода приложения на другой язык и облегчает определение того, когда процесс локализации может внести новые ошибки в продукт.
Тестирование глобализации проверяет, что программное обеспечение адаптировано к новой культуре, например, к разным валютам или часовым поясам. [63]
Фактический перевод на человеческие языки также должен быть проверен. Возможные неудачи локализации и глобализации включают:
Тестирование разработки — это процесс разработки программного обеспечения, который включает синхронизированное применение широкого спектра стратегий предотвращения и обнаружения дефектов с целью снижения рисков, времени и затрат на разработку программного обеспечения. Оно выполняется разработчиком или инженером программного обеспечения на этапе построения жизненного цикла разработки программного обеспечения. Тестирование разработки направлено на устранение ошибок построения до того, как код будет передан на другое тестирование; эта стратегия направлена на повышение качества конечного программного обеспечения, а также эффективности всего процесса разработки.
В зависимости от ожиданий организации в отношении разработки программного обеспечения, тестирование разработки может включать статический анализ кода , анализ потока данных, анализ метрик, экспертную оценку кода, модульное тестирование, анализ покрытия кода, прослеживаемость и другие методы тестирования программного обеспечения.
A/B-тестирование — это метод проведения контролируемого эксперимента для определения того, является ли предлагаемое изменение более эффективным, чем текущий подход. Клиенты направляются либо к текущей версии (контроль) функции, либо к измененной версии (обработка), и собираются данные для определения того, какая версия лучше подходит для достижения желаемого результата.
Параллельное или параллельное тестирование оценивает поведение и производительность программного обеспечения и систем, использующих параллельные вычисления , как правило, в нормальных условиях использования. Типичные проблемы, которые выявляет этот тип тестирования, — это взаимоблокировки, состояния гонки и проблемы с общей памятью/обработкой ресурсов.
В тестировании программного обеспечения тестирование соответствия проверяет, что продукт работает в соответствии с указанными стандартами. Например, компиляторы тщательно тестируются, чтобы определить, соответствуют ли они признанному стандарту для этого языка.
Создание ожидаемого вывода, будь то сравнение данных текста или снимков экрана пользовательского интерфейса, [3] : 195 иногда называют тестированием снимками или тестированием Golden Master. В отличие от многих других форм тестирования, оно не может автоматически обнаруживать сбои и вместо этого требует, чтобы человек оценивал вывод на предмет несоответствий.
Тестирование свойств — это метод тестирования, при котором вместо утверждения, что определенные входные данные производят определенные ожидаемые выходные данные, практикующий случайным образом генерирует множество входных данных, запускает программу на всех из них и утверждает истинность некоторого «свойства», которое должно быть истинным для каждой пары входных данных и выходных данных. Например, каждый выходной сигнал функции сериализации должен быть принят соответствующей функцией десериализации, а каждый выходной сигнал функции сортировки должен быть монотонно возрастающим списком, содержащим точно такие же элементы, как и его входные данные.
Библиотеки тестирования свойств позволяют пользователю контролировать стратегию, с помощью которой конструируются случайные входные данные, чтобы обеспечить охват вырожденных случаев или входных данных, содержащих определенные шаблоны, необходимые для полной проверки аспектов тестируемой реализации.
Тестирование свойств также иногда называют «генеративным тестированием» или «тестированием QuickCheck», поскольку оно было введено и популяризировано библиотекой Haskell QuickCheck . [64]
Метаморфическое тестирование (MT) — это метод тестирования программного обеспечения на основе свойств, который может быть эффективным подходом для решения проблемы тестового оракула и проблемы генерации тестовых случаев. Проблема тестового оракула заключается в сложности определения ожидаемых результатов выбранных тестовых случаев или определения того, согласуются ли фактические результаты с ожидаемыми результатами.
Тестирование VCR, также известное как «тестирование воспроизведения» или «тестирование записи/воспроизведения», представляет собой метод тестирования для повышения надежности и скорости регрессионных тестов, в которых задействован компонент, с которым медленно или ненадежно общаться, часто сторонний API вне контроля тестировщика. Он включает в себя создание записи («кассеты») взаимодействия системы с внешним компонентом, а затем воспроизведение записанных взаимодействий в качестве замены общения с внешней системой при последующих запусках теста.
Эта техника была популяризирована в веб-разработке библиотекой Ruby vcr.
В организации тестировщики могут находиться в отдельной команде от остальной части команды разработчиков ПО или могут быть объединены в одну команду. Тестирование ПО также может выполняться неспециализированными тестировщиками ПО.
В 1980-х годах термин «тестировщик программного обеспечения» стал использоваться для обозначения отдельной профессии.
Известные роли и должности в области тестирования программного обеспечения включают в себя: [65] менеджер по тестированию , руководитель тестирования , аналитик тестирования , разработчик тестов , тестер , разработчик автоматизации и администратор тестирования . [66]
Организации, разрабатывающие программное обеспечение, проводят тестирование по-разному, но существуют общие закономерности. [2]
В каскадной разработке тестирование обычно выполняется после завершения кода, но до отправки продукта заказчику. [67] Такая практика часто приводит к тому, что фаза тестирования используется в качестве буфера проекта для компенсации задержек проекта, тем самым ставя под угрозу время, отведенное на тестирование. [10] : 145–146
Некоторые утверждают, что каскадный процесс позволяет начать тестирование с началом проекта разработки и сделать его непрерывным процессом до завершения проекта. [68]
Гибкая разработка программного обеспечения обычно подразумевает тестирование в процессе написания кода и организацию команд, состоящих как из программистов, так и из тестировщиков, причем члены команды выполняют как программирование, так и тестирование.
Одна из гибких практик, разработка программного обеспечения через тестирование (TDD), представляет собой способ модульного тестирования , при котором тестирование на уровне модулей выполняется во время написания кода продукта. [69] Тестовый код обновляется по мере добавления новых функций и обнаружения условий сбоя (исправления ошибок). Обычно код модульного теста поддерживается вместе с кодом проекта, интегрируется в процесс сборки и запускается в каждой сборке и как часть регрессионного тестирования. Цели этой непрерывной интеграции — поддержка разработки и сокращение дефектов. [70] [69]
Даже в организациях, где команды разделены на функции программирования и тестирования, многие часто заставляют программистов выполнять модульное тестирование . [71]
Пример ниже является общим для каскадной разработки. Те же действия обычно встречаются в других моделях разработки, но могут быть описаны по-разному.
Тестирование программного обеспечения используется совместно с проверкой и валидацией : [72]
Термины верификация и валидация обычно используются взаимозаменяемо в отрасли; также часто можно увидеть эти два термина с противоречивыми определениями. Согласно стандартному глоссарию терминологии программной инженерии IEEE : [11] : 80–81
И, согласно стандарту ISO 9000:
Противоречие вызвано использованием понятий «требования» и «указанные требования», но в разном значении.
В случае стандартов IEEE указанные требования, упомянутые в определении валидации, представляют собой набор проблем, потребностей и желаний заинтересованных сторон, которые программное обеспечение должно решать и удовлетворять. Такие требования документируются в спецификации требований к программному обеспечению (SRS). А продукты, упомянутые в определении верификации, являются выходными артефактами каждой фазы процесса разработки программного обеспечения. Эти продукты, по сути, являются спецификациями, такими как спецификация архитектурного проекта, подробная спецификация проекта и т. д. SRS также является спецификацией, но ее нельзя проверить (по крайней мере, не в том смысле, который используется здесь, подробнее об этом ниже).
Но для ISO 9000 указанные требования представляют собой набор спецификаций, как только что было упомянуто выше, которые должны быть проверены. Спецификация, как объяснялось ранее, является продуктом фазы процесса разработки программного обеспечения, которая получает другую спецификацию в качестве входных данных. Спецификация успешно проверена, когда она правильно реализует свою входную спецификацию. Все спецификации могут быть проверены, кроме SRS, поскольку она первая (хотя ее можно проверить). Примеры: Спецификация проектирования должна реализовывать SRS; и артефакты фазы строительства должны реализовывать Спецификацию проектирования.
Итак, если дать этим словам общепринятое определение, то кажущееся противоречие исчезает.
И SRS, и программное обеспечение должны быть проверены. SRS может быть проверен статически, проконсультировавшись с заинтересованными сторонами. Тем не менее, запуск некоторой частичной реализации программного обеспечения или прототипа любого типа (динамическое тестирование) и получение от них положительной обратной связи может еще больше повысить уверенность в том, что SRS сформулирован правильно. С другой стороны, программное обеспечение как конечный и работающий продукт (а не его артефакты и документы, включая исходный код) должно быть проверено динамически с заинтересованными сторонами, запустив программное обеспечение и дав им возможность попробовать его.
Некоторые могут утверждать, что для SRS входными данными являются слова заинтересованных сторон, и, следовательно, валидация SRS — это то же самое, что и верификация SRS. Думать таким образом не рекомендуется, поскольку это только приводит к большей путанице. Лучше думать о верификации как о процессе, включающем формальный и технический входной документ.
В некоторых организациях тестирование программного обеспечения является частью процесса обеспечения качества программного обеспечения (SQA). [3] : 347 В SQA специалисты по процессам разработки программного обеспечения и аудиторы занимаются процессом разработки программного обеспечения, а не только артефактами, такими как документация, код и системы. Они изучают и изменяют сам процесс разработки программного обеспечения , чтобы уменьшить количество ошибок, которые в конечном итоге появляются в поставляемом программном обеспечении: так называемый уровень дефектов. Что составляет приемлемый уровень дефектов, зависит от характера программного обеспечения; видеоигра-симулятор полета будет иметь гораздо более высокую толерантность к дефектам, чем программное обеспечение для настоящего самолета. Хотя существуют тесные связи с SQA, отделы тестирования часто существуют независимо, и в некоторых компаниях может не быть функции SQA. [ необходима цитата ]
Тестирование программного обеспечения — это деятельность по исследованию тестируемого программного обеспечения с целью предоставления заинтересованным сторонам информации, связанной с качеством. В отличие от этого, QA ( гарантия качества ) — это реализация политик и процедур, направленных на предотвращение попадания дефектов к клиентам.
Меры качества включают в себя такие аспекты, как правильность , полнота, безопасность и требования ISO/IEC 9126, такие как возможности, надежность , эффективность , переносимость , ремонтопригодность , совместимость и удобство использования .
Существует ряд часто используемых метрик или мер программного обеспечения, которые помогают определить состояние программного обеспечения или адекватность тестирования.
Процесс тестирования программного обеспечения может производить несколько артефактов . Фактически производимые артефакты являются фактором используемой модели разработки программного обеспечения, заинтересованных сторон и организационных потребностей.
План тестирования — это документ, в котором подробно описывается подход, который будет использоваться для предполагаемых тестовых мероприятий. План может включать такие аспекты, как цели, область применения, процессы и процедуры, требования к персоналу и планы действий в чрезвычайных ситуациях. [51] План тестирования может быть в форме единого плана, включающего все типы тестов (например, план приемки или системного тестирования) и соображения по планированию, или он может быть выпущен как главный план тестирования, который предоставляет обзор более чем одного подробного плана тестирования (план плана). [51] В некоторых случаях план тестирования может быть частью широкой « стратегии тестирования », которая документирует общие подходы к тестированию, которая сама по себе может быть главным планом тестирования или даже отдельным артефактом.
Тестовый случай обычно состоит из уникального идентификатора, ссылок на требования из спецификации проекта, предварительных условий, событий, серии шагов (также известных как действия), которые необходимо выполнить, ввода, вывода, ожидаемого результата и фактического результата. Клинически определяемый тестовый случай — это ввод и ожидаемый результат. [74] Это может быть так же кратко, как «для условия x ваш полученный результат равен y», хотя обычно тестовые случаи более подробно описывают входной сценарий и то, какие результаты могут ожидаться. Иногда это может быть серия шагов (но часто шаги содержатся в отдельной процедуре тестирования, которая может быть выполнена для нескольких тестовых случаев в целях экономии), но с одним ожидаемым результатом или ожидаемым исходом. Необязательные поля — это идентификатор тестового случая, шаг теста или номер порядка выполнения, связанные требования, глубина, категория теста, автор и флажки для того, является ли тест автоматизированным и был ли он автоматизирован. Более крупные тестовые случаи могут также содержать состояния или шаги предварительных условий и описания. Тестовый случай также должен содержать место для фактического результата. Эти шаги могут быть сохранены в документе текстового процессора, электронной таблице, базе данных или других общих репозиториях. В системе базы данных вы также можете увидеть результаты прошлых тестов, кто сгенерировал результаты и какая конфигурация системы использовалась для генерации этих результатов. Эти прошлые результаты обычно хранятся в отдельной таблице.
Тестовый сценарий — это процедура или программный код, который воспроизводит действия пользователя. Первоначально этот термин был получен из продукта работы, созданного автоматизированными инструментами регрессионного тестирования. Тестовый случай будет базой для создания тестовых сценариев с использованием инструмента или программы.
В большинстве случаев для тестирования одной и той же функциональности определенной функции используются несколько наборов значений или данных. Все тестовые значения и изменяемые компоненты среды собираются в отдельных файлах и хранятся как тестовые данные. Также полезно предоставлять эти данные клиенту и вместе с продуктом или проектом. Существуют методы генерации тестовых данных.
Программное обеспечение, инструменты, образцы входных и выходных данных, а также конфигурации в совокупности называются тестовым набором .
Тестовый запуск — это набор тестовых случаев или тестовых наборов, которые пользователь выполняет и сравнивает ожидаемые и фактические результаты. После завершения может быть создан отчет или все выполненные тесты.
Существует несколько программ сертификации для поддержки профессиональных устремлений тестировщиков ПО и специалистов по обеспечению качества. Некоторые специалисты утверждают, что область тестирования не готова к сертификации, как упоминалось в разделе о противоречиях.
Некоторые из основных споров, связанных с тестированием программного обеспечения, включают в себя:
Обычно считается, что чем раньше обнаружен дефект, тем дешевле его исправить. В следующей таблице показана стоимость исправления дефекта в зависимости от стадии его обнаружения. [84] Например, если проблема в требованиях обнаружена только после релиза, то ее исправление обойдется в 10–100 раз дороже, чем если бы она уже была обнаружена в ходе проверки требований. С появлением современных методов непрерывного развертывания и облачных сервисов стоимость повторного развертывания и обслуживания может со временем уменьшиться.
Данные, из которых экстраполирована эта таблица, скудны. Лоран Боссавит говорит в своем анализе:
Кривая «более мелких проектов» оказалась получена всего из двух команд студентов первого года обучения, размер выборки настолько мал, что экстраполяция на «более мелкие проекты в целом» совершенно необоснованна. Исследование GTE не объясняет свои данные, кроме того, что они получены из двух проектов, одного большого и одного маленького. Статья, цитируемая по проекту Bell Labs «Safeguard», специально отрицает сбор детальных данных, которые предполагают точки данных Боэма. Исследование IBM (статья Фагана) содержит утверждения, которые, по-видимому, противоречат графику Боэма, и не содержит числовых результатов, которые явно соответствуют его точкам данных.
Бём даже не ссылается на статью по данным TRW, за исключением статьи для «Making Software» в 2010 году, где он ссылается на оригинальную статью 1976 года. Существует большое исследование, проведенное в TRW в подходящее время, чтобы Бём мог его процитировать, но эта статья не содержит тех данных, которые бы подтверждали заявления Бёма. [85]
int f(int x){return x*x-6*x+8;}
f(x)>=0
x=3