2.3 Измерения в конструировании (Construction Measurement)
Большая часть результатов, да и самой деятельности по конструированию программного обеспечения, может быть измерена, в том числе - количественно. Это и исходный разработанный код, и модифицированный объем кода, и степень повторного использования, и многие другие характеристики. Эти измерения, или как их еще принято называть - результаты аудита кода и метрики кода, несут большую пользу как для оценки рисков и качества (приводящих к соответствующим операциям по снижению рисков и повышению качества), а также, для управления конструированием и программными проектами, в целом. О каком планировании может идти речь, если мы не способны предсказать (например, на основе оценки результатов предыдущих проектов) ни длительность работ, ни стоимость отдельных задач, ни вероятность возникновения дефектов против заданных параметров приемлемого качества?
Код является одним из наиболее четко детерминированных активов проекта (постепенно такими становятся и модели, строящиеся на основе структур метаданных, и тесно связанные с кодом - например, UML). Код является и самим носителям требуемой функциональности. Соответственно, применение измерений в отношении кода становится тем инструментом, который влияет и на управление и на сам код.
Последнее время, большое внимание многие профессиональные разработчики, то есть инженеры- конструкторы программного обеспечения, уделяют рефакторинг кода, как методы его реструктурирования, призванные без изменения содержания (то есть функциональности и функциональной целостности) обеспечить решение задач минимизации сложности, готовности к изменениям (гибкости), прозрачности документирования и многих других актуальных аспектов конструирования. Но, к сожалению, многие забывают о необходимости мотивированности изменений, даже на уровне рефакторинга. Применение измерений, в частности, метрик, позволяет определить необходимость внесения таких изменений, проведения рефакторинга. И не потому что “так, наверное, будет всё же лучше, красивше...”, а потому, что в иерархии наследования из 10 поколений классов - 9 являются абстрактными (“из любви к искусству”), а на 10-м (в силу превышений сроков проекта, после того, как долго и “в кайф” создавали архитектурно-красивый код) “повешено” 20 (!) бизнес-методов. Вот это - действительно обоснованная причина для рефакторинга, который, даже с применением самых совершенных инструментальных средств, вместе с обдумыванием необходимости рефакторинга, а потом, иногда, и борьбой с его последствиями из-за несогласованности членов команды (а это уже жизнь, даже в самом идеальном коллективе, где люди понимают друг друга с полуслова) часто является просто тратой времени.
Если применяется рефакторинг, но не применяются метрики - в подавляющем большинстве случаев, это отрицательно влияет на проект. И таких примеров работ, требующих применения измерений, но, к несчастью, игнорирующих их, можно приводить достаточно долго. Вы, наверняка, сами можете рассказать на эту тему много примеров из жизни.
Почему “авторизованный перевод” этой темы SWEBOK оказался столь эмоционален? Практика автора показывает, что в погоне за “красотой”, разработчики слишком часто забывают о цели их работы и воспринимают деятельность по управлению проектами (не буду спорить, иногда лишь формальную, для “прикрытия” всего, что только можно ...) со стороны менеджеров и, тем более, любой аудит - как однозначную помеху “полёту мысли”. Зря. Если все именно так обстоит в вашем случае - проект, с большой вероятностью, а иногда и просто, “если не случится чудо”, можно считать пусть и не провальным (“фуух... не закрыли....”), то, наверняка, выйдущим за рамки тех или иных ограничений, будь то сроки, деньги, качество или, наконец, время, которое разработчик мог провести с семьей. И не сидеть ночью, дописывая функциональность или отлавливая очередную ошибку за несколько дней до передачи проекта в эксплуатацию. Все эти вопросы преследуют одну единственную цель - предсказуемость работ и результата. И измерения - важный инструмент достижения этой цели.
Область знаний “Software Engineering Process” уделяет специальное внимание вопросам измерений при создании программного обеспечения.
Конструирование - деятельность, в рамках которой программное обеспечение приводится к соглашению с произвольными (иногда - хаотическими) ограничениями реального мира, которые требуют от программного обеспечения точного следования им. Приближаясь к ограничениям реального мира, конструирование (в большей степени, чем любая другая область знаний) ведется на основе практических соображений и техник.
3.1 Проектирование в конструировании (Construction Design)
Некоторые проекты предполагают больший объем работ по проектированию именно на стадии конструирования; другие проекты явно выделяют проектную деятельность в форме фазы дизайна. Вне зависимости от четкости выделения деятельности по проектированию, как таковой, практически всегда на стадии конструирования приходится заниматься и вопросами детального дизайна системы. Такие проектные работы имеют стремление к следованию устойчивым ограничениям, навязываемым конкретными проблемами, решение которых должно быть обеспечено использованием конструируемой программной системы.
Детали деятельности по проектированию на стадии конструирования в основном те же самые, что и описанные в области знаний “Проектирование программного обеспечения” (Software Design). Отличие заключается в большем внимании деталям.
3.2 Языки конструирования (Construction Languages)
Языки конструирования включают все формы коммуникаций, с помощью которых человек может задать решение проблемы, выполняемое на компьютере.
Простейший тип языков конструирования - конфигурационный язык (configuration language), позволяющий задавать параметры выполнения программной системы.
Инструментальный язык (toolkit language) - язык конструирования из повторно-используемых элементов; обычно строится как сценарный язык (script), выполняемый в соответствующей среде.
Язык программирования (programming language) - наиболее гибкий тип языков конструирования. Содержит минимальный объем информации о конкретных областях приложения и процессе разработки, требуя больше всего (по сравнению с другими типами языков конструирования) усилий на изучение и наработку опыта для эффективного применения при решении конкретных задач.
Существует три основных вида нотаций используемых при определении языков программирования:
• лингвистическая
• формальная
• визуальная
Лингвистические нотации характеризуются, в частности, использованием строк текста, содержащих специализированные “слова”, представляющие сложные программные конструкции, и комбинируемые в шаблоны, напоминающие предложения, построенные в соответствии с определенным синтаксисом. В случае корректного использования таких нотаций, каждая получаемая строка обладает строгой смысловой нагрузкой (семантикой), обеспечивающей интуитивное понимание того, что будет происходить когда будет выполняться программное обеспечение, построенное с использованием такого языка конструирования.
Формальные нотации являются менее интуитивными, чем лингвистические, и часто базируются на точных формальных (математических) определениях. Формальные нотации конструкций и формальные методы являются ядром практически всех форм системного программирования, точнее
- поведения систем во времени. Такие нотации обеспечивают наибольшую готовность получаемого кода к тестированию, что намного важнее, чем просто возможность отображения на обычный человеческий язык. Формальные конструкции также используют точный метод определения комбинаций применяемых символов, что позволяет избежать неоднозначностей, присущих конструкциям естественных языков.
Визуальные нотации наименее связаны с текстово-ориентированными подходами, предполагая непосредственную интерпретацию визуальных конструкций в процессе исполнения описываемой логики. При этом логика в визуальных нотациях задается расположением соответствующих визуальных сущностей, ответственных за те или иные операции и структуры данных.
Использование визуальных конструкций ограничено сложностью визуального представления сложных выражений и утверждений только за счет перемещения визуальных сущностей на диаграмме (визуальном представлении). Однако, визуальная нотация может играть роль достаточно мощного инструмента, когда применяется в тех задачах программирования, где необходимо построение пользовательского интерфейса для программ, чья логика. Детализированное поведение определено ранее.
Сегодняшние работы (и их состояние) в области архитектур и приложений, управляемых моделями, в первую очередь - OMG MDA (Model-Driven Architecture www.omg.org/mda)/UML (Unified Modeling Language www.omg.org/uml), Microsoft DSL (Domain-Specific Language), направлены на то, чтобы использовать ту или иную визуальную нотацию, базирующуюся на мета-моделях, в качестве инструмента, применяемого и для определения функциональной логики системы. Можно ли в чистом виде считать эти нотации именно визуальными - вопрос спорный. Но в терминах, предлагаемых SWEBOK, они относятся именно к визуальным нотациям, так как предполагают однозначную интерпретацию визуального представления в виде текста и наоборот. Кроме того, исторически эти нотации определялись изначально как нотации визуального представления функциональности и уже в дальнейшем эти визуальные представления были отражены на цровне соответствующих метамоделей (хотя это в большей степени верно для UML, чем DSL, но DSL можно рассматривать и как аналог UML, предполагающий бОльшую свободу применений и интегрированность с конкретной платформой - Microsoft). Другая область стандартов, направленных на применение визуальных нотаций для описания функциональности - Business Process Management Notation (BPMN - www.omg.org/bpmn) и связанный с ней язык Business Process Execution Language, построенный на
базе XML. Таким образом, область обоснованного применения визуальных нотаций для конструирования программных систем качественно расшириться и, не исключено, мы станем свидетелями de-facto формирования новой категории нотаций, соглашений и смешанных типов языковых средств, предназначенных для конструирования программного обеспечения как естественного продолжения проектирования.
3.3 Кодирование (Coding)
Практика конструирования программного обеспечения показывает активное применение следующих соображений и техник:
• техники создания легко понимаемого исходного кода на основе использования соглашений об именовании, форматирования и структурирования кода;
• использование классов, перечисляемых типов, переменных, именованных констант и других выразительных сущностей;
• организация исходного текста (в выражения, шаблоны, классы, пакеты/модули и другие структуры)
• использование структур управления;
• обработка ошибочных условий и исключительных ситуаций
• предотвращение возможных брешей в безопасности (например, переполнение буфера или выход за пределы индекса в массиве)
• использование ресурсов на основе применения механизмов исключения (из рассмотрения) и порядка доступа к параллельно используемым ресурсам (например, на основе блокировки данных, использования потоков и их синхронизации и т.п.)
• документирование кода
• тонкая “настройка” кода
• рефакторинг (не упоминается SWEBOK)
3.4 Тестирование в конструировании (Construction Testing)
При конструировании используются две формы тестирования, проводимого инженерами, непосредственно создающими исходный код:
Главная цель тестирования в конструировании уменьшить временной разрыв между моментом проявления ошибок, имеющихся в коде, и моментом их обнаружения. Во многих случаях, тестирование в конструировании производится после того, как код написан. В ряде случаев, тесты (что отмечалось ранее, на примере XP) пишутся до того, как создается код.
Тестировании в конструировании обычно включает подмножество видов тестирования, описанных в области знаний “Тестирование программного обеспечения” (Software Testing). Например, тестирование в конструировании обычно не включает системного тестирования, нагрузочного тестирования, usability-тестирования (оценки прозрачности использования) и других видов тестовой деятельности.
IEEE опубликовал два стандарта, посвященных данной теме:
• IEEE Std 829-1998: “IEEE Standard for Software Test Documentation”
• IEEE Std 1008-1987: “IEEE Standard for Software Unit Testing”
Напрямую с данной темой связаны под-темы SWEBOK 2.1.1 “Unit Testing” и 2.1.2 “Integration Testing”.
3.5 Повторное использование (Reuse)
Во введении в стандарт IEEE Std. 1517-99 “IEEE Standard for Information Technology - Software Lifecycle Process - Reuse Processes” даётся следующее понимание повторному использованию в программном обеспечении: “Реализация повторного использования программного обеспечения подразумевает и влечёт за собой нечто большее, чем просто создание и использование библиотек активов. Оно требует формализации практики повторного использования на основе интеграции процессов и деятельности по повторному использованию в сам жизненный цикл программного обеспечения.” В то же время, повторное использование достаточно важно и непосредственно при
конструировании программных систем, что подчеркивается включением этой темы в обсуждаемую область знаний конструирования ПО.
Задачи, связанные с повторным использованием в процессе конструирования и тестирования, включают:
• выбор единиц (units), баз данных тестовых процедур, данных <полученных в результате> тестов и самих тестов, подлежащих повторному использованию
• оценку потенциала повторного использования кода и тестов
• отслеживание информации и создание отчетности по повторному использованию в новом
коде, тестовых процедурах и данных, полученных в результате тестов.
3.6 Качество конструирования (Construction Quality)
Существует ряд техник, предназначенных для обеспечения качества кода, выполняемых по мере его конструирования. Основные техники обеспечения качества, используемые в процессе конструирования, включают:
• модульное (unit) и интеграционное (integration) тестирование
• разработка с первичностью тестов (test-first development - тесты пишутся до конструирования
кода)
• пошаговое кодирование (деятельность по конструированию кода разбивается на мелкие шаги, только после тестирования результатов которых производится переход к следующему шагу кодирования; известен также как итеративное кодирование с тестированием)
• использование процедур утверждений (assertion)
• отладка (в привычном понимании - debugging)
• технические обзоры и оценки (review)
• статический анализ
Выбор и использование конкретных техник часто диктуется стандартами (внутренними и внешними), используемыми проектной командой, а также зависят от опыта и подготовленности специалистов, занимающихся конструированием кода.
Деятельность по обеспечению качества в конструировании отличается от других операций по обеспечению качества. Основное отличие заключается в фокусе на программном (исходном) коде и других артефактах (активах), тесно связанных с кодом, в частности, детальных моделях.
3.7 Интеграция (Integration)
Одна из ключевых деятельностей, осуществляемых в процессе конструирования, - интеграция отдельно сконструированных операций (процедур), классов, компонентов и подсистем (модулей). В дополнение к этому, некоторые программные системы нуждаются в специальной интеграции с другим программным и аппаратным обеспечением.
Кроме упомянутых аспектов интеграции, к обсуждаемым интеграционным вопросам конструирования относятся:
• планирование последовательности, в которой интегрируются компоненты;
• обеспечение поддержки создания промежуточных версий программного обеспечения;
• задание “глубины” тестирования (в частности, на основе критериев “приемлемого” качества) и других работ по обеспечению качества интегрируемых в дальнейшем компонент;
• наконец, определение этапных точек проекта, когда будут тестироваться промежуточные версии конструируемой программной системы.
Лекция 5. Программная инженерия
Тестирование программного обеспечения (Software Testing)
Лекция базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK®, 2004. Содержит перевод описания области знаний SWEBOK® “Software Testing”, с комментариями и замечаниями.
"Основы программной инженерии" разработаны на базе IEEE Guide to SWEBOK® 2004 в соответствии с IEEE SWEBOK 2004 Oopyright and Reprint Permissions: "This document may be copied, in whole or in part, in any form or by any means, as is, or with alterations provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy."
.
Программная инженерия
Тестирование программного обеспечения (Software Testing)
5.2 Тестовые работы (Test Activities)......................................................................................... 15
Тестирование (software testing) - деятельность, выполняемая для оценки и улучшения качества программного обеспечения. Эта деятельность, в общем случае, базируется на обнаружении дефектов и проблем в программных системах.
Тестирование программных систем состоит из динамической верификации поведения программ на конечном (ограниченном) наборе тестов (set of test cases), выбранных соответствующим образом из обычно выполняемых действий прикладной области и обеспечивающих проверку соответствия ожидаемому поведению системы.
В данном определении тестирования выделены слова, определяющие основные вопросы, которым адресуется данная область знаний:
• Динамичность (dynamic): этот термин подразумевает тестирование всегда предполагает выполнение тестируемой программы с заданными входными данными. При этом, величины, задаваемые на вход тестируемому программному обеспечению, не всегда достаточны для определения теста. Сложность и недетерминированность систем приводит к тому, что система может по разному реагировать на одни и те же входные параметры, в зависимости от состояния системы. В данной области знаний термин “вход” (input) будет использоваться в рамках соглашения о том, что вход может также специфицировать состояние системы, в тех случаях, когда это необходимо. Кроме динамических техник проверки качества, то есть тестирования, существуют также и статические техники, рассматриваемые в области знаний “Software Quality”.
• Конечность (ограниченность, finite): даже для простых программ теоретически возможно столь большое количество тестовых сценариев, что исчерпывающее тестирование может занять многие месяцы и даже годы. Именно поэтому, с практической точки зрения, всестороннее тестирование считается бесконечным. Тестирование всегда предполагает
компромисс между ограниченными ресурсами и заданными сроками, с одной стороны, и практически неограниченными требованиями по тестированию, с другой. То есть мы снова говорим об определении характеристик “приемлемого” качества, на основе которых планируем необходимы объем тестирования.
• Выбор (selection)', многие предлагаемые техники тестирования отличаются друг от друга в том, как выбираются сценарии тестирования. Инженеры по программному обеспечению должны обладать представлением о том, что различные критерии выбора тестов могут давать разные результаты, с точки зрения эффективности тестирования. Определение подходящего набора тестов для заданных условий является очень сложной проблемой. Обычно, для выбора соответствующих тестов совместно применяют техники анализа рисков, анализ требований и соответствующую экспертизу в области тестирования и заданной прикладной области.
• Ожидаемое поведение (expected behaviour). Хотя это не всегда легко, все же необходимо решить, какое наблюдаемое поведение программы будет приемлемо, а какое - нет. В противном случае, усилия по тестированию - бесполезны. Наблюдаемое поведение может рассматриваться в контексте пользовательских ожиданий (подразумевая “тестирования для проверки” - testing for validation), спецификации (“тестирование для аттестации” - testing for verification) или, наконец, в контексте предсказанного поведения на основе неявных требований или обоснованных ожиданий. См. тему SWEBOK 6.4 “Приемочные тесты” области знаний “Software Requirements”.
Общий взгляд на тестирование программного обеспечения последние годы активно эволюционировал, становясь все более конструктивным, прагматичным и приближенным к реалиям современных проектов разработки программных систем. Тестирование более не рассматривается как деятельность, начинающаяся только после завершения фазы конструирования. Сегодня тестирование рассматривается как деятельность, которую необходимо проводить на протяжении всего процесса разработки и сопровождения и является важной частью конструирования программных продуктов. Действительно, планирование тестирования должно начинаться на ранних стадиях работы с требованиями, необходимо систематически и постоянно развивать и уточнять планы тестов и соответствующие процедуры тестирования. Даже сами по себе сценарии тестирования оказываются очень полезными для тех, кто занимается проектированием, позволяя выделять те аспекты требований, которые могут неоднозначно интерпретироваться или даже быть противоречивыми.
Не секрет, что легче предотвратить проблему, чем бороться с ее последствиями. Тестирование, наравне с управлением рисками, является тем инструментом, который позволяет действовать именно в таком ключе. Причем действовать достаточно эффективно. С другой стороны, необходимо осознавать, что даже если приемочные тесты показали положительные результаты, это совсем не означает, что полученный продукт не содержит ошибок. Этим вопросам, в частности, адресована область знаний “Сопровождение программного обеспечения” (Software Maintenance). Однако, адекватное внимание вопросам тестирования качественно снижает риск возникновения ошибок на этапе эксплуатации, обеспечивая более высокую удовлетворенность пользователей, что и является, по существу, целью любого проекта.
В области знаний “Качество программного обеспечения” (Software Quality) техники управления качеством четко разделены на статические (без выполнения кода) и динамические (с выполнением кода). Обе эти категории важны. Данная область знаний - “Тестирование” - касается динамических техник.
Как уже отмечалось ранее, тестирование тесно связано с областью знаний “Конструирование” (Software Construction). Более того, модульное (unit-) и интеграционное тестирование все чаще рассматривают как неотъемлемый элемент деятельности по конструированию.
Техники, базирующиеся на условиях у использования
Техники, базирующиеся на природе у приложения
(---------------------------
Выбор и комбинация — различных техник ^ .......................... ■/
Рисунок 5. Область знаний “Тестирование программного обеспечения” [SWEBOK, 2004, с.5-2, рис. 1]
1. Основы тестирования (Software Testing Fundamentals)
Охватывает основные понятия в области тестирования, базовые термины, ключевые проблемы и их связь другими областями деятельности и знаний.
1.1.1 Определение тестирования и связанной терминологии достаточно полно даётся в “Глоссарии терминов по программной инженерии” - IEEE Standard 610-90 (Standard Glossary of Software Engineering Terminology).
1.1.2 Недостатки и сбои (Faults vs. Failures)
В литературе, посвященной программной инженерии, встречается множество терминов, описывающих нарушение функционирования программных систем - недостатки (faults), дефекты (defects), сбои (failures), ошибки (errors) и др. Соответствующая терминология, как было указано выше в 1.1.1, описана в IEEE Std. 610-90 также обсуждается в области знаний SWEBOK “Качество программного обеспечения” (Software Quality). Важно чётко разделять причину нарушения работы прикладных систем, обычно описываемую терминами недостаток или дефект, и наблюдаемый нежелательный эффект, вызываемый этими причинами - сбой. Термин ошибка, в зависимости от контекста, может описывать и как причину сбоя, и сам сбой. Тестирование позволяет обнаружить дефекты, приводящие к сбоям.
Необходимо понимать, что причина сбоя не всегда может быть однозначно определена. Не существует теоретических критериев, позволяющих гарантированно определить какой именно дефект приводит к наблюдаемому сбою.
1.2 Ключевые вопросы (Key Issues)
1.2.1 Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования (Test selection criteria/test adequacy criteria, or stopping rules)
Критерии отбора тестов могут использоваться как для создания набора тестов, так и для проверки, насколько выбранные тесты адекватны решаемым задачам (тестирования). При этом, обсуждаемые критерии помогают определить, когда можно или необходимо прекратить тестирование.
1.2.2 Эффективность тестирования/Цели тестирования (Test effectiveness/Objectives for testing)
Тестирование - это наблюдение за выполнением программы, запущенной в целях тестирования с заданными параметрами, по заданному сценарию или с другими заданными начальными условиями или целями тестирования. Эффективность теста может быть определена только в контексте заданных условий.
1.2.3 Тестирование для идентификации дефектов (Testing for defect identification)
Данный случай тестирования подразумевает успешность процедуры тестирования, если дефект найден. Это отличается от подхода в тестировании, когда тесты запускаются для демонстрации того, что программное обеспечение удовлетворяет предъявляемым требованиями и, соответственно, тест считается успешным, если не найдено дефектов.
1.2.4 Проблема оракула (The oracle problem)
“Оракул”, в данном контексте, любой агент (человек или программа), оценивающий поведение программы, формулируя вердикт - тест пройден (“pass”) или нет (“fail”).
1.2.5 Теоретические и практические ограничения тестирования (Theoretical and practical limitation of testing)
Теория тестирования выступает против необоснованного уровня доверия к серии успешно пройденных тестов. К сожалению, большинство установленных результатов теории тестирования - негативны, означая, по словам Дейкстры (Dijkstra), то, что “тестирование программы может использоваться для демонстрации наличия дефектов, но никогда не покажет их отсутствие”. Основная причина этого в том, что полное (всеобъемлющее) тестирование недостижимо для реального программного обеспечения.
Техники, базирующиеся на условиях у использования