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

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

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

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

P.S. И ошибки исправляла... ;)

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

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

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

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

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

Логика превращения - это собственно, тестируемый код. Как ты собираешься сравнивать проводки с кодом? :)

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

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

(10)
Код (А, Б, В - реквизиты):
А=2
Б=2
В=А+Б

Тест (внешний отчет):
А=2
Б=2
Если В<>А+Б Тогда
 Сообщить("Ошибка №21");
КонецЕсли;

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

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

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

А если подойти к процессу тестирования со стороны интерфейса?

Тесты хранятся в виде записей последовательности действий (выбор пунктов меню, активизация реквизитов, ввод текста, нажатие на кнопки) по созданию тестовой базы.

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

Тест представляется списком действий, описываемых в читабельном варианте.

Допустим изменили конфигурацию.
Взяли тесты к ней, расставили точки останова, запустили тест на автомате (тут сразу и скорость выполнения теста можно увидеть, причем в разных условиях).

На точке останова, посмотрели детальное выполнение, если надо, часть действий переделали (ну допустим интерфейс изменился).

Дешево и сердито.

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

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

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

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

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

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

То есть, я так понял, в случае вашего теста программер один раз формирует документ как надо, "фотографирует" получившиеся проводки и потом автоматически их сверяет?

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

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

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

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

(25) Я смотрел когда-то давно старую версию - мне понравилась сама идея - сейчас пишу из кафе :-) От лишнего апа я думаю хуже она не станет :-)

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

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

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

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

http://itland.ru/forum/index.php?showtopic=3642
А восьмерку я видел весьма поверхностно, так что по конкретике реализации - это не ко мне :)

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

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

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

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

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

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

(37) "Не нравится и способ передачи таблицы результатов из отчета в FuncTest, но тут уж на то воля автора"
Мне самому она не очень нравится. Так что если напишешь по-другому - приму с благодарностью.

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

"Можно тестировать все – что не изменяет данных. БД до тестирования и после тестирования должна оставаться неизменной"
Вот этого я не понял. Что именно ты имеешь в виду? Ввод документов на основании? Обработки?

(38+) Вот еще чего забыл. На страничке http://1c.alterplast.ru/functest/reports.html открылся сбор отзывов пользователей. Твой отзыв можно туда тоже добавить?

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

добавляй.

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

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

(41) Готово.

(43) 500 баксов.

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

Разработка критериев анализа систем автоматизации тестирования

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

http://www.citforum.ru/SE/testing/pankratov/criterion/

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