Тестовая документация. Виды. Тест-кейсы, чек-листы

Август 6, 2022

Главная
Информатика
Тестовая документация. Виды. Тест-кейсы, чек-листы

Содержание

2. Процесс тестирования.
3. Процесс тестирования.
4. Вечный круг тестирования.
5. Тестовые артефакты (тестовая документация). Спецификация программного обеспечения (Software Specification), Требования (Модуль 4) План тестирования (Test Plan)
6. Чек лист Чек лист (Check-list) - список шагов или перечень функциональностей, который позволяет тестировщику убедиться в
7. Check-list
8. Определения Тест дизайн (Test Design) – это этап процесса тестирования ПО, на котором проектируются и создаются
9. Test Suite На примере Test Suite можно рассмотреть так: Test Suite - это кирпичная стена, Test
10. Тест кейс. Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров,
11. Тест кейс должен быть унифицированным – в рамках одного тест кейса использовать одни и те же
12. Тест кейсов не должно быть слишком много, т.к. их потом трудно будет поддерживать. Тест кейсы должны
13. Виды тестовых случаев. Позитивный тест кейс (пользователь вводит корректные данные) Негативный тест кейс (пользователь вводит корректные
14. Структура тест-кейсов Каждый тест кейс имеет 3 основные составляющие: - PreConditions (Предусловия) – список действий, которые
15. Поля, которые содержит тест-кейс ID (уникальный номер теста) Epic (module) (модуль системы, к которому относится данные
16. Показываем формат…
17. Пример тест кейса 1: Проверка отображения страницы.
18. Пример тест кейса 2: Проверка отображения страницы. Действие: Открыть страницу «Вход в систему» Проверка: Проверьте, что
19. Советы по написанию тест кейсов: Разбейте функционал программы и начните составление тест кейсов для одной из
20. Напишите тест кейсы для формы входа в почтовый ящик. (Demo)
21. Примеры тест кейсов для формы входа в почтовый ящик: Т1: Внешний вид страницы для входа в
22. Жизненный цикл тест кейса.
23. Для чего нам нужны тест-кейсы\ чек-листы?
24. Для чего нам нужна тестовая документация 1. Передача знаний 2. Ускорение регрессионного тестирования 3. Помощь при
25. Основные техники тест дизайна. Верификация, валидация Positive\ negative testing Эквивалентное разделение, классы эквивалентности Анализ граничных Значений
26. Эквивалентное разделение (Equivalence Partitioning - EP), классы эквивалентности (equivalent classes-EC) Класс эквивалентности - множество тестов со
27. Эквивалентное разделение (Equivalence Partitioning - EP), классы эквивалентности (equivalent classes-EC) Например, у вас есть диапазон допустимых
28. Анализ граничных Значений (Boundary Value Analysis) Например, пусть мы тестируем программу для отдела кадров, в ней
29. Анализ граничных Значений (Boundary Value Analysis) if (age >= 0 && age hireStatus="NO"; if (age >=
30. Пример со скидками Рисуем…
31. State transition testing Тестирование переходов из одного состояния системы, в другое
32. Причина/ Следствие (Cause/Effect)
33. Причина/ Следствие (Cause/Effect) Это ввод комбинаций условий (причин), для получения ответа от системы (следствие). Например, вы
34. Причина/ Следствие (Cause/Effect) Пример с регистрацией нового пользователя. Что будет являться следствием ?
35. Предугадывание ошибок Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на
36. Дымовое (Smoke testing). Дымовое тестирование-это короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода
37. Таблица принятия решений Вы хотите купить абонемент в тренажерный зал на 1 месяц. Ниже указаны условия:
38. Таблица принятия решений
39. Таблица принятия решений Попрактикуемся…
40. AD HOC Это тестирование без подробных спецификаций, сопроводительных документов, тест плана и т.д. Другими словами, тестирование
41. Попарное тестирование (Pairwise testing).
42. All pairs testing Пример из жизни: Подобрать тестовые конфигурации на основе требований к поддерживаемым ОС, Версиям
44. Скачать презентацию

Слайд 2

Процесс тестирования.

Слайд 3

Процесс тестирования.

Слайд 4

Вечный круг тестирования.

Слайд 5

Тестовые артефакты (тестовая документация).
Спецификация программного обеспечения (Software Specification), Требования (Модуль 4)
План

тестирования (Test Plan) (Модуль 3)
Чек лист (Cheсk-list)
Тестовый случай (Test Case)
Тестовый набор (Test Suite)
Баг Репорты (Bug Reports) (Модуль 6)
Отчеты о тестировании (Test Results Reports)

Слайд 6

Чек лист
Чек лист (Check-list) - список шагов или перечень функциональностей, который

позволяет тестировщику убедиться в корректной работе приложения.
Пример:

Слайд 7

Check-list

Слайд 8

Определения
Тест дизайн (Test Design) – это этап процесса тестирования ПО, на

котором проектируются и создаются тестовые случаи (Test Case), в соответствии с определёнными ранее критериями качества и целями тестирования.
Тестовый набор (Test Suite) - это набор тестов реализующих бизнес-задачу, выполняемую тестируемой системой. Тестовый набор включает в себя, кроме тестовых сценариев, ещё и тестовые данные и правила их генерации.
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Слайд 9

Test Suite
На примере Test Suite можно рассмотреть так:
Test Suite - это

кирпичная стена,
Test Case – это один кирпич из стены.
В Test Suite попадают тест кейсы объединённые по какой либо роли, функциональности.

Слайд 10

Тест кейс.
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов,

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

Слайд 11

Тест кейс должен быть унифицированным – в рамках одного тест кейса

использовать одни и те же термины, обозначения.
Тест кейс должен быть однозначным и понятным - значение каждой фазы и слова, должно пониматься в единственно возможном смысле. Не используйте слова «плохо», «хорошо», «очевидно».
Тест кейс не должен быть слишком простым или слишком сложным, не используйте длинных, запутанных сложноподчинённых предложений (лучше разделить один шаг на несколько).
Тест кейс должен проверять одну функциональность и содержать до 10-ти шагов.
Тест кейсов не должно быть слишком много, т.к. их потом трудно будет поддерживать.

Слайд 12

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

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

Слайд 13

Виды тестовых случаев.
Позитивный тест кейс (пользователь вводит корректные данные)
Негативный тест кейс

(пользователь вводит корректные данные)

Слайд 14

Структура тест-кейсов
Каждый тест кейс имеет 3 основные составляющие:
- PreConditions (Предусловия)

– список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
- Test Case Description(Описание тестового случая) – список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям .
- PostConditions (Постусловия) –список действий, которые возвращают систему в первоначальное состояние.
Примечание: Post Conditions не является обязательной частью. Эта часть актуальна при автоматизированном тестировании, когда за один прогон можно наполнить базу даннях множеством некорректных документов. Поэтому желательно возвращать систему в первоначальное состояние.

Слайд 15

Поля, которые содержит тест-кейс
ID (уникальный номер теста)
Epic (module) (модуль системы, к

которому относится данные тест)
Summary (краткое описание, ИДЕЯ тестового случая)
Description (подробное описание того, что будет тестироваться)
Steps (подробное описание шагов)
Data (используемые в процессе тестирования, данные)
Expected result (ожидаемый результат)
Actual result (Фактический результат)
Requirement # (ссылка на требование)
Bug # (ссылка на баг)
Criticality (важность тестового случая)
Comment (комментарий)

Слайд 16

Показываем формат…

Слайд 17

Пример тест кейса 1: Проверка отображения страницы.

Слайд 18

Пример тест кейса 2: Проверка отображения страницы.
Действие: Открыть страницу «Вход в

систему» Проверка: Проверьте, что отображаемая страница соответствует странице на рисунке (и прилагаем изображение )

Слайд 19

Советы по написанию тест кейсов:
Разбейте функционал программы и начните составление тест

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

Слайд 20

Напишите тест кейсы для формы входа в почтовый ящик. (Demo)

Слайд 21

Примеры тест кейсов для формы входа в почтовый ящик:
Т1: Внешний вид

страницы для входа в почту.
Т2: Авторизация зарегистрированного пользователя с помощью корректных данных.
Т3: Авторизация с помощью корректного логина и некорректного пароля (и наоборот) зарегистрированного пользователя.
Т4: Авторизация с помощью некорретной пары логин-пароль
Т5: Авторизация с пустыми полями логина и пароля.

Слайд 22

Жизненный цикл тест кейса.

Слайд 23

$Для чего нам нужны тест-кейсы\ чек-листы?$

Для чего нам нужны тест-кейсы\ чек-листы?

Слайд 24

Для чего нам нужна тестовая документация
1. Передача знаний
2. Ускорение регрессионного тестирования
3.

Помощь при автоматизации
4. Отчетность о выполненной работе
5. Визуализация покрытия требований
6. Оценка трудозатрат

Слайд 25

$Основные техники тест дизайна. Верификация, валидация Positive\ negative testing Эквивалентное разделение,$

Основные техники тест дизайна.
Верификация, валидация
Positive\ negative testing
Эквивалентное разделение, классы эквивалентности
Анализ граничных

Значений (Boundary Value Analysis)
Причина/ Следствие (Cause/Effect )
Предугадывание ошибки (Error Guessing)
Исчерпывающее тестирование (Exhaustive Testing)
Попарное тестирование (Pairwise testing)
AD HOC testing
Дымовое (Smoke testing)

Слайд 26

Эквивалентное разделение (Equivalence Partitioning - EP), классы эквивалентности (equivalent classes-EC)
Класс

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

Слайд 27

Эквивалентное разделение (Equivalence Partitioning - EP), классы эквивалентности (equivalent classes-EC)
Например, у

вас есть диапазон допустимых значений от 1 до 10, Вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала - 15.

Слайд 28

Анализ граничных Значений (Boundary Value Analysis)
Например, пусть мы тестируем программу

для отдела кадров, в ней есть поле "Возраст соискателя".
Требования по возрасту у нас будут такие:
0-13 лет - не нанимать
14-17 лет - можно нанимать на неполный день
18-54 года - можно нанимать на полный день
55-99 лет - не нанимать
Пример взят из книги A Practitioner's guide to Sofware Test Design (Lee Copeland).

Слайд 29

Анализ граничных Значений (Boundary Value Analysis)
if (age >= 0 && age

<=13)
hireStatus="NO";
if (age >= 14 && age <=17)
hireStatus="PART";
if (age >= 18 && age <=54)
hireStatus="FULL";
if (age >= 55 && age <=99)
hireStatus="NO";
Можно протестировать одно число из каждого диапазона. Например: 5, 15, 20, 60. А также граничные значения (первое и последнее значения из каждого диапазона): 0, 13, 14, 17, 18, 54, 55, 99.

Слайд 30

Пример со скидками
Рисуем…

Слайд 31

State transition testing
Тестирование переходов из одного состояния системы, в другое

Слайд 32

Причина/ Следствие (Cause/Effect)

Слайд 33

Причина/ Следствие (Cause/Effect)
Это ввод комбинаций условий (причин), для получения ответа

от системы (следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как "Имя", "Адрес", "Номер Телефона" а затем, нажать кнопку "Добавить" - эта "Причина". После нажатия кнопки "Добавить", система добавляет клиента в базу данных и показывает его номер на экране - это "Следствие".

Слайд 34

Причина/ Следствие (Cause/Effect)
Пример с регистрацией нового пользователя.
Что будет являться следствием

Слайд 35

Предугадывание ошибок
Это когда тест аналитик использует свои знания системы и способность

к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки.

Слайд 36

Дымовое (Smoke testing).
Дымовое тестирование-это короткий цикл тестов, выполняемый для подтверждения

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

Слайд 37

Таблица принятия решений
Вы хотите купить абонемент в тренажерный зал на 1

месяц. Ниже указаны условия:
1) В августе цена на 10% ниже
2) В январе цена на 10% выше
3) Если вы студент, то получаете 20% скидку
4) Если Вам больше 60 лет, то вы получаете 30% скидку (данная скидка не суммируется со студенческой)

Слайд 38

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

Слайд 39

Таблица принятия решений
Попрактикуемся…

Слайд 40

AD HOC
Это тестирование без подробных спецификаций, сопроводительных документов, тест плана и

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

Слайд 41

Попарное тестирование (Pairwise testing).

Слайд 42

All pairs testing
Пример из жизни:
Подобрать тестовые конфигурации на основе требований к

поддерживаемым ОС, Версиям ОС, Браузерам, Разрешениям экрана

Тестовая документация. Виды. Тест-кейсы, чек-листы

Содержание

Процесс тестирования.

Процесс тестирования.

Вечный круг тестирования.

Тестовые артефакты (тестовая документация).Спецификация программного обеспечения (Software Specification), Требования (Модуль 4)План

Чек листЧек лист (Check-list) - список шагов или перечень функциональностей, который

Check-list

ОпределенияТест дизайн (Test Design) – это этап процесса тестирования ПО, на

Test SuiteНа примере Test Suite можно рассмотреть так:Test Suite - это

Тест кейс.Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов,

Тест кейс должен быть унифицированным – в рамках одного тест кейса

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

Виды тестовых случаев. Позитивный тест кейс (пользователь вводит корректные данные)Негативный тест кейс

Структура тест-кейсовКаждый тест кейс имеет 3 основные составляющие: - PreConditions (Предусловия)

Поля, которые содержит тест-кейсID (уникальный номер теста)Epic (module) (модуль системы, к

Показываем формат…

Пример тест кейса 1: Проверка отображения страницы.

Пример тест кейса 2: Проверка отображения страницы.Действие: Открыть страницу «Вход в

Советы по написанию тест кейсов: Разбейте функционал программы и начните составление тест

Напишите тест кейсы для формы входа в почтовый ящик. (Demo)

Примеры тест кейсов для формы входа в почтовый ящик: Т1: Внешний вид

Жизненный цикл тест кейса.

Для чего нам нужны тест-кейсы\ чек-листы?

Для чего нам нужна тестовая документация1. Передача знаний2. Ускорение регрессионного тестирования3.

Основные техники тест дизайна. Верификация, валидацияPositive\ negative testingЭквивалентное разделение, классы эквивалентностиАнализ граничных

Эквивалентное разделение (Equivalence Partitioning - EP), классы эквивалентности (equivalent classes-EC) Класс

Эквивалентное разделение (Equivalence Partitioning - EP), классы эквивалентности (equivalent classes-EC)Например, у

Анализ граничных Значений (Boundary Value Analysis) Например, пусть мы тестируем программу

Анализ граничных Значений (Boundary Value Analysis)if (age >= 0 && age

Пример со скидкамиРисуем…

State transition testingТестирование переходов из одного состояния системы, в другое

Причина/ Следствие (Cause/Effect)

Причина/ Следствие (Cause/Effect) Это ввод комбинаций условий (причин), для получения ответа

Причина/ Следствие (Cause/Effect) Пример с регистрацией нового пользователя.Что будет являться следствием

Предугадывание ошибокЭто когда тест аналитик использует свои знания системы и способность

Дымовое (Smoke testing). Дымовое тестирование-это короткий цикл тестов, выполняемый для подтверждения

Таблица принятия решенийВы хотите купить абонемент в тренажерный зал на 1

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

Таблица принятия решенийПопрактикуемся…

AD HOCЭто тестирование без подробных спецификаций, сопроводительных документов, тест плана и

Попарное тестирование (Pairwise testing).

All pairs testingПример из жизни:Подобрать тестовые конфигурации на основе требований к

Похожие презентации

Тестовые артефакты (тестовая документация).
Спецификация программного обеспечения (Software Specification), Требования (Модуль 4)
План

Чек лист
Чек лист (Check-list) - список шагов или перечень функциональностей, который

Определения
Тест дизайн (Test Design) – это этап процесса тестирования ПО, на

Test Suite
На примере Test Suite можно рассмотреть так:
Test Suite - это

Тест кейс.
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов,

Виды тестовых случаев.
Позитивный тест кейс (пользователь вводит корректные данные)
Негативный тест кейс

Структура тест-кейсов
Каждый тест кейс имеет 3 основные составляющие:
- PreConditions (Предусловия)

Поля, которые содержит тест-кейс
ID (уникальный номер теста)
Epic (module) (модуль системы, к

Пример тест кейса 2: Проверка отображения страницы.
Действие: Открыть страницу «Вход в

Советы по написанию тест кейсов:
Разбейте функционал программы и начните составление тест

Примеры тест кейсов для формы входа в почтовый ящик:
Т1: Внешний вид

Для чего нам нужна тестовая документация
1. Передача знаний
2. Ускорение регрессионного тестирования
3.

Основные техники тест дизайна.
Верификация, валидация
Positive\ negative testing
Эквивалентное разделение, классы эквивалентности
Анализ граничных

Эквивалентное разделение (Equivalence Partitioning - EP), классы эквивалентности (equivalent classes-EC)
Класс

Эквивалентное разделение (Equivalence Partitioning - EP), классы эквивалентности (equivalent classes-EC)
Например, у

Анализ граничных Значений (Boundary Value Analysis)
Например, пусть мы тестируем программу

Анализ граничных Значений (Boundary Value Analysis)
if (age >= 0 && age

Пример со скидками
Рисуем…

State transition testing
Тестирование переходов из одного состояния системы, в другое

Причина/ Следствие (Cause/Effect)
Это ввод комбинаций условий (причин), для получения ответа

Причина/ Следствие (Cause/Effect)
Пример с регистрацией нового пользователя.
Что будет являться следствием

Предугадывание ошибок
Это когда тест аналитик использует свои знания системы и способность

Дымовое (Smoke testing).
Дымовое тестирование-это короткий цикл тестов, выполняемый для подтверждения

Таблица принятия решений
Вы хотите купить абонемент в тренажерный зал на 1

Таблица принятия решений
Попрактикуемся…

AD HOC
Это тестирование без подробных спецификаций, сопроводительных документов, тест плана и

All pairs testing
Пример из жизни:
Подобрать тестовые конфигурации на основе требований к