✖


Jump to content

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

Часть серии о
Разработка программного обеспечения
Основная деятельность
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и своды знаний
Глоссарии
Контуры
TestingCup — Чемпионат Польши по тестированию программного обеспечения, Катовице , май 2016 г.

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

или спонсору объективную независимую информацию о качестве программного обеспечения и риске его сбоя Тестирование программного обеспечения может предоставить пользователю . [1]

Тестирование программного обеспечения может определить правильность программного обеспечения для конкретных сценариев , но не может определить правильность для всех сценариев. [2] [3] Он не может найти все ошибки .

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

Тестирование программного обеспечения часто носит динамический характер; запуск программного обеспечения для проверки соответствия фактических результатов ожидаемым. Он также может быть статичным по своей природе; просмотр кода и связанной с ним документации .

Тестирование программного обеспечения часто используется для ответа на вопрос: делает ли программное обеспечение то, что оно должно делать и что оно должно делать?

Информация, полученная в результате тестирования программного обеспечения, может использоваться для улучшения процесса разработки программного обеспечения. [5] : 41–43 

Тестирование программного обеспечения должно следовать «пирамидальному» подходу, при котором большинство ваших тестов должны быть модульными тестами , за которыми следуют интеграционные тесты и, наконец , сквозные тесты (e2e) должны иметь наименьшую долю. [6] [7] [8]

Экономика [ править ]

Исследование, проведенное NIST в 2002 году, сообщает, что ошибки в программном обеспечении обходятся экономике США в 59,5 миллиардов долларов ежегодно. Более трети этих затрат можно было бы избежать, если бы было проведено более качественное тестирование программного обеспечения. [9] [ сомнительно – обсудить ]

Аутсорсинг тестирования программного обеспечения из-за затрат очень распространен, причем предпочтительными направлениями являются Китай, Филиппины и Индия. [ нужна ссылка ]

История [ править ]

Гленфорд Дж. Майерс впервые представил разделение отладки и тестирования в 1979 году. [10] Хотя его внимание было сосредоточено на тестировании на поломку («Успешный тестовый пример — это тот, который обнаруживает еще не обнаруженную ошибку»). [10] : 16  ), это проиллюстрировало желание сообщества разработчиков программного обеспечения отделить фундаментальную деятельность по разработке, такую ​​​​как отладка, от проверки.

Цели [ править ]

Тестирование программного обеспечения обычно ориентировано на достижение цели.

Поиск ошибок [ править ]

Тестирование программного обеспечения обычно включает в себя обработку ошибок программного обеспечения – дефектов в коде , приводящих к нежелательному результату. [11] : 31  Ошибки обычно замедляют ход тестирования и требуют помощи программистов для отладки и исправления.

Не все дефекты приводят к сбою. Например, дефект в мертвом коде не будет считаться сбоем.

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

Один дефект может привести к множественным симптомам отказа.

Обеспечение выполнения требований [ править ]

Тестирование программного обеспечения может включать пробел в требованиях – упущение в проекте требования. [5] : 426  Пробелы в требованиях часто могут быть нефункциональными требованиями, такими как тестируемость , масштабируемость , ремонтопригодность , производительность и безопасность .

Покрытие кода [ править ]

Фундаментальным ограничением тестирования программного обеспечения является то, что тестирование при всех комбинациях входных данных и предварительных условий (начальное состояние) невозможно даже для простого продукта. [3] : 17–18  [13] Дефекты, проявляющиеся в необычных условиях, трудно обнаружить при тестировании. Кроме того, нефункциональные аспекты качества (каким оно должно быть в сравнении с тем, что оно должно делать ) — удобство использования , масштабируемость , производительность , совместимость и надежность — могут быть субъективными; то, что представляет достаточную ценность для одного человека, может не иметь ценности для другого.

Хотя тестирование всех возможных входных данных невозможно, при тестировании можно использовать комбинаторику , чтобы максимизировать охват при минимизации тестов. [14]

Категоризация [ править ]

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

Тестирование можно разделить на несколько категорий. [15]

Автоматизированное тестирование [ править ]

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

Уровни [ править ]

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

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

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

Интеграционное тестирование [ править ]

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

Тестирование системы [ править ]

Этот абзац представляет собой отрывок из тестирования системы . [ редактировать ]
Системное тестирование , также известное как сквозное (E2E) тестирование, — это тестирование всей программной системы .

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

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

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

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

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

Исследовательский [ править ]

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

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

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

Черно-белый ящик [ править ]

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

Тестирование «белого ящика» [ править ]

Основная статья: Тестирование белого ящика
Схема тестирования белого ящика
Схема тестирования белого ящика

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

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

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

  • Тестирование API – тестирование приложения с использованием общедоступных и частных API (интерфейсов программирования приложений).
  • Покрытие кода — создание тестов, удовлетворяющих некоторым критериям покрытия кода (например, разработчик тестов может создавать тесты, обеспечивающие выполнение всех операторов в программе хотя бы один раз).
  • Методы внедрения ошибок – намеренное введение ошибок для оценки эффективности стратегий тестирования.
  • мутационного тестирования Методы
  • Статические методы тестирования

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

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

100%-ное покрытие операторов гарантирует, что все пути или ветви кода (с точки зрения потока управления ) будут выполнены хотя бы один раз. Это полезно для обеспечения правильной функциональности, но недостаточно, поскольку один и тот же код может правильно или неправильно обрабатывать разные входные данные. [37]

Тестирование «черного ящика» [ править ]

Основная статья: Тестирование черного ящика
Диаграмма черного ящика

Тестирование «черного ящика» (также известное как функциональное тестирование) описывает разработку тестовых примеров без знания реализации и без чтения исходного кода. Тестировщикам известно только то, что должно делать программное обеспечение, а не то, как оно это делает. [38] Методы тестирования черного ящика включают в себя: разделение эквивалентности , анализ граничных значений , тестирование всех пар , таблицы переходов состояний , таблицы решений тестирование , нечеткое тестирование , тестирование на основе моделей , тестирование вариантов использования , исследовательское тестирование и тестирование на основе спецификаций. [31] [32] [36]

Тестирование на основе спецификаций направлено на проверку функциональности программного обеспечения в соответствии с применимыми требованиями. [39] Этот уровень тестирования обычно требует, чтобы тестировщику были предоставлены подробные тестовые примеры , которые затем могут просто проверить, что для данного входного значения выходное значение (или поведение) либо «является», либо «не совпадает» с ожидаемым значением. указано в тестовом примере. Тестовые примеры строятся вокруг спецификаций и требований, т. е. того, что приложение должно делать. Для создания тестовых примеров он использует внешние описания программного обеспечения, включая спецификации, требования и проекты. Эти тесты могут быть функциональными и нефункциональными , но обычно функциональными. Тестирование на основе спецификаций может быть необходимо для обеспечения правильной функциональности, но его недостаточно для защиты от сложных ситуаций или ситуаций высокого риска. [40]

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

Тестирование интерфейса компонентов

Тестирование интерфейса компонента — это вариант тестирования «черного ящика» , в котором основное внимание уделяется значениям данных, а не только связанным действиям компонента подсистемы. [41] Практику тестирования интерфейсов компонентов можно использовать для проверки обработки данных, передаваемых между различными модулями или компонентами подсистемы, помимо тестирования полной интеграции между этими модулями. [42] [43] Передаваемые данные можно рассматривать как «пакеты сообщений», а диапазон или типы данных можно проверять на предмет данных, сгенерированных одним устройством, и проверять их достоверность перед передачей в другое устройство. Одним из вариантов тестирования интерфейса является ведение отдельного файла журнала передаваемых элементов данных, часто с регистрируемой временной меткой, что позволяет анализировать тысячи случаев передачи данных между устройствами в течение дней или недель. Тесты могут включать проверку обработки некоторых экстремальных значений данных, в то время как другие переменные интерфейса передаются как нормальные значения. [42] Необычные значения данных в интерфейсе могут помочь объяснить неожиданную производительность в следующем модуле.

Визуальное тестирование [ править ]

Цель визуального тестирования — предоставить разработчикам возможность изучить, что происходило в момент сбоя программного обеспечения, представляя данные таким образом, чтобы разработчик мог легко найти необходимую ему информацию, и эта информация была выражена четко. . [44] [45]

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

Визуальное тестирование дает ряд преимуществ. Качество связи резко повышается, поскольку тестировщики могут показать разработчику проблему (и события, ведущие к ней), а не просто описать ее, и во многих случаях необходимость воспроизводить неудачные тесты перестанет существовать. У разработчика будут все необходимые доказательства неудачного теста, и он сможет вместо этого сосредоточиться на причине ошибки и способах ее устранения.

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

Дополнительная информация: Тестирование графического пользовательского интерфейса.

Тестирование серого ящика [ править ]

Основная статья: Тестирование серого ящика

Тестирование серого ящика (американское написание: тестирование серого ящика) предполагает использование знаний о внутренних структурах данных и алгоритмах для разработки тестов при выполнении этих тестов на уровне пользователя или на уровне черного ящика. Тестер часто имеет доступ как к «исходному коду, так и к исполняемому двоичному файлу». [47] Тестирование «серого ящика» может также включать обратное проектирование (с использованием динамического анализа кода) для определения, например, граничных значений или сообщений об ошибках. [47] Манипулирование входными данными и форматирование выходных данных не квалифицируются как «серый ящик», поскольку входные и выходные данные явно находятся за пределами «черного ящика», который мы называем тестируемой системой. Это различие особенно важно при проведении интеграционного тестирования между двумя модулями кода, написанными двумя разными разработчиками, когда тесту подвергаются только интерфейсы.

Зная основные концепции работы программного обеспечения, тестировщик делает более обоснованный выбор при тестировании при внешнем тестировании программного обеспечения. Обычно тестировщику «серого ящика» разрешается создать изолированную среду тестирования с такими действиями, как заполнение базы данных . Тестер может наблюдать за состоянием тестируемого продукта после выполнения определенных действий, таких как выполнение операторов SQL для базы данных, а затем выполнение запросов, чтобы убедиться, что ожидаемые изменения были отражены. Тестирование «серого ящика» реализует интеллектуальные сценарии тестирования, основанные на ограниченной информации. Это особенно применимо к обработке типов данных, обработке исключений и т. д. [48]

С появлением концепции тестирования «серого ящика» это «произвольное различие» между тестированием «черного» и «белого ящика» несколько исчезло. [33]

Тестирование установки [ править ]

Этот раздел представляет собой отрывок из тестирования установки . [ редактировать ]

Большинство программных систем имеют процедуры установки, которые необходимы, прежде чем их можно будет использовать по своему основному назначению. Тестирование этих процедур для получения установленной программной системы, которую можно использовать, называется установочным тестированием . [49] : 139  Эти процедуры могут включать полное или частичное обновление, а также процессы установки/удаления.

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

Тестирование совместимости [ править ]

Основная статья: Тестирование совместимости

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

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

Основная статья: Дымовое тестирование (программное обеспечение)

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

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

Регрессионное тестирование [ править ]

Основная статья: Регрессионное тестирование

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

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

Приемочное тестирование [ править ]

Основная статья: Приемочное тестирование

Приемочное тестирование — это тестирование на уровне системы, позволяющее убедиться, что программное обеспечение соответствует ожиданиям клиентов. [51] [52] [53] [54]

Приемочное тестирование может выполняться как часть процесса передачи между любыми двумя этапами разработки. [ нужна ссылка ]

Тесты часто группируются по этим уровням в зависимости от того, где они выполняются в процессе разработки программного обеспечения или по уровню специфичности теста. [54]

  • Пользовательское приемочное тестирование (UAT)
  • Эксплуатационные приемочные испытания (ОАТ)
  • Договорные и нормативные приемочные испытания
  • Альфа- и бета-тестирование

Иногда UAT выполняется заказчиком в своей среде и на собственном оборудовании.

OAT используется для проведения оперативной готовности (предварительного выпуска) продукта, услуги или системы в рамках системы менеджмента качества . OAT — это распространенный тип нефункционального тестирования программного обеспечения, используемый в основном в разработки и сопровождения программного проектах обеспечения. Этот тип тестирования фокусируется на эксплуатационной готовности системы, которая будет поддерживаться или станет частью производственной среды. Следовательно, оно также известно как тестирование эксплуатационной готовности (ORT) или тестирование эксплуатационной готовности и обеспечения (OR&A). Функциональное тестирование в рамках OAT ограничивается теми тестами, которые необходимы для проверки нефункциональных аспектов системы.

Кроме того, тестирование программного обеспечения должно гарантировать, что переносимость системы, а также ее ожидаемая работа не повреждают или частично не повреждают ее операционную среду или не приводят к выходу из строя других процессов в этой среде. [55]

Договорное приемочное тестирование проводится на основе контрактных критериев приемки, определенных при заключении договора, а нормативное приемочное тестирование проводится на основе соответствующих нормативных актов к программному продукту. Оба этих теста могут выполняться пользователями или независимыми тестировщиками. Приемочное тестирование по правилам иногда предполагает проверку результатов испытаний регулирующими органами. [54]

Альфа-тестирование [ править ]

Альфа-тестирование — это симулированное или фактическое эксплуатационное тестирование, проводимое потенциальными пользователями/заказчиками или независимой группой тестирования на площадке разработчиков. Альфа-тестирование часто используется для готового программного обеспечения как форма внутреннего приемочного тестирования перед тем, как программное обеспечение перейдет на бета-тестирование. [56]

Бета-тестирование [ править ]

См. также: Жизненный цикл выпуска программного обеспечения § Бета-версия.

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

нефункциональное и тестирование Функциональное

Функциональное тестирование относится к действиям, которые проверяют определенное действие или функцию кода. Обычно их можно найти в документации по требованиям к коду, хотя некоторые методологии разработки основаны на сценариях использования или пользовательских историях. Функциональные тесты, как правило, отвечают на вопрос «может ли пользователь это сделать» или «работает ли эта конкретная функция».

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

Непрерывное тестирование [ править ]

Основная статья: Непрерывное тестирование

Непрерывное тестирование — это процесс выполнения автоматических тестов в рамках конвейера поставки программного обеспечения для получения немедленной информации о бизнес-рисках, связанных с кандидатом на выпуск программного обеспечения. [58] [59] Непрерывное тестирование включает проверку как функциональных , так и нефункциональных требований ; Объем тестирования простирается от проверки восходящих требований или пользовательских историй до оценки системных требований, связанных с общими бизнес-целями. [60] [61]

Разрушающий контроль [ править ]

Основная статья: Разрушающий контроль

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

Дополнительная информация: Обработка исключений и тестирование восстановления.

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

Основная статья: Тестирование производительности программного обеспечения

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

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

Существует мало согласия относительно того, каковы конкретные цели тестирования производительности. Термины нагрузочное тестирование, тестирование производительности, тестирование масштабируемости и объемное тестирование часто используются как взаимозаменяемые.

Программные системы реального времени имеют строгие временные ограничения. Чтобы проверить, соблюдаются ли временные ограничения, тестирование в реальном времени используется .

Юзабилити-тестирование [ править ]

Юзабилити-тестирование предназначено для проверки простоты и понимания пользовательского интерфейса. В основном это касается использования приложения. Это не тот тип тестирования, который можно автоматизировать; необходимы реальные пользователи-люди, за которыми следят опытные дизайнеры пользовательского интерфейса .

Тестирование доступности [ править ]

Тестирование доступности проводится для обеспечения доступности программного обеспечения для людей с ограниченными возможностями. Некоторые из распространенных тестов веб-доступности:

  • Обеспечение надлежащего цветового контраста между шрифтом и цветом фона.
  • Размер шрифта
  • Альтернативные тексты для мультимедийного контента
  • Возможность использовать систему, используя не только мышь, но и клавиатуру компьютера.

Общие стандарты соответствия

Тестирование безопасности [ править ]

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

Международная организация по стандартизации (ISO) определяет это как «тип тестирования, проводимый для оценки степени, в которой объект тестирования и связанные с ним данные и информация защищены так, что неуполномоченные лица или системы не могут их использовать, читать или изменять, и авторизованным лицам или системам не отказано в доступе к ним». [62]

Интернационализация и локализация [ править ]

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

Тестирование на глобализацию подтверждает, что программное обеспечение адаптировано к новой культуре (например, к разным валютам или часовым поясам). [63]

Фактический перевод на человеческие языки также должен быть проверен. Возможные неудачи локализации и глобализации включают в себя:

  • Программное обеспечение часто локализуется путем перевода списка строк вне контекста, и переводчик может выбрать неправильный перевод для неоднозначной исходной строки.
  • Техническая терминология может стать противоречивой, если проект переводят несколько человек без должной координации или если переводчик ведет себя неосмотрительно.
  • Буквальный дословный перевод может показаться неуместным, искусственным или слишком техническим на целевом языке.
  • Непереведенные сообщения на языке оригинала могут быть жестко запрограммированы в исходном коде.
  • Некоторые сообщения могут создаваться автоматически во время выполнения , и результирующая строка может быть неграмматичной, функционально неправильной, вводящей в заблуждение или сбивающей с толку.
  • Программное обеспечение может использовать сочетание клавиш исходного языка , которое не имеет функции в раскладке клавиатуры , но используется для ввода символов в раскладке целевого языка.
  • Программное обеспечение может не поддерживать кодировку символов целевого языка.
  • Шрифты и размеры шрифтов, подходящие для исходного языка, могут быть неподходящими для целевого языка; например, символы CJK могут стать нечитаемыми, если шрифт слишком мелкий.
  • Строка на целевом языке может быть длиннее, чем может обработать программное обеспечение. Это может сделать строку частично невидимой для пользователя или привести к сбою или неисправности программного обеспечения.
  • В программном обеспечении может отсутствовать надлежащая поддержка чтения или записи двунаправленного текста .
  • Программное обеспечение может отображать изображения с нелокализованным текстом.
  • Локализованные операционные системы могут иметь разные имена файлов конфигурации системы и переменных среды , а также разные форматы даты и валюты .

Тестирование разработки [ править ]

Основная статья: Тестирование разработки

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

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

A/B-тестирование [ править ]

Основная статья: A/B-тестирование

A/B-тестирование — это метод проведения контролируемого эксперимента, чтобы определить, является ли предлагаемое изменение более эффективным, чем текущий подход. Клиентов перенаправляют либо к текущей версии (контроль) функции, либо к модифицированной версии (обработка), и данные собираются, чтобы определить, какая версия лучше подходит для достижения желаемого результата.

Параллельное тестирование [ править ]

Основная статья: Параллельное тестирование

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

Тестирование на соответствие типовое или тестирование

Основная статья: Тестирование соответствия

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

Сравнительное тестирование выходных данных [ править ]

Создание ожидаемого результата отображения, будь то сравнение данных текста или снимков экрана пользовательского интерфейса, [3] : 195  его иногда называют тестированием моментальных снимков или Золотым мастер-тестированием, в отличие от многих других форм тестирования, оно не может обнаруживать сбои автоматически и вместо этого требует, чтобы человек оценивал выходные данные на предмет несоответствий.

Тестирование недвижимости [ править ]

Не путать с алгоритмами тестирования свойств .

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

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

Тестирование свойств также иногда называют «генеративным тестированием» или «тестированием QuickCheck», поскольку оно было представлено и популяризировано библиотекой Haskell QuickCheck . [64]

Метаморфические испытания [ править ]

Основная статья: Метаморфические испытания

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

Тестирование видеомагнитофона [ править ]

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

Стоимость устранения неисправности Время обнаружено
Требования Архитектура Строительство Тест системы Пост-релиз
Время введения Требования 1× 3× 5–10× 10× 10–100×
Архитектура – 1× 10× 15× 25–100×
Строительство – – 1× 10× 10–25×

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

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

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

См. также [ править ]

Ссылки [ править ]

  1. ^ Канер, Джем (17 ноября 2006 г.). Исследовательское тестирование (PDF) . Всемирная ежегодная конференция Института обеспечения качества по тестированию программного обеспечения. Орландо, Флорида . Проверено 22 ноября 2014 г.
  2. ^ Jump up to: Перейти обратно: а б Пан, Цзяньтао (весна 1999 г.). «Тестирование программного обеспечения» (курсовая работа). Университет Карнеги-Меллон . Проверено 21 ноября 2017 г.
  3. ^ Jump up to: Перейти обратно: а б с д Канер, Джем ; Фальк, Джек; Нгуен, Хунг Куок (1999). Тестирование компьютерного программного обеспечения (2-е изд.). Нью-Йорк: Джон Уайли и сыновья. ISBN  978-0-471-35846-6 .
  4. ^ Лейтнер, Андреас; Чупа, Илинка; Ориоль, Мануэль; Мейер, Бертран ; Фива, Арно (сентябрь 2007 г.). Разработка через контракт = Разработка через тестирование – написание тестовых примеров (PDF) . ESEC/FSE'07: Европейская конференция по разработке программного обеспечения и симпозиум ACM SIGSOFT по основам программной инженерии 2007. Дубровник, Хорватия . Проверено 8 декабря 2017 г.
  5. ^ Jump up to: Перейти обратно: а б Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: лучшие практики управления программным обеспечением . Издательство компьютерного общества Wiley-IEEE. ISBN  978-0-470-04212-0 .
  6. ^ Кон, Майк (2009). Как добиться успеха в Agile: разработка программного обеспечения с использованием Scrum . Аддисон-Уэсли Профессионал. ISBN  978-0321579362 .
  7. ^ Молина, Алессандро (2021). Создание программного обеспечения, управляемого тестированием, с помощью Python. Создавайте наборы тестов, которые масштабируются в соответствии с потребностями и сложностью ваших приложений, используя Python и PyTest . Пакт Паблишинг. ISBN  978-1838642655 .
  8. ^ Фернандес да Кошта, Лукас (2021). Тестирование приложений JavaScript . Мэннинг. ISBN  978-1617297915 .
  9. ^ «Экономические последствия неадекватной инфраструктуры для тестирования программного обеспечения» (PDF) . Национальный институт стандартов и технологий . Май 2002 года . Проверено 19 декабря 2017 г.
  10. ^ Jump up to: Перейти обратно: а б с Майерс, Гленфорд Дж . (1979). Искусство тестирования программного обеспечения . Джон Уайли и сыновья. ISBN  978-0-471-04328-7 .
  11. ^ Jump up to: Перейти обратно: а б Стандартный словарь терминологии разработки программного обеспечения IEEE, IEEE, 1990, doi : 10.1109/IEESTD.1990.101064 , ISBN  978-1-55937-067-7
  12. ^ «Программа базового уровня для сертифицированных тестировщиков» . Международный квалификационный совет по тестированию программного обеспечения . 31 марта 2011 г. Раздел 1.1.2. Архивировано из оригинала (pdf) 28 октября 2017 года . Проверено 15 декабря 2017 г.
  13. ^ «Программа базового уровня для сертифицированных тестировщиков» (PDF) . Международный квалификационный совет по тестированию программного обеспечения . 1 июля 2005 г. Принцип 2, раздел 1.3. Архивировано из оригинала (PDF) 17 декабря 2008 г. Проверено 15 декабря 2017 г.
  14. ^ Рамлер, Рудольф; Копецкий, Теодорих; Платц, Вольфганг (17 апреля 2012 г.). Комбинаторный дизайн тестов в наборе тестов TOSCA: извлеченные уроки и практические последствия . Пятая международная конференция IEEE по тестированию и валидации программного обеспечения (ICST). Монреаль, Квебек, Канада. дои : 10.1109/ICST.2012.142 .
  15. ^ Канер, Джем; Бах, Джеймс; Петтикорд, Брет (2001). Уроки, извлеченные из тестирования программного обеспечения: контекстно-ориентированный подход . Уайли. стр. 31–43 . ISBN  978-0-471-08112-8 .
  16. ^ Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: лучшие практики управления программным обеспечением . Издательство компьютерного общества Wiley-IEEE. п. 74. ИСБН  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. 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). Разработка программного обеспечения и профессиональная практика . Пресс. стр. 193–4. ISBN  978-1-4302-3801-0 .
  21. ^ Вигерс, К. (2013). Создание культуры разработки программного обеспечения . Аддисон-Уэсли. стр. 211–2. ISBN  978-0-13-348929-3 .
  22. ^ Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: лучшие практики управления программным обеспечением . Издательство компьютерного общества Wiley-IEEE. п. 75. ИСБН  978-0-470-04212-0 .
  23. ^ Jump up to: Перейти обратно: а б Грэм, Д.; Ван Винендал, Э.; Эванс, И. (2008). Основы тестирования программного обеспечения . Cengage Обучение. стр. 57–58. ISBN  978-1-84480-989-9 .
  24. ^ Jump up to: Перейти обратно: а б с д Оберкампф, ВЛ; Рой, CJ (2010). Верификация и валидация в научных вычислениях . Издательство Кембриджского университета. стр. 154–5. ISBN  978-1-139-49176-1 .
  25. ^ Ли, Д.; Нетравали, АН; Сабнани, КК; Сугла, Б.; Джон, А. (1997). «Пассивное тестирование и приложения для управления сетью». Материалы Международной конференции по сетевым протоколам 1997 года . IEEE-компьютер. Соц. стр. 113–122. дои : 10.1109/icnp.1997.643699 . ISBN  978-0-8186-8061-8 . S2CID   42596126 .
  26. ^ Джем Канер, « Учебное пособие по исследовательскому тестированию, заархивировано 12 июня 2013 г. в Wayback Machine », стр. 2
  27. ^ Джем Канер, Учебное пособие по исследовательскому тестированию, заархивировано 12 июня 2013 г. в Wayback Machine , стр. 36.
  28. ^ Ли, Д.; Яннакакис, М. (1996). «Принципы и методы тестирования конечных автоматов-обзор» . Труды IEEE . 84 (8): 1090–1123.
  29. ^ Петренко А.; Евтушенко, Н. (2011). «Адаптивное тестирование детерминированных реализаций, заданных недетерминированными автоматами». Тестирование программного обеспечения и систем: 23-я Международная конференция IFIP WG 6.1, ICTSS 2011, Париж, Франция, 7-10 ноября . Шпрингер Берлин Гейдельберг. стр. 162–178.
  30. ^ Петренко А.; Евтушенко, Н. (2014). «Адаптивное тестирование недетерминированных систем с помощью автомата». В 2014 году прошел 15-й международный симпозиум IEEE по системной инженерии высокой надежности . IEEE. стр. 224–228.
  31. ^ Jump up to: Перейти обратно: а б с д Лимае, М.Г. (2009). Тестирование программного обеспечения . Тата МакГроу-Хилл Образование. стр. 108–11. ISBN  978-0-07-013990-9 .
  32. ^ Jump up to: Перейти обратно: а б с д Салех, штат Калифорния (2009). Программная инженерия . Издательство Дж. Росс. стр. 224–41. ISBN  978-1-932159-94-3 .
  33. ^ Jump up to: Перейти обратно: а б с Амманн, П.; Оффатт, Дж. (2016). Введение в тестирование программного обеспечения . Издательство Кембриджского университета. п. 26. ISBN  978-1-316-77312-3 .
  34. ^ Эвератт, Джорджия; Маклеод-младший, Р. (2007). «Глава 7: Функциональное тестирование». Тестирование программного обеспечения: тестирование на протяжении всего жизненного цикла разработки программного обеспечения . Джон Уайли и сыновья. стр. 99–121. ISBN  978-0-470-14634-7 .
  35. ^ Jump up to: Перейти обратно: а б Корнетт, Стив (около 1996 г.). «Анализ покрытия кода» . Технология тестирования «яблочко». Введение . Проверено 21 ноября 2017 г.
  36. ^ Jump up to: Перейти обратно: а б Блэк, Р. (2011). Прагматическое тестирование программного обеспечения: как стать эффективным и действенным специалистом по тестированию . Джон Уайли и сыновья. стр. 44–6. ISBN  978-1-118-07938-6 .
  37. ^ Простой пример: C функция int f(int x){return x*x-6*x+8;} состоит всего из одного утверждения. Все тесты на соответствие спецификации f(x)>=0 добьется успеха, если только x=3 бывает выбран.
  38. ^ Паттон, Рон (2005). Тестирование программного обеспечения (2-е изд.). Индианаполис: Издательство Sams. ISBN  978-0-672-32798-8 .
  39. ^ Лэйкок, Гилберт Т. (1993). Теория и практика тестирования программного обеспечения на основе спецификаций (PDF) (диссертация). Кафедра компьютерных наук Шеффилдского университета . Проверено 2 января 2018 г.
  40. ^ Бах, Джеймс (июнь 1999 г.). «Тестирование на основе рисков и требований» (PDF) . Компьютер . 32 (6): 113–114 . Проверено 19 августа 2008 г.
  41. ^ Матур, AP (2011). Основы тестирования программного обеспечения . Пирсон Образовательная Индия. п. 63. ИСБН  978-81-317-5908-0 .
  42. ^ Jump up to: Перейти обратно: а б Клэпп, Джудит А. (1995). Контроль качества программного обеспечения, анализ ошибок и тестирование . Уильям Эндрю. п. 313. ИСБН  978-0-8155-1363-6 . Проверено 5 января 2018 г.
  43. ^ Матур, Адитья П. (2007). Основы тестирования программного обеспечения . Пирсон Образовательная Индия. п. 18. ISBN  978-81-317-1660-1 .
  44. ^ Леннберг, Ян (7 октября 2003 г.). Визуальное тестирование программного обеспечения (PDF) (магистерская диссертация). Хельсинкский технологический университет . Проверено 13 января 2012 г.
  45. ^ Чима, Распал. «Визуальное тестирование» . Журнал ТЕСТ . Архивировано из оригинала 24 июля 2012 года . Проверено 13 января 2012 г.
  46. ^ Jump up to: Перейти обратно: а б с Льюис, МЫ (2016). Тестирование программного обеспечения и постоянное улучшение качества (3-е изд.). ЦРК Пресс. стр. 68–73. ISBN  978-1-4398-3436-7 .
  47. ^ Jump up to: Перейти обратно: а б Рэнсом, Дж.; Мисра, А. (2013). Основная безопасность программного обеспечения: безопасность у источника . ЦРК Пресс. стр. 140–3. ISBN  978-1-4665-6095-6 .
  48. ^ «Инструменты тестирования SOA для черного, белого и серого ящика» (информационный документ). Перекрестная проверка сетей. Архивировано из оригинала 1 октября 2018 года . Проверено 10 декабря 2012 г.
  49. ^ Jump up to: Перейти обратно: а б Майерс, Г. (2004). Сэндлер, К; Бэджетт, Т; Томас, М. (ред.). Искусство тестирования программного обеспечения (2-е изд.). Уайли. ISBN  9780471469124 .
  50. ^ Амманн, Пол; Оффатт, Джефф (28 января 2008 г.). Введение в тестирование программного обеспечения . Издательство Кембриджского университета . п. 215. ИСБН  978-0-521-88038-1 . Проверено 29 ноября 2017 г.
  51. ^ Jump up to: Перейти обратно: а б с Льюис, МЫ (2016). Тестирование программного обеспечения и постоянное улучшение качества (3-е изд.). ЦРК Пресс. стр. 92–6. ISBN  978-1-4398-3436-7 .
  52. ^ Мачадо, П.; Винченци, А.; Мальдонадо, Джей Си (2010). «Глава 1: Тестирование программного обеспечения: обзор» . В Борбе, П.; Кавальканти, А.; Сампайо, А.; Вудкук, Дж. (ред.). Методы тестирования в программной инженерии . Springer Science & Business Media. стр. 13–14. ISBN  978-3-642-14334-2 .
  53. ^ Клапп, Дж.А.; Стантен, Сан-Франциско; Пэн, WW; и др. (1995). Контроль качества программного обеспечения, анализ ошибок и тестирование . Корпорация Нова Дата. п. 254. ИСБН  978-0-8155-1363-6 .
  54. ^ Jump up to: Перейти обратно: а б с «Программа ISTQB CTFL 2018» (PDF) . ISTQB — Международная квалификационная комиссия по тестированию программного обеспечения . Архивировано (PDF) из оригинала 24 марта 2022 г. Проверено 11 апреля 2022 г.
  55. ^ Вудс, Энтони Дж. (5 июня 2015 г.). «Эксплуатационная приемка – применение стандарта тестирования программного обеспечения ISO 29119» (информационный документ). Капгемини Австралия . Проверено 9 января 2018 г.
  56. ^ «Стандартный словарь терминов, используемых при тестировании программного обеспечения» (PDF) . Версия 3.1. Международный квалификационный совет по тестированию программного обеспечения . Проверено 9 января 2018 г.
  57. ^ О'Рейли, Тим (30 сентября 2005 г.). «Что такое Веб 2.0» . О'Рейли Медиа. Раздел 4. Окончание цикла выпуска программного обеспечения . Проверено 11 января 2018 г.
  58. ^ Ауэрбах, Адам (3 августа 2015 г.). «Часть конвейера: почему необходимо непрерывное тестирование» . Аналитика TechWell . Компания TechWell . Проверено 12 января 2018 г.
  59. ^ Филипп-Эдмондс, Кэмерон (5 декабря 2014 г.). «Взаимосвязь между риском и непрерывным тестированием: интервью с Уэйном Ариолой» . Прилипчивые умы . Проверено 16 января 2018 г.
  60. ^ Ариола, Уэйн; Данлоп, Синтия (октябрь 2015 г.). DevOps: вы быстрее сообщаете клиентам об ошибках? (PDF) . Тихоокеанская северо-западная конференция по качеству программного обеспечения . Проверено 16 января 2018 г.
  61. ^ Ауэрбах, Адам (2 октября 2014 г.). «Сдвиньте влево и поставьте качество на первое место» . Аналитика TechWell . Компания TechWell . Проверено 16 января 2018 г.
  62. ^ «Раздел 4.38». ISO/IEC/IEEE 29119-1:2013 – Программное обеспечение и системная инженерия – Тестирование программного обеспечения – Часть 1 – Концепции и определения . Международная организация по стандартизации . Проверено 17 января 2018 г.
  63. ^ «Шаг за шагом к глобализации: готовый к использованию во всем мире подход к тестированию. Сеть разработчиков Microsoft» . Сеть разработчиков Microsoft. Архивировано из оригинала 23 июня 2012 года . Проверено 13 января 2012 г.
  64. ^ Классен, Коэн; Хьюз, Джон (2000). «Быстрая проверка» . Материалы пятой международной конференции ACM SIGPLAN по функциональному программированию . МЦФП '00. стр. 268–279. дои : 10.1145/351240.351266 . ISBN  978-1-58113-202-1 . S2CID   5668071 . {{cite book}}: CS1 maint: дата и год ( ссылка )
  65. ^ Гельперин, Дэвид ; Хетцель, Билл (1 июня 1988 г.). «Рост тестирования программного обеспечения» . Коммуникации АКМ . 31 (6): 687–695. дои : 10.1145/62959.62965 . S2CID   14731341 .
  66. ^ Грегори, Джанет; Криспин, Лиза (2014). Больше гибкого тестирования . Аддисон-Уэсли Профессионал. стр. 23–39. ISBN  978-0-13-374956-4 .
  67. ^ «Жизненный цикл тестирования программного обеспечения» . etestinghub . Фаза тестирования в тестировании программного обеспечения . Проверено 13 января 2012 г.
  68. ^ Дастин, Эльфрида (2002). Эффективное тестирование программного обеспечения . Аддисон-Уэсли Профессионал. п. 3. ISBN  978-0-201-79429-8 .
  69. ^ Jump up to: Перейти обратно: а б «Что такое разработка через тестирование (TDD)?» . Гибкий Альянс . 5 декабря 2015 года . Проверено 17 марта 2018 г.
  70. ^ «Разработка через тестирование и непрерывная интеграция мобильных приложений» . Сеть разработчиков Microsoft . 14 января 2009 года . Проверено 17 марта 2018 г.
  71. ^ Браун, Крис; Кобб, Гэри; Калбертсон, Роберт (12 апреля 2002 г.). Введение в быстрое тестирование программного обеспечения .
  72. ^ Тран, Юшиуань (1999). «Верификация/Валидация/Сертификация» (курсовая работа). Университет Карнеги-Меллон . Проверено 13 августа 2008 г.
  73. ^ Jump up to: Перейти обратно: а б Готель, Орлена; Клеланд-Хуанг, Джейн ; Хейс, Джейн Хаффман; Зисман, Андреа; Эгед, Александр; Грюнбахер, Пауль; Дехтяр, Алекс; Антониоль, Джулиано; Малетик, Джонатан (1 января 2012 г.). Клеланд-Хуанг, Джейн; Готель, Орлена; Зисман, Андреа (ред.). Отслеживание программного обеспечения и систем . Спрингер Лондон. дои : 10.1007/978-1-4471-2239-5_1 . ISBN  9781447122388 .
  74. ^ ИИЭР (1998). Стандарт IEEE для документации по тестированию программного обеспечения . Нью-Йорк: IEEE. ISBN  978-0-7381-1443-9 .
  75. ^ Пинто, Леандро Сейлс; Синха, Саураб; Орсо, Алессандро (11 ноября 2012 г.). «Понимание мифов и реалий эволюции тестовых наборов» . Материалы 20-го Международного симпозиума ACM SIGSOFT по основам программной инженерии . Ассоциация вычислительной техники. стр. 1–11. дои : 10.1145/2393596.2393634 . ISBN  9781450316149 . S2CID   9072512 .
  76. ^ Стром, Дэвид (1 июля 2009 г.). «Мы все — часть истории» . Совместная работа по тестированию программного обеспечения и производительности. Архивировано из оригинала 31 августа 2009 года.
  77. ^ Гриффитс, М. (2005). «Обучение гибкому управлению проектами в PMI». Конференция по гибкому развитию (ADC'05) . ieee.org. стр. 318–322. дои : 10.1109/ADC.2005.45 . ISBN  978-0-7695-2487-0 . S2CID   30322339 .
  78. ^ Уиллисон, Джон С. (апрель 2004 г.). «Гибкая разработка программного обеспечения для гибких сил» . CrossTalk (апрель 2004 г.). СТСЦ. Архивировано из оригинала 29 октября 2005 года.
  79. ^ Пример: Марк Фьюстер, Дороти Грэм: Автоматизация тестирования программного обеспечения. Эддисон Уэсли, 1999 г., ISBN   978-0-201-33140-0 .
  80. ^ «стоп29119» . commonsensetesting.org . Архивировано из оригинала 2 октября 2014 года.
  81. ^ Пол Крилл (22 августа 2014 г.). «Тестировщики программного обеспечения отказываются принять предложение по стандарту ISO 29119» . Инфомир .
  82. ^ Канер, Джем (2001). «Предложение о гранте NSF, чтобы« заложить основу для значительного улучшения качества академических и коммерческих курсов по тестированию программного обеспечения »» ( PDF) . Архивировано из оригинала (PDF) 27 ноября 2009 г. Проверено 13 октября 2006 г.
  83. ^ Канер, Джем (2003). Измерение эффективности тестировщиков программного обеспечения (PDF) . ЗВЕЗДА Востока. Архивировано из оригинала (PDF) 26 марта 2010 г. Проверено 18 января 2018 г.
  84. ^ МакКоннелл, Стив (2004). Код завершен (2-е изд.). Майкрософт Пресс. п. 29 . ISBN  978-0-7356-1967-8 .
  85. ^ Боссавит, Лоран (20 ноября 2013 г.). «Цена дефектов: иллюстрированная история». Лепреконы программной инженерии: как фольклор превращается в реальность и что с этим делать . постный паб.

Дальнейшее чтение [ править ]

Внешние ссылки [ править ]

Викискладе есть медиафайлы по теме тестирования программного обеспечения .
В Викиверситете вы можете узнать больше и рассказать другим о тестировании программного обеспечения на кафедре тестирования программного обеспечения.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Software_testing&oldid=1229909840"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: fa19a38aea05b0e61690e9ca056d2d51__1718783700
URL1:https://arc.ask3.ru/arc/aa/fa/51/fa19a38aea05b0e61690e9ca056d2d51.html
Заголовок, (Title) документа по адресу, URL1:
Software testing - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)