Когда Вы поддерживаете свой Oracle BRM (Billing and Revenue Management) в течение некоторого времени, Вы начинаете понимать, что количество сконфигурированных сущностей продолжает расти. К этому времени, вполне вероятно, что Вы также разработали некоторые настройки и интегрировались с дополнительными решениями. Эволюция Вашей среды приводит к созданию сложного кластера взаимосвязанных объектов. Наступает момент, когда Вы или Ваш клиент решаете что-то изменить. Поначалу может показаться, что разработать новую функцию легко. Однако, правда заключается в том, что она, скорее всего, столкнется с существующей функцией или потребует обновления существующей конфигурации. То, что казалось простым изменением, затем повлияет на всю систему. Таких случаев иногда трудно избежать, но если быть готовым к ним, это может избавить Вас от многих проблем. Сценарии функционального тестирования и универсальность тестирования могут стать решающим фактором.
Оглавление
Поток непрерывного развития
В компании Tridens мы создали непрерывный поток разработки. Все наши конфигурации BRM, настройки и другие интегрированные компоненты должным образом версионируются и отслеживаются в распределенной системе контроля версий (Git). Такая практика позволяет нашим разработчикам в любое время проверить необходимые версии компонентов и начать работу. На данный момент все хорошо, но как нам справиться с возможностью того, что новые функции сломают текущую сборку?
У нас установлен поток развертывания и тестирования, который отслеживает удаленные репозитории наших источников. Следовательно, каждый раз, когда разработчик фиксирует и переносит некоторые изменения в систему контроля версий, это инициирует процесс тестирования. Поток развертывания создает образы докеров для всех соответствующих компонентов с их последними версиями в локальной (или удаленной) среде, и выполняются автоматизированные тесты, чтобы убедиться в стабильности сборки. Только когда тесты пройдут успешно, мы можем выпустить новые версии в производство. Этот процесс помогает нам гарантировать, что новые функции будут работать без проблем с существующими. Выполняемые тесты являются частью разработанного нами Oracle BRM TestToolkit. BRM TestToolkit содержит предопределенные шаги и сценарии с фоновым клеевым кодом. Шаги очень описательны и удобны для пользователя, что позволяет нашим разработчикам или любым другим пользователям быстро писать новые тестовые сценарии. Пример тестовых сценариев приведен на изображении ниже.
BRM TestToolkit для автоматизированного тестирования
То, что начиналось как простые тестовые сценарии для создания счетов и покупки товаров, сегодня представляет собой основной блок нашего тестирования BRM TestToolkit. Чтобы уточнить, сейчас у нас есть несколько различных тестовых сценариев и сценариев для периферийных случаев, чтобы обеспечить максимальный охват реализованных функций. Автоматизированные тесты позволяют нашим разработчикам сосредоточиться на поставленной задаче и не тратить огромное количество времени на ручное тестирование. Конечно, иногда мы сталкиваемся с тем, что разрабатываем новую функцию, еще не охваченную тестовыми сценариями. В таких случаях определения шагов тестирования и их фоновый код реализуются как часть этой функции - для использования в будущем.
TestToolkit может взаимодействовать с различными компонентами, обеспечивая возможность быстрой настройки и для других систем. Мы также используем переработанные версии нашего BRM TestToolkit для других наших компонентов. Одна из последних добавленных нами функций - модульность, когда разработчики могут помечать различные тестовые сценарии как части группы. Каждая группа затем имеет свои сценарии и разделенную логику, что позволяет, при желании, выполнять только определенное количество тестов одновременно и параллельно. Более того, модульность позволяет нам отделить тесты рейтинга предоплаты от тестов рейтинга постоплаты или тесты покупок аддонов от разных покупок. Вы можете увидеть поток тестов на изображении ниже.
Покрытие тестового сценария
BRM TestToolkit взаимодействует с нашим API, который мы интегрировали с Oracle BRM для упрощения более сложных операций. TestToolkit также может взаимодействовать с BRM RestBridge, наше решение по обертке BRM, которое облегчает взаимодействие с BRM, позволяя использовать формат JSON или XML через REST API. Определения шагов тестирования поддерживают, помимо многих других, следующие операции:
- Создание и управление учетной записью
- Покупка сделок и другие операции по сделкам
- Поиск и проверка баланса
- Генерация трафика - События, связанные с использованием
- Вызовы API
- Выброс CDR
- инструменты трафика в реальном времени (протокол diameter)
- Проверки рейтинга
- BRM TestToolkit сравнивает различные события использования и покупки с ожидаемыми значениями
- каждый отдельный план или продукт может иметь свой собственный набор рейтинговых файлов, что обеспечивает универсальность в сложных настройках продуктов
Составляя удобные для пользователя этапы тестирования, каждый разработчик может написать сценарии для разрабатываемой функции. Во многих случаях наши разработчики предпочитают составлять сценарии тестирования заранее - до разработки функции. Заблаговременная подготовка сценариев соответствует модели разработки, ориентированной на поведение (Behaviour Driven Development, BDD). BDD по сути означает, что сценарии диктуют ход разработки и должны существовать заранее. Эти сценарии описывают, как должна вести себя система, и разработчики должны разрабатывать новые функции таким образом, чтобы они соответствовали этим сценариям. Каждый тест-сценарий может выполняться отдельно, в результате чего получается отчет в заданном формате. Ниже приведен пример HTML-отчета.
Отчетность
Когда система запускает тест-сценарии как часть новой сборки разработки, она обычно выполняет их в полном объеме - включая все тесты. От среды к среде это может занять некоторое время, но это дает Вам широкую картину того, как новая функция могла повлиять на любые другие существующие реализации. Мы можем оценить стабильность сборки на основании отчета о тестировании, который BRM TestToolkit генерирует в конце тестового прогона. Отчеты о тестировании содержат подробную информацию по каждому сценарию тестирования, а также предоставляют некоторую статистику и аналитику по всем тестам в целом. Мы можем использовать этот анализ, чтобы найти различия между сборками и убедиться, что сборка работает правильно. Смотрите пример отчета ниже.
Заключение
Наличие правильного решения для тестирования может сэкономить огромное количество времени и предотвратить появление ненужных ошибок. Поэтому, если Вы столкнулись с трудностями, упомянутыми в этой статье, или если Вас заинтересовал наш набор инструментов для тестирования BRM, не стесняйтесь обращаться к нам. Мы с удовольствием расскажем Вам больше о нашем решении и разработаем оптимальный план по улучшению Вашего процесса развертывания и тестирования.