Классификации видов тестирования

Июль 23, 2022

Главная
Информатика
Классификации видов тестирования

Содержание

6. Подходы к интеграционному тестированию: Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, функции собираются воедино и
7. Высокоуровневые модули Низкоуровневые модули
8. Большой взрыв ("Big Bang" Integration) Все или практически все разработанные модули собираются вместе в виде законченной
10. При статическом тестировании программный код не выполняется — анализ программы происходит на основе исходного кода, который
12. Smoke тестирование - это минимальный набор написанных тест-кейсов, определяющий, что билд готов к передаче в тестирование.
13. Sanity (bug-fix) testing заключается в том, чтобы проверить только исправленные дефекты, изменения из баг-трекинговой системы. Сосредоточен
14. Альфа тестирование - это тестирование, обычно проводимое на ранней стадии разработки продукта и включающее имитацию реального
15. Regression testing – повторное тестирование после внесение изменений в программное обеспечение или в его окружение (в
16. Тестирование производительности – тестирование поведение системы при различных нагрузках и при различных сценариях использования. Основные виды
17. Стрессовое тестирование (Stress testing) – проверка системы при пиковых нагрузках, ограниченных ресурсах и восстановление после возвращению
18. Тестирование стабильности (Stability testing) - оценка работоспособности системы при длительной нагрузке. Главная задача - выявить утечки
19. При тестировании производительности нас интересует: изменение времени выполнения операций в зависимости от интенсивности операций (где интенсивность
20. Тестирование интерфейса пользователя (UI testing) - тестирование графического интерфейса пользователя для того, чтобы убедиться, что он
22. Тестирование совместимости (compatibility testing) - проверить, что приложение совместимо с определенными конфигурациями оборудования, операционными системами, базами
23. Localization testing - проверяет, правильно ли локализован продукт. То есть, переведен на другой язык и корректно
24. 2.3 Методологии разработки ПО Модель жизненного цикла программного обеспечения - структура, содержащая процессы действия и задачи,
25. "Водопад" или каскадная модель
26. "Водопад" или каскадная модель Модель предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход
27. "Водоворот" или каскадная модель с промежуточным контролем - в этой модели предусмотрен промежуточный контроль за счет
28. V модель - разработка через тестирование которая предполагает регулярное тестирование продукта во время разработки.
29. Особенности V модели: • детализация проекта возрастает при движении слева направо, одновременно с течением времени, и
30. Спиральная модель Общая идея спирального процесса заключается в том, чтобы на каждой итерации строить очередную версию
31. Итеративная разработка: Итеративный подход — это выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой
32. Agile – семейство гибких методологий разработки. Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее
33. Scrum - одна из самых популярных методологий гибкой разработки. Одна из причин ее популярности - простота.
34. В Scrum всего три роли: Scrum Master, Product Owner, Team
35. Скрам Мастер (СМ) - отвечает за успех Scrum в проекте. По сути, СМ является интерфейсом (посредником)
36. Product Owner - это человек, отвечающий за разработку продукта. Как правило, это product manager для продуктовой
37. Обязанности команды (7 +/- 2): Отвечают за оценку элементов бэклога Принимают решение по дизайну и имплементации
38. Особенности Scrum - Product Backlog - приоритезированный список бизнес-требований и технических требований к системе. Данный документ
40. Особенности Scrum - Sprint Backlog - содержит функциональность, выбранную Product Owner на итерацию из Product Backlog.
41. Особенности Scrum - Burn-down diagram - диаграмма, показывающая количество сделанной и оставшейся работы.
42. Особенности Scrum - Daily Scrum meeting – ежедневное совещание, которое, длится не более 15 минут. В
43. Особенности Scrum Retrospective meeting - проводится после завершения спринта. Члены команды высказывают своё мнение о прошедшем
44. Особенности Scrum Planning Poker / Scrum poker — техника оценки, используемая для оценки сложности предстоящей работы
46. Kanban - одна из разновидностей управления разработкой программного обеспечения. Перспективный вариант для аутсорсинговых компаний и фрилансеров,
51. Скачать презентацию

Слайд 2

Слайд 3

Слайд 4

Слайд 5

Слайд 6

Подходы к интеграционному тестированию:
Снизу вверх (Bottom Up Integration)
Все низкоуровневые модули, функции

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

Слайд 7

Высокоуровневые модули
Низкоуровневые модули

Слайд 8

Большой взрыв ("Big Bang" Integration)
Все или практически все разработанные модули собираются

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

Слайд 9

Слайд 10

При статическом тестировании программный код не выполняется — анализ программы происходит

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

Слайд 11

Слайд 12

Smoke тестирование - это минимальный набор написанных тест-кейсов, определяющий, что билд

готов к передаче в тестирование. Цель для команды тестирования – не нахождение дефектов, а убедиться, что вся функциональность работает стабильно и готова к тестированию. Занимает от 15 минут до 2х часов. Если не работают элементарные вещи, то билд отдают на доработку. Можно использовать средства автоматизации.

Слайд 13

Sanity (bug-fix) testing заключается в том, чтобы проверить только исправленные дефекты,

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

Слайд 14

Альфа тестирование - это тестирование, обычно проводимое на ранней стадии разработки

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

Слайд 15

Regression testing – повторное тестирование после внесение изменений в программное обеспечение

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

Слайд 16

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

различных сценариях использования.
Основные виды тестирования производительности:
Stress testing
Load testing
Stability testing
Volume testing

Слайд 17

Стрессовое тестирование (Stress testing) – проверка системы при пиковых нагрузках, ограниченных

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

Слайд 18

Тестирование стабильности (Stability testing) - оценка работоспособности системы при длительной нагрузке.

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

Слайд 19

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

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

Слайд 20

Тестирование интерфейса пользователя (UI testing) - тестирование графического интерфейса пользователя для

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

Обычно результатом выполнения UI и Usability тестов является список рекомендаций и предложений по улучшению.

Слайд 21

Слайд 22

Тестирование совместимости (compatibility testing) - проверить, что приложение совместимо с определенными

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

Слайд 23

Localization testing - проверяет, правильно ли локализован продукт. То есть, переведен

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

Слайд 24

2.3 Методологии разработки ПО
Модель жизненного цикла программного обеспечения -

структура, содержащая процессы действия и задачи, которые осуществляются в ходе разработки, использования и сопровождения программного продукта.
Водопад или каскадная модель
Водоворот или каскадная с промежуточным контролем
V модель - разработка через тестирование
Спиральная модель
Итеративная модель
Cемейство Agile: Scrum, XP, Kanban

Слайд 25

"Водопад" или каскадная модель

Слайд 26

"Водопад" или каскадная модель
Модель предусматривает последовательное выполнение всех этапов проекта

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

Слайд 27

"Водоворот" или каскадная модель с промежуточным контролем - в этой модели

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

Слайд 28

V модель - разработка через тестирование которая предполагает регулярное тестирование продукта

во время разработки.

Слайд 29

Особенности V модели:
• детализация проекта возрастает при движении слева направо,

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

Слайд 30

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

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

Слайд 31

Итеративная разработка:
Итеративный подход — это выполнение работ параллельно с непрерывным

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

Слайд 32

Agile – семейство гибких методологий разработки.
Люди и взаимодействие важнее процессов

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

Слайд 33

Scrum - одна из самых популярных методологий гибкой разработки. Одна из

причин ее популярности - простота.

Слайд 34

В Scrum всего три роли: Scrum Master, Product Owner, Team

Слайд 35

Скрам Мастер (СМ) - отвечает за успех Scrum в проекте. По

сути, СМ является интерфейсом (посредником) между менеджментом и командой. В Agile команда самоорганизующаяся и самоуправляемая.

Слайд 36

Product Owner - это человек, отвечающий за разработку продукта. Как правило,

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

Слайд 37

Обязанности команды (7 +/- 2):
Отвечают за оценку элементов бэклога
Принимают

решение по дизайну и имплементации
Разрабатывают софт и предоставляют его заказчику
Отслеживают собственный прогресс
Отвечают за результат перед Product Owner

Слайд 38

Особенности Scrum
- Product Backlog - приоритезированный список бизнес-требований и технических требований

к системе. Данный документ постоянно обновляется - в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За Product Backlog отвечает Product Owner.
Обычно backlog состоит из User Stories следующего формата: - As a , I want so that - As a , I want - In order to as a , I want

Слайд 39

Слайд 40

Особенности Scrum
- Sprint Backlog - содержит функциональность, выбранную Product Owner на

итерацию из Product Backlog. В Scrum итерация называется Sprint длительностью 2-4 недели. Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику). В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Планирование спринта происходит в начале новой итерации, где выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда. При этом никто не может менять список задач утвержденный на Sprint.

Слайд 41

Особенности Scrum
- Burn-down diagram - диаграмма, показывающая количество сделанной и оставшейся

работы.

Слайд 42

Особенности Scrum
- Daily Scrum meeting – ежедневное совещание, которое, длится не

более 15 минут. В течение совещания каждый член команды отвечает на 3 вопроса:
Что сделано с момента предыдущего совещания?
Что будет сделано до следующего совещания?
Какие проблемы мешают достижению целей спринта?

Слайд 43

Особенности Scrum
Retrospective meeting - проводится после завершения спринта. Члены команды высказывают

своё мнение о прошедшем спринте. Отвечают на два основных вопроса:
– Что было сделано хорошо в прошедшем спринте?
– Что надо улучшить в следующем?
В процессе митинга решают вопросы и фиксируют удачные решения. Совещание ограничено одним-тремя часами.

Слайд 44

Особенности Scrum
Planning Poker / Scrum poker — техника оценки, используемая для

оценки сложности предстоящей работы или относительного объёма решаемых задач при разработке программного обеспечения.

Слайд 45

Слайд 46

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

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

Слайд 47

Слайд 48

Слайд 49

Классификации видов тестирования

Содержание

Подходы к интеграционному тестированию:Снизу вверх (Bottom Up Integration)Все низкоуровневые модули, функции

Высокоуровневые модулиНизкоуровневые модули

Большой взрыв ("Big Bang" Integration)Все или практически все разработанные модули собираются