Файл: Обеспечения.pdf

24

возможные риски и пути их решения.
Более детально требования к содержанию плана тестирования изложены на рисунке 3.
Рис. 3. Структура плана тестирования по ГОСТ Р 56922—
2016/ISO/IEC/IEEE 29119- 3:2013
Атрибутами тест-плана являются:

Заголовок / версия / Автор,

Техническое задание на продукт или иная документация,

Задачи / функциональность, которая должна быть протестирована,

Виды проводимого тестирования,

Список тестовой документации (тест-кейсы, тест-сьюты),

Список инструментов тестирования,

25

Сервер (или иное расположение тестируемой программной системы),

Ответственные лица (ФИО/ Должность / занятие),

График тестирования,

Оценка риска,

Примечание.
Тест-сьют – группа тест-кейсов для проверки отдельного модуля или функциональности. Атрибутами тест-сьюта являются:

ID – идентификатор (уникальный в рамках компании),

Автор,

Приоритет выполнения,

Краткое описание,

Список тест-кейсов.
Пример тест-сьюта для приложения интернет-магазина:

TS #1: “Модуль авторизации” o
TC #1.1: “Авторизация пользователя” o
TC #1.2: “Восстановление пароля” o
TC #1.3: “Помощь” o
TC #1.4: …

TS #2: “Регистрация пользователя” o
TC #2.1: ...
Тестовый случай (Test Case) – совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или ее части. Атрибуты тест-кейса:

ID.

Дата.

Автор.

26

Заголовок / описание.
Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод об удовлетворении реализации поставленным требованиям.

Выполняемые шаги.

Приоритет выполнения.

Предусловия.
Список действий, которые приводят систему к состоянию, пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состоянии.

Постусловия. Список действий, переводящих систему в первоначальное состояние.

Дополнительные сведения.
Порядок создания тестовой документации определяется условиями реализации программных систем. Если к началу разработки существовала документация, описывающая требования, то создание тестовой документации должно опираться на эти требования и начинаться непосредственно после их выявления. Если программное обеспечение передается на доработку без какой-либо документации, или требования формализованы не полностью, то создание тестовой документации может быть проведено в режиме исследования.
Далее, применяя одну из техник тест-дизайна, нужно создать наборы тест-кейсов и сгруппировать их в тест-сьюты. Стоит контролировать заполнение обязательных атрибутов тестовой документации. Выполнение лабораторной работы не предусматривает использование какого-либо специального программного обеспечения для учета документации, будет достаточно любого текстового редактора. Но системы ведения тестовой документации могут значительно сокращать трудоемкость для

27 тестировщика, поскольку обладают возможностями ведения нескольких типов тестовой документации и выполнения манипуляций с ней в рамках процедур тестирования. В качестве примера можно привести сервисы и
ПО для тестовой документации: TestLink, TestRail, QA Touch. Примеры тестовой документации приведены в таблицах 1 и 2.
Таблица 1. Примеры оформления списка тест-сьютов
ID
Автор Приоритет
Заголовок
Список тест-кейсов
1 user
1
Модуль пользователя
1.1 Авторизация
1.2 Регистрация
1.3 Редактирование профиля
2 user
1
Модуль товаров
2.1 Получение новинок
2.2 Получение товаров в категории
2.3 Получение товара
3 user
1
Модуль корзины
3.1 Добавление товара в корзину
3.2 Увеличение количества товара в корзине
3.3 Уменьшение количества товара в корзине
4 user
1
Модуль оформления заказа
4.1 Оформление заказа
4.2 Оформление заказа
4.3 Оформление заказа
Таблица 2. Примеры оформления списка тест-кейсов
ID Описание
(Тип)
Предусловия
Шаги
Ожидаемый результат
1.1 Авторизация
(позитивный)
1. Пользователь находится на странице входа в личный кабинет
2. Пользователь был ранее зарегистрирован в системе
1. Ввести в поля «Логин» и
«Пароль» логин и пароль пользователя
2. Нажать кнопку «Войти»
1.
Пользователь перенаправляется на страницу личного кабинета
1.2 Регистрация
(негативный)
1. Пользователь находится на странице регистрации
2. Пользователь был ранее зарегистрирован в системе
1. Ввести в обязательные поля «Имя», «Фамилия»,
«Пароль», «Подтвердите пароль», «Электронная почта» данные. Также можно ввести данные в поля
«Номер телефона» и
«Адрес».
2. Нажать кнопку
«Зарегистрироваться»
1. Пользователь на странице регистрации получает сообщение
«Пользователь с таким email существует»

28
Продолжение таблицы 2
ID Описание (Тип)
Предусловия
Шаги
Ожидаемый результат
1.3 Редактирование профиля
(негативный)
1. Пользователь находится на странице личного кабинета
1. Нажать на пункт
«Профиль»
2. Получить страницу редактирования профиля
3. Нажать на кнопку
«Изменить»
4. Ввести в поля
«Пароль» и
«Подтвердите пароль» разные значения
5. Нажать на кнопку
«Сохранить»
1.
Пользователю отображается сообщение «Пароли не совпадают»
2.1 Получение новинок
(Позитивный)
1. Пользователь находится на одной из страниц магазина
1. Пользователь нажимает на название интернет-магазина, расположенного в шапке сайта
1.
Пользователю отображается главная страница магазина со списком новинок
2.2 Получение товаров в категории
(Позитивный)
1. Пользователь находится на одной из следующих страниц: на главной странице, на странице
«Корзина», на странице входа в личный кабинет, на странице регистрации, на странице каталога товаров, на странице товара
1. Нажать на пункт меню категорий
1.
Пользователь перенаправляется на страницу категорий
2.
На странице категорий отображается заголовок, совпадающий с названием ранее выбранного пункта меню
2.3 Получение товара
(Позитивный)
1. Пользователь находится на одной из следующих страниц: на главной странице, на странице
«Корзина», на странице категорий
2. На данной странице отображается товар
1. Нажать на кнопку
«Товар»
1.
Пользователь перенаправляется на страницу товара
2. Информация о товаре на странице товара должна совпадать с информацией на странице, с которой был осуществлен переход

29
Окончание таблицы 2
ID
Описани е (Тип)
Шаги
Ожидаемый результат
Ожидаемый результат
3.1
Добавле ние товара в корзину
(Позитив ный)
1. Пользователь находится на одной из следующих страниц: на главной странице, на странице категорий, на странице товара
2. На данной странице отображается товар
1.
Нажать на кнопку «Добавить в корзину»
1.
Страница, на которой находится пользователь, обновляется
2.
Пользователю отображается сообщение «Товар в корзину успешно добавлен»
3. При переходе на страницу «Корзина» отображается добавленный товар
3.2
Увеличен ие количест ва товара в корзине
(Позитив ный)
1. Пользователь находится на странице «Корзина»
1.
Нажать на кнопку «+»
1. В колонке «Кол- во» в строке товара увеличивается значение на 1 3.3
Уменьше ние количест ва товара в корзине
(Негатив ный)
1. Пользователь находится на странице «Корзина»
2. Значение в колонке «Кол- во» в строке товара равно 1 1.
Нажать на кнопку «-»
1. Значение в колонке
«Кол-во» в строке товара не изменяется
Задания к лабораторной работе
1. Выбрать веб-приложение для тестирования, согласовать с преподавателем.
2. Сформировать отчет с тестовой документацией: список тест-кейсов и тест-сьютов в соответствии с требованиями к атрибутам документации. Не нужно рассматривать функции авторизации / регистрации, поскольку они одинаковые для программных систем.
3. Требования к наличию тестов: smoke-тесты, тестирование навигации, тестирование ввода данных (как минимум две формы),

30 тестирование бизнес-логики. Обязательно сделать как позитивные, так и негативные тест-кейсы.
4. В отчет по лабораторной работе включить: a. Цель работы. b. Описание тестируемого приложения. c. Тестовую документацию. d. Выводы по работе. e. Список использованных источников.
5. Оформить и защитить отчет.
Контрольные вопросы
1. Приведите пример негативных тест-кейсов для трех видов тестирования.
2. Перечислите требования к тест-плану.
3. Перечислите требования к тест-сьютам.
4. Перечислите требования к тест-кейсам.
5. Какова связь этапа жизненного цикла разработки программного обеспечения и вида тестовой документации?

31
ЛАБОРАТОРНАЯ РАБОТА №4
Тема лабораторной работы: методы тест-дизайна.
Общие сведения по работе
Методы тест-дизайна упорядочивают деятельность по проектированию и созданию необходимых наборов тестов для контроля за качеством реализации программных продуктов. Основная задача при этом – минимизация количества тестов и количества их прогонов при максимизации контроля в условиях ограниченных временных, вычислительных и человеческих ресурсов. Частично требования к тест- дизайну изложены в требованиях к тестовой документации, стандартах процессов тестирования, требованиях к использованию инструментов тестирования, а также в описаниях этапов жизненного цикла разработки выбранной модели. В данной лабораторной работе необходимо сосредоточиться на задаче проектирования необходимого набора тест- кейсов для тестирования отдельной функциональности приложений, основываясь на анализе входной информации.
Методические рекомендации и материалы
Одной из проблем при создании набора тестов является разнообразие входных данных. Данные могут подавать на вход программной системы в разном сочетании, в разном объеме. Поэтому проектирование тестов должно учитывать и такие особенности.
Для минимизации выполняемых прогонов тестов применяют техники анализа эквивалентных классов, граничных значений. Сутью подходов является разделение всех подаваемых на вход данных на отдельные группы. Вся совокупность данных в пределах одной группы приводит к одной и той же реакции системы, в то время как данные из разных групп позволяют получить разный результат. Так, например, если тестируются

32 поля ввода текста и установлено ограничение на минимально допустимую длину текста, равное 5 символам, то ввод строк длиной 1,2,3 или 4 символов должен приводить к одной реакции системы – выводу ошибки.
Таким образом, эквивалентный класс – это набор данных или тестов, проверяющих один из вариантов реализации логики функционирования программной системы. Минимизация тестов, выполняемых над системой, достигается за счет использования только одного из значений из эквивалентного класса.
Другая проблема, которая требует рассмотрения – это тестирование поведения системы в граничных значениях эквивалентных классов.
Обосновывается эта проблема необходимостью контролировать покрытие всех возможных вариантов условными операторами (например, проверятся код: if (a.equals(“some_string”) в случаях a = null, a не содержит строку
“some_string”)), вариантов использования операторов сравнения (x > y или x ≥ y ?) в программном коде. Способом проконтролировать поведение программной системы в таких случаях является анализ эквивалентных классов и граничных между ними значений. Методика тестирования будет заключаться в определении отношения граничных значений к определенному эквивалентному классу. После этого производится выполнение тестов на значениях каждого класса, плюс выполняются прогоны тестов на граничных значениях и в некоторой близкой области к граничным значениям. Например, необходимо протестировать ввод целочисленного положительного числа при условии, что поведение алгоритма меняется при значении переменной, равном 7. Эквивалентные классы будут включать два интервала: [0, …, 7] и (7, …, ∞); При использовании методики тестирования граничных значений нужно выполнить тесты при значении переменной, равном:

значению из интервала [0, …, 7], например 3,

33

значению переменной, равном значению на границе классов, т. е. 7,

значениям переменной в области близкой к граничному значению
(т.к. число целое, то минимальный сдвиг от границы может дать значения, равные 6 и 8),

значению из интервала (7, …, ∞), например 9.
Методика тестирования предполагает использование всех перечисленных случаев, хотя очевидно, что значения 8 и 9 принадлежат одному классу и могут быть сведены только к одному значению.
Использовать или не использовать все указанные значения решают на основе данных: если сдвиг от граничных значений и выбор дополнительных значений эквивалентных классов помогут повысить вероятность локализации дефектов, то нужно использовать все изложенные варианты данных. В случае целочисленных данных, как в примере, сложно сказать, что поведение системы может измениться, поэтому список данных, используемых в тестировании, можно сократить.
Задания к лабораторной работе
1. Для одной из форм приложения выделить эквивалентные классы.
2. Сделать расчет количества тестов для проверки формы приложения с учетом требования минимизации количества проводимых тестов.
3. В отчет по лабораторной работе включить: a. Цель работы. b. Список используемых тест-кейсов. c. Описание эквивалентных классов. d. Расчет количества тестов. e. Выводы по работе. f. Список использованных источников.
4. Оформить и защитить отчет.

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

35
ЛАБОРАТОРНАЯ РАБОТА №5
Тема лабораторной работы: ручное тестирование
Общие сведения по работе
Работа предусматривает использование ранее созданной тестовой документации в тест-кейсах и тест-сьютах для контроля реализованной функциональности в программной системе. Ручное выполнение тест- кейсов может быть выполнено в зависимости от стадии разработки программного обеспечения (необходимая функциональность должна быть реализована) и является наиболее простым способом реализации процедуры тестирования как таковой. Другие подходы в виде реализации модульных тестов, реализации автотестов могут быть более трудоемкими и менее гибкими.
Методические рекомендации и материалы
Ручное функциональное тестирования подразумевает выполнение тестовых сценариев тестировщиком на специально подготовленном стенде.
Порядок проведения ручного тестирования описывается следующими шагами:
1. Анализ исходных документов с требованиями и описанием тестовых случаев.
2. Изучение тест-плана для уточнения сроков, объемов, видов тестирования, ответственных лиц, проводящих тестирование.
3. Выполнение требуемых тест-кейсов с учетом условий выполнения, шагов сценария, эталонных результатов. Ручное выполнение подразумевает взаимодействие тестировщика с элементами пользовательского интерфейса тестируемой программной системы.
Эталон необходимо сравнивать с полученным в программной системе результатом.

36 4. После завершения очередного прогона тест-кейса в отчете по тестированию фиксируются сведения о времени, идентификаторе соответствующего тест-кейса и общем результате: успешно или неуспешно. В случае неуспешного выполнения необходимо описать возникший дефект: на основании шагов и условий тестового сценария нужно описать расхождение в полученном и ожидаемом результате, прикрепить соответствующие дополнительные материалы (скриншоты, видео, логи, дампы) для лучшего понимания разработчиком возникшей проблемы и ускорения поиска путей ее решения.
Ручное выполнение тест-кейсов может быть проведено с использованием соответствующего программного обеспечения, в котором как хранятся сами тест-кейсы, так и организуется создание тест-планов и есть возможность поэлементного просмотра списка тест-кейсов в режиме выполнения.
Описание дефектов производится в соответствии со следующей структурой:

Краткое описание. Приводится текстовое описание дефекта. Главная цель – пояснить, уточнить особенности дефекта, которые не могут раскрыть остальные поля.

Серьезность. Отражает объем функциональности, которая не может быть использована из-за возникшего дефекта. Градация из значений – блокирующая (blocker), критическая (critical), значительная (major), незначительная (minor), тривиальная (trivial), предложение к улучшению (enhancement) – позволяет сделать вывод о том, насколько дефект затрагивает работу программной системы и может ли тестирование быть выполнено далее.