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


1С:Предприятие :: 1С:Предприятие 8 общая

А вы уверены что ваш код работает?

А вы уверены что ваш код работает?
Я
   like
 
14.06.18 - 10:48
Коллеги, как вы решаете вопрос с тестированием своего кода? Вы уверены, что ваш код отрабатывает так как вы планировали?
Представим себе ситуацию, что вы дорабатываете, что то сложнее чем внешний отчет в erp.
Вот вы написали код и вроде бы все должно быть прекрасно. Что делать дальше? Надо бы запустить наш прекрасный код на выполнение.
Тут возникает примерно такой вот диалог
(в) На чем тестить?
(о) на данных))))
(в) На каких?
(о) давай возьмем у заказчика
(в) у нас 20 разработчиков, которые «пилят различный функционал» существующая база заказчика весит 500гб. Думаю все понимают что это не вариант…

Дальнейшее развитие выглядит примерно так: заполняем тестовую базу какими то далекими от реальности данными (очень часто разработчики не полностью владеют предметной областью) и как то тестим. При этом при каждой маленькой ошибочке, на действительно больших конфигурациях, ждем по 30 минут после каждого F7. И после всего этого после передачи заказчику оказывается что на их данных все отваливается и уже устойчивая мысль, что при каждом обновлении  конфигурации все ломается, крепчает у заказчиков еще больше.

Это, как любят писать в англоязычных форумах, не делает нас счастливее.
Из всего выше сказанного вопрос: «как вы решаете эту проблему?»
 
 
   dezss
 
1 - 14.06.18 - 10:50
тестировать хотя бы на данных сопоставимых размеров...
   VladZ
 
2 - 14.06.18 - 10:50
1. Код должен тестироваться на данных заказчика.
2. Заказчик должен обеспечить разработчика нужными данными.
3. У разработчика должна быть техническая возможность эти данные разместить у себя. Либо заказчик предоставляет ресурсы для тестирования.
   lodger
 
3 - 14.06.18 - 10:51
можно(или нужно?) тратить отдельное время на написание автотестов, которые имитируют деятельность пользователя, в том числе ввод данных.
   Вафель
 
4 - 14.06.18 - 10:52
Нужно различать тестирование алгоритмов и тестирование производительности
   shuhard
 
5 - 14.06.18 - 10:53
(0) [ Вы уверены, что ваш код отрабатывает так как вы планировали] да
[заполняем тестовую базу какими то далекими от реальности данными] тестируем на копии продуктива по согласованному сквозному контрольному примеру с параллельным выполнением на эталонной копии, всякое расхождение документируем и изъясняем
   VS-1976
 
6 - 14.06.18 - 10:53
(0) 1-е правило чтобы упростить код и уменьшить стоимость поддержки, данные должны быть введены всегда в правильном формате.
2. Как и сказали выше данные должны быть. Часто для выявления нюансов не напишешь код, который будет адекватно отрабатывать при различных входящих данных
   spectre1978
 
7 - 14.06.18 - 10:53
(0) Гы, как по этой жизни можно быть в чем-то уверенным? Я не уверен в том что доживу до вечера - может инсульт, может машина собьет. Вероятность такого события не велика, но она есть. А вы про какой-то код :))
   Остап Сулейманович
 
8 - 14.06.18 - 10:53
(0) "устойчивая мысль, что при каждом обновлении  конфигурации все ломается, крепчает у заказчиков еще больше."
Такая СеЛяВа. И это нужно донести до заказчика. Или заказчик должен оплатить качественное тестирование. А это ~ 70% от общей стоимости. И тогда тестируйте по полной.
   olegves
 
9 - 14.06.18 - 10:53
(2) +100500
   shuhard
 
10 - 14.06.18 - 10:55
(0)[И после всего этого после передачи заказчику оказывается что на их данных все отваливается и уже устойчивая мысль, что при каждом обновлении  конфигурации все ломается, крепчает у заказчиков еще больше. ]
очередной ЦКП ждёт смена начальника отдела, это нормально
 
 Рекламное место пустует
   Вафель
 
11 - 14.06.18 - 10:55
Ну и вообще желательно писать код так чтобы можно было тестировать модульно, каждую функцию отдельно
   olegves
 
12 - 14.06.18 - 10:55
(8) кто не содержит собственную армию - тот содержит чужую (с)
   VladZ
 
13 - 14.06.18 - 10:56
(3) Я бы не стал. А потом встанет вопрос: а кто будет тестировать программу для тестирования?

Лучше уж пусть человек сядет и потычет.
   Вафель
 
14 - 14.06.18 - 11:00
(8) нужно регрисионные тесты просто делать,тогда ломаться будет на пару порядокв меньше
   like
 
15 - 14.06.18 - 11:01
Вау, как быстро....
Давайте уточню, про производительность не шла речь, это отдельный вопрос, при котором на тестирование на "реальных данных" обязательное условие - ИМХО
   Остап Сулейманович
 
16 - 14.06.18 - 11:05
(14) Тест - это просто тест. Любой. Хоть даже и регрессионный (правда я не понял к чему оно((( ). Оно от "поломок" не защитит. Тест поможет выявить логическую ошибку.
Но! Как сказал ТС - только на конкретном наборе тестовых данных. Отсутствие ошибок на одном наборе абсолютно не означает их отсутствие на другом наборе.
Вот ТС и пытается понять - какое количество наборов нужно для более менее достоверного тестирования. И кто эти наборы будет готовить.
Как то так.
   МихаилМ
 
17 - 14.06.18 - 11:06
база 500 гб - можно каждому разрабу позволить присовременых ценах на хдд.
   like
 
18 - 14.06.18 - 11:06
(16) Именно, спасибо вам
   like
 
19 - 14.06.18 - 11:07
(17) Это больше похоже на мечты, потому что таких проектов может быть больше одного
   Джинн
 
20 - 14.06.18 - 11:08
Что за тупой вопрос? Моделируется ситуация и тестируется. С вводом данных. По возможности применяю метод, принятый в ВВС США - модель должна быть такая, что проверяются все существующие ветки алгоритма.
   like
 
21 - 14.06.18 - 11:08
(16) И еще дополнение как эти наборы будут создаваться, ввиду того что в платформе слой данных не отделен от слоя логики
   like
 
22 - 14.06.18 - 11:08
(20) Вы часто это делаете?
   shuhard
 
23 - 14.06.18 - 11:11
(21)[ввиду того что в платформе слой данных не отделен от слоя логики]
очевидный бред
   ptiz
 
24 - 14.06.18 - 11:13
(19) Без копии реальной базы, пускай не с последними данными - никуда. Раз в неделю восстанавливать копию рабочей, накатывать на неё все наработки, на ней и тестировать. Если не каждому разрабу, то по копии на каждые 5 человек. Ненужные данные ради уменьшения объема можно и прямыми запросами удалить.
   like
 
25 - 14.06.18 - 11:13
(23) Правда?? Я аргументирую, невозможно создать и записать объект предметной области в имитацию бд (речь про бд в памяти)
   like
 
26 - 14.06.18 - 11:15
(24) Ну то есть в течении недели вы не совсем понимаете можете ли вы выпустить релиз сейчас или нет? Это не упрек, я правда пытаюсь понять как обстоят дела у "других"
   Вафель
 
27 - 14.06.18 - 11:15
(16) тестиирование не защищает на 100%, а уменьшает количество ошибок
   Вафель
 
28 - 14.06.18 - 11:16
(20) Это называется 100% покрытие кода тестами
   Mort
 
29 - 14.06.18 - 11:17
80% кода будут работать если ты просто один раз взял, запустил и оно работает.

Сложные участки кода надо включить голову и проанализировать на ошибки. Иногда код стоит переписать, если в комнате порядок, тараканам будет негда прятатья.

Тестирование вскрывает только очевидные косяки.
   like
 
30 - 14.06.18 - 11:17
(27) бесспорно, но мне кажется мы все таки удаляемся от основного вопроса, он звучит так: "Как вы тестируете свой код"
   BeerHelpsMeWin
 
31 - 14.06.18 - 11:18
А можно узнать, что это за контора, где есть 20 разработчиков, но нет возможности развернуть тестовую, пусть и 500гб базу заказчика? И зачем вы беретесь за такие проекты?
   ptiz
 
32 - 14.06.18 - 11:18
(26) А зачем обновляться чаще раза в неделю? Что за жареный петух вас клюет? Или "хренась-хренась и в продакшен"?
Имхо, если 20 человек пилят одну базу - частые обновления приведут к хаосу. Должно быть время на "вылизывание" релиза перед накатыванием в рабочую базу.
   Вафель
 
33 - 14.06.18 - 11:18
(30) лично я пишу тесты
 
 
   like
 
34 - 14.06.18 - 11:19
(29) В моем понимании тестирование это набор "шишок" которые мы набили ранее и будем стараться не допускать в будущем, увы память (человечекая) для хранения всех этих "шишок" с моей точки зрения для этого не подходит
   Вафель
 
35 - 14.06.18 - 11:19
   Diman000
 
36 - 14.06.18 - 11:20
Если ситуация сложная, то как тестировать надо думать заранее.
И почему это базу в 500 Гб дублировать для целей тестирования это не вариант?
У меня, например, есть такой вариант построения тестового контура.
Одна база является полной копией рабочей, каждую ночь копируется. Это для всяких экспериментов над продуктивом и реальными данными, для воспроизведения ошибок в продуктиве и все такое.
Вторая база также каждую ночь поднимается из рабочей, а утром в нее накатывают конфигурацию из хранилища разработки. Это получается база для тестирования алгоритмов разработки на актуальных данных.
В третью базу тоже ежедневно загружается конфигурация разработки, то актуальными данными она автоматически не обновляется, только по запросу. Это чтобы долговременные тестовые примеры не затирались.

И да, рабочая база у нас как раз 500гб. Но вот ее тестовые копии 100-150, потому как из них версии удаляем и саму базу сжимаем.
У каждого программиста база с данными и по запросу она актуализируется свежей копией.
   like
 
37 - 14.06.18 - 11:20
(32) Этого жаренного петуха обычно называют критический релиз
   Вафель
 
38 - 14.06.18 - 11:20
Ну и вооще континуус интегрэйшн придумали уже давно
   zak555
 
39 - 14.06.18 - 11:20
> Думаю все понимают что это не вариант… 

почему не вариант ?
   фросия
 
40 - 14.06.18 - 11:21
есть такая профессия: тестировщик
   Вафель
 
41 - 14.06.18 - 11:22
(40) у вас тестировщик тесты пишет или ручками прокликивает?
   очко
 
42 - 14.06.18 - 11:24
(35) А ты можешь видос записать и на ютуб выложить как ты это делаешь?
   Mort
 
43 - 14.06.18 - 11:24
(34) Тестирование это хорошо, когда помещаешь релиз и вдруг оказывается, что форма заказа тупо не открывается - тупо две команды написали противоречащий код.
Правило Паретто, 20% усилий дают 80% результата. Тестирование вот и должно давать 80% результата за мелкие усилия. Простая обработка которая прогонит важные формы и объекты. Гнаться за 100%, называя это покрытием кода или ещё какой глупостью, имхо, не надо. Надо усилия в другом месте приложить - толку будет больше.
   shuhard
 
44 - 14.06.18 - 11:27
(25) [невозможно создать и записать объект предметной области в имитацию бд (речь про бд в памяти)]
начните с азов, отличия неймановской и принстонской архитектур
   Numerus Mikhail
 
45 - 14.06.18 - 11:27
(0) выпускаем отраслевое решение для 50+ филиалов по России
Есть копии почти всех баз.
После разработки тестируется на нескольких самых больших базах. Раз в 3 месяца выпускается бета релиз, регионы уже сами тестируют, если хотят. После этого выпускается нормальный релиз.
   фросия
 
46 - 14.06.18 - 11:28
(41) я не знаю ни одного тестировщика, пожтому не могу сказать как они работают
   Mort
 
47 - 14.06.18 - 11:29
Конечно, тестирование в последнее время используют в качестве формализации задачи на мид- и микро- уровне. Даже название дали "TDD". Код, который, написан под формализованной задачей в виде проходимого теста качественее, чем код написанный от балды по ТЗ без цели, это да. А к тестированию в классическом пониманию как к проверке готового продукта это мало имеет отношения имхо.
   очко
 
48 - 14.06.18 - 11:31
А кто-нибудь юзал 1С:Сценарное тестирование?
   ildary
 
49 - 14.06.18 - 11:41
(42) я бы тоже посмотрел такое видео, т.к. хочется освоить автотесты, надоело руками тестировать.
 
 Рекламное место пустует
   like
 
50 - 14.06.18 - 11:43
(48) юзали, очень не удобно, не надёжные в плане выполнения, отваливаются по не понятным причинам, спасает перезапуск
   like
 
51 - 14.06.18 - 11:45
А кто нибудь реально юнит тестами пользовался? Интересует вопрос с большими запросами, опять таки где и как хранить тестовые наборы
   like
 
52 - 14.06.18 - 11:48
(45) спасибо, ознакомился
   Cyberhawk
 
53 - 14.06.18 - 11:48
Иногда настраиваю автоматическую миграцию данных из рабочей инфобазы (или ее копии) в ЦТБ (центральную тестовую базу)
   Cyberhawk
 
54 - 14.06.18 - 11:48
Это закрывает вопрос об имении актуальных реальных данных у разработчиков
   Cyberhawk
 
55 - 14.06.18 - 11:49
И это явно более выгодный вариант, чем делать копию рабочей и на нее накатывать изменения из текущего хранилища" разработки
   Aleksey
 
56 - 14.06.18 - 12:02
Даже 1с не позволяет себе на 100% тестировать свой продукт.
   Aleksey
 
57 - 14.06.18 - 12:08
А так у 1с есть статья по этому поводу. Она рекомендует по мимо рабочего сервера (сервер заказчика с реальными данными) иметь еще 3 промежуточных сервера: сервер разработчика (с тестовыми данными), сервер тестирования (тестовые данные) и подготовительный сервер (с пользовательскими данными). Т.е. не нужно каждому разработчику давать реальную базу

Источник https://its.1c.ru/db/metod8dev#content:5905:hdoc
   4St
 
58 - 14.06.18 - 12:11
(51) Тестовые наборы можно готовить через xUnitFor1C
https://github.com/xDrivenDevelopment/xUnitFor1C/wiki/Тестирование-через-образец-исходных-данных
Пользуемся иногда. Вполне себе работающий механизм.
А против (43) еще помогает практика code review. Прямо сильно помогает.
   shuhard
 
59 - 14.06.18 - 12:12
(57) великое открытие на 30 году существования вендора
dev
uat
test
   Aleksey
 
60 - 14.06.18 - 12:28
(59) Зная код типовых и как иногда 1с относиться к своим же рекомендациям, то сдается мне что знание и использование это разные вещи
   Вафель
 
61 - 14.06.18 - 12:30
(58) только вот код ревью должен быть всегда, а не выборочно
   Cyberhawk
 
62 - 14.06.18 - 12:33
(61) А кто его (по феншую) должен осуществлять? Напарник (параллельно к тебе в должности) или какой-нибудь вышестоящий гуру?
   Вафель
 
63 - 14.06.18 - 12:39
(62) тимлид
   like
 
64 - 14.06.18 - 12:40
спасибо всем, я в принципе получил ответы на свои вопросы
   KAUTERPER
 
65 - 14.06.18 - 12:42
Нет проблем. Напрягаешься и сразу пишешь божественный код, который не нужно тестировать.
   DrShad
 
66 - 14.06.18 - 12:53
(64) ТЗ естественно нет?
   like
 
67 - 14.06.18 - 12:57
(66) больше чем тз, обследование и тех проект есть, но только это не решает вопрос удобства тестирования
   DrShad
 
68 - 14.06.18 - 13:21
(67) обследование и тех проект это больше чем ТЗ!? не смешите
   4St
 
69 - 14.06.18 - 16:50
(61) (62) (63)да, ревью должны быть постоянными. Очень помогает чек лист: проверяем форматирование, разыменования в запросах, осмысленность имён переменных и методов, возможность завершения циклов и и тд. Если есть разногласия по пунктам не из чеклиста, решаем по ситуации. Главное - даже не догма, а здравый смысл.
Тимлидов на весь код не хватает, простые вещи спокойно проверяют мидлы. Плюс появляются общие стандарты кода и общее владение кодом, копипасты меньше.
Минус - это небольшое удорожание разработки. Плюс - не так страшно на продакшн выкладывать, техподдержке легче, и продукт не так быстро становится горой костылей.
Одно только понимание, что твой код будут читать, заставляет писать по человечески. Особенно когда с этими читателями вместе обедать ходишь.
   Вафель
 
70 - 14.06.18 - 17:57
(69) через гит ревью делаете?
   exwill
 
71 - 14.06.18 - 17:58
(0) Математически доказано, что эта проблема не решаема. Поэтому. Написал код. Отдал заказчику. Работает? Ну и ладно.
Не работает? Исправляешь.
Можно и потестировать перед передачей заказчику. Но увлекаться не надо. Потому что надежного результата ты все равно не получишь.
   4St
 
72 - 14.06.18 - 18:11
(70) когда как. Чаще всего все-таки через конфигуратор, там удобнее навигация по коду. Результаты фиксируем в рамках тикета на разработку в jira или gitlab.
В вебе гитлаба иногда смотрим blame, если надо быстро понять, кто это накодил. Гитовый клиент у нас sourcetree, там тоже мельком посматриваем, кто над чем работает в данный момент, какие новости в коде, где предстоит тяжёлый мерж и и.д.
   Вафель
 
73 - 14.06.18 - 18:26
(72) но ведь сравнение версий в конфигураторе - это потеря полчаса времени
   4St
 
74 - 14.06.18 - 18:39
(73) нам проще, пишем внешние обработки. Там порядка 100 000 строк кода и от 50 до 130 форм, но конфигуратор это пережевывает, понятно, быстрее, чем соседние релизы erp.
Зато с ветками удобно, и объединять интереснее.
   dmpl
 
75 - 15.06.18 - 08:49
(0) Тестовый набор данных подписывается у заказчика как часть ТЗ. Если на них работает - значит продукт написан качественно, подписывается акт, получаются деньги.
   dmpl
 
76 - 15.06.18 - 08:54
(37) Подождут.
   dmpl
 
77 - 15.06.18 - 09:00
(73) От объема изменений зависит. Бывает и 1-2 минуты.
   luter-89
 
78 - 15.06.18 - 09:40
Нужно писать код так, чтобы он не зависел от входных данных, обрабатывать все возможные типы данных, тогда и ошибок не будет.
   Dotoshin
 
79 - 15.06.18 - 10:21
(78) Ты недооцениваешь способности пользователей. Иногда они изобретают такие комбинации данных, которые тебе сроду в голову не придут. Так что все возможные варианты не предусмотришь. Поэтому пишутся тест-кейсы, в в которых предусмотрены определенные наборы данных и по этим кейсам  тестится разработанное ПО. Если в рамках кейса косяков нет, то считаем что ошибок нет. Но на самом деле ошибки все равно есть, просто они пока еще не проявились.
Бывает так, что ошибки проявляются только при каких-то определенных обстоятельствах. Например на разных компах,  на одном и том же наборе данных, на одном компе ошибка есть, а на другом нет. Недавно боролись с масштабированием УФ, на одном компе все масштабируется, а на другом нет. Оказалось, что на одном компе стояли не все обновления или как-то криво стояли. В общем сделали все одинаково, все заработало.
   Cyberhawk
 
80 - 15.06.18 - 10:40
"все возможные варианты не предусмотришь" // Дарю: "иначе"
   Cyberhawk
 
81 - 15.06.18 - 10:41
+(80) "Иначе ВызватьИсключение "Неождаемое поведение, ололо, разбирайся""
   Cyberhawk
 
82 - 15.06.18 - 10:42
"Бывает так, что ошибки проявляются только при каких-то определенных обстоятельствах. Например на разных компах" // Ага, с разными версиями Андроида и мобильной платформы 1С это особенно наглядно проявляется - цирк еще тот
   ildary
 
83 - 15.06.18 - 11:15
(82) с разными версиями пользователей особенно.


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