Лекция № 4 Тема 2. Разработка через

Скачать презентацию Лекция № 4 Тема 2.  Разработка через Скачать презентацию Лекция № 4 Тема 2. Разработка через

agile_lecture_4.ppt

  • Размер: 914.0 Кб
  • Автор:
  • Количество слайдов: 42

Описание презентации Лекция № 4 Тема 2. Разработка через по слайдам

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

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

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

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

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

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

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

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

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

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

Пример инверсии управления Представьте себе,  что имеется программа,  которая получает некоторую информациюПример инверсии управления Представьте себе, что имеется программа, которая получает некоторую информацию от пользователя с помощью командной строки: var info=new Info. About. People() ; var tmp=»»; Console. Write. Line(“ ФИО? ”); Console. Read. Line(tmp ); Info. Set. Fio(tmp); Console. Write. Line(“ Дата рождения? ”); Console. Read. Line(tmp); Info. Set. Birth. Day(tmp ); Register. Client(info); В этой ситуации код управляет исполнением: он решает, когда задавать вопросы, когда считывать ответы, а когда обрабатывать результаты. 11 ГИБКИЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Название:  A. 10. b Контроль разбиения электронных адресов Функция: Разбиение электронных адресов ДействиеНазвание: A. 10. b Контроль разбиения электронных адресов Функция: Разбиение электронных адресов Действие Ожидаемый результат Результат теста: Предусловие: Создайте объект Recipient target = new Recipient (); Объект создан. Исключений не возникало. Шаги теста: Задайте свойство FIO объекта target. Email = » monkey @ microsoft. com ; vasya @ rambler. ru , zozo @ test. net » ; Поле установлено. Исключений не возникало. Проанализуруйте значение свойства sex у объекта target. emails приняло значение {» monkey @ microsoft. com ”, “ vasya @ rambler. ru ”, “ zozo @ test. net ”} Постусловие: Укажите пустую ссылку на объект t arget= null Исключений не возникло. Позитивный тестовый случай для теста Контроль разбиения электронных адресов

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