Что является целью тестирования программ почему

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

Цели и этапы тестирования ПО

Цели тестирования:

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

Этапы тестирования:

1. Анализ
2. Разработка стратегии тестирования и планирование процедур контроля качества
3. Работа с требованиями
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

Градации дефектов и типы тестирования ПО

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

Тестировщик с нуля | Урок 3 | Цели тестирования

Жизненный цикл разработки ПО:

• Пре-альфа
• Альфа
• Бета
• Релиз-кандидат
• Релиз
• Пост-релиз

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

Градация cерьезности дефекта (Severity):

• Блокирующая (Blocker) — Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.
• Критическая (Critical) — Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
• Значительная (Major) — Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
• Незначительная (Minor) — Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
• Тривиальная (Trivial) — Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Градация приоритета дефекта (Priority):

Тестировщик с нуля: Цели тестирования

• Высокий (High) — Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
• Средний (Medium) — Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
• Низкий (Low) — Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Типы тестирования ПО:

• Тестирование типа «белый ящик» проверяет внутренние структуры и модули, игнорирует ожидаемую функциональность для конечных пользователей. Это может быть тестирование API, внесение неисправностей (fault injection), модульное тестирование, интеграционное тестирование.
• Тестирование типа «чёрный ящик» больше интересуется тем, что делает ПО, а не как делает. Это означает, что тестировщики не обязаны ни разбираться в объекте тестирования, ни понимать, как он работает под капотом. Такой тип тестирования нацелен на конечных пользователей, их опыт взаимодействия с видимым интерфейсом. К «чёрным ящикам» относится тестирование на основе моделей, тестирование способов использования, таблицы переходов состояний, спецификационное тестирование и т. д.
• Тестирование типа «серый ящик» проектируется со знанием программных алгоритмов и структур данных (белый ящик), но выполняется на пользовательском уровне (чёрный ящик). Сюда относится регрессионное тестирование и шаблонное тестирование (pattern testing).

Документация и планирование тестирования ПО

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

Отвечает на вопросы:

• Что надо тестировать?
• Что будете тестировать?
• Как будете тестировать?
• Когда будете тестировать?
• Критерии начала тестирования.
• Критерии окончания тестирования.

Тест-кейс (тестовый случай, test case) — это набор условий и/или переменных, с помощью которых тестировщик будет определять насколько полно тестируемое приложение удовлетворяет предъявляемому к нему требованию. Для того, чтобы убедиться, что требование полностью удовлетворяется, может понадобиться несколько тест-кейсов.

Для полного тестирования всех требований, предъявляемых к приложению, должен быть создан/выполнен по меньшей мере один тест-кейс для каждого требования. Если требование имеет дочерние требования, то для каждого такого дочернего требования должен быть создан/выполнен также по крайней мере один тест-кейс. Некоторые методологии (например, RUP) рекомендуют создавать по меньшей мере два тест-кейса для каждого требования. Один из них должен выполнять позитивное тестирование, другой — негативное.

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

Тест дизайн (Test design) — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.

Роли, ответственные за тест дизайн:
• Тест аналитик — определяет «ЧТО тестировать?»
• Тест дизайнер — определяет «КАК тестировать?»

Баг Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

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

Виды тестирования ПО

Модульное тестирование (Unit testing)

— это тестирование отдельных компонентов приложения.

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

Функциональное тестирование (Functional testing)

— это тип тестирования рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.

Функциональные тесты немного сходны с приемочными. Но в отличие от последних — не требуется запускать веб-сервер. На данном этапе происходит эмуляция переменных запроса (GET, POST и т.д.) к веб-приложению. Функциональное тестирование широко применяется для тестирования Restfull API сервисов.

Приемочное тестирование (Acceptance testing)

— это формальное тестирование по отношению к потребностям, требованиям и бизнес процессам пользователя, проводимое с целью определения соответствия системы критериям приёмки.

В веб-приложениях обычно эммулируется работа пользователя с сайтом через веб-браузер. При приемочном автоматизированном тестировании используют инструмент Selenium (Selenium — это инструмент для тестирования Web-приложений.) с WebDriver (WebDriver — это набор «биндингов» к разным языкам (C#, Java), позволяющий отдавать различные команды Selenium).

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

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

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

Нагрузочное тестирование

— это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.

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

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

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

Источник: blog-programmista.ru

Цели и задачи тестирования?

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

1. В чем отличие тестирования от отладки?

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

Тестирование позволяет выявить эти ошибки.

1. Что такое Верификация (verification) и что такое Валидация (validation)?

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

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

1. Какие стратегииподходы тестирования Вы знаете? Перечислите их.

Подходы

• Black Box (нет доступа к исходному коду, тестирование с точки зрения конечного пользователя)

• White Box (есть доступ к исходному коду, позволяет проверить внутреннюю структуру программы, анализ приложения на уровне кода)
• Grey Box (есть доступ к части кода, смешанная методика)

1. Какие уровни тестирования Вы знаете? Перечислите их.

Уровни

• Модульное (Unit-testing) — тестирование независимых элементов кода
• Интеграционное (Integration-testing) – тестирование интерфейсов между протестированными модулями
• Системное (System-testing)
• Приемочное (Acceptance-testing) — тестирование на стороне заказчика

1. Какие виды тестирования Вы знаете? Перечислите их.

• Функциональное
• Тестирование производительности (performance testing)
• Нагрузочное тестирование (load testing)
• Стресс-тестирование (stress testing)
• Тестирование безопасности
• Localization testing
• Platform testing
• Installation testing
• Regression testing

1. Перечислите основные этапы процесса тестирования.

• Planning (планирование – определение целей, стратегии, подготовка тестового окружения, расстановка приоритетов)
• Test-case design Metrics (оценка, метрики – проектные, процессные, product-метрики)

1. Что такое требование к ПО?

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

1. Какие бывают типы требований?

• Бизнес-требования —Содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью.
• Пользовательские требования —Описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.
• Функциональные требования — определяют что должен реализовать продукт. Описывается в системной спецификации. Определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе». Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.
• Нефункциональные требования – описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся: * легкость и простота использования * легкость перемещения * целостность * эффективность и устойчивость к сбоям * внешние взаимодействия между системой и внешним миром * ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

1. Что такое Test Case?

Test Case — это специальная, искусственно созданная ситуация, выбранная определённым образом, и описание того, какие наблюдения за работой программы нужно сделать для проверки её соответствия некоторому требованию

1. Что должно быть в описании тест-кейса (приведите пример)?

• Preconditions (предусловия) — список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния
• Actions,Steps (шаги) – список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о соответствии поставленным требованиям
• ExpectedResult (ожидаемый результат) – результат, который должен получиться после выполнения тест-кейса в соответствии с требованиями

1. Что такое Test Matrix (Тестовая матрица)?

Тестовая матрица – это матрица, в которой хранятся test cases со всеми необходимыми параметрами для их описания:

• ID
• Description
• Pre-Conditions
• Entry Point
• Actions
• Expected Result
• Requirement ID
• Priority

1. Что является источникомоснованием для создания тест-кейсов?

Требования (Requirements)

1. Какие техники создания тест-кейсов Вы знаете? Перечислите и опишите основную идею каждой из них.

• Разбиение на классы эквивалентности

1. Выделяются правильные и неправильные классы эквивалентности;
2. Тестируется правильный класс для каждого корректного значения;
3. Тестируется одно некорректное значение за раз.

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

1. Определяется список возможных условий и действий;
2. Определяются комбинации условий и действий;
3. Создается тест-кейс для каждого правила (столбца).

• Метод функциональных диаграмм

1. Осуществляется декомпозиция функциональных требований;
2. Выписываются причины, каждой из них присваивается уникальный номер;
3. Выписываются последствия, каждому из них также присваивается уникальный номер;
4. По спецификации составляется граф «причина-последствие»;
5. Строится таблица решений;
6. Записывается тест-кейс для каждого столбца.

1. Что такое «ошибка» (дефект, «баг»)?

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

1. Какая информация обязательно должна быть в отчете об ошибке, чтобы ее можно было воспроизвести?

• Bug ID– номер ошибки
• Status – состояние ошибки
• Title – краткое описание
• Description – содержит информацию о шагах, ожидаемом и полученном результатах, версии билда, тестовом окружении
• Severity – может указывать тестировщик
• Priority – насколько ошибка критична для end-user’а
• Date – дата обнаружения
• Author – тестировщик, нашедший ошибку
• Test-caseID – номер тест-кейса в матрице
• Requirement ID – номер требования
• ResponsiblePerson – девелопер, ответственный за исправление

Источник: studfile.net

Home

В соответствие с IEEE Std 829-1983 Тестирование — это процесс анализа ПО, направленный на выявление отличий между его реально существующими и требуемыми свойствами (дефект) и на оценку свойств ПО.

По ГОСТ Р ИСО МЭК 12207-99 в жизненном цикле ПО определены среди прочих вспомогательные процессы верификации, аттестации, совместного анализа и аудита. Процесс верификации является процессом определения того, что программные продукты функционируют в полном соответствии с требованиями или условиями, реализованными в предшествующих работах.

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

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

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

Жизненный цикл продукта и тестирование

Все чаще в наше время используются итеративные процессы разработки ПО, в частности, технология RUP — Rational Unified Process (Рис. 1). При использовании такого подхода тестирование перестает быть процессом «на отшибе», который запускается после того, как программисты написали весь необходимый код.

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

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

Рис. 1. Жизненный цикл продукта по RUP

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

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

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

В итерациях второй фазы — Разработка — основное внимание уделяется проектированию и опробованию ключевых проектных решений. В третьей фазе — Построение — наиболее велика доля задач разработки и тестирования. А в последней фазе — Передача — решаются в наибольшей мере задачи тестирования и передачи системы Заказчику.

Рис. 2. Итерации жизненного цикла программного продукта

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

Категории тестирования

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

• нагрузочное тестирование;
• тестирование бизнес циклов;
• стрессовое тестирование.

• нагрузочное тестирование;
• тестирование бизнес циклов;
• стрессовое тестирование.

Подкатегории тестирования

• unit-тестирование (модульное тестирование);
• функциональное тестирование;
• тестирование интерфейса;
• тестирование БД

• unit-тестирование (модульное тестирование);
• функциональное тестирование;
• тестирование интерфейса;
• тестирование БД.

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

• unit-тестирование (модульное тестирование);
• функциональное тестирование;
• тестирование интерфейса;
• тестирование БД.

Виды тестирования

Unit-тестирование (модульное тестирование) — данный вид подразумевает тестирование отдельных модулей приложения. Для получения максимального результата тестирование проводится одновременно с разработкой модулей.

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

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

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

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

В выходную документацию данных тестов входят тестовые процедуры, входные данные, код, исполняющий тест, выходные данные. Далее представлен вид выходной документации.

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

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