Автоматическое тестирование функционала конфигураций 1С #6494

Брать тут:     . Зачем нужна эта дура: вкратце Наши ожидания от функционала любой программы (в том числе и конфигурации 1С) можно записывать в виде, понятном для компьютера. И затем использовать эти записи для автоматической проверки сохранения программой ожидаемого функционала. Полезно для контроля над ошибками при внесении в программу изменений. Так же может применятся, как способ написания ТЗ.

Это что, вообще никому не интересно, или просто нужно время подумать?

Нужно время подумать. Я решил дома посмотреть в спокойной обстановке.

Посмотрел. Интересно. Пока руками не потрогаю ничего не скажу. Если бы она еще и правила тестирования сама писала ;))) P.S. И ошибки исправляла... ;)

Это хорошо. Подождем.

У Вас сами тесты хранятся в текстовичках? А как насчет хранить их в БД? Например, в документе, который хранит а) ТЗ с движениями/проводками б) имя регистра в) ссылку на тестовый документ (что тестируем).

Мне не нравится эта идея. Поскольку в таком случае процесс "постановки на тестирование" для произвольной конфигурации резко усложняется.

Я подумал - а ведь исходная инфа и проводки/движения, которые делает документ - все это же уже есть в самом документе... То есть можно вообще ничего нигде не хранить. Ert должен пробежаться по документам и сравнить логику "превращения" первичного документа в его проводки и движения по регистрам и счетам. У вас, в общем и целом, это так?

Не. Кроме исходной инфы и проводок документа есть еще и наши ожидания. То, как мы хотим, чтобы было. Эти ожидания и хранятся в тесте. Логика превращения - это собственно, тестируемый код. Как ты собираешься сравнивать проводки с кодом? :)

Логика превращения - это либо тестируемый код, либо тест (рассмотрение одного и того же с двух противоположных сторон; код производит изменения, тест - их проверяет). Тест можно писать на любом языке. Почему бы это не сделать обрабткой 1С? Или другими средствами получается заметно проще и элегантнее?

Я запутался. Можно пример?

Код (А, Б, В - реквизиты): А=2 Б=2 В=А+Б Тест (внешний отчет): А=2 Б=2

А вот мне недавно пришлось перелапатить все печатные формы на предмет их влезания в лист, как тест сможет проверить влезло/не влезло :) ?

Чушь. Если у тебя в результате сложения 2+2 получится 5 - твой тест все равно пройдет. Думаю, что никак. В перспективе (очень дальней) такие вещи можно будет сделать просто автоматически.

Нет, при несовпадении он напишет ошибку.

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

Какую? И в коде 2+2 = 5, и в тесте 2+2 = 5. Совпадает? совпадает. Правильно? нет.

Сделай. А я посмотрю, насколько это будет дешево.

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

Ты не понял. Представь, что у тебя неправильно работает операция сложения.

Для тестирования функций использут отдельные законченные тесты. Кроме того, если известны исходные данные (2+2) и требуемый результат , то ошибка таки всплывет.

Вот в твоих тестах нету требуемого результата - 4. Или я не понял, что именно ты тестируешь своим тестом?

То есть, я так понял, в случае вашего теста программер один раз формирует документ как надо, "фотографирует" получившиеся проводки и потом автоматически их сверяет? Тогда это получается подстраховка на случай изменения MD (только в этом случае может что-либо измениться)... А, или еще может измениться, если проводить документы в случайном порядке... Да, тогда это интересно...

Именно. Еще можно применять, как способ написания ТЗ. Документ уже есть, но проводок еще никаких не создает. Мы создали тестовых документов, и в тестах указали, какие проводки хотим видеть. После этого программируем до тех пор, пока тесты не начнут проходить.

Ну тогда имхо проще хранить ожидания в документах - иначе сам тест должно быть очень тяжело вводить (вбивать вручную)... В части справочников - на них же надо как-то ссылки давать? Коды и наименования ручками переписывать - тоже вроде как  не дело...

Ты ФанкТест не смотрел что ли вообще? Для пользователя есть интерфейс, где он и выбирает справочники/документы. А в тексте хранится ЗначениеВСтрокуВнутр. Интерфейс, правда, немного корявый, но просто никак не дойдут руки доделать.

Я смотрел когда-то давно старую версию - мне понравилась сама идея - сейчас пишу из кафе :-) От лишнего апа я думаю хуже она не станет :-) Да никогда руки не дойдут. :-) Надо имхо документами такие вещи делать. Особенно хорошо я думаю это прокатит в 8.0. (одним доком можно зацепить сразу все регистры/счета).

ух ты, звездочки дали :-)

На итланде в форуме по восьмерке народ плачется, что инструмента нету. Сделаешь? :)

А разве не прокатит просто док, у которого табличные части - это ожидания по движениям регистров, а в шапке указан документ, который после проведения должен выполнить эти движения/проводки? Такого рода доки могут принадлежать особому "административному" журналу, который невидим для юзеров. А ссылку подскажете?

А восьмерку я видел весьма поверхностно, так что по конкретике реализации - это не ко мне :)

То есть я хочу сказать в 8.0 имхо это можно сделать влегкую - почти ничего даже писать не надо... Ну только сам перебор этих административных документов и сравнение движений "подопытного" дока с табличными частями тестирующего дока (два или три вложенных цикла).

Ну я вчитался и понял, что пожалуй да, на восьмерке это должно быть легко. Множественные табличные части - рулят.

Ну как, посмотрел?

Фез, сабж ветки   реально написать за 50 квалифицированных человеко-часов? Т.е. в реальное время?

Повторюсь здесь. Эту задачу за это время я бы не взялся делать. Скорее всего, если сначала подумать, чего именно мы хотим тестировать - то получится как-то использовать уже существующие технологии (тот же FuncTest), а если их не хватит, то доработки вполне могут влезть в указанные временнЫе рамки.

Поделюсь пока небольшим опытом внедрения FuncTest. В первую очередь, внедрил автоматическое тестирование модулей проведения. Все работает нормально. Затраты на поддержание тестов в актуальном состоянии небольшие. Одна беда писать модули проведения легко и одно удовольствие. Данные уже готовы и структурированы. Участие в этом процессе вредных пользователей минимально. По моим оценкам затраты на написание и исправление модулей проведения заметно меньше 10%. Во вторую очередь тестировал отчеты. По условиям функционирования FuncTest, надо было адаптировать отчет под автоматическое тестирование. Это конечно не очень нравиться. Вот где пожалел, что в 7.7 нет препроцессорных команд. Не нравится и способ передачи таблицы результатов из отчета в FuncTest, но тут уж на то воля автора. В отчете у меня была уж очень хитрая ошибка (а если кодер грамотный, то только такие и могут быть) пришлось помучиться с моделированием ошибочной ситуации в тестовой базе. В данный момент пытаюсь тестировать процедуры глобального модуля. Принцип такой создал внешнюю обработку, которая принимает от FuncTest задание и вызывает процедуру глобального модуля. Результаты в виде таблицы значений передает обратно в FuncTest. На написание обработки, заполнение тестовой базы данными ушло два часа. Баг исправлялся 5 минут. Причем если бы я не использовал автоматическое тестирование, время на исправление бага было бы таким же. Обидно, что может к этой процедуре я больше никогда и не вернусь и соответственно затраты на автоматическое тестирование ушли впустую. Какие предварительные выводы у меня получились? Область применения FuncTest жестко ограничена. Можно тестировать все – что не изменяет данных. БД до тестирования и после тестирования должна оставаться неизменной. Затраты времени (соответственно рублей) на разработку заметно увеличиваются. Это пассив, а что в активе? Чего больше всего боится программист, после обновления конфигурации? Что перестанет работать то - что работало. Примеры из жизни: Надо было немного переделать печатную форму документа. Само исправление заняло немного времени, но попутно решил провести рефакторинг – чуть-чуть оптимизировать код. Сделал это не аккуратно. В результате менеджеры целый день выдавали документы с ошибкой. Менеджеры уже привыкли, что проблем у них никаких и тщательно не проверяли, что у них печатается. Да и ошибка проявлялась не всегда и была малозаметной (итоговые суммы были правильными). Ошибка обнаружилась только в конце дня. Второй пример крупнее. Одна довольно крупная фирма по продаже компьютеров в течение дня не могла принимать заявки у корпоративных покупателей из-за проблем с 1С после обновления. Получается что выгода от внедрения автоматического тестирования не в уменьшении времени на разработку и ни в улучшении качества программы, а в уменьшении потерь предприятия от ошибок в программе. Попутно мы частично снимаем с пользователей функцию вечного бета-тестера экспериментов программиста.

"Не нравится и способ передачи таблицы результатов из отчета в FuncTest, но тут уж на то воля автора" Мне самому она не очень нравится. Так что если напишешь по-другому - приму с благодарностью. "Обидно, что может к этой процедуре я больше никогда и не вернусь и соответственно затраты на автоматическое тестирование ушли впустую." Вспомни об этих словах через год. Ты поймешь, как ты был не прав. Даже если один какой-то тест никогда больше и не сломается - общая масса тестов вселяет в разработчика все бОльшую и бОльшую уверенность. Это действительно сильный эффект. "Можно тестировать все – что не изменяет данных. БД до тестирования и после тестирования должна оставаться неизменной" Вот этого я не понял. Что именно ты имеешь в виду? Ввод документов на основании? Обработки?

(38+) Вот еще чего забыл. На страничке открылся сбор отзывов пользователей. Твой отзыв можно туда тоже добавить?

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

добавляй.

Раздели обработку на две части. Первая часть будет формировать табличные части документов в виде ТаблицыЗначений. Вторая часть будет создавать документы и говорить ЗагрузитьТабличнуюЧасть. Тогда можно будет проверять только первую часть, забив на вторую (в силу ее примитивности).

то же, но для 8, пожалуйста

Готово.

500 баксов.

(45+) И условия лицензирования - GPL.

Разработка критериев анализа систем автоматизации тестирования 1. Поддерживаемые процессы тестирования. 2. Поддерживаемые типы тестов. 3. Поддерживаемые технологии. 4. Интеграция с системами разработки. 5. Техническая и документальная поддержка компанией разработчиком. 6. Обучение и сертификация персонала, работающего с набором инструментов и/или методологией. 7. Представительство компании-разработчика в странах ближнего зарубежья. /

Большое спасибо очень помогли. А то ручками уже ......