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

ОБЕСПЕЧЕНИЯ

отдельные модули исходного кода программы.

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

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

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

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

модули тестов, которые запускают тестируемый элемент.

Заглушки — заменяют недостающие компоненты, которые вызываются элементом.

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

изделия. Обычно имеет точку входа и точку выхода. Используется, как правило, при нисходящем тестировании.

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

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

Изоляция позволяет тестировать разрабатываемые классы в момент, когда другие подсистемы еще не созданы, когда некоторые сервисы, которые будут использоваться в продукционной среде, еще не доступны и т.д.

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

или автоматически генерируемых).

Мок-объекты передаются в тестируемый код и полностью эмулирует работу другого класса, который должен был бы использоваться в тестируемом коде при реальном использовании.

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

в тестовый код - это Инверсия зависимостей (Dependency Inversion) или Внедрение зависимостей (Dependency Injection).

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

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

используемый для уменьшения связанности в компьютерных программах.

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

Service locator pattern)
Внедрение зависимости (англ. Dependency injection)
Через метод класса (англ. Setter injection)
Через конструктор (англ. Constructor injection)
Через интерфейс внедрения (англ. Interface injection)

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

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

var info=new InfoAboutPeople() ;
var tmp="";
Console.WriteLine(“ФИО?”);
Console.ReadLine(tmp );
Info.SetFio(tmp);
Console.WriteLine(“Дата рождения?”);
Console.ReadLine(tmp);
Info.SetBirthDay(tmp);
RegisterClient(info);

В этой ситуации код управляет исполнением: он решает, когда задавать вопросы, когда считывать ответы, а когда обрабатывать результаты.

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

бы использовать элементы, которые работают с окном.
Теперь между этими двумя программами большая разница в потоке управления — в частности, в управлении временем,

когда вызываются методы Info.SetFio(tmp), Info.SetBirthDay(tmp), RegisterClient(info).
Контроль вызова методов передаётся оконной системе. Далее она решает, когда вызвать методы, основываясь на связях, которые настроены при создании формы. Управление инвертировано — управляют кодом, а не код управлет фреймворком.

Это явление и ещё известно как Принцип Голливуда —
«Не звони нам, мы сами позвоним тебе» — Hollywood Principle — «Don't call us, we'll call you»

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

подклассам интерфейс для создания экземпляров некоторого класса. В момент создания наследники могут определить, какой класс создавать.
Иными словами, Фабрика делегирует создание объектов наследникам родительского класса. Это позволяет использовать в коде программы не специфические классы, а манипулировать абстрактными объектами на более высоком уровне.

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

некоторого рода ассоциативный массив с экземплярами объектов-реализаций, которые определяются по ключу – типу или имени интерфейса.

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

конструктор для ассоциирования объекта с конкретными реализациями абстракций. При использовании этого типа инверсии зависимостей, необходимые объекты передаются в конструктор, в качестве аргументов.

Одно из достоинств Constructor injection заключается в том, что все зависимости класса прописываются явно. То есть, взглянув на один лишь конструктор класса, мы уже понимаем, какими ресурсами остальной системы он пользует.

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

из инъецируемых объектов. От предыдущего типа инъекции она отличается местом инъецирования.

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

задаются интерфейсы, которые определяют методы для связывания. Один интерфейс на каждую зависимость.


interface injectReader
{
void injectReader(IReader obj);
}

interface injectWriter
{
void injectWriter(IWriter obj);
}

Зависимый объект должен реализовывать все эти интерфейсы.

class Copier: injectReader, injectWriter...

public void injectReader(IReader obj)
{
reader = obj;
}

public void injectWriter(IWriter obj)
{
writer = obj;
}
}

установленного интерфейса:

reader = new keyboardReader();
writer = new stdoutWriter();

copier = new copier();

reader->inject(copier);
writer->inject(copier);

Определяется также единый интерфейс для всех сервисов:
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);
}
}

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

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

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

исходных текстов, исполняемого кода, подвергаемых тестированию с указанием типа тестированию (автоматизированные тесты, формальные инспекции, тестирование на моделях, полунатурные испытания и т.п.). Необходимо зафиксировать тестируемые аспекты и не тестируемые аспекты.

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

могут быть использованы для приёмочного тестирования.
Тестируемые аспекты.
В рамках данного плана предполагается выполнить функциональное тестирование ПО в режимах генерации списка получателей, формирования сообщений и отправки писем.
Также предполагается провести модульное тестирование класса Recipient, который отвечает за хранение и преобразование информации о получателе писем.
Нетестируемые аспекты.
В рамках данного плана не предполагается выполнять:
Функциональное тестирование системы в режиме аутентификации пользователя и проверки количества реально отправленных писем.
Нефункциональное тестирование, в том числе нагрузочное тестирование, тестирование производительности, тестирование удобства использования (usability).
Тестирование будет проводится с использованием системы автоматизированного тестирования TestComplete, а также интегрированных в среду разработки Microsoft Visual Studio юнит-тестов.

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

действий, которые они могут выполнять в системе. В процессе тестирования, описанные здесь варианты использования, позволяют проще оценить точность реализации требований пользователей и провести пошаговую проверку этих требований.

Стратегия использования прецедентов при определении требований определяет необходимость дополнительно к вопросу "что пользователи ждут от системы?" задавать вопрос "что система должна сделать для конкретного пользователя?". Такой подход позволяет искать функции, которые нужны многим пользователям, и исключать те возможности, которые не могут помочь пользователям выполнять свои повседневные задачи.

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

использования, которая представлена на рисунке 1 для системы рассылки массовых информационных сообщений выпускникам факультета.
У тестируемого программного обеспечения можно выделить три основных режима функционирования – работа с файлами адресов рассылки, формирование наполнения рассылки и, непосредственно, отправка писем указанным адресатам. И два вспомогательных – авторизация и ведения отчёта отправки.

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

сообщений выпускникам факультета.

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

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

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

использования были выделены следующие варианты использования, которые требуют дополнительного тестирования:
Авторизация.
Формирование списка рассылки:
выбор файла БД;
выбор столбцов;
добавление фильтров.
Ввод заголовка сообщения.
Ввод тела сообщения.
Работа с вложениями.
Отправка писем.
Автоподстановка шаблонов.
Отправка, начиная с указанного получателя.
Формирование и сохранение отчёта об отправке.
Класс Recipient.

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

и критерий, по которому можно было бы определить, что тестирование завершено. Стратегия тестирования определяется исходя из вида тестирования.
Необходимо дать описание подходов к тестированию (unit тестов, тестирования с помощью Test Complete, системы отслеживания ошибок (bug tracking) и прочих специальных средств тестирования), которые будут применяться в ходе проведения тестирования – в рамках одного тестового плана следует придерживаться общих методик тестировании системы. Описать насколько подробно будет тестироваться система и её компоненты.

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

использования ПО. Стратегия тестирования – методом «чёрного ящика».
Модульное тестирование (для проверки методов разработанного класса Recipient) с точки зрения разработчика-программиста, который использует данный класс. Стратегия тестирования – методом «белого ящика».
 
Специальные средства тестирования:
Тестирование будет производиться при помощи TestComplete и встроенных в Microsoft Visual Studio Unit-тестов. Некоторые тесты будут проводиться вручную.

Требования к окружению:
Для выполнения тестов требуется установленный TestComplete версии 7 или выше, также для выполнения некоторых тестов необходим доступ к интернету с открытыми портами для отправки электронной почты, для функционирования тестируемой системы необходим установленный Microsoft Office 2003 и .NET Framework 3.5 и выше.

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

примеру – описание проверки четко определенной самостоятельной части функциональности (или свойств) программного обеспечения и ожидаемых результатов. В общем случае, один контрольный пример соответствует одному варианту использования [58].

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

совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Выделим тестовые случаи на основе анализа объектов тестирования для системного тестирования (выделены на основе анализа диаграммы use-case):
Проверка авторизации пользователя – логин и пароль пользователя должны быть введены, при подключении к smtp серверу ответ должен быть положительным.
Проверка формирования списка рассылки – контролируется корректная загрузка и анализ excel файла списка получателей, автоматический выбор столбцов по заголовку, а также изменение заголовков, проверка установки фильтров.
Проверка контроля ввода заголовка сообщения – заголовок сообщения не должен быть пустым.
Проверка ввода тела сообщения – тело сообщения не должно быть пустым и может содержать управляющие символы перехода на новую строку, а также шаблоны, которые будут заменены при автоподстановке.
Проверки управления вложениями – контролируется возможность добавлять и удалять файлы вложения к формируемой рассылке.
Проверка отправки писем – тестируется возможность отправки писем через указанный smtp сервер выбранным получателям (для успешного прохождения данного тект-кейса необходимо интернет подключение с открытыми портами).

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

на соответствующие значения из списка получателей (подстановка имён и мужского/женского склонения).
Контроль отправки писем с указанного получателя – проверка возможности указать из списка получателей адрес, с которого необходимо продолжить отправку, а также контроль того, что отправка началась именно с данного получателя.
Проверка формирования и сохранения отчёта об отправке – отчёт об отправке должен содержать подробную информацию о совершаемой рассылке – дату и время, текст сообщения, адреса получателей, результат успешности отправки письма каждому из адресатов.
Модульное тестирование класса Recipient. Проверка функционированеия всех методов данного класса. Основное внимание уделить трём свойствам: sex, FIO и emails. Остальные свойства просто не должны самостоятельно изменять своего значения. Свойства sex, FIO и emails изменяются по следующим правилам:
При тестировании свойства sex производится анализ отчества по окончанию записи. Если свойство FIO заканчивается на *вич, то свойство sex, возвращает строку «М», если свойство FIO заканчивается на *вна, то свойство sex, возвращает строку «Ж», в противном случае возвращает строку "не установлен".
При тестировании свойства FIO необходимо проверить, чтобы установленное свойство всегда возвращала строку, все слова в которой начинаются с большой буквы.
При тестировании свойства emails необходимо проверить, чтоб строка, разделённая разделителями типа точки, точки с запятой или пробелами разбивалась на массив строк адресов получателя.

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

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

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

таблице 1 представлен тестовый набор корректных и не корректных данных для каждого тестового случая.
Таблица 1 – Тестовый набор данных

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

должен иметь 3 части:
Предусловия – список действий, которые приводят систему к состоянию пригодному для проведения данного теста; либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Описания теста – список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод об удовлетворении реализации, поставленных требований.
Постусловия – список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state).

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

Кейсов
Время Прохождения Тест Кейса
Существует 2 широко применяемых подхода к оценке и измерению тестового покрытия:
Покрытие требований
Покрытие кода

Примеры критериев окончания тестирования:
результаты тестирования удовлетворяют критериям качества продукта;
требования к количеству открытых багов выполнены;
выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF);
выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB).

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

для теста Проверка формирования списка рассылки

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