Подходы к тестированию

1.

ЛЕКЦИЯ 5
«Подходы к тестированию»

2.

Вопросы:
Изобразите ЖЦ дефекта.
(как сможете )
2

3.

Содержание:
Уровни тестирования (типы тестов по
покрытию)
Приоритизация выполнения проверок
Тестовые активности
3

4.

Уровни тестирования
Тестовое покрытие –
это одна из метрик оценки качества
тестирования, представляющая из себя
плотность покрытия тестами требований
либо исполняемого кода
4

5.

Уровни тестирования
Тестовое покрытие определяется:
-Глубиной тестирования
-Шириной тестирования
-Целями тестирования
-Профессиональным уровнем тестировщика
5

6.

Уровни тестирования
Ширина тестирования
отражает
количество
модулей/функций
приложения, которые были протестированы.
Глубина тестирования
отражает
вид
проверок,
которые
производились
для
модуля/функции
(например,
позитивность/негативность
сценариев, тестирование в рамках/вне рамок
тест сценариев и др.).
6

7.

По уровню покрытия
( по глубине)
Smoke – пригодность сборки для дальнейших тестов
(сценарии, проверяющие работоспособность основной
функциональности компонента или системы на валидных
данных. Если Smoke тест не прошёл, то билд возвращается
разработчикам для исправления обнаруженных серьёзных
дефектов, которые блокируют дальнейшее тестирование)
Уровень качества:
Acceptable
Unacceptable

8.

По уровню покрытия
( по глубине)
–
MAT (Minimal Acceptance Test, Positive test) тест только на
положительных сценариях. Валидные данные- это данные,
которые необходимо использовать для корректной работы
модуля/функциональности (например, тип принимаемого
значения- дата, положительное целое число, текст). Если в
требованиях используется интервал допустимых значений, то
данные, которые могут использоваться в тестовом сценарии МАТ,
обязательно должны попадать в этот интервал. Если в требованиях
описан определённый формат, в котором должны вводиться
данные ( например, адрес эл. почты или реквизиты банка) то
формат должен быть соблюдён.
Тестирование ГУИ не входит в тест уровня МАТ.Если GUI дефекты
были найдены на этом уровне, их следует внести, но оценивать
качество на уровне МАТ мы будем без ГУИ дефектов.
Уровень качества: High /Medium /Low

9.

По уровню покрытия
( по глубине)
–
AT (Acceptance Test) полный тест на положительных и
негативных сценариях. Тест на этом уровне покрывает все
возможные сценарии тестирования: проверку
работоспособности модулей при вводе корректных значений;
проверку при вводе некорректных значений (которые не
должны использоваться при работе с функциональностью
согласно требованиям, например буквы в числовом поле);
проверку исключительных ситуаций, сообщений об ошибках;
использование форматов данных, отличных от тех, которые
указаны в требованиях.
Уровень качества:
High
Medium
Low

10.

По цели тестирования
(по ширине)
New Feature Test (NFT, AT of NF) – тестирование
новой функциональсти, которая ранее не
тестировалась. Включает в себя: проведение
полного (АТ) теста непосредственно новой
функциональности;
тестирование
новой
документации на соответствие документации;
проверок
всевозможных
завязок
ранее
реализованной
функиональности
с
новым
модулем/функцией.

11.

По цели тестирования
(по ширине)
• Regression testing – удостовериться, что изменения в коде
(добавление новой функциональности или исправление
дефектов) не повлияло на работу старой функциональности.
• Регрессионное тестирование может быть проведено на
уровне Smoke, MAT или AT.

12.

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

13.

По цели тестирования
(по ширине)
User Acceptance Test (UAT, ПиМИ): формальная
проверка приложения (зачастую заказчиком),
сопровождаемая протоколированием результатов

14.

Тестовые активности:
Smoke
Регрессионное
Валидация дефектов (DV)
Тестирование новых функций (NFT)

15.

Задача 1
• Вам предоставляется на тестирование веб-проект –
интернет магазин по продаже деталей для
автомобилей.
• Из планов разработки известно, что на
тестирование будут поставлены 3 сборки:
– #1 включает в себя 50% функциональности
– #2 включает в себя оставшиеся 50% функциональности
– #3 является финальной (release candidate) и будет отдана заказчику
• Вопрос:
– Какие тестовые активности Вы проведете на каждой
сборке?

16.

Спасибо за внимание!
Жду Ваших вопросов
16