Пульт управления тестированием ABAP в SAP NetWeaver (SAP NetWeaver ABAP Test Cockpit — ATC) используется для проверки качества ABAP-объектов в нескольких областях и присвоения приоритетов различным категориям таких проверок в зависимости от их важности. Эти проверки можно настраивать и переносить. Функциональность ATC доступна в SAP NetWeaver начиная с пакета расширения 2 для версии SAP NetWeaver 7.0 с пакетом поддержки 12.
С течением времени количество пользовательских ABAP-программ становится все больше. Качество этих программ, безусловно, не может быть одинаковым. Пульт управления тестированием ABAP (ATC) в SAP NetWeaver — бесплатный автоматический инструмент, с помощью которого можно выявить проблемы с качеством и затем устранить их. Надежность ABAP-программ является важным условием их эффективного выполнения в продуктивной среде.
В идеале, проверять качество ABAP-программы в рамках реализации проекта следует на первом этапе разработки. Однако стремление найти компромисс между возможными задержками сроков и затратами на приоритетные области проекта может привести к тому, что процессы проверки вручную останутся без должного внимания. После переноса в продуктивную среду новые ABAP-программы попадают в пул уже существующих ABAP-программ и с этого момента на то, чтобы обнаружить проблемы с качеством в общем портфолио ABAP программ, потребуется больше затрат. Например, связанные с производительностью ошибки в операторе SELECT без условия WHERE в больших по размеру таблицах в продуктивной среде относятся к критическим. Такие ошибки могут замедлить выполнение ежедневных операций в транзакциях, использующих такие программы.
Чтобы избежать появления такой затратной проблемы, необходимо выполнять превентивную автоматизированную проверку качества не только в продуктивной среде, но уже в самом начале разработки ABAP-программ. ATC позволяет находить подобные ошибки с указанием номера строки программы, в которой они возникли. Для эффективного выполнения проектов следует внедрить полностью или частично автоматизированные проверки качества по соответствующим требованиям. В этом цикле из трех статей мы подробно рассмотрим описанные опции и многочисленные возможности ATC.
ATC проверяет качество ABAP-объектов в нескольких областях, в том числе по производительности, безопасности, синтаксису, соглашениям по программированию и робастному программированию, а также выполняет общие проверки. В зависимости от важности этих категорий проверок им присваивается приоритет. Эти проверки можно настраивать и переносить. Настройка пользовательских вариантов проверок подробно рассматривается во второй части.
Робастное или надежное программирование — это стиль программирования, который фокусируется на обработке исключений программного кода. Такой стиль, требует, чтобы код обрабатывал все возможные исключения во всех местах их возможных возникновений путем «изящного» перехвата возможных исключений с отображением точного и однозначного сообщения о возникших ошибках. Эти сообщения об ошибках позволяют пользователю более легко отлаживать программу. В рамках системы SAP и программирования на языке ABAP данный стиль должен исключить появления системных дампов (аварийного завершения) в ходе выполнения ваших программ.
ATC объединяет несколько инструментов: Syntax Check (транзакции SE38 и SE80), Extended Syntax Check (SLIN), Code Inspector (SCI) и Code Vulnerability (платная функция). За исключением последней функции, эти инструменты предоставляются в ATC бесплатно. ATC не просто интегрирует указанные инструменты, но функционирует как целостная платформа управления для проведения проверок качества кода с использованием функций отчетности, блокировки переносов и потока операций для обработки особых ситуаций возникающих в ходе проверки кода.
Функции отчетности ATC подробно рассматриваются в третьей части. Функциональность блокировки переносов в инструменте ATC предоставляет как полностью, так и частично автоматические опции проверки. При полностью автоматической блокировке переносов перед деблокированием выполняется автоматическая проверка переноса на наличие ошибок ATC в соответствующих ABAP-программах. При обнаружении ошибок ATC в таких ABAP-программах деблокирование переноса не выполняется, он остается в той же системе. Подробное описание функциональности блокировки переносов и потока операций для обработки особых ситуаций ATC приводится в третьей части.
В первой части рассмотрим настройку ATC. Рекомендации по эффективному использованию ATC собраны в подразделе «Знания, полученные опытным путем».
В продуктивных сценариях эффективное использование ATC может вызвать ряд затруднений. Группа поддержки не несет ответственности за ошибки ATC в существующих программах, которые были разработаны другими проектными группами. Группа поддержки отвечает только за ту часть кода программы, которая была изменена во время процесса предоставления поддержки. Такой сценарий можно наблюдать практически во всех организациях и проектах. Описанная модель затрудняет использование ATC. Кроме того, такая ситуация препятствует применению функциональности ATC для блокировки переносов. В этом случае переносы будут блокироваться по причине существующих ошибок в программе, исправление которых находится за пределами сферы ответственности группы поддержки. Вариант проверки по умолчанию в инструменте ATC Code Inspector не распознает такое поведение и выводит все ошибки. Таким образом, вам придется дополнительно настраивать вариант с помощью пользовательской разработки, чтобы проверка качества в ATC выполнялась только для версии программы, выпущенной после определенной даты (например, после даты вступления в силу договора о предоставлении поддержки).
Все инструменты, интегрированные в утилите ATC, связаны с технической проверкой качества ABAP-программ. Здесь нет компонентов для проверки функциональной правильности или логики программ. Для проверки этих аспектов вам придется ждать начала этапа тестирования проекта.
Для проектов, в которых на этапе разработки широко применяются проверки ATC, наблюдается тенденция по проценту исправляемых и игнорируемых ошибок, выявленных в процессе проверки ATC. Из всех ошибок, выявленных ATC, около 35–40 % исправляются группой разработки, а оставшиеся 60–65 % игнорируются. Вообще, данное процентное соотношение наблюдается после анализа всех ошибок ATC вручную. Эти данные взяты мной исключительно из собственного опыта участия в крупных проектах внедрения и расширения.
Некоторые найденные ATC ошибки игнорируются по той причине, что их исправление не дает каких-либо преимуществ. Например, условие SELECT* для пользовательской таблицы базы данных с небольшим количеством полей является правильным, однако ATC помечает его как ошибку с высоким приоритетом. Исправление этой ошибки не даст ощутимых преимуществ ввиду ничтожной степени риска снижения производительности в продуктивной среде, а для исправления отбираются именно ошибки, которые являются критическими для работы продуктивной системы. Процент исправленных ошибок подтверждает способность функциональности ATC выявлять проблемы, связанные с техническим качеством. Однако в данном случае, как уже было сказано выше, применять функциональность блокировки переносов будет затруднительно. Если ошибки игнорируются при обработке особых ситуаций ATC, переносы блокироваться не будут. Однако если решение игнорировать ошибки принято за пределами системы в результате проверки вручную, например, в Excel, переносы будут заблокированы.
Как правило, проверка кода вручную выполняется на основе предварительно составленного контрольного списка. Такой список не может быть таким же подробным, как проверки ATC. Кроме того, при выполнении вручную, невозможно избежать ошибок связанных с человеческим фактором, что исключается автоматических проверках ATC.
Для каждого проекта определены сроки и приоритеты по затратам. Необходимо найти баланс по объему усилий, затрачиваемых на проверку качества кода во время этапов реализации, разработки и тестирования. В противном случае исправление ошибок может потребовать слишком много времени и сорвать сроки выполнения проекта. Если исправление ошибки не дает ощутимых преимуществ, ее можно проигнорировать. Однако если критическая техническая ошибка с этапа разработки переходит на этап тестирования, на ее исправление придется потратить намного больше средств. Исправление ошибки становится намного более затратным на этапе проверки перед переходом к продуктивной эксплуатации, чем на этапе тестирования. И, разумеется, затраты возрастают еще больше, если неисправленная ошибка попадает в продуктивную систему. Решения по проверкам качества кода принимаются с учетом факторов затрат, сроков, возможных задержек и общего настроя группы управления программами.
Благодаря различным опциям настройки и интегрированным функциям проверки ATC можно использовать разными способами. Настройка ATC выполняется двумя способами: локально и централизованно:
Ниже обе опции будут рассмотрены подробнее. В табл. 1 представлены возможные варианты использования ATC в любом проекте или ландшафте.
Технические эксперты рекомендуют разработчикам в рамках процесса разработки на ABAP выполнять самопроверку и привлекать к проверке качества ABAP-объектов коллег. Этот процесс можно добавить в контрольный список проверки ABAP-кода. При самопроверке разработчик, создавший код, проверяет качество, а его коллега предоставляет взгляд со стороны. Отчет ATC для данного идентификатора разработчика может стоять первым пунктом в контрольном списке на проверку коллегой. Менеджеры по качеству, технические руководители и менеджеры проектов могут просматривать проверки ATC для всех разработанных программ с помощью централизованных прогонов обработки отчетов для данного уровня переносов, пакета, пользователя или программного компонента.
В SAP Solution Manager настройка ATC является предпосылкой для настройки качества в инструменте управления жизненным циклом пользовательского кода (Custom Code Lifecycle Management; CCLM). Настройка ATC должна быть выполнена для всех управляемых систем с разработками на ABAP для автоматического переноса результатов централизованного прогона ATC с помощью утилиты CCLM в функцию обеспечения качества (ABAP-программ). Результаты ATC представлены графически в CCLM. Эта функция весьма полезна для менеджеров, отслеживающих тренды по качеству в портфолио ABAP, особенно для крупных проектов внедрения с большим объемом разработок на ABAP.
Как было сказано ранее, некоторый процент ошибок, выявленных ATC, будет проигнорирован, поскольку их устранение не даст компании никаких дополнительных преимуществ. Если решение проигнорировать ошибку принимается вручную за пределами системы SAP, то в графике трендов по результатам Solution Manager не выводит сравнение количества проигнорированных ошибок и ошибок, запланированных к исправлению. Технические руководители и менеджеры по качеству должны будут уделить внимание данному факту во время применения функции обеспечения качества CCLM.
Локальная настройка ATC (для настройки локального прогона, локального прогона и периодического планирования в фоновом задании) выполняется в системе разработки, в которой были созданы ABAP-программы. После завершения настройки отчеты ATC можно будет обрабатывать локально, вручную и периодически. Фоновые задания можно запланировать в рамках настройки для автоматического выполнения периодических отчетов.
Ниже представлены шаги локальной настройки ATC:
После ввода всех значений выберите пиктограмму сохранения, см. Рис. 3. Это важный шаг, поскольку в нем определяется поведение инструмента ATC в разных сценариях использования. Ниже приводится описание всех значений настройки.
Рис. 1. Экран транзакции ATC
Рис. 2. Экран настройки ATC
Если вы являетесь подписчиком журнала SAP
Professional Journal, пожалуйста,
авторизируйтесь на сайте.
Если вы хотите подписаться на журнала SAP Professional Journal, пожалуйста, обратитесь в редакцию или сделайте заказ
на сайте.
Правила получения тестового доступа к статьям SAP Professional Journal
Комментарии по теме