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

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

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

обзор архитектуры продукта и общего дизайна продукта

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

выполнение программы или приложения с целью изучения поведения

обзор инфраструктуры развертывания и связанных с ней сценариев и автоматизации

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

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

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

Основной целью тестирования является обнаружение сбоев в программном обеспечении, чтобы дефекты могли быть обнаружены и исправлены. Тестирование не может установить, что продукт функционирует должным образом при всех условиях, но только то, что он не функционирует должным образом при определенных условиях. В сферу тестирования программного обеспечения может входить изучение кода, а также выполнение этого кода в различных средах и условиях, а также изучение аспектов кода: выполняет ли он то, что должен делать, и делает ли то, что ему нужно. В современной культуре разработки программного обеспечения организация, занимающаяся тестированием, может быть отделена от команды разработчиков. Существуют различные роли для членов команды тестирования. Информация, полученная в результате тестирования программного обеспечения, может быть использована для корректировки процесса разработки программного обеспечения.[5]: 41–43

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

Ошибки и сбои

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

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

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

Входные комбинации и предварительные условия

Фундаментальная проблема тестирования программного обеспечения заключается в том, что тестирование при любых комбинациях входных данных и предварительных условий (начальное состояние) невозможно даже для простого продукта. 17-18 Это означает, что количество ошибок в программном продукте может быть очень большим, а дефекты, которые встречаются нечасто, трудно обнаружить при тестировании и отладке. Что еще более важно, нефункциональные аспекты качества (каким оно должно быть в сравнении с тем, что оно должно делать) - удобство использования, масштабируемость, производительность, совместимость инадежность — может быть весьма субъективной; то, что представляет достаточную ценность для одного человека, может быть невыносимым для другого.

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

Экономика

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

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

Роли

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

История

Гленфорд Майерс впервые ввел разделение отладки и тестирования в 1979 году. Хотя его внимание было сосредоточено на тестировании на поломках ("Успешный тестовый пример - это тот, который обнаруживает еще не обнаруженную ошибку". ), это иллюстрировало желание сообщества разработчиков программного обеспечения отделитьосновные виды деятельности по разработке, такие как отладка, отличаются от проверки.

Подход к тестированию

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

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

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

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

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

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

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

"Коробочный" подход

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

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

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

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

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

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

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

Тестирование API – тестирование приложения с использованием общедоступных и частных API (интерфейсов прикладного программирования)

Покрытие кода – создание тестов, удовлетворяющих некоторым критериям покрытия кода (например, разработчик тестов может создавать тесты, чтобы заставить все инструкции в программе выполняться хотя бы один раз)

Методы внедрения ошибок – преднамеренное введение ошибок для оценки эффективности стратегий тестирования

Методы тестирования на мутации

Методы статического тестирования

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

Покрытие функций, которое сообщает о выполненных функциях

Охват оператора, который сообщает о количестве строк, выполненных для завершения теста

Покрытие решений, которое сообщает о том, были ли выполнены как истинная, так и ложная ветви данного теста

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

Тестирование черного ящика

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

Схема черного ящика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уровни тестирования

Вообще говоря, существует по крайней мере три уровня тестирования: модульное тестирование, интеграционное тестирование и системное тестирование.Однако разработчики могут включить четвертый уровень - приемочное тестирование. Это может быть в форме эксплуатационного приемочного тестирования или простого тестирования конечным пользователем (бета-версия), тестирование для обеспечения соответствия программного обеспечения функциональным ожиданиям.На основе программы ISTQB Certified Test Foundation Level, test levels включает в себя эти четыре уровня, а четвертый уровень называется приемочным тестированием. Тесты часто группируются на один из этих уровней в зависимости от того, где они добавляются в процессе разработки программного обеспечения, или по уровню специфичности теста.

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

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

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

Эти типы тестов обычно пишутся разработчиками во время работы над кодом (в стиле "белого ящика"), чтобы гарантировать, что конкретная функция работает должным образом. Одна функция может иметь несколько тестов, чтобы перехватить угловые случаи или другие ветви в коде. Модульное тестирование само по себе не может проверить функциональность части программного обеспечения, а скорее используется для обеспечения того, чтобы строительные блоки программного обеспечения работали независимо друг от друга.

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

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

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

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

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

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

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

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

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

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

Приемочное тестирование

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

Приемочные испытания обычно включают следующие четыре типа:

1. Пользовательское приемочное тестирование (UAT)
2. Эксплуатационные приемочные испытания (OAT)
3. Договорное и нормативное приемочное тестирование
4. Альфа- и бета-тестирование

UAT, а также альфа- и бета-тестирование описаны в следующем разделе типы тестирования.

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

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

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

Типы, методы и тактики тестирования

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

Тестирование установки

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

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

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

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

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

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

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

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

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

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

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

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

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

Приемочное тестирование

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

Приемочное тестирование может означать одно из двух:

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

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

Основная статья: Альфа-тестирование

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

Бета-тестирование

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

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

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

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

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

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

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

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

Разрушающее тестирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обеспечение надлежащего цветового контраста между шрифтом и цветом фона

Размер шрифта

Альтернативные тексты для мультимедийного контента

Возможность использования системы с помощью компьютерной клавиатуры в дополнение к мыши.

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

Закон об американцах с ограниченными возможностями 1990 года

Раздел 508 Поправки к Закону о реабилитации 1973 года

Инициатива по обеспечению доступности Интернета (WAI) Консорциума всемирной паутины (W3C)

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

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

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

Интернационализация и локализация

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

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

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

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

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

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

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

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

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

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

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

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

В программном обеспечении может отсутствовать надлежащая поддержка чтения или записи двунаправленного текста.

Программное обеспечение может отображать изображения с текстом, который не был локализован.

Локализованные операционные системы могут иметь файлы конфигурации системы с разными именами и переменные среды, а также разные форматы даты и валюты.

Тестирование разработки

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

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

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

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

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

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

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

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

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

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

Тестирование сравнения результатов

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

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

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

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

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

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

Метаморфическое тестирование

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

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

Тестирование видеомагнитофонов

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

Этот метод был популяризирован в веб-разработке видеомагнитофоном Ruby library.

Процесс тестирования

Традиционная водопадная модель разработки

Обычной практикой в разработке водопадов является то, что тестирование выполняется независимой группой тестировщиков. Это может произойти:

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

в тот же момент начинается проект разработки, как непрерывный процесс, пока проект не завершится.

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

Дополнительная информация: Интеграция модели зрелости возможностей и водопадной модели

Модель разработки Agile или XP

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

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

Конечными целями этого процесса тестирования являются поддержка непрерывной интеграции и снижение частоты дефектов.

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

Примерный цикл тестирования

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

Анализ требований: Тестирование должно начинаться на этапе требований жизненного цикла разработки программного обеспечения. На этапе проектирования тестировщики работают над определением того, какие аспекты проекта можно протестировать и с какими параметрами эти тесты работают.

Планирование тестирования: Стратегия тестирования, План тестирования, создание тестового стенда. Поскольку во время тестирования будет выполняться много действий, необходим план.

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

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

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

Анализ результатов тестирования: или Анализ дефектов, выполняется командой разработчиков обычно вместе с клиентом, чтобы решить, какие дефекты следует назначить, исправить, отклонить (т. Е.

Найти программное обеспечение, работающее должным образом) или отложить, чтобы разобраться с ними позже.

Повторное тестирование дефекта: после того, как команда разработчиков устранила дефект, он повторно проверяется командой тестирования.

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

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

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

Основная статья: Автоматизация тестирования

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

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

Инструменты тестирования

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

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

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

Гипервизор, позволяющий полностью контролировать выполнение программного кода, включая:-

Анимация программы, позволяющая пошаговое выполнение и условную точку останова на уровне исходного кода или в машинном коде

• Отчеты о покрытии кода

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

Инструменты тестирования автоматизированного функционального графического интерфейса пользователя (GUI) используются для повторения тестов системного уровня через графический интерфейс пользователя

Тесты - Контрольные показатели, позволяющие проводить сравнения производительности во время выполнения

Анализ производительности (или инструменты профилирования), которые могут помочь выявить горячие точки и использование ресурсов

Некоторые из этих функций могут быть включены в единый составной инструмент или интегрированную среду разработки (IDE).

Захват и воспроизведение

Тестирование с захватом и воспроизведением состоит в сборе сквозных сценариев использования во время взаимодействия с приложением и превращении этих сценариев в тестовые примеры. Возможные применения захвата и воспроизведения включают в себя генерацию регрессионных тестов. Инструмент SCARPE выборочно захватывает подмножество исследуемого приложения по мере его выполнения. JRapture фиксирует последовательность взаимодействий между исполняемой Java-программой и компонентами хост-системы, такими как файлы или события в графических пользовательских интерфейсах. Затем эти последовательности могут быть воспроизведены для тестирования на основе наблюдений. Саиева и др. предлагают создавать специальные тесты, которые воспроизводят записанные пользовательские трассировки выполнения, чтобы протестировать возможные исправления для критических ошибок безопасности. Pankti собирает профили объектов в процессе производства для создания специализированных дифференциальных модульных тестов. Этот инструмент улучшает захват и воспроизведение с помощью систематической генерации производных тестовых оракулов. AutographQL отслеживает запросы пользователей в API GraphQL и генерирует тестовые примеры, которые могут обнаруживать ошибки схемы

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

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

Показатели качества включают такие темы, как корректность, полнота, безопасность и требования стандарта ISO/ IEC 9126, такие как возможности, надежность, эффективность, переносимость, Ремонтопригодность, совместимость и удобство использования.

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

Иерархия сложности тестирования

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

Класс I: существует конечный полный набор тестов.

Класс II: любая частичная скорость распознавания (т. Е. Любая неполная способность отличать правильные системы от неправильных систем) может быть достигнута с помощью ограниченного набора тестов.

Класс III: существует счетный полный набор тестов.

Класс IV: существует полный набор тестов.

Класс V: все случаи.

• Было доказано, что каждый класс строго включен в следующий. Например, тестирование, когда мы предполагаем, что поведение тестируемой реализации может быть обозначено детерминированным конечным автоматом для некоторых известных конечных наборов входных и выходных данных и с некоторым известным числом состояний, принадлежит классу I (и всем последующим классам). Однако, если число состояний неизвестно, то оно относится только ко всем классам, начиная со II класса. Если тестируемая реализация должна быть детерминированным конечным автоматом, не отвечающим спецификации для одной трассы (и ее продолжений), и число ее состояний неизвестно, то она относится только к классам, начиная с класса III. Тестирование временных машин, в которых переходы запускаются, если входные данные создаются в пределах некоторого реального ограниченного интервала, относится только к классам, начиная с класса IV, тогда как тестирование многих недетерминированных систем относится только к классу V (но не ко всем, а некоторые даже принадлежат к классу I). Включение в класс I не требует простоты предполагаемой вычислительной модели, поскольку было доказано, что некоторые тестовые примеры, включающие реализации, написанные на любом языке программирования, и тестовые реализации, определенные как машины, зависящие от непрерывных величин, относятся к классу I. Другие разработанные примеры, такие как фреймворк тестирования Мэтью Хеннесси в рамках семантики must и темпоральные машины с рациональными тайм-аутами, относятся к классу II.

Артефакты тестирования

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

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

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

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

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

Тестовый пример

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

Тестовый скрипт

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

Набор тестов

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

Тестовое устройство или тестовые данные

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

Тестовый жгут

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

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

Отчет о результатах выполнения тестового примера или набора тестов

Сертификаты

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

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

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

Гибкое тестирование против традиционного

Должны ли тестировщики учиться работать в условиях неопределенности и постоянных изменений или они должны стремиться к "зрелости" процесса? Движение гибкого тестирования получило растущую популярность с 2006 года, в основном в коммерческих кругах, в то время как правительственные и военные поставщики программного обеспечения используют эту методологию, а также традиционные тестовые модели (например, в модели водопада).]

Ручное и автоматическое тестирование

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

Оправдано ли существование стандарта тестирования программного обеспечения ISO 29119?

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

Некоторые практики заявляют, что поле тестирования не готово для сертификации

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

Исследования, использованные для показа относительных затрат на устранение дефектов

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

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

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

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

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

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

Связанные процессы

Проверка и проверка программного обеспечения

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

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

Проверка: правильно ли мы создали программное обеспечение? (т. Е. Соответствует ли оно требованиям).

• Проверка: создали ли мы правильное программное обеспечение? (т.е. удовлетворяют ли результаты заказчика).
• Термины верификация и валидация обычно взаимозаменяемы в отрасли; также часто можно увидеть, что эти два термина определяются с противоречивыми определениями. Согласно стандартному глоссарию терминологии разработки программного обеспечения IEEE:

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

• Валидация - это процесс оценки системы или компонента во время или в конце процесса разработки, чтобы определить, удовлетворяет ли он установленным требованиям.

И, в соответствии со стандартом ISO 9000:

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

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

Противоречие вызвано использованием понятий требований и заданных требований, но в разных значениях.

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

Но для стандарта ISO 9000 указанные требования представляют собой набор спецификаций, как только что упоминалось выше, которые должны быть проверены. Спецификация, как объяснялось ранее, является продуктом этапа процесса разработки программного обеспечения, который получает другую спецификацию в качестве входных данных. Спецификация успешно проверяется, когда она правильно реализует свою входную спецификацию. Все спецификации могут быть проверены, кроме SRS, потому что это первая спецификация (хотя она может быть проверена). Примеры: Спецификация проектирования должна реализовывать SRS; и артефакты этапа строительства должны реализовывать спецификацию проектирования.

Итак, когда эти слова определяются в общих чертах, кажущееся противоречие исчезает.

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

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

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

Тестирование программного обеспечения можно рассматривать как часть процесса обеспечения качества программного обеспечения (SQA).В SQA специалисты по разработке программного обеспечения и аудиторы занимаются процессом разработки программного обеспечения, а не просто артефактами, такими как документация, код и системы. Они изучают и изменяют сам процесс разработки программного обеспечения, чтобы уменьшить количество ошибок, которые в конечном итоге возникают в поставляемом программном обеспечении: так называемая частота дефектов. То, что составляет приемлемый процент дефектов, зависит от характера программного обеспечения; видеоигра с симулятором полета будет иметь гораздо более высокую устойчивость к дефектам, чем программное обеспечение для реального самолета. Несмотря на тесные связи с SQA, отделы тестирования часто существуют независимо, и в некоторых компаниях функция SQA может отсутствовать. Тестирование программного обеспечения - это деятельность по исследованию тестируемого программного обеспечения с целью предоставления заинтересованным сторонам информации, связанной с качеством. В отличие от этого, QA (quality assurance) - это внедрение политик и процедур, направленных на предотвращение попадания дефектов к клиентам.

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

Проверка данных – процесс обеспечения правильности и полезности компьютерных данных.

• Динамический анализ программы – анализ компьютерного программного обеспечения, который выполняется путем выполнения программы
• Формальная проверка – подтверждение или опровержение правильности определенных предполагаемых алгоритмов
• Тестирование графического пользовательского интерфейса – термин в программной инженерии
• Независимая испытательная организация – Организация, которая проводит испытания в соответствии с согласованными требованиями.
• Ручное тестирование – тестирование программного обеспечения без использования специальных инструментов для автоматизации процесса
• Тестирование ортогональных массивов – методика тестирования программного обеспечения
• Парное тестирование – методика тестирования программного обеспечения
• Обратная семантическая трассировка – метод контроля качества
• Тактика тестирования программного обеспечения – Обзор нескольких заметных тактик, полезных при тестировании программного обеспечения
• Инструмент управления тестированием – хранит этапы тестирования, планирование тестирования и отчетность
• Таблица трассировки – методика тестирования программного обеспечения
• Веб–тестирование - тестирование программного обеспечения, ориентированное на веб-приложения

Читать

/se.inf.ethz.ch/~meyer/publications/testing/principles.pdf

Пруф

curlie.org/Computers/Programming/Software_Testing/Products_and_Tools

• economist.com/technology-quarterly/2008/03/08/software-that-makes-software-better
• /vladislaveremeev.gitbook.io/qa_bible/obshee/evristiki-i-