<?php // Полная загрузка сервисных книжек, создан 2025-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Капец, какой титанический труд. Мне теперь будет плохо от любых словосочетаний автоматическое тестирование.
(2) Большая часть шагов ведь автоматически записывается. Дальше дело за малым — либо объединить исходный тест-кейс/сценарий c автоматически записанными шагами, либо наоборот, разбить автоматически записанные шаги на логические группы. Некоторые даже и этого не делают, хотя сценарии тогда сложно читать и адаптировать.
И уж точно это проще, чем разработать и запрограммировать механизм. Написание сценария занимает меньше 10% от всей разработки и может выполняться даже не программистом или с его небольшой помощью. Конечно при условии, что разработка ведётся по чётким требованиям, на основе которых можно составить хотя бы тест-кейс. А ещё лучше — сценарий, похожий на тот, что был в начале каждого примера.
Зато потом многие ошибки до продуктива не доходят. Вот например последняя ошибка, которую ловили на нашем CI-контуре как раз была связана с присоединенными файлами. Ошибка, которую трудно обнаружить вручную. Её бы поймали пользователи, процесс ввода нескольких типов документов был бы нарушен, и пришлось бы в срочном порядке обновлять рабочую базу ещё раз.
И, как правило, сценарии получаются значительно проще чем здесь. Здесь специально в учебных целях рассмотрены сложные случаи — обмен между двумя базами, работа с файлами, проверка движений. Потому что в сети довольно много примеров, относящихся к синтетическим базам, где никаких ограничений и сложностей нет. Здесь можно посмотреть, как будут выглядеть сложные сценарии для типовых конфигураций.
Главная проблема — не написать сценарий, а адаптировать его к изменениям в конфигурации. Чем чаще и масшатбнее меняется функционал, тем больше времени требуется на адаптацию. Об этом собственно уже писал во вводной публикации: , а вот здесь о том же самом писал . Но это проблема любого тестирования, даже ручного. Оно хорошо работает когда требования к системе изначально поступают обдуманные и не хаотичные. Точно также, как и любая автоматизация.
(3)
Все таки стоит оговариваться, что результат автоматической записи сильно далек от идеального.
Требуется внимательная вычитка, удаление мусора, и замена многих неадекватных шагов.
А неадекватных шагов будет много. Например везде придется заменять шаг переключения флага, т.к. это очевидно рандом. Мы либо ставим флаг, либо снимаем, но не просто меняем несмотря на его состояние. И это далеко не все. Надо будет вырабатывать культуру выбора значений в ссылочных полях, т.к. автоматика будет выдавать что-то типа: «нажать выбор, выбрать текущую строку», что тоже рандом.
Времени на первых порах это занимает довольно много. И избавиться от этого процесса полностью видимо вообще не удастся.
Думаю вы это конечно где-то уже говорили. Оставляю тут эту информацию, чтобы картина была полнее.
Владимир, сделайте, пожалуйста, оглавление. Вы выдаете огромные объемы, но не учитываете, что читать это целиком мало кто решится. Очень тяжело без навигации. И код наверно лучше в спойлеры спрятать.
(5) Предыдущие публикации были с подробным оглавлением. Но здесь сквозные примеры, их сложно разбить на составляющие. В рамках одного примера все действия плавно перетекают одно в другое.
Да, понимаю, что публикация имеет этот недостаток. Поэтому постарался уменьшить его, описав в начале каждого примера какие вопросы будут в ходе него рассмотрены и чему можно на каждом примере научиться. Публикация рассчитана уже на практиков. Тех, кто действительно решил применять VA на своих проектах и кому для старта не хватает может быть только сквозных примеров. И подсказок, которые помогут преодолеть первые препятствия.
Больше таких длинных примеров приводить не планирую, их здесь уже четыре штуки накопилось, учитывая первую часть. Следующая публикация будет для разработчиков. По теме реализации своих шагов, библиотек и экспортных сценариев. Там точно получится сделать нормальную структуру и оглавление.
(4) Не воспринимайте как критику. Просто когда я смотрю, как работают разработчики на других платформах с аналогичными фреймворками, то начинает казаться, что мы в мире 1С вообще избалованы и капризны )) А ведь на других платформах покрытие систем юнит- и функциональными тестами гораздо чаще является нормой, чем в наших процессах разработки. Может быть у них тоже есть какие-то секреты, позволяющие автоматизировать процесс создания функциональных тестов. Но судя по тому, что можно найти в сети, как раз в 1С сейчас одни из самых удобных фреймворков.
(7) Не понял что я вообще мог принять за критику ) Ну да ладно (вы вроде всегда максимально тактичны).
К чему вы привели видео не понял, ведь на них вроде программисты )
Для программиста и голое API платформы вполне норм. А если хочется быстро и удобно, то берешь Тестер и погнал.
Мой коммент был не про программистов, а про вероятных пользователей записывалки шагов (тестировщиков и аналитиков).
(8) Комментарий выше и ссылки на видео были к тому, что похоже именно фреймворки для 1С сейчас дают возможность максимально автоматизировать функциональное и сценарное тестирование. По сравнению с инструментами для других платформ. Особенно это касается подходов с использованием Gherkin, которые в случае 1С позволяют заниматься сценарным тестированием и созданием исполняемой документации с минимальным знанием программирования.
Простейшие сценарии ведь вообще без программирования можно создать, только адаптировать их потом чаще придётся.
«Тестер» тоже для 1С, и «Тестирование 3.0». У нас сейчас очень классные инструменты есть. Кажется, что специалистам на других платформах намного сложнее приходится с решением тех же вопросов. Они глубже в техническую сторону вопроса должны погружаться.
(9) Я походу переутомился. Не понимаю что мне пишут )
Я понял, что не понял вас до этого, но теперь не могу понять этот коммент.
Пойду посплю, пожалуй ) Переработал )
(10) Хорошая мысль. Поступлю аналогично ))
Владимир, отлично, пошли примеры. Но почему не делать выводы, ведь это важно с точки зрения применимости технологии. Так или иначе (даже если его упростить), думаю невооруженным взглядом видно, например, почему простой по сути и очень сложный по форме, является первый сценарий. Безотносительно к вашему труду, а лишь правды ради — назвать сложным сценарий “прикрепления файла к документу” ну ведь никак нельзя. Уверен, вы ожидали подобный комментарий-придирку о недостаточной сложности, но ведь именно в этом и вся суть, а в не в многообещающей методологии.
Для контраста, вот как ваш первый тест выглядит в Тестере:
Показать
(12) Уверен, каждый инструмент найдёт свою нишу.
В отношении данного примера тоже можно сказать, что реализовав шаги сценария Gherkin не за счет типовых шагов встроенной библиотеки Ванессы, а запрограммировав собственные шаги, всё получится гораздо лаконичнее. В сценарии остались бы только исходные высокоуровневые шаги, а во внешней обработке немного кода на 1С, как в Вашем примере. Такой вариант тоже возможен и легко реализуем программистом.
Но в этом случае мы лишимся главного преимущества Ванессы — человекочитаемости вплоть до каждого элементарного действия и объединения в одном месте тест-кейса и исполняемого сценария. Опять же, есть те, кто BDD использует или стремится к этому подходу. Для них пока нет альтернатив, кроме проектов, основанных на Vanessa-Behavior. Ведь в этом случае сценарий — это еще и часть документации по системе, а не только регрессионные тесты.
С другой стороны видео, записанное для демонстрации возможностей Тестера, тоже показывает достаточно большое количество ручных операций и программирования: . И в документации также сказано о том, что не всегда с первого раза получается записать сценарий, который воспроизводится без ошибок. И дана рекомендация записывать накликиванием короткие сценарии, а затем дополнять их кодом.
Просто у каждого инструмента своё назначение. Программисту для регрессионного тестирования наверное будет удобно «Тестер» использовать. Я вот смотрю в документацию и видео-примеры и понимаю, что удобно. Но я разработчик. А если аналитиков подключать или QA, то надо уже думать, смогут ли они адаптировать сценарии к изменениям в системе, когда это понадобится (а ведь точно понадобится, система — штука живая).
Ещё у Тестера есть неоспоримое преимущество — документация по инструменту, очень хорошая. Лучшая из всех имеющихся инструментов и программисту очевидно легко изучить будет. Я вот пытаюсь восполнить этот недостаток у Ванессы.
Было бы интересно увидеть пример адаптации готового сценария для Тестера, разбитого на процедуры, к изменениям в системе. Думаю это не должно быть сложнее, чем в случае с Ванессой.
Нет ли у Вас в планах записать такое видео или публикацию сделать? Например для типовой конфигурации, так как это наиболее актуально. Или может быть оно уже есть, а я пропустил?
Спасибо за поддержание конструктива!
Да, такой пример я рассматривал, вот ссылка
На счет человеко-читаемости. Сложный вопрос. К примеру, такие шаги: “Это необходимо чтобы в списке файлов появилось две строки и мы могли автоматически записать шаг”, “И я запоминаю значение поля с именем «Номер» как «НомерДокумента»” и другие, накапливают особенности и соглашения, а сам (общий, даже с учетом возможности подшагов) объем сценария растет серьёзно с ростом кол-ва тестируемых объектов. В итоге получается, что ну ведь не сложный сценарий прикрепления файла, через призму кнопконаждималки + человеко-понятности, делает этот сценарий совсем уже не простым.
В тестере, кнопконажимался была реализована для быстрого входа в систему, реальные тесты, насколько я знаю, со временем люди начинают писать руками.
(14)
Вы сами решаете на каком уровне детализации остановиться.
Можно создать сценарий вообще с одним шагом «Сделать всё» и спрятать детали реализации внутрь.
(0)
Не рекомендую проверять движения регистра на прямую.
Лучше проверять отчеты.
Структура регистра может сто раз ещё поменяться, но отчет будет меняться синхронно с ним и будет учитывать эти изменения регистра.
(0)
Это странное решение. Лучше так не делать, а ждать асинхронного события.
Я сам писал сценарий для тестирования обмена в РИБ и точно могу сказать, что паузы при синхронизации не нужны.
(0)
1) можно проверять область макета
2) есть шаги, которые не зависят от порядка строк и в таблицах и в макетах
(0)
В Vanessa-Automation это работает. Можно в ячейке указывать $ДатаДокумента$.
(0)
И спасибо за статью!
(0)
Ещё в макетах можно указывать симол *, тогда ячейка не будет участвовать в сравнении.
(15) можно и вручную протестировать, можно обработками и многими другими способами. Но речь об удобстве применения инструмента, а не только о его теоретических возможностях, а это включает в себя оперативный и понятный анализ падений, оперативность рефакторинга, оперативный запуск и обмен сценариями других программистов команды, запуск сценариев во время разработки при каждом F5, без необходимости очистки базы и многое-многое другое, запуск сценариев в фоне и многое другое. В свое время, я приложил достаточно усилий (со своей точки зрения) чтобы получить требуемый уровень комфорта в работе и качестве результата используя сценарное тестирвоание и ванесса-инструменты, не получилось. Затем посмотрел в код нескольких обработок «по промышленным стандартам», затем часовые видео о том, как настраивать окружение, и почти ничего а самом тестировании и пришел к выводу, что продолжать бесполезно, нужно делать самим. И я без претензий, никто ведь никому ничего не должен, но для конструктивного продолжения разговора, подскажите пожалуйста, где найти видео-или-документацию с разбором практического примера, по сути не уступающей разбору в этой ссылке
(22)
Тут непонятно — в чём у вас возникла проблема в ванессой при
— оперативный и понятный анализ падений
— оперативность рефакторинга
— оперативный запуск и обмен сценариями других программистов команды
— запуск сценариев во время разработки при каждом F5, без необходимости очистки базы
Это, на мой взгляд, всё реализуемо и в Ванессе (как бы она не называлась).
Я не встречал развёрнутого комментария по этим темам, что вы попробовали — но не получилось то-то и то-то.
(23)
Возможно так и есть, но мне этим овладеть не удалось, во всяком случае в моем понимании процесса.
я их не писал, а должен был? мне хватило информации, которой я почерпнул из открытых источников.
(16) Да, тоже отметил в конце публикации, что проверка через отчет гораздо надёжнее.
Смысл демонстрации проверки движений через форму списка был в том, чтобы продемонстрировать применение ряда шагов, которые остались бы без внимания в случае проверки отчета. Про методику проверки отчетов было в прошлой публикации, поэтому здесь решил показать другой вариант. Менее надёжный, более сложный, зато включающий больше незнакомых читателю шагов.
Может быть зря так перегружаю информацией, но всё таки публикации нацелены на тех, кто хочет научиться применять разные приёмы, а не просто прочитать про базовые возможности. Надеюсь что тем, кто серьёзно нацелен на применение Ванессы эта информация будет полезна. Как и информация из комментариев.
(17) Леонид, не могли бы Вы пожалуйста написать, как следовало поступить в этом случае? Явная установка паузы — это единственное решение, которое я нашёл в случае применения встроенной библиотеки шагов.
Есть ещё шаг
У этого шага есть пояснение
Согласно пояснению это подходящий для ожидания завершения обмена шаг. Но его название не соответствует тому, что от него бы потребовалось в данном случае. Поэтому показалось, что выхода два — создавать новый шаг на основе существующего (а эту тему ещё не рассматривали, она будет дальше) или применить паузу.
(19) Классно. Хотел в следующий раз на этом примере продемонстрировать, как можно сделать собственный шаг на основе существующего. Теперь знаю, что сначала лучше посмотреть на реализацию в Vanessa-Automation ))
(24)
У меня сложилось впечатление, что вы попробовали — но не получилось.
В открытых источниках информация может быть противоречивой.
Вы можете смело спрашивать, например, у меня по возможностям Ванессы и как реализовать тот или иной патерн.
(26)
Ок. Постараюсь показать на примере.
(26)
Этот шаг, как вы правильно написали, работает на стороне TestManager.
Мы его не используем, т.к. в качестве TestManager используем пустую базу, а не ERP.
У меня в сценарии используется шаг, ожидающий появления элемента:
И я нажимаю на кнопку с именем ‘СписокПриложенийВыполнитьСинхронизацию’
Тогда открылось окно ‘Синхронизация данных с*’
И я жду появления элемента с именем «ЗавершениеОбмена» в течение 100 секунд
(30) Спасибо!
(19) подскажите, пожалуйста, по использованию такого шага:
«И табличный документ формы с именем «РеквизитТабличныйДокумент» содержит строки:
| Значение1 | Значение2 |
| Значение3 | Значение4 |»
Как правильно написать проверку строки, чтобы задействовать ранее сохраненные переменные?
Хочется сохранить дату и номер документа, а потом проверить, что строка с документом есть в отчете по структуре подчиненности.
Пробовал несколько вариантов, но не смог найти как сделать.
Первый вариант:
И табличный документ «ТаблицаОтчета» содержит значения:
| ‘Перемещение товаров $НомерДокумента$ от $ДатаДокумента$’ |
Второй вариант:
И табличный документ формы с именем «ТаблицаОтчета» содержит строки:
| » | ‘Перемещение товаров $НомерДокумента$ от $ДатаДокумента$’ | » |
1. Как сменить каталог для фич, который Ванесса сама определяет по умолчанию?
2. Как удалять фичи из дерева с родителем «vanessa-add-temp.feature»?
3. Как сделать, чтобы фичи записывались в разные файлы, а не только в «vanessa-add-temp.feature»?
+ вечно сыпятся ошибки, использую версию 6.0.0:
1. При записи тест клиента с кнопки «начать запись действий пользователя» всегда выдается сообщение «04.08.2019 21:40:39 Порт 48 000 занят или находится вне указанного диапазона, порт подключения изменен на 48 001». В итоге запись действий не выполняется.
Сделал по другому:
Сначала нажимаю кнопка «Запустить тест-клиент», затем нажимаю «начать запись действий пользователя» — вроде работает, но при попытке воспроизвести тест с прикреплением файла падают ошибки:
1. в тест клиенте «ошибка записи XML»
2. В основном сеансе:
ЗавершитьЗаписьДействийПользователя:{ВнешняяОбработка.bddRunner.Форма.УправляемаяФорма.Форма(3076)}: Ошибка при вызове метода контекста (ЗавершитьЗаписьЖурналаДействийПользователя): Ошибка сетевого взаимодействия при вызове.
И еще один вопрос:
Редактирую фичу через VS, затем перезагружаю ее, но сама фича не меняется, т.е. как ее первый раз Ванесса запомнила, так вся фича и выглядит.
Открываю фича файл — там удаленные мной шаги удалены, я не сошел с ума..