Презентация Компьютерное моделирование Жизненный цикл модели качество тестирование онлайн

Содержание слайда: Компьютерное моделирование Жизненный цикл модели качество тестирование Сосновский Ю.В.

Содержание слайда: Технологические основы языков программирования высокого уровня Сложность задач Технологии программирования Структурное программирование Модульное программирование Объектный подход ОО и алгоритмическая декомпозиция. Алгоритмы, классы и объекты. ОО Анализ ОО Проектирование ОО Программирование Принципы объектного подхода.

Содержание слайда: Сложность задач Сложные задачи порождают сложные программные системы

Содержание слайда: Как бороться со сложностью? Разработка ПО по сути проблем похожа на производство Процесс создания ПО имеет много аналогий с производственным процессом В любом производстве есть способы преодоления сложности: технологии

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

Содержание слайда: определения Программный продукт (ПП) - это программное обеспечение, предназначенное для удовлетворения потребностей пользователей широкого распространения и продажи (записанное на носителях данных и снабженное программной документацией) Коробочный программный продукт – это программный продукт, предназначенный для неопределенного круга покупателей и поставляемое на условиях «как есть», со стандартными для всех покупателей функциями Заказной программный продукт – программный продукт, появление которого обусловлено требованием конкретного заказчика и продажа которого может, по требованию заказчика, сопровождаться проектной доработкой или разработкой функций, дополняющих стандартные Процесс разработки программного продукта – это структура, согласно которой построена разработка программного обеспечения Жизненный цикл программного обеспечения (ПО) – это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации (ISO 12207)

Содержание слайда: Модель жизненного цикла ПП – описание набора фаз (этапов, стадий) проекта по созданию ПО, в которых выполняются отдельные процессы, разбитые на операции и задачи Проект – это уникальный процесс, в ходе выполнения которого получают уникальный продукт. Проект представляет собой уникальную (в отличие от операций) деятельность, имеющую начало и конец во времени, направленную на достижение определённого результата (цели), создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска Требование – задокументированная уникальная потребность (необходимость) того, что должен делать конкретный продукт или каким он должен быть

Содержание слайда: Отладка (Debugging) – деятельность, направленная на установление точной природы известной ошибки, а затем - на исправление этой ошибки. Результаты тестирования являются исходными данными для отладки Контроль (Verification) – оценка соответствия характеристик ПП требованиям, объявленным в ТЗ (попытка найти ошибки, выполняя программу в тестовой, или смоделированной среде) Испытание (Validation) – оценка соответствия характеристик ПП требованиям заказчика при решении его реальных задач (попытка найти ошибки, выполняя программу в заданной реальной среде и, что важнее – решает ли ПП заданные проблемы заказчика)

Содержание слайда: Процесс разработки ПО Основные этапы процесса разработки ПО: Сбор и анализ требований Разработка архитектуры Кодирование Тестирование Документирование Сопровождение

Содержание слайда: Жизненный цикл ПО Постановка задачи Постановка задачи (спецификация программы) означает точное, полное и понятное описание того, что происходит при выполнении конкретной программы Точность, т.е. исключение любой неоднозначности Полнота, т.е. рассмотрение всех вариантов для заданного ввода, включая ошибочный или непредусмотренный ввод, и определение соответствующего вывода Ясность, т.е. она должна быть понятной и пользователю и системному аналитику, поскольку постановка задачи - это единственный контракт между ними

Содержание слайда: жизненный цикл проекта PLCM Модель жизненного цикла - структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования [ГОСТ 12207, 1999] Жизненный цикл автоматизированной системы (АС) - совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС, от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации АС [ГОСТ 34, 1990] ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий стандарт IEEE 12207 Второй – в рамках семейства ГОСТ 34 – разрабатывался в СССР самостоятельно, как стандарт на содержание и оформление документов на программные системы в рамках Единой системы программной документации (ЕСПД) и Единой системы конструкторской документации (ЕСКД)

Содержание слайда: Уровни жизненного цикла Скотт Амблер (Scott W. Ambler): ЖЦ разработки программного обеспечения – проектная деятельность по разработке и развертыванию программных систем ЖЦ программной системы – включает разработку, развертывание, поддержку и сопровождение ЖЦ информационных технологий (ИТ) – включает всю деятельность ИТ-департамента ЖЦ цикл организации – охватывает всю деятельность организации в целом

Содержание слайда: PDCA-цикл «Подходящая» модель ЖЦ: направляет проект улучшает скорость разработки улучшает отслеживание и контроль над проектом минимизирует издержки и влияние рисков улучшает отношение с клиентом

Содержание слайда: Модели жизненного цикла ПО Каскадная (водопадная, нисходящая) Макетирование (прототипирование) Инкрементная Эволюционная

Содержание слайда: Стратегии создания ПО

Содержание слайда: каскадная модель жизненного цикла ПО

Содержание слайда:

Содержание слайда:

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

Содержание слайда: Модель с промежуточным контролем:

Содержание слайда: Макетирование (прототипирование)

Содержание слайда: Инкрементная модель жц разработки по

Содержание слайда:

Содержание слайда:

Содержание слайда: «+» не требуется заранее тратить средства, необходимые для разработки всего проекта в результате выполнения каждого инкремента получается функциональный продукт заказчик располагает возможностью высказаться по поводу каждой разработанной версии системы позволяет разбить возникшую про­блему на управляемые части существует возможность поддерживать постоянный прогресс в ходе выполне­ния проекта снижаются затраты на первоначальную поставку программного продукта ускоряется начальный график поставки

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

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

Содержание слайда: Итерационная модель

Содержание слайда: Спиральная модель Спиральная модель была предложена как альтернатива каскадной модели, учитывающая повторяющийся характер разработки ПО Основные принципы спиральной модели можно сформулировать следующим образом: Разработка вариантов продукта, соответствующих различным вариантам требований с возможностью вернуться к более ранним вариантам Создание прототипов ПО для уточнения и выявления требований Планирование следующих вариантов с оценкой альтернатив и анализом рисков, связанных с переходом к следующему варианту Переход к разработке следующего варианта до завершения предыдущего в случае, когда риск завершения очередного варианта (прототипа) становится неоправданно высок. Использование каскадной модели как схемы разработки очередного варианта Активное привлечение заказчика к работе над проектом

Содержание слайда: Спиральная (эволюционная) модель разработки ПО Программное обеспечение создается итерационно с использованием метода прототипирования. Требования изначально не могут быть осознаны и установлены Прототипом называют действующий программный продукт, реализующий отдельные функции и внешние интерфейсы разрабатываемого программного обеспечения.

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

Содержание слайда: V-модель жизненного цикла V-образная модель была разработана как разновидность каскадной модели V-образная модель ЖЦ создана с целью помочь работающей над проектом коман­де в планировании с обеспечением дальнейшей возможности тестирования системы. В этой модели особое значение придается действиям, направленным на верифика­цию и аттестацию продукта

Содержание слайда:

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

Содержание слайда:

Содержание слайда:

Содержание слайда: Agile методологии

Содержание слайда: Актуальные методологии разработки ПО Agile-программирование Rational Unified Process (RUP) Ранняя идентификация и непрерывное устранение основных рисков. Концентрация на выполнении требований заказчиков к программе (анализ и построение модели прецедентов (вариантов использования)). Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки. Постоянное обеспечение качества на всех этапах разработки проекта. Работа над проектом в команде

Содержание слайда:

Содержание слайда: Гибкая разработка (Agile) Короткие циклы – итерации (программный проект в миниатюре) Личности и их взаимодействия важнее, чем процессы и инструменты (один офис) Работающее программное обеспечение важнее, чем полная документация Сотрудничество с заказчиком важнее, чем контрактные обязательства Реакция на изменения важнее, чем следование плану

Содержание слайда: Agile Manifesto удовлетворение клиента за счѐт ранней и бесперебойной поставки ценного ПО; приветствие изменения требований, даже в конце разработки ( это может повысить конкурентоспособность полученного продукта); частая поставка рабочего ПО (каждый месяц или неделю или ещѐ чаще); тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта; проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием; рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

Содержание слайда: Agile Manifesto работающее ПО — лучший измеритель прогресса; спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок; постоянное внимание на улучшение технического мастерства и удобный дизайн; простота — искусство НЕ делать лишней работы; лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды; постоянная адаптация к изменяющимся обстоятельствам.

Содержание слайда: Технология RAD Rapid Application Development — быстрая разработка приложений. Она предусматривает: ведение разработки небольшими группами (3-7 человек), каждая из которых проектирует и реализует отдельные подсистемы (улучшает управляемость проекта); использование готовых компонентов (уменьшение времени получения работоспособного прототипа); наличие четко проработанного графика цикла, рассчитанного не более чем на три месяца (увеличивает эффективность работы). RAD хорошо зарекомендовал себя для небольших стандартных проектов для конкретного заказчика. RAD ориентирован на разработку информационных систем, которые можно разбить на отдельные модули и где производительность не критична.

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

Содержание слайда: Экстремальное программирование Цель экстремального программирования (ХР) — устранить высокую стоимость изменений, вносимых в ПО в процессе как разработки, так и эксплуатации. Цикл разработки в ХР состоит из очень коротких итераций. выслушивание заказчика проектирование кодирование тестирование. Заказчик постоянно присутствует в группе разработчиков. При принятии решений всегда стремятся выбрать самое простое, тесты пишутся еще до написания кода. Сборка системы выполняется ежедневно.

Содержание слайда: Основные принципы ХР Планирование  Частая смена версий  Метафора  Простой проект  Тесты Переработка системы  Программирование в паре Непрерывная  интеграция 

Содержание слайда: Короткий цикл обратной связи (Fine scale feedback) Короткий цикл обратной связи (Fine scale feedback) Разработка через тестирование (Test driven development) Игра в планирование (Planning game) Заказчик всегда рядом (Whole team, Onsite customer) Парное программирование (Pair programming) Непрерывный, а не пакетный процесс Непрерывная интеграция (Continuous Integration) Рефакторинг (Design Improvement, Refactor) Частые небольшие релизы (Small Releases) Понимание, разделяемое всеми Простота (Simple design) Метафора системы (System metaphor) Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership) Стандарт кодирования (Coding standard or Coding conventions) Социальная защищенность программиста (Programmer welfare): 40-часовая рабочая неделя (Sustainable pace, Forty hour week)

Содержание слайда: рефакторинг Рефакторинг — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований Цель рефакторинга — сделать код программы более легким для понимания; без этого рефакторинг нельзя считать успешным

Содержание слайда: Необходимость рефакторинга Дублирование кода Длинный метод Большой класс Длинный список параметров «Завистливые» функции — метод, который чрезмерно обращается к данным другого объекта Избыточные временные переменные Классы данных Не сгруппированные данные

Содержание слайда: Scrum Технология (набор принципов), на которых строится процесс разработки, позволяющий в жѐстко фиксированные небольшие промежутки времени (спринты от 2 до 4 недель) предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определѐн наибольший приоритет.

Содержание слайда: С чего все начиналось Курица говорит свинье: «Давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как мы его назовем?» Курица подумала и говорит: «Почему бы не назвать «Яичница с беконом?»». «Так не пойдѐт», — отвечает свинья, «ведь тогда мне придѐтся полностью посвятить себя проекту, а ты будешь вовлечена только частично»…

Содержание слайда: Роли «Свиньи» ScrumMaster — тот, кто ведѐт Scrum митинги. Является интерфейсом между менеджментом и командой (менеджер проекта или teamlead). Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды - команда является самоорганизующейся и самоуправлямой Владелец Продукта (Product Owner) — человек, отвечающий за разработку продукта который представляет интересы конечных пользователей и других заинтересованных в продукте сторон. Ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта Команда (Scrum Team), состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (7±2 человека). «Цыплята» Пользователи (Users) Клиенты, Продавцы (Stakeholders) Эксперты-консультанты (Consulting Experts)

Содержание слайда: Product Backlog — приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе. Включает в себя use cases, defects, enhancements, technologies, stories, features, issues, и т.д.. Также включает задачи, важные для команды, например «провести тренинг». Постоянно пересматривается и дополняется

Содержание слайда: Планирование спринта

Содержание слайда: Процесс. Встречи Планирование спринта (Planning Meeting) Митинг (Daily Scrum) Что сделано с момента предыдущего митинга до текущего? Что будет сделано с момента текущего митинга до следующего? Какие проблемы мешают достижению целей спринта? Демонстрация (Demo Meeting) Ретроспектива (Retrospective Meeting)

Содержание слайда: SCRUM Scrum - принципы разработки для предоставления пользователю работающего ПО с новыми возможностями в жёстко фиксированные сроки (спринты от 2 до 4 недель) Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. Строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость Митинг происходит каждый день в течение спринта (начинается точно вовремя; все могут наблюдать, но только «свиньи» говорят; длится не более 15 минут; проводится в одном и том же месте в течение спринта). В течение митинга каждый член команды отвечает на 3 вопроса (Что сделано с момента предыдущего митинга, что будет сделано до следующего митинга, какие проблемы мешают достижению целей спринта)

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда: Соотношение SCRUM vs RUP

Содержание слайда: Общее соотношение подходов

Содержание слайда: Выбор модели жц

Содержание слайда: Основные критерии качества ПО

Содержание слайда: Представление качества в стандарте ISO 9126

Содержание слайда: Критерии качества ПО Внешние характеристики: Корректность (наличие/отсутствие дефектов в спецификации, проекте и реализации) Практичность (легкость изучения и использования) Эффективность (степень использования системных ресурсов) Надежность (способность системы выполнять необходимые функции; интервал между отказами) Целостность (способность предотвращать неавторизованный или некорректный доступ) Адаптируемость (возможность использования в других областях и средах) Правильность (степень безошибочности данных, выдаваемых системой) Живучесть (способность продолжать работу при недопустимых данных или в напряженных условиях)

Содержание слайда: ISO 9000 ISO 9001:2000 Quality management systems — Requirements. Models for quality assurance in design, development, production, installation, and servicing Системы управления качеством — Требования. Модели для обеспечения качества при проектировании, разработке, коммерциализации, установке и обслуживании Определяет общие правила обеспечения качества результатов во всех процессах жизненного цикла (Аналог — ГОСТ Р-2001)

Содержание слайда: ISO 9004:2000 Quality management systems — Guidelines for performance improvements Системы управления качеством. Руководство по улучшению деятельности. (Аналог — ГОСТ Р-2001) ISO/IEC 90003:2004 Software engineering — Guidelines for the application of ISO 9001:2000 to computer software Руководящие положения по применению стандарта ISO 9001 при разработке, поставке и обслуживании программного обеспечения

Содержание слайда: Характеристики и атрибуты качества программного обеспечения по ISO 9126

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда: Стоимость качества Preventive costs (стоимость предотвращения низкого качества продукта\сервиса): Планирование качества Разработка/оценка процессов Планирование улучшения качества Обучение Стоимость всех активностей для предотвращения ошибок (QA)   Appraisal costs (стоимость оценки): Стоимость тестирования Стоимость выполнения ревью Стоимость выполнения инспекций Все затраты на выявление дефектов (QC)   Failure cost (цена «неудач»/ошибок, обнаруженных до и после поставки продукта\предоставления сервиза заказчику, internal failure cost and external failure cost): Стоимость идентификации, анализа, исправления ошибок и проверки исправления ошибок Повторное тестирование Стоимость переработок, работ по обработке жалоб заказчика

Содержание слайда: Стоимость качества

Содержание слайда: Управление требованиями ГОСТ Р и ISO/IEC 12207 V&V Спецификация — (Specification) набор требований и параметров, которым удовлетворяет некоторая сущность. Согласно определению, приведенному в Единой системе конструкторской документации (ЕСКД) спецификация — документ, определяющий состав сборочной единицы, комплекса, комплекта. В спецификации содержится подробное перечисление узлов и деталей какого-либо изделия, конструкции, установки, и т. п., входящих в состав сборочного или монтажного чертежа. Также под спецификацией часто подразумевается документ с перечислением условий, которым должен удовлетворять производственный заказ (требования клиента к производителю).

Содержание слайда: Требования к ПО Требования к ПО — совокупность утверждений относительно свойств программной системы, подлежащая реализации при создании программного обеспечения. Создаются в процессе анализа требований к программному обеспечению Виды требований по уровням: Бизнес-требования — определяют назначение программного обеспечения Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия) Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе (use case) Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять диаграммы: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD)

Содержание слайда: Тестирование ПО Тестирование – проверка соответствия ПО требованиям, осуществляемая с помощью наблюдения за его работой в специальных, искусственно построенных ситуациях (тесты) Набор тестов конечен Критерии полноты тестирования: важность, эквивалентность и отношение между ситуациями тестирования Критерий тестового покрытия: если программа правильно работает в ситуации A, то, скорее всего, в ситуации B также все будет правильно (используется одна из ситуаций одного класса)

Содержание слайда: Стандарты тестирования IEEE 829-1998 Standard for Software Test Documentation - описывает виды документов, служащих для подготовки тестов IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing - описывает организацию модульного тестирования ISO/IEC 12119:1994 (ГОСТ Р-2000, IEEE 1465-1998) Information Technology. Software packages — Quality requirements and testing - описывает требования к процедурам тестирования программных систем

Содержание слайда: организационные принципы управления тестированием Программирующая организация не должна сама тестировать разработанные ею программы Необходимо досконально изучать результаты применения каждого теста Тесты для неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать Не следует выбрасывать тесты, даже если программа уже не нужна Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены Вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части Тестирование — процесс творческий

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

Содержание слайда: 5.2.4. Автоматизация тестирования 5.2.5. Примеры. Модульное тестирование. Разработка через тестирование. Приложения модульного тестирования Экстремальное программирование предполагает как один из постулатов использование инструментов автоматического модульного тестирования. Этот инструментарий может быть либо созданным третьей стороной (например, Boost.Test), либо быть создан группой разработчиков данного приложения. В экстремальном программировании используются модульные тесты для разработки через тестирование. Для этого разработчик до Разработка через тестирование (test-driven development) — техника программирования, при которой модульные тесты для программы или её фрагмента пишутся до самой программы (test-first development) и, по существу, управляют её разработкой. Является одной из основных практик экстремального программирования. высокого уровня существуют инструменты и библиотеки модульного тестирования. Некоторые из них: Для Java JUnit JUnit.org

Содержание слайда: Типичный жизненный цикл дефекта Новый — дефект зарегистрирован тестировщиком Назначен — назначен ответственный за исправление дефекта Разрешён — дефект переходит обратно в сферу ответственности тестировщика. Как правило, сопровождается резолюцией, например: Исправлено (исправления включены в версию такую-то) Дубль (повторяет дефект, уже находящийся в работе) Не исправлено (работает в соответствии со спецификацией, имеет слишком низкий приоритет, исправление отложено до следующей версии и т.п.) «У меня всё работает» (запрос дополнительной информации об условиях, в которых дефект проявляется) Далее тестировщик проводит проверку исправления, в зависимости от чего дефект либо снова переходит в статус Назначен (если он описан как исправленный, но не исправлен), либо в статус Закрыт. Открыт повторно — дефект вновь найден в другой версии. Примеры систем отслеживания ошибок Свободно распространяемые BUGS - the Bug Genie Bugzilla eTraxis Mantis bug tracking system

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

Содержание слайда: Тестирование ПО метод белого ящика (white-box testing, прозрачного ящика, структурное тестирование) – разработчик теста имеет доступ к исходному коду и может тесты, связанные с библиотеками тестируемого ПО метод чёрного ящика – доступ к ПО через стандартные интерфейсы. Нацелено на проверку требований (тесты на основе требований и ограничений из спецификаций, стандартов, внутренних нормативных документов) Тестирование на соответствие (conformance testing)

Содержание слайда: Уровни тестирования Модульное тестирование (Unit-testing)  – тестируется минимально возможный для компонент (отдельный класс или функция) Интеграционное тестирование (Integration testing) – отдельные программные модули объединяются и тестируются в группе Системное тестирование (System testing) – тестирование на полной, интегрированной системе для проверки соответствия системы исходным требованиям (метод «черного ящика») Приемочное тестирование (Acceptance testing) – тестирование готового продукта конечными пользователями на реальном окружении, в котором будет функционировать тестируемое приложение

Содержание слайда: тестирование Статическое тестирование (Static testing) –тестируемая программа (код) не выполняется. Анализ происходит на основе исходного кода (Обзоры (Reviews), Инспекции (Inspections), Сквозные просмотры (Walkthroughs), Аудиты (Audits), тестирование требований, спецификаций, документации) Динамическое тестирование (Dynamic testing) Альфа-тестирование — тестирование в процессе разработки Бета-тестирование — тестирование выполняется пользователями (end-users) Регрессионное тестирование (Regression testing) – тестирование функциональности, которая была уже протестирована до внесения какого-либо изменения (IEEE 610-90 “Standard Glossary of Software Engineering Terminology”) «Смок-тест» (Smoke Testing, «дымовое тестирование») в тестировании означает минимальный набор тестов на явные ошибки (обычно выполняется самим программистом)

Содержание слайда: Виды тестирования Функциональное тестирование (functional testing) Тестирование производительности (perfomance testing) Стрессовое тестирование (stress testing) Нагрузочное тестирование (load testing) Тестирование удобства использования (usability testing) Тестирование интерфейса пользователя (UI testing) Тестирование безопасности (security testing) Тестирование локализации (localization testing) Тестирование совместимости (compatibility testing)

Содержание слайда: Типы дефектов и статические методы тестирования по времени появления: структурные ошибки набора ошибки компиляции ошибки периода выполнения В теоретической информатике программные ошибки классифицируют по степени нарушения логики: синтаксические семантические прагматические

Содержание слайда: Выявление ошибок Инспекции исходного текста 1. Программиста просят рассказать о логике работы программы. Во время беседы возникают вопросы, преследующие цель обнаружения ошибки. 2. Программа анализируется по списку вопросов для выявления исторически сложившихся общих ошибок программирования Сквозное тестирование

Содержание слайда: Техники создания тест-кейсов

Содержание слайда: Известные технологии программирования Структурное программирование Теорема о базисных конструкциях. Алгоритм: один вход и один выход. Нет безусловным переходам (goto). Поддержка: операторы ЯПВУ. Модульное программирование Разбиение задачи на подзадачи до тех пор, пока они не станут простыми. Подход к коллективной разработке. Поддержка: подпрограммы, модули ЯПВУ.

Содержание слайда: Технологические основы языков программирования высокого уровня Сложность задач Технологии программирования Структурное программирование Модульное программирование Объектный подход ОО и алгоритмическая декомпозиция. Алгоритмы, классы и объекты. ОО Анализ ОО Проектирование ОО Программирование Принципы объектного подхода.

Содержание слайда: Объектный подход... Перечисленных технологий стало недостаточно вследствие роста сложности задач. Объектно-ориентированная технология. Объектный подход: объектная декомпозиция (отличия от алгоритмической) объектная модель (классы + объекты).

Содержание слайда: Объектный подход OOA + OOD + OOP OOA – object-oriented analysis – объектно-ориентированный анализ. OOD – object-oriented design – объектно-ориентированное проектирование. OOP – object-oriented programming – объектно-ориентированное программирование.

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

Содержание слайда: Тенденция последнего десятилетия Постепенно унифицируются подходы к разработке ПО Создаются языки описания и моделирования сложных систем Agile IBM: http://www.rational.com/rup MSF: http://www.microsoft.com/msf Есть русский перевод: http://www.microsoft.com/rus/msf Agile: http://www.agilemanifesto.org Различные языки моделирования слились в один

Содержание слайда: История подходов в программировании

Содержание слайда: UML Unified Modeling Language Де-факто и де-юре стандартный язык моделирования в современной ИТ-индустрии Пока еще преподается не во всех технических вузах СНГ, но ситуация улучшается http://www.omg.org/uml http://www.rational.com/uml http://www.uml.org

Содержание слайда: Структура стандарта UML Графическая нотация Метамодель OCL (Object Constraint Language или язык ограничений) Примеры расширения языка

Содержание слайда: Легенда о Вавилонской башне В Библии предание о том, как Бог, разгневанный дерзостью людей, вознамеривавшихся соорудить башню до небес (Вавилонская башня) «смешал их языки» (они перестали понимать друг друга) и рассеял человечество по всей земле.

Содержание слайда: UML Для визуального моделирования нужна специальная нотация или язык. UML (unified modeling language) – это язык для визуализации, специфицирования, конструирования, документирования элементов программных систем. UML – язык общего назначения, предназначенный для объектного моделирования.

Содержание слайда: Модели UML UML позволяет описывать систему следующими моделями: Модель функционирования Как описывается функциональность системы с точки зрения пользователя. Объектная модель Как выглядит проект системы с точки зрения объектного подхода. Динамическая модель Как взаимодействуют друг с другом компоненты системы в динамике, с течением времени. Какие процессы происходят в системе.

Содержание слайда: Диаграммы UML Диаграммы UML предназначены для визуального отображения моделей и их компонентов. UML 2.0 – 13 типов диаграмм Структурные диаграммы (6) Диаграммы поведения (3) Диаграммы взаимодействия (4)

Содержание слайда: Понятия UML Для описания структуры: Актер, Атрибут, Класс, Компонент, Интерфейс, Объект, Пакет. Для описания поведения: Действие, Событие, Сообщение, Метод, Операция, Состояние, Вариант использования. Для описания связей: Агрегация, Ассоциация, Композиция, Зависимость, Наследование. Некоторые другие понятия: Стереотип, Кратность, Роль.

Содержание слайда: Актеры и Варианты использования в UML Актер в UML – человек, машина или программа, воздействует на систему, является внешним по отношению к ней.

Содержание слайда: Связь актеров и вариантов использования Актеры и варианты использования общаются посредством посылки сообщений. Сообщения могут идти в обе стороны. Стрелка показывает инициатора общения (актер на рисунке) и может быть опущена.

Содержание слайда: Диаграмма вариантов использования

Содержание слайда: http://staruml.sourceforge.net/en/ dia-installer.de