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

1.

Основы
тестирования.
Проектирование
тестов
Преподаватель: Колесников П.В.
г.Москва

2.

Тест - кейс
Статусы, отчет о тестировании, регрессионное и
смоук тестирование

3.

Тестовый случай (Test Case) — это артефакт, описывающий совокупность шагов,
конкретных условий и параметров, необходимых для проверки реализации
тестируемой функции или её части.
ТЕСТ КЕЙС (TEST CASE) – это комплекс исходных данных, условий и ожидаемых
результатов, разработанный с целью проверки требуемого свойства продукта.
Test cases, собранные в последовательность для достижения некоторой цели
образуют test suite (набор тестов).

4.

Зачем нужно написание
тест кейсов?
Найти проблемные места в требованиях.
Структурировать всю информацию
Ускорить регрессию
Хранить и собирать информацию.
Отслеживать процесс тестирования

5.

НАЗВАНИЯ АТРИБУТОВ ТЕСТ КЕЙСА
ID
Re
Priorit
q.
y
ID
Modu
le
SubModule
Test
description
Expecte
d
result
Res
ult
Comm
ent

6.

7.

Высокоуровневый тест-кейс — тест-кейс без конкретных входных данных и
ожидаемых результатов.
Низкоуровневый тест-кейс — тест-кейс с конкретными входными данными и
ожидаемыми результатами.
Спецификация тест-кейса — документ, описывающий набор тест-кейсов
(включая их цели, входные данные, условия и шаги выполнения,
ожидаемые результаты) для тестируемого элемента.
Спецификация теста — документ, состоящий из спецификации тестдизайна, спецификации тест-кейса (test case specification) и/или
спецификации тест-процедуры (test procedure specification).
Тест-сценарий (test scenario, test procedure specification, test script) —
документ, описывающий последовательность действий по выполнению
теста (также известен как «тест-скрипт»).

8.

Чек-листы — один из фундаментальных инструментов тестирования. Они позволяют
не забывать о важных тестах, фиксировать результаты своей работы и отслеживать
статистику о статусе программного продукта.
Иногда чек-листами называют подробные инструкции о тестируемом продукте,
содержащие последовательность действий, множество деталей и т.д. Это не так!
Главный принцип чек-листов заключается в том, что каждый тестировщик по-своему
проходит их, расширяя тестовый набор своей экспертизой.
Какие преимущества чек-листов по сравнению с тест-кейсами:
✓ нивелирование эффекта пестицида в регрессионном тестировании
✓ расширение тестового покрытия за счёт отличий при прохождении
✓ сокращение затрат на содержание и поддержку тестов: не надо писать много
буковок!
✓ отсутствие рутины, которую так не любят квалифицированные тестировщики
✓ возможность проходить и комбинировать тесты по-разному, в зависимости от
предпочтений сотрудников

9.

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

10.

Цель написания тест-кейсов:
1. Структурировать и систематизировать подход к тестированию (без чего крупный
проект почти гарантированно обречён на провал).
2. Вычислять метрики тестового покрытия (test coverage metrics) и принимать меры по
его увеличению (тест-кейсы здесь являются главным источником информации, без
которого существование подобных метрик теряет смысл).
3. Отслеживать соответствие текущей ситуации плану (сколько примерно понадобится
тест-кейсов, сколько уже есть, сколько выполнено из запланированного на данном
этапе количества и т.д.).
4. Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками
(тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем
это отражено в требованиях)..
5. Хранить информацию для длительного использования и обмена опытом между
сотрудниками и командами (или, как минимум, не пытаться удержать в голове сотни
страниц текста).
6. Проводить регрессионное тестирование и повторное тестирование (которые без тесткейсов было бы вообще невозможно выполнить).
7. Повышать качество требований (написание чек-листов и тест-кейсов — хорошая
техника тестирования требований).
8. Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту.

11.

12.

13.

Общие рекомендации по написанию:
Начинайте с понятного и очевидного места, не пишите лишних начальных шагов
(запуск приложения, очевидные операции с интерфейсом и т.п.).
• Даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность
в будущем случайно «приклеить» описание этого шага к новому тексту).
• Если вы пишете на русском языке, то используйте безличную форму (например,
«открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»), в
английском языке не надо использовать частицу «to» (т.е. «запустить приложение»
будет «start application», не «to start application»).
• Соотносите степень детализации шагов и их параметров с целью тест-кейса, его
сложностью, уровнем и т.д. В зависимости от этих и многих других факторов степень
детализации может варьироваться от общих идей до предельно чётко прописанных
значений и указаний.
• Ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста
(например, «повторить шаги 3–5 со значением…»).
• Пишите шаги последовательно, без условных конструкций вида «если… то…».

14.

15.

Набор изолированных свободных тест-кейсов: действия из раздела «приготовления»
нужно повторять перед каждым тест-кейсом, а сами тест-кейсы можно выполнять в
любом порядке.
Набор обобщённых свободных тест-кейсов: действия из раздела «приготовления»
нужно выполнить один раз (а потом просто выполнять тест-кейсы), а сами тест-кейсы
можно выполнять в любом порядке.
Набор изолированных последовательных тест-кейсов: действия из раздела
«приготовления» нужно повторять перед каждым тест-кейсом, а сами тест-кейсы нужно
выполнять в строго определённом порядке.
Набор обобщённых последовательных тест-кейсов: действия из раздела
«приготовления» нужно выполнить один раз (а потом просто выполнять тест-кейсы), а
сами тест-кейсы нужно выполнять в строго определённом порядке.

16.

Подходы к составлению наборов тест-кейсов:
•На основе чек-листов.
•На основе разбиения приложения на модули и подмодули. Для каждого модуля
(или его отдельных подмодулей) можно составить свой набор тест кейсов.
•По принципу проверки самых важных, менее важных и всех остальных функций
приложения.
•По принципу группировки тест-кейсов для проверки некоего уровня требований
или типа требований, группы требований или отдельного требования.
•По принципу частоты обнаружения тест-кейсами дефектов в приложении
(например, мы видим, что некоторые тест-кейсы раз за разом завершаются
неудачей, значит, мы можем объединить их в набор, условно названный
«проблемные места в приложении»).
•По архитектурному принципу: наборы для проверки пользовательского
интерфейса и всего уровня представления, для проверки уровня бизнес-логики,
для проверки уровня данных.
•По области внутренней работы приложения, например, «тест-кейсы,
затрагивающие работу с базой данных», «тест-кейсы, затрагивающие работу с
файловой системой», «тест-кейсы, затрагивающие работу с сетью».
•По видам тестирования.

17.

18.

19.

Тест-кейс
№1.
Корректный
Номер
1
Заголовок
Отправка сообщения через форму обратной связи на странице
“Контакты”
Предусловие
Открыта главная страница сайта avtozx.ru. Есть доступ к почте
администратора сайта avtorzx.ru
Шаг
Ожидаемый результат
В верхнем меню сайта нажать на ссылку “Контакты”
Открылась страница “Контакты”
Ввести значение в поле “Ваше имя” состоящее из латинских букв,
кириллицы
В поле “Ваше имя” отображается введённое имя
Ввести корректный email в поле “Ваш e-mail”
В поле “Ваш e-mail” отображается введённый email
Ввести в поле “Тема” значение состоящее из латинских букв,
кириллицы, спецсимволов и чисел
В поле “Тема” отображается введённый текст
Ввести в поле “Сообщение” значение состоящее из латинских
букв, кириллицы, спецсимволов и чисел
В поле “Сообщение” отображается введённый текст
Ввести в поле капчи требуемое капчей значение
В поле капчи отображается введённое значение
Нажать под заполняемой формой на кнопку “Отправить”
Под кнопкой «Отправить» появился текст “Спасибо. Ваше
сообщение было отправлено.”
Все заполненные поля очищены.
Проверить почту администратора сайта
На почту пришло сообщение, отправленное с сайта через форму
обратной связи и содержащее в теле сообщения данные
введённые на шагах 1-5.

20.

Тест-кейс №2.
Некорректный
Номер
1
Заголовок
Отправить сообщение через форму
обратной связи (Указываем, что проверяем
или что делаем?)
Предусловие
Перейти на главную страницу сайта avtozx.ru
(Это не предусловие, а описание шага)
Шаг
Ожидаемый результат
Нажать на ссылку “Контакты” (Где она
находится?)
Открылась страница (Какая?)
Ввести имя в поле “Ваше имя” (Какие
символы вводить?)
(Ничего не указано в ожидаемом
результате, что должно произойти?)
Ввести email в поле “Ваш e-mail”
(корректный или некорректный?)
В поле отображается email (Какой?
Введённый? В каком поле отображается?)
Ввести в поле значение, состоящее из
латинских букв, кириллицы, спецсимволов и
чисел (В какое поле?)
В поле “Тема” отображается текст (Какой?)
Ввести в поле “Сообщение” текст (Какие
символы вводить?)
Видим в поле “Сообщение” введённый
текст (Видим или отображается?)
Вводим в поле капчи требуемое капчей
значение (Помните только безличные
глаголы — Ввести).
В поле капчи будет введённое значение (Что
будет делать? Танцевать?)
Нажать под заполняемой формой на кнопку
(На какую?)
Появился текст “Спасибо. Ваше сообщение
было отправлено.” (Где появится?)
(Последний шаг не заполнен, а это
неправильно, так как мы не проверим
действительно ли работает отправка писем
через форму обратной связи)

21.

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

22.

Чего не должно быть в тест-кейсе
1. Зависимостей от других тест-кейсов;
2. Нечеткой формулировки шагов или ожидаемого результата;
3. Отсутствия необходимой для прохождения тест-кейса информации;
4. Излишней детализации.
Что еще необходимо знать, перед созданием тест-кейса?
Во-первых, каждый выполненный тест-кейс, дает нам один из трех результатов:
1.Положительный результат, если фактический результат равен ожидаемому
результату,
2.Отрицательный результат, если фактический результат не равен ожидаемому
результату. В этом случае, найдена ошибка.
3.Выполнение теста блокировано, если после одного из шагов продолжение теста
невозможно. В этом случае так же, найдена ошибка.
Во-вторых, одним тест-кейсом проверяется одна конкретная вещь, и для этой вещи
должен быть только один ожидаемый результат.

23.

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

24.

Селен: Это инструмент с открытым исходным кодом, который может
автоматизировать веб-приложения и доступен на различных языках
программирования, таких как Java, Python, C #, Ruby и javascript.
HP QTP (UFT): Это лицензированный инструмент HP, который может
автоматизировать функциональное и регрессионное тестирование как вебприложений, так и настольных приложений.
Тест завершен: Это открытая тестовая платформа, которая помогает легко и
эффективно создавать автоматизированные тесты для настольных компьютеров,
Интернета, мобильных устройств и нескольких устройств.
Роботиум: Это известный фреймворк для автоматизации тестирования Android. Он
работает с собственными и гибридными приложениями и помогает писать
автоматизированные сценарии функционального тестирования.

25.

Смоук-тестирование — первый этап исследований программного обеспечения (ПО)
после его создания или модернизации. Цель проверки — изучение
работоспособности системы, корректности отклика и обработки данных.
Smoke-тесты короткого цикла направлены на выявление критических дефектов,
которые в дальнейшем могут спровоцировать архитектурные ошибки и
серьезные поломки оборудования.

26.

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