Войти
Тестирование программного обеспечения - это расследование, проводимое для предоставить заинтересованным сторонам информацию о качестве тестируемого программного продукта или услуги. Тестирование программного обеспечения также может дать объективный, независимый взгляд на программное обеспечение, чтобы позволить бизнесу оценить и понять риски внедрения программного обеспечения. Методы тестирования включают в себя процесс выполнения программы или приложения с целью обнаружения ошибок программного обеспечения (ошибок или других дефектов) и проверки пригодности программного продукта для использования.
Тестирование программного обеспечения включает выполнение программного компонента или системного компонента для оценки одного или нескольких представляющих интерес свойств. В общем, эти свойства указывают на степень, в которой тестируемый компонент или система:
Поскольку количество возможных тестов даже для простых программных компонентов практически бесконечно, все тестирование программного обеспечения использует определенную стратегию для выбора тестов, выполнимых с учетом доступного времени и ресурсов. В результате тестирование программного обеспечения обычно (но не исключительно) пытается выполнить программу или приложение с целью поиска ошибок программного обеспечения (ошибок или других дефектов). Работа по тестированию - это итеративный процесс, так как, когда одна ошибка исправлена, она может выявить другие, более глубокие ошибки или даже создать новые.
Тестирование программного обеспечения может предоставить объективную независимую информацию о качестве программного обеспечения и риске его отказа пользователям или спонсорам.
Тестирование программного обеспечения может быть проведено, как только исполняемое программное обеспечение (даже если оно частично завершено).) существует. Общий подход к разработке программного обеспечения часто определяет, когда и как проводится тестирование. Например, в поэтапном процессе большая часть тестирования происходит после того, как системные требования определены и затем реализованы в тестируемых программах. Напротив, при гибком подходе требования, программирование и тестирование часто выполняются одновременно.
Хотя тестирование программного обеспечения может определять правильность программного обеспечения на основе некоторых конкретных гипотез (см. иерархию сложности тестирования ниже), тестирование не может выявить все дефекты в программном обеспечении. Вместо этого в нем содержится критика или сравнение, в котором состояние и поведение продукта сравнивается с тестовыми оракулами - принципами или механизмами, с помощью которых кто-то может распознать проблему. Эти оракулы могут включать в себя (но не ограничиваются ими) спецификации, контракты, сопоставимые продукты, предыдущие версии того же продукта, выводы о предполагаемой или ожидаемой цели, ожиданиях пользователей или клиентов, соответствующих стандартах, применимых законах или другие критерии.
Основная цель тестирования - выявить сбои программного обеспечения, чтобы можно было обнаружить и исправить дефекты. Тестирование не может установить, что продукт функционирует должным образом во всех условиях, а только то, что он не работает должным образом при определенных условиях. Объем тестирования программного обеспечения часто включает в себя изучение кода, а также выполнение этого кода в различных средах и условиях, а также изучение аспектов кода: делает ли он то, что он должен делать, и делает то, что ему нужно делать. В нынешней культуре разработки программного обеспечения организация тестирования может быть отделена от группы разработчиков. У членов команды тестирования есть разные роли. Информация, полученная в результате тестирования программного обеспечения, может использоваться для корректировки процесса разработки программного обеспечения.
У каждого программного продукта есть целевая аудитория. Например, аудитория программного обеспечения для видеоигр полностью отличается от банковского программного обеспечения. Следовательно, когда организация разрабатывает или иным образом инвестирует в программный продукт, она может оценить, будет ли программный продукт приемлемым для ее конечных пользователей, целевой аудитории, покупателей и других заинтересованных сторон. Тестирование программного обеспечения помогает сделать эту оценку.
Не все дефекты программного обеспечения вызваны ошибками кодирования. Одним из распространенных источников дорогостоящих дефектов являются пробелы в требованиях, т. Е. Непризнанные требования, которые приводят к ошибкам, упущенным разработчиком программы. Пробелы в требованиях часто могут быть нефункциональными требованиями, такими как тестируемость, масштабируемость, ремонтопригодность, производительность и безопасность.
Программные сбои возникают в результате следующих процессов. Программист делает ошибку (ошибка), что приводит к дефекту (неисправность, ошибка) в программном обеспечении исходный код. Если этот дефект выполняется, в определенных ситуациях система будет давать неверные результаты, вызывая сбой. Не все дефекты обязательно приведут к сбоям. Например, дефекты в мертвом коде никогда не приведут к сбоям. Дефект может перерасти в сбой при изменении окружающей среды. Примеры этих изменений в среде включают запуск программного обеспечения на новой платформе компьютерного оборудования, изменения в исходных данных или взаимодействие с другим программным обеспечением. Единичный дефект может привести к большому количеству симптомов отказа.
Основная проблема тестирования программного обеспечения заключается в том, что тестирование при всех комбинациях входных данных и предварительных условий (начальное состояние) невозможно даже с простым продуктом. Это означает, что количество дефектов в программном продукте может быть очень большим, а дефекты, которые возникают нечасто, трудно обнаружить при тестировании. Что еще более важно, нефункциональные параметры качества (каким оно должно быть по сравнению с тем, что оно должно делать) - удобство использования, масштабируемость, производительность, совместимость, надежность - могут быть весьма субъективными; то, что представляет для одного человека достаточную ценность, может быть невыносимо для другого.
Разработчики программного обеспечения не могут протестировать все, но они могут использовать комбинаторный дизайн тестов, чтобы определить минимальное количество тестов, необходимых для получения желаемого покрытия. Комбинаторный дизайн тестов позволяет пользователям получить больший охват тестированием с меньшим количеством тестов. Независимо от того, ищут ли они скорость или глубину тестирования, они могут использовать комбинаторные методы разработки тестов для создания структурированных вариаций в своих тестовых примерах.
Исследование, проведенное NIST в 2002 году сообщает, что ошибки в программном обеспечении обходятся экономике США в 59,5 миллиардов долларов ежегодно. Более трети этих затрат можно было бы избежать, если бы было проведено более качественное тестирование программного обеспечения.
Аутсорсинг тестирования программного обеспечения из-за затрат очень распространен, причем предпочтительными странами являются Китай, Филиппины и Индия.
Тестирование программного обеспечения может выполняться специализированными тестировщиками программного обеспечения; до 1980-х гг. термин «тестировщик программного обеспечения» использовался повсеместно, но позже он также рассматривался как отдельная профессия. Что касается периодов и различных целей в тестировании программного обеспечения, были установлены разные роли, такие как менеджер тестирования, руководитель тестирования, аналитик тестирования, разработчик тестов, тестировщик, разработчик автоматизации и администратор тестирования. Тестирование программного обеспечения также может выполняться неспециализированными тестировщиками программного обеспечения.
Гленфорд Дж. Майерс первоначально ввел разделение отладки и тестирования в 1979 году. Хотя его внимание было сосредоточено на тестировании на поломку (" Успешный тестовый пример - это тот, который обнаруживает еще не обнаруженную ошибку »). Он иллюстрирует желание сообщества разработчиков программного обеспечения отделить фундаментальные действия по разработке, такие как отладка, от проверки.
Существует множество подходов к тестированию программного обеспечения. Обзоры, пошаговые руководства или проверки называются статическим тестированием, тогда как выполнение запрограммированного кода с заданным набором тестовых примеров упоминается to as динамическое тестирование.
Статическое тестирование часто является неявным, например, корректура, а также когда инструменты программирования / текстовые редакторы проверяют структуру исходного кода или компиляторы (пре-компиляторы) проверяют синтаксис и поток данных как статический анализ программы. Динамическое тестирование происходит при запуске самой программы. Динамическое тестирование может начаться до того, как программа будет завершена на 100%, чтобы протестировать определенные разделы кода и применить их к дискретным функциям или модулям. Типичными методами для них являются использование заглушек / драйверов или выполнение из среды отладчика.
Статическое тестирование включает проверку, тогда как динамическое тестирование также включает валидацию.
Пассивное тестирование означает проверку поведения системы без какого-либо взаимодействия с программным продуктом. В отличие от активного тестирования, тестировщики не предоставляют никаких тестовых данных, а просматривают системные журналы и трассировки. Они ищут закономерности и конкретное поведение, чтобы принимать какие-то решения. Это связано с автономной проверкой времени выполнения и анализом журнала.
Исследовательское тестирование - это подход к тестированию программного обеспечения, который кратко описывается как одновременное обучение, тест дизайн и выполнение теста. Сем Канер, который ввел термин в употребление в 1984 году, определяет исследовательское тестирование как «стиль тестирования программного обеспечения, который подчеркивает личную свободу и ответственность отдельного тестировщика за постоянную оптимизацию качества своей работы путем обработки тестов. связанное с обучением, разработка тестов, выполнение тестов и интерпретация результатов тестирования как взаимодополняющие действия, которые выполняются параллельно на протяжении всего проекта ».
Методы тестирования программного обеспечения традиционно разделяются в тестирование методом белого и черного ящика. Эти два подхода используются для описания точки зрения, которую принимает тестировщик при разработке тестовых примеров. Гибридный подход, называемый тестированием серого ящика, также может применяться к методологии тестирования программного обеспечения. С появлением концепции тестирования «серого ящика», которая разрабатывает тесты на основе конкретных элементов дизайна, это «произвольное различие» между тестированием черного и белого ящиков несколько сошло на нет.
Диаграмма тестирования белого ящика Тестирование белого ящика (также известное как тестирование с прозрачным ящиком, тестирование с использованием стеклянного ящика, тестирование с прозрачным ящиком и структурное тестирование) проверяет внутренние структуры или работу программы, в отличие от функциональных возможностей, открытых до конца -пользователь. При тестировании методом белого ящика для разработки тестовых случаев используется внутренняя перспектива системы (исходный код), а также навыки программирования. Тестировщик выбирает входные данные для прохождения пути через код и определяет соответствующие выходы. Это аналогично тестированию узлов в цепи, например, внутрисхемное тестирование (ICT).
Хотя тестирование методом белого ящика может применяться на уровнях unit, интеграции и system процесса тестирования программного обеспечения, обычно это сделано на уровне единицы. Он может тестировать пути внутри модуля, пути между модулями во время интеграции и между подсистемами во время тестирования на уровне системы. Хотя этот метод разработки тестов может выявить множество ошибок или проблем, он может не обнаружить нереализованные части спецификации или отсутствующие требования.
При тестировании методом белого ящика используются следующие методы:
Инструменты покрытия кода могут оценивать полноту набора тестов, созданного с помощью любого метода, включая тестирование методом черного ящика. Это позволяет команде разработчиков программного обеспечения исследовать части системы, которые редко тестируются, и гарантирует, что наиболее важные функциональные точки были протестированы. Покрытие кода в виде метрики программного обеспечения может быть указано в процентах для:
100% покрытие операторов гарантирует, что все пути или ветки кода (в терминах поток управления ) выполняются хотя бы один раз. Это помогает обеспечить правильную функциональность, но этого недостаточно, поскольку один и тот же код может обрабатывать разные входные данные правильно или неправильно. Псевдотестируемые функции и методы - это те, которые описаны, но не указаны (их тело можно удалить, не нарушая какой-либо тестовый пример).
Диаграмма черного ящика Черный- Ящик-тестирование (также известное как функциональное тестирование) рассматривает программное обеспечение как «черный ящик», проверяя функциональность без каких-либо знаний о внутренней реализации, без просмотра исходного кода. Тестировщики осведомлены только о том, что программа должна делать, но не о том, как она это делает. Методы тестирования черного ящика включают: разделение эквивалентности, анализ граничных значений, тестирование всех пар, таблицы переходов между состояниями, таблица решений тестирование, нечеткое тестирование, тестирование на основе модели, вариант использования тестирование, исследовательское тестирование и основанное на спецификации
Тестирование на основе спецификаций направлено на проверку функциональности программного обеспечения в соответствии с применимыми требованиями. Этот уровень тестирования обычно требует, чтобы тестировщику были предоставлены подробные тестовые примеры, которые затем могут просто проверить, что для данного входа выходное значение (или поведение) либо «есть», либо «нет» то же, что и ожидаемое значение, указанное в тестовом примере. Тестовые сценарии построены вокруг спецификаций и требований, то есть того, что приложение должно делать. Он использует внешние описания программного обеспечения, включая спецификации, требования и дизайн для создания тестовых примеров. Эти тесты могут быть функциональными или нефункциональными, но обычно функциональными.
Тестирование на основе спецификаций может быть необходимо для обеспечения правильной работы, но этого недостаточно для защиты от сложных ситуаций или ситуаций с высоким риском.
Одним из преимуществ метода черного ящика является отсутствие знаний в области программирования требуется. Какие бы предубеждения ни были у программистов, тестировщик, вероятно, имеет другой набор и может делать упор на разные области функциональности. С другой стороны, тестирование методом черного ящика было названо «походом на прогулку по темному лабиринту без фонарика». Поскольку они не исследуют исходный код, бывают ситуации, когда тестировщик пишет множество тестовых примеров, чтобы проверить что-то, что могло быть протестировано только одним тестом, или оставляет некоторые части программы непроверенными.
Этот метод тестирования может применяться на всех уровнях тестирования программного обеспечения: модуль, интеграция, система и приемка. Обычно он включает большую часть, если не все тестирование на более высоких уровнях, но также может доминировать над модульным тестированием.
Тестирование интерфейса компонента
Тестирование интерфейса компонента - это разновидность тестирования черного ящика, с акцентом на значениях данных, помимо связанных действий компонента подсистемы. Практика тестирования интерфейса компонентов может использоваться для проверки обработки данных, передаваемых между различными модулями или компонентами подсистем, помимо тестирования полной интеграции между этими модулями. Передаваемые данные могут рассматриваться как «пакеты сообщений», а диапазон или типы данных могут быть проверены на предмет данных, сгенерированных из одного блока, и проверены на достоверность перед передачей в другой блок. Одним из вариантов тестирования интерфейса является ведение отдельного файла журнала передаваемых элементов данных, часто с фиксированной временной меткой, что позволяет анализировать тысячи случаев передачи данных между модулями в течение дней или недель. Тесты могут включать проверку обработки некоторых экстремальных значений данных, в то время как другие переменные интерфейса передаются как нормальные значения. Необычные значения данных в интерфейсе могут помочь объяснить неожиданную производительность в следующем блоке.
Цель визуального тестирования - предоставить разработчикам возможность изучить, что происходило в момент сбоя программного обеспечения, путем представления данных таким образом, чтобы разработчик мог легко найти информацию, которую он или она требует, и информация будет четко выражена.
В основе визуального тестирования лежит идея, что показать кому-то проблему (или провал теста), а не просто ее описать, значительно увеличивает ясность и понимание. Поэтому визуальное тестирование требует записи всего процесса тестирования - записи всего, что происходит в тестовой системе, в видеоформате. Выходные видеоролики дополняются вводом тестера в реальном времени через веб-камеру «картинка в картинке» и аудиокомментариями с микрофонов.
Визуальное тестирование дает ряд преимуществ. Качество связи резко повышается, потому что тестировщики могут показать проблему (и события, приведшие к ней) разработчику, а не просто описать ее, и во многих случаях отпадет необходимость воспроизводить ошибки тестирования. Разработчик будет иметь все необходимые доказательства отказа теста и вместо этого может сосредоточиться на причине ошибки и способах ее устранения.
Специальное тестирование и исследовательское тестирование являются важными методологиями проверки целостности программного обеспечения, поскольку они требуют меньше времени на подготовку для внедрения, а важные ошибки можно найти быстро. При специальном тестировании, когда тестирование проводится импровизированным, импровизированным способом, способность тестировщика (ов) основывать тестирование на документированных методах, а затем импровизировать варианты этих тестов может привести к более тщательной проверке исправлений дефектов. Однако, если не ведется строгая документация процедур, одним из ограничений специального тестирования является отсутствие повторяемости.
Тестирование серого ящика (американское написание: серое - серое) тестирование ящика) включает в себя знание внутренних структур данных и алгоритмов для целей разработки тестов при выполнении этих тестов на уровне пользователя или на уровне черного ящика. Тестировщик часто имеет доступ как к «исходному коду, так и к исполняемому двоичному файлу». Тестирование «серого ящика» может также включать обратное проектирование (с использованием динамического анализа кода) для определения, например, граничных значений или сообщений об ошибках. Манипулирование входными данными и форматирование выходных данных не квалифицируются как серый ящик, поскольку входные и выходные данные явно находятся за пределами «черного ящика», который мы называем тестируемой системой. Это различие особенно важно при проведении интеграционного тестирования между двумя модулями кода, написанного двумя разными разработчиками, где для теста доступны только интерфейсы.
Зная основные концепции работы программного обеспечения, тестировщик делает более информированный выбор тестирования при тестировании программного обеспечения извне. Обычно тестировщику серого ящика разрешается создать изолированную среду тестирования с такими действиями, как заполнение базы данных. Тестировщик может наблюдать за состоянием тестируемого продукта после выполнения определенных действий, таких как выполнение операторов SQL для базы данных, а затем выполнение запросов, чтобы убедиться, что ожидаемые изменения были отражены. Тестирование методом серого ящика реализует сценарии интеллектуального тестирования, основанные на ограниченной информации. В частности, это будет относиться к обработке типов данных, обработке исключений и т. Д.
В общем, существует как минимум три уровня тестирования: модульное тестирование, интеграционное тестирование и системное тестирование. Однако четвертый уровень, приемочное тестирование, может быть включен разработчиками. Это может быть в форме эксплуатационного приемочного тестирования или простого (бета) тестирования конечного пользователя, чтобы убедиться, что программное обеспечение соответствует функциональным ожиданиям. Согласно программе ISTQB Certified Test Foundation Level, уровни тестирования включают эти четыре уровня, а четвертый уровень называется приемочным тестированием. Тесты часто сгруппированы в один из этих уровней по месту их добавления в процессе разработки программного обеспечения или по уровню специфичности теста.
Модульное тестирование относится к тестам, которые проверяют функциональность определенного раздела кода, обычно на функциональном уровне. В объектно-ориентированной среде это обычно на уровне класса, а минимальные модульные тесты включают конструкторы и деструкторы.
Эти типы тестов обычно пишутся разработчиками, когда они работают над кодом (белый ящик style), чтобы убедиться, что конкретная функция работает должным образом. Одна функция может иметь несколько тестов, чтобы отловить угловые случаи или другие ветки в коде. Само по себе модульное тестирование не может проверить функциональность части программного обеспечения, а скорее используется для обеспечения того, чтобы строительные блоки программного обеспечения работали независимо друг от друга.
Модульное тестирование - это процесс разработки программного обеспечения, который включает синхронизированное применение широкого спектра стратегий предотвращения и обнаружения дефектов с целью снижения рисков, времени и затрат при разработке программного обеспечения. Он выполняется разработчиком программного обеспечения или инженером на этапе построения жизненного цикла разработки программного обеспечения. Модульное тестирование направлено на устранение ошибок конструкции до того, как код будет переведен на дополнительное тестирование; эта стратегия предназначена для повышения качества конечного программного обеспечения, а также эффективности всего процесса разработки.
В зависимости от ожиданий организации в отношении разработки программного обеспечения, модульное тестирование может включать статический анализ кода, анализ потока данных, анализ показателей, коллегиальные обзоры кода, анализ покрытия кода и другие методы тестирования программного обеспечения.
Интеграционное тестирование - это любой тип тестирования программного обеспечения, целью которого является проверка интерфейсов между компонентами на соответствие проекту программного обеспечения. Программные компоненты могут быть интегрированы итеративно или все вместе («большой взрыв»). Обычно первое считается лучшим методом, поскольку он позволяет быстрее обнаруживать и устранять проблемы интерфейса.
Интеграционное тестирование направлено на выявление дефектов в интерфейсах и взаимодействии между интегрированными компонентами (модулями). Постепенно все большие группы тестируемых программных компонентов, соответствующих элементам архитектурного проекта, интегрируются и тестируются до тех пор, пока программное обеспечение не станет работать как система.
Интеграционные тесты обычно включают много кода и производят трассировки, которые больше, чем произведенные юнит-тестами. Это влияет на простоту локализации неисправности в случае сбоя интеграционного теста. Чтобы решить эту проблему, было предложено автоматически разрезать большие тесты на более мелкие части, чтобы улучшить локализацию неисправности.
Тестирование системы тестирует полностью интегрированную систему, чтобы убедиться, что система соответствует требованиям. его требования. Например, системный тест может включать тестирование интерфейса входа в систему, затем создание и редактирование записи, а также отправку или печать результатов с последующей суммарной обработкой или удалением (или архивированием) записей, а затем выходом из системы.
Обычно этот уровень приемочных испытаний включает следующие четыре типа:
Приемочное тестирование пользователей, а также альфа- и бета-тестирование описаны в следующем разделе # Типы тестирования.
Оперативная приемка используется для обеспечения операционной готовности (предварительного выпуска) продукта, услуги или системы как части системы менеджмента качества. OAT - это распространенный тип нефункционального тестирования программного обеспечения, используемый в основном в проектах разработка программного обеспечения и сопровождение программного обеспечения. Этот тип тестирования фокусируется на том, какая система будет поддерживаться или стать частью производственной среды. Следовательно, это также известно как тестирование операционной готовности (ORT) или тестирование операционной готовности и обеспечения (ORA). Функциональное тестирование в рамках OAT ограничивается теми тестами, которые необходимы для проверки нефункциональных аспектов системы.
Кроме того, тестирование программного обеспечения должно гарантировать, что переносимость системы, а также ее правильная работа, также не повреждают или частично повреждают ее операционную среду или не приводят к тому, что другие процессы в этой среде становятся неработоспособными. 247>
Контрактные приемочные испытания выполняются на основе критериев приемки контракта, определенных во время заключения контракта, в то время как нормативные приемочные испытания выполняются на основе соответствующих нормативных требований к программному продукту. Оба этих теста могут выполняться пользователями или независимыми тестировщиками. Приемочное тестирование в соответствии с нормативными требованиями иногда включает в себя проверку результатов тестирования регулирующими органами.
Различные ярлыки и способы группирования тестирования могут быть типами тестирования, тактиками тестирования программного обеспечения или методы.
TestingCup - Чемпионат Польши по тестированию программного обеспечения, Катовице, май 2016 г. Большинство программных систем имеют процедуры установки, которые необходимы, прежде чем они могут быть используются по своему основному назначению. Тестирование этих процедур для получения установленной программной системы, которую можно использовать, называется тестированием установки.
Распространенной причиной сбоя программного обеспечения (реального или предполагаемого) является отсутствие его совместимости с другим прикладным программным обеспечением, операционные системы (или операционные системы версии, старые или новые) или целевые среды, которые сильно отличаются от исходных (например, терминал или GUI приложение, предназначенное для запуска на рабочем столе, теперь требуется, чтобы оно стало веб-приложением, которое должно отображаться в веб-браузере ). Например, в случае отсутствия обратной совместимости это может произойти из-за того, что программисты разрабатывают и тестируют программное обеспечение только в последней версии целевой среды, которую могут использовать не все пользователи. Это приводит к непредвиденным последствиям: последняя работа может не работать в более ранних версиях целевой среды или на старом оборудовании, которое могли использовать более ранние версии целевой среды. Иногда такие проблемы могут быть исправлены путем упреждающего абстрагирования функциональности операционной системы в отдельную программу модуль или библиотеку.
проверка работоспособности определяет разумно ли продолжить дальнейшее тестирование.
Дымовое тестирование состоит из минимальных попыток работы с программным обеспечением, предназначенных для определения наличия каких-либо основных проблем, которые могут помешать ему вообще работать. Такие тесты можно использовать как тест проверки сборки.
Регрессионное тестирование фокусируется на обнаружении дефектов после того, как произошло серьезное изменение кода. В частности, он направлен на выявление регрессов программного обеспечения в виде деградированных или потерянных функций, включая возвращенные старые ошибки. Такие регрессии возникают, когда функциональные возможности программного обеспечения, которые ранее работали правильно, перестают работать должным образом. Обычно регрессия возникает как непреднамеренное последствие изменений программы, когда вновь разработанная часть программного обеспечения сталкивается с ранее существовавшим кодом. Регрессионное тестирование, как правило, является самым большим усилием по тестированию при разработке коммерческого программного обеспечения из-за проверки множества деталей в предыдущих функциях программного обеспечения, и даже новое программное обеспечение может быть разработано с использованием некоторых старых тестовых примеров для тестирования частей нового проекта, чтобы гарантировать, что предыдущие функции по-прежнему поддерживаются.
Общие методы регрессионного тестирования включают повторный запуск предыдущих наборов тестовыхПримеры и проверка того, возникли повторно ранее исправленные ошибки. Глубина тестирования зависит от фазы процесса выпуска и риска добавленных функций. Они могут быть полными для изменений, добавленных в конце выпуска или считающихся рискованными, или очень неглубокими, состоящими из положительных тестов каждой функции, если изменения находятся на ранней стадии выпуска или считаются неопасными. В регрессионном тестировании важно иметь твердое утверждение о существующем поведении. Для этого можно сгенерировать и добавить новые утверждения в вспомогательные тестовые примеры, это называется автоматическим усилением теста.
Приемочное тестирование может означать одно из двух:
Альфа-тестирование - это моделирование или фактическое эксплуатационное тестирование потенциальными пользователями / заказчиками или независимой группой тестирования в сайт разработчиков. Альфа-тестирование часто используется для готового программного обеспечения как форма внутреннего приемочного тестирования перед тем, как программное обеспечение перейдет в бета-тестирование.
Бета-тестирование проводится после альфа-тестирования и может быть считается формой внешнего приемочного тестирования пользователем. Версии программного обеспечения, известные как бета-версии, выпускаются для ограниченной аудитории за пределами группы программирования, известной как бета-тестеры. Программное обеспечение предоставляется группам людей, поэтому дальнейшее тестирование может гарантировать, что в продукте мало ошибок или ошибок. Бета-версии могут быть доступны для широкой публики, чтобы увеличить поле обратной связи до максимального числа будущих пользователей и предоставить ценность раньше, в течение длительного или даже неопределенного периода времени (бессрочная бета ).
Функциональное тестирование относится к действиям, которые проверяют конкретное действие или функцию кода. Они обычно находятся в документации требований к коду, хотя некоторые методологии разработки основываются на вариантах использования или пользователя. Функциональные тесты, как правило, отвечают на вопрос «может ли пользователь это сделать» или «работает ли эта конкретная функция».
Нефункциональное тестирование относится к аспектам программного обеспечения, которые могут не быть связаны с конкретным функция или действие пользователя, такое как масштабируемость или другое производительность, поведение при определенных ограничениях или безопасность. Тестирование определит предел, точка, в которой крайние значения масштабируемости или производительности приводят к нестабильному выполнению. Нефункциональные требования, как правило, отражают качество продукта, особенно в контексте пригодности его пользователей.
Непрерывное тестирование - это процесс выполнения автоматических тестов как части конвейера поставки программного обеспечения для получения немедленной обратной связи о бизнес-рисках, связанных с выпуском программного обеспечения-кандидата.. Непрерывное тестирование включает в себя проверку как функциональных требований, так и нефункциональных требований ; Объем тестирования простирается от проверки восходящих требований или пользовательских историй до оценки системных требований, связанных со всеобъемлющими бизнес-целями.
Разрушающее тестирование пытается вызвать программное обеспечение или вспомогательные система выйдет из строя. Он проверяет, что программное обеспечение функционирует должным образом, даже когда оно получает недопустимые или неожиданные входные данные, тем самым устанавливая надежность процедур проверки входных данных и управления ошибками. Внедрение ошибок программного обеспечения в форме фаззинг - это пример тестирования на отказ. Ссылки на различные коммерческие нефункциональные инструменты тестирования приведены на странице внедрение ошибок программного обеспечения ; также доступны многочисленные инструменты с открытым исходным кодом и бесплатные программные средства, выполняющие деструктивное тестирование.
Тестирование производительности обычно выполняется, чтобы определить, как система или подсистема работает с точки зрения скорости реагирования и стабильности при определенной рабочей нагрузке. Он также может служить для исследования, измерения, проверки или проверки других качественных характеристик системы, таких как масштабируемость, надежность и использование ресурсов.
Нагрузочное тестирование в первую очередь связано с проверкой того, может ли система продолжать работать при определенной нагрузке, будь то большие объемы данных или большое количество пользователей. Обычно это называется программной масштабируемостью. Связанное с этим нагрузочное тестирование, когда оно выполняется как нефункциональное действие, часто называют испытанием на выносливость. Объемное тестирование - это способ тестирования функций программного обеспечения, даже когда определенные компоненты (например, файл или база данных) радикально увеличиваются в размерах. Стресс-тестирование - это способ проверить надежность при неожиданных или редких рабочих нагрузках. Тестирование стабильности (часто называемое нагрузочным тестированием или тестированием на выносливость) проверяет, может ли приложение непрерывно работать в течение приемлемого периода или дольше.
Нет единого мнения о том, каковы результаты тестирования производительности. Термины нагрузочное тестирование, тестирование производительности, тестирование масштабируемости и объемное тестирование часто используются как синонимы.
Программное обеспечение реального времени системы имеют строгие временные ограничения. Для проверки соблюдения временных ограничений используется тестирование в реальном времени.
Юзабилити-тестирование - это проверка того, прост в использовании и понимании пользовательского интерфейса. В основном это касается использования приложения. Это не тот вид тестирования, который можно автоматизировать; необходимы реальные пользователи, которые контролируются опытными проектировщиками пользовательского интерфейса.
Тестирование доступности может соответствовать таким стандартам, как:
Тестирование безопасности необходимо для программного обеспечения, обрабатывающее конфиденциальные данные для предотвращения вторжения в систему со стороны хакеров.
Международная организация по стандартизации (ISO) определяет это как «тип тестирования, проводимого для оценки степени, в элементе определения тестирования, и связанных с ними данных. и информация защищена, чтобы неуполномоченные лица или системы не могли использовать, читать или использовать их, уполномоченными лицами или системам не было отказан о в доступе к ним ».
Тестирование интернационализации и локализации подтверждает, что софт tware можно использовать с разными языками и географическими регионами. Процесс псевдолокализации используется для проверки перевода приложения на другой язык и упрощения определения, когда процесс локализации может привести к появлению новых ошибок в продукте.
Тестирование глобализации подтверждает, что программное обеспечение адаптировано к новой культуре (например, к валютам или часовым поясам).
Фактический перевод на человеческие языки также должен быть протестирован. Возможные ошибки локализации и глобализации включают:
Тестирование разработки - это процесс разработки программного обеспечения, который включает синхронизированное применение широкого применения алгоритмов предотвращения и обнаружения дефектов с низкого уровня рисков, времени и затрат на программное обеспечение программного обеспечения. Это выполняется разработчиком программного обеспечения или инженерного этапа построения жизненного цикла разработки программного обеспечения. Тестирование разработки направлено на устранение ошибок конструкции до того, как код будет переведен на другое тестирование; эта стратегия для повышения качества программного обеспечения, а также эффективности всего процесса разработки.
В зависимости от ожидания организации в отношении разработки программного обеспечения, тестирование разработки может быть статический анализ кода, анализ потока данных, анализ показателей, экспертные проверки кода, модульное тестирование, анализ покрытия кода, отслеживаемость и другие методы тестирования программного обеспечения.
A / B-тестирование - это метод проведения контролируемого эксперимента, чтобы определить, является ли предлагаемое изменение более эффективным, чем текущий подход. Клиенты направляются либо к текущей версии (элемент управления), либо к измененной версии (лечению), и определяются данные, чтобы определить, какая версия лучше подходит для достижения желаемого результата.
Параллельное или параллельное тестирование оценивает поведение и производительность программного обеспечения и систем, которые используют параллельные вычисления, как правило, при нормальных условиях использования. Типичные проблемы, которые выявляют этот тип тестирования - это взаимоблокировки, состояния гонки и проблемы с общей памятью / обработкой ресурсов.
При тестировании программного обеспечения тестирование на соответствие соответствует, что продукт работает в соответствии с установленными стандартами. Компиляторы, например, тщательно тест определены, чтобы определить, соответствуют ли они установленному стандарту для этого языка.
Создание ожидаемого вывода для отображения, будь то сравнение данных текста или снимков экрана пользовательского интерфейса, в отличие от многих других, иногда называют тестированием снимков или тестированием Золотой Мастер. Тестирование формы тестирования, это не может автоматически обнаруживать сбои и вместо этого требует, чтобы человек оценивал результат на предмет несоответствий.
Распространенной практикой в каскадной разработке является то, что выполняется независимой тестировщиков. Это может пройти:
Однако даже в каскадной модели разработки модульное тестирование часто используется командой разработчиков программного обеспечения, даже если дальнейшее тестирование отдельной группой.
Напротив, некоторые новые дисциплины программного обеспечения, такие как экстремальное программирование и движение гибкой разработки программного обеспечения, придерживаются принципов "Тестовая разработка программного обеспечения " модель. В этом процессе модульные тесты сначала пишутся разработчиками программного обеспечения (часто с парным программированием в методологии экстремального программирования). Ожидается, что изначально тесты не пройдут. За неудачным тестом пишется ровно столько кода. Это означает, что наборы тестов постоянно обновляются и интегрируются с любыми регрессионными тестами. Модульные тесты поддерживаются вместе с остальным исходным кодом программного обеспечения, как правило, интегрируются в процесс сборки (при этом интерактивные тесты по сути к частично ручному процессу сборки).
Конечными целями процесса тестирования являются поддержка непрерывной интеграции и снижение количества дефектов.
Эта методология усилий по тестированию, выполняемые при разработке, до достижений-либо формальных команд тестирования. В некоторых других моделях разработки большая часть выполнения теста происходит после определения и завершения процесса кодирования.
Хотя между организациями существуют разные, существует типичный цикл тестирования. Приведенный ниже пример является распространенным среди организаций, использующих модель Waterfall. Те же методы обычно встречаются в других моделях разработки.
Многие группы программирования полагаются на большее и многое другое о автоматическом тестировании, особенно группы, которые используют через тестирование. Существует набор инструментов для написания тестов, программное обеспечение непрерывной интеграции будет запускать тесты автоматически каждый раз, когда код проверяется в системе контроля версий.
Хотя автоматизация не может воспроизвести все, что может сделать человек (и все способы, он может быть очень полезна для регрессионного тестирования). Однако, чтобы быть действительно полезным, он требует хорошо разработанного набора тестов тестовых скриптов.
Тестирование программ и обнаружению неисправностей может помочь инструменты тестирования и отладчики. Инструменты тестирования / отладки включают в себя такие функции, как:
Некоторые из этих функций могут быть включены в единую инструмент mposite или интегрированная среда разработки (IDE).
Меры качества включают такие темы, как правильность, полнота, безопасность и ISO / IEC 9126 такие требования, как возможности, надежность, эффективность, портативность, ремонтопригодность, совместимость и удобство использования.
количество часто используемых показателей программного обеспечения или показателей, которые используются для помощи в определении состояния программного обеспечения или адекватности тестирования.
На основе количества тестовых примеров, необходимых для построения полного набора тестов в каждом контексте (т. Е. Такого набора тестов, что, если он применяется к тестируемой реализации, то мы собираем достаточно информации, чтобы точно определить, является ли система правильной или неправильной в соответствии с некоторой спецификацией), была предложена иерархия сложности тестирования. Он включает следующие классы тестируемости :
Доказано, что каждый класс строго входит в следующий. Например, тестирование, когда мы предполагаем, что поведение тестируемой реализации может быть обозначено детерминированным конечным автоматом для некоторых известных конечных наборов входов и выходов и с некоторым известным количеством состояний, принадлежит классу Я (и все последующие классы). Однако, если количество состояний неизвестно, то оно относится только ко всем классам, начиная с Класса II. Если тестируемая реализация должна быть детерминированным конечным автоматом, не удовлетворяющим спецификации для одной трассы (и ее продолжений), и ее количество состояний неизвестно, то она принадлежит только классам, начиная с Класса III. Тестирование темпоральных машин, в которых переходы запускаются, если входы производятся в пределах некоторого реально ограниченного интервала, принадлежит только классам, начиная с класса IV, тогда как тестирование многих недетерминированных систем относится только к классу V (но не всем, а некоторые даже принадлежат классу I.). Включение в класс I не требует простоты предполагаемой модели вычислений, поскольку некоторые примеры тестирования, включающие реализации, написанные на любом языке программирования, и реализации тестирования, определенные как машины, зависящие от непрерывных величин, оказались в классе I. случаи, такие как структура тестирования Мэтью Хеннесси в соответствии с семантикой must и темпоральные машины с рациональными тайм-аутами, относятся к Классу II.
В процессе тестирования программного обеспечения может возникнуть несколько артефактов. Фактически создаваемые артефакты зависят от используемой модели разработки программного обеспечения, потребностей заинтересованных сторон и организации.
Существует несколько программ сертификации для поддержки профессиональных устремлений тестировщиков программного обеспечения и специалистов по обеспечению качества. Обратите внимание, что некоторые практики утверждают, что поле тестирования не готово к сертификации, как упоминалось в разделе противоречие.
Некоторые из основных разногласий по тестированию программного обеспечения включают:
Принято считать, что чем раньше обнаружен дефект, тем дешевле его исправить. В следующей таблице указана стоимость исправления дефекта в зависимости от стадии его обнаружения. Например, если проблема в требованиях обнаруживается только после выпуска, то ее исправление будет стоить в 10–100 раз дороже, чем если бы она уже была обнаружена в результате обзора требований. С появлением современных методов непрерывного развертывания и облачных сервисов стоимость повторного развертывания и обслуживания со временем может снизиться.
| Стоимость устранения дефекта | Время обнаружения | |||||
|---|---|---|---|---|---|---|
| Требования | Архитектура | Строительство | Тест системы | Пост- выпуск | ||
| Время появления | Требования | 1 × | 3 × | 5–10 × | 10 × | 10–100 × |
| Архитектура | – | 1 × | 10 × | 15 × | 25–100 × | |
| Строительство | – | – | 1 × | 10 × | 10–25 × | |
Данные, из которых экстраполирована эта таблица, скудны. Лоран Боссавит говорит в своем анализе:
Кривая «небольших проектов», оказывается, получена только от двух команд первокурсников, размер выборки настолько мал, что экстраполяция на «более мелкие проекты в целом» совершенно неоправданна. Исследование GTE не объясняет свои данные, за исключением того, что оно было получено в результате двух проектов, большого и малого. В документе, процитированном для проекта Bell Labs "Safeguard", прямо говорится о том, что он не собирал подробные данные, которые предполагают данные Боэма. Исследование IBM (статья Фагана) содержит утверждения, которые, кажется, противоречат графику Бема, и не содержат числовых результатов, которые явно соответствуют его точкам данных.
Бем даже не цитирует статью для данных TRW, за исключением того, что написал для «Making Software» в 2010 году, и там он процитировал оригинальную статью 1976 года. В TRW в нужное время было проведено большое исследование, чтобы Бем мог процитировать его, но этот документ не содержит тех данных, которые подтверждали бы утверждения Бема.
Тестирование программного обеспечения используется вместе с верификацией и валидацией :
Термины «верификация» и «валидация» обычно взаимозаменяемы в отрасли; также часто можно встретить эти два термина с противоречивыми определениями. Согласно Стандарту IEEE Глоссарий терминологии программной инженерии:
И, согласно стандарту ISO 9000:
Противоречие вызвано использованием понятий требований и заданных требований, но с разными значениями.
В случае стандартов IEEE указанные требования, упомянутые в определении валидации, представляют собой набор проблем, потребностей и желаний заинтересованных сторон, которые программное обеспечение должно решить и удовлетворить. Такие требования задокументированы в Спецификации требований к программному обеспечению (SRS). И продукты, упомянутые в определении верификации, являются выходными артефактами каждого этапа процесса разработки программного обеспечения. Фактически, эти продукты являются спецификациями, такими как Спецификация архитектурного проекта, Спецификация детального проектирования и т. Д. SRS также является спецификацией, но ее нельзя проверить (по крайней мере, в том смысле, который используется здесь, подробнее об этом ниже).
Но для ISO 9000 указанные требования представляют собой набор спецификаций, как только что упомянуто выше, которые необходимо проверить. Спецификация, как объяснялось ранее, является продуктом этапа процесса разработки программного обеспечения, который получает другую спецификацию в качестве входных данных. Спецификация успешно проверяется, если она правильно реализует входную спецификацию. Все спецификации могут быть проверены, кроме SRS, потому что это первая (хотя она может быть проверена). Примеры: Спецификация проекта должна реализовывать SRS; и артефакты фазы построения должны реализовывать спецификацию проектирования.
Итак, когда эти слова определены в общих терминах, очевидное противоречие исчезает.
И SRS, и программное обеспечение должны быть проверены. SRS можно проверить статически, проконсультировавшись с заинтересованными сторонами. Тем не менее, запуск некоторой частичной реализации программного обеспечения или любого прототипа (динамическое тестирование) и получение от них положительных отзывов может еще больше повысить уверенность в том, что SRS сформулирована правильно. С другой стороны, программное обеспечение как конечный и работающий продукт (а не его артефакты и документы, включая исходный код) должно динамически подтверждаться заинтересованными сторонами путем выполнения программного обеспечения и их тестирования.
Некоторые могут возразить, что для SRS входными данными являются слова заинтересованных сторон, и поэтому проверка SRS аналогична проверке SRS. Думать подобным образом не рекомендуется, так как это только приведет к еще большей путанице. Лучше рассматривать верификацию как процесс, включающий формальный и технический входной документ.
Тестирование программного обеспечения может рассматриваться как часть процесса обеспечения качества программного обеспечения (SQA). В SQA специалисты по процессам программного обеспечения и аудиторы озабочены процессом разработки программного обеспечения, а не только артефактами, такими как документация, код и системы. Они исследуют и изменяют сам процесс программной инженерии, чтобы уменьшить количество ошибок, которые заканчиваются в поставляемом программном обеспечении: так называемую частоту дефектов. Что составляет приемлемый уровень дефектов, зависит от характера программного обеспечения; Видеоигра для симулятора полета будет иметь гораздо более высокую устойчивость к дефектам, чем программное обеспечение для реального самолета. Хотя существуют тесные связи с SQA, отделы тестирования часто существуют независимо, и в некоторых компаниях может не быть функции SQA.
Тестирование программного обеспечения - это деятельность по исследованию тестируемого программного обеспечения с целью предоставления информации, связанной с качеством, для заинтересованные стороны. В отличие от этого, QA (обеспечение качества ) - это реализация политик и процедур, предназначенных для предотвращения появления дефектов у клиентов.
 | На Викискладе есть материалы, связанные с тестированием программного обеспечения. |
 | В Викиверситете вы можете узнать больше и рассказать другим о тестировании программного обеспечения в Департаменте тестирования программного обеспечения |
