Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
Тема полезности юниттестов хотя и замусоленна в форумах и книгах, Но я пока не встречал аргументов в пользу или против них, опирающихся только на фактах. можно найти аргументы, которые опираются на логические рассуждения в основе которых находятся возможно известные факты, но этого недостаточно. Так как я сам отношусь очень скептически к юниттестам задался вопросом, а как измерить полезность конкретного юниттеста? Возможно ли вообще? Или может можно найти экономическое обоснование если не каждому отдельно взятому тесту то все практике как таковой? Вообщем, флейм он. Какие будут мысли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 19:53 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronа как измерить полезность конкретного юниттеста? Возможно ли вообще? да, можно. тест либо тестирует реализованную функциональность компонента, либо нет. хороший тест является также документацией к использованию компонента. если по тесту непонятно как пользоваться, а как нельзя, это плохой тест. mikronИли может можно найти экономическое обоснование если не каждому отдельно взятому тесту то все практике как таковой? найти экономическое обоснование можно посчитав цену ошибки. посчитать время, на устранение багов, на отладку. хорошее покрытие тестами, позволяет очень быстро отлаживать маленькую функциональность. без тестов это сделать невозможно, надо запускать весь проект и тестировать всё сразу, в дебаге. посчитать время на устранение ошибок, при добавлении или изменение функциональности, ведь никаких инструментов кроме как скомпилировалось или нет у разработчика нет. надо тестировать всё, после любого изменения, вручную. досконально. а какой-то формулы, типа N тестов умножить на X чего-то там, разделить на Y, и получить рубли/доллары, нет, я не знаю такой формулы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 20:03 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
hVosttmikronа как измерить полезность конкретного юниттеста? Возможно ли вообще? да, можно. Вот и хорошо. лозунги и тезисы отправим сразу на свалку истории. Как будем мерять? В каких единицах? Для начала можно упростить, пусть стоимость единицы времени работы постоянна и не зависит от квалификации. Такой у нас комунизм. Теперь надо разобратся со стоимостью ошибки. Задача и з разряда невозможных, но у нас комунизм и ошибку тоже будем мерять в часах работы на устранение её послествий. У нас не АЭС. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 20:32 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
Есть исследования , основанные на сравнительной эффективности команд для которых, впрочем, есть критика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 21:03 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikron, как то покрывал тестами разработку c-lib. нашел очень много ошибок, причем покрытие было не 100%. написать простой юнит тест простой функции существенно проще, чем выкапывать потом сбой большой программы из-за этой маленькой функции. измерить разницу затруднительно. я бы оценил в сотни процентов, но опять же - не надо пытаться засунуть в тесты абсолютно всё затраты на покрытие <100% исходного кода ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 21:14 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
Другими словами нормируем единицу устранения ошики как 1 час. Тогда полезность = время устранения последствий стандартной ошибки / врема затраченое на создание и поддержание теста. Верно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 21:30 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronДругими словами нормируем единицу устранения ошики как 1 час. Тогда полезность = время устранения последствий стандартной ошибки / врема затраченое на создание и поддержание теста. Верно? Эта формула исходит из того, что тест предотвращает ровно одну ошибку, а это не так. Еще время устранения ошибки это не все. Ошибку надо: - Обнаружить - Воспроизвести (найти условие при котором она вопроизводится) - Описать - Поискать в базе нет ли дублей - Приоритезировать - Найти root cause - Исправить - Проверить исправление (если регрессионное тестирование не автоматизировано то и на регрессии) - Возможно его документировать - Развернуть исправление у n клиентов И пока будет продолжаться этот цикл другие люди будут ее находить у себя тоже и прогонять через часть этого цикла ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 22:08 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
И еще тесты как документация - наверное надо померить время чтобы разобраться с кодом. И тесты как средство улучшения дизайна - тут есть всякие метрики типа cyclomatic complexity. Но это все про хорошие тесты, которые надо уметь готовить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 22:30 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
Siemargl как то покрывал тестами разработку c-lib. нашел очень много ошибок, причем покрытие было не 100%. во первых, где граница в этом неявном "утверждении полезности" между юнит-тестом и одноразовым тестом? Другими словами, найденые ошибки это "заслуга" теста или юнит-теста? Если потратить время на ручное тестирование, то с ненулевой вероятностью будут так же обнаружены ошибки. ещё не доказано что кодирование и повторное выполнение тестов оправдано. И второе, ошибки найдены, но ещё не доказана полезность проделанной работы. Другими словами, кого волнуют ошибки, если они никогда не проявляются? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 22:38 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
WebSharperНо это все про хорошие тесты, которые надо уметь готовить Довайте оставим категории "хорошие" и "плохие" как субьективные, и попробуем определится с объективными критериями оценки. Так как человек в основе существо разумное (хочется верить) то и делает оно только то что разумно оправдывает затраты на усилия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 22:43 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
пример: БД из сотен таблиц. порядка 10 разрабов. поменялось поле/маппинг для одной из таблиц. это не сразу выстрелит, если нет тестов. а если есть - это сразу покажется на билд-сервере, где играются тесты при коммите. это, конечно, не юнит-тесты, но, чтобы прочувствовать. с юнит примерно похоже. а прикинь, если этого нет? это же @опа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 22:58 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
если он проверяет что-то нужное в хорошо тестируемом коде, то полезность - 1. если иначе - удалить его, чтобы не мешался (есть еще проверка трешака, там, полезность 0,5) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 23:05 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
WebSharpermikronДругими словами нормируем единицу устранения ошики как 1 час. Тогда полезность = время устранения последствий стандартной ошибки / врема затраченое на создание и поддержание теста. Верно? Эта формула исходит из того, что тест предотвращает ровно одну ошибку, а это не так. Еще время устранения ошибки это не все. Ошибку надо: - Обнаружить - Воспроизвести (найти условие при котором она вопроизводится) - Описать - Поискать в базе нет ли дублей - Приоритезировать - Найти root cause - Исправить - Проверить исправление (если регрессионное тестирование не автоматизировано то и на регрессии) - Возможно его документировать - Развернуть исправление у n клиентов И пока будет продолжаться этот цикл другие люди будут ее находить у себя тоже и прогонять через часть этого цикла Я не говорил о "времени устранения ошибки", я говорил о "времени устранения последствий ошибки". Влияние наличие юнит-теста на время исправления самой ошибки я думаю пока можно исключить из рассмотрения. Все остальные якобы "надо" я пока не вижу как относятся к искомой мере "полезности". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 23:13 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronSiemarglкак то покрывал тестами разработку c-lib. нашел очень много ошибок, причем покрытие было не 100%. во первых, где граница в этом неявном "утверждении полезности" между юнит-тестом и одноразовым тестом? Другими словами, найденые ошибки это "заслуга" теста или юнит-теста? Если потратить время на ручное тестирование, то с ненулевой вероятностью будут так же обнаружены ошибки. ещё не доказано что кодирование и повторное выполнение тестов оправдано. И второе, ошибки найдены, но ещё не доказана полезность проделанной работы. Другими словами, кого волнуют ошибки, если они никогда не проявляются? а в чем разница в затратах кодирования теста и юнит теста? а вот повторять автотесты гораздо дешевле а если ошибка проявляется в 0.00001%, но стоит - ракету ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 23:18 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
Пусть: P - {относительная полезность юнит-теста} L - {время устранения последствий стандартной программной ошибки} = 1 человекoчас S - {время затраченное на создание и поддержание юнит-теста} тоже измеряется в человекочасах. Пока имеем: P = L / S Если у нас например софт для АЭС то умножаем P на кол-чо часов необходимых для устранения последствий аварии I и получаем абсолютную полезность юнит-теста для конкретной предметной области. I - {Фактор времени устранения последствий программной ошибки по отношений к стандартной программной ошибке} Таким образом приходим к тому что {полезность юнит-теста} - величина безразмерная. Так же естественно получается: P х I > 1 -- юнит-тест оправдан P х I < 1 -- к чёрту юнит-тест. последствия ошибки дешевле исправить. Какие будут дополнения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2018, 23:50 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
Siemarglа в чем разница в затратах кодирования теста и юнит теста? а вот повторять автотесты гораздо дешевле Я стараюсь отделить тест от юнит-тест. Юнит-тест - автоматизированные тесты для функций модуля. Тест же может быть кодированным или ручным или просто в дебагере пробежали. Суть - тест с минимальными одноразовыми затратами без возможности автоматического повторения. Немного лирики. Мне приходится иногда писать бессмысленные тесты в угоду "Test coverage". Бессмысленные как я считаю потому, что я уже оттестировал этот участок программы функциональным тестом. Я не вижу пользы от дополнительного юнит-теста. Я хотел бы увидеть и понять. Siemarglа если ошибка проявляется в 0.00001%, но стоит - ракету ? Абсолютно согласен что надо учесть. Риски вычисляются как {вероятност события} x {стоимость ликвидации последствий} ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 00:23 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronВот и хорошо. лозунги и тезисы отправим сразу на свалку истории. Как будем мерять? В каких единицах? я понимаю желание подъехать ко всему на своём деревянном номенклатурном танке. в каких единицах мерить вообще производительность по программированию? в строках кода в час? м? очевидную фигню то прогонять не надо уже. mikronТеперь надо разобратся со стоимостью ошибки. – простой 1 час – простой 1 день – простой 1 неделю – потеря данных – порча информации – порча данных – утечка конфиденциальных данных ... mikronЗадача и з разряда невозможных, но у нас комунизм и ошибку тоже будем мерять в часах работы на устранение её послествий. У нас не АЭС. дак а чо. давай просто представим, что программисты пишут без ошибок по факту. им даже работу свою проверять не надо. сколько времени экономится, на бесполезные проверки. написал, закоммитил и приступил к следующей задачи. даже проверять, компилируется или нет - потеря драгоценных минут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 06:12 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronКакие будут дополнения? прослезился ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 06:13 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronКакие будут дополнения? основное дополнение здесь, сам по себе расчёт полезности дороже написания юнит-тестов ))) но как способ отмыть баблишко, самое то ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 06:15 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronЭта формула исходит из того, что тест предотвращает ровно одну ошибку, а Я не говорил о "времени устранения ошибки", я говорил о "времени устранения последствий ошибки". Тогда почему один час и одна ошибка? Нафига нужна "стандартная ошибка" если она просто означает час времени. Если устранить это получаем "Время, которое сэкономил тест"/"Время его написания". Если вспомнить, что время разных людей стоит по разному и последствия ошибок бывают разные то, можно вот так: "Стоимость всех ресурсов которые сэкономил тест"/"Стоимость всех ресурсов на написание его и поддержание" Что представляет собо математическое выражение того, что и так понятно и относится не только к тестам, а вообще ко всему :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 09:46 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronСуть - тест с минимальными одноразовыми затратами без возможности автоматического повторения. Как осуществлять регрессионное тестирование? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 09:53 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
hVosttmikronВот и хорошо. лозунги и тезисы отправим сразу на свалку истории. Как будем мерять? В каких единицах? я понимаю желание подъехать ко всему на своём деревянном номенклатурном танке. в каких единицах мерить вообще производительность по программированию? в строках кода в час? м? очевидную фигню то прогонять не надо уже. Чтоб тебе понятней было давай на твоём примере: Твою высокую активность на форуме - производительность можно измерить количеством строк в час. Очевидно что о полезность при этом говорить нельзя. Так понятно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 10:00 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
WebSharpermikronЭта формула исходит из того, что тест предотвращает ровно одну ошибку, а Я не говорил о "времени устранения ошибки", я говорил о "времени устранения последствий ошибки". Тогда почему один час и одна ошибка? Нафига нужна "стандартная ошибка" если она просто означает час времени. Если устранить это получаем "Время, которое сэкономил тест"/"Время его написания". Если вспомнить, что время разных людей стоит по разному и последствия ошибок бывают разные то, можно вот так: "Стоимость всех ресурсов которые сэкономил тест"/"Стоимость всех ресурсов на написание его и поддержание" Что представляет собо математическое выражение того, что и так понятно и относится не только к тестам, а вообще ко всему :) Верно, но такое определение сложно применить к софту, ошибки которого не могут быть оценены сразу. Например библиотеки. С другой стороны стоимость в денежном эквиваленте величина не постоянная а для оценки полезности желательно иметь независимой от стоимости трудозатрат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 10:20 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
WebSharper, >> Тогда почему один час и одна ошибка? Один час работы по устранению последсвий ошибки - это типа эталонная ошибка. Таким образом например tipo для label - a 1 / 3600 эталонной ошибки. Согласись секунду мозгу достаточно что-бы понять что имелось в виду. Других последсвий нет. Или есть другие предложения? А про одну ошибку я реч не вёл. Пусть будут все ошибки, которэе предотвратил тест. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 10:35 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
Что полезного дает понятие эталонной ошибки? Нафига оно нужно вообще, чтобы было менее понятно что это один час? Тогда в определениях недостаточно косвенности. Надо определить эталонной множество ошибок, которое состоит их ровно одной эталонной ошибки, которое определяетсся через эталонное время исправление из эталонных временных единиц, которое равно часу :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 10:50 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
WebSharperЕсть исследования , основанные на сравнительной эффективности команд для которых, впрочем, есть критика. Прочитал, это немного из другой оперы про TDD, но критика не без основания. основной пункт критиков ошибочная measure (измеренная величина) и как следсвие неверные выводы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 11:02 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
WebSharperЧто полезного дает понятие эталонной ошибки? Нафига оно нужно вообще, чтобы было менее понятно что это один час? Тогда в определениях недостаточно косвенности. Хорошо, давай попробуем без эталонной ошибки. Как тогда будем мерит "затраты на исправлене последствий ошибки" если речь идёт скажем о функции синуса из стандартной библиотеки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 11:08 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronЧтоб тебе понятней было давай на твоём примере: Твою высокую активность на форуме - производительность можно измерить количеством строк в час. Очевидно что о полезность при этом говорить нельзя. Так понятно? примерно так же понятно, как смотри, небо голубое но говорить о пользе верблюдов при этом нельзя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 11:48 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronХорошо, давай попробуем без эталонной ошибки. Как тогда будем мерит "затраты на исправлене последствий ошибки" если речь идёт скажем о функции синуса из стандартной библиотеки? 1) Придумаем тест 2) Посомотрим по истории все тикеты которые приводили бы к фейлу теста, если бы он был 3) Посмотрим по истории все тикеты, закрытые как дублирующие к ним 4) Для каждого тикета просуммируем все затраты связанные с ним ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 11:51 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikron, единственная мера с точки зрения бизнеса может быть такая: A - доходы от разработки B - расходы на разработку в час C - риск непредвиденных расходов D - недополученные доходы М - маржа чтобы точнее оценить, надо взять десяток примерно одинаковых по скиллам команд, дать им одно задание, одни пишут с тестами, другие без тестов, изолировать друг от друга, потом считать. с точки зрения именно разработчика, с тестами разработчик может давать более контролируемые и прогнозируемые оценки разработки и сопровождения, так как знает, что большинство проблем будет отловлено авто-тестами, а не безразмерным количеством времени на отлов багов. также разработчик понимает, что написание тестов может заменить собою огромное количество технической документации, не полностью, но довольно весомую часть. поддерживать тесты в актуальном состоянии придётся, а документацию поддерживать крайне дорого. и сверять актуальность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 11:55 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
WebSharper1) Придумаем тест 2) Посомотрим по истории все тикеты которые приводили бы к фейлу теста, если бы он был 4) Для каждого тикета просуммируем все затраты связанные с ним 1.1) На основании каких знаний мы "придумываем тест" ? Когда мы "придумываем тест" мы знаем об ошибках извесных через системы слежения за ошибками? 1.2) Идея придумывать тесты мне совсем не нравится, потому что я запросто могу генерировать тесты из разряда "1+1==2" , доказывать что они безполезны, и на основании этого делать ложный вывод о бесполезности юнит-тестов. Мне больше нравится идея, если мы оценим уже имеющиеся тесты. Это будет объективно. 2.1) Как это практически реализовать? Вот у меня есть достип ко всем системам: JIRA/QualityCenter/Code Repository/системы автоматизации. Как измерить я пока не представляю. 4.1) Тоже не нравится, потому что учитывает затраты на "defect management". Меня же интересует "стоимость последствий ошибки" а не стоимость её исправления. Образно стоимость последсвий ошибки софта на АЭС может быть милионы человекочасов, а а стоимость её исправления 4 часа. Это разные величины. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 12:46 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronа а стоимость её исправления 4 часа поиск ошибки — 9950$ исправление ошибки — 50$ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 12:49 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
Хорошо, оставим пока в покое "стоимость исправлений последствий ошибки". Давайте посмотрим на "Стоимость" / TCO юнит-тестов. так-как её тоже посчитать сложно, предлогаю прикинуть от чего она зависит. ИМХО: 1) пропорционална сложности кода для юнит-теста. (Ведь кто-то его написал) - пропорционална сумарной сложность исполняемого кода во время теста минус сумарная сложность исполняемого тестируемого кода. (Можно вычеслить на основании байт-кода и принадлежности классов к тесту / коду) - пропорционална кол-ву методов в тесте: если даже сложность низкая но для теста нужно написать 30 методов, то сложность скорее высокая, и заключается в понимании материи теста. - пропорционална кол-ву классов в тесте: Обоснование см выше. 2) пропорциональна кол-ву ревизий в репозитории (И кто-то его пофиксил, непонятно почему, но затраты были) - Ревизии кототрые лежат по времени не далеко одна от другой можно считать или одной или с коеффициентом "свежести" (х0.3 например) - Ревизии кототрые лежат по времени далеко одна от другой надо считать с коефициентом "старости" (х1.5) 3) ресурсы тестов так-же влияют на сложность. например есть куча "XStream" фаилов, в кототрых внутри сложные биснес-обекты. их можно мысленно перевести в код. Значит берём их сжатый размер с фактором и добавляем к сложности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 13:40 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikron 1.1) На основании каких знаний мы "придумываем тест" ? Тесты это отражение требований. 1.2) Идея придумывать тесты мне совсем не нравится, потому что я запросто могу генерировать тесты из разряда "1+1==2" , Есть масса книжек про то, как тестировать в части из них написано, что тестировать. доказывать что они безполезны, и на основании этого делать ложный вывод о бесполезности юнит-тестов. Мне больше нравится идея, если мы оценим уже имеющиеся тесты. Это будет объективно. Тогда нам неоткуда взять данные по предотвращенным ошибкам так как тест их предотвратил. То есть они зарублены макимум на этапе CI 2.1) Как это практически реализовать? Вот у меня есть достип ко всем системам: JIRA/QualityCenter/Code Repository/системы автоматизации. Как измерить я пока не представляю. Берете требования к юниту, пишите один тест, дальше смотрите changelog, считая, что тест был с самого начала и прогоняете его по каждому изменению, дальше идете по тикетам и опросом людей выясняете сколько заняли все работы по данному тикету. 4.1) Тоже не нравится, потому что учитывает затраты на "defect management". Меня же интересует "стоимость последствий ошибки" а не стоимость её исправления. Образно стоимость последсвий ошибки софта на АЭС может быть милионы человекочасов, а а стоимость её исправления 4 часа. Это разные величины. Я думаю, все сведется к тому, что конкретные последствия будут оценены методом экспертной оценки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2018, 14:31 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikron Так как я сам отношусь очень скептически к юниттестам задался вопросом, а как измерить полезность конкретного юниттеста? Возможно ли вообще? Или может можно найти экономическое обоснование если не каждому отдельно взятому тесту то все практике как таковой? Я думаю что такой формулы не существует. Полезность мы определяем сами экспертно на основании своего видения страховки от возможных ошибок за 1 минуту до релиза. По сути мы вкладываем в разработку +20% или +30% рабочего времени но зато имеем стабильный статус релиза. Код, который покрыт юнит-тестом очень приятно рефакторить. Вы что-то поменяли. Пересобрали. Прогнали тесты. Зеленые статусы говорят о том что рефакторинг как минимум ничего не сломал. Есть еще один полезный бонус. Текст юнит-теста является готовой документацией по модулю. Можно даже не проверяя документировать как юзкейсы. Особенно если написать на DSL типа JBehave. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 00:19 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
привести точную разбивку по стоимости не получится. Это примерно как привести экономическое обоснование использования ООП, а не процедурного программирования. Есть устоявшиеся подходы к разработке, которым и надо следовать. Если сильно надо убедить начальство - то можно провести ссылки на майкрософтовскую документацию, где написано про юнит тестирование и как оно вовлечено в общий процесс разработки. А то если требовать экономического обоснования каждому шагу, каждой библиотеке и каждому паттерну - то никакой работы не будет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 06:14 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
maytonКод, который покрыт юнит-тестом очень приятно рефакторить. Вы что-то поменяли. Пересобрали. Прогнали тесты. Зеленые статусы говорят о том что рефакторинг как минимум ничего не сломал. Более того! Даже если разработчик не удосужился прогнать тесты перед коммитом, это сделает за него билд-сервер, и просто тупо не выпустит артефакты, сборка провалится при отказе любого теста, или в случае, если кто-то очень умный грохнул тесты, закомментировал или изменил так, что процент покрытия уменьшился. Ещё один плюс юнит-тестов, именно в методологии TDD, начиная разработку с юнит-тестов, определяются контракты и ожидания. После написания тестов, надо добиться, чтобы тесты не падали. С этого момента, реализацию можно легко делегировать на группу. И ещё один плюс юнит-тестов, о которых я писал, но повторю. Думаю ни для кого из разработчиков не секрет, что можно пользоваться дебагом в процессе разработке. Пишем что-то, компилируем, запускаем в дебаге, и либо скурпулёзно проходим по шагам реализованный алгоритм, либо ленивый стайл, тыкаем и ждём падения с точкой останова в месте падения. Проблема тут вот в чём, надо запускать весь проект с полноценным окружением. Даже возьмём крайний случай, добавили в код хитрую валидацию ИНН с расчётом контрольного числа. Как теперь проверить? Запускать всё, добираться до записи, где надо ввести ИНН и дрочить инпут? Это стиль разработки джуниора, и даже мы не позволяем джунам действовать таким образом. Пишется и отлаживается прям в юнит-тесте, никакого окружения не нужно, можно отладить очень маленький кусочек в так полюбившемся многим дебаггере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 06:29 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
maytonЕсть еще один полезный бонус. Текст юнит-теста является готовой документацией по модулю. Это не посто бонус. Это колоссальный экономический эффект. Актуализация рабочей документации -- крайне дорогое удовольствие, которое ещё даже не гарантирует, что оно покрывает всю кодовую базу и не устарело. Юнит-тесты вынуждают поддерживать всё в актуальном состоянии, при чём на любой момент времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 06:32 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
maytonКод, который покрыт юнит-тестом очень приятно рефакторить. Вы что-то поменяли. Пересобрали. Прогнали тесты. Зеленые статусы говорят о том что рефакторинг как минимум ничего не сломал. А красные — просто красивые. Реально они говорят только что сломался тест. maytonЕсть еще один полезный бонус. Текст юнит-теста является готовой документацией по модулю. Можно даже не проверяя документировать как юзкейсы. Часто встречается этот миф. То есть что, ты вполне себе так серьёзно и взвешенно утверждаешь что MSDNне нужен? Достаточно вуложить тексты тестов и пусть народ сам разбирается! Я не могу это воспринимать серьёзно, сорри. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 10:30 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
StalkerSто можно провести ссылки на майкрософтовскую документацию, где написано про юнит тестирование и как оно вовлечено в общий процесс разработки. Если есть спрос то логично что микрософт продаст вам побрякушек. Но вот он подтверждает например моё мнение: John-L-MillerI was a software test developer, manager, and manager of managers at Microsoft for Windows NT 3.1, 2000, and portions of Windows XP. I am making this answer based on my experience. It does not represent the perspective or views of my employer, Microsoft. If we’d taken this approach - fix bugs a customer will hit in normal use, and ignore purely internal bugs - our quality would have suffered slightly, but I believe we could have released the same product in half the time with half as many people working on it. A test is effective if it finds bugs that would affect users. If you’re just pushing test coverage up, or trying for exhaustive testing of corner cases and internal functions (such as class definitions), you’re wasting time. Focus on the customer, fixing significant problems they will bump into, and giving them the product more quickly. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 10:46 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronЧасто встречается этот миф. То есть что, ты вполне себе так серьёзно и взвешенно утверждаешь что MSDNне нужен? Достаточно вуложить тексты тестов и пусть народ сам разбирается! земля круглая -- тоже миф. примерно такого уровня твоё заявление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 10:51 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronТо есть что, ты вполне себе так серьёзно и взвешенно утверждаешь что MSDNне нужен? Достаточно вуложить тексты тестов и пусть народ сам разбирается! Я не могу это воспринимать серьёзно, сорри. MSDN уже давно отстаёт от текущих публичных разработок на GutHub, зато тесты там всегда актуальные. Огромное количество публичных проектов, включая широко используемые, вообще не содержит документации, или документации там кот наплакал. Но с тестами обычно всё в порядке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 11:09 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
hVosttmikronЧасто встречается этот миф. То есть что, ты вполне себе так серьёзно и взвешенно утверждаешь что MSDNне нужен? Достаточно вуложить тексты тестов и пусть народ сам разбирается! земля круглая -- тоже миф. примерно такого уровня твоё заявление. Что земля круглая доказал Магелан. Хорошо, допустим это не миф. Ты можеш это доказать? Или хотя бы привести пример из жизни? Покажи мне хоть один продукт, где документация к нему - тексты тестоб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 11:16 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
hVosttОгромное количество публичных проектов, включая широко используемые, вообще не содержит документации, или документации там кот наплакал. Но с тестами обычно всё в порядке. Ключевое слово "публичных". Любители поразбиратся читают сам код и коментарии к / в коду. А теперь закрой код, и давай раскажи нам как по тестам понят что к чему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 11:26 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronТы можеш это доказать? доказать, что примеры кода, непосредственного использования компонентов программы, вдоль и поперёк, с ожиданием конкретного результата: что на входе, что на выходе -- это документирует код? тогда докажи что квадрат это квадрат. и примеры пожалуйста приведи. заходишь на гитхаб, открываешь любой популярный проект, и с вероятностью 90% он покрыт тестами, открываешь тесты, читаешь. я так тысячу раз делал. mikronПокажи мне хоть один продукт, где документация к нему - тексты тестоб. не цепляйся к словам, ясно что тесты это тесты, а документация это документация, поэтому тесты = документация утверждение не верное. имелось в виду, что тесты хорошо документируют модули и компоненты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 13:34 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronТема полезности юниттестов хотя и замусоленна в форумах и книгах, Но я пока не встречал аргументов в пользу или против них, опирающихся только на фактах. можно найти аргументы, которые опираются на логические рассуждения в основе которых находятся возможно известные факты, но этого недостаточно. Так опираются аргументы на факты или нет? Вы уж решите как-нибудь. mikronТак как я сам отношусь очень скептически к юниттестам задался вопросом, а как измерить полезность конкретного юниттеста? Возможно ли вообще? Или может можно найти экономическое обоснование если не каждому отдельно взятому тесту то все практике как таковой? Вообщем, флейм он. Какие будут мысли? Мысли будут такие: тесты очевидно нужны, и здесь речь не только о юнит-тестировании. Рассчитать полезность теста невозможно. Вероятно можно найти экономическое обоснование - этим занимается экономика, а значит можно что угодно. Если вам непонятно, зачем нужны тесты, то либо вы не учавствовали в создании программ уровнем выше вывода Hello world, либо не занимались разработкой в команде (все это нормально), но как мне кажется, и, что более вероятно - вы занимаетесь неким троллингом, не зря вы про флейм что-то написали. Неужели не очевидно, детсяки разработчиков, часть бестолоковых, шальной pull request, некачественное review, и вот не бьется расчет, или то, что раньше работало перестает работать, кнопка перестала нажиматься.. Неужели вы не знаете эту фразу о двух шагах вперед и шаге назад? Вы исправляете одну ошибку, появляется новая, в том месте, где раньше все было ок. Вот мы и пришли постепенно к регрессионному тестированию Так что давайте по существу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 20:06 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronmaytonЕсть еще один полезный бонус. Текст юнит-теста является готовой документацией по модулю. Можно даже не проверяя документировать как юзкейсы. Часто встречается этот миф. То есть что, ты вполне себе так серьёзно и взвешенно утверждаешь что MSDNне нужен? Достаточно вуложить тексты тестов и пусть народ сам разбирается! Я не могу это воспринимать серьёзно, сорри. При чем здесь МСДН? Я вообще не говорил про это. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 23:40 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
hVosttДаже возьмём крайний случай, добавили в код хитрую валидацию ИНН с расчётом контрольного числа. Как теперь проверить? Запускать всё, добираться до записи, где надо ввести ИНН и дрочить инпут? Это стиль разработки джуниора, и даже мы не позволяем джунам действовать таким образом. Пишется и отлаживается прям в юнит-тесте, никакого окружения не нужно, можно отладить очень маленький кусочек в так полюбившемся многим дебаггере. Мы на проекте делаем end-2-end тесты. Это круче чем unit. Это собственно симуляция работы приложения. Поднимаем симулятор MQ, Jetty, БД. Вобщем сетевые mocks. Толкаем сообщение и отслеживаем что оно проходит все точки. Благо, UI как такового нет. Просто бизнес-процессы. Даже представить сложно как много эта техника экономит денег и времени мануального тестирования. Коэффициент я точно не скажу. Но тут я-бы сказал что важнее сам факт автоматизации. Можно подвязать под Jenkins/Teamcity. Кнопку нажал и пошла симуляция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 00:13 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
maytonМы на проекте делаем end-2-end тесты. Это круче чем unit. Это собственно симуляция работы приложения. Поднимаем симулятор MQ, Jetty, БД. Вобщем сетевые mocks. Толкаем сообщение и отслеживаем что оно проходит все точки. Благо, UI как такового нет. Просто бизнес-процессы. это уже интеграционные тесты. задача юнит-тестов эт тестировать как можно маленькие блоки: классы, методы, свойства. также юнит-тесты проверяют правильную работу исключений. не не "круче", чем unit, это другое тестирование, и не решает задач юнит-тестов :) хотя интеграционные тесты крайне полезны, так как тестируют уже именно бизнес-логику, в окружениях, близких к реальным. maytonДаже представить сложно как много эта техника экономит денег и времени мануального тестирования. скажем, мануальное тестирование можно затолкать в интеграционное, при желании :) maytonКоэффициент я точно не скажу. ну... если не можешь сказать коэффициент и доказать, значит это всё не работает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 07:46 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
maytonМы на проекте делаем end-2-end тесты. Это круче чем unit. Почему гугуль не использует end-to-end ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 10:03 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
hVosttну... если не можешь сказать коэффициент и доказать, значит это всё не работает Это покрывает 100% бизнес кейсов брат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 10:14 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
WebSharpermaytonМы на проекте делаем end-2-end тесты. Это круче чем unit. Почему гугуль не использует end-to-end У меня нет желания спорить по вопросу гугла. Каждая предметная область имеет какие-то особенности. Я думаю что тестирование в авиации или automotive сильно существенно отличается от тестирования скажем в It-отрасли биржевого или финансового ПО. И если гугл что-то не использует - то я думаю что в этом есть свой поинт. Опять-же автор топика поднял вопрос о сферических тестах в космосе и поэтому я оставляю за собой право выбирать под-область и говорить о ней в качестве примера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 10:17 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
По поводу тестов и авто-документирования. Разработчик обычно ленится писать документацию по коду. 99% проектов что я видел были снабжены бизнес-требованиями в виде confluence-документации или просто в виде россыпи документов Word. Если у нас к примеру есть функция которая проверяет валидность email или url, то "глазками" оценить ее все-все возможные кейсы использования трудно. Ну... скажем это не тривиальная задача. К примеру регулярка которая оценивает валидность email, может выглядеть как лист A4 текста в виде Regexp (я такое реально видел). Но если эта функция снабжена хотя-бы парой asserts, где проверяется что один емайл валиден а другой - нет - то это уже 99% документация. Можно еще добавить маргинальные случаи когда емейл пуст или емейл == null и готово. Автор топика выражал скепсис по поводу такого подхода. Он ссылался на ручное документирование. Я не возражаю. Но я в качестве примера говорил о коде который изначально вообще не документирован но при этом имеет Unit-покрытие. В качестве домашнего задания (просто для себя) я-бы попросил автора и прочих участников топика, честно оценить сколько вашего проектного кода документировано? Отвечать на это необязательно. Это просто тема для размышления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 10:29 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
maytonТекст юнит-теста является готовой документацией по модулю При чем здесь МСДН? Я вообще не говорил про это. MSDN пример гипотетический. Если бы тесты являлись готовой документацией, микросовт бы сэкономил кучу денег прекратив поддержку MSDN, и никто бы и не заметил потери. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 13:00 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronmaytonТекст юнит-теста является готовой документацией по модулю При чем здесь МСДН? Я вообще не говорил про это. MSDN пример гипотетический. Если бы тесты являлись готовой документацией, микросовт бы сэкономил кучу денег прекратив поддержку MSDN, и никто бы и не заметил потери. это тупиковый путь в рассуждениях. ms это вендор, который теряет деньги, если не получает прибыль. поэтому не только документирует, но ещё и рекламу снимает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 13:27 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
hVosttmaytonМы на проекте делаем end-2-end тесты. Это круче чем unit. это уже интеграционные тесты. задача юнит-тестов эт тестировать как можно маленькие блоки: классы, методы, свойства. Это подразумевает что "задачу" нам поставили "совочком вырыть котлован". В этой дискуссии я не участвую - чуждо мне такое понимание. ИМХО Задача у всех тестов одна - уменьшить риски и сократить расхода путём выявления софтварных ошибок на ранней стадии. Эту задачу в определённой степени решают как интеграционные тесты так и унит - тесты. Моё личное убеждение совпадает с мнение того менеджера из микрософта - только функциональные тесты. это деление немного в другой плоскости, но среди юнит тестов обычно функциональных ничтожно мало. Интегранционные - скорее все, но и не полностью. Но это личные впечатления. А так как опыт у каждого разный и субективные впечатления у всех разные. Для обектовного взгляда нужна чёткая измеряемая величина, тогда можно говорит, каким методом, или методом каких тестов задача решается наиболее эффективно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 14:41 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronMSDN пример гипотетический. Если бы тесты являлись готовой документацией, микросовт бы сэкономил кучу денег прекратив поддержку MSDN, и никто бы и не заметил потери. Тесты, в т.ч. и Unit-тесты это не замена документации, а дополнение к документации. Причем чаще всего более актуальное чем документация. Если изменения в документации можно оставить "на потом", то тесты валятся "здесь и сейчас". Поэтому доверия к тестам чуть больше. Но все равно "Все врут" (с) доктор Хаус ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 14:44 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronДля обектовного взгляда нужна чёткая измеряемая величина удачи в поисках ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 14:44 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
maytonВ качестве домашнего задания (просто для себя) я-бы попросил автора и прочих участников топика, честно оценить сколько вашего проектного кода документировано? Отвечать на это необязательно. Это просто тема для размышления. Охотно отвечу. Наверно максимум 1%. Но я никогда ту документацию не открываю. Потому как она наверняка устарела и не точная. Есть такой тезис: код это и есть самая полная, актуальная и не противоречивая документация. Он в моём lightguide. Совершенно другое дело взгляд на функционал - здесь толко документация. Код права голоса не имеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 14:57 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
maytonИ если гугл что-то не использует - то я думаю что в этом есть свой поинт. И вам даже не интересно прочитать по ссылке и понять, какой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 16:29 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronДля обектовного взгляда нужна чёткая измеряемая величина рубли/доллары подойдут? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 20:14 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronЕсть такой тезис: код это и есть самая полная, актуальная и не противоречивая документация. Это неверный тезис. Например, мне нужна сортировка, реализация сортировки может быть очень сложной и замысловатой, если мне придётся разбираться досконально в алгоритме, чтобы понять, могу ли я заиспользовать метод или нет -- это крайне отвратительная документация, не тянет даже под градусом. Так что не надо зачёсывать пожалуйста. Тесты показывают что на входе, что на выходе -- это именно то, что нужно. mikronСовершенно другое дело взгляд на функционал - здесь толко документация. Код права голоса не имеет. Постоянная актуализация документации -- крайне дорогое удовольствие. Особенно подробная. Да, согласен, хорошо написанная документация, покрывающая всю кодовую базу, и актуальная -- это хорошо. Но увы. Такое можно встретить крайне редко. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 20:21 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mikronОхотно отвечу. Наверно максимум 1%. Но я никогда ту документацию не открываю. Потому как она наверняка устарела и не точная. Есть такой тезис: код это и есть самая полная, актуальная и не противоречивая документация. Он в моём lightguide. А какое ПО вы разрабатываете если не секрет? Сколько разработчиков в команде? Есть ли CI ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2018, 02:15 |
|
||
|
Как измерить полезность теста?
|
|||
|---|---|---|---|
|
#18+
mayton, Это не совсем разработка и скорее software customisation. Поверх основного кода, накладывается код для клиента. Получается такой гибрид. И CI и тесты. Но к чему эти вопросы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2018, 03:16 |
|
||
|
|
start [/forum/topic.php?all=1&fid=16&tid=1340175]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
178ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
85ms |
get tp. blocked users: |
1ms |
| others: | 276ms |
| total: | 585ms |
| 0 / 0 |
