Инна Слизовская

Инженер по автоматизации тестирования

Управление тестированием

Содержание

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

• Результаты тестирования

• Работа с рисками

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

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

программного продукта

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

Анализ требований

Планирование

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

Изучение информации о системе. Получение и анализ

данных для составления плана тестирования

Определение объемов тестирования,

подходов, ресурсов и календарного плана

Определение цели тестирования,

входных данных, архитектуры тестов

Этапы тестирования (продолж.)

Отладка тестов

Выполнение

тестов (testing cycles)

Интеграционное

системное тестирование

(System Integration Testing)

Приемочные испытания

(Acceptance Testing)

Эксплуатация и

поддержка

Непосредственная проверка тестов,

анализ всевозможных тестовых случаев

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

интеграции систем и модулей для

определения рабочих характеристик

Альфа-тестирование,

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

Проверка результатов,

исправление дефектов

Пересмотр и отладка тестовых случаев

Планирование тестирования

• объем работ

• сроки выполнения

• подходы к решению задач

• команда

• календарный план

Цели плана тестирования

• Определить объекты тестирования

• Проанализировать архитектуру системы на

полноту и тестопригодность

• Создать перечень инструментов и ресурсов,

используемых в проекте

• Перечислить список отчётных документов

Основные разделы плана тестирования

• Введение

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

• Стратегия тестирования

• Материалы, подлежащие сдаче

• Расписание

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

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

Тестирование бизнес-циклов

Тестирование пользовательского интерфейса

Нагрузочное тестирование

Тестирование безопасности

Инсталляционное тестирование

....

• Инструментальные средства

Jira

Crucible

Pytest

…

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

• Определить и описать тестовые сценарии

• Подготовить анализ рабочей нагрузки

• Определить и структурировать тестовые

процедуры

• Просмотреть и оценить тестовое покрытие

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

Значение в поле «Сумма» должно

рассчитываться как сумма значений из

полей «A» и «B».

Плохой тест-кейс ...

Действия:

Ввести значения в поля «A» и «B».

Ожидаемый результат:

Значение в поле «Сумма» должно

рассчитываться как сумма значений из

полей «А» и «B».

Хороший тест-кейс ...

Действия:

1. В поле «А» ввести значение 2

2. В поле «B» ввести значение 3

3. Нажать на кнопку «Рассчитать»

Ожидаемый результат:

В поле «Сумма» отобразилось значение 5

Содержание тест-кейса

• Title/Goal

• PreConditions

• Test Case Description

• Expected Result

• Actual Result

Пример 1

• do A1, verify B1

• do A2, verify B2

• do A3, verify B3 Action Expected Result Test Result

(passed/failed/blocked)

PreConditions

do A1 verify B1

do A2 verify B2

Test Case Description

do A3 verify B3

Детализация описания тест кейсов

Проверка отображения страницы

Действие Ожидаемый результат Результат теста

Открыть страницу Логин - Окно Логин открыто

- Название окна - Логин

- Логотип компании

отображается в правом

верхнем углу

- На форме 2 поля - Имя

и Пароль

- Кнопка Логин доступна

- Линк забыл пароль -

доступен

...

Пример 2.1

Детализация описания тест кейсов.

Пример 2.2 Название: Проверка отображения

страницы

Действие: Открыть страницу Логин

Проверка: Проверьте, что отображаемая

страница соответствует странице на

картинке 1 (и прилагаем screenshot

страницы Логин)

Структура тест-кейса

• Тест-кейсы необходимо писать по

требованиям

• Тест-кейсы должны не повторять требования,

а проверять их

• Один тест-кейс - одна проверка

• Не зависящие от данных, ситуаций и объектов

Action > Expected Result > Actual Result

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

• Выполнить тестовые процедуры

• Оценить выполнение тестирования

• Исправить провалившиеся тесты

• Исправить, если нужно, тестовые процедуры

• Проверить результаты

• Проанализировать неожиданные результаты

• Занести дефекты

% тестирования продукта

Сколько тестовых сценариев прошло хотя бы раз?

Сколько тестовых сценариев еще ни разу не

запускалось?

0

20

40

60

80

100

120

week1 week2 week3 week4

executed not exec'd

Известное качество

Неизвестное качество

Работа с дефектами

Баг / ошибка / дефект / неисправность

1. Известен ожидаемый результат;

2. Известен фактический результат;

3. Известно, что результат из пункта 2 не равен

результату из пункта 1.

Важность и Приоритет Ошибки

Важность (Severity) – это атрибут,

характеризующий влияние бага на

работоспособность приложения.

Blocker –> Critical -> Major -> Minor ->Trivial

Приоритет (Priority) – это атрибут,

указывающий на очередность выполнения

задачи или устранения бага.

High -> Medium -> Low

Priority = Impact + Users portion + Stability

Типичные проблемы отчетов об ошибках

• Тестирование устаревшего билда

• Изобретение собственных требований

• Использование нечетких формулировок

• Попытка определить причину ошибки

• Завышение приоритета ошибки

• Самовольное сужение тестового покрытия

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

• Оценить покрытие функциональности

тестовыми сценариями

• Оценить покрытие кода

• Проанализировать дефекты

• Определить, были ли достигнуты критерии

завершенности и успешности тестирования

Ключевые метрики тестирования ПО

• Метрики покрытия (Coverage Measures)

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

требований (Requirements-based Test Coverage)

Тестовое покрытие, основанное на покрытии кода

приложения (Code-based Test Coverage)

• Метрики достигнутого качества (Measuring Perceived

Quality)

• Отчеты, основанные на ошибках (Defect Reports)

• Метрики производительности (Performance Measures)

Отчеты, основанные на ошибках (Defect Reports)

Плотность ошибок

Отчеты, основанные на ошибках (Defect Reports)

Изменение количества ошибок (Defect Trend Reports)

Отчеты, основанные на ошибках (Defect Reports)

Дефекты, предсказанные, найденные, закрытые

0

100

200

300

400

500

600

wk1 wk2 wk3 wk4 wk5 wk6 wk7 wk8

predicted found closed

Все дефекты

закрыты но не все

найдены

Отчеты, основанные на ошибках (Defect Reports)

Доля отклоненных дефектов

Declined defects ratio

0,0%

5,0%

10,0%

15,0%

Actual Threshold

Работа с рисками

Риск - фактор, который может привести в

будущем к негативным последствиям,

обычно выражается влиянием и

вероятностью

Оценка рисков

0,1 0,3 0,5 0,7 0,9

1 0,1 0,3 0,5 0,7 0,9

2 0,2 0,6 1 1,4 1,8

3 0,3 0,9 1,5 2,1 2,7

4 0,4 1,2 2 2,8 3,6

5 0,5 1,5 2,5 3,5 4,5

 

Реакция на риски

• Избежание (Avoid) – не делать то, что может привести

к возникновению риска

• Смягчение, сокращение (Mitigate) – проведение

мероприятий по сокращению влияния риска

• Принятие, удержание (Accept) – сохранение

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

• Передача (Transfer) – перевод ответственности за

риск другой стороне

Типичные риски

…

• Планирование

• Неправильное определение границ работ

• Неправильный выбор архитектуры

• Неправильная оценка ресурсов

• Организационные

• Частое и противоречивое изменение требований заказчиком

• Текучесть кадров

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

• Каждый тест должен быть связан с

требованием Каждое требование тестируемо и имеет тест

• Тестирование проводится планово

• Принцип Парето 20/80 Все проверить нельзя

• Начинать с малого и наращивать Взаимосвязь с другими тестами

• Независимо от разработчиков

• Не забыть о «подразумевающихся» и не

функциональных требованиях

Q & A