1с отключить проверку корректности метаданных
Определение имен таблиц MSSQL
Структура базы данных 1С весьма запутана и состоит из малозначимых для человека названий. 1С содержит функцию определения структуры хранения по имени объекта. В основу разработки положена эта функция ПолучитьСтруктуруХраненияБазыДанных, которая согласно русскому названию возвращает описание структуры. В этой структуре важны 2 поля Назначение, которое должно быть равно «Основная», и название таблицы ИмяТаблицыХранения.
Определение смещения дат
Таблица _YearOffset содержит число, обозначающее смещение года дат. Оно принимает значение 0 или 2000. Так со смещением 2000 дата 01.01.2014 будет храниться в базе данных как 01.01.4014. Соответственно при отборе по датам (удаление происходит за период времени) нужно учитывать смещение. Смещение можно получить следующим кодом 1С:
Установка пометки на удаление документов
Имея названия таблиц документов и зная, что поля _Date_Time, _Marked и _Posted отвечают за дату, отметку об удалении и отметку о проведении соответственно, можно одним SQL-запросом пометить их все на удаление. Делается это так:
Установка пометки на удаление в журналах документов
Не смотря на установку отметки на удаление у документов, в журналах документов хранятся дубли отметок об удалении на каждый документ. Список журналов, где участвует документ можно получить из метаданных документа так: Метаданные.ЖурналыДокументов
Отметка на удаление через поля _Marked и _Posted происходит аналогично через команду:
Удаление движений регистров
При удалении документов 1С удаляет движения документа по регистрам. В случае прямого доступа эти движения нужно удалить самостоятельно. Список регистров можно получить через метаданные ДокументМетаданные.Движения.
Команда, которой выполняется удаление движений следующая:
Заключение
Как оказалось, добиться убыстрения работы 1С примерно на 2 порядка не так сложно, достаточно выполнить 3 вида команд. В конечной обработке логика расширена за счет выбора документов по видам, добавлением таймаута, добавлением транзакции, пакетным выполнением команд.
PS. Список возникающих проблем и пути устранения:
1. Обработка игнорирует документы, где запрещено проведение, например, корректировка записей регистров. В корректировке записей регистров удаление документа связано со снятием активности записей регистров.
2. Результат удаления не отражается в планах обмена. Решается одновременным запуском обработки в связанных базах.
3. Не затрагивает таблицы итогов. Решается пересчетом итогов через Конфигуратор-Тестирование и Исправление-Пересчет итогов.
Коллеги, привет!
Есть ли возможность отключить различные проверки при обновлении конфигурации и базы данных (пусть на свой страх и риск при падениях базы)?
Дописал 3 строчки кода в расширении, перезапускаешь и начинается проверка на 1-3 минуты. А если это часто делаешь - куча времени тратиться на ожидание этой проверки.
(3) Не изменилось ни чего, так же задумывается с "проверка корректности метаданных". Попробовал выше снять галки с тонкий клиент и сервер - тоже нет эффекта. Для проверки в модуле просто пустую строку добавлял и удалял.
(5) благодарю, у меня похоже эти ситуация как раз
"На текущий момент существует два способа применения расширений конфигурации.
Без анализа структур данных (быстрый): используется когда гарантированно нет изменения структур данных
С анализом структур данных. Способ гораздо дольше, так как уже требует совмещать расширение с основной конфигурацией и проводить достаточно много проверок.
Определение способа производится предварительным анализом в начале применения. Анализ должен быть быстрым и поэтому использует достаточно грубый метод - анализируется может ли измененный объект влиять на структуры данных. Так как изменение модуля документа так же отмечает сам документ как измененный то, это приводит к применению такого расширения по долгому пути. При изменении общего модуля применение соответственно будет происходит быстро. Мы планируем улучшить ситуацию, но пока так.
Как обходной путь для расширений, не меняющих структуры данных, пока можно предложить понизить режим совместимости расширения конфигурации (только расширения) до версии 8.3.10. Это гарантирует применение расширения быстрым способом (так как в нем точно нет изменений, влияющих на структуры данных)."
Буду пробовать понижать версию совместимости.
(7) У меня не помогает режим совместимости. Правда и 5-10 минут, как пишут некоторые, нет. Полминуты-минута. НО всё равно безмерно раздражает.
Э. А простите, вопросы к страдающим:
- проверка идет в режиме конфигуратора, т.е. у вас происходит режим разработчика и жалобы на проверку расширения в этом режиме?
- или вы готовое расширение накатываете на боевую базу и жалуетесь уже на боевой базе?
Надеюсь, что намек достаточно прозрачный
(9) Спрашивается, нахрена делать проверку метаданных, если эти метаданные не изменялись ни в основной конфигурации, ни в расширении? Если я модуль добавил или реквизит какой - хрен с вами, проверяйте. Но постоянно-то при каждой записи изменений конфигурации зачем?
Надеюсь, что намёк достаточно прозрачный?
С рабочей базой проблема не волнует. Рабочая обновляется раз в день в отличии от работы разработчика в базе разработчика. На рабочей ненапряжно и подождать. Если, конечно, процесс занимает не десятки минут и больше.
Купили на предприятие ЕРП2.0. Как можно разрабатывать и что-то вообще делать, если оно дико тормозит. cf файл весит 700 мб. При изменении кода, приходится ждать от 10 секунд до минуты. Что делать?
(1) btree, С конфигурацией лучше работать локально, по сети будет тормозить, при каждой запуске по сети 1с обновляет кэш конфигурации на локальном диске, не считая временных файлов которые формирует при сравнениях, отладке, разработке.
(10) btree, Монитор ОС при загрузке или сравнении конфигурации сколько показывает, в среднем должен показывать 40-50Мб/с или выше, если значения не такие у вас диск не работет в режиме SATA, проверить биос и обновить драйвера чипсета. Если ноутбук новый, то обновить БИОС.
(15) btree, И сделайте тоже самое виндой, в ней можно увидеть каждый процесс и какая скорость обмена с диском у этого процесса.
(14) alex_sh2008, в мониторе показывает в байтах, и скорость показывает 3млн, то есть меньше чем 3 мб
(18) btree, Значит надо смотреть что по мимо 1С нагружает диск так сильно что для 1С ничего не остается. У меня на SATA 2 обычном диске конфигурация ERP 2 грузится около минуты, при этом еще и обновление windows ставится. Ищите кто у вас парализует работу дисковой подсистемы, проверьте настройки антивируса, что бы не сканировал то что не надо, особенно данные 1С там точно вирусов не может быть. И кстати если у вас общая производительность диска низкая то явно можно указать что в Windows не включен режим ACHI, и диск работает в режиме эмуляции IDE, а тот тест то что ранее выложили, это тест внутренней производительности диска
(19) alex_sh2008, когда я перевел базу на файловый режим, конфигуратор грузится за 7 секунд. Потом когда я что-то поменял, проверка корректности метаданных около 15 секунд и секунд 7 запуск.
И как мне кажется минута это непозволительная роскошь, для загрузки конфигуратора. Работает конфигурация в режиме 1с предприятия приемлемо для конечного пользователя, но вот для разработчика это просто ужас какой-то.
Может я конечно разбалованный, что сразу привык проверять результат написанного кода. Но как по-другому?
(20) btree, Возможно эти значения вполне нормальные для вашей материнской платы и жесткого диска, а что касается разработки, то 90% разработки это планирование, и лишь 10% сама реализация.
Без смысленно на ноутбуке запускать sql серверные версии 1С, производительности материнской платы не хватит.
(22) alex_sh2008, обычно да, а когда тебе файловый вариант пишет превышен максимальный размер внутренней таблицы (пишу приблизительно, так как не помню, что оно там точно выдавало), то тут кроме как скл ничего не поможет
(34) alex_sh2008, Спасибо, запись на автограф - в среду вечером. Не опаздывайте, у меня масса поклонников.
Для ERP до минуты для запуска отладки это нормально.
Если приходится постоянно перезапускать предприятие, что что-то не так с процессом работы.
Лучше дольше подумать, прежде чем что-то писать.
Тогда отладка занимает минимум времени.
Че-то боюсь, вы не правы.
Отладка занимает столько времени, сколько нужно, чтобы "код" пришел "в соответствие" с данными, которые он обрабатывает. И это никак не зависит от времени продумывания.
(24) btree, Тогда стоит заняться оптимизацией системы, по наблюдать за монитором и отследить процессы которые постоянно обращаются к диску и обмен у этих процессов очень большой, у меня как то была ситуация когда система жутко тормозила, проанализировав я увидел что все забирало под себя Wi-Fi, отключил половину сервисов сетевой карты, все стало нормально летать.
(4) btree, Должно хватать.
У меня слабее ноутбук. Подвисает только при открытии конфигурации и запуске отладки.
Работа с кодом достаточно комфортная.
(5) ekaruk, должно, но не хватает. Тест гилева дает 32,47. (Файловый вариант 71,43) При добавлении реквизита например в документ какой-нибудь, я жду минуту (идет реструктуризация). При первом открытии формы любого документа, тоже жду около 10 секунд.
На сервере та же самая беда, правда там не ссд диски, а обычные 10к
Платформа 1С:Предприятие 8.3 (8.3.6.1999)
Странно, что-то у вас с настройками не так, надо смотреть отключены ли энергосберегающие функции в биос и настройки схемы питания ос.
Зимой сделал знакомому "бюджетный" сервер (E3-1241v3 + SuperMicro X10SLL-F + SSD (TempDB + кэш + временные файлы)), так этот "бюджетник", без каких либо особых настроек, выдал 78 попугаев в клиент-сервере по тесту Гилева. Соответственно на вашем камне должно быть не ниже 50, так-как даже мой старенький алиенвар на i7 920, без всяких SSD, в клиент-серверном тесте выдает больше 50 "попугаев".
(4) btree, SSD как подключен? Как дополнительный или как системный?
Плюс есть такая полезная функция в 8.3.6, как выполнение проверки в модулях при изменении/ удалении реквизитов. Так вот, когда надо удалить или переименовать какой-то реквизит в большом количестве мест - она мега полезна, но при повседневной обычной работе жутко мешает. Отключите её в настройках конфигуратора и скорость работы резко возрастет.
Неужели у всех все летает. Только что проверил. Запустил конфигуратор, дождался, ничего не менял. Нажал F5, загрузилось через 20 секунд. Это что нормально, неужели ни у кого ничего подобного не наблюдается.
Смешно конечно. Взял обычную торговлю, добавил реквизит в документ Реализацию, нажал F5, на запуск ушло 5 секунд (с нажатием кнопки подтверждения реструктуризации).
Вопрос, может мне надо чего-то где-то настроить, чтобы оно как-то быстрее работало?
Вы ещё загляните в общий модуль "МенеджерОбменаЧерезУниверсальныйФормат". 40+ тысяч строк.
Вот, где ERP2 тупит, так тупит. После каждой нажатой точки, после каждого знака "равно". Просто при наборе текста.
(25)да и не только ерп, сижу мучаюсь в БП 2.0, РегламентированныйОтчетПрибыль, в формах по 36к строк, контекстную подсказку хоть отключай. Проц наверно надо менять, i3 на 3.3ггц явно мало.
Работаю с очень переписанной УПП, дополненной свистелко-перделками УСО, автотранспортом и кучей какой-то ереси приправленной интегрированным документооборотом от 1С. На сервере конфиг открывается десяток минут, сравнивается минут под 20, объединяется ~ 40.
Юзерам работается шикарно. Мне нет. Из сервера выжимать уже нечего. База ~400ГБ. Файлы хранятся вне базы.
Локально, копия той-же базы под локальным скулем:
Страйп из двух SDD. На него кеш 1С сервера, сам сервер. Софт сервера MSSQL и базу скуля.
Ремдрайв на ~ 4гб. Туда сместить (например симлинками командой mklink) весь какой получиться найти кеш клиентской части 1С (можно смотреть монитором ресурсов).
из директорий:
AppData
Roaming
LocalAppData
MyDocuments
Коварная 1С всё равно будет создавать некоторые темпы в \\Windows\Temp но локально для одной 1С сместить директорию темпов у меня не вышло пока. Руки дойдут, расковыряю их dll, придумаю как пути подменить. Под ОС тоже SSD.
Открытие конфига до минуты.
Сравнение 2-3 минуты.
Объединение 4-5 минут.
Любите ли Вы динамическое обновление конфигураций так, как люблю его я? Обожаю что-нибудь с его помощью пропатчить на продакшене! Особенно в пятницу! Вечером! Перед майскими праздниками! Без предупреждения!
На самом деле нет! Динамическое обновление с одной стороны выглядит отличным механизмом платформы 1С, который позволяет вносить изменения в конфигурации "на лету". Главное, чтобы изменения не затрагивали структуру базы данных, в противном случае придется выполнять обновление монопольно и "выгонять" пользователей.
Согласитесь, при появлении ошибки в коде после очередных изменений просто берешь и обновляешь базу "на горячую" и никаких проблем! Главное всем, кому нужны были эти изменения, перезапустили сеанс и изменения вступят в силу!
С другой стороны может что-то пойти не так и Вы найдете небольшую, но весомую порцию багов у себя.
И никакие отговорки, что это были изменения для ТОП-менеджеров Вам не помогут!
Но как же так! Вы пользуетесь динамическим обновлением и у Вас нет никаких проблем? Коллеги рассказывают страшные истории, но Вы им не верите? "Просто они плохие 1Сники!", думаете Вы?
Как работает динамическое обновление
Наверное это странный вопрос, ведь ответ лежит на поверхности - это механизм позволяет обновить конфигурацию базы данных без остановки ее работы, внося изменения не требующие модификации на уровне базы данных. В официальной документации на ИТС есть информация в каких случаях платформа позволяет провести динамическое обновление. Вроде все просто. Но что если пойти дальше.
В любой информационной базе есть таблицы "Config" и "ConfigSave". Назначение этих таблиц также известно:
- Config - содержит основную конфигурацию информационной базы, которая соответствует актуальной структуре базы данных и используется активными сеансами.
- ConfigSave - содержит сохраненную конфигурацию. Ту самую, которую Вы редактируете в конфигураторе. Как только Вы нажимаете "Сохранить", все измененные объекты и связанная информация записывается именно сюда. После запуска обновления информационной базы все изменения из этой таблицы переносятся в таблицу Config. Если же выполнить команду "Конфигурация -> Конфигурация базы данных -> Вернуться к конфигурации БД", то вся информация об изменениях в этой таблице удалится.
Все просто, не так ли? Но пойдем еще дальше. Посмотрите на структуру таблиц для хранения данных конфигурации.
Структура таблиц идентична.
Описание полей такое:
- FileName - строка длиной 128, используется для хранения имени "файла", это некоторая часть конфигурации.
- Creation - дата создания записи.
- Modified - дата модификации записи.
- Attributes - целое число, назначение которого сейчас нет смысла рассматривать (на самом деле я точно не могу утверждать, только предполагаю зачем оно нужно. Но если Вы знаете, то напишите в комментариях).
- DataSize - размер данных в байтах, хранящийся в поле "BinaryData"
- BinaryData - непосредственно данные конфигурации.
- PartNo - номер части. Иногда размер данных объекта метаданных может быть очень большим и платформа его разбивает на части.
То есть конфигурация хранится некоторыми блоками. Вообще, структура хранения конфигурации в таблице базы соответствует тому, как устроена внутренняя структура форматом файлов CF. Подробнее об этом Вы можете узнать в отличной статье "Описание формата файлов конфигурации (CF, EPF, ERF)" от Андрея Овсянкина.
Со структурой таблиц и их назначением понятно. Пойдем дальше.
Когда Вы начинаете процесс обновления информационной базы, на первом этапе платформа 1С выполняет множество служебных действий, останавливаться на которых сейчас особо нет смысла. Самое интересное начинается после того, как Вы нажимаете заветную кнопку "Обновить динамически".
Среди множества служебных действий, платформа переносит данные об объектах из таблицы ConfigSave в Config:
В следующий раз, когда информационная база будет обновляться в обычном режиме, записи об объектам, созданных при динамическом обновлении, будут удалены и останутся только основные записи с актуальными данными конфигурации.
Это очень поверхностное описание и сам процесс имеет множество особенностей как со стороны работы БД, так и со стороны работы клиентских приложений платформы 1С. Но суть должна быть понятной.
Подробный пример динамического обновления
Для того, чтобы детальней погрузиться в происходящее при таком обновлении, рассмотрим все действия платформы 1С, до которых можно добраться законым способом. То есть мы не будем влазить в модули работы самой платформы и открывать то, за что можно получить повестку в суд. Мы лишь посмотрим что делает платформа на стороне базы данных. И этого нам будет достаточно!
В нашем примере есть некоторая конфигурация на базе БСП (хотя это и не важно), в которой добавлен очень важный общий модуль "ДляДинамическогоОбновления".
Модуль полностью клиентский, имеет в своем составе только одну функцию.
На первом шаге мы вносим изменения в модуль и нажимаем "Сохранить конфигурацию". При этом изменения в конфигурации сохранены, но не применены к информационной базе.
На этом шаге платформа 1С делает записи в таблицу "ConfigSave", некоторое промежуточное хранилище, из котого потом измененные элементы конфигурации должны будут перенесены в основную таблицу конфигурации "Config".
Вот вся история операций в таблице "ConfigSave" после сохранения конфигурации. Здесь подробная информация обо всех действия практически на физическом уровне, поэтому некоторые операции "INSERT" разделены на две (INSERT и UPDATE), а операция UPDATE может быть выделена как операции DELETE и INSERT. Но эти особенности сейчас не играют роли.
Кроме этого в таблице есть дата операции (Period) и идентификатор транзакции (__$start_lsn). По факту все эти действия выполняются в разных транзакциях, лишь некоторые из действий в таблице выполняются в единой транзакции.
Вся операция, как уже упоминалось выше, делится на два этапа:
- Записываем в таблицу информацию об изменениях конфигурации , в частности нашего общего модуля "ДляДинамическогоОбновления". Кстати, на скрине выше видно, что его идентификатор "cb327a01-e9cc-44e6-af31-5f30c88faeca", отсюда и эти названия похожие. Имена содержат суффикс "new", что говорит о промежуточной записи объектов.
- На следующем шаге промежуточные записи преобразовываем в нормальные , просто исключив "new" из имен элементов конфигурации.
Тут все достаточно просто, идем к следующему шагу. Вы нажимаете кнопку "Обновить информационную базу", но так как в базе есть сеансы, а изменения касаются только модулей, то платформа 1С предлагает выполнить динамическое обновление без завершения сеансов.
В этот момент платформа 1С сделала два действия:
- Скопировала записи из таблицы "ConfigSave" в таблицу "Config" с суффиксом "new", почти все действия выполнены в одной транзакции.
- Затем было обнаружено, что обновление невозможно продолжить из-за наличия активных сеансов. Был показан диалог для динамического обновления, а ранее добавленные записи удалены из таблицы "Config" в одной транзакции.
Изменений в таблице "ConfigSave" в этот момент не выполнялось.
И вот мы добрались до последнего шага - запуска динамического обновления. Соглашаемся с этой операцией и получаем следующее.
- В таблице "Config" сначала добавляются новые записи с суффиком "new" для последующих операций с ними. Примерно такие же действия мы видели в самом начале в таблице "Config", перед тем как было предложено выполнение динамического обновления. Но в этот раз также сделаны служебные записи "commit", "dynamicCommit" и "dbStruFinal", которые относятся непосредственно к динамическому обновлению (частично о них было упомянуто выше).
- Предварительные записи с суффиксом "new" теперь платформа преобразовывает в нормальные записи, также добавляет записи с форматом "_dynupdate_", плюс вставляет флаг динамического обновления "DynamicallyUpdated".
- Из таблицы "ConfigSave" удалены все сохраненные ранее записи. Все в одной транзакции.
- И напоследок из таблицы "Config" удаляются служебные данные "commit", "dynamicCommit" и "dbStruFinal".
Заметьте, каждый этап - почти всегда разные транзакции, это важно.
После этого конфигурация успешно обновлена динамически, база работает. Чтобы клиентам получить новые изменения достаточно перезапустить сеанс. Вроде все хорошо.
На самом деле это не все действия платформы 1С, т.к. еще обновляются данные в таблице "Params" и некоторые другие. Но мы это рассматривать сейчас не будем.
Разработчики ликуют и со словами "Я же говорил" продолжают убеждать коллег, что динамическое обновление это нормально!
Что может пойти не так
Весь процесс динамического обновления мы рассмотрели, но что же может случиться?
Представим простую ситуацию: что, если все обновление прошло успешно, кроме последнего этапа? Например, во время выполнения запросов на удаление служебных данных соединение с базой данных почему-то "отпало":
- Сбой сети.
- Регламентные работы на сервере, внезапно.
- Обслуживание базы, которое завершило блокирующий сеанс, опять же внезапно!
- Конфигуратор вылетел из-за ошибки внутренней.
- Разработчик 1С был странным и завершил сеанс конфигуратора во время обновления.
- И еще сотни причин, которые лень добавлять.
Чтобы такое проще было представить, можно добавить в базу данных триггер, который при попытке удаления служебной записи о динамическом обновлении упадет в ошибку.
Попытаемся теперь выполнить динамическое обновление и столкнемся с ошибками:
- Сначала во время обновления в конфигураторе поймаем ошибку.
- А при попытке зайти в конфигуратор повторно мы словим ошибку.
- При попытке повторить обновление мы уйдем в бесконечную ошибку вида.
Все, конфигуратор нам больше недоступен! Чистите кэш, пытайтесь выполнить обновление ИБ, удаляйте сеансовые данные! Все бесполезно! Можете еще взять бубен, но и он бесполезен!
После этого проблема будет полностью исправлена в 99% случаев.
И это все?
Такая ошибка вас не остановит? Говорите, что ну и ладно, что в конфигуратор не вошли, зато клиенты работают, а с конфигуратором бы разобрались? Ведь решения есть на просторах интернета!
Хорошо, а как вам такой же "обрыв" соединения на этапе обновления данных в таблице "Params". Сделаем другой триггер (отключите только предыдущий):
При попытке обновления записи "DynamicallyUpdated" в таблице "Params" мы получим падение. Конфигуратор закроется системной ошибкой. Не страшно, скажите Вы! Но в этот же момент все клиентские соединения также вылетят, причем с разными ошибками. Например, с такой.
А при попытке перезапустить клиентский сеанс, также будут происходить различные ошибки. Никто не сможет работать с информационной базой!
Но и тут не все потеряно!
Клиентские сеансы не могут зайти в базу, их всех выкинуло и так далее! Но мы все еще можем в большинстве (но не во всех) случаев зайти в конфигуратор! И при повторном обновлении также в большинстве (но не во всех) случаях мы восстановим работу информационной базы!
Итог, все вылетели из базы, мы словили адреналина, и восстановили работу после штатного повторного обновления. Вас и это не убедило, что динамическое обновление очень опасно?
Вы поистине яркий человек
Если Вам и этого мало, то как Вы думаете, что будет, если оба этих случая будут комбинированы? В этом случае Вы "выкинете" всех пользователей из информационной базы, а потом еще и не сможете войти в конфигуратор повторно. Пойдете после этого вручную очищать таблицу "Config" от служебны записей динамического обновления и надеяться, что это в этот раз поможет.
Вы удивительный человек!
А ведь есть еще проблемы другого рода:
- Повреждение сеансовых данных сервера. Возникают из-за какого-то особого поведения платформы 1С, меняется от релиза к релизу, сложно прогнозируемые и сложновоспроизводимые ошибки.
- Повреждение клиентского кэша, которое приводит к:
- Ошибкам запуска клиентского приложения при входе в информационную базу
- Случайным ошибкам во время работы приложения, таким как "Тип неопределен" или подобные.
Ниже есть ссылки на примеры различных проблем и их решение. Для воспроизведения таких проблем мне пришлось бы откопать код приложений платформы 1С, но это не очень правильно.
Это весело
Вы все еще считаете, что динамическое обновление это хорошо? Что нет ни единой причины, чтобы отказаться от него? Что все описанные ошибки, которые даже можно воспроизвести прямо на свежих версиях платформы (от 8.0 до 8.3.20), не являются критичными? Может вы еще и бэкапы не делаете?
Кстати, описанные выше проблемы аткуальный как для платформы 1С версии 8.0, так и для всех более новых версий, вплоть до 8.3.20.*. И это только вершина айсберга!
Надеюсь, информация из статьи поможет кому-то хотя бы задуматься над тем, что Вы делаете!
P.S. А Вы задумывались над тем, что установка расширений тоже может приводить к подобным проблемам? :)
У пользователей и разработчиков на платформе «1С:Предприятие» нередко возникает необходимость проверки работоспособности конфигурации после обновления на последний актуальный релиз, внедрения нового функционала или в других случаях. В данной статье мы рассмотрим механизмы тестирования конфигураций 1С, их достоинства, недостатки и различия.
Самый распространенный вид тестирования – вручную. Например, после обновления конфигурации программист вынужден проверять все ситуации, возникающие во время работы пользователя в программе, смотреть, где возникают ошибки, и исправлять их. На это он может потратить от нескольких часов до нескольких дней, недель и даже месяцев. Продолжительность тестирования зависит от самой конфигурации, а если она не типовая, а измененная, то длительность зависит также от сложности доработок, внесенных в конфигурацию. Ручное тестирование отнимает не только много времени, но и сил специалистов. Также важное значение имеет человеческий фактор: специалист устает, отвлекается, пропускает некоторые ошибки по невнимательности, а также может ненамеренно внести новые ошибки.
Попробуйте решения для тестирования от «1С-ИжТиСи» бесплатно
Оцените, насколько наши сервисы и продукты будут полезны и выгодны именно для вас. Это совершенно ничего не стоит.
Заполните форму — а всё остальное организуют наши специалисты.
Также можно позвонить по бесплатному номеру 8 (800) 77-51-256 либо написать письмо на Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript. .
Существуют различные механизмы тестирования на платформе «1С:Предприятие», среди которых:
- Тестирование и исправление информационной базы 1С;
- Автоматизированное тестирование в «1С:Предприятие 8.3»;
- Программный продукт «1С:Сценарное тестирование 8» (далее – СТ);
- Программный продукт «1С:Автоматическое тестирование конфигураций» (далее – АТ).
Тестирование и исправление информационной базы 1С
Механизм тестирования и исправления информационной базы 1С, встроенный в саму конфигурацию, является одним из простейших видов тестирования. Он запускается из режима Конфигуратора и служит для диагностики и устранения ошибочных состояний информационных баз, имеющих различный формат хранения данных (файловый или клиент-серверный).
Область применения данного вида тестирования невелика, поскольку он имеет строго ограниченное количество проверок: реиндексация таблиц, проверка логической целостности баз данных, проверка ссылочной целостности, пересчет итогов, сжатие таблиц информационной базы и реструктуризация таблиц. В то же время он не предполагает наличие у пользователя навыков программирования, все необходимые тесты уже написаны.
Автоматизированное тестирование
Автоматизированное тестирование в «1С:Предприятие 8.3» – это новый механизм, предназначенный для имитации интерактивных действий пользователей системы и проверки результатов этих действий.
При тестировании используются два вида клиентских приложений: менеджер тестирования и клиент тестирования. Менеджер тестирования устанавливает связь с клиентом тестирования и выполняет сценарий тестирования – код на встроенном языке, в котором описывается последовательность выполняемых интерактивных действий.
Для выполнения автоматизированного тестирования необходимо сначала разработать сценарий тестирования – написать внешнюю или встроенную в конфигурацию обработку, в которой будут последовательно описаны выполняемые шаги. После чего запустить исполнение созданной обработки в менеджере тестирования.
Данный вид тестирования предполагает наличие у пользователя навыков программирования, достаточных для создания обработок.
Сценарное тестирование
Подобный механизм тестирования представлен программным продуктом «1С:Сценарное тестирование 8». Это инструментарий для проверки работоспособности любой конфигурации системы «1С:Предприятие 8», который позволяет подготавливать необходимые тесты и выполнять их в ручном либо автоматическом режиме.
СТ состоит из двух внешних обработок: одна предназначена для записи теста, вторая – для его выполнения.
Тест представляет собой набор действий, которые пользователь должен выполнить в программе (например, создание новых элементов справочников, документов, заполнение данных на форме, нажатие кнопок). При автоматическом выполнении такого теста происходит имитация ввода информации пользователем. Выполнение команд теста по интерактивному созданию объектов и заполнению форм отрабатываются платформой так же, как если бы эти данные пользователь вводил с клавиатуры.
- Для разработки тестов не требуются навыки программирования, достаточно представления о работе тестируемой конфигурации на уровне пользователя.
- Позволяет писать и выполнять тесты для проверки работоспособности любой конфигурации на платформе «1С:Предприятие 8».
- Тесты, как правило, пишутся для наиболее часто используемых сценариев реальной работы пользователей с прикладным решением и выполняются на каждой новой версии измененной конфигурации или платформы.
- Тесты можно делать более или менее сложными, в зависимости от критичности ошибок в том или ином функционале прикладного решения и в зависимости от количества времени, которое в организации готовы потратить на тестирование.
- Для выполнения теста не требуется специальной подготовки тестируемой конфигурации.
- Имеется возможность при выполнении автоматизированного теста обойти обнаруженную ошибку вручную и продолжить выполнение теста в автоматическом режиме.
- Предоставляет возможность отладки шагов при записи теста.
Автоматическое тестирование конфигураций
Еще одним программным продуктом, позволяющим выполнять поиск ошибок в конфигурациях, является «1С:Автоматическое тестирование конфигураций». Он предназначен для максимально полной проверки работоспособности конфигураций на платформе «1С:Предприятие» редакций 8.2 и 8.3.
Он используется при тестировании функционала конфигурации, при выпуске нового релиза, тестировании конфигурации после обновления, а также конфигурации, полученной путем объединения функционала нескольких конфигураций.
Программный продукт может выполнять следующие тесты:
- Тест «Синтаксический контроль» предназначен для выявления синтаксических ошибок тестируемых конфигураций.
В отличие от типового синтаксического контроля модулей данный тест позволяет выявить все синтаксические ошибки модулей конфигурации за один запуск тестирования. При тестировании нескольких конфигураций показаны будут только вновь возникшие ошибки. - Тест «Проверка конфигурации» запускает стандартную проверку конфигурации – проверку логической целостности конфигурации и поиск некорректных ссылок. Позволяет сопоставлять ошибки в нескольких конфигурациях.
- Тест «Вызов событий форм» имитирует работу пользователя с конфигурацией: выполняется программное открытие всех форм тестируемых объектов конфигурации, генерируются различные события форм и элементов управления. Сравнивает результат работы теста для нескольких конфигураций и выводит отчет тестирования обновленной конфигурации (также имеется возможность посмотреть отчеты для всех четырех конфигураций).
- Тест «Анализ оборотов и остатков» позволяет сравнивать регистры тестируемой и эталонных конфигураций.
- Тест «Сравнение движений документов» выполняет проведение документов информационной базы и сохраняет их движения в специальном формате. Если при указании нескольких конфигураций окажется, что результаты их движений различаются, будет выведено предупреждение об изменение логики работы.
- Группа тестов «Проверка метаданных» включает в себя три теста:
- тест «Метаданные» проверяет корректность обновления метаданных обновленной конфигурации;
- тест «Формы» выполняет проверку корректности обновления обычных и управляемых форм, их реквизитов и элементов управления обновленной конфигурации;
- тест «Роли» выполняет проверку корректности обновления ролей обновленной конфигурации.
Особенности:
- Выполняет комплексное тестирование конфигураций, разработанных на платформе «1С:Предприятие», полностью в автоматическом режиме. Участие пользователя требуется только для запуска тестирования и последующего исправления найденных программой ошибок.
- Не требует предварительного создания тестов для проверки работоспособности конфигурации 1С, они уже имеются в программе и применимы для любых конфигураций.
- Позволяет тестировать не только типовые конфигурации, но также сильно измененные.
- Качество тестирования не зависит от степени критичности ошибок и их количества в конфигурации.
- Для запуска тестирования не требует дополнительных приложений, обработок или каких-либо сложных настроек конфигурации.
- После завершения тестирования формирует отчет о различиях и ошибках, найденных в работе тестируемых информационных баз. В списке обнаруженных ошибок указывается место и контекст их возникновения (облегчает процесс исправления ошибок). Также имеется возможность посмотреть время выполнения того или иного события.
- Автоматически формирует отчет по списку процедур и функций, которые не удалось вызвать автоматически, с указанием возможных причин (отчет «Покрытие кода тестами»).
- Помогает в устранении найденных ошибок. После завершения тестирования выводит подробный список задач, которые должен вручную выполнить специалист для исправления ошибок.
- Тестирование можно выполнять с использованием от одной до четырех конфигураций одновременно, при этом все, кроме основной, будут считаться эталонными.
- Позволяет производить сравнительный анализ производительности работы тестируемых конфигураций.
- Позволяет выполнять выборочное тестирование – тестирование отдельных объектов конфигурации, запуск отдельных тестов, направленных на решение конкретных задач).
- Имеет возможность запуска на платформе «1С:Предприятие» как редакции 8.2, так и редакции 8.3.
- Используется для тестирования одной или нескольких конфигураций с режимом запуска как «Обычное приложение», так и «Управляемое приложение».
Сравнение программных продуктов и механизмов тестирования
Проведя сравнение АТ с другими механизмами тестирования, например, с СТ, можно выделить ряд существенных преимуществ данного программного продукта.
Отличия «1С:Автоматическое тестирование конфигураций» от «1С:Сценарное тестирование 8»:
- СТ требует ручной подготовки сценариев тестирования. В случае изменения функционала необходимо заново разрабатывать сценарии тестирования.
- Работа СТ не автономна. При возникновении критичных ошибок процесс тестирования останавливается.
- Список ошибок в СТ протоколирует пользователь, а в АТ он формируется автоматически.
- СТ может находить ошибки, которые зависят от последовательности действий пользователя.
- СТ позволяет настраивать тестирование взаимосвязи объектов. В АТ каждый объект тестируется независимо, за исключением ввода на основании, открытия форм из «родительского» объекта (например, подбор или выбор из справочника).
- СТ можно настроить на работу с пустой базой, а для работы АТ необходимо наличие информационной базы, максимально близкой к продуктивной.
- На текущий момент АТ проверяет эталонные значения только для движений и регистров.
Мы рассмотрели четыре механизма тестирования конфигураций 1С, из которых каждый специалист может выбрать наиболее подходящие для него инструменты и повышать качество конфигураций, значительно сократив трудозатраты, по сравнению с тестированием вручную.
Читайте также: