Тестирование базы данных
February 3, 2022

Тестирование результата проведения документов

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

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

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

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

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

  1. Настройки системы. Например, при различных методах списания стоимости товара получается различная стоимость, состав аналитики и количество движений в документах выбытия товаров со склада.
  2. Состояние системы на момент проведения документа. При выполнении теста необходимо обеспечить состояние системы сопоставимое с состоянием, при котором был подготовлен эталон. Например, задолженность клиента на разные моменты времени может быть различной и еще содержать различные комбинации аналитик.

Общий подход к решению проблемы "простое". Настройки сохранить в тестовой базе и поддерживать их актуальность. Состояние системы обеспечивать в самом тестовом сценарии.

При подготовке эталона возникают вопросы:

  1. все записи включать в эталон или отдельные?
  2. все реквизиты записей включать в эталон или часть?
  3. значения реквизитов фиксировать или параметризировать?

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

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

Переменные можно использовать во всех частях сценария, и как значение реквизита документа, и как значение для сверки с эталоном движений. И если впоследствии потребуется изменить значение переменной, то автоматически значение изменится везде где используется. Чтобы обеспечить читаемость кода переменным нужно давать "говорящие" имена, которые позволять понять код сравнения актуальных значений с эталоном без полного сканирования кода. Например, так:

Проверить равенство значения реквизита документа ИмяРеквизитаДокумента эталонному значению реквизита регистра ИмяРеквизитаРегистра

Проверить равенство значения переменной ИмяПеременной эталонному значению реквизита регистра ИмяРеквизитаРегистра

ИмяРеквизитаДокумента == ИмяРеквизитаРегистра

ИмяПеременной == ИмяРеквизитаРегистра

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

Получаем следующую классификацию переменных сценария:

  • константы для реквизитов документов
  • константы для реквизитов эталона
  • переменные для реквизитов эталона = значениям реквизитов документа
  • вычисляемые переменные для реквизитов эталона