Ключевое понятие

Пульт управления тестированием 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

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 можно использовать разными способами. Настройка ATC выполняется двумя способами: локально и централизованно:

• Локальная настройка выполняется в системе разработки. При такой настройке качество кода всех ABAP-программ в системе разработки проверяется локально. В этом случае программы находятся в статусе «Выполняется» и «Завершено».
• Централизованная настройка осуществляется в системе обеспечения качества или в тестовой системе. Централизованная настройка позволяет проверять качество кода ABAP-программ из разных систем разработки, перенесенных в систему обеспечения качества. Результаты проверки при централизованной настройке переносятся обратно в соответствующие системы разработки. В этом случае по установленным критериям фильтрации для выполнения проверок при такой настройке учитываются только готовые программы, перенесенные в систему обеспечения качества.

Ниже обе опции будут рассмотрены подробнее. В табл. 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:

1. Войдите в систему разработки SAP ERP Central Component (ECC), Master Data Management (MDM) или любой другой системы SAP, в которой выполняется программирование на ABAP. Используемый для входа в систему идентификатор должен предоставлять полномочия на выполнение транзакции ATC с правами администратора.
2. На экране SAP Easy Access перейдите к транзакции ATC. На рис. 1 показаны два основных раздела данной транзакции: ATC Administration (Администрирование ATC) и Quality Governance (Управление качеством). В разделе ATC Administration (Администрирование ATC) доступны опции, связанные с начальной настройкой, функции планирования и мониторинга отчетности, а также список утверждающих особые ситуации. В разделе Quality Governance (Управление качеством) доступен браузер особых ситуаций для обработки утверждений или отклонений, а также средства управления вариантами проверки.
3. Для настройки ATC выберите опцию Configure ATC (Сконфигурировать ATC) в разделе Setup (Настройка), как показано на рис. 1. Появится экран настройки (рис. 2).
4. Для выполнения настройки выберите пиктограмму изменения, показанную на рис. 2. Введите значения, как показано на рис. 3. Эти значения рассматриваются ниже.

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

   • Global Check Variant — DEFAULT (Глобальный вариант проверки — DEFAULT). Это глобальный вариант проверки Code Inspector, который используется при проверке различных параметров ABAP-кода. DEFAULT — это стандартный вариант проверки SAP. Для него в разных областях (производительность и удобство использования) установлены предопределенные значения. Он подробно рассматривается в разделе «Пользовательская настройка варианта проверки».
   • Do You Want to Enable ATC Exemptions in the System? (Активировать особые ситуации ATC в системе?) Yes (Да). В этом шаге подтверждается решение об использовании потока операций для обработки особых ситуаций ATC. Если программа сообщает об ошибке, найденной ATC, вы можете выбрать один из двух вариантов действий. Исправьте ошибку, внеся в программу необходимые изменения, либо проигнорируйте ее, предоставив достаточное обоснование. При выборе опции игнорирования вы направляете запрос утверждающему (техническому руководителю или менеджеру по качеству) на признание данной ошибки особой ситуацией. В потоке операций для обработки особых ситуаций ATC утверждающий особых ситуаций может запросить дополнительные пояснения, отклонить или утвердить запрос на признание ошибки особой ситуацией. Это подробно описано в разделе «Поток обработки особых ситуаций в ATC» в третьей статье цикла.
   • For Which Kind of Results? (Для каких результатов?) (применимость особой ситуации) — For Central Results Only (Только для результатов централизованного прогона). В этом шаге указывается, для каких результатов следует применять особую ситуацию. В данной настройке указано значение Central Results (Результаты централизованного прогона). В ATC создаются результаты двух видов:
     • Local results (Результаты локального прогона) — ATC запускается локально в той же системе и результаты используются в потоке операций для обработки особых ситуаций. Этот случай относится к категории For Any Results (Для любых результатов), см. Рис. 3.
     • Результаты централизованного прогона — ATC запускается через тестовую систему или систему обеспечения качества, а результаты отправляются обратно в систему разработки. В ATC система обеспечения качества или тестовая система называется ведущей. Такой вариант прогона ATC применяется для анализа готовой ABAP-программы, перенесенной в систему обеспечения качества или в тестовую систему.
   • Master System (Ведущая система) — система обеспечения качества с доверительным RFC-подключением. Это тестовая система или система обеспечения качества, в которой выполняется проверка ABAP-программ. Если имеется несколько систем, следует тщательно продумать, какая из них станет ведущей. Как правило, целесообразно сделать ведущей систему обеспечения качества в ландшафте. Как было сказано выше, роль ведущей системы велика, поскольку прогоны ATC из этой системы отправляются обратно в систему разработки и рассматриваются как результаты централизованного прогона.
   • ATC Behavior on Release — No ATC check (Поведение ATC при деблокировании — без проверки ATC). Это относится к сценарию блокировки переносов. Здесь определяется поведение ATC при деблокировании переноса, содержащего ABAP-программы с выявленными ATC ошибками. В данном примере проверка выполняться не будет. В раскрывающемся списке доступны и другие опции, например, Inform on Errors (Priority 1 or 2) (Информировать об ошибках с приоритетом 1 или 2) или Block on Errors (Priority 1 or 2) (Блокировать при ошибках с приоритетом 1 или 2). Для блокирования переноса по причине обнаружения ATC ошибок в программе, которую данный перенос содержит, требуется дополнительная настройка. Этот сценарий рассматривается в разделе «Блокирование переноса по причине обнаружения ATC ошибок» в третьей статье цикла.
5. После завершения настройки запланируйте прогон ATC. Для этого вернитесь на главный экран транзакции ATC. Выберите опцию Schedule Runs (Запланировать прогоны) в разделе Runs (Прогоны), см. Рис. 4. В результате появится экран, показанный на рис. 5.
6. Запланировать прогон ATC можно двумя способами:
   • оперативно (т. е. прогон ATC можно выполнить вручную в любое время);
   • периодически (т. е. прогон ATC выполняется автоматически в фоновом задании с указанной периодичностью).

Рис. 1. Экран транзакции ATC

Рис. 2. Экран настройки ATC