Обеспечение стабильности работы. Автоматическое тестирование. : ФинСофт:КупецЪ

Говоря о проекте ФинСофт:КупецЪ, надо упомянуть инструменты для автоматизации тестирования, которые являются "коньком" используемой технологии.

Вначале два слова о компиляторе.
При разработке Купца используется так называемая Case-технология. Проект ведется на уровне метаданных. То есть в виде специфической базы данных с вкраплением ручного кода. На основании информации в метаданных с помощью генератора кода создаются программные модули на языке программирования, которые затем компилируются в бинарный машинный код в виде стандартных динамических библиотек (dll) windows или исполняемых exe-файлов. Именно в нативный машинный код, а не в какую-либо разновидность интерпретируемого байт-кода. Это позволяет не только получать очень быстро работающую программу, но и осуществлять глубокую верификацию ошибок. Поэтому при работе в Купце практически никогда не выскакивают системные сообщения об ошибках. Привычка верифицировать код компилятором приводит к тому, что даже в тех случаях, когда в том или ином виде используются динамические вычисления, придумываются методы, чтобы подсунуть их компилятору, чтобы он их увидел и проверил.

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

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



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



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



Проверка контрольных сумм очень важна на случай каких-либо форс-мажоров. Для примера возьмем итоговую сумму по товарным накладным. Эта сумма сохраняется в заголовке документа и равна сумме по всем входящим строкам. Она используется как для ускорения расчетов, так и для дополнительной проверки, все ли в порядке с базой данных.

Программа хранит информацию о фактических и свободных оперативных остатках в разрезе товар/склад для повышения скорости работы. Проверка сверяет остатки, рассчитанные по документам, и хранимые значения.

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

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



Тестирование бизнес-логики.
Этот раздел был создан для автоматической сверки контрольных сумм некоторых базовых расчетов в бизнес-логике. В частности, здесь проверяется работа парционного учета. Парционный учет в Купце довольно интеллектуален. Он не только выполняет распределение отгрузок (списаний, перемещений) по закупкам, но и использует итоги периодов для оптимизации времени выполнения. Один из тестов заключается в том, чтобы вначале выполнить расчет распределения по партиям товаров за период без оптимизации, затем с учетом различных вариантов нахождения готовых итогов и сравнить результаты. Ниже показаны скриншоты диалога запуска тестов бизнес-логики и выходного файла с результатами.

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



Для каждого отчета можно сохранять наборы параметров выполнения. Для автоматизированного тестирования мы сохраняем их под специальными названиями "Автотест 1", "Атотест 2" и т.д.



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



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

Юнит тесты интерфейса.
Мы можем визуально проверить работу в нужных диалоговых окнах. Например, зайдем в пункт меню Журналы-Приходные накладные и нажмем комбинацию клавиш Ctrl+Alt+U. После этого окно оживает и начинает "проигрываться" в автоматическом режиме. Мы можем расслабиться и наблюдать. Проверяется расположение контролов при ресайзе (изменении размеров окна), порядок обхода контролов по клавише TAB (Enter), затем мышка последовательно наводится на разные контролы (поля ввода, кнопки и т.п.) и мы видим, какой текст выводится во всплывающих подсказках. Если на окне есть закладки, то все эти тесты повторяются для каждой из них. Как и в случае с юнит тестами отчетов, можно создать список проверяемых диалогов и проигрывать их последовательно в автоматическом режиме. Окно запуска тестов в этом случае выглядит так:

Тестирование макета.
Для проверки работоспособности программы в нагрузочных режимах можно автоматически сгенерить базу данных с заданными параметрами. Фрагмент диалога для генерации базы данных выглядит следующим образом.



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

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