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

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

Функциональные.
Нефункциональные.
Связанные с изменениями.

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

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

Функциональные тесты базируются на функциях и особенностях, а также на взаимодействии с другими системами и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing), приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов.

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

1.Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).

Тестирование функциональности может проводиться в двух аспектах:

Требования.
Бизнес-процессы.

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

Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этом аспекте тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

Преимущества функционального тестирования:

имитирует фактическое использование системы.

Недостатки функционального тестирования:

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

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

2. Тестирование безопасности (Security and Access Control Testing)

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

Принципы безопасности программного обеспечения

Общая стратегия безопасности основывается на трех основных принципах:

Конфиденциальность.
Целостность.
Доступность.

Конфиденциальность

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

Целостность

Существует два основных критерия при определении понятия целостности:

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

Доступность

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

3. Тестирование взаимодействия или Interoperability Testing

Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing).

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

Нефункциональные виды тестирования

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

1.Все виды тестирования производительности

Тестирование производительности ( Performance testing ).

Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:

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

Стрессовое тестирование ( Stress Testing )

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

Объемное тестирование ( Volume Testing )

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

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

Тестирование стабильности или надежности( Stability / Reliability Testing)

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

В англоязычной терминологии вы можете так же найти еще один вид тестирования — Load Testing — тестирование реакции системы на изменение нагрузки (в пределе допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.

2. Тестирование Установки (Installation Testing)

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

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

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

В распределенных системах, где приложение разворачивается на уже работающем окружении, простого набора инструкций может быть мало. Для этого часто пишется план установки (Deployment Plan), включающий не только шаги по инсталляции приложения, но и шаги отката (roll-back) к предыдущей версии (в случае неудачи). Сам по себе план установки также должен пройти процедуру тестирования для избежания проблем при выдаче в реальную эксплуатацию. Особенно это актуально, если установка выполняется на системы, где каждая минута простоя — это потеря репутации и большого количества средств, например: банки, финансовые компании или даже баннерные сети. Поэтому тестирование установки можно назвать одной из важнейших задач по обеспечению качества программного обеспечения.

3. Тестирование удобства пользования (Usability Testing)

Иногда мы сталкиваемся с непонятными или нелогичными приложениями, многие функции и способы использования которых часто не очевидны. После такой работы редко возникает желание использовать приложение снова, и мы ищем более удобные аналоги. Для того, чтобы приложение было популярным, ему мало быть функциональным – оно должно быть еще и удобным. Если задуматься, интуитивно понятные приложения экономят нервы пользователям и затраты работодателя на обучение. Значит, они более конкурентоспособные! Поэтому тестирование удобства использования, о котором пойдет речь далее, является неотъемлемой частью тестирования любых массовых продуктов.

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

Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:

Производительность, эффективность ( efficiency) — сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д. (меньше — лучше).
Правильность ( accuracy) — сколько ошибок сделал пользователь во время работы с приложением (меньше — лучше).
Активизация в памяти ( recall ) – как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени (повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя).
Эмоциональная реакция ( emotional response ) – как пользователь себя чувствует после завершения задачи — растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция — лучше).

Уровни проведения

Проверка удобства использования может проводиться как по отношению к готовому продукту, посредством тестирования черного ящика (black box testing), так и к интерфейсам приложения (API), используемым при разработке — тестирование белого ящика (white box testing). В этом случае проверяется удобство использования внутренних объектов, классов, методов и переменных, а также рассматривается удобство изменения, расширения системы и интеграции ее с другими модулями или системами. Использование удобных интерфейсов (API) может улучшить качество, увеличить скорость написания и поддержки разрабатываемого кода и, как следствие, улучшить качество продукта в целом.

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

Советы по улучшению удобства пользования:

Для дизайна удобных приложений полезно следовать принципам «пока-йока» или fail-safe. У нас это более известно как «защита от дурака». Простой пример: если поле требует цифровое значение,то логично ограничить пользователю диапазон ввода только цифрами – будет меньше случайных ошибок.
Для повышения юзабилити существующих приложений можно использовать цикл Демминга (Plan-Do-Check-Act), собирая отзывы о работе и дизайне приложения у существующих пользователей, и, в соответствии с их замечаниями, планируя и проводя улучшения.

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

Тестирование пользовательского интерфейса = Тестирование удобства пользования

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

Тестирование удобства пользования можно провести без участия эксперта

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

4. Тестирование на отказ и восстановление (Failover and Recovery Testing)

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

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

Тестирование на отказ и восстановление очень важно для систем, работающих по принципу “24×7”. Если Вы создаете продукт, который будет работать, например,в интернете, то без проведения данного вида тестирования Вам просто не обойтись, т.к. каждая минута простоя или потеря данных, в случае отказа оборудования, может стоить вам денег, потери клиентов и репутации на рынке.

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

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

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

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

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

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

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

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

5. Конфигурационное тестирование (Configuration Testing)

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

В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

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

Примечание: В ISTQB Syllabus вообще не говорится о таком виде тестирования, как конфигурационное. Согласно глоссарию, данный вид тестирования рассматривается там как тестирование портируемости(portability testing: The process of testing to determine the portability of a software product.).

Связанные с изменениями виды тестирования

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

1. Дымовое тестирование (Smoke Testing)

Понятие дымовое тестирование пошло из инженерной среды:

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

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

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

Аналогами дымового тестирования являются Build Verification Testing и Acceptance Testing, выполняемые на функциональном уровне командой тестирования, по результатам которых делается вывод о том, принимается или нет установленная версия программного обеспечения в тестирование, эксплуатацию или на поставку заказчику.

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

2. Регрессионное тестирование (Regression Testing)

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

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

Сам по себе термин «регрессионное тестирование», в зависимости от контекста использования, может иметь разный смысл. Сэм Канер, к примеру, описал 3 основных типа регрессионного тестирования:

Регрессия багов (Bug regression) — попытка доказать, что исправленная ошибка на самом деле не исправлена.
Регрессия старых багов (Old bugs regression) — попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, т.е. старые баги стали снова воспроизводиться.
Регрессия побочного эффекта (Side effect regression) — попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения.

3. Тестирование сборки (Build Verification Test)

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

4. Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

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

Отличие санитарного тестирования от дымового (Sanity vs Smoke testing)

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

Источник

I. Виды тестирования по цели

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

Функциональные.
Нефункциональные.
Связанные с изменениями.

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

Функциональные тесты базируются на функциях и особенностях, а также на взаимодействии с другими системами и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing), приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов.

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

Тестирование функциональности может проводиться в двух аспектах:

Требования.
Бизнес-процессы.

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

Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этом аспекте тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

2. Тестирование безопасности (Security and Access Control Testing)

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

Общая стратегия безопасности основывается на трех основных принципах:

Конфиденциальность.
Целостность.
Доступность.

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

Существует два основных критерия при определении понятия целостности:

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

3. Тестирование взаимодействия или Interoperability Testing

Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing).

Нефункциональные виды тестирования

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

1.Все виды тестирования производительности

Тестирование производительности ( Performance testing ).

Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:

Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.

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

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

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

Стрессовое тестирование ( Stress Testing )

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

Объемное тестирование ( Volume Testing )

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

Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.

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

Тестирование стабильности или надежности( Stability / Reliability Testing)

2. Тестирование установки (Installation Testing)

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

3. Тестирование удобства пользования (Usability Testing)

Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:

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

Правильность ( accuracy) — сколько ошибок сделал пользователь во время работы с приложением (меньше — лучше).

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

Эмоциональная реакция ( emotional response ) – как пользователь себя чувствует после завершения задачи — растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция — лучше).

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

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

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

Дымовое тестирование (Smoke Testing)
Регрессионное тестирование (Regression Testing)
Тестирование сборки (Build Verification Test)
Санитарное тестирование или проверка согласованности/исправности (SanityTesting)

Дымовой тест (англ. Smoke testing или smoke test, дымовое тестирование) — в тестировании программного обеспечения означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется программистом; не проходившую этот тест программу не имеет смысла отдавать на более глубокое тестирование.

Тестирование сборки (Build Verification Test), как и дымное тестирование, направленно для предварительной проверки разрабатываемого программного продукта перед запуском полномасштабного тестирования по всем параметрам, проводимого командой тестировщиков. Проводится оно для того, чтобы знать – готов ли релиз для такого этапа разработки ПО, как Тестирование или же он еще нуждается в доработке.

Тестирование сборки состоит из набора коротких тестов, которые и определяют готовность сборки.

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

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

Цель санитарного тестирования — проверить «рациональность» системы после изменений, чтобы продолжить более тщательное тестирование.

II. Виды тестирования по степени автоматизации

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

Тем не менее, перед тем как автоматизировать тестирование любого приложения, необходимо сначала выполнить серию тестов вручную. Мануальное тестирование требует значительных усилий, но без него мы не сможем убедиться в том, возможна ли автоматизация в принципе. Один из фундаментальных принципов тестирования гласит: 100% автоматизация невозможна. Поэтому, ручное тестирование – необходимость.

Мифы о ручном тестировании:

– кто угодно может провести ручное тестирование

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

– автоматизированное тестирование мощнее ручного

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

– ручное тестирование – это просто

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

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

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

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

Существует несколько основных видов автоматизированного тестирования:

– автоматизация тестирования кода (Code-driven testing) – тестирование на уровне программных модулей, классов и библиотек (фактически, автоматические юнит-тесты);

– автоматизация тестирования графического пользовательского интерфейса (Graphical user interface testing) – специальная программа (фреймворк автоматизации тестирования) позволяет генерировать пользовательские события – нажатия клавиш, клики мышкой, и отслеживать реакцию программы на эти действия – соответствует ли она спецификации.

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

Автоматические тесты – это полноценные программы, просто предназначенные для тестирования.

III. Виды тестирования по запуску кода

Статическое тестирование (static testing) — тестирование без запуска кода на исполнение.

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

Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации.

Можно поделить статическое тестирование на 2 типа:

1. Обзоры (Review)

2. Статический анализ (Static Analysis)

Обзоры

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

В свою очередь обзоры делятся на:

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

Статический анализ

Статический анализ (Static Analysis) – код, написанный разработчиками, анализируется на наличие структурных дефектов, которые могут привести к ошибкам.

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

— неиспользуемые переменные,

— мертвый код,

— бесконечные циклы,

— переменные с неопределенными значениями,

— неправильный синтаксис.

В рамках этого подхода тестированию могут подвергаться:

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

Динамическое тестирование (dynamic testing) — тестирование с запуском кода на исполнение. Запускаться на исполнение может как код всего приложения целиком (системное тестирование), так и код нескольких взаимосвязанных частей (интеграционное тестирование), отдельных частей (модульное или компонентное тестирование) и даже отдельные участки кода.

Основная идея этого вида тестирования состоит в том, что проверяется реальное поведение (части) приложения.

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

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

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

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

IV. Виды тестирования по времени проведения

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

Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

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

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

Дымовое тестирование или Smoke Testing

Понятие дымовое тестирование пошло из инженерной среды:

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

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

Регрессио́нное тести́рование (англ. regression testing, от лат. regressio — движение назад) — собирательное название для всех видов тестирования программного обеспечения, направленных на обнаружение ошибок в уже протестированных участках исходного кода. Такие ошибки — когда после внесения изменений в программу перестает работать то, что должно было продолжать работать, — называют регрессионными ошибками (англ. regression bugs).

Регрессионное тестирование (по некоторым источникам) включает new bug-fix — проверка исправления найденного ранее дефекта, old bug-fix — проверка, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова, а также side-effect — проверка того, что не нарушилась работоспособность работающей ранее функциональности, если ее код мог быть затронут при исправлении некоторых дефектов в другой функциональности. Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов, а также проверки, не попали ли регрессионные ошибки в очередную версию в результате слияния кода.

Из опыта разработки ПО известно, что повторное появление одних и тех же ошибок — случай достаточно частый. Иногда это происходит из-за слабой техники управления версиями или по причине человеческой ошибки при работе с системой управления версиями. Но настолько же часто решение проблемы бывает «недолго живущим»: после следующего изменения в программе решение перестаёт работать. И наконец, при переписывании какой-либо части кода часто всплывают те же ошибки, что были в предыдущей реализации.

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

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

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

Приемочное тестирование или Приемо-сдаточное испытание (User Acceptance Testing)

Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

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

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

продукт достиг необходимого уровня качества;
заказчик ознакомлен с Планом Приемочных Работ (Product Acceptance Plan) или иным документом, где описан набор действий, связанных с проведением приемочного тестирования, дата проведения, ответственные и т.д.

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

V. Виды тестирования по доступу к коду (методы тестирования)

Метод белого ящика

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

Метод черного ящика

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

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

VI. Виды тестирования по позитивности сценария

Позитивное тестирование – это тестирование с применением сценариев, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. С его помощью мы можем определить, что система делает то, для чего и была создана. Например, умножение на калькуляторе цифр 3 и 5.

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

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

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

Источники:

https://qastart.by/class/vidi-testirovaniya-m/4-vidi-testirivaniya-po-celi
http://www.protesting.ru/testing/testtypes.html
https://qalight.ua/ru/baza-znaniy/ruchnoe-i-avtomatizirovannoe/
https://studfile.net/preview/2426273/page:7/
https://vk.com/@zapiskisedogotestera-vidy-testirovaniya-po-zapusku-koda
https://qalight.ua/ru/baza-znaniy/testirovanie-sborki/
https://intellect.icu/sanitarnoe-testirovanie-ili-proverka-soglasovannosti-ispravnosti-ili-sanity-testing-6092

Источник

Узнайте о целях, видах и типах тестирования программного обеспечения

В Интернете постоянно встречаются вопросы на тему «Тестирование ПО»: что это такое, каково определение терминов этого процесса.

В статье мы поговорим о тестировании, узнаем его разновидности.

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

Тестирование – это одна из техник регулировки качества программы. Его этапы:

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

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

Можно выделить такие виды тестирования программного обеспечения :

Разберем каждый из них по отдельности.

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

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

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

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

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

Тестирование взаимодействия

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

Нефункциональные виды тестирования

Тестирование надежности

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

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

Проверяет инсталляцию и ее настройки, обновления и удаление ПО.

Стрессовое тестирование

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

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

Еще одна задача такого тестирования – дать оценку деградированию работы системы.

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

Этот метод тестирования направлен на определение степени удобности применения, понятности и привлекательности для юзеров.

Объемное тестирование

Задача этого теста – получить оценку производительности во время увеличения количества информации в БД приложения.

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

Эмулирует работу большого количества пользователей на каком-то ресурсе.

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

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

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

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

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

Виды тестирования, которые связаны с изменениями

Дымовое

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

Регрессионное

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

Повторное

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

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

Дает возможность определить соответствие выпущенной версии основным параметрам качества.

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

Санитарное

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

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

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

Также отдельным пунктом стоит выделить Тестирование пользовательского интерфейса (UI).

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

Вопросы-ответы

Что такое системное тестирование?

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

Что представляет собой тест-кейс?

Тест-кейс является описанием проверки работы системы. Он может быть как длинным, так и коротким. Написать кейс может любой участник команды, не только тестировщик.

Заключение

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

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

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

Где научиться тестированию и как к этому правильно подойти?

Запишитесь на этот курс – и под руководством опытных преподавателей вы узнаете все тонкости тестирования, научитесь проверять как Web-приложения, так и мобильные.

Курс рассчитан на 4 месяца, занятия проходят 5 раз в неделю. Длительность каждого урока – 4 часа.

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

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

Записывайтесь прямо сейчас на курс и становитесь на более высокую ступень профессионального развития.

Источник

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

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

Для чего проводится тестирование ПО?

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

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

К задачам обеспечения качества относятся:

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

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

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

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

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

Программный продукт проходит следующие стадии:

Требования

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

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

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

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

Тестовые среды

Основные фазы тестирования

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

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

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

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

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

Согласно ISTQB, тестирование белого ящика — это:

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

Согласно ISTQB, тестирование черного ящика — это:

Тестовая документация

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

Тест план должен отвечать на следующие вопросы:

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

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

Атрибуты тест кейса:

Источник

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

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

Тестирование функциональности может проводиться в двух аспектах:

Преимущества функционального тестирования:

Недостатки функционального тестирования:

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

2. Тестирование безопасности (Security and Access Control Testing)

Принципы безопасности программного обеспечения

Общая стратегия безопасности основывается на трех основных принципах:

Конфиденциальность

Целостность

Существует два основных критерия при определении понятия целостности:

Доступность

3. Тестирование взаимодействия или Interoperability Testing

Нефункциональные виды тестирования

1.Все виды тестирования производительности

Тестирование производительности ( Performance testing ).

Стрессовое тестирование ( Stress Testing )

Объемное тестирование ( Volume Testing )

Тестирование стабильности или надежности( Stability / Reliability Testing)

2. Тестирование Установки (Installation Testing)

3. Тестирование удобства пользования (Usability Testing)

Уровни проведения

Советы по улучшению удобства пользования:

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

4. Тестирование на отказ и восстановление (Failover and Recovery Testing)

5. Конфигурационное тестирование (Configuration Testing)

В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:

Связанные с изменениями виды тестирования

1. Дымовое тестирование (Smoke Testing)

Понятие дымовое тестирование пошло из инженерной среды:

2. Регрессионное тестирование (Regression Testing)

3. Тестирование сборки (Build Verification Test)

4. Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

Отличие санитарного тестирования от дымового (Sanity vs Smoke testing)

Источник

3.2.1. Специфика тестирования бизнес-процесса —

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

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

в основе обеих
объектов лежит понятие алгоритма;
обаобъекта имеют
одинаковые этапы жизненного цикла;

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

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

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

содержать:

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

Для
целей тестирования объект удобно
представлять в виде ориентированного
графа G
— (N,
£),
где N
=
{N_x,
N₂,
—, N_m)
— множество
узлов (вершин), соответствующих функционалу
объекта;
Е
— (Е_и
Е₂,…,
Е„)
—
множество ребер (дуг), соответствующих
передачам управления между функциями.

Путем
(маршрутом)
называется последовательность вершин
и дуг Р= (N_h
E_U₂,
N₂,
£₂
j,…,
Е_к._и,
N_k),
где
каждая дуга E_ii₊_l
выходит
из N_t
и
входит в N‘_t₊_b
причем
TV,
не обязательно начальный узел.
Ветвью
называется
путь Р,
в
котором N_x
—
либо начальный узел,
либо узел ветвления, N_k
—
узел ветвления либо завершающий
узел, все остальные JV,-
не являются узлами ветвления.

/Очевидно,
что полное тестирование всех возможных
маршру

тов
нереально в связи с огромными затратами
труда и времени.

Поэтому на практике
применяются критерии выбора тестов,
не

гарантирующие
полной проверки объекта. Общим требованием
к

этим
критериям является достижение лишь
определенной степе

ни
полноты покрытия объекта или его
компонентов. Как прави

ло,
эти критерии устанавливают требование,
по крайней мере,

однократной
проверки всех функций (критерий С₀),
всех его вет

вей
(критерий С_х)
либо
всех полпутей специального вида.
Самым

распространенным
критерием тестирования является
критерий,

требующий
по крайней мере однократной проверки
каждой из

ветвей объекта (критерий
С,). Например, тестирование при при

емке
программного обеспечения для ВВС США
производится на

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

зование критерия С,
обеспечивает обнаружение <я?61%
до
90%

ошибок. ■-.-■■

Однако
бизнес-процесс является гораздо более
сложным и непредсказуемым
объектом, чем обычная компьютерная
прог-.
дамма, в том числе и параллельная. Если
последняя содержит ряд управляющих
параллелизмом механизмов, таких, как
механизмы с?тхронизации
ветвей, то выполнение бизнес-пдоцесса,
вообще сребря,
непредсказуемо. Например, любое ЛПР^южет
приказать своему
подчиненному изменить традиционный
маршрут испол-аения
би?нее-процесса (типичный пример приказа
такого рода — «к
этот
Документ передайте не Ивану Ивановичу,
как обычно, а Петру
Петровичу»). В то же время даже для
последовательных арограмм
задача тестирования является
трудноразрешимой. Из-эестно,
что полное и исчерпывающее ее тестирование
практически
невозможно, так как требует огромных
трудозатрат. Таким образом,
перефразировав известное утверждение
Дейкстры (касаю-чееся
программного обеспечения), можно сказать,
что любой 1нзнес-процесс
содержит хотя бы одну ошибку — просто
пока «ще
небыли созданы условия для ее проявления.

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

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

убыток.

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

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

создание
информационных объектов (ИО) и/или их
атрибутов, не используемых в дальнейшей
деятельности;
отсутствие и/или
неполнота ИО и/или их атрибутов;
дублирование
ИО и/или их атрибутов и, как следствие,
их не- „ согласованность
и противоречивость и др.

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

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

17.1

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

Источник

1.

Требования. Анализ требований. Тестирование
документации. Виды и направления
тестирования.
www.andersenlab.com

2.

План лекции
Что такое требование?
Виды требований
Источники и пути выявления требований
Анализ требований
Тестирование требований
Виды документации
Методы тестирования
Типы тестирования
Уровни тестирования
Виды тестирования

3.

Что такое требование
Требование
это описание того, какие функции и с соблюдением каких условий должно выполнять
приложение в процессе решения полезной для пользователя задачи
Важность требований:
● Позволяют понять, что и с соблюдением
каких условий система должна делать.
● Предоставляют возможность оценить масштаб
изменений и управлять изменениями.
● Являются основой для формирования плана
проекта (в том числе плана тестирования).
● Помогают предотвращать или разрешать конфликтные ситуации.
● Упрощают расстановку приоритетов в наборе задач.
● Позволяют объективно оценить степень прогресса в разработке проекта.

4.

Важность требований

5.

Источники и пути выявления требований
Источники и пути выявления требований
Use case.
Совещание.
Анкетирование.
Интервью, опросы.
“Мозговой штурм”, семинары.
Анализ моделей деятельности.
Анализ конкурентных продуктов.
Анализ нормативной документации.
Наблюдение за производственной деятельностью.
Анализ статистики использования предыдущих версий системы.

6.

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

7.

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

8.

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

9.

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

10.

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

11.

Виды документации
Виды документации
Продуктная документация (product documentation, development documentation) используется
проектной командой во время разработки и поддержки продукта. Она включает:
План проекта (project management) и в том числе тестовый план (test).
Требования к программному продукту (product requirements document) и функциональные
спецификации (functional specifications document, FSD; software requirements specification,
SRS).
Архитектуру и дизайн (architecture and design).
Тест-кейсы и наборы тест-кейсов (test cases, test suites).
Технические спецификации (technical specifications), такие как схемы баз данных, описания
алгоритмов, интерфейсов и т.д.

12.

Виды документации
Виды документации
Проектная документация (project documentation) включает в себя как продуктную
документацию, так и некоторые дополнительные виды документации и используется не только на
стадии разработки, но и на более ранних и поздних стадиях (например, на стадии внедрения и
эксплуатации).
Пользовательскую и сопроводительную документацию (user and accompanying
documentation), такую как встроенная помощь, руководство по установке и использованию,
лицензионные соглашения и т.д.
Маркетинговую документацию (market requirements document, MRD),которую
представители разработчика или заказчика используют как на начальных этапах (для
уточнения сути и концепции проекта), так и на финальных этапах развития проекта (для
продвижения продукта на рынке).

13.

Методы тестирования
White/Black/Grey Box-тестирование
Типы тестирования, которые отличаются знанием внутреннего устройства объекта
тестирования.
Black-box тестирование:
Тестирование методом «черного ящика», также известное как тестирование,
основанное на спецификации или тестирование поведения – техника тестирования, основанная на
работе исключительно с внешними интерфейсами тестируемой системы.
Black-box тестирование по ISTQB:
● тестирование, как функциональное, так и нефункциональное,
не предполагающее знания внутреннего устройства компонента или системы;
● тест-дизайн, основанный на технике черного ящика – процедура написания или выбора тесткейсов на основе анализа функциональной или нефункциональной спецификации
компонента или системы без знания ее внутреннего устройства.

14.

Методы тестирования
White-box тестирование:
Тестирование методом белого ящика (также прозрачного, открытого, стеклянного ящика или
же основанное на коде или структурное тестирование) – метод тестирования программного
обеспечения, который предполагает, что внутренняя структура/устройство/реализация системы
известны тестировщику.
White-box тестирование по ISTQB:
● тестирование, основанное на анализе внутренней
структуры компонента или системы;
● тест-дизайн, основанный на технике белого ящика – процедура написания или выбора тесткейсов на основе анализа внутреннего устройства системы или компонента.

15.

Методы тестирования
Grey-box тестирование:
Тестирование методом серого ящика – метод тестирования программного обеспечения,
который предполагает комбинацию White Box и Black Box подходов. То есть внутреннее устройство
программы нам известно лишь частично
Предполагается, например, доступ ко
внутренней структуре и алгоритмам
работы ПО для написания максимально
эффективных тест-кейсов, но само
тестирование проводится с помощью
техники черного ящика, то есть с
позиции пользователя.

16.

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

17.

Типы тестирования
Ручное и автоматизированное тестирование
Выделяют три типа тестирования:
Ручное тестирование (manual) — выполнение кейсов выполняется вручную.
Полуавтоматизированное тестирование (half-automated)- ручное тестирование сочетается с
автоматическим.
Автоматизированное (automated) — предполагает использование специального
программного обеспечения (помимо тестируемого) для контроля выполнения тестов и
сравнения ожидаемого фактического результата работы программы. Существует несколько
видов автоматизированного тестирования:
— автоматизация тестирования кода (code-driven testing);
— автоматизация тестирования графического пользовательского интерфейса (graphical
user interface testing);
— автоматизация тестирования API (Application Programming Interface).

18.

Уровни
тестирования
Уровни
тестирования
Уровни тестирования
Тестирование на разных уровнях производится на протяжении всего жизненного цикла
разработки и сопровождения программного обеспечения. Уровень тестирования определяет то,
над чем производятся тесты: над отдельным модулем, группой модулей или системой, в целом.
Проведение тестирования на всех уровнях системы — это залог успешной реализации и сдачи
проекта.
Классификация по ISTQB:
— Unit testing
— Integration testing
— System testing
— Acceptance testing

19.

Уровни тестирования
Unit or Component testing
Модульное или компонентное тестирование проверяет функциональность и ищет дефекты в
частях приложения, которые доступны и могут быть протестированы по-отдельности (модули
программ, объекты, классы, функции и т.д.).
Обычно компонентное (модульное) тестирование проводится вызывая код, который
необходимо проверить и при поддержке сред разработки, таких как фреймворки (frameworks каркасы) для модульного тестирования или инструменты для отладки.
Все найденные дефекты, как правило исправляются в коде без формального их описания в
системе менеджмента багов (Bug Tracking System).
Разница между компонентным и модульным тестированием — в компонентном тестировании,
в качестве параметров функций, используют реальные объекты и драйверы, а в модульном
тестировании — конкретные значения.

20.

Уровни тестирования
Integration testing
Интеграционное тестирование предназначено для проверки связи между компонентами, а
также взаимодействия с различными частями системы (операционной системой, оборудованием
либо связи между различными системами).
Уровни интеграционного тестирования:
Компонентный интеграционный уровень (Component integration level) — проверяется
взаимодействие между компонентами системы после проведения компонентного
тестирования;
Системный интеграционный уровень (System integration level) — проверяется взаимодействие
между разными системами после проведения системного тестирования.

21.

Уровни тестирования
Integration testing
Подходы к интеграционному тестированию:
Снизу вверх (Bottom Up integration) — Все низкоуровневые модули собираются воедино и
затем тестируются. После чего собирается следующий уровень модулей.
Сверху вниз (Top Down integration) — Сначала тестируются все высокоуровневые модули,
затем постепенно добавляются низкоуровневые.
Большой взрыв (“Big Bang integration) — Все разработанные модули собираются вместе в виде
законченной системы, а затем проводится интеграционное тестирование.

22.

Уровни тестирования
System testing
Основной задачей системного тестирования является проверка как функциональных, так и не
функциональных требований , наличие дефектов в системе в целом.
Можно выделить два подхода к системному тестированию:
На базе требований (requirements based) — для каждого требования пишутся тестовые случаи
(test cases), проверяющие выполнение данного требования.
На базе случаев использования (use case based) — на основе представления о способах
использования продукта создаются случаи использования системы (Use Cases). По
конкретному случаю использования можно определить один или более сценариев. На
проверку каждого сценария пишутся тест-кейсы (test cases), которые должны быть
протестированы.

23.

Уровни тестирования
Acceptance testing
Приемочное тестирование это формальный процесс тестирования, который проверяет
соответствие системы требованиям и проводится с целью:
— определения удовлетворения системой приемочным критериям;
— вынесения решения заказчиком или другим уполномоченным лицом принятия
приложения.
Виды приемочного тестирования:
— Пользовательское приемочное тестирование (User acceptance testing);
— Альфа тестирование (Alpha testing) — проводится разработчиками или командой
тестировщиков на на поздней стадии разработки с имитацией реального использования продукта;
— Бета тестирование (Beta testing) — проводится небольшой группой авторизированных
пользователей, с целью собрать первые фидбеки.

24.

Виды тестирования
Виды тестирования
Функциональные:
— Функциональные тесты
— Тестирование безопасности
— Тестирование взаимодействия
Нефункциональные:
— Тестирование производительности
— Тестирование установки
— Тестирование удобства пользования
— Тестирование на отказ и восстановление
— Конфигурационное тестирование
Связанные с изменениями:
— Дымовое тестирование
— Регрессионное тестирование
— Тестирование сборки
— Санитарное тестирование или проверка согласованности/исправности

25.

Функциональные виды
Функциональные виды тестирования
По ISTQB: Тестирование, основанное на анализе спецификации функциональности
компонента или системы.
Функциональность — Способность программного продукта обеспечивать функции, которые
соответствуют установленным и предполагаемым потребностям, при использовании ПО в
определенных условиях.
Преимущества функционального тестирования:
— имитирует фактическое использование системы.
Недостатки функционального тестирования:
— возможность упущения логических ошибок в программном обеспечении;
— вероятность избыточного тестирования.
Достаточно распространенной является автоматизация функционального тестирования.

26.

Функциональные виды
Функциональные тесты
Основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях
тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти
функции описываются в требованиях, функциональных спецификациях или в виде случаев
использования системы (use cases).
Может проводиться в двух аспектах:
— Требования.
— Бизнес-процессы.
Тестирование в аспекте «требования» использует спецификацию функциональных
требований к системе, как основу для дизайна тестовых случаев (Test Cases). Это позволит
сфокусироваться и не упустить при тестировании наиболее важный функционал.
Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов,
которые описывают сценарии ежедневного использования системы. В этом аспекте тестовые
сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

27.

Функциональные виды
Тестирование безопасности
Стратегия тестирования, используемая для проверки безопасности системы, а также для
анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак
хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Общая стратегия безопасности основывается на трех основных принципах:
Конфиденциальность.
Целостность.
Доступность.

28.

Функциональные виды
Тестирование взаимодействия
Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование,
проверяющее способность приложения взаимодействовать с одним и более компонентами или
системами и включающее в себя тестирование совместимости (compatibility testing) и
интеграционное тестирование (integration testing).
Программное обеспечение с хорошими характеристиками взаимодействия может быть легко
интегрировано с другими системами, не требуя каких-либо серьезных модификаций. В этом
случае, количество изменений и время, требуемое на их выполнение, могут быть использованы
для измерения возможности взаимодействия.

29.

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

30.

Нефункциональные виды
Тестирование производительности
Задачей тестирования производительности ( Performance testing ) является определение
масштабируемости приложения под нагрузкой.
Виды:
Стрессовое тестирование (Stress testing).
Объемное тестирование (Volume testing).
Тестирование стабильности или надежности(Stability / Reliability Testing).
Нагрузочное тестирование (Load).

31.

Нефункциональные виды
Тестирование установки
Тестирование установки (Installation testing) направлено на действия, которые нужно
совершить пользователю для установки и настройки ПО.
Может включать в себя:
полную или частичную установку;
модификацию установки/удаления.

32.

Нефункциональные виды
Тестирование удобства использования
Тестирование удобства пользования (Usability Testing) — это метод тестирования,
направленный на установление степени удобства использования, обучаемости, понятности и
привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
Тестирование удобства пользования дает оценку уровня удобства использования
приложения по следующим пунктам:
Производительность, эффективность (efficiency).
Правильность (accuracy).
Активизация в памяти (recall).
Эмоциональная реакция (emotional response).

33.

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

34.

Нефункциональные виды
Конфигурационное тестирование
Конфигурационное тестирование(Configuration Testing) — специальный вид тестирования,
направленный на проверку работы программного обеспечения при различных конфигурациях
системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях
компьютеров и т.д.)
В зависимости от типа проекта конфигурационное тестирование может иметь разные цели:
Проект по профилированию работы системы.
Проект по миграции системы с одной платформы на другую.
Примечание: В ISTQB Syllabus вообще не говорится о таком виде тестирования, как
конфигурационное. Согласно глоссарию, данный вид тестирования рассматривается там как
тестирование портируемости(portability testing: The process of testing to determine the portability of
a software product.).

35.

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

36.

Виды связанные с изменениями
Дымовое тестирование
Smoke testing это выборка из общего числа запланированных тестовых сценариев,
покрывающая основную функциональность компонента или системы. Проводится с целью
удостовериться, что базовые функции программы в целом работают корректно, без углубления в
детали.
Аналогами дымового тестирования являются Build Verification Testing и Acceptance Testing,
выполняемые на функциональном уровне командой тестирования, по результатам которых
делается вывод о том, принимается или нет установленная версия программного обеспечения в
тестирование, эксплуатацию или на поставку заказчику.
Для облегчения работы, экономии времени и людских ресурсов рекомендуется внедрить
автоматизацию тестовых сценариев для дымового тестирования.

37.

Виды связанные с изменениями
Санитарное тестирование или проверка согласованности/исправности
Санитарное тестирование (Sanity Testing) — это узконаправленное тестирование,
достаточное для доказательства того, что конкретная функция работает согласно заявленным
в спецификации требованиям.
Является подмножеством регрессионного тестирования. Используется для определения
работоспособности определенной части приложения после изменений произведенных
в ней или окружающей среде. Обычно выполняется вручную.
Различие между дымовым и санитарным тестированием
Эти виды тестирования имеют «Вектора движения», направления в разные стороны.
Санитарное тестирование (Sanity testing) направлено вглубь проверяемой функции, в то время как
дымовое (Smoke testing) направлено вширь, для покрытия тестами как можно большего
функционала в кратчайшие сроки.

38.

Виды связанные с изменениями
Регрессионное тестирование
Регрессионное тестирование (Regression Testing) — это вид тестирования, направленный на
проверку изменений, сделанных в приложении или окружающей среде (починка дефекта, слияние
кода, миграция на другую операционную систему, базу данных, веб-сервер или сервер
приложения), для подтверждения того факта, что существующая ранее функциональность работает
как и прежде. Регрессионными могут быть как функциональные, так и нефункциональные тесты.
Сам по себе термин «регрессионное тестирование», в зависимости от контекста
использования, может иметь разный смысл. Сэм Канер, к примеру, описал 3 основных типа
регрессионного тестирования:
Регрессия багов (Bug regression).
Регрессия старых багов (Old bugs regression).
Регрессия побочного эффекта (Side effect regression).

39.

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

40.

Спасибо за внимание!
www.andersenlab.com

41.

Список литературы
—
https://qaevolution.ru/yuzabiliti-testirovanie/kratkij-konspekt-poleznyx-znanij-po-testirovaniyu-dokumentacii/
https://habr.com/post/346290/
https://www.altexsoft.com/blog/business/software-documentation-types-and-best-practices/
https://www.guru99.com/types-of-software-testing.html

Источник

Шаг 7. Тестирование

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

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

(Воспроизводится с разрешения Центрального секретариата МОС с веб-сайта Международной организации стандартизации www.iso.org.)

Более подходящее определение тестирования программного обеспечения:

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

{57}

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

Требуют учета следующие весьма серьезные аспекты:

• важно помнить, что на подготовку и планирование нужно отвести более половины всего времени тестирования, а остальную часть – на фактическое проведение тестов;

• почти невозможно и весьма нежелательно выполнять 100-процентное тестирование, поскольку затраты и сроки будут нереальны. Лучше практиковать структурированный подход, добиваясь максимума эффективности при минимуме усилий. Руководитель тестирования должен всегда определять глубину тестирования, количество ошибок и «объем тестов».

Можно выделить следующие типы тестирования {57}:

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

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

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

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

• тест приемки пользователями (UAT) выполняется пользователями системы. В «теневых» эксплуатационных условиях автоматизированное решение BPM будет испытано на предмет соответствия требованиям бизнеса. Это включено в этап реализации;

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

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

1. Определите показатели теста. Тестирование всегда предполагает баланс между выгодами от тестирования и связанными с ним затратами. 100-процентное тестирование – практически нереальное и чрезвычайно дорогостоящее мероприятие. TMap® – прагматичный подход, описанный в {57}.

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

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

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

5. Выполните тестирование. Завершите конфигурации и программы тестов.

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

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

Данный текст является ознакомительным фрагментом.