Разработка через тестирование. Примеры

1. Лекция № 4

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Лекция № 4
Тема 2. Разработка через тестирование. Примеры.

2. Модульное тестирование

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Модульное тестирование
Модульное тестирование, или юниттестирование (англ. unit testing) — процесс
в программировании, позволяющий проверить на
корректность отдельные модули исходного кода
программы.
Идея состоит в том, чтобы писать тесты для каждой
нетривиальной функции или метода. Это позволяет
достаточно быстро проверить, не привело ли
очередное изменение кода к регрессии, то есть к
появлению ошибок в уже оттестированных местах
программы, а также облегчает обнаружение и
устранение таких ошибок.
2

3. Концепция модульных тестов

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Концепция модульных тестов
Unit testing (юнит тестирование или модульное
тестирование) — заключается в изолированной
проверке каждого отдельного элемента путем
запуска тестов в искусственной среде. Для этого
необходимо использовать драйверы и заглушки.
Оценивая каждый элемент изолированно и
подтверждая корректность его работы, точно
установить проблему значительно проще чем, если
бы элемент был частью системы.
3

4. Элементы unit тестирования

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Элементы unit тестирования
Unit (Элемент) — наименьший компонент, который
можно скомпилировать.
Драйверы — модули тестов, которые запускают
тестируемый элемент.
Заглушки — заменяют недостающие компоненты,
которые вызываются элементом.
4

5. Заглушка (stub)

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Заглушка (stub)
Фиктивная подпрограмма, имитирующая одну или несколько
функций отсутствующего модуля программного изделия.
Обычно имеет точку входа и точку выхода. Используется, как
правило, при нисходящем тестировании.
• возвращаются к элементу, не выполняя никаких других
действий;
• отображают трассировочное сообщение и иногда предлагают
тестеру продолжить тестирование;
• возвращают постоянное значение или предлагают тестеру
самому ввести возвращаемое значение;
• осуществляют упрощенную реализацию недостающей
компоненты;
• имитируют исключительные или аварийные условия.
5

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

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Изоляции в тестировании
Идея изоляции является одной из центральных в
модульном тестировании.
Изоляция позволяет тестировать разрабатываемые
классы в момент, когда другие подсистемы еще не
созданы, когда некоторые сервисы, которые будут
использоваться в продукционной среде, еще не
доступны и т.д.
6

7. Мок обьекты

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Мок обьекты
Для изолирования используют паттерн Mock_Object (в
виде заглушек, созданных вручную или
автоматически генерируемых).
Мок-объекты передаются в тестируемый код и
полностью эмулирует работу другого класса, который
должен был бы использоваться в тестируемом коде
при реальном использовании.
7

8. Внедрение Мок объектов в код

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Внедрение Мок объектов в код
Базовые принципы, на которых основывается внедрение мокобъектов в тестовый код - это Инверсия зависимостей
(Dependency Inversion) или Внедрение зависимостей
(Dependency Injection).
Общая суть применения принципов инверсии зависимостей
сводится к следующему - взаимодействия внутри системы
начинают строиться на основе интерфейсов, а не классов.
Классы как бы отказываются от знаний, кому именно они
делегируют обязанности. Для них становится важным
только то, чтобы делегируемые «умели» что-то делать, кто
они именно такие при этом - неважно.
8

9. Инверсия управления

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Инверсия управления
(Inversion of Control, IoC) — важный принцип объектноориентированного программирования, используемый
для уменьшения связанности в компьютерных
программах.
9

10. Техники реализации инверсии управления

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Техники реализации инверсии управления
• Фабричный метод (англ. Factory pattern)
• Service locator (англ. Service locator pattern)
• Внедрение зависимости (англ. Dependency injection)
– Через метод класса (англ. Setter injection)
– Через конструктор (англ. Constructor injection)
– Через интерфейс внедрения (англ. Interface
injection)
10

11. Пример инверсии управления

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Пример инверсии управления
Представьте себе, что имеется программа, которая получает некоторую
информацию от пользователя с помощью командной строки:
var info=new InfoAboutPeople() ;
var tmp="";
Console.WriteLine(“ФИО?”);
Console.ReadLine(tmp );
Info.SetFio(tmp);
Console.WriteLine(“Дата рождения?”);
Console.ReadLine(tmp);
Info.SetBirthDay(tmp);
RegisterClient(info);
В этой ситуации код управляет исполнением: он решает, когда задавать
вопросы, когда считывать ответы, а когда обрабатывать результаты.
11

12.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Если бы использовалась оконная система
для похожей задачи, то необходимо было
бы использовать элементы, которые
работают с окном.
Теперь между этими двумя программами
большая разница в потоке управления
— в частности, в управлении временем,
когда вызываются методы Info.SetFio(tmp), Info.SetBirthDay(tmp),
RegisterClient(info).
Контроль вызова методов передаётся оконной системе. Далее она
решает, когда вызвать методы, основываясь на связях, которые
настроены при создании формы. Управление инвертировано —
управляют кодом, а не код управлет фреймворком.
Это явление и ещё известно как Принцип Голливуда —
«Не звони нам, мы сами позвоним тебе» — Hollywood Principle —
«Don't call us, we'll call you»
12

13. Фабричный метод

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Фабричный метод
Фабричный метод (англ. Factory Method) — порождающий
шаблон проектирования, предоставляющий подклассам
интерфейс для создания экземпляров некоторого класса. В
момент создания наследники могут определить, какой
класс создавать.
Иными словами, Фабрика делегирует создание объектов
наследникам родительского класса. Это позволяет
использовать в коде программы не специфические классы,
а манипулировать абстрактными объектами на более
высоком уровне.
13

14. Service locator

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Service locator
Паттерн Service locator представляет собой
хранилище сервисных объектов. Фактически это
некоторого рода ассоциативный массив с
экземплярами объектов-реализаций, которые
определяются по ключу – типу или имени
интерфейса.
14

15. Передача зависимого объекта через конструктор. Constructor Injection

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Передача зависимого объекта через конструктор.
Constructor Injection
Инъекция с помощью конструктора использует конструктор
для ассоциирования объекта с конкретными реализациями
абстракций. При использовании этого типа инверсии
зависимостей, необходимые объекты передаются в
конструктор, в качестве аргументов.
Одно из достоинств Constructor injection заключается в том,
что все зависимости класса прописываются явно. То есть,
взглянув на один лишь конструктор класса, мы уже
понимаем, какими ресурсами остальной системы он
пользует.
15

16. Setter Injection

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Setter Injection
Инъекция при помощи set-метода требует определения
отдельного set-метода для каждого из инъецируемых
объектов. От предыдущего типа инъекции она
отличается местом инъецирования.
16

17.

Interface Injection
Interface injection использует интерфейсы для осуществления связывания
объектов.
Во-первых, задаются интерфейсы, которые определяют методы для
связывания. Один интерфейс на каждую зависимость.
Зависимый объект должен
реализовывать все эти
interface injectReader
интерфейсы.
{
void injectReader(IReader obj);
class Copier: injectReader, injectWriter...
}
public void injectReader(IReader obj)
interface injectWriter
{
{
reader = obj;
void injectWriter(IWriter obj);
}
}
public void injectWriter(IWriter obj)
{
writer = obj;
}
17
}

18. Interface Injection

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Interface Injection
Определяется также единый интерфейс для всех сервисов:
interface Injector
{
public void inject(object obj);
}
Каждый сервис реализует этот интерфейс таким образом, чтобы внедрить
себя в зависящий объект:
class keyboardReader: Injector...
public void inject(object obj)
{
if ( obj is injectReader )
{
throw new typeException(obj);
}
obj.injectReader(this);
}
}
Таким образом, сервисы сами
внедряют себя в зависимый
объект
посредством
установленного интерфейса:
reader = new keyboardReader();
writer = new stdoutWriter();
copier = new copier();
reader->inject(copier);
writer->inject(copier);
18

19. Пример выделения тестовых случаев.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Пример выделения тестовых случаев.
Система рассылки массовых информационных сообщений
выпускникам факультета должна формировать список рассылки на
основе указанного файла Excel и применять к нему специфические
фильтры (дата рождения, пол, специальность и т.п.).

20.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Тестовые требования
Необходимо определить тестируемую область системы
- указать часть проектной документации, исходных
текстов, исполняемого кода, подвергаемых
тестированию с указанием типа тестированию
(автоматизированные тесты, формальные инспекции,
тестирование на моделях, полунатурные испытания и
т.п.). Необходимо зафиксировать тестируемые аспекты
и не тестируемые аспекты.

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

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Тестовые требования.
Тестирование производится с точки зрения конечного пользователя, и
разработанные тесты могут быть использованы для приёмочного тестирования.
Тестируемые аспекты.
В рамках данного плана предполагается выполнить функциональное
тестирование ПО в режимах генерации списка получателей, формирования
сообщений и отправки писем.
Также предполагается провести модульное тестирование класса Recipient,
который отвечает за хранение и преобразование информации о получателе
писем.
Нетестируемые аспекты.
В рамках данного плана не предполагается выполнять:
Функциональное тестирование системы в режиме аутентификации
пользователя и проверки количества реально отправленных писем.
Нефункциональное тестирование, в том числе нагрузочное тестирование,
тестирование производительности, тестирование удобства использования
(usability).
Тестирование будет проводится с использованием системы
автоматизированного тестирования TestComplete, а также интегрированных в
среду разработки Microsoft Visual Studio юнит-тестов.

23. Описание вариантов использования

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Описание вариантов использования
Описать роли пользователей в зависимости от уровня доступа и
действий, которые они могут выполнять в системе. В процессе
тестирования, описанные здесь варианты использования,
позволяют проще оценить точность реализации требований
пользователей и провести пошаговую проверку этих требований.
Стратегия использования прецедентов при определении
требований определяет необходимость дополнительно к вопросу
"что пользователи ждут от системы?" задавать вопрос "что система
должна сделать для конкретного пользователя?". Такой подход
позволяет искать функции, которые нужны многим пользователям,
и исключать те возможности, которые не могут помочь
пользователям выполнять свои повседневные задачи.

24. Описание вариантов использования.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Описание вариантов использования.
Для более полного покрытия тестовых случаем
рассмотрим диаграмму вариантов использования, которая
представлена на рисунке 1 для системы рассылки
массовых информационных сообщений выпускникам
факультета.
У тестируемого программного обеспечения можно
выделить три основных режима функционирования –
работа с файлами адресов рассылки, формирование
наполнения рассылки и, непосредственно, отправка писем
указанным адресатам. И два вспомогательных –
авторизация и ведения отчёта отправки.

25.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Рисунок 1 – Диаграмма вариантов использования программного обеспечения
автоматизированной рассылки информационных сообщений выпускникам факультета.

26. Объекты тестирования для каждой роли пользователя

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Объекты тестирования для каждой роли пользователя
Содержит список тех объектов (Use-Case-ов,
функциональных требований, нефункциональных
требований), которые были определены в качестве
объектов тестирования. Этот список показывает то, что
будет протестировано.

27. Объекты тестирования для каждой роли пользователя.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Объекты тестирования для каждой роли пользователя.
В результате проведенного анализа диаграммы вариантов
использования
были
выделены
следующие
варианты
использования, которые требуют дополнительного тестирования:
• Авторизация.
• Формирование списка рассылки:
– выбор файла БД;
– выбор столбцов;
– добавление фильтров.
• Ввод заголовка сообщения.
• Ввод тела сообщения.
• Работа с вложениями.
• Отправка писем.
• Автоподстановка шаблонов.
• Отправка, начиная с указанного получателя.
• Формирование и сохранение отчёта об отправке.
• Класс Recipient.

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

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Стратегия тестирования
Главными вопросами тестовой стратегии являются
техники тестирования, которые будут использоваться, и
критерий, по которому можно было бы определить, что
тестирование завершено. Стратегия тестирования
определяется исходя из вида тестирования.
Необходимо дать описание подходов к тестированию
(unit тестов, тестирования с помощью Test Complete,
системы отслеживания ошибок (bug tracking) и прочих
специальных средств тестирования), которые будут
применяться в ходе проведения тестирования – в рамках
одного тестового плана следует придерживаться общих
методик тестировании системы. Описать насколько
подробно будет тестироваться система и её компоненты.

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

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Стратегия тестирования
Уровни тестирования:
Системное, с точки зрения конечного пользователя для тестирования
вариантов использования ПО. Стратегия тестирования – методом «чёрного
ящика».
Модульное тестирование (для проверки методов разработанного класса
Recipient) с точки зрения разработчика-программиста, который использует
данный класс. Стратегия тестирования – методом «белого ящика».
Специальные средства тестирования:
Тестирование будет производиться при помощи TestComplete и
встроенных в Microsoft Visual Studio Unit-тестов. Некоторые тесты будут
проводиться вручную.
Требования к окружению:
Для выполнения тестов требуется установленный TestComplete версии 7
или выше, также для выполнения некоторых тестов необходим доступ к
интернету с открытыми портами для отправки электронной почты, для
функционирования тестируемой системы необходим установленный Microsoft
Office 2003 и .NET Framework 3.5 и выше.

30. Разработка позитивных и негативных тестовых случаев (test case).

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Разработка позитивных и негативных тестовых
случаев (test case).
Основное требование к контрольному примеру –
описание проверки четко определенной
самостоятельной части функциональности (или
свойств) программного обеспечения и ожидаемых
результатов. В общем случае, один контрольный
пример соответствует одному варианту использования
[58].

31. Разработка контрольных примеров тестирования (test case).

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Разработка контрольных примеров тестирования (test case).
Тестовый случай (Test Case) описывает совокупность шагов, конкретных условий и
параметров, необходимых для проверки реализации тестируемой функции или её
части.
Выделим тестовые случаи на основе анализа объектов тестирования для системного
тестирования (выделены на основе анализа диаграммы use-case):
1.Проверка авторизации пользователя – логин и пароль пользователя должны быть
введены, при подключении к smtp серверу ответ должен быть положительным.
2.Проверка формирования списка рассылки – контролируется корректная загрузка и
анализ excel файла списка получателей, автоматический выбор столбцов по
заголовку, а также изменение заголовков, проверка установки фильтров.
3.Проверка контроля ввода заголовка сообщения – заголовок сообщения не должен
быть пустым.
4.Проверка ввода тела сообщения – тело сообщения не должно быть пустым и может
содержать управляющие символы перехода на новую строку, а также шаблоны,
которые будут заменены при автоподстановке.
5.Проверки управления вложениями – контролируется возможность добавлять и
удалять файлы вложения к формируемой рассылке.
6.Проверка отправки писем – тестируется возможность отправки писем через
указанный smtp сервер выбранным получателям (для успешного прохождения
данного тект-кейса необходимо интернет подключение с открытыми портами).

32.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
7.Контроль автоподстановки шаблонов – проверка автоматической замены шаблонов в
теле сообщения на соответствующие значения из списка получателей (подстановка
имён и мужского/женского склонения).
8.Контроль отправки писем с указанного получателя – проверка возможности указать из
списка получателей адрес, с которого необходимо продолжить отправку, а также
контроль того, что отправка началась именно с данного получателя.
9.Проверка формирования и сохранения отчёта об отправке – отчёт об отправке должен
содержать подробную информацию о совершаемой рассылке – дату и время, текст
сообщения, адреса получателей, результат успешности отправки письма каждому из
адресатов.
10.Модульное тестирование класса Recipient. Проверка функционированеия всех методов
данного класса. Основное внимание уделить трём свойствам: sex, FIO и emails.
Остальные свойства просто не должны самостоятельно изменять своего значения.
Свойства sex, FIO и emails изменяются по следующим правилам:
a.При тестировании свойства sex производится анализ отчества по окончанию записи.
Если свойство FIO заканчивается на *вич, то свойство sex, возвращает строку «М», если
свойство FIO заканчивается на *вна, то свойство sex, возвращает строку «Ж», в
противном случае возвращает строку "не установлен".
b. При тестировании свойства FIO необходимо проверить, чтобы установленное свойство
всегда возвращала строку, все слова в которой начинаются с большой буквы.
c.При тестировании свойства emails необходимо проверить, чтоб строка, разделённая
разделителями типа точки, точки с запятой или пробелами разбивалась на массив строк
адресов получателя.

33. Описание корректных и некорректных тестовых данных для каждого тестового случая.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Описание корректных и некорректных тестовых
данных для каждого тестового случая.
Тестовые случаи разделяются по ожидаемому
результату на позитивные и негативные.
Позитивный тестовый случай использует только
корректные данные и проверяет, что приложение
правильно выполнило вызываемую функцию.
Негативный тестовый случай оперирует как
корректными, так и некорректными данными (минимум
1 некорректный параметр) и ставит целью проверку
исключительных ситуаций (срабатывание
валидаторов), а также проверяет, что вызываемая
приложением функция не выполняется при
срабатывании валидатора.

34. Описание корректных и некорректных тестовых данных для каждого контрольного примера тестирования.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Описание корректных и некорректных тестовых данных для
каждого контрольного примера тестирования.
В таблице 1 представлен тестовый набор корректных и не корректных данных для
каждого тестового случая.
Таблица 1 – Тестовый набор данных
Контрольный пример
A.1. Проверка авторизации
пользователя
A.2. Проверка формирования
списка рассылки
A.3. Проверка контроля ввода
заголовка сообщения
A.4. Проверка ввода тела
сообщения
A.5. Проверки управления
вложениями
A.6. Проверка отправки писем
Корректные данные
Логин: «Vasya»
Пароль: «Passw»
Не корректные данные
Логин: пустое поле или не
зарегестрированный пользователь
Пароль: пустое поле
Существующий файл Excel,
Некорректное имя файла, пустой
который содержит в себе заголовки файл или указанные заголовки не
и более одной записи.
соответствуют содержимому.
Заголовок: «План мероприятий
Заголовок: ничего не введено
празднования дня ХАИ»
Тело сообщения:
Тело сообщения:
Здравствуйте <FIO>
ничего не введено
Высылаем Вам пробное письмо!
С уважением мы )))
Указываются существующие
Указаны несуществующие файлы
файлы к которым есть права
или файлы с закрытым уровнем
доступа чтения.
доступа.
Произведена авторизация,
Любое из перечисленных полей не
сформирован список получателей, заполнено или введены не
заполнены заголовок и тело
корректные данные авторизации.
сообщения.

35.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Контрольный пример
Корректные данные
A.7. Контроль автоподстановки Тело сообщения:
шаблонов
Здравствуйте <FIO>
Высылаем Вам пробное письмо!
С уважением мы )))
A.8. Контроль отправки писем
с указанного получателя
Выбран любой получатель из
сформированного списка
получателей.
A.9. Проверка формирования и Для сохранения указана
сохранения отчёта об отправке локальная папка и введено
корректное имя файла.
Не корректные данные
Тело сообщения:
Здравствуйте <тут хачу шоб
было его фио>
Высылаем Вам пробное письмо!
С уважением мы )))
–
Путь к сохраняемому файлу
отчёта задан некорректно или
нет прав доступа к сохранению в
данной папке.
A.10. Проверка полового
a.Поле FIO принимает значение a.Поле FIO принимает значение
признака записи по окончанию строки, которая оканчивается на строки, которая не заканчивается
фамилии
вич или на вна.
на вич или на вна.
b.Поле FIO содержит в себе хотя b. Поле FIO пустое.
бы одно слово.
c.Поле EMail содержит один или c. Поле EMail пустое или
несколько адресов электронной содержит только разделители.
почты, раделённых запятой,
точкой с запятой или пробелами.

36. Условия, при которых каждый тест кейс должен быть проверен.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Условия, при которых каждый тест кейс должен быть
проверен.
Каждый тест кейс должен иметь 3 части:
Предусловия – список действий, которые приводят систему к
состоянию пригодному для проведения данного теста; либо список
условий, выполнение которых говорит о том, что система
находится в пригодном для проведения основного теста
состояния.
Описания теста – список действий, переводящих систему из
одного состояния в другое, для получения результата, на
основании которого можно сделать вывод об удовлетворении
реализации, поставленных требований.
Постусловия – список действий, переводящих систему в
первоначальное состояние (состояние до проведения теста - initial
state).

37. Критерии прекращения тестирования.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Критерии прекращения тестирования.
Определить метрики измерения полноты тестируемого функционала
системы:
• Тестовое Покрытие
• Детализация Тест Кейсов
• Время Прохождения Тест Кейса
Существует 2 широко применяемых подхода к оценке и измерению
тестового покрытия:
• Покрытие требований
• Покрытие кода
Примеры критериев окончания тестирования:
• результаты тестирования удовлетворяют критериям качества
продукта;
• требования к количеству открытых багов выполнены;
• выдержка определенного периода без изменения исходного кода
приложения Code Freeze (CF);
• выдержка определенного периода без открытия новых багов Zero
Bug Bounce (ZBB).

38. Условия, при которых каждый тест кейс должен быть проверен.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Условия, при которых каждый тест кейс должен быть проверен.
Позитивный тестовый случай для теста Проверка формирования списка рассылки
Название:
Функция:
Действие
A.2. Проверка формирования списка рассылки
Формирование списка получателей
Ожидаемый результат
Предусловие:
Подготовьте файл со списком получателей.
Excel файл адресатов расположен на вашем локальном компьютере.
Запустите систему рассылки
ПО запущено. Открыта главная форма.
Шаги теста:
Нажмите на кнопку «Добавить адресатов»
Открылась форма загрузки списка получателей.
Укажите подготовленный excel файл, который содержит Список получателей загрузился в таблицу
список получателей с адресами и ФИО
Проверьте соответствие указанных заголовков и
колонкам в файле.
Все заголовки были определены верно
В выпадающем списке фильтров специальностей
установите фильтр по специальности «Программная
инжинерия»
Фильтр установлен. В таблице получателей остались подписчики,
соответствующие данному фильтру.
Установите флажок «День рождения в диапазоне»
Флажок установился, а поля ввода даты стали активными.
Укажите диапазон дня рождения от 21 марта 2011 года
до 27 марта 2011 года.
Фильтр даты рождения установлен. В таблице получателей
остались только те, у кого день рождение попадает с 21 по 27 марта,
год игнорируется.
Форма загрузки получателей закрылась. Произошёл возврат на
главную форму. На главной форме в поле «Кому» указано
количество отфильтрованных получателей.
Нажмите кнопку «Сформировать список»
Постусловие:
Закройте ПО
ПО закрылось без ошибок.
Результат
теста:

39.

Позитивный тестовый случай для теста
Контроль полового признака записи по окончанию фамилии
Название:
Функция:
Действие
Предусловие:
Создайте объект
Recipient target = new Recipient();
A.10.a Проверка полового признака записи по
окончанию фамилии
Половая принадлежность
Ожидаемый результат
Результат
теста:
Объект создан.
Исключений не возникало.
Шаги теста:
Задайте свойство FIO объекта
target
target.FIO = "Петр Иванович";
Поле установлено.
Исключений не возникало.
Проанализуруйте значение
свойства sex у объекта target
target.sex
приняло значение «М»
Постусловие:
Укажите пустую ссылку на объект Исключений не возникло.
target=null

40.

Позитивный тестовый случай для теста
Контроль нормализации поля ФИО
A.10.b Контроль нормализации поля ФИО
Название:
Функция:
Действие
Нормализация ФИО
Ожидаемый результат
Предусловие:
Создайте объект
Recipient target = new Recipient();
Объект создан.
Исключений не возникало.
Шаги теста:
Задайте свойство FIO объекта target
target.FIO = "пЁтр иванОвич";
Поле установлено.
Исключений не возникало.
Проанализуруйте значение свойства sex target.FIO
у объекта target
приняло значение «Петр Иванович»
Постусловие:
Укажите пустую ссылку на объект
target=null
Исключений не возникло.
Результат
теста:

41.

Позитивный тестовый случай для теста
Контроль разбиения электронных адресов
A.10.b Контроль разбиения электронных адресов
Название:
Функция:
Действие
Разбиение электронных адресов
Ожидаемый результат
Предусловие:
Создайте объект
Recipient target = new Recipient();
Объект создан.
Исключений не возникало.
Шаги теста:
Задайте свойство FIO объекта target Поле установлено.
target.Email =
Исключений не возникало.
"[email protected];
[email protected], [email protected]";
Проанализуруйте значение свойства target.emails приняло значение
sex у объекта target
{"[email protected]”,
“[email protected]”, “[email protected]”}
Постусловие:
Укажите пустую ссылку на объект
Исключений не возникло.
target=null
Результат
теста:

42.

ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Спасибо за внимание