<?php // Полная загрузка сервисных книжек, создан 2024-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='\
За время, прошедшее с первой публикации, появилось ещё одно новое видео по рассматриваемой теме на канале «ФТО-Проект». Рекомендую посмотреть :
Шикарная статья. Выражаю особую благодарность за подробное описание. У меня сейчас как раз проект в котором я хочу внедрить данные технологии.
(0) Огромное спасибо за две обалденные и очень полные статьи 🙂
(0)
Спасибо за статью.
Единственное что не очень — это гифки. В них нет паузы и перемотки. Не всегда удобно смотреть.
(0) подобное подключение отладки устарело и нужно редко.
я еще в версии 5.1.0 Vanessa.ADD (т.е. довольно давненько) сделал более удобный механизм отладки — абсолютно штатная 1С-отладка шагов/тестов, если файл с клиента доступен на сервере.
При следующих условиях
— шаги отлаживаются в файловой базе — самый простой и полезный кейс
— клиент и сервер 1С — это одна машина
— файлы обработок находятся в сетевой папке, доступной и на клиенте, и на сервере 1С
Теперь не нужно мучаться с отладкой шагов, как раньше 🙂
(0) Еще команда «Генератор макетов данных» очень полезна
А в новой версии еще одна полезная команда появляется — «Управление дымовыми тестами»
Спасибо! все объединили в одном месте. Добавил в избранное.
Отличный мануал! У самого бы руки никогда не дошли.
А тут прям в таком виде можно давать новым сотрудникам. Круто.
(4) Позвольте с вами не согласиться, уважаемый коллега! 😉
Размер имеет значение. Хорошая гифка на 3-5 сек в тексте намного нагляднее статичной картинки. Тут важно чувство меры.
Вопрос к Владимиру: каким инструментом гифки делаете? (интересуюсь с целью перенять опыт)
(9) Gif-анимацию записываю через LICEcap. Он умеет делать паузу (только во время записи), но я этим не пользуюсь, так как иначе время необходимое для удачной записи сильно увеличится.
Также неудобно, что он не отображает факт клика мышью. Знаю, что есть инструменты, позволяющие это делать — отображать клик отдельной анимацией. Но руки не дошли до их изучения. LICEcap просто уже давно использую и привык.
(4) Согласен, для такого материала гораздо лучше подходит видео с озвучкой. Без озвучки совсем не то, и накладные расходы на запуск виде больше чем польза от них. Но для записи качественных видеоуроков необходимы особые условия — тишина долгое время, микрофон, заливка…. пока не имею такой возможности и думаю что повторять потом этот материал в формате видео уже будет мало смысла.
(12)
Именно. Поэтому я планирую в ближайшем времени переход на автовидео инструкции.
(5) Хм, а может быть я именно эту возможность за нововведения в платформе 8.3.14 принял? ))
Заметил, что обработки, реализующие шаги по прежнему нужно открывать для их успешной отладки, но только если подключение отладчика произошло уже потом, после запуска тест-менеджера. Если же тест-менеджер запускается из конфигуратора, то в этом не было необходимости.
(13) Они же перестали работать в последних версиях платформы. С 8.3.12 точно, а кажется даже с 8.3.9. Разве нет?
Мы пытались их применять в компании. Выделение активного элемента больше не работало. Удалось частично починить — коллега вносил изменения в механизм. Но кнопки командной панели так и не получилось заставить выделяться. Смотрели как в ADD, так и в Automation.
(15)
Сама запись автовидео как работала так и работает.
Начиная с 8.3.12 нельзя определить координаты элемента на экране через win api, поэтому нельзя подсветить активный элемент на экране и подвести к элементу курсор мышки. Но эти проблемы я решаю в новых автовидео.
(10) Хотелось бы избежать горячих обсуждений «у кого лучше» ) Всё таки тема посвящена вопросам установки и интерфейсу. А ссылкой на доклад просто захотелось поделиться как на новое видео по рассматриваемой теме.
Доклад в целом хороший. А больше всего порадовало, что не только в Москве и Петербурге проводятся такие конференции. Их появление в регионах — это важно, организаторы действительно молодцы!
На канале ФТО есть еще несколько отличных видео с этой встречи. В том числе выступление Петра Грибанова по новым механизмам платформы 1С.
(16) Спасибо! Будет хорошо, если получится.
(0) Могу помочь разобраться, что не так с подстановкой шагов фич через gherkin.autocomplete в VSC
Здесь или на форуме
Кстати, всем напомню, что поддержка по продукту Vanessa.ADD оказывается
1 на нашем форуме
— (предпочтительно, т.к. история сохраняется и в разных ветках есть разные контексты)
2 и в чате-телеграме Серебряной Пули
3 или в чатах статей про Vanessa.ADD на ИС, таких, как эта статья.
(19) Продублирую описание установки и описанный здесь эффект на форум, как только появится время.
Возможно проблема в том, что на машинах, где редактирую сценарии, установлена Windows 7. Как на домашнем, так и на рабочем компьютере. Где-то читал, что с Windows 7 проблемы возникают с этим плагином. На CI-сервере где Windows Server 2016 плагин не ставил. Посмотрю поведение на нём чуть позже, может быть такой эффект наблюдаться не будет.
(15)
Можно поподробнее про эти изменения?
(22) Извиняюсь, я дезинформировал )) Сейчас узнал — «починка» заключалась в применении старой версии платформы 8.3.6 для записи видеоинструкций для нашей конфигурации )) Была попытка попробовать изменить код на Паскале, но получилось запустить конфигурацию на старой версии платформы.
(23)
Понял. Спасибо.
(20) Написав вопросы на форуме 12 дней назад так и не дождался ни одного комментария )
Поддержка платная или я что-то не то / не так спросил?
Статья хороша. А вот гифки без паузы — неудобно. Неплохим решением было бы приостанавливать гиф-анимацию при нахождении курсора на области картинки. Интересно, существуют ли такие плагины для браузеров?
(26) вот прям написали, что болело, мало опыта боялись спрашивать. Тоже с тестером работаем, там чтоли все больше для дела реализовано и мануал в одном месте а не нужно собирать по крупицам
Понимаете, этим почти всё можно оправдать, начиная от качества кода, и заканчивая отсутствием документации и/или поддержки. Я считаю это не совсем честно по отношению к коллегам. По моим наблюдениям, энтузиастов-разработчиков чаще распирает от желания показать свои наработки, обретенные знания или просто желание заявить о себе, и при этом — не учитывается потеря времени людьми, которые пытаются безуспешно овладеть этими новациями. То, что распирает — хорошо, до тех пор, пока не нарушается баланс заявлено/по факту. Давайте будем честными, очень часто, отсутствие документации или статей практического характера далеко не всегда связано с тем, что просто “руки не дошли написать”, причины чаще кроются за недостаточной проработкой темы как таковой. Вот и получается, заявляется одно, народ на волне мыкается как слепые котята, мало что получается…ну а какие проблемы, опенсорс ведь.
У вас для прохождения тестов требуется восстановление рабочей базы (вынесем за скобки её потенциально большой размер) и последующая подготовка данных. Я правильно понимаю, что в этом случае тестирование не интегрировано в процесс программирования (разработчики не могут оперативно обмениваться тестами, не могут создавать ситуации на лету, повторно запускать тесты без очистки данных), либо эта задача не кажется первостепенной ?
Давайте будем честными, очень часто, отсутствие документации или статей практического характера далеко не всегда связано с тем, что просто “руки не дошли написать”, причины чаще кроются за недостаточной проработкой темы как таковой.
Вижу недостижимый для меня уровень абстракции. Если в прошлой или этой публикации есть недостаточно проработанные темы, то напишите, пожалуйста, про них. Постараюсь раскрыть их в следующий раз. В этой публикации старался расписать всё максимально подробно. Есть ли пункт, который не получилось проработать руками по тексту статьи?
(31)
Прошу прощения, не уточнил, и совсем не хотел чтобы вы восприняли это применительно к проделанной вами работе. Моя реплика касалась выделенных выше комментариев. Хочу заострить внимание безотносительно персон и продуктов (открытых разработок не только по тестированию огромное количество), что коль сколько энтузиаст-разработчик решает показать сообществу своё решение, и делает это с упором научить других/улучшить сообщество в целом, то требования к таким проектам повышаются, и просить документацию и поддержку хотя бы на уровне входа в порог — это нормально, в противном случае, это выхолащивает немало людей, кто пытается этой темой заняться. Это не пустые слова, есть практический опыт обращений.
Нет, я даже и не думал придираться. Перефразируя коллегу выше, по форме — всё отлично, по сути — выхлоп на уровне прошлых статей. И не думайте обижаться! Вы объяснили, решили начать с начала. Продолжайте, и потом вернемся к разговору тестовых данных, применимости методологии для программистов, изменчивости состава метаданных, рефакторингу тестовых данных и сценариев, и другим интересным проверкам, например проверить что в журнале стало на одну запись больше, заведомо не зная сколько там было, прокрутить период кнопками назад до нужного значения, когда начальное не статично и определяется текущим периодом и многое-многое другое.
(33)
Могу порекомендовать хорошие инструменты Crucible+Fisheye , сейчас на Github есть файлы настроек для подсветки синтаксиса языка 1С для Crucible.
Когда-то использовал в связке с Bitbucket и настраивал только выгрузку хранилища в Bitbuket для связи с задачами в Jira и ревью в Crucible. Но в начале осени настраивал все эти продукты самостоятельно и выяснил, что для посткоммитного ревью (когда в git автоматически отправляются уже помещенные в хранилище изменения) достаточно связки Crucible+Fisheye.
Стоят дорого, но можно использовать триалки.
Здесь есть мой вопрос в сообщество со ссылками на то, что ранее использовал и хотел получить от более простой связки (один из скриншотов не открывается):
Через саппорт мне подробнее отвечали на те же вопросы, но не знаю, могу ли выкладывать эту переписку.
Не нужно воспринимать функцию «Blame» в смысле её дословного перевода. Она очень быстро даёт информацию кто автор конкретной строки, по какой задаче она в последний раз изменена, что при применении той же Jira позволяет ответить на вопрос, как лучше внести новые изменения в код и какую документацию скорректировать при необходимости.
Собственно про преимущества git наверное не буду много писать. Это всё очень просто ищется и в поисковиках и на Инфостарте. Как правило картинок больше, чем советов по настройке. Но я для настройки отдельную публикацию делал :
(34)
Спасибо за наводки )
Пользовался Blame начиная с SVN (это не фишка гита). Ничего оно мне на практике так и не дало )
Ну т.е. нафантазировать пользу я могу, но по факту на практике не помню чтоб нужно было.
Когда перелезем на EDT, эта фишка конечно будет приятным бонусом )
Спасибо, про публикации и всеобщее увлечение гитом мне известно )
Затронул эту тему только потому что интересен этот социальный феномен.
(29)
Эти накликивания имеют и обратный эффект — разубеждают тех, кто понимает о чем речь. Если статьи одна за другой демонстрируют кликеры… то складывается впечатление, что собсна BDD то никакого и нет. И доверие с каждой демонстрацией начинает падать по экспоненте. Потому что кликеры существуют со времен мамонтов. На ИТС ЕМНИП даже обработка была. А завернуть это в шаги на человечьем языке может любой падаван (на ключевые слова геркина всем вроде пофиг). Но это со времен тех же мамонтов никто не считал хорошей идеей. И сам собой возникает резонный вопрос: В чем собсна соль?
Не воспринимайте это как троллинг или холивор. Я просто честно описал свои ощущения (возможно я один такой).
Если конечная цель — кликер для прикладника, то в общем то все норм. Это можно понять и принять (мерещится что так все и делают в общем то)
Вы считаете что неофобия — это плохо? Думается неофобия — это один из самых важных скилов в современном обществе. Потому что «экспертов» и «новаторов» вокруг стало слишком много. И все обещают чудеса. И все это в 99% случаев пузыри.
А про других разработчиков… Вы же знаете историю про «величайшую победу запада в холодной войне»?
Это когда наши решили копировать IBM-360.
У нас (у русских) есть национальная забава — копировать, подражать и воровать.
Так и живем на западных идеях и технологиях.
Это повод гордиться? Да вроде нет.
Мы тупые? Похоже что да. Но это опять же не повод гордиться.
Так почему же разработчики 1С должны наступать на те же грабли, на которые этот народ наступал уже сотни раз?
ps Я не считаю что вы не правы. Я просто пытаюсь показать что все несколько сложнее. Нельзя впадать в крайность — это основной посыл
(38) Мне кажется вы не поняли о чем я писал.
Мы не с клиентом работаем, а между собой (покрываем систему тестами).
Фичи пишет тестировщик, а программер ему помогает. Вопрос был в этом.
Взаимодействие с клиентом через геркин меня вообще не интересует.
Например, сейчас пишется сценарий проверки прав, в котором уже овер 2000 шагов.
И это мы только только начинаем и пробуем.
ps В любом случае спасибо что поделились опытом
Спорное утверждение
(38) Удивительно что ваш комментарий плюсуют. Ведь он абсолютно мимо кассы. Без обид.
Сломанный телефон какой-то. Видимо мне стоит как нибудь выделить время и разобрать все по косточкам так, чтобы не было не единого шанса появляться комментам, подобным вашему.
Совершенно парадоксальное недопонимание. Прям как с синезолотым платьем.
(39) К сожалению вы не поняли зачем Геркин 🙁
Это просто с ног на голову. Тестировщик пишет тест-кейсы. А фичи пишет бизнес-аналитик по результату сбора требований. Если у вас задача обкладывать готовый функционал тестами — то используйте (как вы и делаете) соответствующие инструменты (Тестер или или всё то же Сценарное тестирование).
Геркин он из . Решается знаменитая проблема нахождения единого языка общения между бизнесом (как минимум бизнес-аналитиком, а в идеале стекйкхолдером), разработчиком и тестировщиком (three amigos):
Если у вас нет таких задач, то вам как говорится «Геркин не нужен!».
(41) Возможно не понял. А возможно не поняли вы.
Тестировщик (или аналитик) тоже не технический специалист, он тоже проверяет поведение системы с точки зрения пользователя и ему тоже нужно взаимодействовать с техническим специалистом.
Озвученная вами проблема существует между технарем и прикладником независимо от того, сотрудниками какой конторы они являются. Для исполнителя-технаря клиентом является тот, кто ставит задачу.
Ну и вообще в исходных моих вопросах вопрошалось не о философских категориях сортов тестирования, а о проблемах на поле боя, с которыми приходится сталкиваться. Этот ваш BDD никто еще не продемонстрировал ни разу. Приводимые детские примеры обсуждать желания нет (это я еще не упоминаю что даже эти приводимые примеры содержат ошибки)
Ну и в целом, товарищи, я не говорил что мне нужен геркин и BDD. Для меня комбинации из трех букв все на одно лицо.
Меня интересует тестирование как таковое. Т.е. потыкать палкой и убедиться что шевелится.
BDD можно спокойно и в упомянутом вами Тестере делать. Это вопрос вкуса. Текущая беседа — не холивар о навязываемых методиках.
ps В 1С тоже не понимают зачем геркин, когда прикручивают его к СППР?
(41)
Обкладывать тестами готовый функционал можно на чём угодно. И с помощью Геркина и без него.
(42) «Человек с молотком во всём видит гвоздь» (с)
Меня в институте учили, что для каждой специфической операции есть специальный инструмент.
Наверное, на матлабе можно сделать учётную систему. Но зачем?
Gherkin был придуман для BDD (Дэн Норт, Аслак Хилесой и иже с ними).
Пришёл Алексей Лустин и создал волну движухи «За BDD в 1С!». И на фоне этой движухи произошла подмена понятий: из языка формализации требований Gherkin стали превращать в язык автотестирования, коим он изначально не являлся и не является. Именно поэтому так тяжело идёт. Всем интересно, но как до дела — так и масса вопросов, нюансов и подводных камней. А ответов нет. А всё потому что не по назначению используется.
Поэтому если стоит вопрос обкладывания готового функционала тестами — надо решать её соответствующими инструментами (выше о них написал). И разработчикам легче в голову ложится, и поддерживать тесты проще, и методики и документация есть.
А если есть задача: отстроить проектное внедрение по Scrum — тогда User Story, Feature и Gherkin inside. С демонстрацией заказчику прироста полезной функциональности зелёными сценариями в Allure. О чём выше и написал 1ceo_2015 (за что и получил непонятые вами плюсы).
Что касается СППР и Gherkin. Сама тенденция не может не радовать. Но, насколько я знаю, если держать в голове тот факт, что разработка продукта в СППР оторвана от сценариев на Gherkin, то всё становится не так радужно. То есть в СППР 2 есть функциональная модель, по которой ведётся дальнейшая разработка, а сбоку есть некие бизнес-процессы, в узлах которых сидит турбо-геркин. То есть по сути левая рука не ведает о том, что творит правая. К сожалению, пресловутая подмена понятий перекочевала и в СППР. Методик, как применять СППР на проектах внедрения я тоже не услышал (на семинаре ERP).
По поводу Gherkin в СППР у нас с Pr-Mex идут жаркие дискуссии. Вот он кстати внизу вписался. Может дать обратную связь или поправить меня про СППР (если это не коммерческая тайна конечно же).
(44) Аминь, пусть так. Не готов вести диалог о тестировании на таком уровне (жалко времени).
Мне эти холиворы не интересны.
Скажите, а сколько вы написали тестов в формате геркин? Сколько функционала покрыли таким способом?
Поделитесь опытом
ps И да, меня в институте учили совершенно другому.
(44)
Сценарии в СППР связаны с функциональной моделью.
Также в СППР есть средства для моделирования и запуска бизнес-процессов.
Похоже, ты не очень в теме как оно там устроено )
(45) Не ради холивара. Я говорю о целесообразности в выборе инструмента. Потренироваться с Gherkin на готовом функционале — почему нет. Но ставить это на поток, на мой взгляд, неправильно идеологически.
Тесты и покрытие — это не про Gherkin . Мы не тестируем готовый функционал. А разрабатываем новый по сценариям поведения пользователей. Сейчас заканчиваем второй проект внедрения, в котором ставим цель разработки по BDD. Идеального результата нет, и ответов на все вопросы, как это делать правильно тоже нет. Поскольку применять BDD в проектах внедрения/кастомизации тиражного продукта — это тоже нетривиальное использование инструмента, заточенного под продуктовую разработку.
В цифрах: на текущем проекте сейчас — это до двадцати фич, в каждой из которых 10-20 структур сценариев, в каждой 20-30 примеров. За количеством не гонимся. Нам важно именно выстроить процесс по методике и доказать (в первую очередь себе), что так можно работать и это эффективно.
(46) Покажешь на партнёрке 😉
(47)
Слабо понял. структуры — это что? примеры — это что?
Если не затруднит, опишите как организованы сценарии. Так мы хоть вернемся в конструктивное русло и к моим исходным вопросам, т.к. вы похоже обладатель того опыта, который меня интересует.
Было бы просто замечательно, если бы вы это описали в статье, и все наконец увидели бы BDD, а не кликеры.
(49) я не успеваю писать статьи 🙁
Максимум на комментарии хватает.
Да и поскольку законченного результата (которого все требуют в качестве пруфов) пока нет, то и писать неловко.
Посмотрите в профиле мою единственную (увы) статью. Там есть примеры структур сценариев.
Ну и есть вот этот очень полезный текст (если с английским больно — вверху статьи есть ссылка на мой вольный перевод). Мы руководствуемся принципами из этой статьи.
Вот по синтаксису Gherkin хорошо расписано.
(48)
Приходи. И все кому интересна эта тема, тоже приходите.
(47)
Тут, на мой взгляд, подмена понятий происходит.
Инструментарий на геркине позволяет реализовывать в жизнь и такие и такие подходы.
И создавать сценари от верхнеуровневых требований — тогда речь про BDD.
И просто покрыть сценариями то, что уже есть. Это просто тестирование.
У вас же была на сайте статья, как вы используете BDD. Скинешь ссылку?
(44) В порядке смолтока (типа на перекуре):
Вот вы набежали в комменты и судя по всему записали меня в какой-то лагерь.
Шутка юмора в том, что я не принадлежу никакому лагерю и никакой идеологии.
Все эти ваши BDD, TDD, User Story, Геркины, Лустины, Нортоны….
Как бы вам сказать… Для меня все это шелуха. И все эти идеологические вопросы и кто по какой модной аббревиатуре работает или тестирует — все это не важно.
Я постигал программерское ремесло совершенно другим способом. И тестирование для меня — это просто искусство тыкать палкой. А базируется мое представление на том, что писал Дейкстра (и многие другие пионеры).
Возможно вы будете удивлены, но понятия «предусловие» и «постусловие» известны многим образованным людям очень давно. И вот когда эти люди всю профессиональную жизнь оперировали этими понятиями, а им начинают втирать про идеологию BDD….
Наверно не надо объяснять как глупо это выглядит со стороны? )
И я вам даже больше скажу. Мы, было дело, составляли технические задания с табличкой:
|предусловие|действие|постусловие|
Где описывался сценарий поведения юзера. Вот прям те же яйца в профиль. И это использовалось для согласования. И мы на тот момент о существовании аббревиатуры BDD и не слыхивали даже.
А все потому что:
1. Формальный подход, который позаимствовал BDD существует как минимум с 70х
2. Все, кто читает первоисточники, о нем знают уже цать лет (почти вся пионерская работа активно переводилась в союзе).
3. Самое вкусное — этот подход же совершенно очевиден. Иначе тестить и нельзя вовсе.
И вот с какого перепугу я должен перестать мыслить в исходных категориях и начать с вами тереть какие три буквы идеологически верней?
Надеюсь мне удалось показать world in my eyes ) Так будет больше взаимопонимания.
(50)
Да, я это понимаю. Мне непонятно только почему вы так усердствуете за трушный BDD, если сами не имеете подтверждения его адекватности.
То что это работает в простейших случаях никто не сомневается (вашу статью посмотрел).
Непонятно как это делать в промышленных масштабах.
Статей и примеров детских я видел уже кучу. Проблема в том, что в реальности сценарии на порядок сложнее. Разложить все на микросценарии (как в примерах) тоже не видится возможным. Писать высокоуровневые фичи кажется по ресурсам нереальным (потому как тут вовлекается на фултайм как минимум 2 человека). И т.д. и т.п. Теория звучит заманчиво, но реальность с ней чет не очень стыкуется.
Я так понимаю что кроме как в СППР, никто так и не продемонстрирует кунгфу.
(53) Да бросьте вы, какие лагеря и три буквы… 😉
Если человек мыслит в терминах:
то это наш человек ))).
Меня как раз наоборот волнует, что продукты семейства VB снизили порог вхождения в тему настолько, что кликеры и простыни интерфейсных шагов вытесняют из сознания мышление в таких терминах.
Ситуация сейчас напоминает вот эту картинку из блога Асхата Уразбаева:
Собственно, на фоне этой картинки и ситуации из меня так много текста )
(52) К пуговицам претензий нет 😉
Инструмент хороший и с каждым релизом всё хорошеет.
А статья была про то, как мы пытаемся разрабатывать по BDD, и как у нас это НЕ получается.
Про подходы написал в (55).
(55) Спасибо за развернутый ответ!
Прям ощутил вашу боль. Сам работал раньше на внедрениях и допилах типовых.
Но сейчас у меня ситуация не похожа на вашу. Тиражная разработка. Соответственно новый функционал обычно затрагивает сразу многие объекты в конфе. И даже если вообразить, что мы делаем это под конкретного юзера, то проблема все равно остается. Объем даже простейших тестов получается не маленьким. Хоть ты сквозной бизнес-процесс прогоняй в минимальном варианте, хоть россыпь мини BDDшек. Есть куча вопросов организационного и чисто технического плана. И мы пытаемся организоваться ведь не в вакууме. Есть ограничения на ресурсы, есть особенности командного состава, есть устоявшиеся практики. Хочется чтобы пакет тестов понимали все участники, чтобы можно было понимать что у нас покрыто тестами а что нет, и много других чтобы…
И вопрос использовать BDD или нет вообще не стоит. Мы решаем свою конкретную проблему в своей системе координат. Ванесса заинтересовала банально тем, что гипотетически сценарии может понять любой участник без доп. подготовки (хотя это пока вызывает сомнения). Т.е. мы смотрим только на определенные свойства инструмента, а все аббревиатуры оставляем за дверью. Нам не важно как будет называться методика (и есть ли вообще название), на рельсы которой мы встанем в итоге. Нам важно получить адекватный нашей реальности подход.
(56) Понимаю ваше негодование )
Правда есть один тонкий момент. Подобную картинку (в нашем контексте) можно понимать двояко:
1. Нарушение принципов BDD
2. Нарушение принципов тестирования как такового
Так вот 1 вариант мне безразличен. Потому что это порой смахивает на религию. Ведь убрав, например, известные ключевые слова, это перестанет быть BDD, но правильность подхода к тестированию как была так и останется. И нельзя говорить что один инструмент про BDD, а другой нет. Инструменты — они сами по себе со своими характеристиками, преимуществами и недостатками. А то, что называют BDD, это просто фантик для известной математики.
И вот теперь, когда все прояснилось, перечитайте о чем я спрашивал в самом начале (26) 🙂
(29)
Ну ок. Допустим даже кому-то это делать лень. Но после того как сценарий автоматически записан его обязательно нужно разбить на логические группы шагов. Это же как разбивать код на процедуры и функции. В 1С модно делать методы на 3000 строк. Но это же ненормально )) Сценарии тоже нужно правильно оформлять. Иначе в сценариях бардак будет. Но глядя на имеющиеся примеры мне кажется, что человеческая лень всё же часто побеждает ))
Постараюсь привести примеры на этот счёт в следующий раз.
Да, примеры больше всего хотелось бы увидеть )
Проблема заключается в том, что нет понимания как это делать. Вернее я представляю как примерно можно извращаться, но все это далеко от удобства классических модулей, процедур и функций.
Я знаю как сделать экспортный сценарий, но слабо понимаю как это использовать в большом масштабе.
Если видимость сценария определяется текущим каталогом, то я получается все тесты в какую-то пирамиду собрать должен (типа головоломка такая). Это как-то не очень стыкуется со здравым смыслом.
Модулей нет, импорта нет, процедур нет, никакой квалификации шагов нет, ничего знакомого нет. Есть одно глобальное пространство в которое свалено все со странными областями видимости. Я просто тупо не понимаю как в этой каше можно вести разработку. В итоге мы сейчас собираем одну большую портянку, а потом ее будем нарезать (если поймем как вообще это делать)
Понимаете? На один шаг вперед видно, на два вроде тоже, а вот дальше туман. Если бы геркин/ванесса была сделана как классический ЯП, то и вопросов бы не было.
Осветите, пожалуйста, подробнее эти моменты в следующей статье. Есть подозрение что я просто что-то прошлепал и не знаю чего-то важного.
(60)
Ох, следующая статья уже готова. Получилась такая, какая получилась )) Завтра вечером отправлю на модерацию. Там будет только практика на УТ 11. Три примера, начинаются с высокоуровневых шагов, затем «накликивание» на их основе, и затем переход к полноценному сценарию через объединение исходного сценария и исполняемых шагов.
Жаль, что не имеет времени на публикацию по этой теме. Действительно было бы интересно узнать об опыте длительного применения этих инструментов на обновляемых типовых конфигурациях. Прочитал его соображения по теме ниже в комментариях, очень полезная информация.
(29)
Я это делаю через специальный этап сборочной линии — «Подготовка тестовых данных». Разворачиваю тестовую базу из копии рабочей (да да из копии рабочей, потому что программисты накодили там поиск по наименованию, кое где вшиты GUID и прочий хардкод, алгоритмы зависят от кучи пользовательских данных, просто так маленькую демо базу не сделать). Затем запускаю обработку инициализации — она готовит пользователей, сбрасывает пароли. Затем стартовые сценарии — подготовка тестовых данных.
А затем выполняются полностью независимые друг от друга сценарии. Их можно выполнить по отдельности. Можно вместе. Они вообще ничего не должны знать друг о друге. Мне кажется, что такой подход правильный. Об этом пишут и специалисты по QA из других направлений. Но всё же не претендую на то что он единственно верный.
Спасибо, понял. И благодаря обсуждению начало появляться понимание почему вы так делаете.
Мне кажется сообществу при обсуждении нужно четко разграничивать два контекста:
1. Внедрения типовых с доработками
2. Собственная/тиражная разработка
Тут есть тонкая разница. В первом случае нужно согласовать и протестить конкретные вкрапления под конкретного клиента и тянуть поддержку тестов на всю конфу нереально. Во втором случае нужно согласовывать между собой и тестировать в общем случае весь функционал конфы/продукта.
Понятно что тут разные вариации могут быть. Но ключевое недопонимание в обсуждении случилось как я понял из-за этой разницы в исходных посылках.
Как говорил Маркс: «бытие определяет сознание» )
ps Пардон за капитанство. Я не очень сообразительный ) Подозреваю все это терлось уже вдоль и поперек в сообществе.
(55)
И встает вопрос — что же это за инструмент тестирования такой, который фактически вынуждает вас вместо эволюции продукта, хоронить его под вашими тестами? То есть получается, что для кода, который вы не писали, у вас не хватает сил изменить тесты, а что если вам этот код еще и писать придётся, это же еще больше сил хватать не будет! На мой взгляд проблемы, которые решает bdd важны, но уж сильно переоценены. У каждого своя статистика, но моя говорит о том, что проблемы в продуктах существенно чаще связаны с чистыми ошибками, недосмотрами, и недостаточным качеством тестирования, и совсем не часто с тем, что кто-то кого-то не понял.
По поводу покрытия готового функционала. Как раз описываемый bdd-инструментаций, по факту, и выводит тестирование уже готового функционала. Вести разработку (программирование) с такими инструментами очень сложно, начиная от перезапусков приложения и заканчивая подготовкой тестовых данных, а в тестере — этот процесс бесшовный. То, что должен делать функционал — легко описывается в комментарии, а дальше — чистый код, без особенностей поведения.
Я прочитал последнюю статью Владимира. Парни, вы всерьёз утверждаете, что овладеть технологией в состоянии простой тестировщик, что всем всё понятно, и такие шаги как “И я запоминаю значение поля с именем «Дата» как «ДатаДокумента»” не являются артефактом того, что подход протекает под реальностью?
(63)
Ну тут мужиков можно понять. Все таки если у тебя, скажем, ERP, и ты клиенту делаешь какую-то доработку точечно, то понятно поддержка тестов функционала самой ERP — это фантастика. Это затраты, которые никак не всунешь в бюджет внедрения. Просто потому что вендор не ты.
И может быть для таких точечных тестов BDD у них хорошо ложится. Но это думается будет работать только в специфических случаях, когда нет задачи написать целую подсистему учета с нуля. Т.к. эта подсистема очевидно будет сшиваться с типовым функционалом, и тесты нужны будут большие и сквозные…
(64)
Но ведь это “дано”. Это именно то, что в 90% случаев и приходится делать, и соответственно — тестировать. Не требуется покрывать своими тестами типовой функционал, достаточно иметь тесты-методы, которые будут создавать нужные данные по необходимости, и инструментарий должен легко давать возможность менять эти тесты без страха перед изменениями, ведь для этого тесты и существуют — не бояться менять/развивать функционал. И не все доработки заканчиваются добавлением новых объектов. А что если нужно тестировать измененный типовой документ, писать тест или нет? Если писать — значит получается очередное обновление (что норма) — это большая проблема восстановить работоспособность тестов.
(65)
Ну я в общем то о том же )
Моя реплика была ровно к тому, что я процитировал.
Обкладывать тестами собственный код — это одно. Тут хоть бюджет в пропорции.
А обкладывать вендорский код «который вы не писали» это для фикси черная дыра. Мало того что объем, так еще и не знаешь к чему готовиться в следующем релизе.
ps Ну или я уже вообще не соображаю, пардон
(66)
Как по мне, всё отлично вы соображаете и задаете острые вопросы, которые многие стесняются задавать.
Конечно, прийти на работу и сесть за написание тестов покрытия функционала типовой, неправильно, думаю об этом и речи ни у кого нет. Но, не писать тесты для покрытия своего функционала, которые затрагивают типовые объекты — нельзя, иначе о каком тестировании речь. Если добавляется движение в документ ПоступлениеТоваров, то проверить эту доработку без создания теста для типового ПоступлениеТоваров — нельзя. И то, что этот документ, будет меняться от релиза к релизу — это совсем не новость, не сложность, и ни что иное — как нормальная ситуация, и если инструментарий + методика к этому не готовы, или готовы настолько, чтобы не делать эти обновления, тогда нельзя говорить о продуктивном тестировании.
(66) Представьте себе торговую компанию. Работа 24/7, точки по всей России. Типовая конфигурация с доработками. Критичные операции — закупка , перемещение, заказ клиента и реализация товара.
Допустим мы доработали документ «Реализация товаров и услуг». Одновременно с ним доработка коснулась складского учета. Планируются дальнейшие доработки типовых модулей складского учета и методов модулей, которые задействованы в различных типовых механизмах.
Следует ли при этом написать хотя бы несколько функциональных тестов на процесс заказа товара клиентом, перемещения товаров и процесс поступления товаров?
Мне кажется, что в таких условиях это может оказаться столь же необходимо, насколько необходимо покрыть тестами доработанный документ «Реализация товаров и услуг». Ведь меняем мы модули, которые задействованы в нескольких механизмах.
Приводя этот пример, я имею в виду, что наиболее критичный для компании функционал можно покрыть автоматическими проверками даже в том случае, если он явно не дорабатывался. Всегда нужно исходить из потребностей предприятия, критичности процесса и стоимости такого покрытия. Ведь завтра программист может внести изменения в модуль ЗаказыКлиентСервер, например будет срочная задача от руководителя отдела продаж ))
Вот если фирма 1С сама начнёт выпускать такие тесты для типовых механизмов — вот это будет классно и решит эту проблему без дополнительных затрат.
(63) Дмитрий, совершенно верно: у каждого своя статистика. И свои проблемы (в том числе и финансовые), над решением которых мы работаем.
Нам важно НЕ слышать от заказчика фразу: «то, что вы сделали работает, но это не то, что мне нужно…», потому что после такой фразы заказчик плохо платит.
Для вас же эта антифраза, по-моему (я много читал вас на infostart), звучит так: «вы сделали то, что мне нужно, на как это всё глючит…».
Если упростить workflow разработки до вида:
1. Бизнес-анализ
2. Формализация требований
3. Разработка
4. Тестирование
то нас интересует (и в чём мы видим, прости Господи, challenge) в большей степени 1, 2 и 3. Для вас же, как мне кажется, в приоритете 3 и 4. То есть «что нужно реализовать» — у вас с этим всё чётко и понятно, осталось реализовать и протестировать. А у нас проблема понять мутного и нечёткого заказчика, вывести его на проверяемые критерии приёмки по его хотелкам, и после реализации убедиться в том, что критерии приёмки реализованы в разработанном функционале.
Соответственно мы не рассматриваем Vanessa как инструмент тестирования. Для нас это инструмент валидации реализации критериев приёмки. То что на выходе в качестве побочного эффекта мы получаем регрессионку — это бонус. Но ключевое — это показать клиенту, что то, что мы реализовали — это то, что он хотел.
То есть вот та низовая техника работы с Vanessa, которую описывает Владимир — это как бы must have, но не core feature. Человекочитаемые, основанные на примерах сценарии, ориентированные на заказчика — вот то, ради чего, на мой взгляд, стоит пользоваться Vanessa. Если это не нужно, и нет такой проблемы и задачи — то конечно надо пользоваться вашим тестером. Он намного ближе программисту и тестировщику, и те самые проблемы изменяющихся эталонных данных, обхода последствий обновления конфигурации у вас проработаны методически лучше (о чём я уже писал выше).
Можно ещё уточнить про ключевого пользователя продуктом. У нас это бизнес-аналитик. Человек не обладающий навыками программирования, но обладающий навыками формализации задачи и методическими знаниями конфигурации. В него Gherkin ляжет лучше программирования в тестере (даже вот эти фокусы с контекстом после очередного вывиха мозга как-то улягутся в извилины).
P.S.
Что до проблемы с обновлением — мы работаем над этим, это своего рода творческий процесс. Как разрабатывать, и как оформить сценарии, чтобы это было устойчиво к обновлению. Ещё пара мучительных обновлений и
я сойду с умабудет выработана какая-то методика.P.P.S.
При достаточном финансировании было бы даже интересно провести эксперимент с комбинированием использования Vanessa и Тестер на одном проекте. Чтобы на каждом этапе упрощенного workflow применялся подходящий для него инструмент.
(69)
1. Бизнес-анализ
2. Формализация требований
3. Разработка
4. Тестирование
то нас интересует (и в чём мы видим, прости Господи, challenge) в большей степени 1, 2 и 3. Для вас же, как мне кажется, в приоритете 3 и 4. То есть «что нужно реализовать» — у вас с этим всё чётко и понятно, осталось реализовать и протестировать.
Верно. Но сказать, что у нас совсем нет проблем с 1 и 2, значит солгать. Проблемы есть, но нам никогда не удавалось их успешно формализовывать. Формализовать — можно, успешно в общем смысле этого слова — нет. Можно доказать, что заказчик это и просил, и заставить его рассчитаться, но это не делает нас лучше, если мы по факту, не уловили исходную проблематику (оставим за скобками непорядочных клиентов). Поэтому, кроме, понятное дело, воспитания у себя чувства задачи, мы решили сместить проблемы такого рода в процесс разработки, чтобы развязать себе руки используя гибкие средства по тестированию, чтобы делать задачи не по принципу “не навредить”, и по принципу — как это должно быть, чтобы не бояться перекраивать код, как решения, так и тестов, ведь согласитесь, в больших проектах, значительно чаще возникает страх что-то сломать, чем изменить. Поэтому, когда функционал приклеивается тестами в силу сложности их создания/модификации, я нахожу это противоречивым самой идее тестирования.
(63)
Ошибки проектирования самые дорогие.
Реализация того, что не просил заказчик — тоже стоит дорого.
(63)
Расскажите, что вам мешает сделать «бесшовным» процесс разработки в Ванессе?
(73)
Приходит секретарша устраиваться на работу:
HR у нее спрашивает: с какой скоростью печатаете?
С: — 10 000 знаков в минуту?
HR: -ЧТО, правда???
C: — правда. Но такая херня получается…
освоить кликерство оно конечно просто. Главное тут освоить осмысленное кликерство имхо 😉
Интересен кейс когда один такой кликер уволился и вместо него посадили другого кликера. И еще произошло обновление с 2.4.2 до 2.4.7 и тесты на этом ГеркинАссемблере упали и надо понять это они упали или функционал.
Такой опыт у кого-то был?
(74)
У нас тестировщик — это ещё методолог в своей области.
Он хорошо понимает, что там происходит.
А чтобы сценарий не превращался в стену текста — существует практика кодревью.
(75) Леонид, я другой кейс уточнял. Передачу контекста между тестировщиками в случае критического обновления конфы.
Когда один тестировщик и он методолог и вечный раб компании — это идеальный вариант из идеального мира))
При запуске Vanessa Behavior не запускается запись действий пользователя, появляется ошибка «Значение не является значением объектного типа (ДопПараметры)» и еще вот это «30.01.2019 14:45:40 Не найден TestClient для подключения.»
Подскажите пожалуйста что не так?
(77) Этой информации мало, чтобы сделать какие-то предположения о причинах такого поведения.
Запись действий пользователя всё же не должна запускаться при запуске Vanessa Behavior. Она должна запускаться отдельной командой. Нужно более точно описать момент возникновения проблемы — при запуске VB или при нажатии на кнопку записи действий пользователя.
Также не помешал бы скриншот, иначе долго гадать будем.
Я только знакомлюсь с этим функционалом, и установила компоненты как показано в статье, хотела проверить все ли нормально, а тут такая ошибка… При запуске VB все нормально. Когда пытаюсь подключиться к тестовой базе появляется окно с ошибкой, а когда пытаюсь начать запись действий, то появляется сообщение.
(73) Минус походу ткнул простой тестировщик )))
Ну а вообще простой тестировщик и программирование легко осваивает.
Объективных экспериментов и сравнения (что легче) вроде никто не публиковал.
(79) Ошибка может быть как в VB, так и в тестируемом приложении. Нужен стек исключения. А лучше отладчик подключить.
Вообще окно VB выглядит странно. В нём нет информации о версии. Заголовок должен быть похож на «ver 5.6.0: Vanessa Behavior«. А у вас там написано просто Vanessa Behavior. Похоже, что либо установка некорректно прошла либо какая-то старая версия установлена.
Спасибо. Устанавливала, через 1script. Попробую еще раз установить.
Добрый день. Переустановила несколько раз, все по инструкции, но при открытии bddRunner.epf появляются два окошка и она не запускается так как нужно.
Подскажите пожалуйста что я делаю не так????
(83) (83) В публикации есть раздел
«Необходимые права на установку библиотек OneScript и настройка прав на запуск внешних обработок»
В нём описано, что необходимо сделать, чтобы избавиться от этого предупреждающего окна. Также информация есть на ИТС здесь:
Спасибо.
Коллеги, просветите: откуда название пошло Vanessa ? ))
(87) Насколько мне известно, отсюда
А когда ожидать следующую публикацию ? Очень интересно посмотреть примеры про тестирование обмена в РИБ.
(89) Ссылки на три следующие части можно найти в профиле.
(88) Уан эс са = One S ‘a = 1C
Как же я сразу не допер )
Большое спасибо за статьи, очень ценный материал.
Есть вопросы, пожелания и предложения))
1. Открыл обработку, включил УИ, записал сценарий, жму Подготовить сценарий. Вываливается ошибка о том, что папка Ц-Юзерс-итакдалееTempvanessa-add не найдена. Оказалось, что темповый файл пытается туда записать, хотя эту папку никто не создавал.
2. Есть ли какая-то библиотека знаний на эту огромную тему? Не форумы, а именно кладезь? Вопросы сыпятся на каждый прочтённый абзац и на каждую нажатую кнопку. Или всё-таки придётся лезть в конфигуратор?
3. Простой пример вопросов — у нас в разрабатываемом модуле есть версии. И эти версии выводятся в заголовок окна. Соответственно, если писать сценарий «И я открываю окно «»Обработка в.1″»», то завтра этот сценарий надо будет переписать на «И я открываю окно «»Обработка в.2″»». Есть ли возможность указывать что-то вроде «Окно, имя которого начинается на «Обработка в.»». Если нет, то как это создать?
4. По циклу статей. Автору за труд — низкий поклон. Но всё же материал довольно путанно изложен и длина текста просто нереальная. Вначале идёт пример, потом установка, потом постянные отсылки к примеру, всё это промежается геркином и настройками. В результате приходится бегать между статьями, одни абзацы пропускать, другие искать и т.п. Может разбить материалы на статьи длиной 10001 символ (иф ю ноу ват ай мин) и пронумеровать их в том порядке, в котором человек, который вообще ничего не знает по теме, мог бы, постепенно сталкиваясь с функционалом, его гармонично познавать? Заодно тогда можно было бы задавать вопросы по конкретной небольшой части, что и комментарии бы сделало полезным источником информации, где реально что-то найти. Очень не хочу обидеть автора, действительно, труд титанический. Просто конструктивное предложение, как этот труд заставить служить людям ещё более эффективно 🙂
(92)
И ещё вопрос — как сделать простой цикл проверки? Например, открывается форма, в неё грузится что-то, форма пока не доступна (у элементов через код выключена доступность), через пару секунд всё загрузилось и доступность у элементов появляется. Как можно установить примерно такой цикл:
Пока Истина Цикл
Если у элемента «Имя» доступность = Истина Тогда
Прервать
Иначе
Пауза 1
Как при этом ограничить тело цикла, чтобы следующие строки не считались (или наоборот, считались) продолжением кода в цикле и в разделе Иначе? (т.е. есть ли какой-то аналог директив КонецЦикла и КонецЕсли?)
Ещё вопрос по принципу разработки шагов.
Шаг полностью создаётся разработчиками или пользователем Ванессы или же есть какие-то служебные операторы (если тогда иначе цикл пока для каждого), и разработка шага — это только разработка проверки условия?
Например, я хочу иметь шаги
1. Если Погода = -30ИСнег Тогда
2. Пока Погода = -30ИСнег Цикл
Мне нужно разработать оба шага в описанном виде или же можно сделать шаг, который будет проверять условие Погода = -30ИСнег, а дальше я просто делаю конструкции
Если <МойШагПроПогоду> Тогда
Пока <МойШагПроПогоду> Цикл
?
(92)
Отвечаю на свой же вопрос:
3. Простой пример вопросов — у нас в разрабатываемом модуле есть версии. И эти версии выводятся в заголовок окна. Соответственно, если писать сценарий «И я открываю окно «»Обработка в.1″»», то завтра этот сценарий надо будет переписать на «И я открываю окно «»Обработка в.2″»». Есть ли возможность указывать что-то вроде «Окно, имя которого начинается на «Обработка в.»». Если нет, то как это создать?
В параметре, описывающем заголовок формы, можно использовать символы подстановки ? (любой один символ) и * (любая последовательность символов). Т.е. можно написать «Обработка в.*» или «Обработка в.2.?»