Управление качеством разработки программного обеспечения
advertisement
1 Санкт-Петербургский государственный университет информационных технологий, механики и оптики Учебно-методическое пособие "Управление качеством разработки программного обеспечения" 2 Содержание 1. Введение 2. Основные определения 3. Процесс разработки программного обеспечения 3.1. Жизненный цикл программного обеспечения 3.2. Модели жизненного цикла программного обеспечения 3.2.1. Каскадная модель 3.2.2. Инкрементная модель 3.2.3. Итерационная модель 3.2.4. Спиральная модель 3.2.5. V-модель жизненного цикла 3.2.6. Модель быстрого прототипирования 3.2.7. Agile-методологии 3.2.7.1 Описание методологии 3.2.7.2 Экстремальное программирование - XP 3.2.7.3 Гибкая разработка - SCRUM 3.2.8. Подгонка жизненного цикла разработки 4. Качество программных продуктов 4.1. Определение качества. Стандарты качества 4.2. Стоимость качества 4.3. Введение в CMMI 4.4. Управление требованиями 5. Тестирование программного обеспечения 5.1. Цели и задачи. Основные определения 5.1.1. Методологии тестирования 5.1.2. Уровни тестирования 5.1.3. Виды тестирования 5.2. Процесс тестирования 5.2.1. Этапы и задачи 5.2.2. Принципы организации тестирования 5.2.3. Планирование тестирования 5.2.4. Автоматизация тестирования 5.2.5. Примеры. Модульное тестирование. Разработка через тестирование 5.3. Дефекты. Причины, описания, отслеживание 5.4. Типы дефектов и статические методы тестирования 5.3.1. Классификация дефектов 5.3.2. Инспекции и сквозные просмотры 5.3.3. Проверка «за столом» 5.5. Техники создания тест-кейсов 5.5.1. Проектирование и исполнение 5.5.2. Методология черного ящика 3 6. 7. 8. 9. 5.5.3. Методология белого ящика Приложение 1 – Конфигурационное управление – построение «билдов» Приложение 2 – RUP и UML Приложение 3 – Глоссарий Литература 4 1. Введение Данное учебно-методическое пособие содержит материал для изучения дисциплины "Управление качеством разработки программного обеспечения". В нем освещены вопросы, связанные с обеспечением и контролем качества программного обеспечения в рамках процесса его разработки. Особое внимание уделено процессу тестирования программных продуктов. В курсе "Управление качеством разработки программного обеспечения" тестирование программного обеспечения рассматривается в аспекте жизненного цикла программного обеспечения. Отображены специфика в подходах к организации, базовым принципам и выполнению тестирования в зависимости от применяемой модели жизненного цикла программного обеспечения и методологии разработки. В настоящее время существуют различные значения термина “качество”. Фил Кросби (Phil Crosby) в 1979 году дал определение качеству как “соответствие пользовательским требованиям”. Уотс Хемпфри (Watts Hamphrey, оригинальный автор концепции модели оценки зрелости CMM, а также PSP и TSP – People Software Process и Team Software Process, описывает качество как “достижение отличного уровня пригодности к использованию”. Существуют корпоративные стандарты управления качеством. Так, например, компания IBM ввела в оборот “качество, управляемое рыночными потребностями”. Критерий Бэлдриджа (Baldrige) для организационного качества (National Institute of Standards and Technology, “Baldrige National Quality Program”, http://www.quality.nist.gov) использует похожую фразу - “качество, задаваемое потребителем” (“customer-driven quality”), определяя удовлетворение потребителя основным принципом в отношении качества. Чаще, понятие качества используется в соответствии с определением системы менеджмента качества ISO 9001 как “степень соответствия присущих характеристик требованиям” как это сформулировано в официальном переводе ИСО 9000-2000 "Системы менеджмента качества. Основные положения и словарь”. Интересно, что и сама “степень соответствия” также выступает в роли ограничения проекта, а в приложении к индустрии программного обеспечения представлена практически во всех областях проектной деятельности – от управления требованиями (“атрибуты качества” как категория нефункциональных требований), до тестирования (т.н. наработка на отказ, такие метрики как MTTF - Mean Time To Failure, то есть среднее время между обнаруженными сбоями системы, и т.п.). В какой-то степени, “приемлемое качество” можно сравнивать с уровнем обслуживания в рамках заданного SLA – Service Level 5 Agreement, давно уже принятого на вооружение в телекоммуникационной индустрии. Таким образом, приемлемое качество может рассматриваться как количественно выраженный компромисс между заказчиком и исполнителем в отношении характеристик продукта, создаваемого исполнителем в интересах решения задач заказчика с учетом других ограничений проекта (в частности, стоимостью, что часто именуется как “cost of quality” – “стоимость качества”). Можно сказать, что такой взгляд может в какой-то степени рассматриваться как расширение определения в ISO 9001 с учетом достигнутого компромисса между заказчиком и исполнителем (поставщиком) в отношении характеристик качества. Рассматриваются вопросы качества программного обеспечения, выходящие за рамки отдельных процессов жизненного цикла. Так например, качество программного обеспечения является постоянным объектом внимания программной инженерии и обсуждается во многих областях знаний в сфере информационных технологий, что вполне обосновано, если учесть поистине катастрофический уровень «проваленных» проектов и неудовлетворенность пользователей программных продуктов, ставшая притчей во языцех для программной индустрии. В общем случае, описывается ряд путей достижения качества программного обеспечения. В частности, эта область знаний касается «статических техник», не требующих выполнения (создания) оцениваемых программных систем, в отличие от «динамических техник», рассмотренных в области знаний “Тестирование”. Другой важный стандарт – CMMI, предоставляет рекомендации по совершенствованию процесса. Требуется упомянуть и ISO 15504 “Information Technology - Software Process Assessment”, известный как SPICE - Software Process Improvement and Capability dEtermination. Непосредственно с управлением качеством связаны процессные области (области компетенции) CMMI: обеспечение качества процесса и продукта (process and product quality assurance, категория процессов CMMI “Support”), проверка (verification, категория “Engineering”) и аттестация (validation, категория “Engineering”). При этом, CMMI классифицирует обзор (review) и аудит (audit) в качестве методов верификации, но не как самостоятельные процессы, в отличие, например, от стандарта 12207. Дебаты в отношении того, какой именно стандарт стоит использовать инженерам для обеспечения качества программного обеспечения – CMMI или ISO 9001, продолжаются с самого создания этих стандартов. Сегодня можно сказать о том, что данные стандарты все же рассматривают как взаимодополняющие и, что сертификация 6 по ISO 9001 помогает в достижении старших уровней зрелости по CMMI. SQA (Software Quality Assurance) концентрируется на процессах. Роль SQA состоит в том, чтобы обеспечить соответствующее планирование процессов, дальнейшее исполнение процессов на основе заданного плана и проведение необходимых измерений процессов с передачей результатов измерений заинтересованным сторонам (организационными структурам и лицам). Тестирование, в общем случае, представляет собой деятельность, выполняемую для оценки и улучшения качества программного обеспечения. Эта деятельность, в общем случае, базируется на обнаружении дефектов и проблем в программных системах. Техники управления качеством разделены на статические (без выполнения кода) и динамические (с выполнением кода). Тестирование входит в состав динамических техник. Тестирование программных систем состоит из динамической верификации поведения программ на конечном (ограниченном) наборе тестов, выбранных соответствующим образом из обычно выполняемых действий прикладной области и обеспечивающих проверку соответствия требуемому поведению системы. Как уже отмечалось ранее, тестирование программного обеспечения тесно связано с программированием (ГОСТ 12207). Более того, модульное (unit-) и интеграционное тестирование все чаще рассматривают как неотъемлемый элемент деятельности по конструированию программного обеспечения в SWEBOK. 7 2. Основные определения Программа – последовательность формализованных инструкций, предназначенная для исполнения устройством управления вычислительной машины. Инструкции программы записываются при помощи машинного кода или специальных языков программирования. Программное обеспечение (ПО) - это совокупность всей информации, данных и программ, которые обрабатываются компьютерными системами. На компьютерном жаргоне – часто используется слово «софт» от английского «software» Системное ПО (system software) - это набор программ, которые управляют компонентами вычислительной системы (ОС, драйвера устройств и т.п.). Инструментальное ПО (programming software) - программное обеспечение, предназначенное для использования в ходе проектирования, разработки и сопровождения программ (среда разработки, компиляторы, СУБД, текстовые редакторы и т.п.). Прикладное (специальное) ПО (application software) – программы, предназначенные для выполнения определенных пользовательских задач и расчитанные на непосредственное взаимодействие с пользователем (офисные приложения, бухгалтерские программы, ERP, электронная почта и т.п.). Программный продукт (ПП) - это программное обеспечение, предназначенное для удовлетворения потребностей пользователей широкого распространения и продажи (записанное на носителях данных; снабженное программной документацией). Коробочный программный продукт - это программный продукт, предназначенный для неопределенного круга покупателей и поставляемое на условиях "как есть", со стандартными для всех покупателей функциями. Заказной программный продукт – программный продукт, появление которого обусловлено требованием конкретного заказчика и продажа которого может, по требованию заказчика, сопровождаться проектной доработкой или разработкой функций, дополняющих стандартные (базовые) возможности. Процесс разработки программного продукта – это структура, согласно которой построена разработка программного обеспечения. 8 Жизненный цикл программного обеспечения (ПО) - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации (ISO 12207). Модель жизненного цикла ПП - описание набора фаз (этапов, стадий) проекта по созданию ПО, в которых выполняются отдельные процессы, разбитые на операции и задачи. Проект – это уникальный процесс, в ходе выполнения которого получают уникальный продукт. Проект представляет собой уникальную (в отличие от операций) деятельность, имеющую начало и конец во времени, направленную на достижение определённого результата (цели), создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска. Требование – задокументированная уникальная потребность (необходимость) того, что должен делать конкретный продукт или каким он должен быть. Отладка (Debugging) – деятельность, направленная на установление точной природы известной ошибки, а затем - на исправление этой ошибки. Результаты тестирования являются исходными данными для отладки. Контроль (Verification) – попытка найти ошибки, выполняя программу в тестовой, или смоделированной, среде. Испытание (Validation) – попытка найти ошибки, выполняя программу в заданной реальной среде. 9 3. Процесс разработки программного обеспечения. Промышленное применение компьютеров и растущий спрос на программы поставили актуальные задачи существенного повышения производительности разработки программного обеспечения, разработки индустриальных методов планирования и проектирования программ, переноса организационно-технических, техникоэкономических и социально-психологических приемов, закономерностей и методов из сферы материального производства в сферу применения информационных технологий. Комплексный подход к процессам разработки, эксплуатации и сопровождения программного обеспечения выдвинул ряд насущных проблем, решение которых исключит «узкие места» в процессе разработки программного обеспечения, уменьшит сроки завершения работ. Поскольку компьютерная программа практически любого типа становится изделием - продуктом, подход к ее изготовлению во многом должен быть аналогичен подходу к производству промышленной продукции. Процесс разработки программного продукта – это «организационная структура», согласно которой построена разработка программного обеспечения. Эта структура определяется моделью жизненного цикла ПП. Основные этапы процесса разработки программного обеспечения: Сбор и анализ требований Разработка архитектуры Кодирование Тестирование Документирование Сопровождение 3.1 Жизненный цикл программного обеспечения. Концепция проекта в области информационных технологий описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ), представляя его как последовательность стадий и выполняемых процессов. Для каждого этапа жизненного цикла определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для 10 выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом. Жизненный цикл программного обеспечения - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания программного обеспечения и заканчивается в момент его полного изъятия из эксплуатации. Существует несколько подходов при определении фаз и работ жизненного цикла программного обеспечения, но все они содержат общие основополагающие этапы: постановка задачи = сбор и анализ требований проектирование решения = разработка архитектуры реализация = кодирование, тестирование и документирование эксплуатация = сопровождение Жизненный цикл программного обеспечения начинается с того момента, когда пользователь (заказчик), т.е. тот, кто нуждается в продукте для решения задачи, излагает свою проблему, которую он хочет решить с помощью ПП. Это составляет содержание этапа постановки задачи и определения требований. Определение требований включает описание общего контекста задачи, ожидаемых функций системы и ее ограничений. На данном этапе основную роль играет аналитик, который обладает навыками описания требований в различной форме. В процессе согласования требований со стороны будущей команды разработчиков в обсуждении участвует менеджер проекта, а также, возможно, архитектор, как действующее лицо, способное оценить технические возможности реализации идеи заказчика. Принципиально то, что на данном этапе самого проекта еще нет и можно говорить только о предпроектных работах, в которых участвуют представители будущей команды разработки или специалисты, занимающиеся предпроектной подготовкой. Определение требований в фактических проектах не может ограничиваться лишь предпроектными работами. Для большинства прикладных задач требования поступают в течение всего развития проекта. Постановка задачи является одним из наиболее важных этапов. Она выполняет функции контракта между пользователем и исполнителем. Как и юридически плохо составленный контракт, плохая постановка задачи бесполезна. При хорошей постановке задачи как пользователь, так и команда разработки ясно и недвусмысленно представляют задачу, которую необходимо выполнить, т.е. в этом случае учитываются интересы как 11 пользователя, так и исполнителей. Пользователь может планировать использование еще не созданного программного обеспечения, опираясь на знание того, что оно может. Хорошая постановка задачи служит основой для формирования ее решения. Постановка задачи (спецификация программы), по существу, означает точное, полное и понятное описание того, что происходит при выполнении конкретной программы. Пользователь обычно смотрит на компьютер, как на черный ящик: для него неважно, как работает компьютер, а важно, что может компьютер из того, что интересует пользователя. При этом основное внимание фокусируется на взаимодействии человека с машиной. Характеристики Хорошей Постановки Задачи: Точность, т.е. исключение любой неоднозначности. Не должно возникать вопросов относительно того, каким будет вывод программы при каждом конкретном вводе. Полнота, т.е. рассмотрение всех вариантов для заданного ввода, включая ошибочный или непредусмотренный ввод, и определение соответствующего вывода. Ясность, т.е. она должна быть понятной и пользователю и системному аналитику, поскольку постановка задачи - это единственный контракт между ними. Часто требование точности, полноты и ясности находятся в противоречии. Так, многие юридические документы трудно понять, потому что они написаны на формальном языке, который позволяет предельно точно сформулировать те или иные положения, исключая любые самые незначительные разночтения. Например, некоторые вопросы в экзаменационных билетах иногда сформулированы настолько точно, что студент тратит больше времени на то, чтобы понять вопрос, чем на то чтобы на него ответить. Более того, студент вообще может не уловить основной смысл вопроса из-за большого количества деталей. Наилучшая постановка задачи та, при которой достигается баланс всех трех требований. Разработка проектных решений, отвечающих на вопрос о том, как должна быть реализована система, чтобы она могла удовлетворять специфицированным требованиям, выполняется на этапе проектирования. Поскольку сложность системы в целом может быть очень высока, главной задачей этого этапа является последовательная декомпозиция системы до уровня очевидно реализуемых модулей или 12 процедур. Наиболее активная роль на данном этапе — архитектор, для которого декомпозиция системы есть главная задача в проекте. На следующем этапе – этапе реализации - кодируется каждый из модулей, выявленных при декомпозиции, программируется на наиболее подходящем для данного приложения языке. Основные действующие лица этапа — руководитель команды и разработчики. Традиционно именно данный этап считали основой проекта в целом, что, не отражает современного взгляда на проект. Интеграция построенных и используемых модулей в систему является одним из видов работ этапа реализации. Фаза разработки заканчивается этапом тестирования, главными лицами которой являются инженеры по тестированию и этапом документирования, главными лицами которого являются технические писатели. Фаза эксплуатации и сопровождения включает в себя всю деятельность по обеспечению нормального функционирования программных систем, в том числе фиксирование в скрытых во время исполнения программ ошибок, поиск их причин и исправление, повышение эксплуатационных характеристик системы, адаптацию системы к окружающей среде, а также, при необходимости, и более существенные работы по совершенствованию системы. Все это дает право говорить об эволюции системы. В связи с этим фаза эксплуатации и сопровождения разбивается на два этапа: собственно сопровождение и развитие. В ряде случаев на данную фазу приходится большая часть средств, расходуемых в процессе жизненного цикла программного обеспечения. 3.2 Модели жизненного цикла программного обеспечения. Одним из ключевых понятий управления проектами, в том числе в приложении к индустрии программного обеспечения, является жизненный цикл проекта (Project Life Cycle Management -PLCM). В индустрии программного обеспечения можно (так как это уже конкретная область приложения концепций и практик проектного управления) и необходимо (для обеспечения возможности управления) более четкое разграничение фаз проекта (что не подразумевает их линейного и последовательного выполнения). Ниже приведены определения «модели» жизненного цикла программной системы, даваемые, например, в различных вариантах стандартов ГОСТ: 13 • Модель жизненного цикла - структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования [ГОСТ 12207, 1999]. • Жизненный цикл автоматизированной системы (АС) совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС, от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации АС [ГОСТ 34, 1990]. Один из них - ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий стандарт IEEE 12207. Второй – в рамках семейства ГОСТ 34 – разрабатывался в СССР самостоятельно, как стандарт на содержание и оформление документов на программные системы в рамках Единой системы программной документации (ЕСПД) и Единой системы конструкторской документации (ЕСКД). В последние годы, акцент делается на стандарты ГОСТ, соответствующие международным стандартам. В то же время, 34-я серия является важным дополнительным источником информации для разработки и стандартизации внутрикорпоративных документов и формирования целостного понимания и видения концепций жизненного цикла в области программного обеспечения. В определённом контексте, “модель” и “методология” могут использоваться взаимозаменяемым образом, например, когда мы обсуждаем разграничение фаз проекта. Говоря “жизненный цикл” мы, в первую очередь, подразумеваем “модель жизненного цикла”. Несмотря на данное в стандартах 12207 определение модели жизненного цикла, все же, модель чаще подразумевает именно общий принцип организации жизненного цикла, чем детализацию соответствующих работ. Соответственно, определение и выбор модели, в первую очередь, касается вопросов определенности и стабильности требований, жесткости и детализированности плана работ, а также частоты сборки работающих версий создаваемой программной системы. Скотт Амблер (Scott W. Ambler), автор концепций и практик гибкого моделирования (Agile Modeling) и Enterprise Unified Process (расширение Rational Unified Process), предлагает следующие уровни жизненного цикла, определяемые соответствующим содержанием работ: 14 • Жизненный цикл разработки программного обеспечения – проектная деятельность по разработке и развертыванию программных систем • Жизненный цикл программной системы – включает разработку, развертывание, поддержку и сопровождение • Жизненный цикл информационных технологий (ИТ) – включает всю деятельность ИТ-департамента • Жизненный цикл организации – охватывает всю деятельность организации в Целом Общая иерархия (декомпозиция) составных жизненного цикла выглядит следующим образом: группа процессов процессы работы задачи элементов В общем случае, разбиение процесса базируется на широко распространенном PDCA-цикле: • “P” – Plan – Планирование • “D” – Do – Выполнение • “C” – Check – Проверка • “A” – Act – Реакция (действие) Модель жизненного цикла отражает различные состояния программного продукта, начиная с момента возникновения необходимости в данном продукте и заканчивая моментом его полного выхода из употребления. Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования. «Подходящая» модель жизненного цикла: направляет проект улучшает скорость разработки улучшает отслеживание и контроль над проектом минимизирует издержки и влияние рисков улучшает отношение с клиентом 15 «Неподходящая» модель ЖЦ: замедляет выполнение работ вынуждает делать лишнюю работу проект оказывается неуспешным 3.2.1 Каскадная модель (1970, W.W. Royce) В первые годы практики программирования сначала записывался программный код, а затем происходила его отладка. Общепринятым считалось правило начинать работу не с разработки плана, а с общего ознакомления с продуктом. Без лишних формальностей можно было спроектировать, закодировать, отладить и протестировать программного обеспечения еще до того, как оно будет готово к выпуску. В структуре такого процесса есть несколько "неправильностей" (или недостатков). Во-первых, поскольку изначально не существовало официального проекта или анализа, невозможно было узнать о моменте завершения процесса. Также отсутствовал способ определения соответствия требованиям относительно достижения качества. В 1970 году каскадная модель была впервые определена как альтернативный вариант метода разработки программного обеспечения по принципу кодирование-устранение ошибок, который был широко распространен в то время. Это была первая модель, которая формализовала структуру этапов разработки программного обеспечения, придавая особое значение исходным требованиям и проектированию, а также созданию документации на ранних этапах процесса разработки. Каскадная модель (или «водопадная модель», waterfall) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Характерна для периода 1970-1985 гг. 16 Рис. 1. Каскадная модель. На начальном периоде каскадная модель сыграла ведущую роль как метод регулярной разработки сложного программного обеспечения. В семидесятых-восьмидесятых годах XX века модель была принята как стандарт министерства обороны США. Со временем недостатки каскадной модели стали проявляться все чаще и возникло мнение, что она безнадежно устарела. Между тем, каскадная модель не утратила своей актуальности при решении следующих типов задач: Требования и их реализация максимально четко определены и понятны; используется неизменяемое определение продукта и вполне понятные технические методики. Это задачи типа: o научно-вычислительного характера (пакеты и библиотеки научных программ типа расчета несущих конструкций зданий, мостов и т.д.) o операционные системы и компиляторы o системы реального времени управления конкретными объектами Кроме того, каскадная модель применима в условиях: повторная разработка типового продукта (автоматизированного бухгалтерского учета, системы электронного документооборота и т.п.) выпуск новой версии уже существующего продукта, если вносимые изменения вполне определены и управляемы (миграция уже существующего продукта на новую платформу) Принципы каскадной модели находят применение как элементы моделей других типов, о чем речь пойдет ниже (где перечислить разделы). 17 Можно выделить следующие положительные стороны применения каскадного подхода: на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Каскадный подход хорошо зарекомендовал себя при построении относительно простых систем, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе. Основным недостатком этого подхода является то, что реальный процесс создания системы никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания программного обеспечения оказывается соответствующим поэтапной модели с промежуточным контролем Каскадная модель имеет следующие преимущества: Проста и понятна заказчикам, т.к часто используется другими организациями для отслеживания проектов, не связанных с разработкой программного обеспечения Проста и удобна в применении: o процесс разработки выполняется поэтапно. o ее структурой может руководствоваться даже слабо подготовленный в техническом плане или - неопытный персонал; o она способствует осуществлению строгого контроля менеджмента проекта; Каждую стадию могут выполнять независимые команды (все документировано) Позволяет достаточно точно планировать сроки и затраты При использовании каскадной модели для «неподходящего» проекта могут проявляться следующие ее основные недостатки: Попытка вернуться на одну или две фазы назад, чтобы исправить какую-либо проблему или недостаток, приведет к значительному увеличению затрат и сбою в графике; 18 Интеграция компонент, на которой обычно выявляется большая часть ошибок, выполняется в конце разработки, что сильно увеличивает стоимость устранения ошибок; Запаздывание с получением результатов – если в процессе выполнения проекта требования изменились, то получится устаревший результат Недостатки каскадной модели особо остро проявляются в случае, когда трудно (или невозможно) сформулировать требования или требования могут меняться в процессе выполнения проекта. В этом случае разработка программного обеспечения имеет принципиально циклический характер. 3.2.2. Инкрементная модель жизненного цикла разработки программного обеспечения Инкрементная разработка представляет собой процесс частичной реализации всей системы и постепенного наращивания функциональных возможностей. Этот подход позволяет уменьшить затраты, понесенные до момента достижения уровня исходной производительности. С помощью этой модели ускоряется процесс создания функционирующей системы. Этому способствует применяемый принцип компоновки из стандартных блоков, благодаря которому обеспечивается контроль над процессом разработки изменяющихся требований. Инкрементная модель действует по принципу каскадной модели с перекрытиями, благодаря чему функциональные возможности продукта, пригодные к эксплуатации, формируется раньше. Для этого может понадобиться полный заранее сформированный набор требований, которые выполняются в виде последовательных, небольших по размеру проектов, либо выполнение проекта может начаться с формулирования общих целей, которые затем уточняются и реализуются группами разработчиков. Подобное усовершенствование каскадной модели одинаково эффективно при использовании как в случае чрезвычайно больших, так и небольших проектов. А теперь будет рассмотрен небольшой пример продукта, разработанного в результате выполнения трех инкрементных этапов. Здесь на инкременте 1 определяются базовые алгоритмы и выходные 19 данные, на инкременте 2 добавляются некоторые ценные возможности производственного типа, такие как возможность занесения в файл и выборки результатов предыдущих прогонов программы, а на инкременте 3 добавляются различные полезные свойства к пользовательскому интерфейсу, а также к заранее определенным вычислительным свойствам системы. Инкрементная модель описывает процесс, при выполнении которого первостепенное внимание уделяется системным требованиям, а затем их реализации в группах разработчиков. Как правило, со временем инкременты уменьшаются и реализуют каждый раз меньшее количество требований. Каждая последующая версия системы добавляет к предыдущей определенные функциональные возможности до тех пор, пока не будут реализованы все запланированные возможности. В этом случае можно уменьшить затраты, контролировать влияние изменяющихся требований и ускорить создание функциональной системы благодаря использованию метода компоновки из стандартных блоков. Рис. 2. Инкрементная модель Анализ требований Требования и планирование Анализ требований Анализ требований Проектирование Инкремент 3 Инкремент 2 Инкремент 1 Разработка тестов Кодирование Выходное тестиров. Сборка Интеграц. тестир. Выходное тестиров. Выходное тестиров. Производство, эксплуатация Предполагается, что на ранних этапах жизненного цикла (планирование, анализ и разработка проекта) выполняется конструирование системы в целом. На этих этапах определяются относящиеся к ним инкременты и функции. 20 Каждый инкремент затем проходит через остальные фазы жизненного цикла: кодирование, тестирование и поставку. Сначала выполняется конструирование, тестирование и реализация набора функций, формирующих основу продукта, или требований первостепенной важности, играющих основную роль для успешного выполнения проекта либо снижающих степень риска. Последующие итерации распространяются на ядро системы, постепенно улучшая ее функциональные возможности или рабочую характеристику. Добавление функций осуществляется с помощью выполнения существенных инкрементов с целью в комплексного удовлетворения потребностей пользователя. Каждая дополнительная функция аттестуется в соответствии с целым набором требований. Применяя инкрементную модель при разработке проекта, для которого она подходит в достаточной мере, можно убедиться в следующих ее преимуществах: не требуется заранее тратить средства, необходимые для разработки всего проекта (поскольку сначала выполняется разработка и реализация основной функции или функции из группы высокого риска); в результате выполнения каждого инкремента получается функциональный продукт; заказчик располагает возможностью высказаться по поводу каждой разработанной версии системы; правило по принципу "разделяй и властвуй" позволяет разбить возникшую проблему на управляемые части, благодаря чему предотвращается формирование громоздких перечней требований, выдвигаемых перед командой разработчиков; существует возможность поддерживать постоянный прогресс в ходе выполнения проекта; снижаются затраты на первоначальную поставку программного продукта; ускоряется начальный график поставки (что позволяет соответствовать возросшим требованиям рынка); снижается риск неудачи и изменения требований; заказчики могут распознавать самые важные и полезные функциональные возможности продукта на более ранних этапах разработки; риск распределяется на несколько меньших по размеру инкрементов (не сосредоточен в одном большом проекте разработки); 21 требования стабилизируются (посредством включения в процесс пользователей) на момент создания определенного инкремента, поскольку не являющиеся особо важными изменения отодвигаются на момент создания последующих инкрементов; инкременты функциональных возможностей несут больше пользы и проще при тестировании, чем продукты промежуточного уровня при по-уровневой разработке по принципу "сверху-вниз" улучшается понимание требований для более поздних инкрементов (что обеспечивается благодаря возможности пользователя получить представление о раннее полученных инкрементов на практическом уровне); в конце каждой инкрементной поставки существует возможность пересмотреть риски, связанные с затратами и соблюдением установленного графика; использование последовательных инкрементов позволяет объединить полученный пользователями опыт в виде усовершенствованного продукта, затратив при этом намного меньше средств, чем требуется для выполнения повторной разработки; в процессе разработки можно ограничить количество персонала таким образом, чтобы над поставкой каждого инкремента последовательно работала одна и та же команда и все задействованные в процессе разработки команды не прекращали работу над проектом (график распределения рабочей силы может выравниваться посредством распределения по времени объема работы над проектом); возможность начать построение следующей версии проекта на переходном этапе предыдущей версии сглаживает изменения, вызванные сменой персонала; в конце каждой инкрементной поставки существует возможность пересмотреть риски, связанные с затратами и соблюдением установленного графика; потребности клиента лучше поддаются управлению, поскольку время разработки каждого инкремента очень незначительно; поскольку переход из настоящего в будущее не происходит моментально, заказчик может привыкать к новой технологии постепенно; ощутимые признаки прогресса при выполнении проекта помогают поддерживать вызванное соблюдением графика "давление" на управляемом уровне. 22 При использовании этой модели относительно проекта, для которого она подходит не в достаточной мере, проявляются следующие недостатки: в модели не предусмотрены итерации в рамках каждого инкремента; определение полной функциональной системы должно осуществляться в начале жизненного цикла, чтобы обеспечить определение инкрементов; формальный критический анализ и проверку намного труднее выполнить для инкрементов, чем для системы в целом; заказчик должен осознавать, что общие затраты на выполнение проекта не будут снижены; поскольку создание некоторых модулей будет завершено значительно раньше других, возникает необходимость в четко определенных интерфейсах; использование на этапе анализа общих целей, вместо полностью сформулированных требований, может оказаться неудобным для руководства; для модели необходимы хорошее планирование и проектирование: руководство должно заботиться о распределении работы, а технический персонал должен соблюдать субординацию в отношениях между сотрудниками. может возникнуть тенденция к оттягиванию решений трудных проблем на будущее с целью продемонстрировать руководству успех, достигнутый на ранних этапах разработки; Менеджер проекта может быть уверен в целесообразности применения модели, если для этого имеются следующие причины: если большинство требований можно сформулировать заранее, но их появление ожидается через определенный период времени; если рыночное окно слишком "узкое" и существует потребность быстро поставить на рынок продукт, имеющий функциональные базовые свойства; для проектов, на выполнение которых предусмотрен большой период времени разработки, как правило, один год; при равномерном распределении свойств различной степени важности; когда при рассмотрении риска, финансирования, графика выполнения проекта, размера программы, ее сложности или 23 необходимости в реализации на ранних фазах оказывается, что самым оптимальным вариантом является применение принципа по-фазовой разработки; при разработке программ, связанных с низкой или средней степенью риска; при выполнении проекта с применением новой технологии, что позволяет пользователю адаптироваться к системе путем выполнения более мелких инкрементных шагов, без резкого перехода к применению основного нового продукта; когда однопроходная разработка системы связана с большой степенью риска; когда результативные данные получаются через регулярные интервалы времени. 3.2.3 Итерационная модель Общепринятая модель жизненного цикла не является идеальной уже потому, что только очень простые задачи проходят все этапы без каких-либо итераций — возвратов на предыдущие шаги производственного процесса. При кодировании, например, может обнаружиться, что реализация некоторой функции очень громоздка, неэффективна и вступает в противоречие с требуемой от системы производительности. В этом случае необходимо перепроектирование, а может быть, и переделка спецификаций. При разработке больших нетрадиционных систем итеративность возникает регулярно на любом этапе жизненного цикла как из-за допущенных на предыдущих шагах ошибок и неточностей, так и из-за изменений внешних требований к условиям эксплуатации системы. 24 Рис. 3. Итерационная модель. Стрелки, идущие вверх, обозначают возвраты к предыдущим этапам, квалифицируемые как требование повторить этап для исправления обнаруженной ошибки. В связи c этим может показаться странным переход от этапа "Эксплуатация и сопровождение" к этапу "Тестирование и отладка". Дело в том, что рекламации, предъявляемые в ходе эксплуатации системы, часто даются в такой форме, что нуждаются в перепроверке. Чтобы понять, о каких ошибках идет речь в рекламации, разработчикам полезно предварительно воспроизвести пользовательскую ситуацию у себя, т.е. выполнить действия, которые обычно относят к тестированию. Классическая итерационная модель абсолютизирует возможность возвратов на предыдущие этапы. Однако это обстоятельство отражает существенный недостаток программных разработок, проводимых в традиционном стиле: стремление заранее предвидеть все ситуации использования системы и невозможность в подавляющем большинстве случаев достичь этого. Все подобные методологии программирования направлены лишь на то, чтобы минимизировать возвраты. Но суть от этого не меняется: при возврате всегда приходится повторять построение того, что уже считалось готовым. Иначе обстоит дело с методологиями, которые реализуют поддержку итерационного развития проектов. В этом случае отказываются от завершенности фаз и этапов, вместо чего предлагается распределять наращивание функциональности и 25 интерфейсных возможностей по итерациям. В результате можно ослабить требование переделки старого при возвратах. По существу, классическая схема остается верной, но только в рамках одной итерации и с одной важной поправкой: все полезное, что было сделано ранее, сохраняется. 3.2.4 Спиральная модель (Бари Боэм, 1988.) На практике, при решении достаточно большого количества задач, разработка ПО имеет циклический характер, когда после выполнения некоторых стадий приходится возвращаться на предыдущие. Можно указать две основные причины таких возвратов: Ошибки разработчиков, допущенные на ранних стадиях и выявленные на поздних стадиях – ошибки анализа, проектирования, кодирования, выявляемые, как правило, на стадии тестирования. Изменение требований в процессе разработки («ошибки» заказчиков). Это или неготовность заказчиков сформулировать требования («Сказать, что должна делать программа я смогу только после того, как увижу как она работает»), или изменения требований, вызванные изменениями ситуации в процессе разработки (изменения рынка, новые технологии, …). Циклический характер разработки программного обеспечения отражен в спиральной модели ЖЦ, описанной Б. Боэмом в 1988 году. Спиральная модель была предложена как альтернатива каскадной модели, учитывающая повторяющийся характер разработки программного обеспечения. Основные принципы спиральной модели можно сформулировать следующим образом: Разработка вариантов продукта, соответствующих различным вариантам требований с возможностью вернуться к более ранним вариантам Создание прототипов программного обеспечения как средства общения с заказчиком для уточнения и выявления требований Планирование следующих вариантов с оценкой альтернатив и анализом рисков, связанных с переходом к следующему варианту Переход к разработке следующего варианта до завершения предыдущего в случае, когда риск завершения очередного варианта (прототипа) становится неоправданно высок. 26 Использование каскадной модели как схемы разработки очередного варианта Активное привлечение заказчика к работе над проектом. Заказчик участвует в оценке очередного прототипа программного обеспечения, уточнении требований при переходе к следующему, оценке предложенных альтернатив очередного варианта и оценке рисков. Схема работы спиральной модели выглядит следующим образом. Разработка вариантов продукта представляется как набор циклов раскручивающейся спирали. Каждому циклу спирали соответствует такое же количество стадий, как и в модели каскадного процесса. При этом, начальные стадии, связанные с анализом и планированием представлены более подробно с добавлением новых элементов. В каждом цикле спиральной модели выделяются четыре базовые фазы: определение целей, альтернативных вариантов и ограничений. оценка альтернативных вариантов, идентификация и разрешение рисков. разработка продукта следующего уровня. планирование следующей фазы. Рис. 4. Циклы спиральной модели. Определение целей, альтернатив, ограничений Суммарная стоимость Оценка альтернатив выявить и устранить риски Анализ рисков Анализ рисков АР АР Треб, План Сборка и ЖЦ Прототип П2 П1 Концеп. Треб. к ПО разработ. Проверка треб. тестирование Проверка проекта Планирование следующих фаз Внедр. Рабочий прототип 3 Проект Детальн. проект ПО Кодиров. Мод. Сборка тестир. Разработка следущего уровня 27 «Раскручивание» проекта начинается с анализа общей постановки задачи на разработку программного обеспечения. Здесь на первой фазе определяются общие цели, устанавливаются предварительные ограничения, определяются возможные альтернативы подходов к решению задачи. Далее проводится оценка подходов, устанавливаются их риски. На шаге разработки создается концепция (видение) продукта и путей его создания. Следующий цикл начинается с планирования требований и деталей жизненного цикла продукта для оценки затрат: На фазе определения целей устанавливаются альтернативные варианты требований, связанные с аранжировкой требований по важности и стоимости их выполнения. На фазе оценки устанавливаются риски вариантов требований. На фазе разработки – спецификация требований (с указанием рисков и стоимости), готовится демо-версия программного обеспечения для анализа требований заказчиком. Следующий цикл – разработка проекта – начинается с планирования разработки: На фазе определения целей устанавливаются ограничения проекта (по срокам, объему финансирования, ресурсам,…), определяются альтернативы проектирования, связанные с альтернативами требований, применяемыми технологиями проектирования, привлечением субподрядчиков, … На фазе оценки альтернатив устанавливаются риски вариантов и делается выбор варианта для дальнейшей реализации. На фазе разработки выполняется проектирование и создается демо-версия, отражающая основные проектные решения. Следующий цикл – реализация программного обеспечения – также начинается с планирования. Альтернативными вариантами реализации могут быть применяемые технологии реализации, привлекаемые ресурсы. Оценка альтернатив и связанных с ними рисков на этом цикле определяется степенью «отработанности» технологий и «качеством» имеющихся ресурсов. Фаза разработки выполняется по каскадной модели с выходом – действующим вариантном (прототипом) продукта. Отметим некоторые особенности спиральной модели: До начала разработки программного обеспечения есть несколько полных циклов анализа требований и проектирования. 28 Количество циклов модели (как в части анализа и проектирования, так и в части реализации) не ограничено и определяется сложностью и объемом задачи В модели предполагаются возвраты на оставленные варианты при изменении стоимости рисков. Спиральная модель (по отношению к каскадной) имеет следующие очевидные преимущества: Более тщательное проектирование (несколько начальных итераций) с оценкой результатов проектирования, что позволяет выявить ошибки проектирования на более ранних стадиях. Поэтапное уточнение требований в процессе выполнения итераций, что позволяет более точно удовлетворить требованиям заказчика Участие заказчика в выполнении проекта с использованием прототипов программы. Заказчик видит, что и как создается, не выдвигает необоснованных требований, оценивает реальные объемы финансирования. Планирование и управление рисками при переходе на следующие итерации позволяет разумно планировать использование ресурсов и обосновывать финансирование работ. Возможность разработки сложного проекта «по частям», выделяя на первых этапах наиболее значимые требования. Основные сложностью: недостатки спиральной модели связаны с ее Сложность анализа и оценки рисков при выборе вариантов. Сложность поддержания версий продукта (хранение версий, возврат к ранним версиям, комбинация версий) Сложность оценки точки перехода на следующий цикл Бесконечность модели – на каждом витке заказчик может выдвигать новые требования, которые приводят к необходимости следующего цикла разработки. Спиральную модель целесообразно применять при следующих условиях: Когда пользователи не уверены в своих потребностях или когда требования слишком сложны и могут меняться в процессе выполнения проекта и необходимо прототипирование для анализа и оценки требований. 29 Когда достижение успеха не гарантировано и необходима оценка рисков продолжения проекта. Когда проект является сложным, дорогостоящим и обоснование его финансирования возможно только в процессе его выполнения Когда речь идет о применении новых технологий, что связано с риском их освоения и достижения ожидаемого результата При выполнении очень больших проектов, которые в силу ограниченности ресурсов можно делать только по частям. 3.2.5 V-модель жизненного цикла V-образная модель жизненного цикла была создана с целью помочь работающей над проектом команде в планировании с обеспечением дальнейшей возможности тестирования системы. В этой модели особое значение придается действиям, направленным на верификацию и аттестацию продукта. Она демонстрирует, что тестирование продукта обсуждается, проектируется и планируется на ранних этапах жизненного цикла разработки. План испытания приемки заказчиком разрабатывается на этапе планирования, а компоновочного испытания системы - на фазах анализа, разработки проекта и т.д. Этот процесс разработки планов испытания обозначен пунктирной линией между прямоугольниками V-образной модели. V-образная модель была разработана как разновидность каскадной модели, а значит, унаследовала от нее такую же последовательную структуру. Каждая последующая фаза начинается по завершению получения результативных данных предыдущей фазы. Модель демонстрирует комплексный подход к определению фаз процесса разработки программного обеспечения. В ней подчеркнуты взаимосвязи, существующие между аналитическими фазами и фазами проектирования, которые предшествуют кодированию, после которого следуют фазы тестирования. Пунктирные линии означают, что эти фазы необходимо рассматривать параллельно. 30 Рис. 5. V-модель жизненного цикла. Планирование проекта и требований Производство, эксплуатация и сопровождение Анализ требований продукта и спецификаций Системное и приемочное тестирование Разработка архитектурного продукта на высшем уровне Интеграция и тестирование Детализованная разработка Модульное тестирование Написание кода Ниже дано краткое описание каждой фазы V-образной модели, начиная от планирования проекта и требований вплоть до приемочных испытаний: планирование проекта и требований – определяются системные требования, а также то, каким образом будут распределены ресурсы организации с целью их соответствия поставленным требованиям. (в случае необходимости на этой фазе выполняется определение функций для аппаратного и программного обеспечения); анализ требований к продукту и его спецификации – анализ существующей на данный момент проблемы с программного обеспечения, завершается полной спецификацией ожидаемой внешней линии поведения создаваемой программной системы; архитектура или проектирование на высшем уровне – определяет, каким образом функции программного обеспечения должны применяться при реализации проекта; детализированная разработка проекта – определяет и документально обосновывает алгоритмы для каждого компонента, который был определен на фазе построения 31 архитектуры. Эти алгоритмы в последствии будут преобразованы в код; разработка программного кода – выполняется преобразование алгоритмов, определенных на этапе детализированного проектирования, в готовое программного обеспечения; модульное тестирование – выполняется проверка каждого закодированного модуля на наличие ошибок; интеграция и тестирование – установка взаимосвязей между группами ранее поэлементно испытанных модулей с целью подтверждения того, что эти группы работают также хорошо, как и модули, испытанные независимо друг от друга на этапе поэлементного тестирования; системное и приемочное тестирование – выполняется проверка функционирования программной системы в целом (полностью интегрированная система), после помещения в ее аппаратную среду в соответствии со спецификацией требований к ПО; производство, эксплуатация и сопровождение – программное обеспечение запускается в производство. На этой фазе предусмотрены также модернизация и внесение поправок; приемочные испытания (на рис. не показаны) – позволяет пользователю протестировать функциональные возможности системы на соответствие исходным требованиям. После окончательного тестирования программного обеспечения и окружающее его аппаратное обеспечение становятся рабочими. После этого обеспечивается сопровождение системы. При использовании V-образной модели при разработке проекта, для которого она в достаточной мере подходит, обеспечивается несколько преимуществ: в модели особое значение придается планированию, направленному на верификацию и аттестацию разрабатываемого продукта на ранних стадиях его разработки. Фаза модульного тестирования подтверждает правильность детализированного проектирования. Фазы интеграции и тестирования реализуют архитектурное проектирование или проектирование на высшем уровне. Фаза тестирования системы подтверждает правильность выполнения этапа требований к продукту и его спецификации; в модели предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта; 32 в V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование программного обеспечения — перед разработкой компонентов; модель определяет продукты, которые должны быть получены в результате процесса разработки, причем каждые полученные данные должны подвергаться тестированию; благодаря модели менеджеры проекта может отслеживать ход процесса разработки, так как в данном случае вполне возможно воспользоваться временной шкалой, а завершение каждой фазы является контрольной точкой; модель проста в использовании (относительно проекта, для которого она является приемлемом). При использовании V-образной модели в работе над проектом, для которого она не является в достаточной степени приемлемой, становятся очевидными ее недостатки: с ее помощью непросто справиться с параллельными событиями; в ней не учтены итерации между фазами; в модели не предусмотрено внесение требования динамических изменений на разных этапах жизненного цикла; тестирование требований в жизненном цикле происходит слишком поздно, вследствие чего невозможно внести изменения, не повлияв при этом на график выполнения проекта; в модель не входят действия, направленные на анализ рисков. Графически модель зачастую изображается (как показано на рис. 4) без указания интегральных задач. Этот вопрос достаточно легко решается, он здесь упоминается только для того, чтобы напомнить читателю о том, что интегральные задачи имеют место при использовании всех моделей жизненного цикла. С целью преодоления этих недостатков V-образную модель можно модифицировать, включив в нее итерационные циклы, предназначенные для разрешения изменений в требованиях за рамками фазы анализа. Подобно своей предшественнице, каскадной модели, V-образная модель лучше всего срабатывает тогда, когда вся информация о требованиях доступна заранее. Общераспространенная модификация V-образной модели, направленная на преодоление ее недостатков, 33 включает в себя внесение итерационных циклов для разрешения изменения в требованиях за рамками фазы анализа. Использование модели эффективно в том случае, когда доступными являются информация о методе реализации решения и технология, а персонал владеет необходимыми умениями и опытом в работе с данной технологией. V-образная модель — это отличный выбор для систем, в которых требуется высокая надежность, таких как прикладные программы для наблюдения за пациентами в клиниках, а также встроенное программного обеспечения для устройств управления аварийными подушками безопасности в автомобилях. 3.2.6 Модель быстрого прототипирования Модель быстрого протитипирования предназначена для быстрого создания прототипов продукта с целью уточнения требований и поэтапного развития прототипов в конечный продукт. Скорость (высокая производительность) выполнения проекта обеспечивается планированием разработки прототипов и участием заказчика в процессе разработки. Начало жизненного цикла разработки помещено в центре эллипса. Совместно с пользователем разрабатывается предварительный план проекта на основе предварительных требований. Результат начального планирования - документ, описывающий в общих чертах примерные графики и результативные данные. Следующий уровень – создание исходного прототипа на основе быстрого анализа, проекта база данных, пользовательского интерфейса и некоторых функций. Затем начинается итерационный цикл быстрого прототипирования. Разработчик проекта демонстрирует очередной прототип, пользователь оценивает его функционирование, совместно определяются проблемы и пути их преодоления для перехода к следующему прототипу. Этот процесс продолжается до тех пор, пока пользователь не согласится, что очередной прототип в точности отображает все требования. Получив одобрение пользователя, быстрый прототип преобразуют детальный проект, и систему настраивают на производственное использование. Именно на этом этапе настройки ускоренный прототип становится полностью действующей системой. При разработке производственной версии программы, может понадобиться более высокий уровень функциональных возможностей, 34 различные системные ресурсы, необходимых для обеспечения полной рабочей нагрузки, или ограничения во времени. После этого следуют тестирование в предельных режимах, определение квалификационных критериев и настройка, а затем, как обычно, функциональное сопровождение. 3.2.7 Agile методологии 3.2.7.1 Описание методологии Эти адаптивные модели также носят название моделей "скоростного" жизненного цикла (Bullock 2003). В 2001 году группой, состоявшей из 17 представителей пользователей этой адаптивной модели жизненного цикла был выпущен "Манифест скоростной разработки программного обеспечения", и эта инициатива получила широкое развитие в отрасли информационных технологий. Гибкая методология разработки (англ. Agile software development) — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения. Существует несколько подобных методик. Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи миниприроста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки. Agile методы делают упор на непосредственное общение лицом к лицу. Большинство agile команд расположены в одном офисе. Как минимум она включает и «заказчиков» (заказчики которые определяют продукт, также это могут быть менеджеры продукта, бизнес аналитики или клиенты). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров. Основной метрикой agile методов является рабочий продукт. Отдавая предпочтение непосредственному общению agile методы уменьшают объем письменной документации по сравнению с другими методами, но не исключают их. 35 Если рассмотреть пары связей: люди и взаимодействие - процессы и инструменты работающий продукт - обширная документация сотрудничество с заказчиком - детали контракта готовность к изменениям - следование плану, то можно сказать, что в agile методологиях мы, признавая, что правая часть тезисов важна, все-таки больше ценим их левую часть. Существует более 15 agile методологий. Самые распространенные: • XP • Scrum Как утверждают сторонники быстрого развития, их методологии не нуждаются в том, чтобы четко фиксировать этапы развития разработки программного проекта. Однако они понимают, что само понятие жизненного цикла полезно для представления процесса разработки в концептуальном плане. Что же касается деятельности менеджера, то в этом подходе в противовес жестким методологиям провозглашаются самодисциплина и сотрудничество вместо дисциплины и подчинения; планирование, контрольные и другие функции носят здесь такой характер, который позволяет менеджеру в большей мере сосредоточиться на руководстве командой, чем на управлении. В результате отслеживание процесса не требует, к примеру, специальных документов о достигнутых результатах и проблемах, для которых нужна специальная поддержка. По этой причине модели жизненного цикла быстрого развития не претендуют на инструментальность, и в таком ключе их рассматривать не имеет смысла. Тем не менее, понятия контрольных точек и контрольных мероприятий, распределения ресурсов, оценки остаются, хотя их содержание становится менее формализованным. Жизненный цикл любой методологии быстрого развития можно описать следующим образом. Начальная фаза. Она выделена, поскольку приходится выполнять работы, которые не являются характерными для основного процесса. Серия максимально коротких итераций, состоящих из шагов: o выбор реализуемых требований (в экстремальном программировании — пользовательских историй); 36 реализация только отобранных требований; o передача результата для практического использования; o короткий период оценки достигнутого (в зависимости от объема работ периода его можно назвать этапом или контрольным мероприятием). Фаза заключительной оценки разработки проекта. o Реальные быстрые методологии конкретизируют эту схему, дополняют ее теми или иными методиками. До последнего времени быстрые процессы было не принято формализовать настолько, чтобы их можно было предлагать в качестве стандарта. И сегодня не приходится говорить, например, о сертификации команды как "правильно" работающей по быстрой методологии, подобном тому, что требует CMM. Тем не менее, вопрос о сертификации быстрого процесса приобретает актуальность — складывается своеобразная мода на гибкие методологии, отрицательно сказывающаяся на престиже подхода в целом. Стремление к сертификации сдвигает границу между гибкими и жесткими методологиями в сторону последних, и есть опасения, что в результате быстрые подходы станут формализованными до такой степени, что их нельзя уже будет называть гибкими. Эта проблема отмечалась во многих докладах на конференции сторонников обсуждаемого подхода Extreme Programming and Agile Methods — XP/Agile Universe 2003. Тем не менее в 2003 появилась компания, выполняющая проекты по методологии экстремального программирования, которая получила сертификат по одному из общепризнанных стандартов ISO 9001:2000, свидетельствующий об определенных гарантиях качества организации проектной деятельности и получаемых результатов. Это произошло по прошествии примерно года с момента подачи заявки на сертификацию. Все, что для этого потребовалось сделать, свелось к приведению соответствия между процессами экстремального программирования и поддерживаемыми стандартом. В остальном процедура сертификации не нарушила процессы производства программ в компании. Не потребовалось никакой настройки процесса, доведения его до требований стандарта. Не претерпела изменений база данных, в которой сохранялись пользовательские истории со сведениями о работе с ними. Документация, предназначенная для пользователей, построенная на базе априорного тестирования, признана соответствующей требованиям качества и т.д. 3.2.7.2 Экстремальное программирование - Extreme Рrogramming (XP) 37 Экстремальное программирование (Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. (авторы Кент Бек, Уорд Каннингем, Мартин Фаулер и другие, 1996-1999) Двенадцать основных практики экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы: Короткий цикл обратной связи (Fine scale feedback) o Разработка через тестирование (Test driven development) o Игра в планирование (Planning game) o Заказчик всегда рядом (Whole team, Onsite customer) o Парное программирование (Pair programming) Непрерывный, а не пакетный процесс o Непрерывная интеграция (Continuous Integration) o Рефакторинг (Design Improvement, Refactor) o Частые небольшие релизы (Small Releases) Понимание, разделяемое всеми o Простота (Simple design) o Метафора системы (System metaphor) o Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership) o Стандарт кодирования (Coding standard or Coding conventions) Социальная защищенность программиста (Programmer welfare): o 40-часовая рабочая неделя (Sustainable pace, Forty hour week) Ниже дано описание практик, которые активно используются и в других моделях для повышения качества продукта. Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего. При необходимости клавиатура свободно передается от одного к другому. В течение работы над проектом пары не фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление о всей системе. Таким образом, 38 парное программирование команды. усиливает взаимодействие внутри Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы. Парное программирование поддерживает эту практику: работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом — в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист. Давая каждому программисту право изменять код, мы получаем риск появления ошибок, вносимых программистами, которые считают что знают что делают, но не рассматривают некоторые зависимости. Хорошо определённые UNIT-тесты решают эту проблему: если не рассмотренные зависимости порождают ошибки, то следующий запуск UNIT-тестов будет неудачным. Заказчик всегда рядом. «Заказчик» в XP — это не тот, кто оплачивает счета, а тот, кто на самом деле использует систему. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов. Рефакторинг — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести к существенной перестройке программы и улучшению её согласованности и четкости. Рефакторинг позволяет разрабатывать архитектуру программы постепенно, откладывая проектные решения до тех пор, пока не станет более ясной их необходимость. Автоматическое юнит-тестирование позволяет убедиться, что рефакторинг не разрушил существующую функциональность. Иногда под рефакторингом неправильно подразумевают коррекцию кода с заранее оговоренными правилами отступа, перевода строк, внесения комментариев и прочими визуально значимыми изменениями, которые никак не отражаются на процессе компиляции, с целью обеспечения лучшей читаемости кода Цель рефакторинга - сделать код программы более легким для понимания; без этого рефакторинг нельзя считать успешным. 39 Рефакторинг следует отличать от оптимизации производительности. Как и рефакторинг, оптимизация обычно не изменяет поведение программы, а только ускоряет ее работу. Но оптимизация часто затрудняет понимание кода, что противоположно рефакторингу. С другой стороны, нужно отличать рефакторинг от реинжиниринга, который осуществляется для расширения функциональности программного обеспечения. Как правило, крупные рефакторинги предваряют реинжиниринг. Рефакторинг нужно применять постоянно при разработке кода. Основными стимулами его проведения являются следующие задачи: 1. Необходимо добавить новую функцию, которая не достаточно укладывается в принятое архитектурное решение 2. Необходимо исправить ошибку, причины возникновения которой сразу не ясны 3. Когда сложно объяснить коллеге логику работы программы Во многом, при рефакторинге лучше полагаться на интуицию, основанную на опыте. Но можно выделить наиболее очевидные причины, когда код нужно подвергнуть рефакторингу: Дублирование кода Длинный метод Большой класс Длинный список параметров "Завистливые" функции - это метод, который чрезмерно обращается к данным другого объекта 6. Избыточные временные переменные 7. Классы данных 8. Не сгруппированные данные 1. 2. 3. 4. 5. Непрерывная интеграция (Continuous Integration) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий. Требования к проекту: 40 Исходные коды и все, что необходимо для сборки и тестирования проекта, хранится в репозитории системы управления версиями; Операции копирования из репозитория, сборки и тестирования всего проекта автоматизированы и легко вызываются из внешней программы На выделенном сервере локальную сборку организуется служба, запускающая по внешнему запросу, по расписанию, по факту обновления репозитория, и др. В случае сборки по расписанию (daily build —ежедневная сборка) дополнительно вводится система нумерации сборок. Обычно каждая сборка нумеруется натуральным числом, которое увеличивается с каждой новой сборкой. Исходные тексты и другие исходные данные при взятии их из репозитория системы контроля версий помечаются номером сборки. Благодаря этому точно такая же сборка может быть точно воспроизведена в будущем — достаточно взять исходные данные по нужной метке и запустить процесс снова. Это даёт возможность повторно выпускать даже очень старые версии программы с небольшими исправлениями. Преимущества непрерывной интеграции: проблемы интеграции выявляются и исправляются быстро, что оказывается дешевле; немедленный прогон модульных тестов для свежих изменений; постоянное наличие текущей стабильной версии вместе с продуктами сборок — для тестирования, демонстрации, и т. п. немедленный эффект от неполного или неработающего кода приучает разработчиков к работе в итеративном режиме с более коротким циклом. Недостатки непрерывной интеграции: затраты на поддержку работы непрерывной интеграции; потенциальная необходимость в выделенном сервере под нужды непрерывной интеграции; 41 немедленный эффект от неполного или неработающего кода — отучает разработчиков от выполнения периодических резервных включений кода в репозиторий 3.2.7.3 Гибкая разработка - SCRUM (Ken Schwaber & Jeff Sutherland, 1996) В методологии Scrum всего три роли. Scrum Master Product Owner Team Скрам Мастер (Scrum Master) - самая важная роль в методологии. Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В Agile команда является самоорганизующейся и самоуправлямой. Основные обязанности Скрам Мастера таковы: Создает атмосферу доверия, Участвует в митингах в качестве фасилитатора Устраняет препятствия Делает проблемы и открытые вопросы видимыми Отвечает за соблюдение практик и процесса в команде Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте. ScrumMaster может также помогать Product Owner создавать Backlog для команды Product Owner - это человек, отвечающий за разработку продукта. Как правило, это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Product Owner - это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет. Обязанности Product Owner таковы: Отвечает за формирование product vision 42 Управляет ROI Управляет ожиданиями заказчиков и всех заинтересованных лиц Координирует и приоритизирует Product backlog Предоставляет понятные и тестируемые требования команде Взаимодействует с командой и заказчиком Отвечает за приемку кода в конце каждой итерации Product Owner ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта. Команда (Team). В методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Product Owner. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды. Обязанности команды таковы: Отвечает за оценку элементов баклога Принимает решение по дизайну и имплементации Разрабатывает софт и предоставляет его заказчику Отслеживает собственный прогресс (вместе Мастером). Отвечает за результат перед Product Owner со Скрам Размер команды ограничивается размером группы людей, способных эффективно взаимодействовать лицом к лицу. Типичные размер команды - 7 плюс минус 2. Команда в Scrum кроссфункциональна. В нее входят люди с различными навыками - разработчики, аналитики, тестировщики. Нет заранее определенных и поделенных ролей в команде, ограничивающих область действий членов команды. Команда состоит из инженеров, которые вносят свой вклад в общий успех проекта в соответствии со своими способностями и проектной необходимостью. Команда самоорганизуется для выполнения конкретных задач в проекте, что позволяет ей гибко реагировать на любые возможные задачи. Для облегчения коммуникаций команда должна находиться в одном месте (colocated). Предпочтительно размещать команду не в кубиках, а в одной общей комнате для того, чтобы уменьшить препятствия для свободного общения. 43 Команде необходимо предоставить все необходимое для комфортной работы, обеспечить досками и флипчартами, предоставить все необходимые инструменты и среду для работы. Product Backlog - это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе. Product Backlog включает в себя use cases, defects, enhancements, technologies, stories, features, issues, и т.д.. Product backlog также включает задачи, важные для команды, например "провести тренинг", "добить всем памяти" Product Backlog постоянно пересматривается и дополняется - в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За Product Backlog отвечает Product Owner. Он также работает совместно с командой для того, чтобы получить приближенную оценку на выполнение элементов Product Backlog для того, чтобы более точно расставлять приоритеты в соответствии с необходимым временем на выполнение. Sprint Backlog содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач Сумма оценок оставшейся работы может быть построена как график зависимости от времени. Такой график называется Sprint Burndown chart. Он демонстрирует прогресс команды по ходу спринта. В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней). Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику). Короткие спринты обеспечивают быстрый feedback проектной команде от заказчика. Заказчик получает возможность гибко управлять scope системы, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в Product Backlog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий (или на один из следующих) спринтов. Каждый спринт представляет собой маленький "водопад". В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. 44 Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды. Рис. 6. Жизненный цикл спринта. В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда. Планирование спринта состоит из двух последовательных митингов. Планирование спринта, митинг первый Участники: команда, пользователи, менеджмент. Product Owner, Scrum Master, Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта. Артефакт: Sprint Backlog Планирование спринта, митинг второй Участники: Скрам Мастер, команда 45 Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность. Артефакт: в Sprint Backlog появляются задачи Если в ходе спринта выясняется, что команда не может успеть сделать запланированное на спринт, то Скрам Мастер, Product Owner и команда встречаются и выясняют, как можно сократить scope работ и при этом достичь цели спринта. Остановка спринта (Sprint Abnormal Termination). Остановка спринта производится в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить Product Owner, если необходимость в достижении цели спринта исчезла. После остановки спринта проводится митинг с командой, где обсуждаются причины остановки спринта. После этого начинается новый спринт: производится его планирование и стартуются работы. Daily Scrum Meeting. Этот митинг проходит каждое утро в начале дня. Он предназначен для того, чтобы все члены команды знали, кто и чем занимается в проекте. Длительность этого митинга строго ограничена и не должна превышать 15 минут. Цель митинга - поделиться информацией. Он не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы митинга. Скрам митинг проводит Скрам Мастер. Он по кругу задает вопросы каждому члену команды Что сделано вчера? Что будет сделано сегодня? С какими проблемами столкнулся? Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items, например в формате что/кто/когда, например Обсудить проблему с отрисовкой контрола 46 Петя и Вася Сразу после скрама Демо и ревью спринта. Рекомендованная длительность: 4 часа Команда демонстрирует инкремент продукта, созданный за последний спринт. Product Owner, менеджмент, заказчики, пользователи, в свою очередь, его оценивают. Команда рассказывает о поставленных задачах, о том как они были решены, какие препятствия были у них на пути, какие были приняты решения, какие проблемы остались нерешенными. На основании ревью принимающая сторона может сделать выводы о том, как должна дальше развиваться система. Участники миитинга делают выводы о том, как шел процесс в команде и предлагает решения по его улучшению. Скрам Мастер отвечает за организацию и проведение этого митинга. Команда помогает ему составить адженду и спланировать кто, и в какой последовательности, что представляет. Подготовка к митингу не должна занимать у команды много времени (правило - не более двух часов). В частности, именно поэтому запрещается использовать презентации в Power Point. Подготовка к митингу не должна занимать у команды более 2-х часов. 3.2.8 Подгонка модели жизненного цикла разработки. Выбор подходящей модели — это только первая стадия применения модели жизненного цикла в процессе определенного проекта. Следующая стадия заключается в ее подгонке в соответствии с потребностями этого проекта. Это означает, что выбранные реальные фазы и действия должны помочь руководителю проекта соотнести проект с выбранной моделью. Согласно модели SEI СММ, не существует каких-либо четких предписаний на сей счет: "Руководящие принципы и критерии для адаптации стандартного процесса разработки программного обеспечения данной организации к выбранным проектам получают путем разработки и последующего утверждения", а также "определенный процесс разработки программного обеспечения в рамах данного проекта является адаптированной версией стандартного процесса разработки программного обеспечения для данной организации". 47 Жизненные циклы, их фазы, а также соответствующие действия, приведенные ниже, можно использовать в качестве отправной точки при определении тех циклов, фаз и действий, которые требуются в данный момент времени. После завершения подгонки модель приобретает большую степень значимости для команды разработчиков и коллектива пользователей. Ее можно использовать как опорную точку на собраниях, посвященных обсуждению состояния процесса разработки, демонстрациях, на обсуждениях оценки рисков, а также при доставке конечного продукта. А что будет в том случае, если при выполнении проекта происходят какие-либо изменения, которые заставляют команду прийти к мысли, что другая модель была бы более действенной? Можно ли изменить модель в процессе выполнения проекта? Ответ на этот вопрос почти всегда положительный, но это следует сделать с обязательным учетом возможных последствий таких изменений для проекта. В крайнем случае, лучше изменить модель, чем пытаться использовать ту, которая не подходит в достаточной степени для соответствия потребностям проекта. Стадии процесса выбора жизненного цикла разработки программного обеспечения и его последующей подгонки можно определить следующим образом: 1. Ознакомьтесь с различными моделями. 2. Просмотрите и проанализируйте возможные виды работ: разработка, модернизация, сопровождение и т.д. 3. Выберите самый подходящий жизненный цикл, используя для этого матрицы критериев: высокая степень риска, пользовательский интерфейс, высокая надежность, время доставки на рынок/выпуска продукта, приоритеты пользователя, уточнение требований, ожидаемый срок эксплуатации системы, технология, размер и сложность, возможный параллелизм, а также интерфейсы для существующих и новых систем. 4. Проанализируйте, насколько выбранный жизненный цикл соответствует стандартам вашей организации, ваших заказчиков или типа проекта — ISO, IEEE и т.д. 5. Сформулируйте набор фаз и действий, образующих каждую фазу. 6. Определите внутренние и внешние производимые продукты. 7. Определите шаблоны и внутреннее содержимое поставляемых продуктов. 8. Определите действия по обзору, инспектированию, верификации и аттестации, а также стадии проекта. 48 9. Выполните оценку эффективности схемы жизненного цикла и проведите ее модернизацию там, где это необходимо. Часто применяемый метод подгонки жизненных циклов заключается в комбинировании моделей. Существует множество различных моделей или представлений жизненного цикла разработки программного обеспечения. Все они представляют собой логически построенную последовательность действий, начиная с определения потребности и заканчивая производством программного обеспечения. Каждая модель представляет собой процесс, который структурно состоит из этапов, направленных на обеспечение целостности соответствующих субкомпонентных действий. Каждая фаза снижает степень риска при выполнении проекта, что достигается благодаря применению критериев входа и выхода для определения дальнейшего хода действий. По завершении каждой фазы получают внутренние или результативные внешние действия. Жизненные циклы разработки программного обеспечения иногда называют методиками менеджмента жизненных циклов. Эти методики охватывают все стандарты и процедуры, оказывающие влияние на планирование, сбор требований и анализ, разработку проекта, конструирование и внедрение программной системы. С целью обеспечения эффективности произвольного жизненного цикла его потребуется аккуратно выбрать и зачастую настроить (подогнать и разработать) в соответствии с задачами и целями определенного проекта. Вместо того чтобы начать разработку "с нуля", в некоторых популярных, обобщенных моделях обеспечиваются готовые начальные схемы. Каждая модель имеет присущие ей преимущества и недостатки, определяющие ее применение для определенных типов проектов. Модель, выбранная для какого-либо проекта, должна обеспечивать потребности организации, соответствовать типу выполняемых работ, а также навыкам и инструментальным средствам, которые имеются у специалистов-практиков. Убедившись в эффективности использования моделей жизненного цикла в рамках процесса, вы можете помочь вашей организации достичь гибкости при выполнении проекта. В каждом проекте, выполняемом организацией, можно применить отдельную модель жизненного цикла, которая подвергается настройке. Однако интеграция моделей жизненного цикла с "каркасом" процесса — это уже другая стадия в ходе достижения более высокого уровня завершенности процесса разработки программного 49 обеспечения. Организация должна осознать то, что разрабатываемые программы должны обладать постоянными характеристиками. В то же время реализация этого процесса должна быть гибкой, что обеспечивается с помощью настраиваемых моделей жизненного цикла разработки программного обеспечения. 50 4 Качество программных продуктов. 4.1 Определение качества. Стандарты качества. Термин «Качество» не имеет общепринятого (индустриального) определения в производстве. Если попросить группу людей высказать свое мнение по поводу того, что такое качественное программное обеспечение, можно получить следующие варианты ответов: Его легко использовать. Оно демонстрирует хорошую производительность. В нем нет ошибок. Оно не портит пользовательские данные при сбоях. Его можно использовать на разных платформах. Оно может работать 24 часа в сутки и 7 дней в неделю. В него легко добавлять новые возможности. Оно удовлетворяет потребности пользователей. Оно хорошо документировано. Все это действительно имеет непосредственное отношение к качеству программного обеспечения. Но эти ответы выделяют характеристики, важные для конкретного пользователя, разработчика или группы таких лиц. Для того чтобы удовлетворить потребности всех сторон (конечных пользователей, заказчиков, разработчиков, администраторов систем, в которых оно будет работать, регулирующих организаций и пр.), для достижения прочного положения разрабатываемого программного обеспечения на рынке и повышения потенциала его развития необходим учет всей совокупности характеристик программного обеспечения, важных для всех заинтересованных лиц. Приведенные выше ответы показывают, что качество программного обеспечения может быть описано большим набором разнородных характеристик. Качество программного обеспечения определяется в стандарте ISO 9126 как вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц. 51 Рис. 7. Представление качества в стандарте ISO 9126 Различные контексты использования Качество процесса Метрики качества процесса влияет на Внутреннее качество Метрики внутреннего качества влияет на Внешнее качество Метрики внешнего качества влияет на Качество при использовании Метрики качества при использовании Основные аспекты качества программного обеспечения по ISO 9126: Различаются понятия внутреннего качества, связанного с характеристиками программного обеспечения самого по себе, без учета его поведения; внешнего качества, характеризующего программного обеспечения с точки зрения его поведения; и качества программного обеспечения при использовании в различных контекстах — того качества, которое ощущается пользователями при конкретных сценариях работы программного обеспечения. Для всех этих аспектов качества введены метрики, позволяющие оценить их. Кроме того, для создания добротного программного обеспечения существенно качество технологических процессов его разработки. Взаимоотношения между этими аспектами качества по схеме, принятой ISO 9126, показано на рисунке. В области управления качеством известны три гуру Джозеф Джуран, Филипп Кросби и Эдвард Деминг. У каждого из них есть свое определение качества, но у всех у них есть общее – это отношение клиента к качеству продукта. Джозеф Джуран в свое время (1988), ввел определение качества как пригодность к использованию (“Fitness for Use”) – качестов для заказчика. 52 Второй элемент в определении Джураном качества заключается в продукции, свободной от дефектов. По Джурану, эти недостатки доставляют неприятности клиентам и, следовательно, они становятся неудовлетворенными. Определение Джураном понятия качество отражает его твердую направленность на то, чтобы удовлетворить ожидания клиента. Филип Кросби, определяет качество как соответствие требованиям (“Conformance requirements”, 1979). По Кросби, качество либо есть, либо его нет. Нет такого явления, как различные уровни качества. Мы можем определить два вида качества: Внешнее качество – качество для заказчика (это удобство в использовании, отсутствие ошибок, хорошая производительность и т.п.) Внутренне качество – это качество для разработчиков программного продукта (соответствие требованиям, удобная архитектура, простота изменения и т.п.) Общие принципы обеспечения качества процессов производства во всех отраслях экономики регулируются набором стандартов ISO 9000. Наиболее важные для разработки программного обеспечения стандарты в его составе следующие: ISO 9000:2000 Quality management systems — Fundamentals and vocabulary. Системы управления качеством — Основы и словарь. (Аналог — ГОСТ Р-2001). ISO 9001:2000 Quality management systems — Requirements. Models for quality assurance in design, development, production, installation, and servicing. Системы управления качеством — Требования. Модели для обеспечения качества при проектировании, разработке, коммерциализации, установке и обслуживании. Определяет общие правила обеспечения качества результатов во всех процессах жизненного цикла. (Аналог — ГОСТ Р-2001). o Этот стандарт выделяет следующие 22 процесса: Управление качеством. Управление ресурсами. 53 Развитие системы управления. Исследования рынка. Проектирование продуктов. Приобретения. Производство. Оказание услуг. Защита продуктов. Оценка потребностей заказчиков. Поддержка коммуникаций с заказчиками. Поддержка внутренних коммуникаций. Управление документацией. Ведение записей о деятельности. Планирование. Обучение персонала. Внутренние аудиты. Оценки управления. Мониторинг и измерения. Управление несоответствиями. Постоянное совершенствование. Управление и развитие системы в целом. Для каждого процесса требуется иметь планы развития процесса, состоящие как минимум из следующих разделов: Проектирование процесса. Документирование процесса. Реализация процесса. Поддержка процесса. Мониторинг процесса. Управление процессом. Усовершенствование процесса. Помимо поддержки и развития системы процессов, нацеленных на удовлетворение нужд заказчиков и пользователей, ISO 9001 требует: Определить, документировать и развивать собственную систему качества на основе измеримых показателей. Использовать эту систему качества как средство управления процессами, нацеливая их на большее удовлетворение нужд заказчиков, планируя и постоянно отслеживая качество результатов всех видов деятельности, в том числе и самого управления. o o 54 Обеспечить использование качественных ресурсов, качественного (компетентного, профессионального) персонала, качественной инфраструктуры и качественного окружения. Постоянно контролировать соблюдение требований к качеству на практике, во всех процессах проектирования, производства, предоставления услуг и при приобретениях. Предусмотреть процесс устранения дефектов, определить и контролировать качество результатов этого процесса. Ранее использовавшиеся стандарты ISO 9002:1994 Quality systems — Model for quality assurance in production, installation and servicing и ISO 9003:1994 Quality systems — Model for quality assurance in final inspection and test в 2000 году были заменены соответствующими им частями ISO 9001. 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 9001 для разработки программных систем, с упором на обеспечение качества при процессе проектирования. Он также определяет некоторый набор техник и процедур, которые рекомендуется применять для контроля и обеспечения качества разрабатываемых программ. Стандарт ISO 9126 предлагает использовать для описания внутреннего и внешнего качества программного обеспечения многоуровневую модель. На верхнем уровне выделено 6 основных характеристик качества программного обеспечения. Каждая характеристика описывается при помощи нескольких входящих в нее атрибутов. Для каждого атрибута определяется набор метрик, 55 позволяющих его оценить. Множество характеристик и атрибутов качества согласно ISO 9126 показано на Рис. 6. Рис. 6. Характеристики и атрибуты качества программного обеспечения по ISO 9126. Ниже приведены определения этих характеристик и атрибутов по стандарту ISO 9126:2001: Функциональность (functionality) Способность программного обеспечения в определенных условиях решать задачи, нужные пользователям. Определяет, что именно делает программное обеспечение, какие задачи оно решает. o Функциональная пригодность (suitability). Способность решать нужный набор задач. o Точность (accuracy). Способность выдавать нужные результаты. o Способность к взаимодействию (interoperability). 56 o o Способность взаимодействовать с нужным набором других систем. Соответствие стандартам и правилам (compliance). Соответствие программного обеспечения имеющимся индустриальным стандартам, нормативным и законодательным актам, другим регулирующим нормам. Защищенность (security). Способность предотвращать неавторизированный, т.е. без указания лица, пытающегося его осуществить, и неразрешенный доступ к данным и программам. Надежность (reliability). Способность программного обеспечения поддерживать определенную работоспособность в заданных условиях. o Зрелость, завершенность (maturity). Величина, обратная частоте отказов программного обеспечения. Обычно измеряется средним временем работы без сбоев и величиной, обратной вероятности возникновения отказа за данный период времени. o Устойчивость к отказам (fault tolerance). Способность поддерживать заданный уровень работоспособности при отказах и нарушениях правил взаимодействия с окружением. o Способность к восстановлению (recoverability). Способность восстанавливать определенный уровень работоспособности и целостность данных после отказа, необходимые для этого время и ресурсы. o Соответствие стандартам надежности (reliability compliance). Этот атрибут добавлен в 2001 году. Удобство использования (usability) или практичность. Способность программного обеспечения быть удобным в обучении и использовании, а также привлекательным для пользователей. o Понятность (understandability). Показатель, обратный к усилиям, которые затрачиваются пользователями на восприятие основных понятий программного обеспечения и осознание их применимости для решения своих задач. o Удобство обучения (learnability). 57 o o Показатель, обратный усилиям, затрачиваемым пользователями на обучение работе с программным обеспечением. Удобство работы (operability). Показатель, обратный усилиям, предпринимаемым пользователями для решения своих задач с помощью ПО. Привлекательность (attractiveness). Способность программного обеспечения быть привлекательным для пользователей. Этот атрибут добавлен в 2001 году. o Соответствие стандартам (usability compliance). удобства использования Этот атрибут добавлен в 2001 году. Производительность (efficiency) или эффективность. Способность программного обеспечения при заданных условиях обеспечивать необходимую работоспособность по отношению к выделяемым для этого ресурсам. Можно определить ее и как отношение получаемых с помощью программного обеспечения результатов к затрачиваемым на это ресурсам всех типов. o Временная эффективность (time behaviour). Способность программного обеспечения выдавать ожидаемые результаты, а также обеспечивать передачу необходимого объема данных за отведенное время. o Эффективность использования ресурсов (resource utilisation). Способность решать нужные задачи с использованием определенных объемов ресурсов определенных видов. Имеются в виду такие ресурсы, как оперативная и долговременная память, сетевые соединения, устройства ввода и вывода и пр. o Соответствие стандартам производительности (efficiency compliance). Этот атрибут добавлен в 2001 году. Удобство сопровождения (maintainability). 58 Удобство проведения всех видов деятельности, связанных с сопровождение программ. o Анализируемость (analyzability) или удобство проведения анализа. Удобство проведения анализа ошибок, дефектов и недостатков, а также удобство анализа необходимости изменений и их возможных последствий. o Удобство внесения изменений (changeability). Показатель, обратный трудозатратам на выполнение необходимых изменений. o Стабильность (stability). Показатель, обратный риску возникновения неожиданных эффектов при внесении необходимых изменений. o Удобство проверки (testability). Показатель, обратный трудозатратам на проведение тестирования и других видов проверки того, что внесенные изменения привели к нужным результатам. o Соответствие стандартам удобства сопровождения (maintainability compliance). Этот атрибут добавлен в 2001 году. Переносимость (portability). Способность программного обеспечения сохранять работоспособность при переносе из одного окружения в другое, включая организационные, аппаратные и программные аспекты окружения. Иногда эта характеристика называется в русскоязычной литературе мобильностью. Однако термин "мобильность" стоит зарезервировать для перевода "mobility" — способности программного обеспечения и компьютерной системы в целом сохранять работоспособность при ее физическом перемещении в пространстве. o Адаптируемость (adaptability). Способность программного обеспечения приспосабливаться различным окружениям без проведения для этого действий, помимо заранее предусмотренных. o Удобство установки (installability). Способность программного обеспечения быть установленным или развернутым в определенном окружении. o Способность к сосуществованию (coexistence). 59 o o Способность программного обеспечения сосуществовать с другими программами в общем окружении, деля с ними ресурсы. Удобство замены (replaceability) другого ПО данным. Возможность применения данного программного обеспечения вместо других программных систем для решения тех же задач в определенном окружении. Соответствие стандартам переносимости (portability compliance). Этот атрибут добавлен в 2001 году. Перечисленные атрибуты относятся к внутреннему и внешнему качеству программного обеспечения согласно ISO 9126. Для описания качества программного обеспечения при использовании стандарт ISO 9126-4 предлагает другой, более узкий набор характеристик. Эффективность (effectiveness). Способность программного обеспечения предоставлять пользователям возможность решать их задачи с необходимой точностью при использовании в заданном контексте. Продуктивность (productivity). Способность программного обеспечения предоставлять пользователям определенные результаты в рамках ожидаемых затрат ресурсов. Безопасность (safety). Способность программного обеспечения обеспечивать необходимо низкий уровень риска нанесения ущерба жизни и здоровью людей, бизнесу, собственности или окружающей среде. Удовлетворение пользователей (satisfaction). Способность программного обеспечения приносить удовлетворение пользователям при использовании в заданном контексте. Помимо перечисленных характеристик и атрибутов качества, стандарт ISO 9126:2001 определяет наборы метрик для оценки каждого атрибута. Приведем следующие примеры таких метрик. Полнота реализации функций — процент реализованных функций по отношению к перечисленным в требованиях. Используется для измерения функциональной пригодности. 60 Корректность реализации функций — правильность их реализации по отношению к требованиям. Используется для измерения функциональной пригодности. Отношение числа обнаруженных дефектов к прогнозируемому. Используется для определения зрелости. Отношение числа проведенных тестов к общему их числу. Используется для определения зрелости. Отношение числа доступных проектных документов к указанному в их списке. Используется для измерения удобства проведения анализа. Наглядность и полнота документации. Используется для оценки понятности. Перечисленные характеристики и атрибуты качества программного обеспечения позволяют систематически описывать требования к нему, определяя, какие свойства программного обеспечения по данной характеристике хотят видеть заинтересованные стороны. Таким образом, требования должны определять следующее. Что программное обеспечение должно делать, например: o позволять клиенту оформить заказы и обеспечить их доставку; o обеспечивать контроль качества строительства и отслеживать проблемные места; o поддерживать нужные характеристики автоматизированного процесса производства, предотвращая аварии и оптимальным образом используя имеющиеся ресурсы. Насколько оно должно быть надежно, например: o работать 7 дней в неделю и 24 часа в сутки; o допускается неработоспособность в течение не более 3 часов в год; o никакие введенные пользователями данные при отказе не должны теряться. Насколько им должно быть удобно пользоваться, например: o покупатель должен, зная название товара и имея средние навыки работы в Интернет, находить нужный ему товар за не более чем 2 минуты; o инженер по специальности "строительство мостов" должен в течение одного дня уметь разобраться в 80% функций системы. Насколько оно должно быть эффективно, например: 61 поддерживать обслуживание до 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 ПО должно сопрягаться с существующей системой записи данных о заказах. o Приведенные атрибуты качества определены в стандартах, но это не значит, что они вполне исчерпывают понятие качества программного обеспечения. Так, в стандарте ISO 9126 отсутствуют характеристики, связанные с мобильностью программного обеспечения (mobility), т.е. способностью программы работать при физических перемещениях машины, на которой она работает. Вместо надежности многие исследователи предпочитают рассматривать более общее понятие добротности (dependability), описывающее способность программного обеспечения поддерживать определенные показатели качества по основным характеристикам (функциональности, производительности, удобству использования) с заданными вероятностями выхода за их рамки и определенным максимальным ущербом от возможных нарушений. Кроме того, активно исследуются понятия удобства использования, безопасности и защищенности программного обеспечения, — они кажутся большинству специалистов гораздо более сложными, чем это описывается данным стандартом. 62 Методы контроля качества Как контролировать качество системы? Как точно узнать, что программа делает именно то, что нужно, и ничего другого? Как определить, что она достаточно надежна, переносима, удобна в использовании? Ответы на эти вопросы можно получить с помощью процессов верификации и валидации. Верификация обозначает проверку того, что программное обеспечение разработано в соответствии со всеми требованиями к нему, или что результаты очередного этапа разработки соответствуют ограничениям, сформулированным на предшествующих этапах. Валидация — это проверка того, что сам продукт правилен, т.е. подтверждение того, что он действительно удовлетворяет потребностям и ожиданиям пользователей, заказчиков и других заинтересованных сторон. Эффективность верификации и валидации, как и эффективность разработки программного обеспечения в целом, зависит от полноты и корректности формулировки требований к программному продукту. Основой любой системы обеспечения качества являются методы его обеспечения и контроля. Методы обеспечения качества представляют собой техники, гарантирующие достижение определенных показателей качества при их применении. Мы будем рассматривать подобные методы на протяжении всего курса. Методы контроля качества позволяют убедиться, что определенные характеристики качества программного обеспечения достигнуты. Сами по себе они не могут помочь их достижению, они лишь помогают определить, удалось ли получить в результате то, что хотелось, или нет, а также найти ошибки, дефекты и отклонения от требований. Методы контроля качества программного обеспечения можно классифицировать следующим образом: Методы и техники, связанные с выяснением программного обеспечения во время его работы. свойств Это, прежде всего, все виды тестирования, измерение количественных показателей качества, которые можно определить по результатам работы программного обеспечения — эффективности по времени и другим ресурсам, надежности, доступности и пр. 63 Методы и техники определения показателей качества на основе симуляции работы программного обеспечения с помощью моделей разного рода. К этому виду относятся проверка на моделях (model checking), а также прототипирование (макетирование), используемое для оценки качества принимаемых решений. Методы и техники, нацеленные на выявление нарушений формализованных правил построения исходного кода программного обеспечения, проектных моделей и документации. К методам такого рода относится инспектирование кода, заключающееся в целенаправленном поиске определенных дефектов и нарушений требований в коде на основе набора шаблонов, автоматизированные методы поиска ошибок в коде, не основанные на его выполнении, методы проверки документации на согласованность и соответствие стандартам. Методы и техники обычного или формализованного анализа проектной документации и исходного кода для выявления их свойств. К этой группе относятся многочисленные методы анализа архитектуры программного обеспечения, о которых пойдет речь в следующей лекции, методы формального доказательства свойств ПО и формального анализа эффективности применяемых алгоритмов. 4.2 Стоимость качества. Фраза «стоимость качества» (“cost of quality”) широко применяется и вводит в заблуждение. Это не цена качества продукта или сервиса. Это не стоимость создания качественного продукта или сервиса. Это - стоимость «плохого качества» (Д. Джуран). Это суммарная стоимость издержек на: инвестиции в предупреждение несоответствий требованиям оценку продукта\сервиса на соответствие требованиям исправление несоответствий требованиям 64 Preventive costs (стоимость предотвращения низкого качества продукта\сервиса): • • • • • • Обзор (review) нового продукта (требований) Планирование качества Разработка/оценка процессов Планирование улучшения качества Обучение Стоимость всех активностей для предотвращения ошибок (QA) Appraisal costs (стоимость оценки – измерение, оценка и проверка продукта\сервиса с целью обеспечения соответствия стандартам качества): • • • • Стоимость тестирования Стоимость выполнения ревью Стоимость выполнения инстпекций Все затраты на выявление дефектов (QC) Failure cost (цена «неудач»/ошибок, обнаруженных до поставки поставки продукта\предоставления сервиза заказчику и после: internal failure cost and external failure cost): • Стоимость идентификации, анализа, исправления ошибок и проверки исправления ошибок • Повторное тестирование • Стоимость переработок • Стоимость работ по обработке жалоб заказчика Удельная стоимость исправления дефектов быстро растет по мере продвижения продукта к стадии эксплуатации. Так, в статье B. Boehm and V. Basili «Software Defect Reduction Top 10 List» (IEEE Computer, IEEE Computer Society, Vol. 34, No.1, January 2001, pp. 135137.) показано, что стоимость исправления дефекта после ввода системы в эксплуатацию вдвое превышает аналогичную стоимость на стадии тестирования продукта и более чем в тысячу раз — в период выработки требований к продукту. 65 Рис. 8. Стоимость качества. Что необходимо сделать: • Определите, что такое качество в вашей компании (стандарты качества) • Определите, что такое качественный продукт\услуга (стандарты) • Подумайте над стоимостью плохого качества • Определите действия для предотвращения плохого качества, оценки качества продукта\услуги на соответствие стандартам качества • Уменьшайте стоимость исправления ошибок путем увеличения затрат на предупреждение и оценку качества. • Балансируйте затраты 4.3 Введение в CMMI «Каркасом» процесса разработки программного обеспечения служит модель зрелости функциональных возможностей (Capability Maturity Model, CMM). Она основана на практических действиях, отображает лучшие результаты и определяет потребности индивидов, работающих над усовершенствованием процесса разработки программного обеспечения и выполняющих оценочный анализ этого процесса. Модель СММ представляет собой схему, по которой этапы разработки соответствуют пяти уровням развития функциональных 66 возможностей, на основе которых осуществляется непрерывное усовершенствование процесса разработки. Исходный. Процесс разработки программного обеспечения можно охарактеризовать как специальный, подобранный для определенного случая процесс, а иногда и как хаотический. Определить можно лишь небольшое количество процессов, и успех зависит от приложенных усилий и предпринимаемых решительных действий. Повторяющийся. Основные процессы управления проектом создаются для того, чтобы отслеживать затраты, график работы и функциональные возможности. Здесь соблюдается необходимый порядок выполнения процесса, предназначенный для повторения достижений, полученных ранее при выполнении подобных проектов. Определенный. Во всех проектах используется испытанная, адаптированная версия стандартного процесса разработки программного обеспечения данной организации. Управляемый. Собираются детальные показатели процесса разработки программного обеспечения и качественные характеристики продукта. Управление процессом разработки программных продуктов осуществляется на количественном уровне. Уровень оптимизации. Непрерывное усовершенствование процесса разработки достигается с помощью количественной обратной связи, достигаемой при осуществлении самого процесса, а также на базе новаторских идей и технологий. Определение процесса включает в себя разработку и сопровождение стандартного процесса разработки определенной организации, а также относящиеся к нему ценные свойства процесса, такие как описательные характеристики жизненных циклов разработки ПО, руководящие принципы адаптации процесса и его критерии Целью разработки CMMI явилось желание его создателей избежать проблем, связанных с использованием различных моделей CMM. Начиная с1991 года, были разработаны модели CMM для различных областей применения, наиболее существенными из них были: - модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software – SW-CMM) - модель зрелости процессов для системного реинжиниринга (Electronic Industries Alliance Interim Standard – EIA/IS 731) - модель зрелости процессов интегрированной разработки продуктов (Integrated Product Development Capability Maturity Model – IPD-CMM) 67 На основе этих моделей и был построен CMMI. Он вобрал в себя лучшее из этих моделей, устранив неоднозначность трактования некоторых понятий ввиду наличия множества моделей. Прежде всего, хотелось бы упомянуть о том, что CMMI является референтной моделью, которая шаг за шагом помогает организации усовершенствовать свои бизнес процессы. Использование данной модели позволяет организации оценить эффективность бизнес-процессов, установить приоритетные направления их усовершенствования, а также внедрить данные усовершенствования. Однако следует помнить, что нельзя улучшать бизнес-процессы во имя их улучшения, данные улучшения должны помогать бизнесу, достичь поставленных перед ним целей. Также необходимо иметь в виду, что улучшение процессов это долговременное, стратегическое усилие организации. Существует два подхода (репрезентации) в совершенствовании бизнес-процессов в контексте CMMI: - непрерывная репрезентация - поэтапная репрезентация Чем же отличаются эти два подхода? Примечание: репрезентация подобна представлению (view) в базе данных. Данные, используемые в обоих подходах одинаковы, отличаются средства их организации и представления. При выборе непрерывной репрезентации организация оставляет за собой право выбора последовательности действий ведущих к совершенствованию бизнес процессов. В данном случае усовершенствуются процессы определенной области процессов. Данный подход позволяет мигрировать с модели EIA/IS 731 на модель CMMI. Поэтапная репрезентация предполагает определенную, доказавшую право на существование, последовательность действий, которая ведет к совершенствованию всех процессов организации в целом, а не определенной области процессов как в предыдущем подходе. Данная репрезентация помогает осуществить переход с модели SW-CMM к модели CMMI. Примечание. Необходимо заметить, что наличие предыдущих моделей помогает перейти к модели CMMI, но ни в коей мере не является необходимым условием для внедрения CMMI. В непрерывной репрезентации для оценки (измерения) степени улучшения процессов используется уровень устойчивости (capability level), в то время как в поэтапной репрезентации используется 68 уровень зрелости (maturity level). Основное различие между этими двумя понятиями заключается в следующем: Уровни устойчивости, используемые в непрерывной репрезентации, применяются для улучшения процессов в каждой области процессов. Существует шесть таких уровней, пронумерованных от 0 до 5. Уровень устойчивости включает в себя общую цель и набор общих и специфических практик (см. глоссарий). Непрерывная репрезентация имеет два типа специфических практик: общие и дополнительные, в поэтапной репрезентации такого деления нет. Непрерывная репрезентация. Уровень устойчивости 0 1 2 Название уровня Незавершенный уровень Выполненный уровень Управляемый уровень 3 Определенный уровень 4 5 Количественно-управляемый уровень Оптимизированный уровень В свою очередь уровень зрелости описывает общую организационную зрелость, и он включает в себя предопределенный набор областей процессов (см. Таблица 1). Существует пять уровней зрелости, пронумерованных от 1 до 5. В поэтапной репрезентации может присутствовать лишь одна общая цель для одной области процессов. Поэтапная репрезентация Уровень зрелости 1 2 3 4 5 Название уровня Начальный уровень Управляемый уровень Определенный уровень Количественно-управляемый уровень Оптимизированный уровень 69 Рис. 9. Иллюстрация различий в двух подходах: Различные области процессов (ОП) могут находиться на разных уровнях устойчивости (УУ) Все области процессов находятся на одном уровне зрелости (УЗ) Рис. 10. Структурная схема CMMI – поэтапная репрезентация 70 Краткий глоссарий CMMI: Область процессов (Process Area) – набор связанных практик данной области, исполняются для достижения ряда целей, которые считаются важными в контексте улучшения процессов в данной области. В CMMI области процессов одинаковы для непрерывной и поэтапной репрезентации. Практики (practices) – это действия, производимые для достижения поставленных целей в данной области процессов. Практики являются основным конструктивным элементом на основе, которого построена модель CMMI. Специфические цели (specific goals) – цели, конкретизирующие основную (общую) цель Общие цели (generic goals) – это цели, достижение которых в данной области свидетельствует о достижении зрелости процессов в данной области процессов. Слово общие говорит о том, что одна и та же цель может присутствовать во многих областях процессов. Специфические практики (specific practices) – практики, выполнение которых способствует достижению специфических целей. Общие практики (generic practices) – практики, выполнение которых способствует достижению общих целей. Общие признаки (common features) – на самом деле общие свойства - это логическая группировка общих целей. Субпрактики (subpractices) – представляют собой детализированные описания, поясняющие специфические и общие практики. Дисциплина (discipline) – область знаний связанная с одной из четырех составляющих применения CMMI. В модели CMMI существует четыре дисциплины: - разработка программного обеспечения - системный инжиниринг - интегрированная разработка процессов и продуктов - выбор (отбор) поставщиков 71 Уровень зрелости (maturity level) – представляет собой точно определенное эволюционное плато на пути к достижению полной зрелости процессов организации. Каждый уровень зрелости формирует отдельный слой фундамента для постоянного совершенствования производственного процесса, включает в себя набор целей процесса, которые, по мере их достижения, приводят к стабилизации значимых компонентов производственного процесса. Каждый уровень зрелости является основой для более высокого уровня зрелости. Каждый уровень зрелости состоит из определенных областей процессов. 4.4. Управление требованиями Определение требований напрямую связано с процедурами проверки (verification) и утверждения (аттестации - validation, как это сформулировано в ГОСТ Р и ISO/IEC 12207). Вообще говоря, принято считать, что требования описаны неполностью, если для них не заданы правила V&V (verification&validation – проверка и аттестация), то есть не определены способы проверки и утверждения. Процедуры проверки являются отправной точкой для инженеров-тестировщиков и специалистов по качеству, непосредственно отвечающих за соответствие получаемого программного продукта предъявляемым к нему требованиям. Способы описания требований и анализ требований. Спецификация — (Specification) инженерный термин, обозначающий набор требований и параметров, которым удовлетворяет некоторая сущность. К примеру, мост через реку удовлетворяет таким параметрам, как максимальный общий вес нагрузки, максимальная нагрузка на ось, максимальная скорость ветра и т. д. Согласно определению, приведенному в Единой системе конструкторской документации (ЕСКД) спецификация — документ, определяющий состав сборочной единицы, комплекса, комплекта. В спецификации содержится подробное перечисление узлов и деталей какого-либо изделия, конструкции, установки, и т. п., входящих в состав сборочного или монтажного чертежа. Также под спецификацией часто подразумевается документ с перечислением условий, которым должен удовлетворять производственный заказ (то есть требования клиента к производителю). Чаще всего в русском языке такую спецификацию называют техническим заданием. Тем не менее, в сфере программирования и компьютерных систем этот термин 72 употребляется наравне. К примеру, спецификация программного комплекса включает описания диалогов пользователя, требования к памяти и процессорам, производительности системы. Спецификация, часто, является базисом для создания стандарта, который отвечает наиболее важным требованиям этой спецификации. Требования к программному обеспечению — совокупность утверждений относительно свойств программной системы, подлежащая реализации при создании программного обеспечения. Создаются в процессе анализа требований к программному обеспечению. Требования могут выражаться в виде текстовых утверждений и графических моделей Виды требований по уровням Бизнес-требования — определяют назначение программного обеспечения Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия) Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario). К системным ограничениям относятся ограничения на программные интерфейсы, требования к атрибутам качества, требования к применяемому оборудованию и программному обеспечению. Виды требований по характеру Функциональные требования — требования к поведению системы («ЧТО» она делает) Нефункциональные требования — требования к характеру поведения системы («КАК» она это делает) 73 Типы документов требований В зарубежной и российской практике встречаются следующие типы документов требований: Концепция программы Требования к программному обеспечению Требования к программному обеспечению часто ошибочно называют техническим заданием, частью которого они являются в автоматизированных информационных системах. За создание требований к программному обеспечению чаще всего в российской практике отвечает Системный аналитик, иногда — Бизнес-аналитик. Для графических моделей требований исторически использовались диаграммы: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD) 5. Тестирование программного обеспечения. 5.1. Цели и задачи. Основные определения. «Тестирование – процесс выполнения программы с намерением найти ошибки.» (Майерс) «Тестирование программ может использоваться для демонстрации наличия ошибок, но оно никогда не покажет их отсутствие.» (Дейкстра, 1970 г) Существующие на сегодняшний день методы тестирования программного обеспечения не позволяют однозначно и полностью устранить все дефекты и ошибки и установить корректность функционирования программного продукта. Поэтому, все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого программного продукта. Такой процесс формальной проверки или верификации может доказать, что дефекты отсутствуют, с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла программного обеспечения). 74 Существует множество подходов к решению задачи тестирования и верификации программного обеспечения, но эффективное тестирование сложных программных продуктов — это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых. Конечной целью любого процесса тестирования является обеспечение такого ёмкого (совокупного) понятия как Качество, с учётом всех или наиболее критичных для данного конкретного случая составляющих. Тестирование программного обеспечения — попытка определить, выполняет ли программа то, что от неё ожидают. Как правило, никакое тестирование не может дать абсолютной гарантии работоспособности программы в будущем. Задачи тестирования программного обеспечения – снизить стоимость разработки путем раннего обнаружения дефектов. 5.1.1 Методологии тестирования В терминологии профессионалов тестирования (программного и некоторого аппаратного обеспечения), фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого программного обеспечения, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем. При тестировании методом белого ящика (white-box testing, также говорят — прозрачного ящика, оно же структурное тестирование), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого программного обеспечения. Рис. 11. Метод белого ящика Тесты создаются на основе знаний о структуре самой системы и о том, как она работает. Критерии полноты основаны на проценте элементов кода, которые отработали в ходе выполнения тестов. Для оценки степени соответствия требованиям могут привлекаться 75 дополнительные знания о связи требований с определенными ограничениями на значения внутренних данных системы (например, на значения параметров вызовов, результатов и локальных переменных). При тестировании методом чёрного ящика, тестировщик имеет доступ к программному обеспечению только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Рис. 12. Метод черного ящика Тестирование черного ящика, нацеленное на проверку требований. Тесты для него и критерий полноты тестирования строятся на основе требований и ограничений, четко зафиксированных в спецификациях, стандартах, внутренних нормативных документах. Часто такое тестирование называется тестированием на соответствие (conformance testing). Частным случаем его является функциональное тестирование — тесты для него, а также используемые критерии полноты проведенного тестирования определяют на основе требований к функциональности. Помимо методов тестирования «белый ящик» и «черный ящик» различают тестирование методом «серого ящика». Рис. 13. Метод серого ящика В данном случае у человека, который разрабатывает тест кейсы, есть некоторая информация о внутренней структуре приложения или о деталях реализации. Данный метод применяется в последнее время чаще предыдущих. 76 5.1.2 Уровни тестирования Еще одна классификация видов тестирования основана на том уровне детализации работ проекта, на который оно нацелено. Эти же разновидности тестирования можно связать с фазой жизненного цикла, на которой они выполняются. Модульное тестирование (Unit-testing) — уровень тестирования, на котором тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. На этом уровне применяются методы «белого ящика». В современных проектах модульное тестирование («юнит-тестинг») осуществляется разработчиками. Модульное тестирование предназначено для проверки правильности отдельных модулей, вне зависимости от их окружения. При этом проверяется, что если модуль получает на вход данные, удовлетворяющие определенным критериям корректности, то и результаты его корректны. Для описания критериев корректности входных и выходных данных часто используют программные контракты — предусловия, описывающие для каждой операции, на каких входных данных она предназначена работать, постусловия, описывающие для каждой операции, как должны соотноситься входные данные с возвращаемыми ею результатами, и инварианты, определяющие критерии целостности внутренних данных модуля. Основной недостаток модульного тестирования состоит в том, что проводить его можно, только когда проверяемый элемент программы уже разработан. Снизить влияние этого ограничения можно, подготавливая тесты (а это — наиболее трудоемкая часть тестирования) на основе требований заранее, когда исходного кода еще нет. Подход опережающей разработки тестов с успехом используется, например, в рамках XP. Модульное тестирование является важной составной частью отладочного тестирования, выполняемого разработчиками для отладки написанного ими кода. Интеграционное тестирование (Integration testing) – уровень тестирования, на котором отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования (юниттесты для модулей должны быть выполнены и найденные ошибки исправлены). Интеграционное тестирование в качестве входных данных использует модули, над которыми было проведено модульное 77 тестирование, группирует их в более крупные множества, выполняет тесты, определённые в плане тестирования для этих множеств, и представляет их в качестве выходных данных и входных для последующего системного тестирования. При этом проверяется, что в ходе совместной работы модули обмениваются данными и вызовами операций, не нарушая взаимных ограничений на такое взаимодействие, например, предусловий вызываемых операций. Интеграционное тестирование выполняется разработчиками используется при отладке, но на более позднем этапе разработки. Системное тестирование (System testing) - это тестирование программного обеспечения, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования «чёрного ящика», и, тем самым, не требует знаний о внутреннем устройстве системы. Системное тестирование выполняется через внешние интерфейсы программного обеспечения и тесно связано с тестированием пользовательского интерфейса (или через пользовательский интерфейс), проводимым при помощи имитации действий пользователей над элементами этого интерфейса. Частными случаями этого вида тестирования являются тестирование графического пользовательского интерфейса (Graphical User Interface, GUI) и пользовательского интерфейса Web-приложений (WebUI). Системное тестирование выполняется инженерами по тестированию. Приемочное тестирование (Acceptance testing)это тестирование готового продукта конечными пользователями на реальном окружении, в котором будет функционировать тестируемое приложение. Приемочные тесты разрабатываются пользователями, обычно, в виде сценариев. Для того, чтобы найти больше ошибок рекомендуется планировать не только системное тестирование и приемочное, но и модульное и интеграционное. 78 Рис.14. Уровни тестирования Acceptance Testing System Testing Integration Testing Unit Testing Статическое тестирование (Static testing) – тестирование, в ходе которого тестируемая программа (код) не выполняется (запускается). Анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. Примеры статического тестирования: Обзоры (Reviews) Инспекции (Inspections) Сквозные просмотры (Walkthroughs) Аудиты (Audits) Также к статическому тестированию требований, спецификаций, документации. относят тестирование 79 Динамическое тестирование (Dynamic testing)– тестирование, в ходе которого тестируемая программа (код) выполняется (запускается). Альфа-тестирование — тестирование в процессе разработки Бета-тестирование — пользователями (end-users) тестирование выполняется Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадии альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в соответствии с определенными процедурами, включающими подтверждающие тесты (любого уровня), проводимые специалистами группы разработки. Данный вид тестирования не может быть заранее спланирован. Регрессионное тестирование (Regression testing) – тестирование функциональности, которая была уже протестирована до внесения какого-либо изменения. После внесения изменений в очередную версию программы, регрессионные тесты подтверждают, что сделанные изменения не повлияли на работоспособность остальной функциональности приложения. Регрессионное тестирование может выполняться как вручную, так и средствами автоматизации тестирования. Обычно используемые методы регрессионного тестирования включают повторные прогоны предыдущих тестов. Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of Software Engineering Terminology”) гласит: “повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам”. На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходить и после внесения таковых. Основная проблема регрессионного тестирования заключается в поиске компромисса между имеющимися ресурсами и необходимостью проведения таких тестов по мере внесения каждого изменения. В определенной степени, задача состоит в том, чтобы определить критерии “масштабов” изменений, с достижением которых необходимо проводить регрессионные тесты. 80 «Смок-тест» (Smoke Testing, «дымовое тестирование») в тестировании означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется самим программистом; не проходящую этот тест программу не имеет смысла отдавать на более глубокое тестирование. ***История. Первое свое применение этот термин получил у печников, которые, собрав печь, закрывали все заглушки, затапливали её и смотрели, чтобы дым шёл только из положенных мест. Повторное «рождение» термина произошло в радиоэлектронике. Подключив в первый раз собранное устройство к источнику питания, радиолюбитель, пристально разглядывая каждый участок печатной платы, проводит так называемый «Smoke Test» — наблюдает, задымится или нет, потому что очень часто из-за досадных ошибок, допущенных при монтаже схемы, она оказывалась неработоспособна и отдельные её части выходили из строя из-за перегрева (часто с выделением дыма). 5.1.3 Виды тестирования Функциональное тестирование (functional testing) – каждое функциональное требование транслируется в тесткейсы (используя техники «черного ящика») для того, чтобы проверить, что система функционирует в точности, как и описано в спецификации (функциональных требованиях к системе) – проверяем, все ли функциональные требования действительно закодированы\реализованы. Тестирование производительности (perfomance testing) Специализированные тесты проверки удовлетворения специфических требований, предъявляемых к параметрам производительности. Существует особый подвид таких тестов, когда делается попытка достижения количественных пределов, обусловленных характеристиками самой системы и ее операционного окружения: – продемонстрировать, что система удовлетворяет критериям производительности при заданных условиях 81 – измерить, какая часть системы является причиной «плохой» производительности системы – измерить время реакции на действие пользователя, время отклика на запрос, и т.д. Стрессовое тестирование (stress testing) – тестирование операционных характеристик приложения в условиях ограниченных ресурсов (например, скорость, память, место на диске и т.д.) – проверить, что система в стрессовых условиях не прекращает свою работу некорректным образом (без сохранения копии базы данных, вывода сообщения пользователям и т.п.) Нагрузочное тестирование (load testing) – применяется для анализа работы информационных систем на различных уровнях нагрузки. – основным понятием нагрузочного тестирования является "виртуальный пользователь". Управляя числом виртуальных пользователей, тестировщик управляет нагрузкой на систему . – определяем, при какой максимальной нагрузке (максимальном количестве пользователей) система способна функционирвать в соответствии с требованиями к производительности – HP LoadRunner Тестирование удобства использования (usability testing) - эксперимент, выполняемый с целью определения, насколько хорошо люди могут использовать некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения, то есть юзабилити-тестирование измеряет юзабилити объекта. Юзабилити-тестирование сосредоточено на определённом объекте или небольшом наборе объектов, в то время как исследования взаимодействия человек-компьютер в целом — формулируют универсальные принципы. - метод оценки удобства продукта в использовании, основанный на привлечении пользователей в качестве тестировщиков, испытателей и суммировании полученных от них выводов. При испытании многих продуктов пользователю предлагают в «лабораторных» условиях решить основные задачи, для выполнения 82 которых этот продукт разрабатывался, и просят высказывать во время выполнения этих тестов свои замечания. Процесс тестирования фиксируется в протоколе (логе) и/или на аудио- и видеоустройства — с целью последующего более детального анализа. Если юзабилити-тестирование выявляет какие-либо трудности (например сложности в понимании инструкций, выполнении действий или интерпретации ответов системы), то разработчики должны доработать продукт и повторить тестирование. Наблюдение за тем, как люди взаимодействуют с продуктом, нередко позволяет найти для него более оптимальные решения. Если при тестировании используется модератор, то его задача — держать респондента сфокусированным на задачах (но при этом не „помогать“ ему решать эти задачи). Основную трудность после проведения процедуры юзабилититестирования нередко представляют большие объёмы и беспорядочность полученных данных. Поэтому для последующего анализа важно зафиксировать: 1. Речь модератора и респондента; 2. Выражение лица респондента (снимается на видеокамеру); 3. Изображение экрана компьютера, с которым работает респондент; 4. Различные события, происходящие на компьютере, связанные с действиями пользователя: o o o Перемещение курсора и нажатия на клавиши мыши; Использование клавиатуры; Переходы между экранами (браузера или другой программы). Все эти потоки данных должны быть синхронизированы по тайм-кодам, чтобы при анализе их можно было бы соотносить между собой. Наряду с модератором в тестировании нередко участвуют наблюдатели. По мере обнаружения проблем они делают свои заметки о ходе тестирования так, чтобы после можно было синхронизировать 83 их с основной записью. В итоге каждый значимый фрагмент записи теста оказывается прокомментирован в заметках наблюдателя. В идеале ведущий (т.е. модератор) представляет разработчика, наблюдатели — заказчика (например издателя), а испытатели — конечного пользователя (например покупателя). Существует еще один подход к usability-тестированию: Для решения задачи предложенной пользователю разрабатывается "идеальный" сценарий решения этой задачи. Как правило, это сценарий, на который ориентировался разработчик. При выполнении задачи пользователями регистрируются их отклонения от задуманного сценария для последующего анализа. После нескольких итераций доработки программы и последующего тестирования можно получить удовлетворительный интерфейс с точки зрения пользователя. Тестирование интерфейса пользователя (UI testing) – тестирование графического интерфейса пользователя для того, чтобы убедиться, что он соответствует принятым стандартам и их требованиям. – проверяем, как приложение обрабатывает ввод с клавиатуры и «мышки» и как отображаются элементы графического интерфейса (текст, кнопки, меню, списки и прочие элементы). Тестирование безопасности (security testing) - оценка уязвимости программного обеспечения к различным атакам. Компьютерные системы очень часто являются мишенью незаконного проникновения. Под проникновением понимается широкий диапазон действий: попытки хакеров проникнуть в систему из спортивного интереса, месть рассерженных служащих, взлом мошенниками для незаконной наживы. Тестирование безопасности проверяет фактическую реакцию защитных механизмов, встроенных в систему, на проникновение. В ходе тестирования безопасности испытатель играет роль взломщика. Ему разрешено все: попытки узнать пароль с помощью внешних средств; атака системы с помощью специальных утилит, анализирующих защиты; 84 подавление, ошеломление системы (в надежде, что она откажется обслуживать других клиентов); целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления; просмотр несекретных данных в надежде найти ключ для входа в систему. Тестирование локализации (localization testing) – проверяем функционирует ли система как ожидается под разными языковыми локализациями операционных систем Тестирование совместимости (compatibility testing) – проверить, что приложение совместимо с определенными конфигурациями оборудования, операционными системами, базами данных, браузерами, и т.д. и др. 5.2 Процесс тестирования. 5.2.1 Этапы и задачи. Тестирование — это проверка соответствия программного обеспечения требованиям, осуществляемая с помощью наблюдения за его работой в специальных, искусственно построенных ситуациях. Такого рода ситуации называют тестовыми или просто тестами. Тестирование — конечная процедура. Набор ситуаций, в которых будет проверяться тестируемое программное обеспечение, всегда конечен. Более того, он должен быть настолько мал, чтобы тестирование можно было провести в рамках проекта разработки программного обеспечения, не слишком увеличивая его бюджет и сроки. Это означает, что при тестировании всегда проверяется очень небольшая доля всех возможных ситуаций. По этому поводу Дейкстра (Dijkstra) заметил, что тестирование позволяет точно определить, что в программе есть ошибка, но не позволяет утверждать, что там нет ошибок. Тем не менее, тестирование может использоваться для достаточно уверенного вынесения оценок о качестве программного обеспечения. Для этого необходимо иметь критерии полноты тестирования, описывающие важность различных ситуаций для оценки качества, а также эквивалентности и зависимости между ними. 85 Этот критерий может утверждать, что все равно в какой из ситуаций, A или B, проверять правильность работы программного обеспечения, или, если программа правильно работает в ситуации A, то, скорее всего, в ситуации B все тоже будет правильно. Часто критерий полноты тестирования задается при помощи определения эквивалентности ситуаций, дающей конечный набор классов ситуаций. В этом случае считают, что все равно, какую из ситуаций одного класса использовать в качестве теста. Такой критерий называют критерием тестового покрытия, а процент классов эквивалентности ситуаций, случившихся вовремя тестирования, — достигнутым тестовым покрытием. Таким образом, основные задачи тестирования: построить такой набор ситуаций, который был бы достаточно представителен и позволял бы завершить тестирование с достаточной степенью уверенности в правильности программного обеспечения вообще, и убедиться, что в конкретной ситуации программное обеспечение работает правильно, в соответствии с требованиями. Рис. 15. Схема процесса тестирования Тестирование — наиболее широко применяемый метод контроля качества. Для оценки многих атрибутов качества не существует других эффективных способов, кроме тестирования. Организация тестирования программного регулируется следующими стандартами: обеспечения IEEE 829-1998 Standard for Software Test Documentation. 86 Описывает виды документов, служащих для подготовки тестов. IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing. Описывает организацию модульного тестирования (см. ниже). ISO/IEC 12119:1994 (аналог AS/NZS 4366:1996 и ГОСТ Р-2000, также принят IEEE под номером IEEE 1465-1998) Information Technology. Software packages — Quality requirements and testing. Описывает требования программных систем. к процедурам тестирования Тестировать можно соблюдение любых требований, соответствие которым выявляется во время работы программного обеспечения. Из характеристик качества по ISO 9126 этим свойством не обладают только атрибуты удобства сопровождения. Поэтому выделяют виды тестирования, связанные с проверкой определенных характеристик и атрибутов качества — тестирование функциональности, надежности, удобства использования, переносимости и производительности, а также тестирование защищенности, функциональной пригодности и пр. Кроме того, особо выделяют нагрузочное или стрессовое тестирование, проверяющее работоспособность программного обеспечения и показатели его производительности в условиях повышенных нагрузок — при большом количестве пользователей, интенсивном обмене данными с другими системами, большом объеме передаваемых или используемых данных и пр. 5.2.2 Принципы организации тестирования Сформулируем основные принципы тестирования, используя одну из предпосылок настоящей главы о том, что важными в тестировании программ являются вопросы психологии. Эти принципы интересны тем, что в основном они интуитивно ясны, но в то же время на них часто не обращают должного внимания. Описание предполагаемых значений выходных данных или результатов должно быть необходимой частью тестового набора. Нарушение этого очевидного принципа представляет одну из наиболее распространенных ошибок. Ошибочные, но правдоподобные результаты могут быть признаны правильными, если результаты теста не были заранее определены. Здесь мы сталкиваемся с явлением 87 психологии: мы видим то, что мы хотим увидеть. Другими словами, несмотря на то, что тестирование по определению – деструктивный процесс, есть подсознательное желание видеть корректный результат. Один из способов борьбы с этим состоит в поощрении детального анализа выходных переменных заранее при разработке теста. Поэтому тест должен включать две компоненты: описание входных данных и описание точного и корректного результата, соответствующего набору входных данных. Необходимость этого подчеркивал логик Копи: «Проблема может быть охарактеризована как факт или группа фактов, которые не имеют приемлемого объяснения, которые кажутся необычным или которые не удается подогнать под наши представления или предположения. Очевидно, что если что-нибудь подвергается сомнению, то об этом должна иметься какая-то предварительная информация. Если нет предположений, то не может быть и неожиданных результатов». Следует избегать тестирования программы ее автором. К сожалению, реализация этого в целом верного принципа не всегда возможна в силу трех факторов: 1) людские ресурсы разработки, как правило, недостаточны; 2) для регулярного применения этого принципа к каждой программе требуется весьма высокая квалификация всех программистов или большой группы программистов, тестирующих все программы, что не всегда осуществимо; 3) необходим высокий уровень формализации ведения разработки; тщательные формализованные спецификации требований к программам и данным, тщательное описание интерфейса и формализация ответственности за качество продукта. В настоящее время проводится значительная работа по созданию и внедрению формализованных методов в большинстве крупных разработок, но опыт подобного ведения разработок пока еще недостаточно массовый. Этот принцип следует из того факта, что тестирование – это деструктивный процесс. После выполнения конструктивной части при проектировании и написании программы программисту трудно быстро (в течение одного дня) перестроиться на деструктивный образ мышления. Многие, кому приходилось самому делать дома ремонт, знают, что процесс обрывания старых обоев (деструктивный процесс) не легок, но он просто невыносим, если не кто-то другой, а вы сами вчера их наклеивали. И вам не придет в голову срывать их, если где-то 88 они чуть-чуть неровно легли на стену. Вот так же и большинство программистов не могут эффективно тестировать свои программы, потому что им трудно демонстрировать собственные ошибки. Это действительно сильный психологический фактор при коллективной разработке. Программист, тщательно отлаживающий программу, невольно может работать медленнее, что становится известно другим участникам разработки. С другой стороны, он вынужден запрашивать дополнительное машинное время на отладку у своего непосредственного руководителя. Тем самым итоги тестирования оказываются уже не просто делом одного человека, тестирующего программу (пока в большинстве случаев ее автора), но и информацией, возбуждающей общественный интерес (и оценку!) участников разработки, в том числе ее руководителей. Перспектива создать о себе мнение как о специалисте, делающем много ошибок, не воодушевляет программиста, и он подсознательно снижает требования к тщательности тестирования. В такой ситуации от руководителей разработки всех рангов требуется большое чувство такта и понимание процессов, чтобы поощрять специалистов, проводящих тщательное тестирование, и уметь различить и ограничить деятельность программистов, прикрывающих свою нерадивость трудностями тестирования. В дополнение к этой психологической проблеме следует отметить еще одну, не менее важную: программа может содержать ошибки, связанные с неверным пониманием постановки или описания задачи разработчиком. Тогда существует вероятность, что к тестированию разработчик приступит с таким же недопониманием своей задачи. Тестирование можно уподобить работе корректора или рецензента над статьей или книгой. Многие авторы представляют себе трудности, связанные с редактированием собственной рукописи. Очевидно, что обнаружение недостатков в своей деятельности противоречит человеческой психологии. Отсюда вовсе не следует, что программист не может тестировать свою программу. Многие программисты с этим вполне успешно справляются. Здесь лишь делается вывод о том, что тестирование является более эффективным, если оно выполняется кем-либо другим. Заметим, что все наши рассуждения не относятся к отладке, т. е. к исправлению уже известных ошибок. Эта работа эффективнее выполняется самим автором программы. Выделяются следующие организационные принципы управления тестированием: • Программирующая организация не должна сама тестировать разработанные ею программы 89 • • • • • • • • • • Необходимо досконально изучать результаты применения каждого теста. Тесты для неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать Не следует выбрасывать тесты, даже если программа уже не нужна Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены Вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части Тестирование — процесс творческий. Разъяснение организационных принципов тестирования: 1. Программирующая организация не должна сама тестировать разработанные ею программы. Здесь можно привести те же аргументы, что и в предыдущем случае. Во многих смыслах проектирующая или программирующая организация подобна живому организму с его психологическими проблемами. Работа программирующей организации или ее руководителя оценивается по их способности производить программы в течение заданного времени и определенной стоимости. Одна из причин такой системы оценок состоит в том, что временные и стоимостные показатели легко измерить, но в то же время чрезвычайно трудно количественно оценить надежность программы. Именно поэтому в процессе тестирования программирующей организации трудно быть объективной, поскольку тестирование в соответствии с данным определением может быть рассмотрено как средство уменьшения вероятности соответствия программы заданным временным и стоимостным параметрам. Как и ранее, из изложенного не следует, что программирующая организация не может найти свои ошибки; тестирование в определенной степени может пройти успешно. Мы утверждаем здесь лишь то, что экономически более целесообразно 90 выполнение тестирования каким-либо объективным, независимым подразделением. В некоторых организациях подобная практика существует, но только на этапах комплексной отладки. Подобный способ тестирования чрезвычайно сложно реализовать из-за организационных трудностей. 2. Необходимо досконально изучать результаты применения каждого теста. По всей вероятности, это наиболее очевидный принцип, но и ему часто не уделяется должное внимание. В экспериментах, проверенных автором, многие испытуемые не смогли обнаружить определенные ошибки, хотя их признаки были совершенно явными в выходных листингах. Представляется достоверным, что значительная часть всех обнаруженных в конечном итоге ошибок могла быть выявлена в результате самых первых тестовых прогонов, но они были пропущены вследствие недостаточно тщательного анализа результатов первого тестового прогона. 3. Тесты для неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных. При тестировании программ имеется естественная тенденция концентрировать внимание на правильных и предусмотренных входных условиях, а неправильным и непредусмотренным входным данным не придавать значения. Например, при тестировании задачи о треугольниках, лишь немногие смогут привести в качестве теста длины сторон 1, 2 и 5, чтобы убедиться в том, что треугольник не будет ошибочно интерпретирован как неравносторонний. Множество ошибок можно также обнаружить, если использовать программу новым, не предусмотренным ранее способом. Вполне вероятно, что тесты, представляющие неверные и неправильные входные данные, обладают большей обнаруживающей способностью, чем тесты, соответствующие корректным входным данным. 4. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать: Это логически просто вытекает из предыдущего принципа. Необходимо проверить программу на нежелательные побочные эффекты. На пример, программа расчета зарплаты, которая производит правильные платежные чеки, окажется неверной, если она 91 произведет лишние чеки для работающих или дважды запишет первую запись в список личного состава. 5. Не следует выбрасывать тесты, даже если программа уже не нужна. Эта проблема наиболее часто возникает при использовании интерактивных систем отладки. Обычно тестирующий сидит за терминалом, на лету придумывает тесты и запускает программу на выполнение. При такой практике работы после применения тесты пропадают. После внесения изменений или исправления ошибок необходимо повторять тестирование, тогда приходится заново изобретать тесты. Как правило, этого стараются избегать, поскольку повторное создание тестов требует значительной работы. В результате повторное тестирование бывает менее тщательным, чем первоначальное, т. е. если модификация затронула функциональную часть программы и при этом была допущена ошибка, то она зачастую может остаться необнаруженной. Эту проблему почти полностью решают современные инструментальные средства тестирования, однако, она перешла в область организации труда разработчика. 6. Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены. Такую ошибку обычно допускают руководители проекта, использующие неверное определение тестирования как процесса демонстрации отсутствия ошибок в программе, корректного функционирования программы. 7. Вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части. Этот принцип не согласуются с интуитивным представлением. На первый взгляд он лишен смысла, но, тем не менее, подтверждается многими программами. Например, допустим, что некоторая программа состоит из модулей или подпрограмм A и B. К определенному сроку в модуле A обнаружено пять ошибок, а в модуле B – только одна, причем модуль A не подвергался более тщательному тестированию. Тогда из рассматриваемого принципа следует, что вероятность необнаруженных ошибок в модуле A больше, чем в модуле В. Справедливость этого принципа подтверждается еще и тем, что для ошибок свойственно располагаться в программе в виде неких скоплений. В качестве примера можно рассмотреть операционные 92 системы IBM S/370. В одной из версий операционной системы 47 % ошибок, обнаруженных пользователями, приходилось на 4 % модулей системы. Интуитивно понятно, что ошибки могут группироваться в частях программы (модулях), разрабатываемых программистами низкой квалификации, или в модулях, в которых слабо проработана общая идея. Раннее выявление таких модулей – залог эффективного процесса тестирования. Преимущество рассматриваемого принципа заключается в том, что он позволяет ввести обратную связь в процесс тестирования. Если в какой-нибудь части программы обнаружено больше ошибок, чем в других, то на ее тестирование должны быть направлены дополнительные усилия. 8. Тестирование — процесс творческий. Вполне вероятно, что для тестирования большой программы требуется больший творческий потенциал, чем для ее проектирования. Выше было показано, что нельзя дать гарантию построения теста, обнаруживающего все ошибки. В дальнейшем будут обсуждаться методы построения хороших наборов тестов, но применение этих методов должно быть творческим. 5.2.3 Планирование тестирования. Процесс тестирования находится в прямой зависимости от процесса разработки программного обеспечения, но при этом сильно отличается от него, поскольку преследует другие цели. Разработка ориентирована на построение программного продукта, тогда как тестирование отвечает на вопрос, соответствует ли разрабатываемый программный продукт требованиям, в которых зафиксирован первоначальный замысел изделия (т.е. то, что заказал заказчик). Вместе оба процесса охватывают виды деятельности, необходимые для получения качественного продукта. Ошибки могут быть привнесены на каждой стадии разработки. Следовательно, каждому этапу разработки должен соответствовать этап тестирования. Отношения между этими процессами таковы, что если что-то разрабатывается, то оно подвергается тестированию, а результаты тестирования используются для определения, соответствует ли это "что-то" набору предъявляемых требований. Процесс тестирования возвращает выявленные им ошибки в процесс разработки. Процесс разработки передает процессу тестирования новые и исправленные проектные версии. 93 Как было отмечено выше, процесс тестирования тесно связан с процессом разработки. Соответственно планирование тестирования тоже зависит от выбранной модели разработки. Однако вне зависимости от модели разработки при планировании тестирования необходимо ответить на пять вопросов, определяющих этот процесс: Кто будет тестировать и на каких этапах? Разработчики продукта, независимая группа тестировщиков или совместно? Какие компоненты надо тестировать? Будут ли подвергнуты тестированию все компоненты программного продукта или только компоненты, которые угрожают наибольшими потерями для всего проекта? Когда надо тестировать? Будет ли это непрерывный процесс, вид деятельности, выполняемый в специальных контрольных точках, или вид деятельности, выполняемый на завершающей стадии разработки? Как надо тестировать? Будет ли тестирование сосредоточено только на проверке того, что данный продукт должен выполнять, или также на том, как это реализовано? В каком объеме тестировать? Как определить, в достаточном ли объеме выполнено тестирование, или как распределить ограниченные ресурсы, выделенные под тестирование? Кто будет тестировать? Разработчики или Разработчики и Тестировщики или Тестировщики где Разработчик: • Кодирование\программирование 94 • • • Создание и выполнение юнит-тестов Исправление ошибок … Тестировщик (Тестер\Tester) • • • • • • Создание и описание тест-кейсов Выполнение тест-кейсов Запись отчетов об ошибках и их верификация Оценка задач тестирования Создание скриптов (test scripts), если есть автоматизация … Ведущий тестировщик (Test Lead) • • • • • • • • • Оценка и планирование процесса тестирования Создание Тест Плана и другой тестовой докуменации и обеспечение их актуальности Внедрение процедуры тестирования и ее выполнение Соблюдение графика Руководство командой тестирования Ревью результатов тестирования Отслеживание выполнения задач тестирования Сбор метрик … Конкретный исполнитель проекта может выступать как в роли разработчика, так и в роли тестировщика. Момент начала тестирования в проекте можно регулировать Что нужно тестировать? Могут быть варианты, когда ничего не надо тестировать (поскольку все компоненты были протестированы ранее), а может потребоваться тестировать каждый компонент с точностью до строки кода. В объектно- ориентированном порграммирования базовым компонентом является класс. В этом случае область тестирования определяется классами. Область тестирования на уровне классов подлежит выбору. Классы, заимствованные из других проектов или взятые из библиотек, чаще всего в повторном тестировании не нуждаются. Существуют различные стратегии по выбору подмножества классов для тестирования. Далее определяется необходимость интеграционного тестирования. 95 Аналогично для системного. Весь ли объем функциональности необходимо тестировать? Какие приоритеты для отдельных функциональных модулей, «фич». Когда нужно тестировать? Необходимо определить правила выполнения юнит-тестов – как часто? В какой момент? Необходимо определить и зафиксировать расписание тестовых билдов для системного тестирования и процедуру приемки билда. Для каждого тестового билда необходимо, помимо дня и времени, определить его содержимой – какая функциональность будет включена в каждый билд (имплементация закончена, юнит-тесты выполнены). Как нужно тестировать? При тестировании в соответствии со спецификацией (функциональном тестировании или тестировании "черного ящика") построение тестовых случаев производится в соответствии со спецификацией и не зависит от того, как реализован ПП. Эффективность зависит от качества спецификации и способности тестировщика корректно ее интерпретировать. При структурном тестировании (тестировании в соответствии с реализацией или тестировании "белого ящика") построение тестовых случаев производится на основе программного кода, представляющего собой реализацию ПП. Входные данные каждого тестового случая должны быть определены спецификацией ПП, однако они могут быть выбраны на основе анализа самого программного кода для прохождения той или иной ветви программы. При этом покрытие увеличивается. Наряду с автономным тестированием компонентов (классов) системы (модульным уровнем тестирования), необходимо тестировать взаимодействие между различными компонентами (интеграционный уровень тестирования). Цель интеграционного тестирования заключается в обнаружении отказов, возникающих вследствие ошибок в интерфейсах или в силу неверных предположений относительно интерфейсов. После интеграционного тестирования проводится системное тестирование ПП (системный уровень). На этом уровне тестированию подвергается система как единое целое. 96 Тестирование следует осуществлять в достаточных объемах, чтобы быть более-менее уверенным в том, что ПП функционирует в соответствии с предъявленными к нему требованиями, т.е. выполняется принцип адекватности тестирования ПП. Адекватность можно измерить, используя понятие покрытия. Покрытие можно измерить двумя способами. Первый заключается в подсчете количества требований, сформулированных в спецификации, которые подверглись тестированию. Второй способ заключается в подсчете выполненных компонентов ПП в результате прогона тестового набора. Набор тестов можно считать адекватным, если определенная часть строк исходного кода или исполняемых ветвей исходного кода была выполнена, по крайней мере, один раз во время прогона тестового набора. Эти два способа измерения отражают два базовых подхода к тестированию: при использовании первого подхода проверяется, что должен выполнять ПП; при использовании второго подхода проверяется, как фактически работает ПП. В каком объеме тестировать? Могут быть различные уровни адекватного тестирования, который охватывает случаи от отсутствия тестирования до исчерпывающего тестирования, когда выполняется прогон всех возможных тестовых случаев. Объем необходимого тестирования следует определять исходя из краткосрочных и долгосрочных целей проекта и в соответствии с особенностями разрабатываемого ПП. Покрытие - это мера полноты использования возможностей программного компонента тестовым набором. Например, одна из мер - задействована ли каждая строка программного кода продукта хотя бы один раз при прогоне данного тестового набора. Другая мера - количество требований спецификации, проверенных данным тестовым набором. Если требования сформулированы в терминах случаев использования, то покрытие измеряется количеством случаев использования и числом сценариев, построенных для каждого случая использования. Анализ рисков в процессе тестирования применяется для определения уровня детализации и времени, затрачиваемого на 97 тестирование конкретного компонента. Например, на тестирование классов, более важных для приложения, отводится больше времени. Все ответы на поставленные вопросы и многое другое фиксируется в документе – Тест план. 1. Перечень тестовых ресурсов. 2. Перечень функций и подсистем, подлежащих тестированию. 3. Тестовую стратегию: o Анализ функций и подсистем с целью определения слабых мест, требующих исчерпывающего тестирования, то есть участков функциональности, где появление дефектов наиболее вероятно. o Определение стратегии выбора входных данных для тестирования. Поскольку в реальных применениях множество входных данных программного продукта практически бесконечно, выбор конечного подмножества для проведения тестирования является сложной задачей. Для ее решения могут быть применены методы покрытия классов входных и выходных данных, анализ крайних значений, покрытие случаев использования и тому подобное. Выбранная стратегия должна быть обоснована и задокументирована. o Определение потребности автоматизации процесса тестирования. При этом решение об использовании существующей, либо о создании новой автоматизированной системы тестирования должно быть обосновано, а также продемонстрирована оценка затрат на создание новой системы или на внедрение уже существующей. 4. График (расписание) тестовых циклов. 5. Указание конкретных параметров аппаратуры и программного окружения. 6. Определение тестовых метрик, которые необходимо собирать и анализировать, таких как покрытие набора требований, покрытие кода, количество и уровень серьезности дефектов, объем тестового кода и т.п. Тест план (Test Plan) - это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения. 98 Тест план должен как минимум отвечать на следующие вопросы: Что надо тестировать? o описание объекта тестирования: системы, приложения, оборудование Что будете тестировать? o список функций и описание тестируемой системы и её компонент в отдельности Как будете тестировать? o стратегия тестирования, а именно: методологии, виды тестирования и их применение по отношению к тестируемому объекту, приоритеты, автоматизация и пр. Когда будете тестировать? o последовательность проведения работ: фазы, циклы тестирования, процедура тестирования - подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки Где будете тестировать? o Окружение тестируемой системы – описание o Необходимое для тестирования оборудование программные средства o … Кто будет тестировать? o Роли и обязанности o Имена и фамилии o …. и Критерии начала тестирования: o готовность окружения o готовность тест кейсов o законченность разработки требуемого функционала o выполнение юнит-тестов o билд построен и удовлетворяет определенным критериям o и т.п. o ... Критерии окончания тестирования: o результаты тестирования удовлетворяют определенным критериям o требовния к количеству открытых багов выполнены (определяются заранее) o и т.п.... 99 Критерии передачи системы для приемочного тестирования: o Приемочные тесты – где хранятся и когда выполняются o Процедура приемки o … Какие риски существую и как мы ими будет управлять? o Риски и их разрешение Метрики и отчеты: o Продуктовые метрики – кто собирает, с какой периодичностью… o Отчеты - кто создает, кому отправляет, и т.п. Расписание билдов ….. Виды тест планов Чаще всего на практике приходится сталкиваться со следующими видами тест планов: 1. Мастер Тест План (Master Plan or Master Test Plan) 2. Тест План (Test Plan) 3. План Приемочных Испытаний (Product Acceptance Plan) документ, описывающий набор действий, связанных с приемочным тестированием: стратегия, дата проведения, ответственные и т.д. 4. План автоматизации (Test Automation Plan) - документ, описывающий набор действий, связанных с автоматизацией тестированием: стратегия, правила, ответственные и т.д. Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является "живым" документом, который постоянно претерпевает изменения, отражающие реальное положение вещей на проекте. В повседневной жизни на проекте может быть один Мастер Тест План и несколько детальных тест планов, описывающих отдельные модули одного приложения. 100 Тест план должен пройти ревью. В этом процессе должны участвовать: Тест Лид (как автор) Тестеры Менеджер Проекта Заказчик Представитель отдела Обеспечения качества (QA) Test Case («тест- кейс», «тестовый случай», «тест») Тестовый случай (Test Case) – это – минимальный элемент верификация\проверка) тестирования (всего одна – совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части – описание определенных действий и условий, которые необходимы для того, чтобы выявить тот или иной баг Описание Тестового случая (Test Case) Хороший тест 101 – Существует обоснованная вероятность выявления тестом ошибки – Не является избыточным в наборе тестов – Наилучший в своей категории – Не слишком сложный и не слишком простой – Описаны условия, шаги однозначно, понятно и ожидаемый результат: – Объемы входных данных не должны быть очень большими (если этого не требуется специально) Тестовая матрица (Test Matrix) – документ, собержащий описание тестовых случаев и результатов их выполнения. Оценка качества тестов Тесты нуждаются в контроле качества так же, как и тестируемый продукт. Поскольку тесты для продукта являются своего рода эталоном его структурных и поведенческих характеристик, закономерен вопрос о том, насколько адекватен эталон. Для оценки качества тестов используются различные методы, наиболее популярные из которых кратко рассмотрены ниже. Тестовые метрики Существует устоявшийся набор тестовых метрик, который помогает определить эффективность тестирования и текущее состояние продукта. К таким метрикам относятся следующие: 1. Покрытие функциональных требований. 2. Покрытие кода продукта. Наиболее применимо для модульного уровня тестирования. 3. Покрытие множества сценариев. 4. Количество или плотность найденных дефектов. Текущее количество дефектов сравнивается со средним для данного типа продуктов с целью установить, находится ли оно в пределах допустимого статистического отклонения. При этом обнаруженные отклонения как в большую, так и в меньшую сторону приводят к анализу причин их появления и, если необходимо, к выработке корректирующих действий. 102 5. Соотношение количества найденных дефектов с количеством тестов на данную функцию продукта. Сильное расхождение этих двух величин говорит либо о неэффективности тестов (когда большое количество тестов находит мало дефектов) либо о плохом качестве данного участка кода (когда найдено большое количество дефектов на не очень большом количестве тестов). 6. Количество найденных дефектов, соотнесенное по времени, или скорость поиска дефектов. Если производная такой функции близка к нулю, то продукт обладает качеством, достаточным для окончания тестирования и поставки заказчику. 5.2.4. Автоматизация тестирования Использование различных подходов к тестированию определяется их эффективностью применительно к условиям, определяемым промышленным проектом. В реальных случаях работа группы тестирования планируется так, чтобы разработка тестов начиналась с момента согласования требований к программному продукту (выпуск Requirement Book, содержащей высокоуровневые требования к продукту) и продолжалась параллельно с разработкой дизайна и кода продукта. В результате, к началу системного тестирования создаются тестовые наборы, содержащие тысячи тестов. Большой набор тестов обеспечивает всестороннюю проверку функциональности продукта и гарантирует качество продукта, но пропуск такого количества тестов на этапе системного тестирования представляет проблему. Ее решение лежит в области автоматизации тестирования, т.е. в автоматизации разработки. Собственно использование эффективной системы автоматизации тестирования сокращает до минимума (например, до одной ночи) время пропуска тестов, без которого невозможно подтвердить факт роста качества (уменьшения числа оставшихся ошибок) продукта. Системное тестирование осуществляется в рамках циклов тестирования (периодов пропуска разработанного тестового набора над build разрабатываемого приложения). Перед каждым циклом фиксируется разработанный или исправленный build, на который заносятся обнаруженные в результате тестового прогона ошибки. Затем ошибки исправляются, и на очередной цикл тестирования предъявляется новый build. Окончание тестирования совпадает с экспериментально подтвержденным заключением о достигнутом уровне качества относительно выбранного критерия тестирования или о снижении плотности не обнаруженных ошибок до некоторой заранее оговоренной величины. Возможность ограничить цикл тестирования пределом в одни сутки или несколько часов 103 поддерживается исключительно за счет средств автоматизации тестирования. Рис.16. Этапы автоматизированного тестирования Разработка тестовых наборов Тестовый прогон Анализ результатов (контроль поркытия) Сохранение тестовых наборов Сохранение протоколов тестирования Сохранение статистики прогонов БАЗА РАЗВИТИЯ ПРОЕКТА Набор тестов, достаточный для покрытия тестируемого приложения в соответствии с выбранным критерием тестирования – как результат ручной или автоматической разработки (генерации) тестовых наборов и драйвер/монитор пропуска тестового набора. Результаты прогона тестового набора, зафиксированные в Logфайле. Log-файл содержит трассы ("протоколы"), представляющие собой реализованные при тестовом прогоне последовательности некоторых событий (значений отдельных переменных или их совокупностей) и точки реализации этих событий на графе программы. В составе трасс могут присутствовать последовательности явно и неявно заданных меток, задающих пути реализации трасс на управляющем графе программы, совокупности значений переменных на этих метках, 104 величины промежуточных результатов, достигнутых на некоторых метках и т.п. Статистика тестового цикла, содержащая: 1) результаты пропуска каждого теста из тестового набора и их сравнения с эталонными величинами; 2) факты, послужившие основанием для принятия решения о продолжении или окончании тестирования; 3) критерий покрытия и степень его удовлетворения, достигнутая в цикле тестирования. Результатом анализа каждого прогона является список проблем, в виде ошибок и дефектов, который заносится в базу развития проекта. Далее происходит работа над ошибками, где каждая поднятая проблема идентифицируется, относится к соответствующему модулю и разработчику, приоритезируется и отслеживается, что обеспечивает гарантию ее решения (исправления или отнесения к списку известных проблем, решение которых по тем или иным причинам откладывается) в последующих build. Исправленный и собранный для тестирования build поступает на следующий цикл тестирования, и цикл повторяется, пока нужное качество программного комплекса не будет достигнуто. В этом итерационном процессе средства автоматизации тестирования обеспечивают быстрый контроль результатов исправления ошибок и проверку уровня качества, достигнутого в продукте. Некачественный продукт зрелая организация не производит. Для автоматизации тестирования существует большое количество приложений. Наиболее популярные из них по итогам 2007 года: HP LoadRunner, HP QuickTest Professional, HP Quality Center Segue SilkPerformer IBM Rational FunctionalTester, IBM Rational PerformaneTester, IBM Rational TestStudio AutomatedQA TestComplete Использование этих инструментов помогает тестировщикам автоматизировать следующие задачи: установка продукта создание тестовых данных GUI взаимодействие определение проблемы Однако автоматические тесты не могут полностью заменить ручное тестирование. Автоматизация всех испытаний — очень 105 дорогой процесс, и потому автоматическое тестирование является лишь дополнением ручного тестирования. Наилучший вариант использования автоматических тестов — регрессионное тестирование. 5.2.5. Примеры. Модульное тестирование. Разработка через тестирование. Модульное тестирование (unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже написанных и оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок Цель модульного тестирования — изолировать отдельные части программы и показать, что по отдельности эти части работоспособны. Этот тип тестирования обычно выполняется программистами. Модульное тестирование позже позволяет программистам проводить рефакторинг, будучи уверенными, что модуль попрежнему работает корректно (регрессионное тестирование). Это поощряет программистов к изменениям кода, поскольку достаточно легко проверить, что код работает и после изменений. Упрощение интеграции Модульное тестирование помогает устранить сомнения по поводу отдельных модулей и может быть использовано для подхода к тестированию «снизу вверх»: сначала тестируются отдельные части программы, затем программа в целом. Документирование кода Модульные тесты можно рассматривать как «живой документ» для тестируемого класса. Клиенты, которые не знают, как использовать данный класс, могут использовать юнит-тест в качестве примера. Отделение интерфейса от реализации Поскольку некоторые классы могут использовать другие классы, тестирование отдельного класса часто распространяется на связанные с ним. Например, класс пользуется базой данных; в ходе написания 106 теста программист обнаруживает, что тесту приходится взаимодействовать с базой. Это ошибка, поскольку тест не должен выходить за границу класса. В результате разработчик абстрагируется от соединения с базой данных и реализует этот интерфейс, используя свой собственный mock-объект. Это приводит к менее связанному коду, минимизируя зависимости в системе. Ограничения Как и любая технология тестирования, модульное тестирование не позволяет отловить все ошибки программы. В самом деле, это следует из практической невозможности трассировки всех возможных путей выполнения программы, за исключением простейших случаев. Кроме того, происходит тестирование каждого из модулей по отдельности. Это означает, что ошибки интеграции, системного уровня, функций, исполняемых в нескольких модулях не будут определены. Кроме того, данная технология бесполезна для проведения тестов на производительность. Таким образом, модульное тестирование более эффективно при использовании в сочетании с другими методиками тестирования. Тестирование программного обеспечения — комбинаторная задача. Например, каждое возможное значение булевской переменной потребует двух тестов: один на вариант TRUE, другой — на вариант FALSE. В результате на каждую строку исходного кода потребуется 3-5 строк тестового кода. Для получения выгоды от модульного тестирования требуется строго следовать технологии тестирования во всём процессе разработки программного обеспечения. Нужно хранить не только записи обо всех проведённых тестах, но и обо всех изменениях исходного кода во всех модулях. С этой целью следует использовать систему контроля версий ПО. Таким образом, если более поздняя версия ПО не проходит тест, который был успешно пройден ранее, будет несложным сверить исходный код вариантов и устранить ошибку. Также необходимо убедиться в неизменном отслеживании и анализе неудачных тестов. Игнорирование этого требования приведёт к лавинообразному увеличению неудачных тестовых результатов. Приложения модульного тестирования Экстремальное программирование предполагает как один из постулатов использование инструментов автоматического модульного тестирования. Этот инструментарий может быть либо созданным 107 третьей стороной (например, Boost.Test), либо быть создан группой разработчиков данного приложения. В экстремальном программировании используются модульные тесты для разработки через тестирование. Для этого разработчик до написания кода пишет тесты, отражающие требования к модулю. Очевидно, ни один из этих тестов до написания кода работать не должен. Дальнейший процесс сводится к написанию кратчайшего кода, удовлетворяющего данному набору тестов. Разработка через тестирование (test-driven development) — техника программирования, при которой модульные тесты для программы или её фрагмента пишутся до самой программы (test-first development) и, по существу, управляют её разработкой. Является одной из основных практик экстремального программирования. Разработка в стиле TDD состоит из коротких циклов (длительностью от 2 минут, в зависимости от опытности и стиля работы программиста). Каждый цикл состоит из следующих шагов: 1. Из репозитория извлекается программная система, находящаяся в согласованном состоянии, когда весь набор модульных тестов выполняется успешно. 2. Добавляется новый тест. Он может состоять в проверке, реализует ли система некоторое новое поведение или содержит ли некоторую ошибку, о которой недавно стало известно. 3. Успешно выполняется весь набор тестов, кроме нового теста, который выполняется неуспешно. Этот шаг необходим для проверки самого теста — включён ли он в общую систему тестирования и правильно ли отражает новое требование к системе, которому она, естественно, еще не удовлетворяет. 4. Программа изменяется с тем, чтобы как можно скорее выполнялись все тесты. Нужно добавить самое простое решение, удовлетворяющее новому тесту, и одновременно с этим не испортить существующие тесты. Большая часть нежелательных побочных и отдалённых эффектов от вносимых в программу изменений отслеживается именно на этом этапе, с помощью достаточно полного набора тестов. 5. Весь набор тестов выполняется успешно. 6. Теперь, когда требуемая в этом цикле функциональность достигнута самым простым способом, программа перестраивается (рефакторинг) для улучшения структуры и устранения избыточного, дублированного кода. 7. Весь набор тестов выполняется успешно. 108 8. Комплект изменений, сделанных в этом цикле в тестах и программе заносится в репозиторий (операция commit), после чего программа снова находится в согласованном состоянии и содержит четко осязаемое улучшение по сравнению с предыдущим состоянием. Этот цикл упрощенно описывается Кентом Беком в своей книге как «красный-зеленый-рефакторинг». Красный и зеленый — это цвета полоски в среде тестирования JUnit, которая показывает, все тесты сработали или нет. При этом на первом («красном») этапе необходимо добиться того, чтобы программа просто компилировалась, без срабатывания добавленного теста. Для большинства популярных языков программирования высокого уровня существуют инструменты и библиотеки модульного тестирования. Некоторые из них: Для Java o JUnit JUnit.org o TestNG testNG.org o JavaTESK UniTESK.ru NUnit— для языков платформы .NET: C#, Visual Basic .NET и др. Для C o CTESK UniTESK.ru o cfix cfix Для C++ o CPPUnit o Boost Test o Google C++ Testing o Symbian— фреймворк для Symbian OS всех версий. DUnit— для Delphi Для Perl o Test o Test::Simple o Test::Unit o Test::Unit::Lite Для PHP o SimpleTest o PHPUnit Для Python o PyUnit o PyTest 109 Nose vbUnit— Visual Basic utPLSQL— PL/SQL Для T-SQL o TSQLUnit o SPUnit Для ActionScript 2.0 — язык сценариев, используемый виртуальной машиной Adobe Flash Player версии 7 и 8 o AsUnit o AS2Unit Для ActionScript 3.0 — скриптовый язык, используемый виртуальной машиной Adobe Flash Player версии 9 o FlexUnit o Test::Unit— для Ruby AsUnit JsUnit - для JavaScript o 5.3. Дефекты. Причины, описания, отслеживание. Ошибками в программном обеспечении, вообще говоря, являются все возможные несоответствия между демонстрируемыми характеристиками его качества и сформулированными или подразумеваемыми требованиями и ожиданиями пользователей. В англоязычной литературе используется несколько терминов, часто одинаково переводящихся как "ошибка" на русский язык: defect — самое общее нарушение каких-либо требований или ожиданий, не обязательно проявляющееся вовне (к дефектам относятся нарушения стандартов кодирования, недостаточная гибкость системы и пр.). failure — наблюдаемое нарушение требований, проявляющееся при каком-то реальном сценарии работы ПО. Это можно назвать проявлением ошибки. fault — ошибка в коде программы, вызывающая нарушения требований при работе (failures), то место, которое надо исправить. Хотя это понятие используется довольно часто, оно, вообще говоря, не вполне четкое, поскольку для устранения нарушения можно исправить программу в нескольких местах. Что именно надо исправлять, зависит от дополнительных условий, выполнение которых мы хотим при этом обеспечить, хотя в некоторых ситуациях наложение дополнительных ограничений не устраняет неоднозначность. 110 error — используется в двух смыслах. Первый смысл — это ошибка в ментальной модели программиста, ошибка в его рассуждениях о программе, которая заставляет его делать ошибки в коде (faults). Это, собственно, ошибка, которую сделал человек в своем понимании свойств программы. Второй смысл — это некорректные значения данных (выходных или внутренних), которые возникают при ошибках в работе программы. Эти понятия некоторым образом связаны с основными источниками ошибок. Поскольку при разработке программ необходимо сначала понять задачу, затем придумать ее решение и закодировать его в виде программы, то, соответственно, основных источников ошибок три: Неправильное понимание задач. Очень часто люди не понимают, что им пытаются сказать другие. Так же и разработчики ПО не всегда понимают, что именно нужно сделать. Другим источником непонимания служит отсутствие его у самих пользователей и заказчиков — достаточно часто они могут просить сделать несколько не то, что им действительно нужно. Для предотвращения неправильного понимания задач программной системы служит анализ предметной области. Неправильное решение задач. Зачастую, даже правильно поняв, что именно нужно сделать, разработчики выбирают неправильный подход к тому, как это делать. Выбираемые решения могут обеспечивать лишь некоторые из требуемых свойств, они могут хорошо подходить для данной задачи в теории, но плохо работать на практике, в конкретных обстоятельствах, в которых должно будет работать программное обеспечение. Помочь в выборе правильного решения может сопоставление альтернативных решений и тщательный анализ их на предмет соответствия всем требованиям, поддержание постоянной связи с пользователями и заказчиками, предоставление им необходимой информации о выбранных решениях, демонстрация прототипов, анализ пригодности выбираемых решений для работы в том контексте, в котором они будут использоваться. 111 Неправильный перенос решений в код. Имея правильное решение правильно понятой задачи, люди, тем не менее, способны сделать достаточно много ошибок при воплощении этих решений. Корректному представлению решений в коде могут помешать как обычные опечатки, так и забывчивость программиста или его нежелание отказаться от привычных приемов, которые не дают возможности аккуратно записать принятое решение. С ошибками такого рода можно справиться при помощи инспектирования кода, взаимного контроля, при котором разработчики внимательно читают код друг друга, опережающей разработки модульных тестов и тестирования. В программировании баг (bug — жук) — жаргонное слово, обычно обозначающее ошибку в программе или системе, которая выдает неожиданный или неправильный результат. Большинство багов возникают из-за ошибок, сделанных разработчиками программы в её исходном коде, либо в её дизайне. Также некоторые баги возникают из-за некорректной работы компилятора, вырабатывающего некорректный код. Программу, которая содержит большое число багов и/или баги, серьёзно ограничивающие её функциональность, называют нестабильной или, на жаргонном языке, «глючной», «забагованной» (unstable, buggy). Термин «баг» обычно употребляется в отношении ошибок, проявляющих себя на стадии работы программы, в отличие, например, от ошибок проектирования или синтаксических ошибок. Отчет, содержащий информацию о баге также называют отчетом об ошибке или отчетом о проблеме (bug report). Отчет о критической проблеме (crash), вызывающей аварийное завершение программы, называют крэш репортом (crash report). «Баги» локализуются и устраняются в процессе тестирования и отладки программы. ***Этимология Запись в тех.журнале По легенде, 9 сентября 1945 года учёные Гарвардского университета, тестировавшие вычислительную машину Mark II Aiken Relay Calculator, нашли мотылька, застрявшего между контактами электромеханического реле и Грейс Хоппер произнесла этот термин. Извлечённое насекомое было вклеено скотчем в технический дневник, с сопроводительной надписью: «First actual case of bug being found» 112 (англ. «первый случай обнаружения бага»). Этот забавный факт положил начало использованию слова «debugging» в значении «отладка программы». В действительности этот случай произошёл 9 сентября 1947, а не 1945, года. Слово «bug» в современном значении употреблялось задолго до этого. Так, в течение Второй мировой войны словом «bugs» назывались проблемы с радарной электроникой. Но ещё в 1878 году Томас Эдисон писал: «Это повторялось снова и снова со всеми моими изобретениями. Первым шагом была интуиция, за ней следовала вспышка, затем возникали препятствия — и они исчезали, потом возникали Баги — так называются маленькие недочеты и трудности — и необходимы месяцы постоянного поиска, исследований и тяжелого труда до успеха или неудачи.» Описание и отслеживание ошибок Система отслеживания ошибок (bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки (баги), найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий. Главный компонент такой системы — база данных, содержащая сведения об обнаруженных дефектах. Эти сведения фиксируются в отчете об ошибке и могут включать в себя: номер (идентификатор) дефекта; кто сообщил о дефекте; дата и время, когда был обнаружен дефект; версия продукта, в которой обнаружен дефект; серьёзность (критичность) дефекта и приоритет решения; описание шагов для выявления дефекта (воспроизведения неправильного поведения программы); кто ответственен за устранение дефекта; обсуждение возможных решений и их последствий; текущее состояние (статус) дефекта; версия продукта, в которой дефект исправлен. 113 Кроме того, развитые системы предоставляют возможность прикреплять файлы, помогающие описать проблему (например, дамп памяти или скриншот). Жизненный цикл дефекта Как правило, система отслеживания ошибок использует тот или иной вариант «жизненного цикла» ошибки, стадия которого определяется текущим состоянием, или статусом, в котором находится ошибка. Типичный жизненный цикл дефекта: 1. Новый — дефект зарегистрирован тестировщиком 2. Назначен — назначен ответственный за исправление дефекта 3. Разрешён — дефект переходит обратно в сферу ответственности тестировщика. Как правило, сопровождается резолюцией, например: o Исправлено (исправления включены в версию такую-то) o Дубль (повторяет дефект, уже находящийся в работе) o Не исправлено (работает в соответствии со спецификацией, имеет слишком низкий приоритет, исправление отложено до следующей версии и т.п.) o «У меня всё работает» (запрос дополнительной информации об условиях, в которых дефект проявляется) 4. Далее тестировщик проводит проверку исправления, в зависимости от чего дефект либо снова переходит в статус Назначен (если он описан как исправленный, но не исправлен), либо в статус Закрыт. 5. Открыт повторно — дефект вновь найден в другой версии. Система может предоставлять администратору возможность настроить, какие пользователи могут просматривать и редактировать ошибки в зависимости от их состояния, переводить их в другое состояние или удалять. В корпоративной среде, система отслеживания ошибок может использоваться для получения отчётов, показывающих продуктивность программистов при исправлении ошибок. Однако, часто такой подход не даёт достаточно точных результатов, из-за того что разные ошибки имеют различную степень серьёзности и сложности. При этом серьёзность проблемы не имеет прямого отношения к сложности устранения ошибки. 114 Примеры систем отслеживания ошибок Свободно распространяемые BUGS - the Bug Genie Bugzilla eTraxis Mantis bug tracking system Trac EmForge Redmine Проприетарные Atlassian JIRA PVCS Tracker TrackStudio Enterprise Разное BugTracker.NET ClearQuest Intland CodeBeamer FlySpray StarTeam Примеры «известных» ошибок. Первое место в неформальном состязании за место "самой дорого обошедшейся ошибки в ПО" (долгое время удерживала ошибка, приведшая к неудаче первого запуска ракеты Ариан-5 4 июня 1996 года стоившая около $500 000 000. После произошедшего 14 августа 2003 года обширного отключения электричества на северовостоке Северной Америки, стоившего экономике США и Канады от 4 до 10 миллиардов долларов это место можно отдать спровоцировавшей его ошибке в системе управления электростанцией. Широко известны также примеры ошибок в системах управления космическими аппаратами, приведшие к их потере или разрушению. Менее известны, но не менее трагичны, ошибки программного обеспечения, управлявшем медицинским и военным оборудованием, некоторые из которых привели к гибели людей. 115 Стоит отметить, что в большинстве примеров ошибок, имевших тяжелые последствия, нельзя однозначно приписать всю вину за случившееся ровно одному недочету, одному месту в коде. Ошибки очень часто "охотятся стаями". К тяжелым последствиям чаще всего приводят ошибки системного характера, затрагивающие многие аспекты и элементы системы в целом. Это значит, что при анализе такого происшествия обычно выявляется множество частных ошибок, нарушений действующих правил, недочетов в инструкциях и требованиях, которые совместно привели к создавшейся ситуации. Даже если ограничиться рассмотрением только программного обеспечения, часто одно проявление ошибки (failure) может выявить несколько дефектов, находящихся в разных местах. Такие ошибки возникают, как показывает практика, в тех ситуациях, поведение в рамках которых неоднозначно или недостаточно четко определяется требованиями (а иногда и вообще никак не определяется — признак неполного понимания задачи). Поэтому разработчики различных модулей программного обеспечения имеют возможность по-разному интерпретировать те части требований, которые относятся непосредственно к их модулям, а также иметь разные мнения по поводу области ответственности каждого из взаимодействующих модулей в данной ситуации. Если различия в их понимании не выявляются достаточно рано, при разработке системы, то становятся "минами замедленного действия" в ее коде. Например, анализ катастрофы Ариан-5 показал следующее Ариан-5 была способна летать при более высоких значениях ускорений и скоростей, чем это могла делать ракета предыдущей серии, Ариан-4. Однако большое количество процедур контроля и управления движением по траектории в коде управляющей системы было унаследовано от Ариан-4. Большинство таких процедур не были специально проверены на работоспособность в новой ситуации, как в силу большого размера кода, который надо было проанализировать, так и потому, что этот код раньше не вызывал проблем, а соотнести его со специфическими характеристиками полета ракет вовремя никто не сумел. В одной из таких процедур производилась обработка горизонтальной скорости ракеты. При выходе этой величины за границы, допустимые для Ариан-4, создавалась исключительная ситуация переполнения. 116 Надо отметить, что обработка нескольких достаточно однородных величин производилась по-разному — семь переменных могли вызвать исключительную ситуацию данного вида, обработка четырех из них была защищена от этого, а три оставшихся, включая горизонтальную скорость, оставлены без защиты. Аргументом для этого послужило выдвинутое при разработке требование поддерживать загрузку процессора не выше 80%. "Нагружающие" процессор защитные действия для этих переменных не были использованы, поскольку предполагалось, что эти величины будут находиться в нужных пределах в силу физических ограничений на параметры движения ракеты. Обоснований для поддержки именно такой загрузки процессора и того, что отсутствие обработки переполнения выбранных величин будет способствовать этому, найдено не было. Когда такая ситуация действительно случилась, т.е. горизонтальная скорость ракеты превысила определенное значение, она не была обработана соответствующим образом, и в результате ею вынужден был заняться модуль, обеспечивающим отказоустойчивость программной системы в целом. Этот модуль, в силу отсутствия у него какой-либо возможности обрабатывать такие ошибки специальным образом, применил обычный прием — остановил процесс, в котором возникла ошибка, и запустил другой процесс с теми же исходными данными. Как легко догадаться, эта же ошибка повторилась и во втором процессе. Не в силах получить какие-либо осмысленные данные о текущем состоянии полета, система управления использовала ранее полученные, которые уже не соответствовали действительности. При этом были ошибочно включены боковые двигатели "для корректировки траектории", ракета начала болтаться, угол между нею и траекторией движения стал увеличиваться и достиг 20 градусов. В результате она стала испытывать чрезмерные аэродинамические нагрузки и была автоматически уничтожена. 5.4. Типы дефектов и статические методы тестирования (Майерс) Бытует мнение, что первая программная ошибка была обнаружена на заре развития ЭВМ, когда в Массачусетском 117 технологическом институте окончилась неудачей попытка запуска машины Whirlwind I («Вихрь I»). Неистовая проверка монтажа, соединений и оборудования не выявила никаких неисправностей. Наконец, уже отчаявшись, решили проверить программу, представляющую собой маленькую полоску бумажной ленты. И ошибка была обнаружена именно в ней – в этом программистском ящике Пандоры, из которого на будущие поколения программистов обрушились беды, связанные с ошибками программ. Задача любого тестировщика заключается в нахождении наибольшего количества ошибок, поэтому он должен хорошо знать наиболее часто допускаемые ошибки и уметь находить их за минимально короткий период времени. Остальные ошибки, которые не являются типовыми, обнаруживаются только тщательно созданными наборами тестов. Однако, из этого не следует, что для типовых ошибок не нужно составлять тесты. Далее будет дана классификация ошибок, что поможет сосредоточить наши усилия в правильном направлении. 5.3.1 Классификация дефектов Для классификации ошибок мы должны определить термин «ошибка». Ошибка – это расхождение между вычисленным, наблюдаемым и истинным, заданным или теоретически правильным значением. Такое определение понятия «ошибка» не является универсальным, так как оно больше подходит для понятия «программная ошибка». В технологии программирования существуют не только программные ошибки, но и ошибки, связанные с созданием программного продукта, например, ошибки в документации программы. Но нас пока будут интересовать программные ошибки. Итак, по времени появления ошибки можно разделить на три вида: • структурные ошибки набора; • ошибки компиляции; • ошибки периода выполнения. Структурные ошибки возникают непосредственно при наборе программы. Что это за ошибки? Если кто-то работал в среде разработки Microsoft Visual Basic, то он знает, что если набрать оператор If, затем сравнение и нажать на клавишу Enter, не набрав слова Then, то Visual Basic укажет, что возникла ошибка компиляции. Это не совсем верно, так как компиляция в Visual Basic происходит только 118 непосредственно при выполнении команды программы. В данном случае мы имеем дело именно со структурной ошибкой набора. Данный тип ошибок определяется либо при наборе программы (самой IDE (Integrated Development Environment) – интегрированной средой разработки) или при ее компиляции, если среда не разделяет первые два типа ошибок. К данному типу ошибок относятся такие как: несоответствие числа открывающих скобок числу закрывающих, отсутствие парного оператора (например, try без catch), неправильное употребление синтаксических знаков и т. п. Во многих средах разработки программного обеспечения данный тип ошибок объединяется со следующим типом, так как раннее определение ошибок вызывает некоторое неудобство при наборе программ (скажем, я задумал что-то написать, а потом вспомнил, что в начале пропустил оператор, тогда среда разработки может выдать мне ошибку при попытке перейти в другую строку). Еще раз нужно отметить, что данный тип ошибок достаточно уникален и выделяется в отдельный тип только некоторыми средами разработки программного обеспечения. Ошибки компиляции возникают из-за ошибок в тексте кода. Они включают ошибки в синтаксисе, неверное использование конструкций языка (оператор else в операторе for и т. п.), использование несуществующих объектов или свойств, методов у объектов. Среда разработки (компилятор) обнаружит эти ошибки при общей компиляции приложения и сообщит о последствиях этих ошибок. Необходимо подчеркнуть слово «последствия» – это очень важно. Дело в том, что часто, говоря об ошибках, мы не разделяем проявление ошибки и саму ошибку, хотя это и не одно и то же. Например, ошибка «неопределенный класс» не означает, что класс не определен. Он может быть неподключенным, так как не подключен пакет классов. Ошибки периода выполнения возникают, когда программа выполняется и компилятор (или операционная система, виртуальная машина) обнаруживает, что оператор делает попытку выполнить недопустимое или невозможное действие. Например, деление на ноль. Предположим, имеется такое выражение: ratio = firstValue / sum. Если переменная sum содержит ноль, то деление – недопустимая операция, хотя сам оператор синтаксически правилен. Прежде, чем программа обнаружит эту ошибку, ее необходимо запустить на выполнение. 119 Хотя данный тип ошибок называется «ошибками периода выполнения», это не означает, что ошибки находятся только после запуска программы. Вы можете выполнять программу в уме и обнаружить ошибки данного типа, однако, понятно, что это крайне неэффективно. Если проанализировать все типы ошибок согласно первой классификации, то можно прийти к заключению, что при тестировании приходится иметь дело с ошибками периода выполнения, так как первые два типа ошибок определяются на этапе кодирования. В теоретической информатике программные ошибки классифицируют по степени нарушения логики на: • синтаксические; • семантические; • прагматические. Синтаксические ошибки заключаются в нарушении правописания или пунктуации в записи выражений, операторов и т. п., т. е. в нарушении грамматических правил языка. В качестве примеров синтаксических ошибок можно назвать: • пропуск необходимого знака пунктуации; • несогласованность скобок; • пропуск нужных скобок; • неверное написание зарезервированных слов; • отсутствие описания массива. Все ошибки данного типа обнаруживаются компилятором. Семантические ошибки заключаются в нарушении порядка операторов, параметров функций и употреблении выражений. Например, параметры у функции add (на языке Java) в следующем выражении указаны в неправильном порядке: GregorianCalendar.add(1, Calendar.MONTH). Параметр, указывающий изменяемое поле (в примере – месяц), должен идти первым. Семантические ошибки также обнаруживаются компилятором. Надо отметить, что некоторые исследователи относят семантические ошибки к следующей группе ошибок. Прагматические ошибки (или логические) заключаются в неправильной логике алгоритма, нарушении смысла вычислений и т. п. Они являются самыми сложными и крайне трудно обнаруживаются. Компилятор может выявить только следствие прагматической ошибки (см. выше пример с делением на ноль, компилятор обнаружит деление 120 на ноль, но когда и почему переменная sum стала равна нулю – должен найти программист). Таким образом, после рассмотрения двух классификаций ошибок можно прийти к выводу, что на этапе тестирования ищутся прагматические ошибки периода выполнения, так как остальные выявляются в процессе программирования. На этом можно было бы закончить рассмотрение классификаций, нос течением времени накапливался опыт обнаружения ошибок и сами ошибки, некоторые из которых образуют характерные группы, которые могут тоже служить характерной классификацией. Ошибка адресации – ошибка, состоящая в неправильной адресации данных (например, выход за пределы участка памяти). Ошибка ввода-вывода – ошибка, возникающая в процессе обмена данными между устройствами памяти, внешними устройствами. Ошибка вычисления – ошибка, возникающая при выполнении арифметических операций (например, разнотипные данные, деление на нуль и др.). Ошибка интерфейса – программная ошибка, вызванная несовпадением характеристик фактических и формальных параметров (как правило, семантическая ошибка периода компиляции, но может быть и логической ошибкой периода выполнения). Ошибка обращения к данным – ошибка, возникающая при обращении программы к данным (например, выход индекса за пределы массива, не инициализированные значения переменных и др.). Ошибка описания данных – ошибка, допущенная в ходе описания данных. Первичное выявление ошибок В течение многих лет большинство программистов убеждено в том, что программы пишутся исключительно для выполнения их на машине и не предназначены для чтения человеком, а единственным способом тес-тирования программы является ее исполнение на ЭВМ. Это мнение стало изменяться в начале 70-х годов в значительной степени благодаря книге Вейнберга «Психология программирования для ЭВМ». Вейнберг показал, что программы должны быть удобочитаемыми и что их просмотр должен быть эффективным процессом обнаружения ошибок. 121 По этой причине, прежде чем перейти к обсуждению традиционных методов тестирования, основанных на применении ЭВМ, рассмотрим процесс тестирования без применения ЭВМ («ручное тестирование»), являющийся по сути первичным обнаружением ошибок. Эксперименты показали, что методы ручного тестирования достаточно эффективны с точки зрения нахождения ошибок, так что один или несколько из них должны использоваться в каждом программном проекте. Описанные здесь методы предназначены для периода разработки, когда программа закодирована, но тестирование на ЭВМ еще не началось. Аналогичные методы могут быть получены и применены на более ранних этапах процесса создания программ (т. е. в конце каждого этапа проектирования). Следует заметить, что из-за неформальной природы методов ручного тестирования (неформальной с точки зрения других, более формальных методов, таких, как математическое доказательство корректности программ) первой реакцией часто является скептицизм, ощущение того, что простые и неформальные методы не могут быть полезными. Однако их использование показало, что они не «уводят в сторону». Скорее эти методы способствуют существенному увеличению производительности и повышению надежности программы. Во-первых, они обычно позволяют раньше обнаружить ошибки, уменьшить стоимость исправления последних и увеличить вероятность того, что корректировка произведена правильно. Во-вторых, психология программистов, по-видимому, изменяется, когда начинается тестирование на ЭВМ. Возрастает внутреннее напряжение и появляется тенденция «исправлять ошибки так быстро, как только это возможно». В результате программисты допускают больше промахов при корректировке ошибок, уже найденных во время тестирования на ЭВМ, чем при корректировке ошибок, найденных на более ранних этапах. Кроме того, скептицизм связан с тем, что это «первобытный метод». Да, сейчас стоимость машинного времени очень низка, а стоимость труда программиста, тестировщика высока и ряд руководителей пойдут на все, чтобы сократить расходы. Однако, есть другая сторона ручного тестирования – при тестировании за компьютером причины ошибок выявляются только в программе, а самая глубокая их причина – мышление программиста, как правило, не претерпевает изменений, при ручном же тестировании, программист глубоко анализирует свой код, попутно выявляя возможные пути его оптимизации, и изменяет собственный стиль мышления, повышая квалификацию. Таким образом, можно прийти к 122 выводу, что ручное тестирование можно и нужно проводить на первичном этапе, особенно, если нет прессинга времени и бюджета. 5.3.2 Инспекции и сквозные просмотры Инспекции исходного текста и сквозные просмотры являются основными методами ручного тестирования. Так как эти два метода имеют много общего, они рассматриваются здесь совместно. Инспекции и сквозные просмотры включают в себя чтение или визуальную проверку программы группой лиц. Эти методы развиты из идей Вейнберга. Оба метода предполагают некоторую подготовительную работу. Завершающим этапом является «обмен мнениями» – собрание, проводимое участниками проверки. Цель такого собрания – нахождение ошибок, но не их устранение (т. е. тестирование, а не отладка). Инспекции и сквозные просмотры широко практикуются в настоящее время, но причины их успеха до сих пор еще недостаточно выяснены. Заметим, что данный процесс выполняется группой лиц (оптимально три-четыре человека), лишь один из которых является автором программы. Следовательно, программа, по существу, тестируется не автором, другими людьми, которые руководствуются изложенными ранее принципами (в разделе 1), обычно не эффективными при тестировании собственной программы. Фактически «инспекция» и «сквозной просмотр» – просто новые названия старого метода «проверки за столом» (состоящего в том, что программист просматривает свою программу перед ее тестированием), однако они гораздо более эффективны опять-таки по той же причине: в процессе участвует не только автор программы, но и другие лица. Результатом использования этих методов является, обычно, точное определение природы ошибок. Кроме того, с помощью данных методов обнаруживают группы ошибок, что позволяет в дальнейшем корректировать сразу несколько ошибок. С другой стороны, при тестировании на ЭВМ обычно выявляют только симптомы ошибок (например, программа не закончилась или напечатала бессмысленный результат), а сами они определяются поодиночке. Ранее, более двух десятков лет, проводились широкие эксперименты по применению этих методов, которые показали, что с их помощью для типичных программ можно находить от 30 до 70 % ошибок логического проектирования и кодирования. (Однако эти методы не эффективны при определении ошибок проектирования «высокого уровня», например, сделанных в процессе анализа требований.) Так, было экспериментально установлено, что при 123 проведении инспекций и сквозных просмотров определяются в среднем 38 % общего числа ошибок в учебных программах. При использовании инспекций исходного текста в фирме IBM эффективность обнаружения ошибок составляла 80 % (в данном случае имеется в виду не 80 % общего числа ошибок, поскольку, как отмечалось ранее, общее число ошибок в программе никогда не известно, а 80 % всех ошибок, найденных к моменту окончания процесса тестирования). Конечно, можно критиковать эту статистику в предположении, что ручные методы тестирования позволяют находить только «легкие» ошибки (те, которые можно просто найти при тестировании на ЭВМ), а трудные, незаметные или необычные ошибки можно обнаружить только при тестировании на машине. Однако проведенное исследование показало, что подобная критика является необоснованной. Кроме того, можно было бы утверждать, что ручное тестирование «морально устарело», но если обратить внимание на список типовых ошибок, то они до сих пор остались прежними и увеличит ли скорость тестирования ЭВМ не всегда очевидно. Но то, что эти методы стали совсем непопулярными это факт. Бесспорно, что каждый метод хорош для своих типов ошибок и сочетание методов ручного тестирования и тестирования с применением ЭВМ для конкретной команды разработчиков представляется наиболее эффективным подходом; эффективность обнаружения ошибок уменьшится, если тот или иной из этих подходов не будет использован. Наконец, хотя методы ручного тестирования весьма важны при тестировании новых программ, они представляют не меньшую ценность при тестировании модифицированных программ. Опыт показал, что в случае модификации существующих программ вносится большее число ошибок (измеряемое числом ошибок на вновь написанные операторы), чем при написании новой программы. Следовательно, модифицированные программы также должны быть подвергнуты тестированию с применением данных методов. Инспекции исходного текста Инспекции исходного текста представляют собой набор процедур и приемов обнаружения ошибок при изучении (чтении) текста группой специалистов . При рассмотрении инспекций исходного текста внимание будет сосредоточено в основном на методах, процедурах, формах выполнения и т. д. 124 Инспектирующая группа включает обычно четыре человека, один из которых выполняет функции председателя. Председатель должен быть компетентным программистом, но не автором программы; он не должен быть знаком с ее деталями. В обязанности председателя входят подготовка материалов для заседаний инспектирующей группы и составление графика их проведения, ведение заседаний, регистрация всех найденных ошибок и принятие мер по их последующему исправлению. Председателя можно сравнить с инженером отдела технического контроля. Членами группы являются автор программы, проектировщик (если он не программист) и специалист по тестированию. Общая процедура заключается в следующем. Председатель заранее (например, за несколько дней) раздает листинг программы и проектную спецификацию остальным членам группы. Они знакомятся с материалами до заседания. Инспекционное заседание разбивается на две части: 1. Программиста просят рассказать о логике работы программы. Во время беседы возникают вопросы, преследующие цель обнаружения ошибки. Практика показала, что даже только чтение своей программы слушателям представляется эффективным методом обнаружения ошибок и многие ошибки находит сам программист, а не другие члены группы. Этот феномен известен давно и часто его применяют для решения проблем. Когда решение неочевидно, то объяснение проблемы другому человеку заставляет разработчика «разложить все по полочкам» и решение «само приходит» к разработчику. 2. Программа анализируется по списку вопросов для выявления исторически сложившихся общих ошибок программирования. Председатель является ответственным за обеспечение результативности дискуссии. Ее участники должны сосредоточить свое внимание на нахождении ошибок, а не на их корректировке. (Корректировка ошибок выполняется программистом после инспекционного заседания.) По окончании заседания программисту передается список найденных ошибок. Если список включает много ошибок или если эти ошибки требуют внесения значительных изменений, председателем может быть принято решение о проведении после корректировки повторной инспекции программы. Список анализируется и ошибки распределяются по категориям, что позволяет совершенствовать его с целью повышения эффективности будущих инспекций. Можно даже 125 вести учет типов ошибок на основании которого следует проводить дополнительную стажировку программиста в слабых областях. В большинстве примеров описания процесса инспектирования утверждается, что во время инспекционного заседания ошибки не должны корректироваться. Однако существует и другая точка зрения: «Вместо того, чтобы сначала сосредоточиться на основных проблемах проектирования, необходимо решить второстепенные вопросы. Два или три человека, включая разработчика программы, должны внести очевидные исправления в проект с тем, чтобы впоследствии решить главные задачи. Однако обсуждение второстепенных вопросов сконцентрирует внимание группы на частной области проектирования. Во время обсуждения наилучшего способа внесения изменений в проект ктолибо из членов группы может заметить еще одну проблему. Теперь группе придется рассматривать две проблемы по отношению к одним и тем же аспектам проектирования, объяснения будут полными и быстрыми. В течение нескольких минут целая область проекта может быть полностью исследована и любые проблемы станут очевидными... Как упоминалось выше, многие важные проблемы, возникавшие во время обзоров блок-схем, были решены в результате многократных безуспешных попыток решить вопросы, которые на первый взгляд казались тривиальными». Время и место проведения инспекции должны быть спланированы так, чтобы избежать любых прерываний инспекционного заседания. Его оптимальная продолжительность, повидимому, лежит в пределах от 90 до 120 мин. Так как это заседание является экспериментом, требующим умственного напряжения, увеличение его продолжительности ведет к снижению продуктивности. Большинство инспекций происходит при скорости, равной приблизительно 150 строк в час. При этом подразумевается, что большие программы должны рассматриваться за несколько инспекций, каждая из которых может быть связана с одним или несколькими модулями или подпрограммами. Для того чтобы инспекция была эффективной, должны быть установлены соответствующие отношения. Если программист воспринимает инспекцию как акт, направленный лично против него, и, следовательно, занимает оборонительную позицию, процесс инспектирования не будет эффективным. Программист должен подходить к нему с менее эгоистических позиций; он должен рассматривать инспекцию в позитивном и конструктивном свете: объективно инспекция является процессом нахождения ошибок в программе и таким образом улучшает качество его работы. По этой причине, как правило, рекомендуется результаты инспекции считать 126 конфиденциальными материалами, доступными только участникам заседания. В частности, использование результатов инспекции руководством может нанести ущерб целям этого процесса. Процесс инспектирования в дополнение к своему основному назначению, заключающемуся в нахождении ошибок, выполняет еще ряд полезных функций. Кроме того, что результаты инспекции позволяют программисту увидеть сделанные им ошибки и способствуют его обучению на собственных ошибках, он обычно получает возможность оценить свой стиль программирования и выбор алгоритмов и методов тестирования. Остальные участники также приобретают опыт, рассматривая ошибки и стиль программирования других программистов. Наконец, инспекция является способом раннего выявления наиболее склонных к ошибкам частей программы, позволяющим сконцентрировать внимание на этих частях в процессе выполнения тестирования на ЭВМ (один из принципов тестирования). Сквозные просмотры Сквозной просмотр, как и инспекция, представляет собой набор процедур и способов обнаружения ошибок, осуществляемых группой лиц, просматривающих текст программы. Такой просмотр имеет много общего с процессом инспектирования, но их процедуры несколько отличаются и, кроме того, здесь используются другие методы обнаружения ошибок. Подобно инспекции, сквозной просмотр проводится как непрерывное заседание, продолжающееся один или два часа. Группа по выполнению сквозного просмотра состоит из 3–5 человек. В нее входят председатель, функции которого подобны функциям председателя в группе инспектирования, секретарь, который записывает все найденные ошибки, и специалист по тестированию. Мнения о том, кто должен быть четвертым и пятым членами группы, расходятся. Конечно, одним из них должен быть программист. Относительно пятого участника имеются следующие предположения: 1) высококвалифицированный программист; 2) эксперт по языку программирования; 3) начинающий (на точку зрения которого не влияет предыдущий опыт); 4) человек, который будет, в конечном счете, эксплуатировать программу; 5) участник какого-нибудь другого проекта; 127 6) кто-либо из той же группы программистов, что и автор программы. Начальная процедура при сквозном просмотре такая же, как и при инспекции: участникам заранее, за несколько дней до заседания, раздаются материалы, позволяющие им ознакомиться с программой. Однако эта процедура отличается от процедуры инспекционного заседания. Вместо того, чтобы просто читать текст программы или использовать список ошибок, участники заседания «выполняют роль вычислительной машины». Лицо, назначенное тестирующим, предлагает собравшимся небольшое число написанных на бумаге тестов, представляющих собой наборы входных данных (и ожидаемых выходных данных) для программы или модуля. Во время заседания каждый тест мысленно выполняется. Это означает, что тестовые данные подвергаются обработке в соответствии с логикой программы. Состояние программы (т. е. значения переменных) отслеживается на бумаге или доске. Конечно, число тестов должно быть небольшим и они должны быть простыми по своей природе, потому что скорость выполнения программы человеком на много порядков меньше, чем у машины. Следовательно, тесты сами по себе не играют критической роли, скорее они служат средством для первоначального понимания программы и основой для вопросов программисту о логике проектирования и принятых допущениях. В большинстве сквозных просмотров при выполнении самих тестов находят меньше ошибок, чем при опросе программиста. Как и при инспекции, мнение участников является решающим фактором. Замечания должны быть адресованы программе, а не программисту. Другими словами, ошибки не рассматриваются как слабость человека, который их совершил. Они свидетельствуют о сложности процесса создания программ и являются результатом все еще примитивной природы существующих методов программирования. Сквозные просмотры должны протекать так же, как и описанный ранее процесс инспектирования. Побочные эффекты, получаемые во время выполнения этого процесса (установление склонных к ошибкам частей программы и обучение на основе анализа ошибок, стиля и методов) характерны и для процесса сквозных просмотров. 128 5.3.3 Проверка за столом Третьим методом ручного обнаружения ошибок является применявшаяся ранее других методов «проверка за столом». Проверка за столом может рассматриваться как проверка исходного текста или сквозные просмотры, осуществляемые одним человеком, который читает текст программы, проверяет его по списку ошибок и (или) пропускает через программу тестовые данные. Большей частью проверка за столом является относительно непродуктивной. Это объясняется прежде всего тем, что такая проверка представляет собой полностью неупорядоченный процесс. Вторая, более важная причина заключается в том, что проверка за столом противопоставляется одному из принципов тестирования, согласно которому программист обычно неэффективно тестирует собственные программы. Следовательно, проверка за столом наилучшим образом может быть выполнена человеком, не являющимся автором программы (например, два программиста могут обмениваться программами вместо того, чтобы проверять за столом свои собственные программы), но даже в этом случае такая проверка менее эффективна, чем сквозные просмотры или инспекции. Данная причина является главной для образования группы при сквозных просмотрах или инспекциях исходного текста. Заседание группы благоприятствует созданию атмосферы здоровой конкуренции: участники хотят показать себя с лучшей стороны при нахождении ошибок. При проверке за столом этот, безусловно, ценный эффект отсутствует. Короче говоря, проверка за столом, конечно, полезна, но она гораздо менее эффективна, чем инспекция исходного текста или сквозной просмотр. Список вопросов для выявления ошибок при инспекции: Важной частью процесса инспектирования является проверка программы на наличие общих ошибок с помощью списка вопросов для выявления ошибок. Концентрация внимания в предлагаемом списке на рассмотрении стиля, а не ошибок (вопросы типа «Являются ли комментарии точными и информативными?» и «Располагаются ли символы THEN/ELSE и DO/END по одной вертикали друг под другом?») представляется неудачной, так же как и наличие неопределенности в списке, уменьшающее его полезность (вопросы типа «Соответствует ли текст программы требованиям, выдвигаемым при проектировании?»). Список, приведенный в данном разделе, был составлен различными авторами. За основу взят список Майерса и дополнен автором после многолетнего изучения ошибок 129 программного обеспечения, разработанного как лично, так и другими специалистами, а также учебных программ. В значительной мере он является независимым от языка; это означает, что большинство ошибок встречается в любом языке программирования. Любой специалист может дополнить этот список вопросами, позволяющими выявить ошибки, специфичные для того языка программирования, который он использует, и обнаруженные им в результате выполнения процесса инспектирования. Ошибки обращения к данным Сводный список вопросов таков: 1. Используются ли переменные с неустановленными значениями? Наличие переменных с неустановленными значениями – наиболее часто встречающаяся программная ошибка, она возникает при различных обстоятельствах. Для каждого обращения к единице данных (например, к переменной, элементу массива, полю в структуре, атрибуту в классе) попытайтесь неформально «доказать», что ей присвоено значение в проверяемой точке. 2. Лежат ли индексы вне заданных границ? Не выходит ли значение каждого из индексов за границы, определенные для соответствующего измерения при всех обращениях к массиву, вектору, списку и т. п.? 3. Есть ли нецелые индексы? Принимает ли каждый индекс целые значения при всех обращениях к массиву, вектору, списку? Нецелые индексы не обязательно являются ошибкой для всех языков программирования, но представляют практическую опасность. 4. Есть ли «подвешенные» обращения? Создан ли объект (выделена ли память) для всех обращений с помощью указателей или переменных-ссылок на объект (или память)? Наличие, переменных-ссылок представляет собой ошибку типа «подвешенного обращения». Она возникает в ситуациях, когда время жизни указателя больше, чем время жизни объекта/памяти, к которому/ой производится обращение. Например, к такому результату приводит ситуация, когда указатель задает локальную переменную в теле метода, значение указателя присваивается выходному параметру или глобальной переменной, метод завершается (освобождая 130 адресуемую память), а программа затем пытается использовать значение указателя. Как и при поиске ошибок первых трех типов, попытайтесь неформально доказать, что для каждого обращения, использующего переменную-указатель, адресуемая память/объект существует. Этот тип ошибок характерен для языка Си или С++, где широко используются ссылки и указатели. Язык Java в этом отношении более развит, например, при потере всех ссылок на объект, объект переходит в «кучу мусора», где автоматически освобождается память из-под объекта (объект удаляется) специальным сборщиком мусора. Последние изменения в языке С++, выполненные командой разработчиков Microsoft, которые преобразовали этот язык в С#, реализуют похожий механизм. 5. Соответствуют ли друг другу определения структуры и ее использование в различных методах? Если к структуре данных обращаются из нескольких методов или процедур, то определена ли эта структура одинаково в каждой процедуре и используется ли она корректным способом? 6. Превышены ли границы строки? Не превышены ли границы строки при индексации в ней? Существуют ли какие-нибудь другие ошибки в операциях с индексацией или при обращении к массивам по индексу? Ошибки описания данных Сводный список вопросов таков: 1. Все ли переменные описаны? Все ли переменные описаны явно? Отсутствие явного описания не обязательно является ошибкой (например, Visual Basic допускает отсутствие описания), но служит потенциальным источником беспокойства. Так, если в подпрограмме на Visual Basic используется элемент массива и отсутствует его описание (например, в операторе DIM), то обращение к массиву может вызвать ошибку (например, Х = А(12)), так как по умолчанию, массив определен только на 10 элементов. Если отсутствует явное описание переменной во внутренней процедуре или блоке, следует ли понимать это так, что описание данной переменной совпадает с описанием во внешнем блоке? При разработке больших программных изделий неявное описание дан ных (описание данных по умолчанию) зачастую 131 запрещают методически (если это не запрещено языком), чтобы упростить поиск ошибок при комплексной отладке. 2. Правильно ли инициализированы объекты, массивы и строки? Если начальные значения присваиваются переменным в операторах описания, то правильно ли инициализируются эти значения? Правильно ли создаются объекты, используется ли соответствующий конструктор? 1. Понятны ли имена переменных? Наличие переменных с бессмысленными именами (например, i и j) не является ошибкой, но является объектом пристального внимания. Классически i и j являются циклическими переменными, а вот названий типа t125 следует избегать, так как возможна путаница имен. 2. Нельзя ли обойтись без переменных со сходными именами? Есть ли переменные со сходными именами (например, user и users)? Наличие сходных имен не обязательно является ошибкой, но служит признаком того, что имена могут быть перепутаны гденибудь внутри программы. 5. Корректно ли произведено описание класса? Правильно ли происходит описание атрибутов и методов класса? Имеются ли методы или атрибуты, которые по смыслу не подходят к данному классу? Не является ли класс громоздким? Наличие положительных ответов на эти вопросы указывает на возможные ошибки в анализе и проектировании системы. Ошибки вычислений Сводный список вопросов таков: 1. Производятся ли вычисления с использованием данных разного типа? Существуют ли вычисления, использующие данные разного типа? Например, сложение переменной с плавающей точкой и целой переменной. Такие случаи не обязательно являются ошибочными, но они должны быть тщательно проверены для обеспечения гарантии того, что правила преобразования, принятые в языке, понятны. Это важно как для языков с сильной типизацией (например, Ada, Java), так и для языков со слабой типизацией (например, С++, хотя он тяготеет к сильной типизации). 132 Например, для языка Java код byte a, b, c; … c = a + b; может вызвать ошибку, так как операция «сложение» преобразует данные к типу int, и результат может превысить максимально возможное значение для типа byte. Таким образом, важным для вычислений с использованием различных типов данных является явное или неявное преобразование типов. Ошибки, связанные с использованием данных разных типов являются одними из самых распространенных. 2. Производятся ли вычисления неарифметических переменных? 3. Возможно ли переполнение или потеря промежуточного результата при вычислении? Это означает, что конечный результат может казаться правильным, но промежуточный результат может быть слишком большим или слишком малым для машинного представления данных. Ошибки могут возникнуть даже если существует преобразование типов данных. 4. Есть ли деление на ноль? Классическая ошибка. Требует проверки всех делителей на неравенство нулю. Следствием данной ошибки является либо сообщение «деление на ноль», либо «переполнение», если делитель очень близок к нулю, а результат не может быть сохранен в типе частного (превышает его). 5. Существуют ли неточности при работе с двоичными числами? 6. Не выходит ли значение переменной за пределы установленного диапазона? Может ли значение переменной выходить за пределы установленного для нее логического диапазона? Например, для операторов, присваивающих значение переменной probability (вероятность), может быть произведена проверка, будет ли полученное значение всегда положительным и не превышающим единицу. Другие диапазоны могут зависеть от области решаемых задач. 7. Правильно ли осуществляется деление целых чисел? Встречается ли неверное использование целой арифметики, особенно деления? Например, если i – целая величина, то выражение 2*i/2 = i зависит от 133 того, является значение i четным или нечетным, и от того, какое действие – умножение или деление выполняется первым. Ошибки при сравнениях Сводный список вопросов таков: 1. Сравниваются ли величины несовместимых типов? Например, число со строкой? 2. Сравниваются ли величины различных типов? Например, переменная типа int с переменной типа long? Каждый язык ведет себя в этих случаях по-своему, проверьте это по его описанию. Как выполняются преобразования типов в этих случаях? 3. Корректны ли отношения сравнения? Иногда возникает путаница понятий «наибольший», «наименьший», «больше чем», «меньше чем». 4. Корректны ли булевские выражения? Если выражения очень сложные, имеет смысл преобразовать их или проверять обратное утверждение. 5. Понятен ли порядок следования операторов? Верны ли предположения о порядке оценки и следовании операторов для выражений, содержащих более одного булевского оператора? Иными словами, если задано выражение (А == 2) && (В == 2) || (С == 3), понятно ли, какая из операций выполняется первой: И или ИЛИ? 6. Понятна ли процедура разбора компилятором булевских выражений? Влияет ли на результат выполнения программы способ, которым конкретный компилятор выполняет булевские выражения? Например, оператор if ((x != 0) && ((y/x) > z)) является приемлемым для Java (т. е. компилятор заканчивает проверку, как только одно из выражений в операции «И» окажется ложным), но это выражение может привести к делению на ноль при использовании компиляторов других языков. 134 Ошибки в передачах управления Сводный список вопросов таков: 1. Может ли значение индекса в переключателе превысить число переходов? Например, значение переключателя для оператора select case. 2. Будет ли завершен каждый цикл? Будет ли каждый цикл, в конце концов, завершен? Придумайте неформальное доказательство или аргументы, подтверждающие их завершение. Хотя иногда бесконечные циклы не являются ошибкой, но лучше их избегать. 3. Будет ли завершена программа? Будет ли программа, метод, модуль или подпрограмма в конечном счете завершена? 4. Существует ли какой-нибудь цикл, который не выполняется из-за входных условий? Возможно ли, что из-за входных условий цикл никогда не сможет выполняться? Если это так, то является ли это оплошностью? 5. Есть ли ошибки отклонения числа итераций от нормы? Существуют ли какие-нибудь ошибки «отклонения от нормы» (например, слишком большое или слишком малое число итераций)? Ошибки интерфейса Сводный список вопросов таков: 1. Равно ли число входных параметров числу аргументов? Равно ли число параметров, получаемых рассматриваемым методом, числу аргументов, ему передаваемых каждым вызывающим методом? Правилен ли порядок их следования? Первый тип ошибок может обнаруживаться компилятором (но не для каждого языка), а вот правильность следования (особенно, если параметры одинакового типа) является важным моментом. 2. Соответствуют ли единицы измерения параметров и аргументов? Например, нет ли случаев, когда значение параметра выражено в градусах, а аргумента – в радианах? Или ошибки связанные с размерностью параметра/аргумента (например, вместо тонн передаются килограммы). 3. Не изменяет ли метод аргументы, являющиеся только входными? 4. Согласуются ли определения глобальных переменных во всех использующих их методах? Ошибки ввода-вывода 135 Сводный список вопросов таков: 1. Правильны ли атрибуты файлов? Не происходит ли запись в файлы read-only? 2. Соответствует ли формат спецификации операторам вводавывода? Не читаются ли строки вместо байт? 3. Соответствует ли размер буфера размеру записи? 4. Открыты ли файлы перед их использованием? 5. Обнаруживаются ли признаки конца файла? 6. Обнаруживаются ли ошибки ввода-вывода? Правильно ли трактуются ошибочные состояния ввода-вывода? 7. Существуют ли какие-нибудь текстовые ошибки в выходной информации? Существуют ли смысловые или грамматические ошибки в тексте, выводимом программой на печать или экран монитора? Все сообщения программы должны быть тщательно проверены. 5.5 Техники создания тест-кейсов. 5.5.1 Проектирование и исполнение. Проектирование теста может быть достаточно трудоемким процессом. Оно включает в себя следующие этапы: 1) задаться целью теста; 2) написать входные значения и шаги; 3) написать предполагаемые выходные значения; 4) выполнить тест и зафиксировать результат; 5) проанализировать результат. От правильного подхода к каждому этапу зависит качество тестирования в целом. О проблеме неверной постановки цели говорилось в первой главе. Необходимость второго этапа обосновано технологической необходимостью. Третий этап проектирования позволит избежать неоднозначности на пятом этапе. Очень часто, при отсутствии описания, что должно получиться, пытаются «подогнать» логику рассуждений в анализе результатов. Кроме того, очень часто этот пункт требует формирования либо независимой оценки (критерия), либо альтернативного просчета по алгоритму. В первом случае очень легко контролировать общий результат, во втором – более детально понять работу алгоритма. Бывают случаи, когда при ручном просчете предполагаемых выходных значений находят ошибки в логике работы программы. 136 Четвертый этап является практически механическим. На этом этапе не нужно думать, а только строго следовать предписанию и аккуратно фиксировать полученные значения. Если исполнение теста приносит результаты, не соответствующие предполагаемым, то это означает, что либо имеется ошибка, либо неверны предполагаемые результаты (ошибка в тесте). Для устранения такого рода недоразумений нужно тщательно проверять набор тестов («тестировать» тесты). Применение автоматизированных средств позволяет снизить трудоемкость процесса тестирования. Например, существуют средства, которые позволяют избавиться от потребности в драйверах. Средства анализа потоков дают возможность пронумеровать маршруты в программе, определить неисполняемые операторы, обнаружить места, где переменные используются до присвоения им значения. Также существуют программы позволяющие выполнять функции с набором параметров, которые варьируются в заданных пределах, что в общем случае, позволяет методом перебора проверить работу функции или метода. При подготовке к тестированию модулей целесообразно еще раз пересмотреть психологические и экономические принципы. При исполнении теста следует обращать внимание на побочные эффекты, например, если метод делает то, чего он делать не должен. В общем случае такую ситуацию обнаружить трудно, но иногда побочные эффекты можно выявить, если проверить не только предполагаемые выходные переменные, но и другие, состояние которых в процессе тестирования измениться не должно. Поэтому при его исполнении наряду с предполагаемыми результатами необходимо проверить и эти переменные. Во время тестирования возникают и психологические проблемы, связанные с личностью тестирующего. Программистам полезно поменяться кодом, чтобы не тестировать свой собственный. Так, программист, сделавший функцию вызова метода, является хорошим кандидатом для тестирования вызываемого метода. Заметим, что это относится только к тестированию, а не к отладке, которую всегда должен выполнять автор класса или модуля. Не следует выбрасывать результаты тестов; представляйте их в такой форме, чтобы можно было повторно воспользоваться ими в будущем. Если в некотором подмножестве классов обнаружено большое число ошибок, то эти классы, по-видимому, содержат еще большее число необнаруженных ошибок. Такие классы должны стать объектом дальнейшего тестирования; желательно даже дополнительно произвести контроль или просмотр их текста. Наконец, следует 137 помнить, что задача тестирования заключается не в демонстрации корректной работы, а в выявлении ошибок. 5.5.2 Техники создания тест-кейсов: методология «черного ящика» В стратегии «черного ящика» программа рассматривается как чёрный ящик. Целью тестирования ставится выяснение обстоятельств, в которых поведение программы не соответствует спецификации. Для обнаружения всех ошибок в программе необходимо выполнить исчерпывающее тестирование, то есть тестирование на всевозможных наборах данных. Для большинства программ такое невозможно, поэтому применяют разумное тестирование, при котором тестирование программы ограничивается небольшим подмножеством всевозможных наборов данных. При этом необходимо выбирать наиболее подходящие подмножества, подмножества с наивысшей вероятностью обнаружения ошибок. Свойства правильно выбранного теста 1. Уменьшает более, чем на одно число других тестов, которые должны быть разработаны для разумного тестирования. 2. Покрывает значительную часть других возможных тестов, что в некоторой степени свидетельствует о наличии или отсутствии ошибки до и после ограниченного множества тестов. Техники стратегии чёрного ящика 1. 2. 3. 4. Эквивалентное разбиение. Анализ граничных значений. Анализ причинно-следственных связей. Предположение об ошибке. Рассмотрим подробнее каждый из этих методов: Эквивалентное разбиение Основу метода составляют два положения: 1. Исходные данные необходимо разбить на конечное число классов эквивалентности. В одном классе эквивалентности содержатся такие тесты, что, если один тест из класса эквивалентности обнаруживает некоторую ошибку, то и любой 138 другой тест из этого класса эквивалентности должен обнаруживать эту же ошибку. 2. Каждый тест должен включать, по возможности, максимальное количество классов эквивалентности, чтобы минимизировать общее число тестов. Разработка тестов этим методом осуществляется в два этапа: выделение классов эквивалентности и построение теста. Классы эквивалентности выделяются путём выбора каждого входного условия, которые берутся с помощью технического задания или спецификации и разбиваются на две (правильные и неправильные) и более группы. Выделение классов эквивалентности способом, однако существует ряд правил: является эвристическим 1. Если входное условие описывает область значений, например «Целое число принимает значение от 0 до 999», то существует один правильный класс эквивалентности и два неправильных. 2. Если входное условие описывает число значений, например «Число строк во входном файле лежит в интервале (1..6)», то также существует один правильный класс и два неправильных. 3. Если входное условие описывает множество входных значений, то определяется количество правильных классов, равное количеству элементов в множестве входных значений. Если входное условие описывает ситуацию «должно быть», например «Первый символ должен быть заглавным», тогда один класс правильный и один неправильный. 4. Если есть основание считать, что элементы внутри одного класса эквивалентности могут программой трактоваться поразному, необходимо разбить данный класс на подклассы. На этом шаге тестирующий на основе таблицы должен составить тесты, покрывающие собой все правильные и неправильные классы эквивалентности. При этом составитель должен минимизировать общее число тестов. Определение тестов: 1. Каждому классу эквивалентности присваивается уникальный номер. 2. Если еще остались не включенные в тесты правильные классы, то пишутся тесты, которые покрывают максимально возможное количество классов. 139 3. Если остались не включенные в тесты неправильные классы, то пишут тесты, которые покрывают только один класс. Анализ граничных значений Граничные условия — это ситуации, возникающие на высших и нижних границах входных классов эквивалентности. Анализ граничных значений отличается от эквивалентного разбиения следующим: 1. Выбор любого элемента в классе эквивалентности в качестве представительного осуществляется таким образом, чтобы проверить тестом каждую границу этого класса. 2. При разработке тестов рассматриваются не только входные значения (пространство входов), но и выходные (пространство выходов). Метод требует определённой степени творчества и специализации в рассматриваемой задаче. Cуществует несколько правил: 1. Построить тесты с неправильными входными данными для ситуации незначительного выхода за границы области значений. Если входные значения должны быть в интервале [-1.0 .. +1.0], проверяем −1.0, 1.0, −1.000001, 1.000001. 2. Обязательно писать тесты для минимальной и максимальной границы диапазона. 3. Использовать первые два правила для каждого из входных значений (использовать пункт 2 для всех выходных значений). 4. Если вход и выход программы представляет упорядоченное множество, сосредоточить внимание на первом и последнем элементах списка. Анализ граничных значений, если он применён правильно, позволяет обнаружить большое число ошибок. Однако определение этих границ для каждой задачи может являться отдельной трудной задачей. Также этот метод не проверяет комбинации входных значений. Анализ причинно-следственных связей Этапы построения теста: 140 3. Спецификация разбивается на рабочие участки. 4. В спецификации определяются множество причин и следствий. Под причиной понимается отдельное входное условие или класс эквивалентности. Следствие представляет собой выходное условие или преобразование системы. Здесь каждой причине и следствию присваивается номер. 5. На основе анализа семантического (смыслового) содержания спецификации строится таблица истинности, в которой последовательно перебираются всевозможные комбинации причин и определяются следствия для каждой комбинации причин. Таблица снабжается примечаниями, задающими ограничения и описывающими комбинации, которые невозможны. Недостатком этого подхода является плохое исследование граничных условий. Предположение об ошибке Программист с большим опытом выискивает ошибки без всяких методов, но при этом он подсознательно использует метод предположения об ошибке. Данный метод в значительной степени основан на интуиции. Основная идея метода состоит в том, чтобы составить список, который перечисляет возможные ошибки и ситуации, в которых эти ошибки могли проявиться. Потом на основе списка составляются тесты. 5.5.3 Техники создания тест-кейсов: методология «белого ящика». Control-Flow Based Testing (тестирование управляющей логики программы): Шаг 1: строим граф, описывающий логику, реализованную в коде 141 142 143 Шаг 2: создаем тест-кейсы для покрытия всех узлов графа, ребер графа (ветки, пути) Statement coverage (покрытие операторов = Line coverage) каждый оператор должен быть выполнен хотя бы один раз слабый критерий – необходимое, но недостаточное условие «-» затруднен анализ покрытия некоторых управляющих структур (не проверяется условные операторы при значении false, достаточно проверить только для значения true, чтобы выполнить оператор) >> слабый критерий – обычно не используют Пример: If (a>0) c:=25; - > один тест для критерия statement coverage для a>0 - > пропускает проверку того, что будет, если a<0 144 a A>1 AND B=0 Y c N X=X/A b A=2 OR X>1 e Y N X=X/A d Вranch\Decision coverage (ветки операторов) каждое решение должно принять значения истина и ложь по крайней мере один раз и для каждой точки входа должно быть выдано управление хотя бы один раз (IF, CASE, Loop) 145 Более сильный критерий, чем покрытие операторов «-» не учитываются условия с вызовами функций внутри условных операторов Необходимый минимум Определяем набор путей start-to-end, которые покрывают все ветки графа и пишем для них тесты Циклы (loops) Простой цикл • • • • Пропустить цикл Пройти один раз Пройти дважды Если мах=n, тогда проходим n-1, n и n+1 раз Вложенный цикл • Устанавливаем счетчик в min для наружных (внешних) циклов и проверяем внутренние • Тестируем значения, выходящие за границы • Все внешние циклы в min 146 • Пока не протестируем все циклы Condition coverage (покрытие условий) Все возможные результаты каждого решения в условии выполнялись хотя бы один раз (каждая компонента логического условия в результате выполнения тестовых примеров должна принимать все возможные значения) и каждой точке входа в программу или подпрограмму должно быть передано управление хотя бы один раз Более сильный критерий, чем покрытие решений Data-Flow testing (тестирование потоков данных) Анализируем все переменные в коде: их определение (“definitions”\”write”) и использование (“uses”\”read”) Определяем все DU пары (Def-Use pairs) и пишем тесты, покрывающие все DU пары для всех переменных: 147 148 Приложение 1 Конфигурационное управление – построение «билдов». (http://window.edu.ru/window_catalog/pdf2txt?p_id=31136&p_page=4) Рассмотрим проект по разработке программного обеспечения. Что в нем является аналогом материальных активов на обычном производстве? Определенно, не столы и стулья, которыми пользуются разработчики. И даже не компьютеры, запчасти к ним и прочее оборудование. Учета и контроля, сродни складскому, требуют файлы проекта. В программном проекте их очень много – сотни и тысячи даже для относительно небольших проектов. Ведь создать новый файл очень легко. Многие технологии программирования поддерживают стиль, когда, например, для каждого класса создается свой отдельный файл. Файл – это виртуальная информационная единица. В чем главное отличие файла от материальных единиц учета? В том, что у файла может быть версия, и не одна, и породить эти версии очень легко – достаточно скопировать данный файл в другое место на диске. В то время как материальные предметы существуют на складе сами по себе, и для них нет понятия версии. Да, может быть несколько однотипных предметов, разных заготовок изделия различной степени готовности. Но все это не то….. А версия файла – это очень не простой объект. Чем одна версия отличается от другой? Несколькими строчками текста или полностью обновленным содержанием? И какая из двух и более версий главнее, лучше? К этому добавляется еще и то, что многие рабочие продукты могут состоять из набора файлов, и каждый из них может иметь по несколько версий. Как собрать корректную версию продукта? В итоге в программном проекте начинают происходить мистические и загадочные события. Тщательно протестированная программа на показательных испытаниях не работает. Функциональность, о которой долго просил заказчик и которая была, наконец, добавлена в продукт, а новая версия торжественно отослана заказчику, таинственным образом исчезла из продукта. На компьютере разработчика программа работает, а у заказчика – нет…. Разгадка проста – все дело в версиях файлов. Там, где все хорошо, присутствуют файлы одной версии, а там, где все плохо – другой. Но беда в том, что «версия всего продукта» – это абстрактное понятие. На 149 деле есть версии отдельных файлов. Один или несколько файлов в поставке продукта имеют не ту версию – все, дело плохо. Необходимо управлять версиями файлов, а то подобная мистика может стать огромной проблемой. Она серьезно тормозит внутреннюю работу. То разработчики и тестеры работают с разными версиями системы, то итоговая сборка системы требует специальных напряжения усилий всего коллектива. Более того, возможны неприятности на уровне управления. Различные курьезные ситуации, когда заявленная функциональность отсутствует или не работает (опять не те файлы послали!), могут сильно портить отношения с заказчиком. Недовольный заказчик может потребовать даже денежной компенсации за то, что возникающие ошибки слишком по долгу исправляются. А будет тут не долго, когда разработчики не могут воспроизвести и исправить ошибку, так как не могут точно определить, из каких же исходных текстов была собрана данная версия! Итак, становится понятно, что в программных проектах необходима специальная деятельность по поддержанию файловых активов проекта в порядке. Она и называется конфигурационным управлением. Выделим две основные задачи в конфигурационном управлении – управление версиями и управление сборками. Первое отвечает за управление версиями файлов и выполняется в проекте на основе специальных программных пакетов – средств версионного контроля. Существует большое количество таких средств – Microsoft Visual SourceSafe, IBM ClearCase, cvn, subversion и др. Управление сборками – это автоматизированный процесс трансформации исходных текстов ПО в пакет исполняемых модулей, учитывающий многочисленные настройки проекта, настройки компиляции, и интегрируемый с процессом автоматического тестирования. Эта процедура является мощным средством интеграции проекта, основой итеративной разработки. Единицы конфигурационного управления Так чем же мы управляем в рамках этой деятельности? Любыми ли файлами, которые имеются в проекте? Нет, не любыми, а только теми, которые изменяются. Например, файлы с используемым в проекте покупным ПО должны покоиться на CD-дисках или в локальной сети. Книги, документы с внешними стандартами, используемыми в проекте (например, в телекоммуникациях очень много разных стандартов на сетевые интерфейсы) и пр. также должны просто храниться там, где каждый желающий их может взять. Как 150 правило, такой информации в проекте немного, но, разумеется, она должна быть в порядке. Однако ради этого специальный вид деятельности в проекте не нужен. Итак, конфигурационное управление имеет дело с меняющимися в процессе продуктами, состоящими из наборов файлов. Такие продукты принято называть единицами конфигурационного управления (configuration management items). Вот примеры: 1. пользовательская документация; 2. проектная документация; 3. исходные тексты ПО; 4. пакеты тестов; 5. инсталляционные пакеты ПО; 6. тестовые отчеты. У каждой единицы конфигурационного управления должно быть следующее. 1. Структура – набор файлов. Например, пользовательская документация в html должна включать индекс-файл и набор html-файлов, а также набор вынесенных картинок (gif или jpeg-файлы). Эта структура должна быть хорошо определена и отслеживаться при конфигурационном управлении – что все файлы не потеряны и присутствуют, имеют одинаковую версию, корректные ссылки друг на друга и т.д. 2. Ответственное лицо и, возможно, группу тех, кто их разрабатывает, а также более широкую и менее ответственную группу тех, кто пользуется этой информацией. Например, определенной программной компонентой могут в проекте пользоваться многие разработчики, но отвечать за ее разработку, исправление ошибок и пр. должен кто-то один. 3. Практика конфигурационного управления – кто и в каком режиме, а также в какое место выкладывает новую версию элемента конфигурационного управления в средство управления версиями, правила именования и комментирования элемента в этой версии, дальнейшие манипуляции с ним там и пр. Более высокоуровневые правила, связанные, например, с правилами изменения тестов и тестовых пакетов при изменении кода. Однако, где-то здесь лежит водораздел между конфигурационным управлением и иными видами деятельности в проекте 151 4. Автоматическая процедура контроля целостности элемента – например, сборка для исходных текстов программ. Есть не у всех элементов, например, может не быть у документации, тестовых пакетов. Элементы конфигурационного управления могут образовывать иерархию. Управление версиями Управление версиями файлов. Поскольку программисты имеют дело с огромным количеством файлов, многие файлы в один момент могут быть необходимы нескольким людям и важно, чтобы все они постоянно составляли единую, как минимум, компилирующуюся версию продукта, необходимо, чтобы была налажена работа с файлами с исходным кодом. Также может быть налажена работа и с другими типами файлов. В этой ситуации файлы оказываются самыми младшими (по иерархии включения) элементами конфигурационного управления. Управление версиями составных конфигурационных объектов. Понятие «ветки» проекта. Одновременно может существовать несколько версий системы – и в смысле для разных заказчиков и пр. (так сказать, в большом, настоящем смысле), и в смысле одного проекта, одного заказчика, но как разный набор исходных текстов. И в том и в другом случае в средстве управления версиями образуются разные ветки. Остановимся чуть подробнее на втором случае. Каждая ветка содержит полный образ исходного кода и других артефактов, находящихся в системе контроля версий. Каждая ветвь может развиваться независимо, а может в определенных точках интегрироваться с другими ветвями. В процессе интеграции изменения, произведенные в одной из ветвей, полуавтоматически переносятся в другую. В качестве примера можно рассмотреть следующую структуру разделения проекта на ветки. • V1.0 – ветвь, соответствующая выпущенному релизу. Внесение изменений в такие ветви запрещены и они хранят образ кода системы на момент выпуска релиза. • Fix V1.0.1 – ветвь, соответствующая выпущенному пакету исправлений к определенной версии. Подобные ветви ответвляются от исходной версии, а не от основной ветви и замораживаются сразу после выхода пакета исправлений. 152 • Upcoming (V1.1) – ветвь, соответствующая релизу, готовящемуся к выпуску и находящемуся в стадии стабилизации. Для таких ветвей, как правило, действуют более строгие правила и работа в них ведется более формально. • Mainline – ветвь, соответствующая основному направлению развития проекта. По мере созревания именно от этой ветви отходят ветви готовящихся релизов. • WCF Experiment – ветвь, созданная для проверки некоторого технического решения, перехода на новую технологию, или внесения большого пакета изменений, потенциально нарушающих работоспособность кода на длительное время. Такие ветви, как правило, делаются доступными только для определенного круга разработчиков и убиваются по завершению работ после интеграции с основной веткой. Управление сборками Итак, почему же процедура компиляции и создания exe dll файлов по исходникам проекта – такая важная процедура? Потому что она многократно в день выполняется каждым разработчиком на его собственном компьютере, с его собственной версией проекта. При этом отличается: - набор подпроектов, собираемых разработчиком; - он может собирать не весь проект, а только какую-то его часть; - другая часть либо им не используется вовсе, либо не пересобирается очень давно, а по факту она давно изменилась; - отличаются параметры компиляции. При этом если не собирать регулярно итоговую версию проекта, то общая интеграция может выявить много разных проблем: - несоответствие друг другу различных частей проекта; - наличие специфических ошибок, возникших из-за того, что отдельные проекты разрабатывались без учета параметров компиляции (в частности, переход в Visual Studio c debug на release версию часто сопровождается появлением многочисленных проблем). В связи с этим процедуру сборки проекта часто автоматизируют, то есть выполняют не из среды разработки, а из 153 специального скирпта – build-скрипта. Этот скрипт используется тогда, когда разработчику требуется полная сборка всего проекта. А также он используется в процедуре непрерывной интеграции (continues integration) – то есть регулярной сборке всего проекта (как правило – каждую ночь). Как правило, процедура непрерывной интеграции включает в себя и регрессионное тестирование, и часто – создание инсталляционных пакетов. Общая схема автоматизированной сборки: Взять исходники из средства контроля версиями -> используя стандартные настройки сборки вызвать компилятор -> прогон регрессионных тестов -> если тесты прошли, то рассылаем отчет Тестировщики должны тестировать по возможности итоговую и целостную версию продукта, так что результаты регулярной сборки оказываются очень востребованы. Кроме того, наличие базовой, актуальной, целостной версии продукта позволяет организовать разработку в итеративноинкрементальном стиле, то есть на основе внесения изменений. Такой стиль разработки называется baseline-метод. Baseline – это базовая, последняя целостная версия некоторого продукта разработки, например, документации, программного кода и т.д. Подразумевается, что разработка идет не сплошным потоком, а с фиксацией промежуточных результатов в виде текущей официальной версии разрабатываемого актива. Принятие такой версии сопровождается дополнительными действиями по оформлению, сглаживанию, тестированию, включению только законченных фрагментов и т.д. Это результат можно посмотреть, отдать тестеровщикам, передать заказчику и т.д. Baseline служит хорошим средством синхронизации групповой работы. Baseline может быть совсем простой – веткой в средстве управления версиями, где разработчики хранят текущую версию своих исходных кодов. Единственным требованием в этом случае может быть лишь общая компилируемость проекта. Но поддержка baseline может быть сложной формальной процедурой. Baseline может также поддерживаться непрерывной интеграцией. Важно, что Baseline (особенно в случае в программными активами) не должна устанавливаться слишком рано. Сначала нужно написать какое-то количество кода, чтобы было что интегрировать. Кроме того, вначале много внимания уделяется разработке основных архитектурных решений, и целостная версия оказывается не 154 востребованной. Но начиная с какого-то момента она просто необходима. Какой этот момент – решать членам команды. Наконец, существую проекты, где автоматическая сборка не нужна вовсе – это простые проекты, разрабатываемые небольшим количеством участников, где нет большого количество исходных текстов программ, проектов, сложных параметров 155 Приложение 2 Рациональный унифицированный процесс (Rational Unified Process - RUP), Лилия Хаф Рациональный унифицированный процесс (Rational Unified Process, RUP) — одна из спиральных методологий разработки программного обеспечения. Методология поддерживается компанией Rational Software, обновление продукта происходит примерно дважды в год. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML). Итерационная разработка программного обеспечения в RUP предполагает разделение проекта на несколько мелких проектов, которые выполняются последовательно, и каждая итерация разработки четко определена набором целей, которые должны быть достигнуты в конце итерации. Конечная итерация предполагает, что набор целей итерации должен в точности совпадать с набором целей, указанных заказчиком продукта, то есть все требования должны быть выполнены. RUP достаточно хорошо формализован, и наибольшее внимание уделяется начальным стадиям разработки проекта — анализу и моделированию. Таким образом, эта методология направлена на снижение коммерческих рисков (risk mitigating) посредством обнаружения ошибок на ранних стадиях разработки. Технические риски (assesses) оцениваются и «расставляются» согласно приоритетам на ранних стадиях цикла разработки, а затем пересматриваются с течением времени и с развитием проекта в течение последующих итераций. Новые цели появляются в зависимости от приоритетов данных рисков. Релизы версий распределяются таким образом, что наиболее приоритетные риски устраняются первыми. Процесс предполагает эволюционирование моделей; итерация цикла разработки однозначно соответствует определенной версии модели программного обеспечения. Каждая из итераций (workflow) содержит элементы управления жизненным циклом программного обеспечения: анализ и дизайн (моделирование), реализация, интегрирование, тестирование, внедрение. В этом смысле RUP является реализацией спиральной модели, хотя довольно часто изображается в виде графика-таблицы. Ниже мы приведем основные компоненты процесса. Для успешного процесса разработки необходимы три составляющие (Рис. 15): - процесс (process), 156 - нотация (notation) - набор утилит (tools). Процесс описывает, что мы делаем, в каком порядке и каким образом. Нотация является средством коммуникации. Набор утилит автоматизирует и управляет процессом. Рис. 17. Треугольник успеха В RUP представлены все три компонента. Сначала рассмотрим функции нотации, которые производят следующие действия: • осуществляет «склеивание» процесса в единое целое; • является языковым средством принятия решений, которые не очевидны из исходного кода; • предоставляет семантику для отображения важных стратегических и тактических решений; • предлагает форму, достаточную для того, чтобы размышлять, а потом принимать решения и средства автоматизации процесса для того, чтобы манипулировать формализованными данными. Фактически нотация охватывает разработку программного обеспечения, начиная с анализа и заканчивая внедрением продукта. Нотация в случае RUP–UML — формальное языковое средство описания процесса (об UML речь пойдет ниже). Далее рассмотрим 157 структуру процесса, а также приведем набор утилит, используемых в процессе управления разработкой проекта согласно RUP. Структура RUP RUP предоставляет структурированный подход к итерационной разработке программного обеспечения, подразделяя процесс на четыре основные фазы во времени (milestones): Inception (исследование, начало), Elaboration (уточнение плана), Construction (конструирование, построение) и Transition (переход, развертывание). К сожалению, в русском языке нет установившейся терминологии, поэтому в дальнейшем мы будем использовать английские термины, сопровождая их переводом на русский язык. На рис. 2 представлено широко распространенное изображение фаз RUP. Целями каждой из данных фаз являются: • Inception — понимание, что мы создаем. Фаза сбора информации и анализа требований, определение образа проекта в целом; • Elaboration — понимание, как мы это создаем. Фаза анализа требований и проектирования системы, планирование необходимых действий и ресурсов, спецификация функций и особенностей дизайна; • Construction — создание бета-версии продукта. Основная фаза разработки и кодирования, построение продукта как восходящей последовательности итераций (версий кода); • Transition — создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю. 158 Рис. 18. Фазы RUP Это фазы управления эволюцией продукта — итерациями жизненного цикла. RUP предполагает приближение к конечной цели, но, в отличие от классического стандарта ISO (методология «водопад»), где transition является конечной фазой, каждая из фаз может повторяться несколько раз, отражая изменение требований заказчика продукта. Методология RUP основана на девяти основных потоках (workflow), являющихся элементами итерации жизненного цикла ПО: • Business modeling (бизнес-анализ) — предполагает анализ требований на данной итерации жизненного цикла, определение желаемых параметров системы и нужд пользователей; • Requirements (требования) — формализация образа системы. Предполагает сбор требований и управление требованиями, перевод требований в функциональные спецификации. Здесь начинается анализ прецедентов и построение use cases (пользовательских историй) — формальное отображение требований пользователя в UML. Результатом являются документы уровня менеджмента; • Analysis and design (анализ и моделирование) — предполагает перевод собранных требований в формализованную программную модель. Результатом является описание системы на фазе реализации (технический проект) — это документы уровня разработчиков системы. Язык формализации — Unified Modelling Language (UML), о 159 котором речь пойдет ниже. В процессе итеративной разработки эволюционировать будет продукт именно этого потока — модель проекта. Все изменения привязываются в RUP непосредственно к моделям, а средства автоматизации и довольно гибкий язык моделирования позволяют управлять данным процессом более или менее безболезненно в плане затрат времени и ресурсов. Здесь имеется в виду тот факт, что результатом разработки является не модель, а исполняемый код. Поэтому заказчик обычно не очень любит платить за моделирование, так как модели не являются продуктом, который ему нужен; • Implementation (реализация, кодирование) — предполагает собственно написание кода. Элементы кода в RUP уже созданы на этапе анализа и дизайна, так как средство реализации UML — Rational Rose — позволяет создавать элементы кода на нескольких языках программирования. Методология — объектно-ориентированное программирование; • Test (тестирование) — предполагает тестирование продукта на данной итерации. Стоит специально отметить, что regression testing (возвратное тестирование, тестирование «неухудшения» продукта) в данном случае должно содержать все актуальные тесты от предыдущей итерации и приемосдаточные тесты от предыдущей transition-фазы; • Deployment (внедрение) — предполагает установку продукта на полигоне заказчика, подготовку персонала, запуск системы плюс приемо-сдаточные испытания, подготовка стандартов упаковки и распространения продукта, передача материалов отделу продаж (действия опциональны в зависимости от специфики продукта). Приведенные выше элементы не являются новыми в плане жизненного цикла разработки ПО, поскольку имеют место практически в любой методологии — возможно, за исключением XP (где они, тем не менее, представлены в весьма оригинальном виде). Особенностью реализации RUP являются временные акценты, а именно — на каких итерациях будут доминировать те или иные потоки, а также наличие универсального языка и набора утилит, позволяющего описывать процесс разработки. Как мы видим на рис. 2, на начальных этапах эволюции продукта основное внимание уделяется формализации проекта (анализ, моделирование), что направлено на сокращение коммерческих рисков и снижение стоимости ошибок дизайна. Когда 160 картина более или менее ясна, начинаются собственно разработка, тестирование и, наконец, внедрение продукта. Preliminary interna — это фактически документы, выпускаемые техническим советом для менеджеров предприятия. Основная цель начальных этапов — заключение контракта или соглашения о намерениях. Дальнейшие итерации — собственно начало работы коллектива разработчиков, который имеет время и ресурсы для построения формальных моделей. UML в данном случае имеет средства, позволяющие отображать модель на элементы кода. Например, дерево объектов отображается непосредственно, вариации зависят от мощности реализации выбранного разработчиками языка программирования, а также от совпадения взглядов Г.Буча и разработчиков данного языка на объектную модель. То же самое относится к методам. Рассмотрим элементы, касающиеся поддержки продукта — core supporting workflows: • Configuration management (управление конфигурацией и изменениями) — мощный слой административных действий, направленных на управление версиями продукта, что предполагает контроль исходного кода (модели, исполняемых модулей, тестов, документации), контроль версий продукта, корпоративные стандарты разработки кода и документации, отслеживание изменений и ошибок (bug tracking); тесно связан с тестированием и поддержкой пользователей (customers support); • Management (управление проектом) — предполагает набор административных действий управления проектом согласно идеологии RUP, используются средства управления проектом (см. ниже список продуктов Rational); • Environment (окружение) — предполагает создание и поддержку средств анализа, проектирования, разработки, тестирования (как программное, так и аппаратное обеспечение). В RUP рекомендовано следовать позволяющим успешно разрабатывать проект: • итеративная разработка; • управление требованиями; • использование модульных архитектур; • визуальное моделирование; • проверка качества; шести практикам, 161 • отслеживание изменений. Практики не являются непосредственно частью процесса RUP, но настоятельно рекомендованы к использованию. Часть практик прямо вытекает из идеологии RUP. Так, итеративная разработка заложена в структуру RUP, поскольку этот процесс является одной из реализаций «спирали». Управление требованиями в RUP появляется на самых ранних стадиях анализа. Теоретически модульная архитектура позволяет повторно использовать код, и система получается более гибкой. В силу того что UML является объектным языком, игнорировать модульность можно, но… несколько затруднительно. Визуальное моделирование позволяет эффективно бороться с возрастающей сложностью систем. Кроме того, модели являются средствами коммуникации между разработчиками, но для этого разработчики должны говорить на UML, что предполагает определенный тренинг. Визуальное моделирование часто осуществляется с помощью инструмента Rational Rose, что позволяет получать набор весьма полезных документов для менеджеров, системных администраторов, разработчиков, тестировщиков, а так же генерировать элементы кода. Данное средство не является единственной реализацией UML — доступны как коммерческие альтернативы (например, Microsoft Visio), так и некоммерческие. Следует отметить, что диалекты UML, реализованные в средствах моделирования, не всегда совпадают: диалект Rational имеет некоторые серьезные различия, описанные как в документации, так и в книгах по UML. Продукты, поддерживающие RUP Ниже перечислены самые поддерживающие Rational Unified Process: известные продукты, • Rational Rose — CASE-средство визуального моделирования информационных систем, имеющее возможности генерирования элементов кода. Специальная редакция продукта — Rational Rose RealTime — позволяет на выходе получить исполняемый модуль; • Rational Requisite Pro — средство управления требованиями, позволяющее создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающие на любом этапе разработки компонентов приложения; • Rational ClearQuest — продукт для управления изменениями и отслеживания дефектов в проекте (bug tracking), тесно 162 интегрирующийся со средствами тестирования и управления требованиями и представляющий собой единую среду для связывания всех ошибок и документов между собой; • Rational SoDA — продукт для автоматического генерирования проектной документации, позволяющий установить корпоративный стандарт на внутрифирменные документы. Возможно также приведение документации к уже существующим стандартам (ISO, CMM); • Rational Purify, Rational Quantify Rational PureCoverage, — средства тестирования и отладки: - Rational Purify — весьма мощное средство поиска ошибок на runtime для разработчиков приложений и компонентов, программирующих на C/C++, - Rational Visual Quantify — средство измерения характеристик для разработчиков приложений и компонентов, программирующих на C/C++, Visual Basic и Java; помогает определять и устранять узкие места в производительности ПО, - Rational Visual PureCoverage — автоматически определяет области кода, которые не подвергаются тестированию; • Rational ClearCase — продукт для управления конфигурацией программ (Rational’s Software Configuration Management, SCM), позволяющий производить версионный контроль всех документов проекта. С его помощью можно поддерживать несколько версий проектов одновременно, быстро переключаясь между ними. Rational Requisite Pro поддерживает обновления и отслеживает изменения в требованиях для группы разработчиков; • SQA TeamTest — средство автоматизации тестирования; • Rational TestManager — система управления тестированием, которая объединяет все связанные с тестированием инструментальные средства, артефакты, сценарии и данные; • Rational Robot — инструмент для создания, модификации и автоматического запуска тестов; • SiteLoad, SiteCheck — средства тестирования Web-сайтов на производительность и наличие неработающих ссылок; 163 • Rational PerformanceStudio — измерение характеристик производительности систем. и предсказание Артефакты и роли Неотъемлемую часть RUP составляют артефакты (artefact), прецеденты (precedent) и роли (role). Артефакты — это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом. Прецеденты — это последовательности действий, выполняемых системой для получения наблюдаемого результата. Фактически любой результат работы индивидуума или группы является артефактом, будь то документ анализа, элемент модели, файл кода, тестовый скрипт, описание ошибки и т.п. За создание того или иного вида артефактов отвечают определенные специалисты. Таким образом, RUP четко определяет обязанности каждого члена группы разработки на том или ином этапе, то есть когда и кто должен создать тот или иной артефакт. Весь процесс разработки программной системы рассматривается в RUP как процесс создания артефактов — начиная с первоначальных документов анализа и заканчивая исполняемыми модулями, руководствами пользователя и т.п. Ниже приведен набор артефактов (моделей, документов и т.п.) для каждого из потоков. Business modeling Артефакты-модели — используется Rational Rose: • модель бизнес-процессов — определение бизнес-требований к разрабатываемой системе; • модель структуры предприятия — артефакт для разработки функциональной модели системы; • модели документов, бизнес-сущностей, модели сценариев бизнес-функций, модели состояний бизнес-сущностей — для проектирования пользовательского интерфейса, БД системы; представляют собой описание статического и динамического состояний системы с различных точек зрения; • модели бизнес-правил — артефакт используется моделирования правил в программном обеспечении. для 164 Артефакты-документы — используются RequisitePro, текстовые процессоры, Microsoft Project: • оценка организации заказчика, структура бизнеса; • словарь терминов предметной области; • набор бизнес-правил; • коммерческое предложение; • спецификации бизнес-функций; • план работ на этапе бизнес-моделирования; • рекомендации по проведению бизнес-моделирования; • запросы на изменение. SoDA, Requirements Артефакты-модели — используется Rational Rose: • модель функции системы; • модель сценариев функций системы; • модель интерфейсов пользователя; • модель сценариев работы пользователя системы; • модель выходных форм; • модель правил системы. Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project: • план управления требованиями; • словарь терминов системы; • спецификация на программную систему; • спецификация на функции системы; • правила системы; • запросы заинтересованных лиц; • план работ на этапе определения требований к системе; • рекомендации по моделированию на этапе определения требований; • запросы на изменение. Analysis and design Артефакты-модели — используется Rational Rose: • логическая модель данных; • физическая модель данных; • модель спецификаций компонентов системы; • сценарии взаимодействия классов, реализующих компоненты системы. Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project: • архитектура программного обеспечения; • спецификации программных компонентов; 165 • рекомендации на этапе анализа и проектирования; • план работ на этапе анализа и проектирования; • запросы на изменение. Implementation Артефакты-модели — используется Rational Rose: • компонентная модель приложения. Артефакты-код — используются Rational Rose, средства программирования, текстовые процессоры: • элементы генерации кода, полученные в Rational Rose; • собственно код приложения; • документация. Артефакты-документы — используются RequisitePro, SoDA, текстовые процессоры, MS Project: • план сборки приложения; • план работ на этапе реализации. Test Артефакты-модели — используется Rational Rose: • модель тестовых примеров; • функциональная модель тестовой программы; • модель спецификации компонентов тестовой программы; • сценарии взаимодействия классов, реализующих взаимодействие компонентов тестовой программы. Артефакты-документы процессоры, MS Project: — используются SoDA, текстовые • описание тестовых примеров; • план тестирования; • план работ на этапе тестирования; • запросы на изменение. Реализация тестирования — Quantify, Purify, PureCoverage, Robot, SiteLoad, SiteCheck. Deployment Артефакты-модели — используется Rational Rose: 166 • модель размещения — описание размещения компонентов по узлам обработки. Артефакты-документы процессоры, MS Project: — используются SoDA, текстовые • обучающие материалы; • документы по инсталляции; • описание версий системы; • план внедрения. Введение в UML (http://www.interface.ru/home.asp?artId=3491) Принципы моделирования Использование языка UML основывается на следующих общих принципах моделирования: абстрагирование - в модель следует включать только те элементы проектируемой системы, которые имеют непосредственное отношение к выполнению ей своих функций или своего целевого предназначения. Другие элементы опускаются, чтобы не усложнять процесс анализа и исследования модели; многомодельность - никакая единственная модель не может с достаточной степенью точности описать различные аспекты системы. Допускается описывать систему некоторым числом взаимосвязанных представлений, каждое из которых отражает определенный аспект её поведения или структуры; иерархическое построение - при описании системы используются различные уровни абстрагирования и детализации в рамках фиксированных представлений. При этом первое представление системы описывает её в наиболее общих чертах и является представлением концептуального уровня, а последующие уровни раскрывают различные аспекты системы с возрастающей степенью детализации вплоть до физического уровня. Модель физического уровня в языке UML отражает компонентный состав проектируемой системы с точки зрения ее реализации на аппаратурной и программной платформах конкретных производителей. 167 Сущности в UML В UML определены четыре типа сущностей: структурные, поведенческие, группирующие и аннотационные. Сущности являются основными объектно-ориентированными элементами языка, с помощью которых создаются модели. Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют статические части модели, соответствующие концептуальным или физическим элементам системы. Примерами структурных сущностей являются «класс», «интерфейс», «кооперация», «прецедент», «компонент», «узел», «актер». Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы, которые описывают поведение модели во времени и в пространстве. Существует два основных типа поведенческих сущностей: взаимодействие - это поведение, суть которого заключается в обмене сообщениями между объектами в рамках конкретного контекста для достижения определенной цели; автомат алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят в ответ на различные события. Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Такая первичная сущность имеется в единственном экземпляре - это пакет. Пакеты представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить структурные, поведенческие и другие группирующие сущности. В отличие от компонентов, которые реально существуют во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только в процессе разработки. Аннотационные сущности - это пояснительные части модели UML: комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов - примечание. Примечание используют, чтобы снабдить диаграммы комментариями или ограничениями, выраженными в виде неформального или формального текста. 168 Отношения в UML В языке UML определены следующие типы отношений: зависимость, ассоциация, обобщение и реализация. Эти отношения являются основными связующими конструкциями UML и также как сущности применяются для построения моделей. Зависимость (dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Ассоциация (association) - структурное отношение, описывающее совокупность смысловых или логических связей между объектами. Обобщение (generalization) - это отношение, при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (предка). При этом, в соответствии с принципами объектно-ориентированного программирования, потомок (child) наследует структуру и поведение своего предка (parent). Реализация (realization) является семантическим отношением между классификаторами, при котором один классификатор определяет обязательство, а другой гарантирует его выполнение. Отношение реализации встречаются в двух случаях: между интерфейсами и реализующими их классами или компонентами; между прецедентами и реализующими их кооперациями. Общие механизмы UML Для точного описания системы в UML используются, так называемые, общие механизмы: спецификации (specifications); дополнения (adornments); деления (common divisions); расширения (extensibility mechanisms). UML является не только графическим языком. За каждым графическим элементом его нотации стоит спецификация, содержащая текстовое представление соответствующей конструкции языка. Например, пиктограмме класса соответствует спецификация, 169 которая описывает его атрибуты, операции и поведение, хотя визуально, на диаграмме, пиктограмма часто отражает только малую часть этой информации. Более того, в модели может присутствовать другое представление этого класса, отражающее совершенно иные его аспекты, но, тем не менее, соответствующее спецификации. Таким образом, графическая нотация UML используются для визуализации системы, а с помощью спецификаций описывают ее детали. Практически каждый элемент UML имеет уникальное графическое изображение, которое дает визуальное представление самых важных его характеристик. Нотация сущности «класс» содержит его имя, атрибуты и операции. Спецификация класса может содержать и другие детали, например, видимость атрибутов и операций, комментарии или указание на то, что класс является абстрактным. Многие из этих деталей можно визуализировать в виде графических или текстовых дополнений к стандартному прямоугольнику, который изображает класс. При моделировании объектно-ориентированных систем существует определенное деление представляемых сущностей. Во-первых, существует деление на классы и объекты. Класс это абстракция, а объект - конкретное воплощение этой абстракции. В связи с этим, практически все конструкции языка характеризуются двойственностью «класс/объект». Так, имеются прецеденты и экземпляры прецедентов, компоненты и экземпляры компонентов, узлы и экземпляры узлов. В графическом представлении для объекта принято использовать тот же символ, что и для класса, а название подчеркивать. Во-вторых, существует деление на интерфейс и его реализацию. Интерфейс декларирует обязательства, а реализация представляет конкретное воплощение этих обязательств и обеспечивает точное следование объявленной семантике. В связи с этим, почти все конструкции UML характеризуются двойственностью «интерфейс/реализация». Например, прецеденты реализуются кооперациями, а операции - методами. UML является открытым языком, то есть допускает контролируемые расширения , чтобы отразить особенности моделей предметных областей. Механизмы расширения UML включают: стереотипы (stereotype) - расширяют словарь UML, позволяя на основе существующих элементов языка создавать новые, ориентированные для решения конкретной проблемы; 170 помеченные значения (tagged value) - расширяют свойства основных конструкций UML, позволяя включать дополнительную информацию в спецификацию элемента; ограничения (constraints) - расширяют семантику конструкций UML, позволяя создавать новые и отменять существующие правила. Совместно эти три механизма расширения языка позволяют модифицировать его в соответствии с потребностями проекта или особенностями технологии разработки. Виды диаграмм UML Графические изображения моделей системы в UML называются диаграммами . В терминах языка UML определены следующие их виды: диаграмма вариантов использования или прецедентов (use case diagram) диаграмма классов (class diagram) диаграммы поведения (behavior diagrams) диаграмма состояний (statechart diagram) диаграмма деятельности (activity diagram) диаграммы взаимодействия (interaction diagrams) диаграмма последовательности (sequence diagram) диаграмма кооперации (collaboration diagram) диаграммы реализации (implementation diagrams) диаграмма компонентов (component diagram) даграмма развертывания (deployment diagram) Каждая из этих диаграмм конкретизирует различные представления о модели системы. При этом, диаграмма вариантов использования представляет концептуальную модель системы, которая является исходной для построения всех остальных диаграмм. Диаграмма классов является логической моделью, отражающей статические аспекты структурного построения системы, а диаграммы поведения, также являющиеся разновидностями логической модели, отражают динамические аспекты её функционирования. Диаграммы реализации служат для представления компонентов системы и относятся к ее физической модели. Из перечисленных выше диаграмм некоторые служат для обозначения двух и более подвидов. В качестве же самостоятельных представлений используются следующие диаграммы: вариантов 171 использования, классов, состояний, деятельности, последовательности , кооперации , компонентов и развертывания. Для диаграмм языка UML существуют три типа визуальных обозначений, которые важны с точки зрения заключенной в них информации: связи, которые представляются различными линиями на плоскости; текст, содержащийся внутри границ отдельных геометрических фигур; графические символы, изображаемые вблизи визуальных элементов диаграмм. При графическом изображении диаграмм рекомендуется придерживаться следующих правил: каждая диаграмма должна быть законченным представлением некоторого фрагмента моделируемой предметной области; представленные на диаграмме сущности модели должны быть одного концептуального уровня; вся информация о сущностях должна быть явно представлена на диаграмме; диаграммы не должны содержать противоречивой информации; диаграммы не следует перегружать текстовой информацией; каждая диаграмма должна быть самодостаточной для правильной интерпретации всех ее элементов; количество типов диаграмм, необходимых для описания конкретной системы, не является строго фиксированным и определяется разработчиком; модели системы должны содержать только те элементы, которые определены 172 Приложение 3 Глоссарий Автоматизированное тестирование Является составной частью процесса тестирования. Оно использует специальные приложения для проведения тестов, что помогает не только сократить время тестирования, но и упростить сам процесс. Автономное тестирование Тестирование нижнего уровня, тестирование компонент, модулей, подпрограмм. Чаще всего это внутреннее приёмочное тестирование. Альфа-тестирование Тестирование программного продукта штатными работниками, либо заказчиками на стороне разработчика. Чаще всего это внутреннее приёмочное тестирование. Артефакт Семантически законченная часть информации, которая: формируется, изменяется или используются процессами, определяет область ответственности. Баг Ошибка, проявляющаяся на стадии работы программы. Баги локализуются и устраняются в процессе тестирования и отладки. Бета-тестирование Распространение среди пользователей готовой версии продукта с ограничениями (по функциональности или времени работы), с целью выявление и устранения максимального количество ошибок. Гамма-тестирование Тестирование программы на основе отчетов пользователей. Заглушка Компонент, содержащий функциональность, необходимую при тестировании. Заглушка — это либо полностью "пустышка", либо просто возвращает предопределенное значение или имитирует более сложное поведение. 173 Инсталляционное тестирование Проверка корректной установки системы при различных условиях с программным обеспечением и ресурсами. Проверка работы системы при модернизации со старой версии на новую, так же как и установки с нуля. Интеграционное тестирование Данное тестирование предназначено для проверки правильности работы между модулями системы. Пример: Загружен документ, после премодерации его помещают в файловый архив, а оттуда есть возможность его вывода на предпросмотр. Данное тестирование сделано для проверки того, что документ остается неизменным на каждом этапе или же меняется в соответствии с требованиями. Контроль факта исправления дефектов После тестирования найденные дефекты исправляются разработчиками. Контроль заключается в последующей проверке правильности исправления дефектов. Очень часто после этого требуется провести регрессионное тестирование для исключения факта поломки ранее работающих модулей систему. Конфигурационное тестирование Предназначено для проверки правильности различных программных и аппаратных окружениях. работы на Пример: проверка правильности работы системы под Windows XP и Windows 2000 или же правильность работы сайта в различных браузерах. Миграционное тестирование Данный вид тестирование проверяет, что процедуры и функции, конвертирующие данные для последующего использования в других приложениям, работают правильно. Модульное (unit-) тестирование Тестирование отдельных компонентов, изолируя модули от их реального окружения. Эти тесты служат для проверки правильности работы отдельных модулей системы, как правило – классов. 174 Нагрузочное / стрессовое тестирование Тестирование предназначено для проверки работоспособности системы при нестандартных нагрузках и для определения максимально возможного пика, при котором система работает правильно. Так же предназначено для выявления результатов, при которых система переходит в нерабочее состояние. Пример: Есть некий сайт с посещаемостью 10000 человек в день. Целью тестирования в данном случае будет нахождение кол-ва посетителей, при котором сайт будет "тормозить" и его сервисы будут обрабатывать информацию неправильно или слишком долго. Обработка требований на ошибки Зачастую в требованиях к системе существуют ошибки или двузначные формулировки. Данное тестирование предназначено для исправления этих ошибок и для того, чтобы в процессе тестирования и разработки не возникало дополнительных вопросов, которые можно урегулировать на уровне требований. Отчёт по дефектам Документ, в котором описаны все дефекты, которые были найдены в данной версии продукта. Для таких документов, как правило, ведется версионность для большего понимания результатов изменений и исправлений ранее найденных дефектов. Оценка качества программного продукта Оценка производится для того, чтобы заказчик мог понять, в каком состоянии находится система в данный момент и какие шаги на основании этого можно предпринимать в дальнейшем для её улучшения. Патч Экземпляр ППО, являющийся обновлением, выпущенным для исправления ошибок, обнаруженных в версии или релизе ППО. В состав патча входит исполняемый код и описание исправленных в патче ошибок. Патч может распространяться без документации. Подготовка тестовых данных Зачастую у тестируемой системы есть специфические данные, которые следует подготовить до начала тестирования. Пример: В систему необходимо загружать архивы определённого содержания, картинка определенного размера и т.д. 175 Покрытие кода Покрытие кода, по своей сути, является тестированием «белого ящика». Тестируемое ПО собирается со специальными настройками или библиотеками и/или запускается в особом окружении, в результате чего для каждой используемой (выполняемой) функции программы определяется её местонахождение в исходном коде. Этот процесс позволяет разработчикам и специалистам по обеспечению качества определить части системы, которые, при нормальной работе, используются очень редко или никогда не используются (такие как код обработки ошибок и т.п.). Приемка Действие(-я), в результате которого заказчик принимает в собственность программное обеспечение по окончании (частичном или полном) контракта. Приемосдаточные испытания Проверка эксплуатацию. программы пользователями перед сдачей в Регрессионное тестирование После исправления дефектов часто бывает так, что изменения коснулись системы в целом и на основании этого возникли новые дефекты. Проверка целостности проекта после внесения изменений (регрессионное тестирование) предназначена для того, чтобы протестировать общий функционал окружения, в котором были произведены изменения. Полезно так же на базовом уровне провести регрессионное тестирование всей системы целиком, потому что изменения могли затронуть модули, в которых прежде не было найдено дефектов. Система отслеживания ошибок Прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки (баги), найденные в программах, а также следить за процессом устранения этих ошибок. Системное тестирование Высокоуровневая проверка функционала всей программы. 176 Скрипт Общие условия проведения тестирования (сценарий тестирования) при ручном тестировании, текст программы для выполнения автоматизированных тестов. Смоук-тест (smoke test) Минимальный набор тестов, проверяющий базовую функциональность, при неработоспособности которой дальнейшее тестирование не имеет смысла. Статическое тестирование Тестирование без реального выполнения программы. Тест Выполняемая тестовая процедура с конкретными входными данными, начальными условиями и ожидаемым результатом, разработанными для определенной цели, такой, как проверка отдельной программы или верификация соответствия на определенное требование. Тест-кейс (тест-план) Это документация описывающая шаги тестирования. В широком смысле, тест-план - это полное описание функционала системы с отражением всех требований к ней. Данная документация, как правило, описывает только реальные требования, которые предъявлены к системе. При тестировании данная документация является гарантом того, что система в целом работает правильно. Нетривиальные ошибки (например, ввод некорректных символов в поиск) в разработке документа не учитываются, но выявляются при тестирование программы в целом. Тестирование Процесс позволяющий определить корректность, полноту и качество разработанного программного продукта (сайта или программы). Особо выделяют следующие вид тестирования: - функциональное тестирование - регрессионное тестирование - юзабилити тестирование - конфигурационное тестирование 177 - нагрузочное тестирование - стрессовое тестирование Тестирование "белого ящика" Тестирование на соответствие программного продукта требованиям со знанием внутренней структуры реализации системы (есть в наличии исходный код и технические спецификации). Это вид тестирования позволяет проводить локализацию ошибок, анализ надежности и устойчивости и т.п., существенно повышая качество системы. Тестирование "черного ящика" Тестирование на соответствие программного продукта требованиям без знания внутренней структуры реализации системы. Тестовое покрытие Мера полноты тестирования для определенной стратегии. Степень, до которой с помощью контрольных примеров проверяют требования к системе или программному продукту. Техническое задание Документ, используемый заказчиком в качестве средства для описания и определения задач, выполняемых при реализации договора. Управление дефектами Это базовое понятие тестирования, которое включает в себя документацию по тестированию и необходимые документы для описания найденных дефектов. Функциональное тестирование Функциональное тестирование проверяет, что система работает в точности, как и описано в спецификации (требованиях к системе). Пример: Есть система интернет-магазина, и есть требования к этой системе. Предположим одно из этих требований – возможность работы с системой WebMoney. Функциональное тестирование предназначено для проверки правильности работы системы с платежами. 178 Юзабилити тестирование Юзабилити тестирование предназначено для оценки удобства пользования системой и соответствующих рекомендаций по её улучшению. Пример: Предложение об изменении местоположения кнопок для большего удобства или же предложение об изменении кол-ва полей в форме регистрации и так далее. GUI-тесты Тестирование графического интерфейса — окон, меню, кнопок, списков и т.д. Как правило, через пользовательский интерфейс реализуется большая часть функциональности ПО. Управление качеством Методы и виды деятельности оперативного характера, используемые для выполнения требований к качеству. [ИСО 8402] Система качества Совокупность организационной структуры, методик, процессов и ресурсов, необходимых для осуществления общего руководства качеством. [ИСО 8402] 179 Литература Майерс Г. Искусство тестирования программ М.: Финансы и статистика, 1982. -176 с. Канер Кем, Фолк Джек, Нгуен Енг Кек Тестирование программного обеспечения.— Киев: ДиаСофт, 2001. — 544 с. — ISBN 9667393879 Калбертсон Роберт, Браун Крис, Кобб Гэри Быстрое тестирование. — М.: «Вильямс», 2002. — 374 с. Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем. — СПб.: Питер, 2004. — 320 с. Рекс Блэк. Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование пер. с англ., - М.: Лори, - 544с.: ил., ISBN 5-85582-239-7, ISBN 0-201-74868-1 (англ.) Денис М. Ахен, Арон Клауз, Ричард Тернер. “CMMI:Комплексный подход к совершенствованию процессов. Практическое введение в модель.” Бек Кент Экстремальное программирование: разработка через тестирование : пер. с англ. / Кент Бек . - СПб. : Питер , 2003. 224 с. (Библиотека программиста) Дастин Элфрид Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация : пер. с англ. / Элфрид Дастин ; Джефф Рэшка ; Джон Пол . - М. : Лори , 2003. - 567 с. Луиза Тамре. Введение в тестирование программного обеспечения. - Издательство: Вильямсб Год: 2003 ISBN: 5-8459-0394-7003 г. Элфрид Дастин, Джефф Рэшка, Джон Пол Автоматизированное тестирование программного обеспечения. 2003 г. Barry Boehm, "A Spiral Model of Software Development and Enhancement", IEEE Computer, Vol.21, No.5, pp. 61-72, 1988.) http://www.agilealliance.com/ http://facweb.cti.depaul.edu/jhuang/is553/Royce.pdf 180 http://www.agilerussia.ru/ http://software-testing.ru/ www.computer.org/computer/homepage/misc/Boehm/r5061.pdf http://facweb.cti.depaul.edu/jhuang/is553/Royce.pdf. http://www.intuit.ru/ http://www.sei.cmu.edu/cmmi/ SW-CMM: http://www.sei.cmu.edu/cmm
