Вход | Регистрация


1С:Предприятие ::

Метки:внешние обработки

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

Я
   fez
 
14.07.04 - 15:24
Брать тут: http://1c.alterplast.ru/functest/index.html    
.
Зачем нужна эта дура: вкратце
Наши ожидания от функционала любой программы (в том числе и конфигурации 1С) можно записывать в виде, понятном для компьютера. И затем использовать эти записи для автоматической проверки сохранения программой ожидаемого функционала.
Полезно для контроля над ошибками при внесении в программу изменений.
Так же может применятся, как способ написания ТЗ.
 
  Рекламное место пустует
   fez
 
1 - 14.07.04 - 17:40
Это что, вообще никому не интересно, или просто нужно время подумать?
   Волшебник
 
2 - 14.07.04 - 17:46
Нужно время подумать. Я решил дома посмотреть в спокойной обстановке.
   Crew
 
3 - 14.07.04 - 17:52
(1)
Посмотрел. Интересно. Пока руками не потрогаю ничего не скажу.
Если бы она еще и правила тестирования сама писала ;)))

P.S. И ошибки исправляла... ;)
   fez
 
4 - 14.07.04 - 19:22
(2) Это хорошо. Подождем.
   romix
 
5 - 15.07.04 - 01:38
У Вас сами тесты хранятся в текстовичках? А как насчет хранить их в БД?
Например, в документе, который хранит
а) ТЗ с движениями/проводками
б) имя регистра
в) ссылку на тестовый документ (что тестируем).
   fez
 
6 - 15.07.04 - 09:47
(5) Мне не нравится эта идея. Поскольку в таком случае процесс "постановки на тестирование" для произвольной конфигурации резко усложняется.
   romix
 
7 - 15.07.04 - 20:11
(6) Я подумал - а ведь исходная инфа и проводки/движения, которые делает документ - все это же уже есть в самом документе... То есть можно вообще ничего нигде не хранить. Ert должен пробежаться по документам и сравнить логику "превращения" первичного документа в его проводки и движения по регистрам и счетам. У вас, в общем и целом, это так?
   fez
 
8 - 15.07.04 - 23:31
(7) Не. Кроме исходной инфы и проводок документа есть еще и наши ожидания. То, как мы хотим, чтобы было. Эти ожидания и хранятся в тесте.

Логика превращения - это собственно, тестируемый код. Как ты собираешься сравнивать проводки с кодом? :)
   romix
 
9 - 15.07.04 - 23:41
(9) Логика превращения - это либо тестируемый код, либо тест (рассмотрение одного и того же с двух противоположных сторон; код производит изменения, тест - их проверяет). Тест можно писать на любом языке. Почему бы это не сделать обрабткой 1С? Или другими средствами получается заметно проще и элегантнее?
   fez
 
10 - 15.07.04 - 23:45
(9) Я запутался. Можно пример?
 
 
   romix
 
11 - 15.07.04 - 23:53
(10)
Код (А, Б, В - реквизиты):
А=2
Б=2
В=А+Б

Тест (внешний отчет):
А=2
Б=2
Если В<>А+Б Тогда
  Сообщить("Ошибка №21");
КонецЕсли;
   Petro
12 - 16.07.04 - 08:12
А вот мне недавно пришлось перелапатить все печатные формы на предмет их влезания в лист, как тест сможет проверить влезло/не влезло :) ?
   fez
 
13 - 16.07.04 - 10:00
(11) Чушь. Если у тебя в результате сложения 2+2 получится 5 - твой тест все равно пройдет.
(12) Думаю, что никак. В перспективе (очень дальней) такие вещи можно будет сделать просто автоматически.
   romix
 
14 - 16.07.04 - 10:42
(13) Нет, при несовпадении он напишет ошибку.
   Поп Гапон
15 - 16.07.04 - 11:08
А если подойти к процессу тестирования со стороны интерфейса?

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

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

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

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

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

Дешево и сердито.
   fez
 
16 - 16.07.04 - 11:55
(14) Какую? И в коде 2+2 = 5, и в тесте 2+2 = 5. Совпадает? совпадает. Правильно? нет.
   fez
 
17 - 16.07.04 - 11:56
(15) Сделай. А я посмотрю, насколько это будет дешево.
   romix
 
18 - 16.07.04 - 15:50
(16) Ошибка и в коде, и в тесте маловероятна, т.к. программеру надо одинаково ошибиться дважды. Кроме того, тест может подставлять проверочные данные и смотреть, какой подсчитался итог.
   fez
 
19 - 16.07.04 - 15:56
(18) Ты не понял. Представь, что у тебя неправильно работает операция сложения.
   romix
 
20 - 16.07.04 - 16:10
(19) Для тестирования функций использут отдельные законченные тесты.
Кроме того, если известны исходные данные (2+2) и требуемый результат (4), то ошибка таки всплывет.
   fez
 
21 - 16.07.04 - 16:20
Вот в твоих тестах нету требуемого результата - 4.
Или я не понял, что именно ты тестируешь своим тестом?
   romix
 
22 - 16.07.04 - 16:27
То есть, я так понял, в случае вашего теста программер один раз формирует документ как надо, "фотографирует" получившиеся проводки и потом автоматически их сверяет?

Тогда это получается подстраховка на случай изменения MD (только в этом случае может что-либо измениться)... А, или еще может измениться, если проводить документы в случайном порядке... Да, тогда это интересно...
   fez
 
23 - 16.07.04 - 18:18
(22) Именно. Еще можно применять, как способ написания ТЗ.
Документ уже есть, но проводок еще никаких не создает.
Мы создали тестовых документов, и в тестах указали, какие проводки хотим видеть.
После этого программируем до тех пор, пока тесты не начнут проходить.
   romix
 
24 - 16.07.04 - 19:58
(23) Ну тогда имхо проще хранить ожидания в документах - иначе сам тест должно быть очень тяжело вводить (вбивать вручную)... В части справочников - на них же надо как-то ссылки давать? Коды и наименования ручками переписывать - тоже вроде как  не дело...
   fez
 
25 - 16.07.04 - 21:05
Ты ФанкТест не смотрел что ли вообще? Для пользователя есть интерфейс, где он и выбирает справочники/документы. А в тексте хранится ЗначениеВСтрокуВнутр().
Интерфейс, правда, немного корявый, но просто никак не дойдут руки доделать.
   romix
 
26 - 16.07.04 - 23:39
(25) Я смотрел когда-то давно старую версию - мне понравилась сама идея - сейчас пишу из кафе :-) От лишнего апа я думаю хуже она не станет :-)

Да никогда руки не дойдут. :-) Надо имхо документами такие вещи делать. Особенно хорошо я думаю это прокатит в 8.0. (одним доком можно зацепить сразу все регистры/счета).
   romix
 
27 - 16.07.04 - 23:39
(26) ух ты, звездочки дали :-)
   fez
 
28 - 17.07.04 - 14:33
(26) На итланде в форуме по восьмерке народ плачется, что инструмента нету. Сделаешь? :)
   romix
 
29 - 20.07.04 - 16:20
(28) А разве не прокатит просто док, у которого табличные части - это ожидания по движениям регистров, а в шапке указан документ, который после проведения должен выполнить эти движения/проводки? Такого рода доки могут принадлежать особому "административному" журналу, который невидим для юзеров. А ссылку подскажете?
   fez
 
31 - 20.07.04 - 16:30
http://itland.ru/forum/index.php?showtopic=3642
А восьмерку я видел весьма поверхностно, так что по конкретике реализации - это не ко мне :)
   romix
 
32 - 20.07.04 - 16:38
(31) То есть я хочу сказать в 8.0 имхо это можно сделать влегкую - почти ничего даже писать не надо... Ну только сам перебор этих административных документов и сравнение движений "подопытного" дока с табличными частями тестирующего дока (два или три вложенных цикла).
   fez
 
33 - 20.07.04 - 16:48
Ну я вчитался и понял, что пожалуй да, на восьмерке это должно быть легко. Множественные табличные части - рулят.
 
  Рекламное место пустует
   fez
 
34 - 27.07.04 - 16:30
(2) Ну как, посмотрел?
   Пролд
 
35 - 19.08.04 - 02:36
(34) Фез, сабж ветки Технология обновления типовых конфигураций  
реально написать за 50 квалифицированных человеко-часов?
Т.е. в реальное время?
   fez
 
36 - 19.08.04 - 11:53
Повторюсь здесь. Эту задачу за это время я бы не взялся делать.
Скорее всего, если сначала подумать, чего именно мы хотим тестировать - то получится как-то использовать уже существующие технологии (тот же FuncTest), а если их не хватит, то доработки вполне могут влезть в указанные временнЫе рамки.
   Wasya
 
37 - 19.08.04 - 12:02
Поделюсь пока небольшим опытом внедрения FuncTest.
В первую очередь, внедрил автоматическое тестирование модулей проведения. Все работает нормально. Затраты на поддержание тестов в актуальном состоянии небольшие. Одна беда писать модули проведения легко и одно удовольствие. Данные уже готовы и структурированы. Участие в этом процессе вредных пользователей минимально. По моим оценкам затраты на написание и исправление модулей проведения заметно меньше 10%.
Во вторую очередь тестировал отчеты. По условиям функционирования FuncTest, надо было адаптировать отчет под автоматическое тестирование. Это конечно не очень нравиться. Вот где пожалел, что в 7.7 нет препроцессорных команд. Не нравится и способ передачи таблицы результатов из отчета в FuncTest, но тут уж на то воля автора. В отчете у меня была уж очень хитрая ошибка (а если кодер грамотный, то только такие и могут быть) пришлось помучиться с моделированием ошибочной ситуации в тестовой базе.
В данный момент пытаюсь тестировать процедуры глобального модуля. Принцип такой создал внешнюю обработку, которая принимает от FuncTest задание и вызывает процедуру глобального модуля. Результаты в виде таблицы значений передает обратно в FuncTest. На написание обработки, заполнение тестовой базы данными ушло два часа. Баг исправлялся 5 минут. Причем если бы я не использовал автоматическое тестирование, время на исправление бага было бы таким же. Обидно, что может к этой процедуре я больше никогда и не вернусь и соответственно затраты на автоматическое тестирование ушли впустую.
Какие предварительные выводы у меня получились? Область применения FuncTest жестко ограничена. Можно тестировать все – что не изменяет данных. БД до тестирования и после тестирования должна оставаться неизменной. Затраты времени (соответственно рублей) на разработку заметно увеличиваются.
Это пассив, а что в активе? Чего больше всего боится программист, после обновления конфигурации? Что перестанет работать то - что работало. Примеры из жизни:
Надо было немного переделать печатную форму документа. Само исправление заняло немного времени, но попутно решил провести рефакторинг – чуть-чуть оптимизировать код. Сделал это не аккуратно. В результате менеджеры целый день выдавали документы с ошибкой. Менеджеры уже привыкли, что проблем у них никаких и тщательно не проверяли, что у них печатается. Да и ошибка проявлялась не всегда и была малозаметной (итоговые суммы были правильными). Ошибка обнаружилась только в конце дня.
Второй пример крупнее. Одна довольно крупная фирма по продаже компьютеров в течение дня не могла принимать заявки у корпоративных покупателей из-за проблем с 1С после обновления.
Получается что выгода от внедрения автоматического тестирования не в уменьшении времени на разработку и ни в улучшении качества программы, а в уменьшении потерь предприятия от ошибок в программе. Попутно мы частично снимаем с пользователей функцию вечного бета-тестера экспериментов программиста.
   fez
 
38 - 19.08.04 - 12:20
(37) "Не нравится и способ передачи таблицы результатов из отчета в FuncTest, но тут уж на то воля автора"
Мне самому она не очень нравится. Так что если напишешь по-другому - приму с благодарностью.

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

"Можно тестировать все – что не изменяет данных. БД до тестирования и после тестирования должна оставаться неизменной"
Вот этого я не понял. Что именно ты имеешь в виду? Ввод документов на основании? Обработки?
   fez
 
39 - 19.08.04 - 12:23
(38+) Вот еще чего забыл. На страничке http://1c.alterplast.ru/functest/reports.html открылся сбор отзывов пользователей. Твой отзыв можно туда тоже добавить?
   Wasya
 
40 - 19.08.04 - 12:26
Скажем у меня есть обработки, которые автоматически формируют документы. Как я понимаю, чтобы их тестировать надо иметь начальную тестовую базу. В ней запускаем обработку. Получилась база с добавленными документами. и ее надо сравнить с эталонной (ожидаемой)базой.
   Wasya
 
41 - 19.08.04 - 12:28
добавляй.
   fez
 
42 - 19.08.04 - 12:36
(40) Раздели обработку на две части. Первая часть будет формировать табличные части документов в виде ТаблицыЗначений. Вторая часть будет создавать документы и говорить ЗагрузитьТабличнуюЧасть().
Тогда можно будет проверять только первую часть, забив на вторую (в силу ее примитивности).
   21
43 - 19.08.04 - 12:37
то же, но для 8, пожалуйста
   fez
 
44 - 19.08.04 - 12:41
(41) Готово.
   fez
 
45 - 19.08.04 - 12:42
(43) 500 баксов.
   fez
 
46 - 19.08.04 - 12:43
(45+) И условия лицензирования - GPL.
   Волшебник
 
47 - 24.08.04 - 00:27
Разработка критериев анализа систем автоматизации тестирования

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

http://www.citforum.ru/SE/testing/pankratov/criterion/
   Денок
48 - 18.01.05 - 12:04
Большое спасибо очень помогли. А то ручками уже ......



Список тем форума
Рекламное место пустует   Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Ветка сдана в архив. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует