Lektsia_7_lb9_kr3

1. Лекция 7

Виды тестирования. Баг-репорт

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

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

3.

4.

5. 1. Классификация по запуску кода на исполнение:

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

6. 2. Классификация по доступу к коду и архитектуре :

Тестирование белого ящика — метод
предполагает полный доступ к коду проекта.
тестирования
ПО,
который
Тестирование серого ящика — метод тестирования ПО, который
предполагает частичный доступ к коду проекта (комбинация White Box и
Black Box методов).
Тестирование чёрного ящика — метод тестирования ПО, который не
предполагает доступа (полного или частичного) к системе. Основывается на
работе исключительно
с внешним интерфейсом
тестируемой системы.

7. 3. Классификация по уровню детализации приложения (уровни тестированиия ПО):

Тестирование на разных уровнях производится на протяжении всего
жизненного цикла разработки и сопровождения программного обеспечения.
Уровень тестирования определяет то, над чем производятся тесты: над
отдельным модулем, группой модулей или системой, в целом. Проведение
тестирования на всех уровнях системы - это залог успешной реализации и
сдачи проекта.
Уровни Тестирования
Компонентное или Модульное тестирование (Component Testing or Unit
Testing)
Интеграционное тестирование (Integration Testing)
Системное тестирование (System Testing)
Приемочное тестирование (Acceptance Testing)

8.

Компонентное или Модульное тестирование (Component or Unit Testing)
Компонентное
(модульное)
тестирование
проверяет
функциональность и ищет дефекты в частях приложения, которые
доступны и могут быть протестированы по-отдельности (модули
программ, объекты, классы, функции и т.д.).
Один из наиболее эффективных подходов к компонентному
(модульному)
тестированию
—
это
подготовка
автоматизированных тестов до начала основного кодирования
(разработки) программного обеспечения.

9. Интеграционное тестирование (Integration Testing)

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

10. Подходы к интеграционному тестированию:

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

11. Системное тестирование (System Testing)

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

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

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

13. 5. Классификация по принципам работы с приложением

4.Классификация по степени автоматизации:
Ручное тестирование.
• Автоматизированное тестирование
5. Классификация по принципам работы с
приложением
Позитивное тестирование — тестирование, при котором используются только
корректные данные.
Негативное тестирование — тестирование приложения, при котором
используются некорректные данные и выполняются некорректные операции.

14. 6. Классификация по уровню функционального тестирования:

Дымовое тестирование (smoke test) — тестирование, выполняемое на
новой сборке, с целью подтверждения того, что программное обеспечение
стартует и выполняет основные для бизнеса функции.
Тестирование критического пути (critical path) — направлено для
проверки функциональности, используемой обычными пользователями во
время их повседневной деятельности.
Расширенное тестирование (extended) — направлено на исследование
всей заявленной в требованиях функциональности.

15. 7. Классификация в зависимости от исполнителей:

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

16. 8. Классификация в зависимости от целей тестирования:

Функциональное тестирование (functional testing) — направлено на
проверку корректности работы функциональности приложения.
Нефункциональное
тестирование
(non-functional
testing)
—
тестирование атрибутов компонента или системы, не относящихся к
функциональности.

17.

1.
Тестирование производительности (performance testing) — определение
стабильности и потребления ресурсов в условиях различных сценариев
использования и нагрузок.
2.
Нагрузочное тестирование (load testing) — определение или сбор
показателей производительности и времени отклика программно-технической
системы или устройства в ответ на внешний запрос с целью установления
соответствия требованиям, предъявляемым к данной системе (устройству).
3.
Тестирование масштабируемости (scalability testing) — тестирование,
которое измеряет производительность сети или системы, когда количество
пользовательских запросов увеличивается или уменьшается.
4.
Объёмное тестирование (volume testing) — это тип тестирования
программного обеспечения, которое проводится для тестирования программного
приложения с определенным объемом данных.
5.
Стрессовое тестирование (stress testing) — тип тестирования
направленный для проверки, как система обращается с нарастающей нагрузкой
(количеством одновременных пользователей).

18.

6.
Инсталляционное тестирование (installation testing) —
тестирование, направленное на проверку успешной установки и
настройки, обновления или удаления приложения.
7.
Тестирование интерфейса (GUI/UI testing) — проверка
требований к пользовательскому интерфейсу.
8.
Тестирование удобства использования (usability testing) — это
метод тестирования, направленный на установление степени удобства
использования, понятности и привлекательности для пользователей
разрабатываемого продукта в контексте заданных условий.
9.
Тестирование локализации (localization testing) — проверка
адаптации программного обеспечения для определенной аудитории в
соответствии с ее культурными особенностями.

19.

10.
Тестирование безопасности (security testing) — это стратегия
тестирования, используемая для проверки безопасности системы, а также
для анализа рисков, связанных с обеспечением целостного подхода к защите
приложения, атак хакеров, вирусов, несанкционированного доступа к
конфиденциальным данным.
11.
Тестирование надёжности (reliability testing) — один из видов
нефункционального тестирования ПО, целью которого является проверка
работоспособности приложения при длительном тестировании с ожидаемым
уровнем нагрузки.
12.
Регрессионное тестирование (regression testing) — тестирование
уже проверенной ранее функциональности после внесения изменений в код
приложения, для уверенности в том, что эти изменения не внесли ошибки в
областях, которые не подверглись изменениям.
13.
Повторное/подтверждающее тестирование (re-testing/confirmation
testing) — тестирование, во время которого исполняются тестовые сценарии,
выявившие ошибки во время последнего запуска, для подтверждения
успешности исправления этих ошибок.

20. Понятие бага

• Багом (от англ. bug) или дефектом часто называют ошибку в
программном коде. Это не совсем ошибка, а скорее
несоответствие фактического результата ожидаемому.
• Баг — это расхождение ожидаемого результата с фактическим.

21. Виды багов

• Функциональные. Возникают, когда фактический результат работы не
соответствует ожиданиям: не получается опубликовать комментарий на
сайте, добавить товар в корзину или открыть страницу.
• Визуальные. Это случаи, когда приложение выглядит иначе, чем
задумано: кнопка накладывается на текст, не отображаются картинки
или текст выходит за пределы окна.
• Логические. Баг, при котором что-то работает неправильно с точки
зрения логики, — например, когда можно указать несуществующую
дату (31 февраля) или поставить дату рождения из будущего (2077 год).
• Дефекты UX. Приложение или программа неудобны в использовании:
при просмотре ленты новостей пользователя постоянно отбрасывает к
началу, слишком близко расположены кнопки и вместо одной
нажимается другая.
• Дефекты безопасности. Случаи, когда из-за ошибки в коде данные
пользователей (почты, пароли, фото, информация о платежах) могут
быть доступны третьим лицам.

22. Атрибут бага - серьезность

23. Атрибут бага - серьезность

24. Атрибут бага - приоритет

Приоритет — это срочность выполнения задачи. Всего выделяется
три уровня приоритетов:
• P1 Высокий — исправляется в первую очередь, так как баг ломает
работу приложения.
• P2 Средний — обязательный к исправлению баг после
критического.
• P3 Низкий — не требует немедленного решения

25. Баг-репорт

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

26. Требования к обязательным полям баг-репорта

Обязательными полями баг репорта являются: короткое описание (Bug
Summary), серьезность (Severity), шаги к воспроизведению (Steps to
reproduce), результат (Actual Result), ожидаемый результат (Expected
Result).
1. Короткое описание
В одном предложении следует уместить смысл всего баг репорта, а
именно: коротко и ясно, используя правильную терминологию сказать
что и где не работает.
Например: Приложение зависает, при попытке сохранения текстового
файла размером больше 50Мб.
Данные на форме "Профайл" не сохраняются после нажатия кнопки
"Сохранить".

27. Принцип «Что? Где? Когда?"

Принцип «Что? Где? Когда?"
Составьте предложение, в котором факты дефекта изложены в
следующей последовательности:
Где?: В каком месте интерфейса пользователя или архитектуры
программного продукта находится проблема. Причем, начинайте
предложение с существительного, а не предлога.
Что?: Что происходит или не происходит согласно спецификации или вашему
представлению о нормальной работе программного продукта. При этом
указывайте на наличие или отсутствие объекта проблемы, а не на его
содержание (его указывают в описании). Если содержание проблемы
варьируется, все известные варианты указываются в описании.
Когда?: В какой момент работы программного продукта, по наступлению
какого события или при каких условиях проблема проявляется.

28. 2.СЕРЬЕЗНОСТЬ

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

29. 3. Шаги к воспроизведению / 4. Результат / 5. Ожидаемый результат

Шаги к воспроизведению
1. Войдите в систему: Пользователь Тестер1, пароль xxxXXX
--> Вход в систему осуществлен
2. Кликните линк Профайл
--> Страница Профайл открылась
3. Введите Новое имя пользователя: Тестер2
4. Нажмите кнопку Сохранить
Результат
На экране появилась ошибка. Новое имя пользователя не было сохранено
Ожидаемый результат
Страница профайл перегрузилась. Новое значение имени пользователя
сохранено.

30.

Заполнение полей баг репорта
В описанной ниже таблице представлены основные поля баг репорта и роль
работника,
ответственного
за
заполнение
данного
поля.
Красным
цветом выделены обязательные для заполнения поля: