Архив метки ATC

Тестируем OData в eCATT – 2

VirVit No Comments

Привет.

Сегодня мы начнем тестировать наш сервис по чтения логов приложений. О тестировании как подходе я много раз писал, поэтому не буду повторяться.

Наша задача – протестировать OData сервис, чтобы любое изменения в его работе тут же показывалось в тестах. Это позволит нам заранее видеть как то или иное изменение скажется на всей системе, особенно, если у нас десятки и сотни тестов, а не 1-2.

OData по сути это формат обмена сообщениями между разными системами. Здесь нет визуальной составляющей, которую нужно или можно тестировать. То есть, мы не сможем проверить, как работа сервиса влияет на отрисовку таблички в приложении или реакцию кнопочки. Об этом я вам позже расскажу.

Итак, мы должны убедиться, что сервис выдает только нужные нам данные и в нужном формате. Если что-то меняется, то тесты должны это показать, а мы увидеть и принять решение – это изменились требования к сервису или ошибка разработки. Если перевести на русский язык, то тест должен запустить сервис как будто это настоящее приложение, получить данные и сверить их с эталонными. Если сверка прошла, то тест пройден. В противном случае – ошибка.

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

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

VirVit 3 комментария

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

Тестирование программного кода в SAP

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

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

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

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

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

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