Тестирование программного обеспечения — это исследование артефактов и поведения тестируемого программного обеспечения путем проверки и проверки. Тестирование программного обеспечения также может обеспечить объективный, независимый взгляд на программное обеспечение, позволяющий бизнесу оценить и понять риски, связанные с внедрением программного обеспечения. Методы испытаний включают, помимо прочего:
Тестирование программного обеспечения может предоставить пользователям или спонсорам объективную независимую информацию о качестве программного обеспечения и риске его сбоя. [1]
Тестирование программного обеспечения может определить правильность программного обеспечения при допущении некоторых конкретных гипотез (см. Иерархию сложности тестирования ниже), но тестирование не может выявить все сбои в программном обеспечении. [2] Вместо этого он представляет собой критику или сравнение , сравнивающее состояние и поведение продукта с тестовыми оракулами — принципами или механизмами, с помощью которых кто-то может распознать проблему. Эти предсказания могут включать (но не ограничиваться ими) спецификации, контракты , [3] сопоставимые продукты, прошлые версии того же продукта, выводы о предполагаемом или ожидаемом назначении, ожидания пользователей или клиентов, соответствующие стандарты, применимые законы или другие критерии.
Основная цель тестирования — обнаружить сбои программного обеспечения, чтобы можно было обнаружить и исправить дефекты. Тестирование не может установить, что продукт работает должным образом при всех условиях, а только то, что он не работает должным образом при определенных условиях. [4] Объем тестирования программного обеспечения может включать в себя проверку кода, а также выполнение этого кода в различных средах и условиях, а также изучение аспектов кода: делает ли он то, что должен делать, и делает ли он то, что ему нужно. делать. В современной культуре разработки программного обеспечения организация тестирования может быть отделена от команды разработчиков. Существуют различные роли членов команды тестирования. Информация, полученная в результате тестирования программного обеспечения, может использоваться для корректировки процесса разработки программного обеспечения. [5] : 41–43
У каждого программного продукта есть целевая аудитория. Например, аудитория программного обеспечения для видеоигр совершенно отличается от аудитории банковского программного обеспечения. Следовательно, когда организация разрабатывает или иным образом инвестирует в программный продукт, она может оценить, будет ли программный продукт приемлем для ее конечных пользователей , целевой аудитории, покупателей и других заинтересованных сторон. Тестирование программного обеспечения помогает в проведении этой оценки.
Сбои программного обеспечения возникают в результате следующего процесса: Программист допускает ошибку (ошибку), в результате чего возникает сбой (дефект, ошибка) в исходном коде программного обеспечения . Если эта ошибка выполняется, в определенных ситуациях система будет выдавать неверные результаты, что приведет к сбою . [6] : 31
Не все неисправности обязательно приводят к сбоям. Например, ошибки в мертвом коде никогда не приведут к сбоям. Неисправность, не выявившая отказов, может привести к отказу при изменении среды. Примеры этих изменений в среде включают запуск программного обеспечения на новой компьютерной аппаратной платформе, изменения в исходных данных или взаимодействие с другим программным обеспечением. [7] Одна-единственная неисправность может привести к широкому спектру симптомов неисправности.
Не все сбои программного обеспечения вызваны ошибками кодирования. Одним из распространенных источников дорогостоящих дефектов являются пробелы в требованиях, то есть нераспознанные требования, которые приводят к ошибкам, упущенным разработчиком программы. [5] : 426 Пробелы в требованиях часто могут быть нефункциональными требованиями, такими как тестируемость , масштабируемость , ремонтопригодность , производительность и безопасность .
Фундаментальная проблема тестирования программного обеспечения заключается в том, что тестирование при всех комбинациях входных данных и предварительных условий (начальное состояние) невозможно даже для простого продукта. [4] : 17–18 [8] Это означает, что количество ошибок в программном продукте может быть очень большим и дефекты, возникающие нечасто, трудно обнаружить при тестировании и отладке. Что еще более важно, нефункциональные аспекты качества (каким оно должно быть в сравнении с тем, что оно должно делать ) — удобство использования , масштабируемость , производительность , совместимость и надежность — могут быть весьма субъективными; то, что представляет собой достаточную ценность для одного человека, может быть невыносимо для другого.
Разработчики программного обеспечения не могут протестировать все, но они могут использовать комбинаторный дизайн тестов, чтобы определить минимальное количество тестов, необходимое для получения желаемого покрытия. Комбинаторный дизайн тестов позволяет пользователям получить большее тестовое покрытие с меньшим количеством тестов. Независимо от того, ищут ли они скорость или глубину тестирования, они могут использовать комбинаторные методы проектирования тестов для создания структурированных вариаций в своих тестовых сценариях. [9]
Исследование, проведенное NIST в 2002 году, показало, что ошибки в программном обеспечении обходятся экономике США в 59,5 миллиардов долларов ежегодно. Более трети этих затрат можно было бы избежать, если бы было проведено более качественное тестирование программного обеспечения. [10] [ сомнительно ]
Аутсорсинг тестирования программного обеспечения из-за затрат очень распространен, причем предпочтительными направлениями являются Китай, Филиппины и Индия. [11]
Тестирование программного обеспечения может проводиться специальными тестировщиками программного обеспечения; до 1980-х годов термин «тестировщик программного обеспечения» использовался вообще, но позже он стал рассматриваться и как отдельная профессия. Что касается периодов и различных целей в тестировании программного обеспечения, [12] были установлены различные роли, такие как менеджер по тестированию , руководитель тестирования , аналитик тестирования , дизайнер тестов , тестировщик , разработчик автоматизации и администратор тестирования . Тестирование программного обеспечения также может выполняться неспециализированными тестировщиками программного обеспечения. [13]
Гленфорд Дж. Майерс впервые представил разделение отладки и тестирования в 1979 году. [14] Хотя его внимание было сосредоточено на тестировании на поломку («Успешный тестовый пример — это тот, который обнаруживает еще не обнаруженную ошибку». [14] : 16 ), это проиллюстрировало желание сообщества разработчиков программного обеспечения отделить фундаментальную деятельность по разработке, такую как отладка, от проверки.
Существует множество подходов к тестированию программного обеспечения. Обзоры , пошаговые руководства или проверки называются статическим тестированием, тогда как выполнение программного кода с заданным набором тестовых случаев называется динамическим тестированием . [15] [16]
Статическое тестирование часто является неявным, например корректура, а также когда инструменты программирования/текстовые редакторы проверяют структуру исходного кода или компиляторы (прекомпиляторы) проверяют синтаксис и поток данных в ходе статического анализа программы . Динамическое тестирование происходит при запуске самой программы. Динамическое тестирование может начаться до того, как программа будет завершена на 100%, чтобы протестировать отдельные разделы кода и применить их к отдельным функциям или модулям. [15] [16] Типичными методами для этого являются либо использование заглушек /драйверов, либо выполнение из среды отладчика . [16]
Статическое тестирование включает в себя проверку , тогда как динамическое тестирование также включает в себя проверку . [16]
Пассивное тестирование означает проверку поведения системы без какого-либо взаимодействия с программным продуктом. В отличие от активного тестирования, тестировщики не предоставляют никаких тестовых данных, а просматривают системные журналы и трассировки. Они изучают закономерности и конкретное поведение, чтобы принять какие-то решения. [17] Это связано с автономной проверкой времени выполнения и анализом журналов .
Тип стратегии тестирования, которую необходимо выполнить, зависит от того, следует ли определять тесты, которые будут применяться к ТР, до начала выполнения плана тестирования (предварительно заданное тестирование [20] ) или каждый входной сигнал, который будет применяться к ТР, может быть динамически изменен. зависит от результатов, полученных в ходе применения предыдущих тестов (адаптивное тестирование [21] [22] ). Хотя планы адаптивного тестирования сложнее определить, было показано, что они предоставляют больше информации о правильности или неправильности IUT с меньшими усилиями по тестированию, даже если возможные правильные и неправильные поведения IUT, которые необходимо разделить, просто перечисляются. одним. [23] Принимая во внимание результаты предыдущих взаимодействий, выбранные последующие тесты могут сосредоточиться на отработке взаимодействий, которые с большей вероятностью выявят в каждом конкретном случае разницу между правильностью и неправильностью.
Методы тестирования программного обеспечения традиционно делятся на тестирование «белого ящика» и «черного ящика». Эти два подхода используются для описания точки зрения, которую придерживается тестировщик при разработке тестовых случаев. Гибридный подход, называемый тестированием серого ящика, также может быть применен к методологии тестирования программного обеспечения. [24] [25] С ростом популярности концепции тестирования «серого ящика», которое разрабатывает тесты на основе конкретных элементов дизайна, это «произвольное различие» между тестированием «черного и белого ящика» несколько исчезло. [26]
Тестирование белого ящика (также известное как тестирование прозрачного ящика, тестирование стеклянного ящика, тестирование прозрачного ящика и структурное тестирование) проверяет внутреннюю структуру или работу программы, а не функциональность, доступную конечному пользователю. При тестировании «белого ящика» для разработки тестовых примеров используется внутренняя перспектива системы (исходный код), а также навыки программирования. Тестер выбирает входные данные для проверки путей прохождения кода и определения соответствующих выходных данных. [24] [25] Это аналогично тестированию узлов в цепи, например, внутрисхемному тестированию (ICT).
Хотя тестирование «белого ящика» может применяться на уровне модуля , интеграции и системы процесса тестирования программного обеспечения, обычно оно выполняется на уровне модуля. [26] Он может тестировать пути внутри модуля, пути между модулями во время интеграции и между подсистемами во время тестирования на уровне системы. Хотя этот метод проектирования тестов может выявить множество ошибок или проблем, он может не выявить нереализованные части спецификации или отсутствующие требования.
Методы, используемые при тестировании «белого ящика», включают: [25] [27]
Инструменты покрытия кода могут оценить полноту набора тестов, созданного любым методом, включая тестирование «черного ящика». Это позволяет команде разработчиков программного обеспечения исследовать части системы, которые редко тестируются, и гарантирует, что наиболее важные функциональные точки были протестированы. [28] Покрытие кода как метрика программного обеспечения может быть представлена в процентах для: [24] [28] [29]
100%-ное покрытие операторов гарантирует, что все пути или ветви кода (с точки зрения потока управления ) будут выполнены хотя бы один раз. Это полезно для обеспечения правильной функциональности, но недостаточно, поскольку один и тот же код может правильно или неправильно обрабатывать разные входные данные. [30]
Тестирование «черного ящика» (также известное как функциональное тестирование) рассматривает программное обеспечение как «черный ящик», проверяя функциональность без каких-либо знаний о внутренней реализации и без просмотра исходного кода. Тестировщикам известно только то, что должно делать программное обеспечение, а не то, как оно это делает. [31] Методы тестирования «черного ящика» включают в себя: разделение эквивалентности , анализ граничных значений , всепарное тестирование , таблицы перехода состояний , тестирование таблицы решений , нечеткое тестирование , тестирование на основе моделей , тестирование вариантов использования , исследовательское тестирование и тестирование на основе спецификаций. . [24] [25] [29]
Тестирование на основе спецификаций направлено на проверку функциональности программного обеспечения в соответствии с применимыми требованиями. [32] Этот уровень тестирования обычно требует, чтобы тестировщику были предоставлены подробные тестовые примеры , которые затем могут просто проверить, что для данного входного значения выходное значение (или поведение) либо «является», либо «не совпадает» с ожидаемое значение, указанное в тестовом примере. Тестовые примеры строятся вокруг спецификаций и требований, т. е. того, что приложение должно делать. Для создания тестовых примеров он использует внешние описания программного обеспечения, включая спецификации, требования и проекты. Эти тесты могут быть функциональными и нефункциональными , но обычно функциональными.
Тестирование на основе спецификаций может быть необходимо для обеспечения правильной функциональности, но его недостаточно для защиты от сложных ситуаций или ситуаций высокого риска. [33]
Одним из преимуществ метода черного ящика является то, что не требуется никаких знаний программирования. Какие бы предубеждения ни были у программистов, у тестировщика скорее всего другой набор и он может подчеркивать разные области функциональности. С другой стороны, тестирование «черного ящика» похоже на «прогулку по темному лабиринту без фонарика». [34] Поскольку они не исследуют исходный код, бывают ситуации, когда тестировщик пишет множество тестовых примеров, чтобы проверить что-то, что можно было бы протестировать только одним тестовым примером, или оставляет некоторые части программы непроверенными.
Этот метод тестирования можно применять на всех уровнях тестирования программного обеспечения: модульном , интеграционном , системном и приемочном . [26] Обычно оно включает в себя большую часть, если не все, тестирование на более высоких уровнях, но также может доминировать и над модульным тестированием.
Тестирование интерфейса компонентов
Тестирование интерфейса компонента — это вариант тестирования «черного ящика» , в котором основное внимание уделяется значениям данных, а не только связанным действиям компонента подсистемы. [35] Практика тестирования интерфейсов компонентов может использоваться для проверки обработки данных, передаваемых между различными блоками или компонентами подсистемы, помимо тестирования полной интеграции между этими блоками. [36] [37] Передаваемые данные можно рассматривать как «пакеты сообщений», а диапазон или типы данных могут быть проверены на предмет данных, сгенерированных одним устройством, и проверены на достоверность перед передачей в другое устройство. Одним из вариантов тестирования интерфейса является ведение отдельного файла журнала передаваемых элементов данных, часто с регистрируемой временной меткой, что позволяет анализировать тысячи случаев передачи данных между устройствами в течение дней или недель. Тесты могут включать проверку обработки некоторых экстремальных значений данных, в то время как другие переменные интерфейса передаются как нормальные значения. [36] Необычные значения данных в интерфейсе могут помочь объяснить неожиданную производительность в следующем модуле.
Цель визуального тестирования — предоставить разработчикам возможность изучить, что происходило в момент сбоя программного обеспечения, представляя данные таким образом, чтобы разработчик мог легко найти необходимую ему информацию, и эта информация была выражена четко. . [38] [39]
В основе визуального тестирования лежит идея о том, что демонстрация проблемы (или неудачного теста), а не просто ее описание, значительно повышает ясность и понимание. Таким образом, визуальное тестирование требует записи всего процесса тестирования – записи всего, что происходит в тестовой системе, в видеоформате. Выходные видео дополняются входными данными тестера в режиме реального времени через веб-камеру «картинка в картинке» и аудиокомментариями с микрофонов.
Визуальное тестирование дает ряд преимуществ. Качество связи значительно повышается, поскольку тестировщики могут показать разработчику проблему (и события, которые привели к ней), а не просто описать ее, и во многих случаях необходимость воспроизводить неудачные тесты перестанет существовать. У разработчика будут все необходимые доказательства неудачного теста, и он сможет вместо этого сосредоточиться на причине ошибки и способах ее устранения.
Специальное тестирование и исследовательское тестирование являются важными методологиями проверки целостности программного обеспечения, поскольку для их реализации требуется меньше времени на подготовку, а важные ошибки можно найти быстро. [40] При специальном тестировании, когда тестирование проводится импровизированным, импровизированным способом, способность тестировщика(ов) основывать тестирование на документированных методах, а затем импровизировать варианты этих тестов может привести к более тщательному изучению исправлений дефектов. [40] Однако, если не ведется строгая документация процедур, одним из ограничений специального тестирования является отсутствие повторяемости. [40]
Тестирование серого ящика (американское написание: тестирование серого ящика) предполагает знание внутренних структур данных и алгоритмов для целей разработки тестов при выполнении этих тестов на уровне пользователя или черного ящика. Тестер часто имеет доступ как к «исходному коду, так и к исполняемому двоичному файлу». [41] Тестирование «серого ящика» может также включать обратное проектирование (с использованием динамического анализа кода) для определения, например, граничных значений или сообщений об ошибках. [41] Манипулирование входными данными и форматирование выходных данных не квалифицируются как «серый ящик», поскольку входные и выходные данные явно находятся за пределами «черного ящика», который мы называем тестируемой системой. Это различие особенно важно при проведении интеграционного тестирования между двумя модулями кода, написанными двумя разными разработчиками, когда тесту подвергаются только интерфейсы.
Зная основные концепции работы программного обеспечения, тестировщик делает более обоснованный выбор при тестировании при внешнем тестировании программного обеспечения. Обычно тестировщику «серого ящика» разрешается создать изолированную среду тестирования с такими действиями, как заполнение базы данных . Тестер может наблюдать за состоянием тестируемого продукта после выполнения определенных действий, таких как выполнение операторов SQL для базы данных, а затем выполнение запросов, чтобы убедиться, что ожидаемые изменения были отражены. Тестирование «серого ящика» реализует интеллектуальные сценарии тестирования, основанные на ограниченной информации. Это особенно применимо к обработке типов данных, обработке исключений и т. д. [42]
Вообще говоря, существует как минимум три уровня тестирования: модульное тестирование, интеграционное тестирование и системное тестирование. [43] [44] [45] [46] Однако разработчики могут включить четвертый уровень — приемочное тестирование. Это может быть в форме эксплуатационного приемочного тестирования или простого (бета-тестирования) конечного пользователя, проверки соответствия программного обеспечения функциональным ожиданиям. [47] [48] [49] Согласно программе ISTQB Certified Test Foundation Level, уровни тестирования включают эти четыре уровня, а четвертый уровень называется приемочным тестированием. [50] Тесты часто группируются в один из этих уровней в зависимости от того, где они добавляются в процессе разработки программного обеспечения, или по уровню специфичности теста.
Модульное тестирование — это тесты, которые проверяют функциональность определенного раздела кода, обычно на функциональном уровне. В объектно-ориентированной среде это обычно происходит на уровне класса, а минимальные модульные тесты включают конструкторы и деструкторы. [51]
Эти типы тестов обычно пишутся разработчиками во время работы над кодом (стиль «белого ящика»), чтобы гарантировать, что конкретная функция работает должным образом. Одна функция может иметь несколько тестов для выявления крайних случаев или других ветвей кода. Модульное тестирование само по себе не может проверить функциональность части программного обеспечения, а скорее используется для обеспечения того, чтобы строительные блоки программного обеспечения работали независимо друг от друга.
Модульное тестирование — это процесс разработки программного обеспечения, который включает синхронизированное применение широкого спектра стратегий предотвращения и обнаружения дефектов с целью снижения рисков, времени и затрат на разработку программного обеспечения. Это выполняется разработчиком или инженером программного обеспечения на этапе создания жизненного цикла разработки программного обеспечения. Модульное тестирование направлено на устранение ошибок конструкции до того, как код будет переведен на дополнительное тестирование; эта стратегия предназначена для повышения качества получаемого программного обеспечения, а также эффективности всего процесса разработки.
В зависимости от ожиданий организации в отношении разработки программного обеспечения модульное тестирование может включать статический анализ кода , анализ потока данных , анализ метрик, одноранговые проверки кода, анализ покрытия кода и другие методы тестирования программного обеспечения.
Интеграционное тестирование — это любой тип тестирования программного обеспечения, целью которого является проверка интерфейсов между компонентами на соответствие проекту программного обеспечения. Программные компоненты могут быть интегрированы итерационным способом или все вместе («большой взрыв»). Обычно первый вариант считается лучшим, поскольку он позволяет быстрее обнаруживать и устранять проблемы интерфейса.
Интеграционное тестирование направлено на выявление дефектов в интерфейсах и взаимодействии между интегрированными компонентами (модулями). Все большие группы тестируемых компонентов программного обеспечения, соответствующие элементам архитектурного проекта, интегрируются и тестируются до тех пор, пока программное обеспечение не начнет работать как система. [52]
Системное тестирование проверяет полностью интегрированную систему, чтобы убедиться, что система соответствует ее требованиям. [6] : 74 Например, системный тест может включать тестирование интерфейса входа в систему, затем создание и редактирование записи, а также отправку или печать результатов с последующей суммарной обработкой или удалением (или архивированием) записей и выходом из системы.
Приемочные испытания обычно включают в себя следующие четыре типа: [50]
UAT, а также альфа- и бета-тестирование описаны в следующем разделе типов тестирования.
Эксплуатационная приемка используется для проведения эксплуатационной готовности (предварительного выпуска) продукта, услуги или системы в рамках системы менеджмента качества . OAT — это распространенный тип нефункционального тестирования программного обеспечения, используемый в основном в проектах разработки и сопровождения программного обеспечения . Этот тип тестирования фокусируется на эксплуатационной готовности системы, которая будет поддерживаться или станет частью производственной среды. Следовательно, оно также известно как тестирование эксплуатационной готовности (ORT) или тестирование эксплуатационной готовности и обеспечения (OR&A). Функциональное тестирование в рамках OAT ограничивается теми тестами, которые необходимы для проверки нефункциональных аспектов системы.
Кроме того, тестирование программного обеспечения должно гарантировать, что переносимость системы, а также ее ожидаемая работа не повреждают или частично не повреждают ее операционную среду или не приводят к выходу из строя других процессов в этой среде. [53]
Договорное приемочное тестирование проводится на основе договорных критериев приемки, определенных при заключении договора, а нормативное приемочное тестирование проводится на основе соответствующих нормативных актов к программному продукту. Оба этих двух тестирования могут выполняться пользователями или независимыми тестировщиками. Приемочные испытания по правилам иногда включают в себя проверку результатов испытаний регулирующими органами. [50]
Различные ярлыки и способы группировки тестирования могут быть типами тестирования, тактиками или методами тестирования программного обеспечения. [54]
Большинство программных систем имеют процедуры установки, которые необходимы, прежде чем их можно будет использовать по своему основному назначению. Тестирование этих процедур для получения установленной программной системы, которую можно использовать, называется установочным тестированием . [55] : 139 Эта процедура может включать полное или частичное обновление, а также процессы установки/удаления.
Распространенной причиной сбоя программного обеспечения (реального или предполагаемого) является отсутствие его совместимости с другим прикладным программным обеспечением , операционными системами (или версиями операционных систем , старыми или новыми) или целевыми средами, которые сильно отличаются от оригинала (например, терминал или Приложение с графическим интерфейсом , предназначенное для запуска на рабочем столе , теперь должно стать веб-приложением , которое должно отображаться в веб-браузере ). Например, в случае отсутствия обратной совместимости это может произойти из-за того, что программисты разрабатывают и тестируют программное обеспечение только в последней версии целевой среды, которую могут использовать не все пользователи. Это приводит к непредвиденным последствиям: последняя работа может не работать на более ранних версиях целевой среды или на более старом оборудовании, которое могли использовать более ранние версии целевой среды. Иногда такие проблемы можно решить, заранее вынеся функциональные возможности операционной системы в отдельный программный модуль или библиотеку .
Проверка работоспособности определяет, целесообразно ли продолжать дальнейшее тестирование.
Дымовое тестирование состоит из минимальных попыток эксплуатации программного обеспечения, предназначенных для определения наличия каких-либо основных проблем, которые вообще мешают его работе. Такие тесты можно использовать в качестве проверочного теста сборки .
Регрессионное тестирование направлено на поиск дефектов после внесения серьезных изменений в код. В частности, он стремится выявить регрессии программного обеспечения , то есть деградацию или потерю функций, включая старые ошибки, которые вернулись. Такие регрессии происходят всякий раз, когда функциональные возможности программного обеспечения, которые ранее работали правильно, перестают работать должным образом. Обычно регрессии возникают как непреднамеренное последствие изменений программы, когда вновь разработанная часть программного обеспечения сталкивается с ранее существовавшим кодом. Регрессионное тестирование, как правило, является крупнейшим испытанием при разработке коммерческого программного обеспечения [56] из-за проверки многочисленных деталей предыдущих функций программного обеспечения, и даже новое программное обеспечение может быть разработано с использованием некоторых старых тестовых примеров для тестирования частей нового дизайна, чтобы гарантировать предыдущую функциональность. все еще поддерживается.
Общие методы регрессионного тестирования включают повторный запуск предыдущих наборов тестовых случаев и проверку того, не возникли ли ранее исправленные ошибки снова. Глубина тестирования зависит от этапа процесса выпуска и риска , связанного с добавленными функциями. Они могут быть либо полными для изменений, добавленных в конце выпуска или считающихся рискованными, либо очень поверхностными, состоящими из положительных тестов по каждой функции, если изменения происходят на ранней стадии выпуска или считаются несущими низкий риск.
Приемочное тестирование может означать одно из двух:
Альфа-тестирование — это моделируемое или фактическое эксплуатационное тестирование, проводимое потенциальными пользователями/заказчиками или независимой группой тестирования на площадке разработчиков. Альфа-тестирование часто используется для готового программного обеспечения как форма внутреннего приемочного тестирования перед тем, как программное обеспечение перейдет на бета-тестирование. [57]
Бета-тестирование проводится после альфа-тестирования и может рассматриваться как форма приемочного тестирования внешним пользователем . Версии программного обеспечения, известные как бета-версии , выпускаются для ограниченной аудитории за пределами группы программистов, известной как бета-тестеры. Программное обеспечение предоставляется группам людей, чтобы дальнейшее тестирование могло гарантировать, что в продукте мало сбоев или ошибок . Бета-версии могут быть доступны для широкой публики, чтобы расширить поле обратной связи до максимального числа будущих пользователей и принести пользу раньше, в течение длительного или даже неопределенного периода времени ( бессрочная бета-версия ). [58]
Функциональное тестирование относится к действиям, которые проверяют определенное действие или функцию кода. Обычно их можно найти в документации по требованиям к коду, хотя некоторые методологии разработки основаны на сценариях использования или пользовательских историях. Функциональные тесты, как правило, отвечают на вопрос «может ли пользователь это сделать» или «работает ли эта конкретная функция».
Нефункциональное тестирование относится к аспектам программного обеспечения, которые могут не быть связаны с конкретной функцией или действием пользователя, например, масштабируемость или другая производительность , поведение при определенных ограничениях или безопасность . Тестирование определит точку разрыва, точку, в которой крайности масштабируемости или производительности приводят к нестабильному выполнению. Нефункциональные требования, как правило, отражают качество продукта, особенно в контексте пригодности его пользователей.
Непрерывное тестирование — это процесс выполнения автоматических тестов в рамках конвейера доставки программного обеспечения для получения немедленной информации о бизнес-рисках, связанных с кандидатом на выпуск программного обеспечения. [59] [60] Непрерывное тестирование включает проверку как функциональных , так и нефункциональных требований ; Объем тестирования простирается от проверки восходящих требований или пользовательских историй до оценки системных требований, связанных с общими бизнес-целями. [61] [62]
Разрушающее тестирование пытается вызвать сбой программного обеспечения или подсистемы. Он проверяет правильность работы программного обеспечения, даже если оно получает неверные или неожиданные входные данные, тем самым обеспечивая надежность процедур проверки входных данных и управления ошибками. [ нужна цитация ] Внедрение ошибок программного обеспечения в форме фаззинга является примером тестирования на отказ. На странице внесения ошибок программного обеспечения имеются ссылки на различные коммерческие инструменты нефункционального тестирования ; Существует также множество инструментов с открытым исходным кодом и бесплатного программного обеспечения, которые выполняют разрушительное тестирование.
Тестирование производительности обычно проводится для определения того, как система или подсистема работает с точки зрения скорости реагирования и стабильности при определенной рабочей нагрузке. Он также может служить для исследования, измерения, проверки или проверки других показателей качества системы, таких как масштабируемость, надежность и использование ресурсов.
Нагрузочное тестирование в первую очередь связано с проверкой того, может ли система продолжать работать при определенной нагрузке, будь то большие объемы данных или большое количество пользователей . Обычно это называется масштабируемостью программного обеспечения . Соответствующее нагрузочное тестирование, выполняемое в качестве нефункциональной деятельности, часто называют тестированием на выносливость . Объемное тестирование — это способ протестировать функции программного обеспечения, даже если некоторые компоненты (например, файл или база данных) радикально увеличиваются в размерах. Стресс-тестирование — это способ проверить надежность при неожиданных или редких рабочих нагрузках. Тестирование стабильности (часто называемое нагрузочным тестированием или тестированием на выносливость) проверяет, может ли программное обеспечение непрерывно функционировать в течение приемлемого периода или сверх него.
Существует мало согласия относительно того, каковы конкретные цели тестирования производительности. Термины нагрузочное тестирование, тестирование производительности, тестирование масштабируемости и объемное тестирование часто используются как взаимозаменяемые.
Программные системы реального времени имеют строгие временные ограничения. Чтобы проверить, соблюдаются ли временные ограничения, используется тестирование в реальном времени .
Юзабилити-тестирование предназначено для проверки простоты и понимания пользовательского интерфейса. В основном это касается использования приложения. Это не тот тип тестирования, который можно автоматизировать; необходимы реальные пользователи-люди, за которыми следят опытные дизайнеры пользовательского интерфейса .
Тестирование доступности проводится для обеспечения доступности программного обеспечения для людей с ограниченными возможностями. Некоторые из распространенных тестов веб-доступности:
Общие стандарты соответствия
Тестирование безопасности необходимо для программного обеспечения, которое обрабатывает конфиденциальные данные, чтобы предотвратить вторжение в систему хакеров .
Международная организация по стандартизации (ISO) определяет это как «тип тестирования, проводимый для оценки степени, в которой объект тестирования и связанные с ним данные и информация защищены так, что неуполномоченные лица или системы не могут их использовать, читать или изменять, и авторизованным лицам или системам не отказано в доступе к ним». [63]
Тестирование на интернационализацию и локализацию подтверждает, что программное обеспечение можно использовать с разными языками и географическими регионами. Процесс псевдолокализации используется для проверки возможности перевода приложения на другой язык и облегчения определения случаев, когда процесс локализации может привести к появлению новых ошибок в продукте.
Тестирование на глобализацию подтверждает, что программное обеспечение адаптировано к новой культуре (например, к разным валютам или часовым поясам). [64]
Фактический перевод на человеческие языки также должен быть проверен. Возможные неудачи локализации и глобализации включают в себя:
Тестирование разработки — это процесс разработки программного обеспечения, который включает синхронизированное применение широкого спектра стратегий предотвращения и обнаружения дефектов с целью снижения рисков, времени и затрат на разработку программного обеспечения. Это выполняется разработчиком или инженером программного обеспечения на этапе создания жизненного цикла разработки программного обеспечения. Тестирование разработки направлено на устранение ошибок конструкции до того, как код будет переведен на другое тестирование; эта стратегия предназначена для повышения качества получаемого программного обеспечения, а также эффективности всего процесса разработки.
В зависимости от ожиданий организации в отношении разработки программного обеспечения, тестирование разработки может включать статический анализ кода , анализ потока данных, анализ метрик, одноранговые проверки кода, модульное тестирование, анализ покрытия кода, отслеживаемость и другие методы тестирования программного обеспечения.
A/B-тестирование — это метод проведения контролируемого эксперимента, чтобы определить, является ли предлагаемое изменение более эффективным, чем текущий подход. Клиентов перенаправляют либо к текущей версии (контроль) функции, либо к модифицированной версии (обработка), и данные собираются, чтобы определить, какая версия лучше подходит для достижения желаемого результата.
Параллельное или параллельное тестирование оценивает поведение и производительность программного обеспечения и систем, использующих параллельные вычисления , как правило, при нормальных условиях использования. Типичными проблемами, которые выявляются при этом типе тестирования, являются взаимоблокировки, состояния гонки и проблемы с обработкой общей памяти/ресурсов.
При тестировании программного обеспечения тестирование на соответствие проверяет, что продукт работает в соответствии с установленными стандартами. Например, компиляторы тщательно проверяются на предмет соответствия признанным стандартам данного языка.
Создание ожидаемого результата отображения, будь то сравнение данных текста или снимков экрана пользовательского интерфейса, [4] : 195 иногда называют тестированием моментальных снимков или Золотым мастер-тестированием, в отличие от многих других форм тестирования, оно не может обнаруживать сбои автоматически и вместо этого требует, чтобы человек оценить результат на наличие несоответствий.
Тестирование свойств — это метод тестирования, при котором вместо того, чтобы утверждать, что определенные входные данные приводят к конкретным ожидаемым результатам, практикующий специалист случайным образом генерирует множество входных данных, запускает программу на всех из них и утверждает истинность некоторого «свойства», которое должно быть истинным для каждой пары. ввода и вывода. Например, каждый вывод функции сериализации должен приниматься соответствующей функцией десериализации, а каждый вывод функции сортировки должен представлять собой монотонно возрастающий список, содержащий точно такие же элементы, что и входные данные.
Библиотеки тестирования свойств позволяют пользователю контролировать стратегию, с помощью которой создаются случайные входные данные, чтобы обеспечить покрытие вырожденных случаев или входные данные с определенными шаблонами, которые необходимы для полной реализации аспектов тестируемой реализации.
Тестирование свойств также иногда называют «генеративным тестированием» или «тестированием QuickCheck», поскольку оно было представлено и популяризировано библиотекой Haskell QuickCheck . [65]
Метаморфическое тестирование (MT) — это метод тестирования программного обеспечения, основанный на свойствах, который может быть эффективным подходом для решения проблемы тестового оракула и проблемы создания тестовых примеров. Проблема тестового оракула заключается в сложности определения ожидаемых результатов выбранных тестовых случаев или определения того, согласуются ли фактические результаты с ожидаемыми результатами.
Тестирование видеомагнитофона, также известное как «тестирование воспроизведения» или тестирование «запись/воспроизведение», представляет собой метод тестирования, позволяющий повысить надежность и скорость регрессионных тестов, в которых используется медленный или ненадежный для взаимодействия компонент, часто сторонний API. вне контроля тестера. Он включает в себя запись («кассету») взаимодействия системы с внешним компонентом, а затем воспроизведение записанных взаимодействий вместо общения с внешней системой при последующих запусках теста.
Этот метод был популяризирован в веб-разработке благодаря библиотеке Ruby vcr.
Обычной практикой каскадной разработки является то, что тестирование выполняется независимой группой тестировщиков. Это может произойти:
Однако даже в каскадной модели разработки модульное тестирование часто выполняется командой разработчиков программного обеспечения, даже если дальнейшее тестирование выполняется отдельной командой. [68]
Напротив, некоторые новые дисциплины программного обеспечения, такие как экстремальное программирование и движение за гибкую разработку программного обеспечения , придерживаются модели « разработки программного обеспечения на основе тестирования ». В этом процессе модульные тесты сначала пишутся разработчиками программного обеспечения (часто с использованием парного программирования в экстремальной методологии программирования). Ожидается, что тесты поначалу пройдут неудачно. За каждым неудачным тестом пишется ровно столько кода, чтобы он прошел. [69] Это означает, что наборы тестов постоянно обновляются по мере обнаружения новых условий отказа и крайних случаев, и они интегрируются со всеми разрабатываемыми регрессионными тестами. Модульные тесты поддерживаются вместе с остальной частью исходного кода программного обеспечения и обычно интегрируются в процесс сборки (при этом интерактивные тесты по своей сути отводятся к частично ручному процессу приемки сборки).
Конечная цель этого процесса тестирования — поддержка непрерывной интеграции и снижение уровня дефектов. [70] [69]
Эта методология увеличивает усилия по тестированию, выполняемые разработчиками, прежде чем они попадут в какую-либо официальную команду тестирования. В некоторых других моделях разработки большая часть выполнения тестов происходит после того, как были определены требования и завершен процесс кодирования.
Хотя между организациями существуют различия, существует типичный цикл тестирования. [2] Приведенный ниже пример часто встречается в организациях, использующих модель разработки «Водопад» . Те же методы обычно встречаются и в других моделях разработки, но они могут быть не такими ясными и явными.
Многие группы программистов [ как кто? ] все больше и больше [ неопределенно ] полагаются на автоматическое тестирование , особенно группы, которые используют разработку через тестирование . Существует множество фреймворков [ укажите ] для написания тестов, и программное обеспечение непрерывной интеграции автоматически запускает тесты каждый раз, когда код проверяется в системе контроля версий .
Хотя автоматизация не может воспроизвести все, что может сделать человек (и все способы, которыми он это делает), она может быть очень полезна для регрессионного тестирования. Однако для того, чтобы он был по-настоящему полезным, требуется хорошо разработанный набор тестовых сценариев.
Тестированию программ и обнаружению ошибок могут существенно помочь инструменты тестирования и отладчики . Инструменты тестирования/отладки включают в себя такие функции, как:
Некоторые из этих функций могут быть включены в один составной инструмент или интегрированную среду разработки (IDE).
Тестирование с захватом и воспроизведением заключается в сборе сценариев сквозного использования при взаимодействии с приложением и превращении этих сценариев в тестовые примеры. Возможные применения захвата и воспроизведения включают создание регрессионных тестов. Инструмент SCARPE [71] выборочно фиксирует подмножество исследуемого приложения по мере его выполнения. JRapture фиксирует последовательность взаимодействий между исполняемой программой Java и компонентами хост-системы, такими как файлы или события в графических пользовательских интерфейсах. Эти последовательности затем можно воспроизвести для тестирования на основе наблюдений. [72] Саиева и др. предлагают создавать специальные тесты, которые воспроизводят записанные следы выполнения пользователя, чтобы проверить возможные исправления на наличие критических ошибок безопасности. [73]
Меры качества включают такие темы, как правильность , полнота, безопасность и требования ISO/IEC 9126 , такие как возможности, надежность , эффективность , переносимость , ремонтопригодность , совместимость и удобство использования .
Существует ряд часто используемых метрик или показателей программного обеспечения, которые помогают определить состояние программного обеспечения или адекватность тестирования.
На основе количества тестовых примеров, необходимых для создания полного набора тестов в каждом контексте (т. е. такого набора тестов, который, если он применяется к тестируемой реализации, позволяет собрать достаточно информации, чтобы точно определить, правильна или неверна система) согласно некоторой спецификации) была предложена иерархия сложности тестирования. [74] [75] Он включает следующие классы контролепригодности :
Доказано, что каждый класс строго входит в следующий. Например, тестирование, когда мы предполагаем, что поведение тестируемой реализации может быть обозначено детерминированным конечным автоматом для некоторых известных конечных наборов входных и выходных данных и с некоторым известным числом состояний, принадлежит классу I (и всем последующим классам). ). Однако если количество состояний неизвестно, то оно принадлежит только всем классам, начиная с класса II. Если тестируемая реализация должна быть детерминированным конечным автоматом, не удовлетворяющим спецификации для одной трассы (и ее продолжений), и количество ее состояний неизвестно, то она принадлежит только классам, начиная с класса III. Тестирование темпоральных машин, в которых переходы срабатывают, если входные данные производятся в пределах некоторого действительно ограниченного интервала, принадлежит только классам, начиная с класса IV, тогда как тестирование многих недетерминированных систем принадлежит только классу V (но не всем, а некоторые даже принадлежат классу I). ). Включение в класс I не требует простоты предполагаемой модели вычислений, поскольку было доказано, что некоторые тестовые случаи, включающие реализации, написанные на любом языке программирования, и тестовые реализации, определяемые как машины, зависящие от непрерывных величин, относятся к классу I. Другие разработанные случаи, такие как среда тестирования Мэтью Хеннесси с обязательной семантикой и темпоральные машины с рациональными тайм-аутами, относятся к классу II.
Процесс тестирования программного обеспечения может привести к появлению нескольких артефактов . Фактически создаваемые артефакты зависят от используемой модели разработки программного обеспечения, потребностей заинтересованных сторон и организации.
План тестирования — это документ, подробно описывающий подход, который будет применяться к намеченным действиям по тестированию. План может включать такие аспекты, как цели, объем, процессы и процедуры, требования к персоналу и планы действий в чрезвычайных ситуациях. [47] План тестирования может иметь форму единого плана, включающего все типы тестирования (например, план приемочного или системного тестирования) и соображения по планированию, или он может быть выпущен в виде генерального плана тестирования, который обеспечивает обзор более чем один подробный план испытаний (план плана). [47] В некоторых случаях план тестирования может быть частью широкой « стратегии тестирования », которая документирует общие подходы к тестированию, что само по себе может быть генеральным планом тестирования или даже отдельным артефактом.
Тестовый пример обычно состоит из уникального идентификатора, ссылок на требования из спецификации проекта, предварительных условий, событий, серии шагов (также известных как действия), которые необходимо выполнить, ввода, вывода, ожидаемого результата и фактического результата. С клинической точки зрения тестовый пример — это входные данные и ожидаемый результат. [77] Это может быть так же кратко, как «для условия x ваш полученный результат равен y», хотя обычно тестовые примеры более подробно описывают входной сценарий и ожидаемые результаты. Иногда это может быть серия шагов (но часто шаги содержатся в отдельной процедуре тестирования, которую из соображений экономии можно проводить на нескольких тестовых примерах), но с одним ожидаемым результатом или ожидаемым результатом. Необязательными полями являются идентификатор тестового набора, шаг теста или номер порядка выполнения, связанные требования, глубина, категория теста, автор и флажки, указывающие, является ли тест автоматизированным и был ли он автоматизирован. Более крупные тестовые примеры могут также содержать обязательные состояния или шаги, а также описания. Тестовый пример также должен содержать место для фактического результата. Эти шаги можно сохранить в документе текстового процессора, электронной таблице, базе данных или других распространенных репозиториях. В системе базы данных вы также можете увидеть результаты прошлых тестов, узнать, кто сгенерировал результаты, и какая конфигурация системы использовалась для получения этих результатов. Эти прошлые результаты обычно хранятся в отдельной таблице.
Тестовый сценарий — это процедура или программный код, который воспроизводит действия пользователя. Первоначально этот термин был получен из продукта работы, созданного с помощью инструментов автоматического регрессионного тестирования. Тестовый пример будет основой для создания тестовых сценариев с использованием инструмента или программы.
В большинстве случаев для проверки одной и той же функциональности определенной функции используется несколько наборов значений или данных. Все тестовые значения и изменяемые компоненты окружающей среды собираются в отдельные файлы и сохраняются как тестовые данные. Также полезно предоставить эти данные клиенту вместе с продуктом или проектом. Существуют методы генерации тестовых данных.
Программное обеспечение, инструменты, примеры ввода и вывода данных, а также конфигурации — все вместе называется « тестовым оборудованием» .
Тестовый запуск — это набор тестовых примеров или наборов тестов, которые выполняет пользователь и сравнивает ожидаемые с фактическими результатами. После завершения может быть создан отчет или все выполненные тесты.
Существует несколько программ сертификации для поддержки профессиональных стремлений тестировщиков программного обеспечения и специалистов по обеспечению качества. Некоторые практики утверждают, что область тестирования не готова к сертификации, как упоминалось в разделе, посвященном разногласиям.
Некоторые из основных противоречий в тестировании программного обеспечения включают в себя:
Принято считать, что чем раньше обнаружен дефект, тем дешевле его устранить. В следующей таблице указана стоимость устранения дефекта в зависимости от стадии его обнаружения. [87] Например, если проблема в требованиях обнаруживается только после выпуска, то ее исправление будет стоить в 10–100 раз дороже, чем если бы она уже была обнаружена в ходе проверки требований. С появлением современных методов непрерывного развертывания и облачных сервисов стоимость повторного развертывания и обслуживания может со временем снизиться.
Данные, на основе которых экстраполируется эта таблица, скудны. Лоран Боссавит говорит в своем анализе:
Кривая «меньших проектов» оказывается полученной только от двух групп студентов-первокурсников, а размер выборки настолько мал, что экстраполяция на «меньшие проекты в целом» совершенно неоправданна. Исследование GTE не объясняет свои данные, за исключением того, что они получены из двух проектов: большого и маленького. В документе, цитируемом для проекта Bell Labs «Safeguard», прямо отрицается сбор детальных данных, которые предполагают данные Боэма. Исследование IBM (статья Фэгана) содержит утверждения, которые, кажется, противоречат графику Бома, и не содержит числовых результатов, которые явно соответствовали бы его данным.
Бём даже не цитирует документ, подтверждающий данные TRW, за исключением статьи для «Making Software» в 2010 году, где он цитирует оригинальную статью 1976 года. Существует большое исследование, проведенное в TRW как раз в то время, когда Бем мог его процитировать, но эта статья не содержит данных, подтверждающих утверждения Бема. [88]
Тестирование программного обеспечения используется в сочетании с проверкой и проверкой : [89]
Термины «верификация» и «валидация» обычно используются в отрасли как синонимы; Также часто можно увидеть, что эти два термина имеют противоречивые определения. Согласно Стандартному глоссарию терминологии программной инженерии IEEE : [6] : 80–81.
И, согласно стандарту ISO 9000:
Противоречие вызвано использованием понятий требования и заданных требований, но имеющих разное значение.
В случае стандартов IEEE указанные требования, упомянутые в определении валидации, представляют собой набор проблем, потребностей и желаний заинтересованных сторон, которые программное обеспечение должно решить и удовлетворить. Такие требования документированы в Спецификации требований к программному обеспечению (SRS). А продукты, упомянутые в определении верификации, являются результатом каждого этапа процесса разработки программного обеспечения. Эти продукты, по сути, являются спецификациями, такими как Спецификация архитектурного проектирования, Детальная спецификация проектирования и т. д. SRS также является спецификацией, но ее невозможно проверить (по крайней мере, в том смысле, который используется здесь, подробнее об этом ниже).
Но для ISO 9000 указанные требования представляют собой набор спецификаций, как только что упоминалось выше, которые должны быть проверены. Спецификация, как объяснялось ранее, является продуктом этапа разработки программного обеспечения, который получает на вход другую спецификацию. Спецификация считается успешной, если она правильно реализует свою входную спецификацию. Все спецификации можно проверить, кроме SRS, поскольку она первая (хотя ее можно проверить). Примеры: Спецификация проекта должна реализовывать SRS; и артефакты этапа строительства должны соответствовать Спецификации проекта.
Итак, когда эти слова определяются в общих чертах, кажущееся противоречие исчезает.
И SRS, и программное обеспечение должны быть проверены. SRS можно проверить статически, проконсультировавшись с заинтересованными сторонами. Тем не менее, запуск некоторой частичной реализации программного обеспечения или любого прототипа (динамическое тестирование) и получение от них положительных отзывов может еще больше повысить уверенность в том, что SRS сформулирована правильно. С другой стороны, программное обеспечение как конечный и работающий продукт (а не его артефакты и документы, включая исходный код) должно динамически проверяться заинтересованными сторонами путем запуска программного обеспечения и предоставления им возможности опробовать его.
Некоторые могут возразить, что для SRS входными данными являются слова заинтересованных сторон, и, следовательно, проверка SRS аналогична проверке SRS. Думать таким образом не рекомендуется, поскольку это только вызовет еще большую путаницу. Лучше думать о проверке как о процессе, включающем формальный и технический входной документ.
Тестирование программного обеспечения можно рассматривать как часть процесса обеспечения качества программного обеспечения (SQA). [4] : 347 В SQA специалисты по процессам разработки программного обеспечения и аудиторы занимаются процессом разработки программного обеспечения, а не просто такими артефактами, как документация, код и системы. Они исследуют и изменяют сам процесс разработки программного обеспечения , чтобы уменьшить количество ошибок, возникающих в поставляемом программном обеспечении: так называемый уровень дефектов. Что представляет собой приемлемый уровень дефектов, зависит от характера программного обеспечения; видеоигра-симулятор полета будет иметь гораздо более высокую устойчивость к дефектам, чем программное обеспечение для реального самолета. Хотя существуют тесные связи с SQA, отделы тестирования часто существуют независимо, и в некоторых компаниях функция SQA может отсутствовать. [ нужна цитата ]
Тестирование программного обеспечения — это деятельность по исследованию тестируемого программного обеспечения с целью предоставления заинтересованным сторонам информации, связанной с качеством. Напротив, QA ( гарантия качества ) — это реализация политик и процедур, направленных на предотвращение попадания дефектов в руки клиентов.
int f(int x){return x*x-6*x+8;}f(x)>=0x=3{{cite book}}: CS1 maint: date and year (link)
