Лекция 2 тестирование и жизненный цикл ПО

Open Access Quality Assurance & Related Software Development for Financial Markets Tel: +7 495 640 24 60 , +1 415 830 38 49 www.exactpro.com

1

Тестирование и жизненный цикл ПОЛекция 2

Open Access Quality Assurance & Related Software Development for Financial Markets Tel: +7 495 640 2460, +1 415 830 38 49www.exactpro.com

20 июня 2016Сергей Чубуров

http://www.exactpro.com/

http://exactpro.com/


2

Содержание

- модели жизненного цикла ПО и их особенности - Agile and Scrum - классификация тестирования: уровни и типы



3

Модели жизненного цикла ПО

• Каскаднаятак же известная как водопадная или последовательная;

• Инкрементальнаяэволюционная

• Спиральнаяили модель Боэма (88-90-е г.г.).

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.



4

Каскадная: модель «водопада» (waterfall)

Применение Проекты, в которых требования и границы прозрачны и точно известны в начале жизненного цикла проекта. Для

которых не предусматривается их изменений в процессе разработки;

- Высокая прозрачность разработки и фаз проекта - Чёткая последовательность - Стабильность требований

- Очень не гибкая методология - У Заказчика нет возможности ознакомиться с системой заранее и даже с «Пилотом» системы - У Пользователя нет возможности привыкать к продукту постепенно - Все требования должны быть известны в начале жизненного цикла проекта - Отсутствует возможность учесть переделку, весь проект делается за один раз



5

Каскадная: модель «водопада» (waterfall), пример

Рентгеновский микротомограф, позволяет с точностью до микрона узнать о внутренней структуре различных материалов. Например, алмазов. Томограф может просветить материал с разрешением до микрона. (миллионная метра) После сканирования программа создает 3D-модель, где можно посмотреть не только на внешнюю сторону детали, но и узнать, что у нее внутри.

https://habrahabr.ru/company/edison/blog/273295/



6

Каскадная: модель «водопада» (waterfall) в реальности

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



7

Каскадная: «V» модель

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

Применение

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

Если требуется тщательное тестирование продукта



8

Инкрементальная модель

Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.

Требуется ранний вывод продукта на рынок.

Большой и объёмный проект, с необходимостью пофазового подхода

Есть несколько рисковых фич или целей.



9

Инкрементальная модель

- Не требуется заранее тратить средства, необходимые для разработки всего проекта; - В результате выполнения каждого инкремента получается функциональный продукт; - Заказчик располагает возможностью высказаться по поводу каждой разработанной версии системы; - Пользователь получает возможность заранее привыкать к системе; - Возможность изменения, усовершенствования, уточнения требований с гораздо меньшим затратами чем в случае каскадной модели;

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



10

Спиральная модель

Когда пользователи не уверены в своих потребностях;

Когда требования слишком сложные;

При разработке новой функции или новой серии продуктов;

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



11

Спиральная модель

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

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



12

Сравнение моделей жизненного цикла



13

Agile – семейство гибких методологий разработки

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

Гибкая методология разработки (Agile software development) — семейство методологий разработки ПО ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля

http://agilemanifesto.org



14

Коротко об Agile

Изменения приветствуются

Команда поставляет готовый продукт

Частые поставки, короткие итерации

Требования поступают от заказчика в виде приоретизированного списка

Команда регулярно улучшает и пересматривает результаты работы



15

Принципы Agile:

1) Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

2) Приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

3) Частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

4) Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

5) Проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

http://agilemanifesto.org/principles.html



16

Принципы Agile:

6) Рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

7) Работающее программное обеспечение — лучший измеритель прогресса;

8) Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;

9) Постоянное внимание улучшению технического мастерства и удобному дизайну;

10) Простота — искусство не делать лишней работы;

11) Лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;

12) Постоянная адаптация к изменяющимся обстоятельствам.



17

Главные преимущества Agile:

Качество продуктаВовлечение заказчика в процесс каждой итерации дает возможность корректировать процесс, что неизменно повышает качество.

Высокая скорость разработкиИтерация длится не более 3-х недель, к концу этого срока обязательно есть результат.

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



18

Scrum методология

Это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет.

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

https://ru.wikipedia.org/wiki/Scrum



19

Scrum, роли

Product owner – это человек, который знает, как он хочет, чтобы выглядел продукт, т.е. он формирует список требований, которые заносятся в бэклог продукта идут в разработку

Team(5-9 человек) – это команда, которая непосредственно участвует в разработке. Очень важно чтобы она была самоорганизующейся и самоуправляемой, а также могла самостоятельно выделить какие из предложенных требований необходимо разработать в первую очередь.

Scrum Master – это человек, который следит за тем, чтобы соблюдались правила Scrum



20

Scrum методология

Спринт — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени, его длительность составляет от 2 до 4 недель. Считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. Задания, которые решаются в ходе спринта берутся из бэклога. Бэклог продукта — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются пользовательскими историями (user story) или элементами бэклога (backlog items). Бэклог проекта открыт для редактирования для всех участников скрам процесса.

Бэклог спринта — содержит функциональность, выбранную владельцем проекта из Бэклога проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Каждый день команда оценивает объём работы, который нужно проделать для завершения спринта.



21

Классификация тестирования



22

Виды тестирования



23

Уровни тестирования

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

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

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

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



24

Компонентное тестирование

Базис:• Требования к компоненту• Детальный дизайн• Код

Объекты:• Модуль• Компонент• Программа• Класс• Функция

Основной целью компонентного тестирования является проверка корректности работы конкретного модуля, компонента или функции(функции в смысле часть кода)

- Функциональное и нефункциональное(например утечки памяти) тестирование

- - TDD



25

Базис:• Дизайн• Архитектура• Сценарии использования

Объекты:• Интерфейсы• Инфраструктура• Подсистемы• Реализация базы данных• Конфигурация системы и конфигурационная информация

Интеграционное тестирование фокусируется на интерфейсах, и способах взаимодействия компонентов системы между собой, взаимодействие системы с окружением(например операционная система), с аппаратным обеспечением, взаимодействие системы с другими системами

- Компонентное - Системное

Интеграционное тестирование



26

Подходы интеграционного тестирования

Big Bang



27

Системное тестирование

Базис:• Спецификации системы• Сценарии использования• Функциональные спецификации

Объекты:• Система• Руководства пользователей• Конфигурация системы и конфигурационная информация

Системное тестирование фокусируется на использовании системы в целом.Проверяются как функциональные так и не функциональные характеристики. Цель – удостовериться что система работает в соответствии с запланированной архитектурой.



28

Приёмочное тестирование

Базис:• Клиентские требования• Сценарии использования• Бизнес процессы

Объекты:• Бизнес процессы на полностью развёрнутой системе• Процессы связанные с работой и обслуживанием системы• Пользовательские процедуры

Тестирования с уровня спецификаций клиентов, основная цель – получить уверенность в системе с точки зрения заявленного клиентами функционала, и оценить её готовность для выпуска

Заказчик(клиент) помогает тестировщикам понять бизнес правила, тестировщики помогают заказчику составить качественные тестовые сценарии



29

Типы тестирования(по цели)

- Функциональное Правильность выполнения заявленных функций, системой, подсистемой или компонентом. Основной фокус на том «что» система делает. Может применяться на всех уровнях.

Тестирование безопасности (Security and Access Control Testing)

- НефункциональноеЗачастую это измеряемые характеристики работы системы. Фокусируется не на самих функциях , а на том «как» система выполняет их

Тестирование производительности: нагрузочное тестирование (Load Testing) стрессовое тестирование (Stress Testing) тестирование на утечки памяти(Soak Testing)

Тестирование удобства пользования (Usability Testing)



30

Типы тестирования(по знанию структуры системы)



31

Типы тестирования(по корректности вводимых данных и тестовых условий)

ПозитивноеТестирование проверяющее поведение системы в рамках ожидаемых сценариев использования с нормальными входными параметрами и условиямиЦель – проверка того что система работает в соответствии с установленными требованиями

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

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

Таким образом, если мы просто проверим что поведение отвечает заданным требованиям, мы упустим «тёмную сторону»



32

Типы тестирования(по степени автоматизации)

- Ручное

- Автоматизированное

- Автоматическое



33

Ещё немного классификации

- СтатическоеТестирование без непосредственного выполнения программы

- ДинамическоеТестирование при выполнении программы

Re-Testing проверка что конкретный дефект устранён

Regression testing проверка что не появилось новых дефектов в ранее работавшем функционале

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



34

Использованные источники:

http://qaevolution.ru/http://www.itlab.unn.ru/MiniProjects/LCM/Conspect.dochttp://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD/UMK_DO/frame/UMK_DO/M1/L3.htmhttp://www.protesting.ruhttp://agilemanifesto.org/principles.htmlhttps://habrahabr.ru/company/edison/blog/269789/https://ru.wikipedia.org/wiki/Гибкая_методология_разработкиhttp://xbsoftware.ru/blog/zhiznennyj-tsykl-po-kaskadnaya-model-waterfall/http://www.4stud.info/software-construction-and-testing/lecture6.htmlhttp://www.intuit.ru/studies/courses/64/64/lecture/1868?page=4https://habrahabr.ru/company/mailru/blog/260105/https://en.wikipedia.org/wiki/Negative_test


http://qaevolution.ru/

http://www.itlab.unn.ru/MiniProjects/LCM/Conspect.doc

http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD/UMK_DO/frame/UMK_DO/M1/L3.htm

http://edu.dvgups.ru/METDOC/GDTRAN/YAT/ITIS/PROEK_INF_SIS/METOD/UMK_DO/frame/UMK_DO/M1/L3.htm

http://www.protesting.ru/

https://habrahabr.ru/company/edison/blog/269789/

https://ru.wikipedia.org/wiki/%D0%93%D0%B8%D0%B1%D0%BA%D0%B0%D1%8F_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8

https://ru.wikipedia.org/wiki/%D0%93%D0%B8%D0%B1%D0%BA%D0%B0%D1%8F_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8

http://www.intuit.ru/studies/courses/64/64/lecture/1868?page=4

https://habrahabr.ru/company/mailru/blog/260105/


35

Вопросы



36

Спасибо


Business

Лекция 2 тестирование и жизненный цикл ПО