Перейти к содержимому

Фотография

Разновидности тестирования.


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 71

#1 Victorea

Victorea

    Активный участник

  • Members
  • PipPip
  • 89 сообщений
  • ФИО:Klimova Victorea
  • Город:Ukraine, Kiev

Отправлено 28 января 2005 - 12:36

Предлагаю дополнить существующие разновидности тестирования:
функциональное
стресс-тестирование
нагрузочное
интеграционное

Какие вы знаете еще виды?
  • 0

#2 Worm

Worm

    Новый участник

  • Members
  • Pip
  • 33 сообщений

Отправлено 28 января 2005 - 14:35

Unit testing
Integration testing
Smoke testing - (Assures that there is no severe problem that prevents further testing. Smoke tests (or Sanity Tests) are used to verify that the software build is ready for System Test (or more extensive testing).)
Function Testing
User Interface Testing
Performance Profiling
Configuration Testing
Installation Testing
Regression testing
Bug fixes testing
Data and Database Integrity Testing
Load Testing
Stress Testing
Volume Testing
Security and Access Control Testing
Failover and Recovery Testing
Conversion testing
Job stream testing
Interface testing
Acceptance testing
Beta testing
User documentation verification

о как ;)
  • 0

#3 Victorea

Victorea

    Активный участник

  • Members
  • PipPip
  • 89 сообщений
  • ФИО:Klimova Victorea
  • Город:Ukraine, Kiev

Отправлено 28 января 2005 - 14:39

Smoke testing

:) - это что за тестирование?
Очень много, Worm! Класс!
Кто знает, какие виды тестирования еще не упомянуты?
  • 0

#4 Worm

Worm

    Новый участник

  • Members
  • Pip
  • 33 сообщений

Отправлено 28 января 2005 - 15:03

ну о нем вообщето много написано по форуму - мое описание выше
  • 0

#5 Victorea

Victorea

    Активный участник

  • Members
  • PipPip
  • 89 сообщений
  • ФИО:Klimova Victorea
  • Город:Ukraine, Kiev

Отправлено 28 января 2005 - 15:44

Нашла определение...

тесты на то, что система хоть как-то работает, что самая-самая ключевая функциональность реализована


Ну что, никто не знает больше Wormа? :P
  • 0

#6 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 28 января 2005 - 16:21

Достаточно?

------------------------------------------------
4.2 Типы тестов
4.2.1 Объект тестирования
Unit (Элемент) – наименьший компонент, который можно скомпилировать.
Unit testing (поэлементное тестирование) – заключается в изолированной проверке каждого отдельного элемента путем запуска тестов в искусственной среде. Для этого необходимо использовать драйверы и заглушки. Поэлементное тестировани – первейшая возможность реализовать исходный код. Оценивая каждый элемент изолированно и подтверждая корректность его работы, точно установить проблему значительно проще, чем если бы элемент был частью системы.
Драйверы – модули тестов, которые запускают тестируемый элемент.
Заглушки - заменяют недостающие компоненты, которые вызываются элементом и выполняют следующие действия:
• возвращаются к элементу, не выполняя никаких других действий;
• отображают трассировочное сообщение и иногда предлагают тестеру продолжить тестирование;
• возвращают постоянное значение или предлагают тестеру самому ввести возвращаемое значение;
• осуществляют упрощенную реализацию недостающей компоненты;
• Имитируют исключительные или аварийные условия.
Тестирование сборки. Проверяется корректность функционирования скомбинированных вместе элементов. Существует четыре стратегии сборки:
• Снизу вверх. Сначала следует выполнить поэлементное тестирование для компонентов, находящихся на более низком уровне, а затем перейти к высокоуровневым компонентам. Для этого метода используются драйверы.
• Сверху вниз. Высокоуровневые подпрограммы становятся драйверами для остальных элементов. В этом методе используются заглушки, имитирующие поведение низкоуровневых элементов.
• Сэндвич. Здесь комбинируются методы сверху вниз и снизу вверх.
• Большой взрыв. Объединяются все элементы. Объединяются все элементы.
System testing (тестирование системы)- Проверяется продукт в целом. После того как все програмные и аппаратные компоненты собраны, подтверждается соответствие продукта исходным требованиям проекта. При наличии полностью скомпонованной системы тестер может оценить многие атрибуты, которые нельзя оценить на более низких уровнях тестирования. Результатом даного тестирования является решение о готовности системы к выпуску. Среда тестирования должна быть как можно ближе к среде развертывания.
Integration testing – в ходе этого тестирования проверяется взаимодействие тестируемого приложения с другими приложениями.


4.2.2 По целям
Инсталляционное тестирование – основная цель, убедиться, что программное обеспечение может быть установлено при различных условиях.
• новая инсталляция,
• усовершенствование системы (upgrade),
• полная или выборочная инсталляция – при нормальных и ненормальных условиях. Недостаточное количество дискового пространства, недостаток привилегий (например, на создание директорий) и т.д.
Данные и целостность базы данных. Проверяется конистентность данных. Включает в себя проверку:
• ссылочной целостности (основной источник проблем)
• ограничений на значения параметров
• ограничений на неинициализацию значений
• ограничений на уникальность значений
Функциональное тестирование - основной тест. Проверка правильности работы. Каждая функция должна отвечать требованиям.
Тестирование бизнес-цикла - должно имитировать действия, выполняемые пользователем и охватывать все типичные операции пользователя. Как правило, тесты объединяются в единый тест сьют.
Тестирование графического интерфейса пользователя.
Тестирование производительности - скорость работы системы при идеальных условиях и максимальная нагрузка
Нагрузочное тестирование – это те же тесты производительности, при которых система подвергается различным нагрузкам; при этом цель этого тестирования – оценить способность системы правильно функционировать при некотором превышении планируемых нагрузок при реальной эксплуатации (система имеет некоторый «запас прочности»).
Объемное тестирование - приложение нагружается большим количеством данных, чтобы определить, когда достигаются условия, при которых система перестает работать.
Стресс тестирование - поведение системы при недостатке ресурсов (дискового пространства, обрывов сети, …)
Конфигурационное тестирование - тестирование работы на различных платформах. Различные варианты аппаратной конфигурации, версии операционной системы и окружения (MDAC, .Net, браузеры, …).
Тестирование безопасности и прав доступа - сосредоточено на двух ключевых областях безопасности:
• Безопасность уровня приложения, в том числе доступ к данным или бизнес-функциям.
• Безопасность уровня системы, включая вход в систему или удаленный доступ к системе.


4.2.3 Способ работы с кодом
White-box test. Тестирование методом «Белого ящика». Для конструирования тестов используются внутренняя структура кода и управляющая логика. При этом существует вероятность,что код будет проверяться так, как он был написан, а это не гарантирует корректность логики.
Black-box test. Тестирование методом «Черного ящика». Для конструирования тестов используются требования и спецификации ПО. Недостатки:
• таким способом невозможно найти взаимоуничтожающихся ошибок,
• некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и потому их трудно найти и воспроизвести и т.д.

4.2.4 Стадии тестирования
Исследовательское тестирование – Прогон приложения с целью выяснения функций приложения и их реализации для подготовки тевстовых сценариев. первый этап в принятии решения что и ка будет тестироваться. Применяется при недостаточном документировании процесса разработки (отсутствие или неполнота спецификаций, прототипов интерфейса, …)
Smoke test (проверка на дым) - Оставшийся с доисторических времен способ проверки электронного оборудования в процессе переконфигурации или ремонта, который сводится к элементарной подаче напряжения на данный модуль и визуальной проверке, нет ли искрения, дыма или других явных признаков неработоспособности.
В более общем смысле первый прогон программы (после написания или после внесения существенных изменений). Как правило используется для определения готова ли программа для передачи в тестирование и продолжается 4-8 часов.
Регрисионное тестирование – Повторное использование поднабора тестов в новой версии приложения, чтобы убедиться, что функции, которые работали в предыдущей версии системы, по прежнему работают так, как ожидалось.
Приемочное тестирование – быстрая проверка работоспособности очередного релиза. Является подмножеством функциональных тестов и состоит из типичных пользовательских сценариев, сосредоточенных на основных требованиях к функциональным возможностям. Как правило, это тестирование автоматизируют.


4.2.5 Метод выполнения.
Ручное тестирование – ввод исходных данных и проверка корректности результата производится непосредственно человеком. Слабо применимо для:
• нагрузочного тестирования
• тестирования производительности
Автоматическое тестирование - ввод исходных данных и проверка корректности результата производится специализированным ПО.
  • 3

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#7 Victorea

Victorea

    Активный участник

  • Members
  • PipPip
  • 89 сообщений
  • ФИО:Klimova Victorea
  • Город:Ukraine, Kiev

Отправлено 28 января 2005 - 16:26

Это похоже на кусок теоретической части, вырванной из тестеровской литературы... ;)
Но появилось разбивка по разделам типов тестов. Это интересно
  • 0

#8 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 31 января 2005 - 07:34

Мне не понравились существующие классификации. Пришлось составить свою. Так что пока это не теория, пока это просто "заметки на полях".
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#9 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 31 января 2005 - 07:41

Народ, доведите до ума эту тему, можно будет как статью/заметку опубликовать.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#10 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 31 января 2005 - 13:42

Я попробую. Но там до "ума" еще очень прилично работы. Только по объему минимум в два раза увеличивать, а потом еще вылизывать.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#11 Worm

Worm

    Новый участник

  • Members
  • Pip
  • 33 сообщений

Отправлено 16 февраля 2005 - 15:59

Я вот тут немного поигрался со своей информацией и тем, что опубликовано в этой теме (спасибо SALar) и выложил свою версию/видение о видах тестирования. Если есть замечания дополнения - жду с нетерпением. "Язвительные" высказывания оставляйте при себе. B)
Практическое применение вижу в качестве списка в тест плане в расширенном виде в разрезе выполняемого проекта
так как эксель формат не поддерживается в форуме то таблицу приобразовал в блоки следующего вида:
1.Вид тестирования
2.Определение
3.Цель

1.Поэлементное тестирование (Юнит тестирование), (Unit testing)
2.Юнит тестирование связано с проверкой реализации дизайна одного программного элемента (модуля, единицы и т.д.) или группы элементов, разработанные, обычно, одним программистом. заключается в изолированной проверке каждого отдельного элемента путем запуска тестов в искусственной среде.
3.Является первейшей возможностью протестировать исходный код. Оценивая каждый элемент изолированно и подтверждая корректность его работы, точно установить проблему значительно проще, чем, если бы элемент был частью системы.

1.Интеграционное тестирование (Integration testing)
2.Проверка скомбинированных компонентов прикладной программы с целью определения корректности их совместного функционирования. Компоненты могут представлять собой модели кода, отдельные прикладные программы, клиентские и серверные приложения.
3.Выявление потенциальных проблем в совместном функционировании компонент.

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

1.Дымное тестирование (проверка на дым), (Smoke testing)
2.Первый прогон программы (после написания или после внесения существенных изменений). Как правило используется для определения готова ли программа для проведения более обширного тестирования и продолжается 4-8 часов.
3.Выявление проблем «лежащих на поверхности» - тестируется чаще всего основная бизнес логика программы.

1.Функциональное тестирование (Functional testing)
2.Проверка соответствия продукта функциональным требованиям и спецификациям.
3.Проверка соответствия продукта функциональным требованиям и спецификациям.

1.Тестирование графического интерфейса пользователя (User Interface testing)
2.Тестирование интерфейса - экранов, кнопок и т.д. Большая часть функциональности ПО реализуется, как правило, через пользовательский интерфейс.
3.Обнаружение ошибок в интерфейсе и поиск ошибок в функциональности посредством интерфейса.

1.Тестирование производительности (Performance testing)
2.Проверка скорости работы системы (время отклика, частота транзакций и другие зависящие от времени величины) в имитационной и реальной средах.
3.Установить реальную производительность программного продукта при созданных условиях.

1.Конфигурационное тестирование (Configuration testing)
2.Конфигурационное тестирование - тестирование работы на различных платформах. Различные варианты аппаратной конфигурации, версии операционной системы и окружения (MDAC, .Net, браузеры, …).
3.Проверить работоспособность системы при различных конфигурациях.

1.Инсталляционное тестирование (Installation testing)
2.Данное тестирование преследует две цели. Первая состоит в том, чтобы убедиться, что продукт может быть установлен при различных условиях – таких как: новая инсталляция, усовершенствование системы (upgrade), установка по умолчанию, полная установка, установка по выбору – при нормальных и ненормальных условиях. Ненормальные условия включают в себя недостаточное количество дискового пространства, недостаток привилегий (например, на создание директорий) и т.д. Вторая цель состоит в том, чтобы убедиться, что после инсталляции программа работает корректно.
3.Убедиться в том, что программное обеспечение может быть установлено при различных условиях.

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

1.Тестирование корректности исправления ошибок (Bug fixes testing)
2.Предназначено для отслеживания корректности исправления найденных ранее ошибок
3.Тестируем ради проверки исправления старых ошибок

1.Тестирование данных и целостности базы данных (Data and Database Integrity testing)
2.Проверяется согласованность данных. Включает в себя проверку: Тестируются данные и базы данных независимо от пользовательского интерфейса – ввод данных и работа с ними непосредственно в базе данных
• ссылочной целостности (основной источник проблем)
• ограничений на значения параметров
• ограничений на не инициализацию значений
• ограничений на уникальность значений
3.Тестируются данные и базы данных независимо от пользовательского интерфейса – ввод данных и работа с ними непосредственно в базе данных

1.Нагрузочное тестирование (Load testing)
2.Это те же тесты производительности, при которых система подвергается различным нагрузкам; при этом цель этого тестирования – оценить способность системы правильно функционировать при некотором превышении планируемых нагрузок при реальной эксплуатации (система имеет некоторый «запас прочности»).
3.Убедиться в том, что система работает соответственно ожидаемым рабочим нагрузочным параметрам (какой предел работоспособности)

1.Стресс тестирование (Stress testing)
2.Является одним из разновидностей тестирования на производительность. Проверяется поведение системы при недостатке ресурсов (дискового пространства, обрывов сети и т.д.).
3.Проверка того, что система адекватно реагирует на те или иные стрессовые ситуации

1.Объемное тестирование (Volume testing)
2.Относится к тестированию производительности. Приложение нагружается большим количеством данных, чтобы определить, когда достигаются условия, при которых система перестает работать.
3.Цель данного тестирования заключается в определении максимального объема данных при работе системы

1.Тестирование безопасности и прав доступа (Security and Access Control testing)
2.Тестирование безопасности и прав доступа - сосредоточено на двух ключевых областях безопасности: Убедиться, что только пользователь с определенными правами имеет возможность войти в систему и выполнять строго выделенные под его роль функции.
• Безопасность уровня приложения, в том числе доступ к данным или бизнес-функциям.
• Безопасность уровня системы, включая вход в систему или удаленный доступ к системе.
3.Убедиться, что только пользователь с определенными правами имеет возможность войти в систему и выполнять строго выделенные под его роль функции.

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

1.Приемочное тестирование (Acceptance testing)
2.Завершающее тестирование, основанное на технических требованиях конечных пользователей/заказчиков, либо основанное на применении продукта конечными пользователями/заказчиками на протяжении некоторого ограниченного периода времени. Как правило, это тестирование автоматизируют.
3.Определение соответствует ли ПО требованиям конечного пользователя или заказчика.

1.Бета тестирование (Beta testing)
2.Тестирование, которое выполняется на стороне заказчика (потенциальных заказчиков), с целью выявления недостатков и возможного усовершенствования системы
3.Целью является выявление ошибок и сбор мнений от потенциального заказчика

1.Анализ документации (User documentation verification)
2.Анализ спецификаций на полноту и правильность, проверка документации продукта, пользовательских инструкций и пр.
3.Проверка соответствия программы с документацией
  • 0

#12 wmi

wmi

    Новый участник

  • Members
  • Pip
  • 21 сообщений

Отправлено 18 февраля 2005 - 10:54

Еще можно написать сертификационное тестирование. Например на соответствие Windows Logo
  • 0

#13 Антонида

Антонида

    Новый участник

  • Members
  • Pip
  • 11 сообщений
  • Город:Минск

Отправлено 11 марта 2005 - 22:28

А что насчет

Failover and Recovery Testing ?

" Failover and Recovery Testing ensures that the target-of-test can successfully failover and recover from a variety of hardware, software or network malfunctions with undue loss of data or data integrity.
Failover testing ensures that, for those systems that must be kept running, when a failover condition occurs, the alternate or backup systems properly “take over” for the failed system without loss of data or transactions.
Recovery testing is an antagonistic test process in which the application or system is exposed to extreme conditions, or simulated conditions, to cause a failure, such as device Input/Output (I/O) failures or invalid database pointers and keys. Recovery processes are invoked and the application or system is monitored and inspected to verify proper application, or system, and data recovery has been achieve "

И ещё

Business Cycle Testing

"Business Cycle Testing should emulate the activities performed on the Project over time. A period should be identified, such as one year, and transactions and activities that would occur during a year’s period should be executed. This includes all daily, weekly, and monthly cycles and, events that are date-sensitive, such as ticklers."


Как вообще на практике эти тесты применяются? Кто-нибудь проводил их?
  • 0
Edited and Deleted by myself

#14 Jackie

Jackie

    Постоянный участник

  • Members
  • PipPipPip
  • 206 сообщений
  • Город:Москва

Отправлено 23 марта 2005 - 10:12

Можно еще добавить usability тестирование - тестирование на эргономичность, на "удобство использования" приложения.
  • 0

#15 Ruden

Ruden

    Новый участник

  • Members
  • Pip
  • 1 сообщений

Отправлено 06 мая 2008 - 13:33

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

#16 Drag

Drag

    Активный участник

  • Members
  • PipPip
  • 123 сообщений


Отправлено 01 марта 2011 - 06:56

Общими усилиями поднимем тему до текущей актуальности? :)
  • 0

#17 Clubberry

Clubberry

    Новый участник

  • Members
  • Pip
  • 54 сообщений
  • ФИО:Артём
  • Город:Днепропетровск

Отправлено 01 марта 2011 - 08:10

Общими усилиями поднимем тему до текущей актуальности? :)

Похоже, что тему нужно просто прикрепить, именно так она и станет актуальной и будет просто пополняться. :)
  • 0

#18 vergulenko

vergulenko

    Новый участник

  • Members
  • Pip
  • 1 сообщений

Отправлено 21 сентября 2011 - 21:26

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

GREY BOX TESTING - сочетание чёрного и белого ящика. Если при чёрном ящике мы имеем доступ только к интерфейсу приложения, видим только то, как приложение выглядит внешне, а при белом ящике - мы имеем дело с кодом, и видим приложение только "внутри", то при сером ящике - мы имеем доступ и к интерфейсу и к коду, что даёт нам некоторые преимущества для проведения более качественного тестирования.

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

LOCALIZATION (L10N) - локализация - перевод и адаптация элементов интерфейса, вспомогательных файлов и документации.

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

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


В некоторых источниках указываются такие составные части регрессионного тестирования: NEW BUG-FIX - проверка исправления найденного ранее бага;
OLD BUG-FIX - проверка того, что исправленный ранее и верифицированный дефект не воспроизводится в системе снова;
SIDE-EFFECT - проверка того, что не нарушилась работоспособность работающей ранее функциональности, если её код мог быть затронут при исправлении некоторых дефектов в другой функциональности.

RISK AREA TESTING - проверка самых рискованных областей продукта, непосредственно перед прожигом (схоже с acceptance testing).

CD CHECK - тестирование работы уже прожжённого диска.

Также можно выделить BUG HUNT - как отдельный тип тестирования - здесь некая группа тестировщиков просто охотится на дефекты всеми доступными способами в течение некоторого времени. Целенаправленно ищет всевозможные дефекты в приложении.
  • 0

#19 Фрося

Фрося

    Специалист

  • Members
  • PipPipPipPipPip
  • 514 сообщений
  • ФИО:Радилова Елена Игоревна

Отправлено 22 сентября 2011 - 05:00

Замечательно!
А может имеет смысл добавлять ссылки -- где встретились термины? В каких книгах, статьях.
  • 0
Почему-то по пятницам особо остро хочется быть блондинкой....

#20 Future

Future

    Опытный участник

  • Members
  • PipPipPipPip
  • 261 сообщений
  • Город:Москва

Отправлено 23 сентября 2011 - 05:34

Вспомнился один ролик КВНовский



Как раз про тестирование и их виды ))))
  • 1


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных