Тестовый метод

Содержание
  1. Вторая часть курса по тестированию
  2. Основная причина ошибок в ПО
  3. Виды тестирования
  4. Про ящики
  5. Масштаб тестирования
  6. Тестирование на ожидание
  7. Деление по инструментам:
  8. Разработка тестов
  9. Теоретические основы тестирования
  10. Жизненный цикл продукта и тестирование
  11. Категории тестирования
  12. Подкатегории тестирования
  13. Unit-тестирование
  14. Функциональное тестирование
  15. Тестирование БД
  16. Методы оценки – Тестирование
  17. Процент метода развития усилий
  18. Оценка проектов тестирования
  19. Методы оценки тестирования
  20. Методика оценки тестирования программного обеспечения PERT
  21. Метод точки использования
  22. Структура разбивки работ
  23. Широкополосная техника Delphi
  24. Анализ функциональных точек / точек тестирования
  25. Процентное распределение
  26. Методика оценки тестирования на основе опыта
  27. Методы тестирования программного обеспечения
  28. Тестирование Black-Box
  29. Тестирование белого ящика
  30. Тестирование серых ящиков
  31. Сравнение методов тестирования
  32. Техники тест-дизайна и их предназначение
  33. Типы тестирования 
  34. Этапы тестирования
  35. Техники тест-дизайна на примерах
  36. Эквивалентное разбиение
  37. Граничные значения
  38. Таблица принятия решений
  39. Попарное тестирование
  40. Причина и следствие
  41. Предугадывание ошибок
  42. Итоги

Вторая часть курса по тестированию

Тестовый метод

•Проверка собственных навыков и качество на соответствие ожиданиям заказчиков;

•Выявление недостающих пятен в компетенциях и их заполнение;

•Повышение уверенности в себе как в тестировщике программного обеспечения;

•Тренировка на внимательность и способность замечать ошибки, как явные так и потенциальные;

•Ознакомление с лайфхаками тестирования и подводными камнями работы тестировшика в крупных проектах.

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

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

Одна из техник контроля качества, включающая в себя:

– активности по планированию работ (TestManagement),

– проектированию тестов (TestDesign),

– выполнению тестирования (TestExecution)

– анализу полученных результатов (TestAnalysis).

Основная причина ошибок в ПО

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

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

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

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

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

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

Видов тестирования много, классификаций тестирования еще больше.

А неоднозначность формализации позволяет нам определить, что:

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

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

• Критерии определения вида теста сами по себе неоднозначны.

Про ящики

Тестирование чёрного ящика или поведенческое тестирование.

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

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

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

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

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

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

Следующее деление:

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

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

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

Следующие виды тестирования:

• Тестирование новой функциональности

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

Масштаб тестирования

• Интеграционное тестирование – тестируется вся система целиком.

• Интеграционное тестирование – тестирование интеграции с другими системами.

• Модульное тестирование – тестируются отдельно различные модули.

• Тестирование компонентов – здесь тестируются компоненты, кнопки, менюшки и другое.

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

• Позитивное тестирование. Тестирование Золотого пути.

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

• Негативное тестирование. (Fuzz-тестирование).

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

• Исследовательское тестирование.

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

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

Деление по инструментам:

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

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

•Тестирование с частичной автоматизацией

Разработка тестов

• На основе модели

• На основе требований

• По вариантам использования.

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

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

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

Ставим пальцы вверх, чтобы мне было интереснее делать данные посты.

Источник: https://zen.yandex.ru/media/id/5c783e8bc65f5c00c8de37fc/vtoraia-chast-kursa-po-testirovaniiu-5cb9e7ac71cb0700b0e11f07

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

Тестовый метод

Авторы: Дмитрий Карбасов; Константин Пасевич

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

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

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

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

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

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

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

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

Какие инструментальные средства будут (если будут) использоваться для поиска и для документирования найденных дефектов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подкатегории тестирования Описание вида тестирования Подвиды тестирования
Нагрузочное тестированиеПрименяется для тестирования всех без исключения функций приложения. В данном случае последовательность тестирования функций не имеет значения.
  • unit-тестирование (модульное тестирование);
  • функциональное тестирование;
  • тестирование интерфейса;
  • тестирование БД
Тестирование бизнес цикловПрименяется для тестирования функций приложения в последовательности их вызова пользователем. Например, имитация всех действия бухгалтера за 1 квартал.
  • unit-тестирование (модульное тестирование);
  • функциональное тестирование;
  • тестирование интерфейса;
  • тестирование БД.
Стрессовое тестированиеПрименяется для тестирования производительности приложения. Цель данного тестирования — определить рамки стабильной работы приложения. При данном тестирование производится вызов всех доступных функций.
  • unit-тестирование (модульное тестирование);
  • функциональное тестирование;
  • тестирование интерфейса;
  • тестирование БД.

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

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

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

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

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

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

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

Данный вид тестирования не может быть полностью автоматизирован. Следовательно, он подразделяется на:

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

Цель: протестировать ввод, обработку и вывод данных;

  • Ручное тестирование (в остальных случаях).

Цель: тестируется правильность выполнения пользовательских требований.

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

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

Тестирование БД

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

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

Источник: https://www.software-testing.ru/library/testing/general-testing/54-testing

Методы оценки – Тестирование

Тестовый метод

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

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

Если вы получили оценки в виде функциональных баллов (FP), то в соответствии с Caper Jones,

Количество тестовых случаев = (количество функциональных точек) × 1,2

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

Процент метода развития усилий

Требуемые усилия по тестированию прямо пропорциональны или в процентах от усилий по разработке. Усилия по разработке могут быть оценены с использованием строк кода (LOC) или функциональных точек (FP). Затем процент усилий для тестирования получается из базы данных организации. Полученный таким образом процент используется для получения оценки усилий для тестирования.

Оценка проектов тестирования

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

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

  • Командные навыки
  • Базовые знания
  • Сложность приложения
  • Исторические данные
  • Циклы ошибок для проекта
  • Наличие ресурсов
  • Вариации производительности
  • Системная среда и время простоя

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

Следующие методы оценки тестирования доказали свою точность и широко используются:

  • Методика оценки тестирования программного обеспечения PERT
  • Метод UCP
  • WBS
  • Широкополосная техника Delphi
  • Анализ функциональных точек / точек тестирования
  • Процентное распределение
  • Методика оценки тестирования на основе опыта

Методика оценки тестирования программного обеспечения PERT

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

Формула, используемая этой техникой, —

Оценка теста = (O + (4 × M) + E) / 6

Куда,

O = Оптимистическая оценка (наилучший сценарий, в котором ничего не происходит неправильно и все условия являются оптимальными)

M = наиболее вероятная оценка (наиболее вероятная продолжительность и могут быть некоторые проблемы, но большинство вещей пойдет правильно).

L = пессимистическая оценка (в худшем случае, когда все идет не так).

Стандартное отклонение для техники рассчитывается как —

Стандартное отклонение (SD) = (E — O) / 6

Метод точки использования

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

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

Шаг 1 — Посчитай нет. актеров. Актеры включают в себя положительные, отрицательные и исключительные.

Шаг 2 — Рассчитайте нескорректированный вес актера как

Нескорректированный вес актера = всего нет.актеров

Шаг 3 — Подсчитайте количество вариантов использования.

Шаг 4 — Рассчитайте нескорректированные веса вариантов использования как

Нескорректированные веса вариантов использования = общее числослучаев использования

Шаг 5 — Рассчитайте нескорректированные точки варианта использования как

Нескорректированные баллы варианта использования = (Нескорректированный вес актера + Нескорректированные веса прецедента)

Шаг 6 — Определить технический / экологический фактор (TEF). Если недоступно, примите это как 0.50.

Шаг 7 — Рассчитайте скорректированный вариант использования как

Скорректированная точка варианта использования = нескорректированные точки варианта использования × [0,65 + (0,01 × TEF]

Шаг 8 — Рассчитайте общее усилие как

Общее усилие = скорректированный вариант использования × 2

Структура разбивки работ

Шаг 1 — Создайте WBS, разбив тестовый проект на маленькие кусочки.

Шаг 2 — Разделите модули на подмодули.

Шаг 3 Разделите подмодули на функциональные возможности.

Шаг 4 — Разделите функциональности на подфункции.

Шаг 5 — Просмотрите все требования к тестированию, чтобы убедиться, что они добавлены в WBS.

Шаг 6 — Определите количество задач, которые ваша команда должна выполнить.

Шаг 7 — Оцените усилия для каждой задачи.

Шаг 8 — Оцените продолжительность каждого задания.

Широкополосная техника Delphi

В широкополосном методе Delphi WBS распределяется по команде, состоящей из 3-7 членов, для переоценки задач. Окончательная оценка является результатом обобщенных основанных на консенсусе команды.

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

Анализ функциональных точек / точек тестирования

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

При тестировании оценка основывается на документе спецификации требований или на ранее созданном прототипе приложения. Для расчета FP для проекта требуются некоторые основные компоненты. Они —

  • Функциональные точки нескорректированных данных — i) внутренние файлы, ii) внешние интерфейсы
  • Функциональные точки нескорректированной транзакции — i) пользовательские входы, ii) пользовательские выходы и iii) пользовательские запросы
  • Основная формула Каперса Джонса —Количество тестовых случаев = (количество функциональных точек) × 1,2
  • Всего фактических усилий (TAE) —(Количество тестовых случаев) × (Процент усилий по разработке / 100)

Функциональные точки нескорректированных данных — i) внутренние файлы, ii) внешние интерфейсы

Функциональные точки нескорректированной транзакции — i) пользовательские входы, ii) пользовательские выходы и iii) пользовательские запросы

Основная формула Каперса Джонса

Количество тестовых случаев = (количество функциональных точек) × 1,2

Всего фактических усилий (TAE)

(Количество тестовых случаев) × (Процент усилий по разработке / 100)

Процентное распределение

В этой технике всем этапам жизненного цикла разработки программного обеспечения (SDLC) присваивается усилие в%. Это может быть основано на прошлых данных из аналогичных проектов. Например —

фаза % усилий
Управление проектом 7%
Требования 9%
дизайн 16%
кодирование 26%
Тестирование (все этапы тестирования) 27%
Документация 9%
Установка и обучение 6%

Затем,% усилий для тестирования (все фазы тестирования) далее распределяется на все фазы тестирования —

Все этапы тестирования % усилий
Тестирование компонентов 16
Независимое тестирование 84
Всего100
Независимое тестирование % усилий
Интеграционное тестирование 24
Тестирование системы 52
Приемочное тестирование 24
Всего100
Тестирование системы % усилий
Функциональное тестирование системы 65
Нефункциональное тестирование системы 35
Всего100
Планирование тестирования и дизайн архитектуры 50%
Фаза обзора 50%

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

Эта методика основана на аналогиях и экспертах. Метод предполагает, что вы уже тестировали аналогичные приложения в предыдущих проектах и ​​собирали показатели из этих проектов.

Вы также собрали показатели из предыдущих тестов.

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

Источник: https://coderlessons.com/tutorials/akademicheskii/izuchite-metody-otsenki/metody-otsenki-testirovanie

Методы тестирования программного обеспечения

Тестовый метод

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

Тестирование Black-Box

Методика тестирования без каких-либо знаний о внутренней работе приложения называется «черным ящиком». Тестер не обращает внимания на архитектуру системы и не имеет доступа к исходному коду.

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

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

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

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

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

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

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

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

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

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

Освоение домена системы всегда дает тестеру преимущество над кем-то с ограниченными знаниями домена.

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

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

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

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

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

Тестирование Black-Box Тестирование серых коробок Тестирование белого ящика
Не нужно знать внутреннюю работу приложения.Тестер имеет ограниченное знание внутренней работы приложения.Тестер имеет полное представление о внутренней работе приложения.
Также известен как тестирование с закрытым ящиком, тестирование с использованием данных или функциональное тестирование.Также известен как прозрачное тестирование, поскольку тестер имеет ограниченное знание внутренних аспектов приложения.Также известен как прозрачное тестирование, структурное тестирование или тестирование на основе кода.
Выполняется конечными пользователями, а также тестировщиками и разработчиками.Выполняется конечными пользователями, а также тестировщиками и разработчиками.Обычно выполняются тестировщиками и разработчиками.
Тестирование основано на внешних ожиданиях. Внутреннее поведение приложения неизвестно.Тестирование выполняется на основе диаграмм базы данных высокого уровня и диаграмм потоков данных.Внутренние работы полностью известны, и тестер может соответствующим образом создавать тестовые данные.
Он является исчерпывающим и наименее трудоемким.Частично трудоемкий и исчерпывающий.Самый исчерпывающий и трудоемкий тип тестирования.
Не подходит для тестирования алгоритмов.Не подходит для тестирования алгоритмов.Подходит для тестирования алгоритмов.
Это можно сделать только методом проб и ошибок.Домены данных и внутренние границы могут быть проверены, если они известны.Домены данных и внутренние границы могут быть лучше проверены.

Источник: https://unetway.com/tutorial/testing-software-methods/

Техники тест-дизайна и их предназначение

Тестовый метод

При создании IT-продукта большую роль играет обеспечение качества – Quality Assurance (QA). Для того, чтобы устранить ошибки и «баги», QA-инженеры в числе прочих инструментов применяют техники тест-дизайна.

Тест-дизайн – это разработка, создание тестов. Каждый тест направлен на проверку конкретного предположения. Например: «Что будет, если пользователь по ошибке кликнет здесь не левой, а правой кнопкой мыши».

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

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

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

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

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

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

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

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

1. Подготовка. На этом этапе QA-инженер читает проектную документацию, выясняет требования к продукту, прорабатывает план, продумывает стратегию, расставляет задачи по приоритетности и анализирует возможные риски. 

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

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

3. Анализ результатов и составление отчетов.  

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

Техники тест-дизайна на примерах

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

Эквивалентное разбиение

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

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

У нас есть четыре возрастных группы: младше 15 лет, от 15 до 25 лет, старше 25 и младше 60 лет и люди старше 60. При этом, в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет технически невозможно.

QA-специалисту не нужно писать 99 тестов для каждого возраста, хватит пяти: по одному для каждой возрастной группы (скажем, 10, 18, 35 и 75 лет) и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), и все же не следует забывать об этой проверке. 

Граничные значения

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

Она тесно связана с  вышеописанной техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99.

Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100.   

Часто сложности возникают, если возрастные категории указаны «внахлест», например, 0-12, 12-25 лет и т.д. 

Таблица принятия решений

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

Какие возможны сценарии: 1.       Правильный логин и правильный пароль. 2.       Правильный логин, неправильный пароль. 3.       Неправильный логин, правильный пароль.

4.       Неправильный логин, неправильный пароль. 

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

Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее. 

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

Пример таблицы принятия решений 

Попарное тестирование

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

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

Pairwise testing: пример 

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

Браузер Операционная система Язык
1 Opera Windows RU
2 Google Chrome Linux RU
3 Opera Linux EN
4 Google Chrome Windows EN

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

Все это можно просчитать и вручную, но не обязательно – гораздо удобнее автоматизировать процесс. Для этого существует программа попарного независимого комбинированного тестирования – Pairwise Independent Combinatorial Testing (PICT).

Для проведения тестирования специалист создает текстовый файл с перечислением и их возможных значений, а затем запускает PICT через cmd – командную строку. Скомбинированные тесты отображаются в виде таблицы в самой консоли.

Так же результаты по желанию можно выгрузить в файл Excel. 

Пример содержимого файла для программы PICT: Браузер: Chrome, Opera ОС: Windows, Linux

Язык: RU, ENG

Пример попарного тестирования

Причина и следствие

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

Примерный алгоритм использования техники:  
1. Выделяем причины и следствия в спецификациях.   2. Связываем причины и следствия.   3. Учитываем «невозможные» сочетания причин и следствий.   4. Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец – это готовый тестовый сценарий.  

5. Расставляем приоритеты.

Эта техника помогает: 

  • Определить минимальное количество тестов для нахождения максимума ошибок. 

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

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

Например, QA-специалист тестирует приложение типа “записная книжка”.

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

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

Предугадывание ошибок

Используя свои знания о системе, QA-специалист может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами. 

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

  • Что произойдет, если не ввести код?
  • Что произойдет, если не ввести спецсимволы?
  • Что произойдет, если ввести не цифры, а другие символы?
  • Что произойдет, если ввести не четыре цифры, а другое количество?

Преимущества:

1. Эта проверка эффективна в качестве дополнения к другим техникам. 2. Выявляет тестовые случаи, которые “никогда не должны случиться”. 

Недостатки: 1. Техника в значительной степени основана на интуиции. 2. Необходим опыт в тестировании подобных систем. 3. Малое покрытие тестами. 

Итоги

Разумеется, этот список далеко не полон и дает только самое общее представление о принципах тестирования и техниках тест-дизайна.

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

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

Источник: https://www.simbirsoft.com/blog/tekhniki-test-dizayna-i-ikh-prednaznachenie/

Все HR- сотруднику
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: