Главная | Обратная связь | Поможем написать вашу работу!
МегаЛекции

Дефекты. Причины, описания, отслеживание




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

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

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

· failure — наблюдаемое нарушение требований, проявляющееся при каком-то реальном сценарии работы ПО. Это можно назвать проявлением ошибки.

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

· error — используется в двух смыслах.

Первый смысл — это ошибка в ментальной модели программиста, ошибка в его рассуждениях о программе, которая заставляет его делать ошибки в коде (faults).

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

Эти понятия некоторым образом связаны с основными источниками ошибок. Поскольку при разработке программ необходимо сначала понять задачу, затем придумать ее решение и закодировать его в виде программы, то, соответственно, основных источников ошибок три:

· Неправильное понимание задач. Очень часто люди не понимают, что им пытаются сказать другие. Так же и разработчики ПО не всегда понимают, что именно нужно сделать. Другим источником непонимания служит отсутствие его у самих пользователей и заказчиков — достаточно часто они могут просить сделать несколько не то, что им действительно нужно. Для предотвращения неправильного понимания задач программной системы служит анализ предметной области.

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

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

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

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

В программировании баг (bug — жук) — жаргонное слово, обычно обозначающее ошибку в программе или системе, которая выдает неожиданный или неправильный результат. Большинство багов возникают из-за ошибок, сделанных разработчиками программы в ее исходном коде, либо в дизайне. Некоторые баги возникают также из-за некорректной работы компилятора, вырабатывающего некорректный код. Программу, которая содержит большое число багов или баги, серьезно ограничивающие ее функциональность, называют нестабильной или, на жаргонном языке, «глючной», «забагованной» (unstable, buggy).

Термин «баг» обычно употребляется в отношении ошибок, проявляющих себя на стадии работы программы, в отличие, например, от ошибок проектирования или синтаксических ошибок. Отчет, содержащий информацию о баге также называют отчетом об ошибке или отчетом о проблеме (bug report). Отчет о критической проблеме (crash), вызывающей аварийное завершение программы, называют крэш репортом (crash report).

«Баги» локализуются и устраняются в процессе тестирования и отладки программы.

Система отслеживания ошибок (bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий.

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

· номер (идентификатор) дефекта;

· кто сообщил о дефекте;

· дата и время, когда был обнаружен дефект;

· версия продукта, в которой обнаружен дефект;

· серьёзность (критичность) дефекта и приоритет решения;

· описание шагов для выявления дефекта (воспроизведения неправильного поведения программы);

· кто ответственен за устранение дефекта;

· обсуждение возможных решений и их последствий;

· текущее состояние (статус) дефекта;

· версия продукта, в которой дефект исправлен.

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

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

Типичный жизненный цикл дефекта:

1. Новый — дефект зарегистрирован тестировщиком

2. Назначен — назначен ответственный за исправление дефекта

3. Разрешён — дефект переходит обратно в сферу ответственности тестировщика. Как правило, сопровождается резолюцией, например:

o Исправлено (исправления включены в версию такую-то)

o Дубль (повторяет дефект, уже находящийся в работе)

o Не исправлено (работает в соответствии со спецификацией, имеет слишком низкий приоритет, исправление отложено до следующей версии и т.п.)

o «У меня всё работает» (запрос дополнительной информации об условиях, в которых дефект проявляется)

4. Далее тестировщик проводит проверку исправления, в зависимости от чего дефект либо снова переходит в статус Назначен (если он описан как исправленный, но не исправлен), либо в статус Закрыт.

5. Открыт повторно — дефект вновь найден в другой версии.

Система может предоставлять администратору возможность настроить, какие пользователи могут просматривать и редактировать ошибки в зависимости от их состояния, переводить их в другое состояние или удалять.

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

При конструировании используются две формы тестирования, проводимого инженерами, непосредственно создающими исходный код:

1) модульное (unit testing);

2) интеграционное (integration testing)

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

Тестирование в конструировании обычно включает подмножество рассмотренных видов тестирования. Например, тестирование в конструировании обычно не включает системного, нагрузочного и usability-тестирования и других видов тестовой деятельности.

Повторное использование

Во введении в стандарт IEEE Std. 1517-99 «IEEE Standard for Information Technology – Software Lifecycle Process – Reuse Processes» дается следующее понимание повторному использованию в программном обеспечении: «Реализация повторного использования программного обеспечения подразумевает и влечёт за собой нечто большее, чем просто создание и использование библиотек активов. Оно требует формализации практики повторного использования на основе интеграции процессов и деятельности по повторному использованию в сам жизненный цикл программного обеспечения.» В то же время, повторное использование достаточно важно и непосредственно при конструировании программных систем.

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

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

Различают повторное использование двух уровней:

a) в малом, при котором выполняется простое копирование некоторого фрагмента в разных местах программы. Этот подход использовать не рекомендуется, так как он затрудняет отладку и тестирование (приходится искать одну и ту же ошибку в нескольких местах программы). Такой фрагмент лучше оформить как метод и обращаться к нему по мере необходимости;

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

Важными вопросами повторного использования являются:

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

2. Определение потенциальной возможности повторного использования.

3. Оценка затрат времени на повторное использование по сравнению с повторным созданием компонентов.

4. Принятие решения по каждому компоненту: что повторно использовать и как (без изменений, с небольшими или значительными изменениями).

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

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

1) выбор единиц (units), баз данных тестовых процедур, данных, полученных в результате тестов, и самих тестов для повторного использования;

2) оценка результатов повторного использования кода и тестов;

3) создание отчетности по повторному использованию в новом коде, тестовых процедурах и результатах тестирования.

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

a) отсутствует необходимость разрабатывать и отлаживать соответствующие модули, это сделали разработчики библиотеки;

b) уменьшается размер программной системы.

Недостатки этой методологии:

a) необходимость контроля совместимости версий модулей библиотек и программной системы (в США из-за этого произошла авария при запуске космической ракеты);

b) дополнительные затраты на приобретение лицензии на пользование пакетом;

c) сложность модификации модулей библиотеки.

Качество конструирования

Качество программного обеспечения — это способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым потребностям. Представление качества в стандарте ISO 9126 иллюстрирует рис. 27.

Рис. 27. Представление качества в стандарте ISO 9126

Различают понятия:

a) внутреннего качества, связанного с характеристиками программного обеспечения самого по себе, без учета его поведения;

b) внешнего качества, характеризующего программного обеспечения с точки зрения его поведения;

c) качества программного обеспечения при использовании в различных контекстах — того качества, которое ощущается пользователями при конкретных сценариях работы программного обеспечения.

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

При конструировании можно выделить два вида качества:

1) Внешнее – качество для заказчика (это удобство в использовании, отсутствие ошибок, хорошая производительность и т.п.)

2) Внутреннее – это качество для разработчиков программного продукта (соответствие требованиям, удобная архитектура, простота изменения и т.п.)

Общие принципы обеспечения качества процессов производства во всех отраслях экономики регулируются набором стандартов ISO 9000. Наиболее важные для разработки программного обеспечения стандарты в его составе следующие:

a) ISO 9000:2000 Quality management systems — Fundamentals and vocabulary. Системы управления качеством — Основы и словарь. (Аналог — ГОСТ Р-2001).

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

c) ISO/IEC 90003:2004 Software engineering — Guidelines for the application of ISO 9001:2000 to computer software. Руководящие положения по применению стандарта ISO 9001 при разработке, поставке и обслуживании программного обеспечения.

Стандарт ISO 9126 предлагает использовать для описания внутреннего и внешнего качества программного обеспечения многоуровневую модель. На верхнем уровне выделено 6 основных характеристик качества программного обеспечения. Каждая характеристика описывается при помощи нескольких атрибутов. Для каждого атрибута определяется набор метрик. Множество характеристик и атрибутов качества согласно ISO 9126 показано на Рис. 28.

Стандарт ISO 9126:2001 дает такие определения этих характеристик и атрибутов:

  • Функциональность (functionality) - способность программного обеспечения в определенных условиях решать задачи пользователей. Определяет, что именно делает программное обеспечение и какие задачи оно решает. Она включает в себя

o Функциональную пригодность (suitability) - Способность решать нужный набор задач.

o Точность (accuracy) - способность выдавать нужные результаты.

o Способность к взаимодействию (interoperability) с набором других систем.

o Соответствие стандартам и правилам (compliance).

o Защищенность (security) - способность предотвращать неавторизированный доступ к данным и программам.

  • Надежность (reliability) - способность программного обеспечения поддерживать определенную работоспособность в заданных условиях. Она характеризуется следующими показателями

o Зрелость, завершенность (maturity) - величина, обратная частоте отказов программного обеспечения. Обычно измеряется средним временем работы без сбоев и величиной, обратной вероятности возникновения отказа за данный период времени.

o Устойчивость к отказам (fault tolerance) - способность поддерживать заданный уровень работоспособности при отказах и нарушениях правил взаимодействия с окружением.

o Способность к восстановлению (recoverability) - способность восстанавливать определенный уровень работоспособности и целостность данных после отказа, необходимые для этого время и ресурсы.

o
Соответствие стандартам надежности (reliability compliance). Этот атрибут добавлен в 2001 году.

 

Рис. 28. Характеристики и атрибуты качества программного обеспечения по ISO 9126.

· Удобство использования (usability) или практичность - способность программного обеспечения быть удобным в обучении и использовании, а также привлекательным для пользователей. Оно включает в себя:

o Понятность (understandability) - показатель, обратный к усилиям, которые затрачиваются пользователями на восприятие основных понятий программного обеспечения и осознание их применимости для решения своих задач.

o Удобство обучения (learnability) - показатель, обратный усилиям, затрачиваемым пользователями на обучение работе с программным обеспечением.

o Удобство работы (operability) - показатель, обратный усилиям, предпринимаемым пользователями для решения своих задач с помощью ПО.

o Привлекательность (attractiveness) - способность программного обеспечения быть привлекательным для пользователей. Этот атрибут добавлен в 2001 году.

o Соответствие стандартам удобства использования (usability compliance). Этот атрибут добавлен в 2001 году.

· Производительность (efficiency) или эффективность - способность программного обеспечения при заданных условиях обеспечивать необходимую работоспособность. Можно определить ее и как отношение получаемых с помощью программного обеспечения результатов к затрачиваемым на это ресурсам всех типов. Она характеризуется следующими показателями.

o Временная эффективность (time behaviour) - способность программного обеспечения выдавать ожидаемые результаты, а также обеспечивать передачу необходимого объема данных за отведенное время.

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

o Соответствие стандартам производительности (efficiency compliance). Этот атрибут добавлен в 2001 году.

· Удобство сопровождения (maintainability), которое включает в себя:

o Анализируемость (analyzability) или удобство проведения анализа ошибок, дефектов и недостатков, а также необходимости изменений и их возможных последствий.

o Удобство внесения изменений (changeability) - показатель, обратный трудозатратам на выполнение необходимых изменений.

o Стабильность (stability) - показатель, обратный риску возникновения неожиданных эффектов при внесении изменений.

o Удобство проверки (testability) - показатель, обратный трудозатратам на проведение тестирования и других видов проверки.

o Соответствие стандартам удобства сопровождения (maintainability compliance). Этот атрибут добавлен в 2001 году.

· Переносимость (portability) - способность программного обеспечения сохранять работоспособность при переносе из одного окружения в другое. Иногда эта характеристика называется в русскоязычной литературе мобильностью. В нее входят:

o Адаптируемость (adaptability) - способность программного обеспечения приспосабливаться различным окружениям без проведения для этого действий, помимо заранее предусмотренных.

o Удобство установки (installability) - способность программного обеспечения быть установленным или развернутым в определенном окружении.

o Способность к сосуществованию (coexistence) с другими программами в общем окружении, деля с ними ресурсы.

o Удобство замены (replaceability) другого ПО данным.

o Соответствие стандартам переносимости (portability compliance). Этот атрибут добавлен в 2001 году.

Перечисленные атрибуты относятся к внутреннему и внешнему качеству программного обеспечения согласно ISO 9126. Для описания качества программного обеспечения при использовании стандарт ISO 9126-4 предлагает другой, более узкий набор характеристик.

· Эффективность (effectiveness) - способность программного обеспечения предоставлять пользователям возможность решать их задачи с необходимой точностью при использовании в заданном контексте.

· Продуктивность (productivity) - способность предоставлять пользователям определенные результаты в рамках ожидаемых затрат ресурсов.

· Безопасность (safety) - способность обеспечивать необходимо низкий уровень риска нанесения ущерба жизни и здоровью людей, бизнесу, собственности или окружающей среде.

· Удовлетворение пользователей (satisfaction) - способность приносить удовлетворение пользователям при использовании в заданном контексте.

Помимо перечисленных характеристик и атрибутов качества, стандарт ISO 9126:2001 определяет наборы метрик для оценки каждого атрибута. Примерами являются следующие метрики.

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

· Корректность реализации функций. Используется для измерения функциональной пригодности.

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

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

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

· Наглядность и полнота документации. Используется для оценки понятности.

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

· Что программное обеспечение должно делать, например:

o позволять клиенту оформить заказы и обеспечить их доставку;

o обеспечивать контроль качества строительства и отслеживать проблемные места;

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

· Насколько оно должно быть надежно, например:

o работать 7 дней в неделю и 24 часа в сутки;

o допускается неработоспособность в течение не более 3 часов в год;

o никакие введенные пользователями данные при отказе не должны теряться.

· Насколько им должно быть удобно пользоваться, например:

o покупатель должен, зная название товара и имея средние навыки работы в Интернет, находить нужный ему товар за не более чем 2 минуты;

o инженер по специальности "строительство мостов" должен в течение одного дня уметь разобраться в 80% функций системы.

· Насколько оно должно быть эффективно, например:

o поддерживать обслуживание до 10000 запросов в секунду;

o время отклика на запрос при максимальной загрузке не должно превышать 3 с;

o время реакции на изменение параметров процесса производства не должно превышать 0.1 с;

o на обработку одного запроса не должно тратиться более 1 MB оперативной памяти.

· Насколько удобно должно быть его сопровождение, например:

o добавление в систему нового вида запросов не должно требовать более 3 человеко-дней;

o добавление поддержки нового этапа процесса производства не должно стоить более $20000.

· Насколько оно должно быть переносимо, например:

o ПО должно работать на операционных системах Linux, Windows XP и MacOS X;

o ПО должно работать с документами в форматах MS Word 97 и HTML;

o ПО должно сохранять файлы отчетов в форматах MS Word 2000, MS Excel 2000, HTML, RTF и в виде обычного текста;

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

Методы контроля качества

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

  • Верификация обозначает проверку того, что очередная версия программного обеспечения разработана в соответствии со всеми требованиями к нему.
  • Валидация — это проверка того, что сам продукт правилен, т.е. что он удовлетворяет потребностям и ожиданиям пользователей.

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

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

· Методы и техники, связанные с выяснением свойств программного обеспечения во время его работы. Это, прежде всего, все виды тестирования, измерение количественных показателей качества, которые можно определить по результатам работы программного обеспечения — эффективности по времени и другим ресурсам, надежности, доступности и пр.

· Методы и техники определения показателей качества на основе симуляции работы программного обеспечения с помощью моделей разного рода. К этому виду относятся проверка на моделях (model checking), а также прототипирование (макетирование), используемое для оценки качества принимаемых решений.

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

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

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

Интеграция

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

Интеграция (от лат. integratio — «соединение») — процесс объединения частей в целое. Наиболее распространенными видами интеграции являются:

· Объединение модулей в единую программную систему;

· Веб-интеграция — объединение разнородных веб-приложений и систем в единую среду;

· Интеграция данных — объединение данных, находящихся в различных источниках и предоставление их пользователям в унифицированном виде

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

Непрерывная интеграция (CI - Continuous Integration) — это практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может надолго задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоемкость этого процесса и сделать его более предсказуемым за счет раннего обнаружения и устранения ошибок и противоречий. Методика предложена Гради Бучем в 1991 г. Она является одним из основных приёмов экстремального программирования.

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

На выделенном сервере организуется служба, в задачи которой входят:

· получение исходного кода из репозитория;

· сборка проекта;

· выполнение тестов;

· развертывание готового проекта;

· отправка отчетов.

Локальная сборка может осуществляться:

· по внешнему запросу,

· по расписанию,

· по факту обновления репозитория и по другим поводам.

Сборка по расписанию (daily build — ежедневная сборка) обычно проводится каждую ночь в автоматическом режиме (чтобы к началу рабочего дня были готовы результаты тестирования). Для их различия вводится система нумерации. Обычно каждая сборка нумеруется натуральным числом, которое увеличивается каждый день (для новой сборки). Исходные тексты и другие исходные данные при получении из репозитория помечаются номером сборки. Благодаря этому, любая сборка может быть точно воспроизведена в будущем — достаточно взять исходные данные по нужной метке и запустить процесс снова. Это обеспечивает возможность повторно выпускать даже очень старые версии программы с небольшими исправлениями. Ежедневные сборки вызывают проблему включения в систему и репозитарий больших модулей, которые разрабатываются несколько дней. Для ее устранения используются версии кода с ветвлениями. Большой модуль включается в отдельную ветку. По окончании разработки и индивидуального тестирования такой ветки, она может быть объединена с основным кодом или «стволом» проекта.

Преимущества непрерывной интеграции

· проблемы интеграции выявляются и исправляются быстро, что обеспечивает минимум затрат;

· немедленный прогон модульных тестов для свежих изменений;

· постоянное наличие текущей стабильной версии вместе с продуктами сборок (для тестирования, демонстрации, и т. п.);

· немедленный эффект от неполного или неработающего кода приучает разработчиков к работе в итеративном режиме с более коротким циклом.

Недостатки непрерывной интеграции

· дополнительные затраты на поддержку ее работы;

· необходимость в выделенном сервере под ее нужды;

· немедленный эффект от неполного или неработающего кода отучает разработчиков от выполнения периодических резервных включений кода в репозиторий.

Кроме перечисленных проблем интеграции, к интеграционным вопросам конструирования относятся следующие задачи:

· планирование последовательности, в которой интегрируются компоненты;

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

· задание «глубины» тестирования и других работ по обеспечению качества интегрируемых компонент;

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

Поделиться:





Воспользуйтесь поиском по сайту:



©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...