Основы Программной Инженерии (по swebok) Введение Программная инженерия как дисциплина swebok руководство
 Скачать 3.21 Mb.
|
|
Процесс тестирования (Test Process) Концепции, стратегии, техники и измерения тестирования должны быть объеденены в единый процесс тестирования как деятельности по обеспечению качества. Процесс тестирования поддерживает работы по тестированию и определяет “правила игры” для членов команды тестирования – от планирования тестов до оценки их результатов. Хотя, в большинстве современных методов разработки, в частности, гибких (agile) подходов, тестирование выходит на передний план и является одной из базовых практик, многостороннее тестирование и, тем более, прогнозирование на основе полученных результатов, часто подменяется отдельными работами в этой области, не позволяющими добиться необходимых параметров качества (что, кстати, ясно показывают уже упоминавшиеся результаты исследований Standish Group [Chaos, 2004]). Только в том случае, если тестирование рассматривать как один из важных процессов всей деятельности по созданию и поддержке программного обеспечения, можно добиться оценки стоимости соответствующих работ и, в конце концов, соблюсти те ограничения, которые определены для проекта. Практические соображения (Practical considerations) Программирование без персоналий (Attitudes/Egoless programming) Очень важным компонентом успешного тестирования является совместное стремление участников проекта обеспечить необходимое качество продукта. Менеджеры играют ключевую роль в организации этой деятельности и на стадии разработки и в процессе сопровождения программных систем. Руководства по тестированию (Test guides) Работы по тестированию могут руководствоваться различными соображениями и критериями – от управления рисками до специфицированных сценариев работы программных систем. В любом случае, желательно, исходя из ресурсов, количественных оценок и других характеристик, обеспечить использование различных техник тестирования для многосторонней оценки и улучшения качества получаемого продукта. Управление процессом тестирования (Test process management) Работы по тестированию, ведущиеся на разных уровнях (см. выше 2. “Уровни тестирования”), должны быть организованы в единый (однозначно интерпретируемый) процесс, на основе учета 4 элементов и связанных с ними факторов: людей (в том числе, в контексте организационной структуры и культуры), инструментов, регламентов и количественных оценок (измерений). Стандарт жизненного цикла IEEE, ISO/IEC, ГОСТ Р 12207 не выделяет деятельность по тестированию в качестве самостоятельного процесса, однако, рассматривает соответствующие принципы работ по тестированию как неотъемлемую часть процессов жизненного цикла и сопровождения программных систем. В другом распространенном стандарте IEEE 1074 деятельность по тестированию также объединена с другими оценочными работами как интегральная часть полного жизненного цикла. Документирование тестов и рабочего продукта (Test documentation and work products) Документация – составная часть формализации процесса тестирования. Существует стандарт IEEE 829- 98 “Standard for Software Test Documentation”, предоставляющий прекрасное описание тестовых документов, их связей между собой и с процессом тестирования. Среди таких документов могут быть: План тестирования Спецификация процедуры тестирования Спецификация тестов Лог тестов и др. Документирование тестов, в случае его формального ведения, должно быть актуальным. В противном случае, как и любые другие документы, документация по тестированию ляжет “мертвым грузом”. В то же время, деятельность по тестированию, в случае отсутствия соответствующих регламентов и результатов (в том числе, исторических, для разных проектов), сложно поддается оценке для прогнозирования и, тем более, улучшению - в общем контексте улучшения процессов. Если компания-разработчик не ведет соответствующей документации по тестированию, говорить о сертификации или оценке по тем или иным моделям или стандартам (CMMI, ISO, SixSigma и т.п.) – просто не представляется возможным. А это уже вопрос доверия заказчиков, не имевших опыта работы с конкретной компанией-разработчиком. Внутренние и независимые команды тестирования (Internal vs. independent test team) Формализация процесса тестирования может включать и организационную формализацию команд(ы) тестирования. В нее могу входить как члены проектной команды, в частности, разрабатывающие код, так и внешние лица и группы. В идеале – желательно иметь как внутреннюю команду тестирования, так и внешнюю группу тестирования (обеспечения качества). Соответствующие организационные решения принимаются на основе стоимостных характеристик проекта, доступных ресурсов, анализа стоимости тестирования, как такового, организационной культуры и т.п. Оценка стоимости и усилий, а также другие измерения процесса (Cost/effort estimation and other process measures) Ряд метрик, связанных с оценкой ресурсов, необходимых для тестирования, как и оценка эффективности тестирования на разных этапах и уровнях, основывается на точке зрения и практиках менеджмента проекта (подразделения, компании…) и используется для оценки и улучшения (оптимизации) процесса тестирования. Разные техники, концепции и модели тестирования требуют разных затрат – по времени и необходимым ресурсам. Результат – стоимость тестирования, как затратная составляющая проекта. Понимание соответствия между стоимостью/ усилиями, необходимыми для той или иной формы тестирования является обязательной частью современного управления проектами разработки программного обеспечения. Окончание тестирования (Termination) Очень важным аспектом тестирования является решение о том, в каком объеме тестирование достаточно и когда необходимо завершить процесс тестирования. Тщательные измерения, такие как достигнутое покрытие кода тестами или охват функциональности, безусловно, очень полезны. Однако, сами по себе они не могут определить критериев достаточности тестирования. Приятие решения об окончании тестирования также включает рассмотрение стоимости и рисков, связанных с потенциальными сбоями и нарушениями надёжности функционирования тестируемой программной системы. В то же время, стоимость самого тестирования также является одним из ограничений, на основе которых принимается решение о продолжении тех или иных связанных с проектом работ (с частности, тестирования) или об их прекращении. Cм. также 1.2.1 “Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования”. Повторное использование и шаблоны тестов (Test reuse and test patterns) Доведение тестов до конца и обеспечение сопровождения программной системы необходимо каждый фрагмент системы тестировать систематическим образом, повторно используя наработанные тесты. Общий репозиторий тестовых активов должен находиться под контролем системы конфигурационного управления, с тем, чтобы любые изменения в требованиях или дизайне могли быть отражены в используемых наборах тестов, в том числе, с точки зрения их расширения новыми тестами, если этого требуют соответствующие изменения. Шаблоны тестов конструируются на основе тестовых решений, наработанных для проверки определенных ситуаций или типовых фрагментов программных систем. Такие шаблоны должны быть документированы с учетом повторного использования, включая прозрачные возможности их адаптации под специфику программных решений, к которым такие шаблоны применяются. Тестовые работы (Test Activities) Данная тема дает краткий обзор работ по тестированию. При этом подразумевается, что успешное управление тестовыми работами сильно зависит от процессов конфигурационного управления (Software Configuration Management), рассматриваемых позднее как самостоятельная область знаний. Планирование (Planning) Также как и другие аспекты управления проектами, работы по тестированию должно планироваться заранее. Как минимум, на уровне организации соответствующего процесса. Ключевые аспекты планирования тестовой деятельности включают: координацию персонала управление оборудованием и другими средствами, необходимыми для организации тестирования планирование обработки нежелательных результатов (т.е. является управлением определенными видами рисков) В случае одновременной поддержки и сопровождения нескольких версий программной системы или нескольких систем, необходимо уделять особое внимание планированию времени, усилий и ресурсов, связанных с проведением работ по тестированию. Данная позиция перекликается с вопросами управления портфелями проектов с точки зрения общего управления проектами. Генерация сценариев тестирования (Test-case generation) Создание тестовых сценариев основывается на уровне и конкретных техниках тестирования. Тесты должны находиться под управлением системы конфигурационного управления и описывать ожидаемые результаты тестирования. Разработка тестового окружения (Test environment development) Используемое для тестирования окружение должно быть совместимо с инструментами программной инженерии (будут рассматриваться позднее как тема самостоятельной области знаний). Это окружение должно обеспечивать разработку и контроль тестовых сценариев, ведение журнала тестирования, и возможности восстановления ожидаемых и отслеживаемых результатов тестирования, самих сценариев, а также других активов тестирования. Выполнение тестов (Execution) Выполнение тестов должно содержать основные принципы ведения научного эксперимента: должны фиксироваться все работы и результаты процесса тестирования форма журналирования таких работ и их результатов должна быть такой, чтобы соответствующее содержание было понятно, однозначно интрепретируемой и повторяемо другими лицами (не теми, кто первоначально проводил тестирование) тестирование должно проводиться в соответствии с заданными и документированными процедурами тестирование должно производиться над однозначно идентифицируемой версией и конфигурацией программной системы Ряд вопросов выполнения тестов и других работ по тестированию освещен в стандарте IEEE 1008-87. Анализ результатов тестирования (Test results evaluation) Для определения успешности тестов их результаты должны оцениваться, анализироваться. В большинстве случаев, “успешность” тестирования подразумевает, что тестируемое программное обеспечение функционирует так, как ожидалось и в процессе работы не приводит к непредусмотренным последствиям. Не все такие последствия обязательно являются сбоями, они могут восприниматься как “помехи”. Однако, любое непредусмотренное поведение может стать источником сбоев при изменении конфигурации или условий функционирования системы, поэтому требуют внимания, как минимум, с точки зрения идентификации причин таких помех. Перед устранением обнаруженного сбоя, необходимо определить и зафиксировать те усилия, которые необходимы для анализа проблемы, отладки и устранения. Это позволит в дельнейшем обеспечить большую глубину измерений, а, соответственно, в перспективе, иметь возможность улучшения самого процесса тестирования. В тех случаях, когда результаты тестирования особенно важны, например, в силу критичности обнаруженного сбоя, может быть сформирована специальная группа анализа (review board). Отчёты о проблемах/журнал тестирования (Problem reporting/Test log) Во многих случаях, в процессе тестовой деятельности ведётся журнал тестирования, фиксирующий информацию о соответствующих работах: когда проводится тест, какой тест, кем проводится, для какой конфигурации программной системы (в терминах параметров и в терминах идентифицируемой версии контекста конфигурационного управления) и т.п. Неожиданные или некорректные результаты тестов могут записываться в специальной подсистеме ведения отчетности по сбоям (problem-reporting system, обеспечивая формирование базы данных, используемой для отладки, устранения проблем и дальнейшего тестирования. Кроме того, аномалии (помехи), которые нельзя идентифицировать как сбои, также могут фиксироваться в журнале и/или системе ведения отчетности по сбоям. В любом случае, документирование таких аномалий снижает риски процесса тестирования и помогает решать вопросы повышения надежности самой тестируемой системы. Отчёты по тестам могут являться входом для процесса управления изменениями и генерации запросов на изменения (change request) в рамках процессов конфигурационного управления (см. далее соответствующую область знаний “Software Configuration Management”). Отслеживание дефектов (Defect tracking) Сбои, обнаруженные в процессе тестирования, чаще всего порождаются дефектами и ошибками, присутствующими в тестируемой программной системе (также они могут быть следствием поведения операционного и/или тестового окружения). Такие дефекты могут (и, чаще всего, должны) анализироваться для определения момента и места первого появления данного дефекта в системе, какие типы ошибок стали причиной этих дефектов (например, плохо сформулированные требования, некорректный дизайн, утечки памяти и т.д.) и когда они могли бы быть обнаружены впервые. Вся эта информация используется для определения того, как может быть улучшен сам процесс тестирования и насколько критична необходимость таких улучшений. Сопровождение программного обеспечения Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK. Содержит перевод описания области знаний SWEBOK “Software Maintenance”, с замечаниями и комментариями. Сопровождение программного обеспечения (Software Maintenance) Результат усилий по разработке программного обеспечения состоит в передачи в эксплуатацию программного продукта, удовлетворяющего требованиям пользователей. Соответственно, в процессе эксплуатации продукт будет изменяться или эволюционировать. Связано это с обнаружением при реальном использовании скрытых дефектов, изменениями в операционном окружении, необходимостью покрытия новых требований и т.п. Фаза сопровождения в жизненном цикле, обычно, начинается сразу после приемки/передачи продукта и действует в течение периода гарантии или, чаще, технической поддержки. Однако, сама деятельность, связанная с сопровождением, начинается намного раньше. Сопровождение программного обеспечения является составной частью жизненного цикла. К сожалению, так сложилось, что вопросам сопровождения уделяется существенно меньше внимания, чем другим фазам жизненного цикла. Исторически, в большинстве организаций, разработка программных систем явно в фаворе, по сравнению с деятельностью по сопровождению. Однако, такая ситуация постепенно начинает меняться (достаточно, хотя бы взглянуть на частоту упоминаний ITIL 1 – IT Infrastructure Library, уделяющей особое внимание вопросам поддержки и сопровождения инфраструктуры информационных технологий). В большой степени, как отмечает SWEBOK, это связано с сокращением инвестиций организаций непосредственно в разработку программных систем, с целью увеличения сроков использования уже существующего и применяемого ПО. Конечно, с точки зрения автора, это не единственная причина. Скорее вопросы постоянно изменяющихся бизнес-потребностей, динамика бизнеса и желание повысить отдачу от уже эксплуатируемых систем приводит к усилению роли поддержки и сопровождения программного обеспечения и естественной интеграции такой деятельности в бизнес-процессы подразделений информационных технологий. ITIL, в частности, определяет три аспекта управления жизненным циклом приложений – определение требований, проектирование и разработку, и, наконец, сопровождение. Все это, в контексте программного обеспечения, относится к деятельности по управлению приложениями – Application Management в ITIL ICT Infrastructure Management (ICT - Information and Communications Technology). Если проблема 2000 года, в свое время, оказала особое влияние на изменение отношения к сопровождению на Западе, то расширение применения продуктов Open Source во всем мире и связанная с ним волна надежд на получение дешевого решения существующих задач привела к тому, что вопросы сопровождения вышли для многих организаций на первый план. Ситуация во многих ИТ-подразделениях показывает, что такие надежды оправдались только частично. Использование продуктов Open Source не стало дешевой альтернативой и, в ряде случаев, привело даже к бОльшим проектным затратам именно в силу недостаточно проработанной политики эксплуатации и сопровождения построенных на их основе прикладных решений. Это ни в коем случае не значит, что волна Open Source “захлебнулась”. Это означает только, что игнорирование оценки стоимости сопровождения привело к превышению бюджетов, недостатку ресурсов и, в конце концов, частому провалу инициатив по использованию таких продуктов в корпоративной среде. Неготовность рассматривать жизненный цикл во времени как продолжающийся и после передачи системы в эксплуатацию, непроработанность соответствующих процедур корректировки продукта после его выпуска – основная беда и в бизнесе-среде, для которой программное обеспечение лишь инструмент, и в компаниях-интеграторах, “забывающих” о необходимости развития успеха после внедрения системы у заказчика, и у независимых поставщиков программных продуктов, которые, выпуская новую версию лучшего в своем классе продукта, начинают работать над новой версией, уделяя недостаточное внимание поддержке и обновлению уже существующих версий. Сопровождение программного обеспечения в SWEBOK определяется как вся совокупность деятельности, необходимой для обеспечения эффективной (с точки зрения затрат) поддержки программных систем. Эти работы выполняются как перед вводом системы в эксплуатацию, так и после этого. Предварительные работы включают планирование деятельности по сопровождению системы, а также организацию перехода к ее полнофункциональному использованию. Если новая система должна заменить старую систему, предназначенную для решения тех же задач, просто на новом уровне эффективности, стоимости использования, новых функциональных возможностей, в этом случае важно обеспечить плавный переход со старой системы на новую, максимально естественный для пользователей. С этим связано не только планирование, например, переноса информации, хранимой в соответствующих базах данных, но и обучение пользователей, подготовка, настройка и проверка “боевой” конфигурации, определение последовательности операций, организация и обучение службы поддержки (help-desk) и т.п. Область знаний “Сопровождение программного обеспечения” связана с другими аспектами программной инженерии. По-сути, описание этой области знаний непосредственно пересекается со всеми другими дисциплинами. Рисунок 6. Область знаний “Сопровождение программного обеспечения” [SWEBOK, 2004, с.6-2, рис. 1] |