Автоматизация контроля программного кода в ABAP с помощью SAP Code Inspector

Жизнь подкидывает мне интересные задачки. На днях мне пришлось задуматься об автоматизации контроля качества ABAP разработок. В системе есть инструмент для автоматизации контроля качества программного кода, написанного на языке ABAP. Транзакция ATC созвучна с ABAP Test Cockpit.

тестирование программного кода (авторство изображения не установлено)

Например, мы можем сказать системе проверять все деблокированные запросы в части разработок на контроль качества с помощью ABAP Code Inspector, где можно задать правила приемки кода. Можно попросить систему автоматизированно по расписанию проверять код, написанный программистами на заранее определенные правила и не допускать его перенос по ландшафту. Для заказчиков я бы рекомендовал включать такие требования в технические задания, чтобы хоть как-то прививать культуру разработки и тестирования кода. Не забывая, что за качество тоже нужно платить. Хотите обеспечить отсутствие бэкдоров в системе или неэффективного кода — пропишите в Code Inspector правила, которые не позволят переносить такие «сомнительные» разработки до ручного утверждения. Запретите прямые SQL выборки во избежание нарушения полномочий доступов. Разработайте политики безопасности, производительности и управляемости программным кодом — это сэкономит существенное количество денег, если вы хотите их считать. Деньги считать.

Транзакция SCI — Code Inspector — позволяет настраивать правила, перечень объектов/людей для контроля. Правила игры простые:

1. Код должен быть «чистым» в части производительности, читабельности, безопасности. Иначе рефакторинг.
2. Код должен быть на 100% покрыт тестами. Иначе вы получите ошибки в продуктивной среде.
3. Пункты 1 и 2 должны быть регламентированы, документированы и обязательны. Без исключений.
4. В случае проблем начни с пункта 3.

В идеале архитектор определяет правила. Тестировщик пишет функциональные тесты. Программисты обеспечивает успешное выполнение тестов. Контролер по качеству обеспечивает приемку разработки.  Заказчик будет счастлив. Мы же все здесь в этом блоге умные люди и понимаем, что есть стандарт, а есть Z. Так и с разработками, где система и вендор предлагают стандартные инструменты для обеспечения качества решения, а мы делаем свой Зет, с которым потом и хороним хорошие проекты.

Откроем транзакцию SCI.

Здесь мы видим инспекции, объекты для проверок и правила (варианты) проверок. Все очевидно, Кэп. Инспекция  состоит из перечня объектов для проверки и варианта проверки (что именно проверять). Давайте проверим что-нибудь из стандартного функционала SAP, например, форму Т-3 на правила именования, которые рекомендует сам вендор.

Определяем область для проверки в виде одной нашей программы формирования штатного расписания.

Создаем новую проверку, где указываем наш перечень объектов и один из стандартных вариантов проверок. В данном случае мы укажем вариант для проверки правил именования переменных. Если вы полистаете стандартные варианты, то увидите очень много интересных вещей. Искренне рекомендую изучить и сделать собственные.

Запустим это безобразие и подождем результата. Налью пока чай.

Если присмотреться, то ничего критичного нет. В своих правилах можно удалить проверки на несуществующие инклуды или ограничить область проверок. В данном случае САП молодец, все выполнил по своим рекомендациям. 😉

Осталось выстроить процесс. С моей точки зрения он выглядит примерно так. Ежедневный ABAP Unit Test всех разработок. Деблокирование запроса для переноса в систему интеграционного тестирования. В момент деблокирования проверяется Code Inspector через ABAP Test Cockpit. В системе интеграционного тестирования запускается eCATT для наполнения данными и прогона функциональных и интеграционных тестов. В случае успеха человек-тестировщик осуществляет ручную проверку сложных ситуаций по плану тестирования. Про планы тестирования я писал ранее.

В итоге мы обеспечиваем практически 99,99% тестирование функциональности, а следовательно и качество решения, которое можно назвать промышленным.