stringtranslate.com

Тестирование программного обеспечения

TestingCup – Чемпионат Польши по тестированию ПО, Катовице , май 2016 г.

Тестирование программного обеспечения — это процесс проверки того, соответствует ли программное обеспечение ожиданиям.

Тестирование программного обеспечения может предоставить пользователю или спонсору объективную, независимую информацию о качестве программного обеспечения и риске его сбоя . [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]

Автоматизированное тестирование

В тестировании программного обеспечения автоматизация тестирования — это использование программного обеспечения отдельно от тестируемого программного обеспечения для управления выполнением тестов и сравнения фактических результатов с прогнозируемыми результатами. [16] Автоматизация тестирования может автоматизировать некоторые повторяющиеся, но необходимые задачи в формализованном процессе тестирования, который уже существует, или выполнять дополнительное тестирование, которое было бы трудно выполнить вручную. Автоматизация тестирования имеет решающее значение для непрерывной поставки и непрерывного тестирования . [17]

Уровни

Тестирование программного обеспечения можно разделить на уровни в зависимости от того, какая часть программной системы находится в центре внимания при тестировании. [18] [19] [20] [21]

Модульное тестирование

Модульное тестирование , также известное как компонентное или модульное тестирование, представляет собой форму тестирования программного обеспечения, при которой изолированный исходный код тестируется для проверки ожидаемого поведения. [22]

Интеграционное тестирование

Интеграционное тестирование , также называемое интеграцией и тестированием, сокращенно I&T, представляет собой форму тестирования программного обеспечения, при которой несколько частей программной системы тестируются как единая группа.

Тестирование системы

Системное тестирование , также известное как сквозное (E2E) тестирование, представляет собой тестирование, проводимое на всей программной системе .

Статическое, динамическое и пассивное тестирование

Существует множество подходов к тестированию программного обеспечения. Обзоры , пошаговые инструкции или инспекции называются статическим тестированием, тогда как выполнение запрограммированного кода с заданным набором тестовых случаев называется динамическим тестированием . [23] [24]

Статическое тестирование часто неявное, как вычитка, плюс когда программные инструменты/текстовые редакторы проверяют структуру исходного кода или компиляторы (прекомпиляторы) проверяют синтаксис и поток данных как статический анализ программы . Динамическое тестирование происходит, когда запускается сама программа. Динамическое тестирование может начинаться до того, как программа будет завершена на 100%, чтобы протестировать определенные разделы кода и применяются к дискретным функциям или модулям. [23] [24] Типичные методы для этого — либо использование заглушек /драйверов, либо выполнение из среды отладчика . [24]

Статическое тестирование включает в себя проверку , тогда как динамическое тестирование также включает в себя проверку . [24]

Пассивное тестирование означает проверку поведения системы без какого-либо взаимодействия с программным продуктом. В отличие от активного тестирования, тестировщики не предоставляют никаких тестовых данных, а просматривают системные журналы и трассировки. Они ищут шаблоны и определенное поведение, чтобы принять какие-то решения. [25] Это связано с проверкой автономного выполнения и анализом журналов .

Исследовательский

Исследовательское тестирование — это подход к тестированию программного обеспечения, который кратко описывается как одновременное обучение, разработка и выполнение тестов. Джем Канер , который ввел этот термин в 1984 году, [26] определяет исследовательское тестирование как «стиль тестирования программного обеспечения, который подчеркивает личную свободу и ответственность отдельного тестировщика за постоянную оптимизацию качества его/ее работы путем рассмотрения обучения, связанного с тестированием, разработки, выполнения тестов и интерпретации результатов тестов как взаимодополняющих видов деятельности, которые выполняются параллельно на протяжении всего проекта». [27]

Предварительное тестирование против адаптивного тестирования

Тип стратегии тестирования, которая будет выполняться, зависит от того, следует ли определять тесты, которые будут применяться к IUT, до начала выполнения плана тестирования (предварительное тестирование [28] ), или каждый ввод, который будет применяться к IUT, может динамически зависеть от выходных данных, полученных в ходе применения предыдущих тестов (адаптивное тестирование [29] [30] ).

Черно-белый ящик

Тестирование программного обеспечения часто можно разделить на «белый ящик» и «черный ящик». Эти два подхода используются для описания точки зрения, которую тестер занимает при разработке тестовых случаев. Гибридный подход, называемый «серый ящик», включает аспекты обоих ящиков и может также применяться к методологии тестирования программного обеспечения. [31] [32]

Тестирование методом белого ящика

Диаграмма тестирования «белого ящика»
Диаграмма тестирования «белого ящика»

Тестирование методом белого ящика (также известное как тестирование прозрачного ящика, тестирование стеклянного ящика, тестирование прозрачного ящика и структурное тестирование) проверяет внутренние структуры или работу программы, в отличие от функциональности, доступной конечному пользователю. При тестировании методом белого ящика внутренняя перспектива системы (исходный код), а также навыки программирования используются для разработки тестовых случаев. Тестировщик выбирает входные данные для проверки путей через код и определяет соответствующие выходные данные. [31] [32] Это аналогично тестированию узлов в схеме, например, внутрисхемному тестированию (ICT).

Хотя тестирование методом белого ящика может применяться на уровнях модуля , интеграции и системы процесса тестирования программного обеспечения, обычно оно выполняется на уровне модуля. [33] Оно может тестировать пути внутри модуля, пути между модулями во время интеграции и между подсистемами во время теста на уровне системы. Хотя этот метод проектирования тестов может выявить множество ошибок или проблем, он может не обнаружить нереализованные части спецификации или отсутствующие требования.

Методы, используемые при тестировании методом белого ящика, включают: [32] [34]

Инструменты покрытия кода могут оценить полноту набора тестов, созданного любым методом, включая тестирование черного ящика. Это позволяет команде разработчиков программного обеспечения изучать части системы, которые редко тестируются, и гарантирует, что наиболее важные функциональные точки были протестированы. [35] Покрытие кода как метрика программного обеспечения может быть представлено в виде процента для: [31] [35] [36]

  • Покрытие функций , которое сообщает о выполненных функциях
  • Покрытие оператора , которое сообщает о количестве строк, выполненных для завершения теста.
  • Покрытие решений , которое сообщает о том, были ли выполнены обе ветви теста: True и False.

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  Эти процедуры могут включать в себя полные или частичные обновления и процессы установки/удаления.

  • Пользователь должен выбрать несколько вариантов.
  • Зависимые файлы и библиотеки должны быть выделены, загружены или найдены.
  • Должны быть указаны допустимые конфигурации оборудования.
  • Программным системам может потребоваться подключение для подключения к другим программным системам. [49] : 145 

Тестирование совместимости

Распространенной причиной сбоя программного обеспечения (реального или предполагаемого) является отсутствие его совместимости с другим прикладным программным обеспечением , операционными системами (или версиями операционной системы , старыми или новыми) или целевыми средами, которые сильно отличаются от оригинала (например, терминал или приложение с графическим интерфейсом пользователя , предназначенное для запуска на рабочем столе , теперь должны стать веб-приложением , которое должно отображаться в веб-браузере ). Например, в случае отсутствия обратной совместимости это может произойти из-за того, что программисты разрабатывают и тестируют программное обеспечение только в последней версии целевой среды, которую могут использовать не все пользователи. Это приводит к непреднамеренным последствиям, когда последняя работа может не работать в более ранних версиях целевой среды или на старом оборудовании, которое более ранние версии целевой среды могли использовать. Иногда такие проблемы можно устранить путем упреждающего абстрагирования функциональности операционной системы в отдельный программный модуль или библиотеку .

Тестирование на дым и санитарную безопасность

Проверка на работоспособность определяет, целесообразно ли продолжать дальнейшие испытания.

Тестирование дыма состоит из минимальных попыток работы программного обеспечения, призванных определить, есть ли какие-либо базовые проблемы, которые могут помешать его работе. Такие тесты можно использовать в качестве теста проверки сборки .

Регрессионное тестирование

Регрессионное тестирование фокусируется на поиске дефектов после того, как произошло крупное изменение кода. В частности, оно стремится обнаружить регрессии программного обеспечения , как ухудшенные или потерянные функции, включая старые ошибки, которые вернулись. Такие регрессии происходят всякий раз, когда функциональность программного обеспечения, которая ранее работала правильно, перестает работать так, как предполагалось. Обычно регрессии происходят как непреднамеренное следствие изменений программы, когда недавно разработанная часть программного обеспечения сталкивается с ранее существующим кодом. Регрессионное тестирование, как правило, является крупнейшим усилием тестирования в коммерческой разработке программного обеспечения [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-тестирование

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] В некоторых случаях план тестирования может быть частью широкой « стратегии тестирования », которая документирует общие подходы к тестированию, которая сама по себе может быть главным планом тестирования или даже отдельным артефактом.

Матрица прослеживаемости

В разработке программного обеспечения матрица прослеживаемости (TM) [73] : 244  представляет собой документ, обычно в форме таблицы, используемый для определения полноты взаимосвязи путем сопоставления любых двух базовых документов с использованием сравнения отношений «многие ко многим». [73] : 3–22  Она часто используется с требованиями высокого уровня (они часто состоят из маркетинговых требований) и подробными требованиями к продукту для сопоставления частей высокоуровневого проекта , детального проекта, плана тестирования и тестовых случаев .

Тестовый случай

Тестовый случай обычно состоит из уникального идентификатора, ссылок на требования из спецификации проекта, предварительных условий, событий, серии шагов (также известных как действия), которые необходимо выполнить, ввода, вывода, ожидаемого результата и фактического результата. Клинически определяемый тестовый случай — это ввод и ожидаемый результат. [74] Это может быть так же кратко, как «для условия x ваш полученный результат равен y», хотя обычно тестовые случаи более подробно описывают входной сценарий и то, какие результаты могут ожидаться. Иногда это может быть серия шагов (но часто шаги содержатся в отдельной процедуре тестирования, которая может быть выполнена для нескольких тестовых случаев в целях экономии), но с одним ожидаемым результатом или ожидаемым исходом. Необязательные поля — это идентификатор тестового случая, шаг теста или номер порядка выполнения, связанные требования, глубина, категория теста, автор и флажки для того, автоматизируется ли тест и был ли он автоматизирован. Более крупные тестовые случаи могут также содержать состояния или шаги предварительных условий и описания. Тестовый случай также должен содержать место для фактического результата. Эти шаги могут быть сохранены в документе текстового процессора, электронной таблице, базе данных или других общих репозиториях. В системе базы данных вы также можете увидеть результаты прошлых тестов, кто сгенерировал результаты и какая конфигурация системы использовалась для генерации этих результатов. Эти прошлые результаты обычно хранятся в отдельной таблице.

Тестовый сценарий

Тестовый сценарий — это процедура или программный код, который воспроизводит действия пользователя. Первоначально этот термин был получен из продукта работы, созданного автоматизированными инструментами регрессионного тестирования. Тестовый случай будет базой для создания тестовых сценариев с использованием инструмента или программы.

Тестовый набор

В разработке программного обеспечения тестовый набор , менее известный как набор проверки, представляет собой набор тестовых случаев , которые предназначены для использования при тестировании программного обеспечения, чтобы показать, что оно имеет некоторый заданный набор поведений. [75] Тестовый набор часто содержит подробные инструкции или цели для каждого набора тестовых случаев и информацию о конфигурации системы, которая будет использоваться во время тестирования. Группа тестовых случаев может также содержать предварительные состояния или шаги и описания следующих тестов.

Испытательное приспособление или данные испытаний

В большинстве случаев для тестирования одной и той же функциональности определенной функции используются несколько наборов значений или данных. Все тестовые значения и изменяемые компоненты среды собираются в отдельных файлах и хранятся как тестовые данные. Также полезно предоставлять эти данные клиенту и вместе с продуктом или проектом. Существуют методы генерации тестовых данных.

Тестовая проводка

Программное обеспечение, инструменты, образцы входных и выходных данных, а также конфигурации в совокупности называются тестовым набором .

Тестовый запуск

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

Сертификаты

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

Противоречие

Некоторые из основных споров, связанных с тестированием программного обеспечения, включают в себя:

Agile против традиционного
Должны ли тестировщики учиться работать в условиях неопределенности и постоянных изменений или им следует стремиться к «зрелости» процесса ? Движение за гибкое тестирование получило растущую популярность с начала 2000-х годов, в основном в коммерческих кругах, [76] [77] тогда как поставщики программного обеспечения для государственных и военных [78] организаций используют эту методологию, а также традиционные модели «тест-последний» (например, в модели «водопад» ). [ требуется ссылка ]
Ручное и автоматизированное тестирование
Некоторые авторы полагают, что автоматизация тестирования настолько дорога по сравнению с ее ценностью, что ее следует использовать экономно. [79] Автоматизацию тестирования можно рассматривать как способ сбора и внедрения требований. Как правило, чем больше система и чем выше ее сложность, тем выше окупаемость инвестиций в автоматизацию тестирования. Кроме того, инвестиции в инструменты и экспертные знания могут быть амортизированы в течение нескольких проектов при правильном уровне обмена знаниями в организации.
Оправдано ли существование стандарта тестирования программного обеспечения ISO 29119 ?
Значительная оппозиция сформировалась в рядах школы контекстно-ориентированного тестирования программного обеспечения по поводу стандарта ISO 29119. Профессиональные ассоциации тестирования, такие как Международное общество по тестированию программного обеспечения, пытались добиться отмены стандарта. [80] [81]
Некоторые специалисты заявляют, что испытательная площадка не готова к сертификации
[82] Ни одна предлагаемая сейчас сертификация на самом деле не требует от заявителя продемонстрировать свою способность тестировать программное обеспечение. Ни одна сертификация не основана на общепринятом наборе знаний. Сертификация сама по себе не может измерить производительность человека, его навыки или практические знания и не может гарантировать его компетентность или профессионализм как тестировщика. [83]
Исследования, используемые для демонстрации относительной стоимости устранения дефектов
Существуют противоположные взгляды на применимость исследований, показывающих относительную стоимость устранения дефектов в зависимости от их появления и обнаружения. Например:

Обычно считается, что чем раньше обнаружен дефект, тем дешевле его исправить. В следующей таблице показана стоимость исправления дефекта в зависимости от стадии его обнаружения. [84] Например, если проблема в требованиях обнаружена только после релиза, то ее исправление обойдется в 10–100 раз дороже, чем если бы она уже была обнаружена в ходе проверки требований. С появлением современных методов непрерывного развертывания и облачных сервисов стоимость повторного развертывания и обслуживания может со временем уменьшиться.

Данные, из которых экстраполирована эта таблица, скудны. Лоран Боссавит говорит в своем анализе:

Кривая «более мелких проектов» оказалась получена всего из двух команд студентов первого года обучения, размер выборки настолько мал, что экстраполяция на «более мелкие проекты в целом» совершенно необоснованна. Исследование GTE не объясняет свои данные, за исключением того, что они получены из двух проектов, одного большого и одного маленького. В статье, цитируемой по проекту Bell Labs «Safeguard», прямо отрицается сбор детальных данных, которые предполагают точки данных Боэма. Исследование IBM (статья Фагана) содержит утверждения, которые, по-видимому, противоречат графику Боэма, и нет числовых результатов, которые явно соответствуют его точкам данных.

Бём даже не ссылается на статью по данным TRW, за исключением статьи для «Making Software» в 2010 году, где он ссылается на оригинальную статью 1976 года. Существует большое исследование, проведенное в TRW в подходящее время, чтобы Бём мог его процитировать, но эта статья не содержит тех данных, которые бы подтверждали заявления Бёма. [85]

Смотрите также

Ссылки

  1. ^ Kaner, Cem (17 ноября 2006 г.). Исследовательское тестирование (PDF) . Ежегодная всемирная конференция по тестированию программного обеспечения Института обеспечения качества. Орландо, Флорида . Получено 22 ноября 2014 г.
  2. ^ ab Pan, Jiantao (весна 1999 г.). «Тестирование программного обеспечения» (курсовая работа). Университет Карнеги-Меллона . Получено 21 ноября 2017 г.
  3. ^ abcd Канер, Джем ; Фальк, Джек; Нгуен, Хунг Куок (1999). Тестирование компьютерного программного обеспечения (2-е изд.). Нью-Йорк: John Wiley and Sons. ISBN 978-0-471-35846-6.
  4. ^ Leitner, Andreas; Ciupa, Ilinca; Oriol, Manuel; Meyer, Bertrand ; Fiva, Arno (сентябрь 2007 г.). Contract Driven Development = Test Driven Development – ​​Writing Test Cases (PDF) . ESEC/FSE'07: Европейская конференция по программной инженерии и симпозиум ACM SIGSOFT по основам программной инженерии 2007. Дубровник, Хорватия . Получено 8 декабря 2017 г.
  5. ^ ab Kolawa, Adam; Huizinga, Dorota (2007). Автоматизированное предотвращение дефектов: лучшие практики в управлении программным обеспечением. Wiley-IEEE Computer Society Press. ISBN 978-0-470-04212-0.
  6. ^ Кон, Майк (2009). Успех с Agile: разработка программного обеспечения с использованием Scrum . Addison-Wesley Professional. ISBN 978-0321579362.
  7. ^ Молина, Алессандро (2021). Создание программного обеспечения на основе тестирования с помощью Python: написание тестовых наборов, масштабируемых в соответствии с потребностями и сложностью ваших приложений, с использованием Python и PyTest . Packt Publishing. ISBN 978-1838642655.
  8. ^ Фернандес да Коста, Лукас (2021). Тестирование приложений JavaScript . Мэннинг. ISBN 978-1617297915.
  9. ^ "Экономические последствия неадекватной инфраструктуры для тестирования программного обеспечения" (PDF) . Национальный институт стандартов и технологий . Май 2002 г. Получено 19 декабря 2017 г.
  10. ^ abc Майерс, Гленфорд Дж. (1979). Искусство тестирования программного обеспечения. John Wiley and Sons. ISBN 978-0-471-04328-7.
  11. ^ ab IEEE Стандартный глоссарий терминологии программной инженерии , IEEE, 1990, doi :10.1109/IEEESTD.1990.101064, ISBN 978-1-55937-067-7
  12. ^ "Certified Tester Foundation Level Syllabus". International Software Testing Qualifications Board . 31 марта 2011 г. Раздел 1.1.2. Архивировано из оригинала (pdf) 28 октября 2017 г. Получено 15 декабря 2017 г.
  13. ^ "Certified Tester Foundation Level Syllabus" (PDF) . International Software Testing Qualifications Board . 1 июля 2005 г. Принцип 2, Раздел 1.3. Архивировано из оригинала (PDF) 17 декабря 2008 г. Получено 15 декабря 2017 г.
  14. ^ Рамлер, Рудольф; Копецки, Теодорих; Платц, Вольфганг (17 апреля 2012 г.). Комбинаторное проектирование тестов в тестовом наборе TOSCA: извлеченные уроки и практические выводы . Пятая международная конференция IEEE по тестированию и валидации программного обеспечения (ICST). Монреаль, Квебек, Канада. doi :10.1109/ICST.2012.142.
  15. ^ Канер, Джем; Бах, Джеймс; Петтикорд, Брет (2001). Уроки, извлеченные из тестирования программного обеспечения: контекстно-ориентированный подход . Wiley. С. 31–43. ISBN 978-0-471-08112-8.
  16. ^ Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: лучшие практики в управлении программным обеспечением . Wiley-IEEE Computer Society Press. стр. 74. ISBN 978-0-470-04212-0.
  17. ^ О'Коннор, Рори В.; Аккая, Марие Умай; Кеманечи, Керем; Йылмаз, Мурат; Пот, Александр; Месснарц, Ричард (15 октября 2015 г.). Улучшение процессов систем, программного обеспечения и услуг: 22-я Европейская конференция, EuroSPI 2015, Анкара, Турция, 30 сентября — 2 октября 2015 г. Материалы. Спрингер. ISBN 978-3-319-24647-5.
  18. ^ Бурк, Пьер; Фэрли, Ричард Э., ред. (2014). "Глава 5". Руководство по своду знаний по программной инженерии . 3.0. IEEE Computer Society. ISBN 978-0-7695-5166-1. Получено 2 января 2018 г. .
  19. ^ Бурк, П.; Фэрли, Р.Д., ред. (2014). "Глава 4: Тестирование программного обеспечения" (PDF) . SWEBOK v3.0: Руководство по своду знаний по программной инженерии . IEEE. стр. 4–1–4–17. ISBN 978-0-7695-5166-1. Архивировано из оригинала (PDF) 19 июня 2018 г. . Получено 13 июля 2018 г. .
  20. ^ Дули, Дж. (2011). Разработка программного обеспечения и профессиональная практика. APress. С. 193–4. ISBN 978-1-4302-3801-0.
  21. ^ Вигерс, К. (2013). Создание культуры разработки программного обеспечения. Addison-Wesley. С. 211–2. ISBN 978-0-13-348929-3.
  22. ^ Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: лучшие практики в управлении программным обеспечением . Wiley-IEEE Computer Society Press. стр. 75. ISBN 978-0-470-04212-0.
  23. ^ Аб Грэм, Д.; Ван Винендал, Э.; Эванс, И. (2008). Основы тестирования программного обеспечения. Cengage Обучение. стр. 57–58. ISBN 978-1-84480-989-9.
  24. ^ abcd Oberkampf, WL; Roy, CJ (2010). Верификация и валидация в научных вычислениях. Cambridge University Press. С. 154–5. ISBN 978-1-139-49176-1.
  25. ^ Ли, Д.; Нетравали, А. Н.; Сабнани, К. К.; Сугла, Б.; Джон, А. (1997). «Пассивное тестирование и приложения для управления сетями». Труды Международной конференции по сетевым протоколам 1997 г. IEEE Comput. Soc. стр. 113–122. doi :10.1109/icnp.1997.643699. ISBN 978-0-8186-8061-8. S2CID  42596126.
  26. ^ Джем Канер, «Учебное пособие по исследовательскому тестированию», архив 2013-06-12 на Wayback Machine , стр. 2
  27. ^ Джем Канер, Учебное пособие по исследовательскому тестированию. Архивировано 12 июня 2013 г. на Wayback Machine , стр. 36.
  28. ^ Ли, Д.; Яннакакис, М. (1996). «Принципы и методы тестирования конечных автоматов — обзор». Труды IEEE . 84 (8): 1090–1123. doi :10.1109/5.533956.
  29. ^ Петренко, А.; Евтушенко, Н. (2011). «Адаптивное тестирование детерминированных реализаций, заданных недетерминированными конечными автоматами». В Testing Software and Systems: 23rd IFIP WG 6.1 International Conference, ICTSS 2011, Париж, Франция, 7-10 ноября. Lecture Notes in Computer Science. Vol. 7019. Springer Berlin Heidelberg. pp. 162–178. doi :10.1007/978-3-642-24580-0_12. ISBN 978-3-642-24579-4.
  30. ^ Петренко, А.; Евтушенко, Н. (2014). «Адаптивное тестирование недетерминированных систем с FSM». В 2014 IEEE 15th International Symposium on High-Assurance Systems Engineering. IEEE. стр. 224–228. doi :10.1109/HASE.2014.39. ISBN 978-1-4799-3466-9.
  31. ^ abcd Limaye, MG (2009). Тестирование программного обеспечения. Tata McGraw-Hill Education. стр. 108–11. ISBN 978-0-07-013990-9.
  32. ^ abcd Салех, KA (2009). Программная инженерия. J. Ross Publishing. стр. 224–41. ISBN 978-1-932159-94-3.
  33. ^ abc Амманн, П.; Оффутт, Дж. (2016). Введение в тестирование программного обеспечения. Cambridge University Press. стр. 26. ISBN 978-1-316-77312-3.
  34. ^ Эверетт, Г. Д.; Маклеод-младший, Р. (2007). "Глава 7: Функциональное тестирование". Тестирование программного обеспечения: тестирование на протяжении всего жизненного цикла разработки программного обеспечения . John Wiley & Sons. стр. 99–121. ISBN 978-0-470-14634-7.
  35. ^ ab Cornett, Steve (c. 1996). "Анализ покрытия кода". Технология тестирования Bullseye. Введение . Получено 21 ноября 2017 г.
  36. ^ ab Black, R. (2011). Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional. John Wiley & Sons. С. 44–6. ISBN 978-1-118-07938-6.
  37. ^ В качестве простого примера, функция C состоит только из одного оператора. Все тесты по спецификации будут успешными, за исключением случаев, когда выбрано.int f(int x){return x*x-6*x+8;}f(x)>=0x=3
  38. ^ Паттон, Рон (2005). Тестирование программного обеспечения (2-е изд.). Индианаполис: Sams Publishing. ISBN 978-0-672-32798-8.
  39. ^ Лейкок, Гилберт Т. (1993). Теория и практика тестирования программного обеспечения на основе спецификаций (PDF) (диссертация). Кафедра компьютерных наук, Шеффилдский университет . Получено 2 января 2018 г.
  40. ^ Бах, Джеймс (июнь 1999 г.). «Тестирование на основе рисков и требований» (PDF) . Компьютер . 32 (6): 113–114 . Получено 19 августа 2008 г. .
  41. ^ Матур, А. П. (2011). Основы тестирования программного обеспечения. Pearson Education India. стр. 63. ISBN 978-81-317-5908-0.
  42. ^ ab Clapp, Judith A. (1995). Контроль качества программного обеспечения, анализ ошибок и тестирование. Уильям Эндрю. стр. 313. ISBN 978-0-8155-1363-6. Получено 5 января 2018 г. .
  43. ^ Матур, Адитья П. (2007). Основы тестирования программного обеспечения. Pearson Education India. стр. 18. ISBN 978-81-317-1660-1.
  44. ^ Лённберг, Ян (7 октября 2003 г.). Визуальное тестирование программного обеспечения (PDF) (диссертация на степень магистра наук). Хельсинкский технологический университет . Получено 13 января 2012 г.
  45. ^ Чима, Распал. "Визуальное тестирование". Журнал TEST . Архивировано из оригинала 24 июля 2012 г. Получено 13 января 2012 г.
  46. ^ abc Льюис, У. Э. (2016). Тестирование программного обеспечения и непрерывное улучшение качества (3-е изд.). CRC Press. С. 68–73. ISBN 978-1-4398-3436-7.
  47. ^ ab Ransome, J.; Misra, A. (2013). Безопасность основного программного обеспечения: безопасность у источника. CRC Press. стр. 140–3. ISBN 978-1-4665-6095-6.
  48. ^ "SOA Testing Tools for Black, White and Gray Box" (белая статья). Crosscheck Networks. Архивировано из оригинала 1 октября 2018 г. Получено 10 декабря 2012 г.
  49. ^ ab Myers, G. (2004). Sandler, C; Badgett, T; Thomas, M. (ред.). Искусство тестирования программного обеспечения (2-е изд.). Wiley. ISBN 9780471469124.
  50. ^ Амманн, Пол; Оффатт, Джефф (28 января 2008 г.). Введение в тестирование программного обеспечения. Cambridge University Press . стр. 215. ISBN 978-0-521-88038-1. Получено 29 ноября 2017 г. .
  51. ^ abc Льюис, У. Э. (2016). Тестирование программного обеспечения и непрерывное улучшение качества (3-е изд.). CRC Press. С. 92–6. ISBN 978-1-4398-3436-7.
  52. ^ Machado, P.; Vincenzi, A.; Maldonado, JC (2010). "Глава 1: Тестирование программного обеспечения: Обзор". В Borba, P.; Cavalcanti, A.; Sampaio, A.; Woodcook, J. (ред.). Методы тестирования в программной инженерии . Springer Science & Business Media. стр. 13–14. ISBN 978-3-642-14334-2.
  53. ^ Clapp, JA; Stanten, SF; Peng, WW; и др. (1995). Контроль качества программного обеспечения, анализ ошибок и тестирование. Nova Data Corporation. стр. 254. ISBN 978-0-8155-1363-6.
  54. ^ abc "ISTQB CTFL Syllabus 2018" (PDF) . ISTQB - International Software Testing Qualifications Board . Архивировано (PDF) из оригинала 24 марта 2022 г. . Получено 11 апреля 2022 г. .
  55. ^ Woods, Anthony J. (5 июня 2015 г.). «Операционная приемка — применение стандарта тестирования программного обеспечения ISO 29119» (Белая книга). Capgemini Australia . Получено 9 января 2018 г.
  56. ^ "Стандартный глоссарий терминов, используемых в тестировании программного обеспечения" (PDF) . Версия 3.1. International Software Testing Qualifications Board . Получено 9 января 2018 г.
  57. ^ O'Reilly, Tim (30 сентября 2005 г.). «Что такое Web 2.0». O'Reilly Media. Раздел 4. Конец цикла выпуска программного обеспечения . Получено 11 января 2018 г.
  58. ^ Ауэрбах, Адам (3 августа 2015 г.). «Часть трубопровода: почему непрерывное тестирование необходимо». TechWell Insights . TechWell Corp . Получено 12 января 2018 г. .
  59. ^ Филипп-Эдмондс, Кэмерон (5 декабря 2014 г.). «Связь между риском и непрерывным тестированием: интервью с Уэйном Ариолой». Stickyminds . Получено 16 января 2018 г. .
  60. ^ Ариола, Уэйн; Данлоп, Синтия (октябрь 2015 г.). DevOps: быстрее ли вы отправляете ошибки клиентам? (PDF) . Pacific Northwest Software Quality Conference . Получено 16 января 2018 г. .
  61. ^ Ауэрбах, Адам (2 октября 2014 г.). «Сдвиньтесь влево и поставьте качество на первое место». TechWell Insights . TechWell Corp . Получено 16 января 2018 г. .
  62. ^ "Раздел 4.38". ISO/IEC/IEEE 29119-1:2013 – Программное обеспечение и системная инженерия – Тестирование программного обеспечения – Часть 1 – Концепции и определения. Международная организация по стандартизации . Получено 17 января 2018 г.
  63. ^ "Глобализация шаг за шагом: готовый к миру подход к тестированию. Сеть разработчиков Microsoft". Сеть разработчиков Microsoft. Архивировано из оригинала 23 июня 2012 г. Получено 13 января 2012 г.
  64. ^ Классен, Коэн; Хьюз, Джон (2000). "QuickCheck". Труды пятой международной конференции ACM SIGPLAN по функциональному программированию . ICFP '00. С. 268–279. doi :10.1145/351240.351266. ISBN 978-1-58113-202-1. S2CID  5668071.
  65. ^ Гельперин, Дэвид ; Хетцель, Билл (1 июня 1988 г.). «Рост тестирования программного обеспечения». Сообщения ACM . 31 (6): 687–695. doi : 10.1145/62959.62965 . S2CID  14731341.
  66. ^ Грегори, Джанет; Криспин, Лиза (2014). Еще больше Agile Testing . Addison-Wesley Professional. стр. 23–39. ISBN 978-0-13-374956-4.
  67. ^ "Жизненный цикл тестирования программного обеспечения". etestinghub . Фаза тестирования в тестировании программного обеспечения . Получено 13 января 2012 г.
  68. ^ Дастин, Эльфриде (2002). Эффективное тестирование программного обеспечения. Addison-Wesley Professional. стр. 3. ISBN 978-0-201-79429-8.
  69. ^ ab "Что такое разработка через тестирование (TDD)?". Agile Alliance . 5 декабря 2015 г. Получено 17 марта 2018 г.
  70. ^ «Test-Driven Development and Continuous Integration for Mobile Applications». Microsoft Developer Network . 14 января 2009 г. Получено 17 марта 2018 г.
  71. ↑ Браун, Крис; Кобб, Гэри; Калбертсон, Роберт (12 апреля 2002 г.). Введение в быстрое тестирование программного обеспечения.
  72. ^ Тран, Эушиуан (1999). «Верификация/валидация/сертификация» (курсовая работа). Университет Карнеги-Меллона . Получено 13 августа 2008 г.
  73. ^ ab Gotel, Orlena; Cleland-Huang, Jane ; Hayes, Jane Huffman; Zisman, Andrea; Egyed, Alexander; Grünbacher, Paul; Dekhtyar, Alex; Antoniol, Giuliano; Maletic, Jonathan (1 января 2012 г.). Cleland-Huang, Jane; Gotel, Orlena; Zisman, Andrea (ред.). Прослеживаемость программного обеспечения и систем . Springer London. doi :10.1007/978-1-4471-2239-5_1. ISBN 9781447122388.
  74. ^ IEEE (1998). Стандарт IEEE для документации по тестированию программного обеспечения . Нью-Йорк: IEEE. ISBN 978-0-7381-1443-9.
  75. ^ Пинто, Леандро Сэйлз; Синха, Саурабх; Орсо, Алессандро (11 ноября 2012 г.). «Понимание мифов и реалий эволюции тестовых наборов». Труды 20-го Международного симпозиума ACM SIGSOFT по основам программной инженерии . Ассоциация вычислительной техники. стр. 1–11. doi :10.1145/2393596.2393634. ISBN 9781450316149. S2CID  9072512.
  76. ^ Strom, David (1 июля 2009 г.). «Мы все — часть истории». Software Test & Performance Collaborative. Архивировано из оригинала 31 августа 2009 г.
  77. ^ Гриффитс, М. (2005). «Обучение PMI гибкому управлению проектами». Конференция по гибкой разработке (ADC'05) . ieee.org. стр. 318–322. doi :10.1109/ADC.2005.45. ISBN 978-0-7695-2487-0. S2CID  30322339.
  78. ^ Уиллисон, Джон С. (апрель 2004 г.). "Agile Software Development for an Agile Force". CrossTalk (апрель 2004 г.). STSC. Архивировано из оригинала 29 октября 2005 г.
  79. ^ Примером может служить Марк Фьюстер, Дороти Грэм: Автоматизация тестирования программного обеспечения. Addison Wesley, 1999, ISBN 978-0-201-33140-0 . 
  80. ^ "stop29119". commonsensetesting.org . Архивировано из оригинала 2 октября 2014 года.
  81. ^ Пол Крилл (22 августа 2014 г.). «Тестировщики программного обеспечения не одобряют предложение по стандарту ISO 29119». InfoWorld .
  82. ^ Канер, Джем (2001). «Предложение о гранте NSF для «закладывания основы для значительного улучшения качества академических и коммерческих курсов по тестированию программного обеспечения»» (PDF) . Архивировано из оригинала (PDF) 27 ноября 2009 г. . Получено 13 октября 2006 г.
  83. ^ Канер, Джем (2003). Измерение эффективности тестировщиков программного обеспечения (PDF) . STAR East. Архивировано из оригинала (PDF) 26 марта 2010 г. Получено 18 января 2018 г.
  84. ^ Макконнелл, Стив (2004). Code Complete (2-е изд.). Microsoft Press. стр. 29. ISBN 978-0-7356-1967-8.
  85. ^ Боссавит, Лоран (20 ноября 2013 г.). «Цена дефектов: иллюстрированная история». Лепреконы программной инженерии: как фольклор превращается в факт и что с этим делать . leanpub.

Дальнейшее чтение

Внешние ссылки

На Викискладе есть медиафайлы по теме «Тестирование программного обеспечения» .
На Викиверситете вы можете узнать больше и научить других тестированию программного обеспечения на кафедре тестирования программного обеспечения.