Сообщений в теме: 52

[DrVal]

В таком случае, как понять руководителю кто хорошо работает?! :)

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

[LeshaL]

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

Сложность покрываемоего тестами функционала, объём необходимых входных данных для теста, сложность создания оракулов и новизну тестируемого функционала для исполнителя как предлагаете оценивать?

[barancev]

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

[barancev]

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

[LeshaL]

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

Конечно же стал бы. Почему нет? И руководство было бы радо результатам моей работы :) Но тут надо действовать аккуратно, не перестараться сразу.

Единственная метрика, которую сложно поджулить - покрытие тестами кода. На мой взгляд, единственная достоверная. Именно поэтому, текущую задачу по автоматизации я и начала с того, что подсчитал текущее покрытие.

[barancev]

Единственная метрика, которую сложно поджулить - покрытие тестами кода.

Да ладно! Ещё как можно!
А главное -- эта метрика не показывает того, насколько хорошо в тестах сделаны оракулы.

[LeshaL]

Единственная метрика, которую сложно поджулить - покрытие тестами кода.

Да ладно! Ещё как можно!
А главное -- эта метрика не показывает того, насколько хорошо в тестах сделаны оракулы.

Интересно как? Только без читерства, типа генерации репорта о покрытии другим тулом :)

[barancev]

Единственная метрика, которую сложно поджулить - покрытие тестами кода.

Да ладно! Ещё как можно!
А главное -- эта метрика не показывает того, насколько хорошо в тестах сделаны оракулы.

Интересно как? Только без читерства, типа генерации репорта о покрытии другим тулом :)

Вообще-то изначально я говорил не о том, чтобы создать ложное завышенное представление о результатах работы, а о том, как выбранная метрика влияет на то, что делает человек. То есть завышение происходит естественным и вполне честным способом, никакого читерства нет! Именно в этом контексте я и отвечу на вопрос.

1. Первое, и самое важное с моей точки зрения -- эта метрика провоцирует уделять больше внимания генерации данных (чтобы попасть в разные места кода) и меньше внимания уделять оракулам, потому что они не оказывают никакого влияния на показатели по этой метрике.

2. Какой уровень детализации выбрать -- по строкам, по ветвям, по дизъюнктам, по путям? Последние два используются крайне редко, потому что нет инструментов, которые умеют их измерять корректно. Соответственно, тестировщик ограничивается метрикой, которую проще измерять, а не ту, коkyjоторая обеспечивает большее разнообразие вариантов.

3. Если выбрана метрика по строкам, и имеется ветвление без else-блока, тогда достаточно теста, в котором выполняется условие ветвления -- и покрытие по строкам достигнуто. А дефект может проявляться как раз в случае, когда программа не заходит в then-блок.

4. Иногда в программе встречаются весьма труднодостижимые места, которые крайне сложно покрыть. Например, если в Java-программе используется работа с потоками, приходится в разных местах вставлять перехват исключения InterruptedException и писать обработчик, который, скажем, делает запись в лог-файл о возникшей проблеме. Вот эти обработчики покрыть тестами весьма непросто. Да и как правило ненужно. И таких "несущественных" фрагментов кода в программе может быть достаточно много. В результате полного покрытия достичь не удаётся. Предположим, что отчёт показывает, достигнуто 95% покрытия. А что же с оставшимися 5%? Может быть остались непокрытыми исключительно "несущественные" куски кода? Или туда затесались 30-40 строк существенного кода, и там может прятаться баг? Как их разделить? Для этого инструменты изменения покрытия имеют специальные инструкции, которые можно вставить в код для пометки несущественных фрагментов, чтобы они не учитывались при сборе статистики. Ну а раз у нас появляется возможность исключать таким образом "несущественные" фрагменты кода, появляется соблазн пометить все труднодостижимые фрагменты кода.

[grass]

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

Сложность покрываемоего тестами функционала, объём необходимых входных данных для теста, сложность создания оракулов и новизну тестируемого функционала для исполнителя как предлагаете оценивать?

Да как на основе экспертной оценки. Во первых вес каждого параметра, во вторых коэффициенты сложности для каждого из приведенных параметров. Теория принятия решений. Институтский курс. И не уверен, что это сложно.

[LeshaL]

Вообще-то изначально я говорил не о том, чтобы создать ложное завышенное представление о результатах работы, а о том, как выбранная метрика влияет на то, что делает человек. То есть завышение происходит естественным и вполне честным способом, никакого читерства нет! Именно в этом контексте я и отвечу на вопрос.

Именно в этом контексте и был интересен ответ. Спасибо.

По первому пункту - согласен. И даже могу дополнить, что и генерация больших объёмов данных при таком подходе не всегда выгодна, т.к. данные могут ходить по совершенно одним и тем же путям программы, но одни будут вызывать NPE, другие нормально работать, а третьи вызывать AIOOB.

Про остальные пункты - это чисто технические заморочки (кстати, что такое покрытие по дизъюнктам?). Я всё это понимаю, но не думаю, что это сильно может влиять именно на работу и попытку подгона под результат. А даже если и так, то если покрытие, как бы его не измеряли, растёт - то это непременно будет плюс и тестируемому продукту и тестовому набору. Легко покрыть сперва все методы - отлично, давайте будет нашей первой целью (т.е. охват в ширь - везде по чуть-чуть). Дальше, можно копать в глубь, измеряя по блокам или ветвям. На строки можно сразу забить(имхо). Я вот примерно такими соображениями руководствуюсь, а не подсчётом количества тестов в наборе, например.

А что касается 100% покрытия, так оно, насколько я помню, вредно, с точки зренеия трудозатрат. Хотя опять же, смотря о каком покрытии вести речь :)
И то что 100% покрытие ничего не гарантирует, я тоже согласен.

[aaa]

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

думаю, что так или иначе работа будет идти с оглядкой на формулу...

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

По сути в системе ооочень много функционала который практически не меняется + большой объём уже пройденных руками тест-кейсов, хотелось бы автоматизировать пройденные тест-кейсы, а также покрыть автотестами весь редкоменяющийся функционал - это для начала, потом в идеале, я просто пока не знают возможно ли это, хотелось бы, чтобы автотесты были готовы к выпуску первой сборки в тестирование.

[aaa]

Хотелось бы может услышать пример построения автоматизации, оценки и контроля работы...

[barancev]

По первому пункту - согласен. И даже могу дополнить, что и генерация больших объёмов данных при таком подходе не всегда выгодна, т.к. данные могут ходить по совершенно одним и тем же путям программы, но одни будут вызывать NPE, другие нормально работать, а третьи вызывать AIOOB.

Да, тут можно добавить и ещё один аспект -- как правило мы измеряем покрытие своего кода, но в программе имеются и обращения к внешним библиотекам, и они могут тоже возвращать разные результаты (в том числе разные исключения, в том числе неспецифицированные unchecked-исключения), и это остаётся неучтённым, поскольку строчку с вызовом внешнего метода достаточно покрыть один раз, чтобы показатели были хорошими.

Про остальные пункты - это чисто технические заморочки (кстати, что такое покрытие по дизъюнктам?). Я всё это понимаю, но не думаю, что это сильно может влиять именно на работу и попытку подгона под результат. А даже если и так, то если покрытие, как бы его не измеряли, растёт - то это непременно будет плюс и тестируемому продукту и тестовому набору.

Дело не в том, что покрытие растёт (если так -- это хорошо), а в том, что если оно уже достигнуто, то больше тесты делать нет необходимости, которые покрывают уже покрытые элементы, они не улучшают показатели. А это опасно, потому что это лишь лишь один из факторов, которые нужно принимать во внимание, когда мы решаем, нужно делать дополнительные тесты или уже достаточно.

Покрытие по дизъюнктам -- это покрытие всех возможных логических комбинаций, при которых срабатывает или не срабатывает составное условие ветвления. Например, знаменитая учебная задача про треугольник, там есть такое условие:
if (a+b<c || b+c<a || c+a<b) {
// это не треугольник!
}
Условие состоит из трёх частей, и оно выполняется тогда, когда выполняется одна из трёх частей (любая), а две другие не выполняются, когда выполняются две любые, а третья не выполняется, или когда выполняются все три. То есть всего имеется восемь различных комбинаций состояний частей этого условия, при этом семь из них приводят к выполнению условия, а одно -- к нарушению. И дополнительным усложнением является то, что некоторые из этих комбинаций не могут быть достигнуты, так что здесь тоже нужно применить интеллект, чтобы понять, почему не достигается полное покрытие -- потому что тестов мало или потому что это принципиально невозможно.

А что касается 100% покрытия, так оно, насколько я помню, вредно, с точки зренеия трудозатрат. Хотя опять же, смотря о каком покрытии вести речь :)
И то что 100% покрытие ничего не гарантирует, я тоже согласен.

Вовсе нет, достижение 100% покрытия это очень хорошо, потому что любое числе меньше 100% оставляет сомнения относительно того небольшого количества элементов, которые остались непокрытыми. Мы должны каждый из них внимательно изучить, и если они несущественны -- явно исключить их из рассмотрения, используя возможности инструмента. И тогда мы сможем с уверенностью сказать, глядя на замечательное число 100%, что покрыты все существенные элементы.

[barancev]

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

По сути в системе ооочень много функционала который практически не меняется + большой объём уже пройденных руками тест-кейсов, хотелось бы автоматизировать пройденные тест-кейсы, а также покрыть автотестами весь редкоменяющийся функционал - это для начала, потом в идеале, я просто пока не знают возможно ли это, хотелось бы, чтобы автотесты были готовы к выпуску первой сборки в тестирование.

Это Вы рассказали план -- что вы собираетесь сделать. Но всё равно не сформулировали цель -- зачем?

[Alfa]

Вовсе нет, достижение 100% покрытия это очень хорошо, потому что любое числе меньше 100% оставляет сомнения относительно того небольшого количества элементов, которые остались непокрытыми. Мы должны каждый из них внимательно изучить, и если они несущественны -- явно исключить их из рассмотрения, используя возможности инструмента. И тогда мы сможем с уверенностью сказать, глядя на замечательное число 100%, что покрыты все существенные элементы.

Простой пример кода
a = b/c
и никакое 100% покрытие не поможет отловить ошибку деления на ноль.

[LeshaL]

Спасибо за разъяснение того, что такое "покрытие по дизъюнктам". Весьма интересно.

Теперь к 100%.

Вовсе нет, достижение 100% покрытия это очень хорошо, потому что любое числе меньше 100% оставляет сомнения относительно того небольшого количества элементов, которые остались непокрытыми. Мы должны каждый из них внимательно изучить, и если они несущественны -- явно исключить их из рассмотрения, используя возможности инструмента. И тогда мы сможем с уверенностью сказать, глядя на замечательное число 100%, что покрыты все существенные элементы.

Сперва хочу обратить на мое высказывание:

А что касается 100% покрытия, так оно, насколько я помню, вредно, с точки зренеия трудозатрат. Хотя опять же, смотря о каком покрытии вести речь :) И то что 100% покрытие ничего не гарантирует, я тоже согласен.

Конечно же 100% покрытие лучше чем 99% с точки зрения покрытия. Я даже не подвергаю это сомнению. Но иногда оно того не стоит. Например, когда для попадания в какую-то ветвь надо иметь устаревшее или дорогостоящее оборудование или когда надо работать с недоступными данными или ...

[barancev]

Вовсе нет, достижение 100% покрытия это очень хорошо, потому что любое числе меньше 100% оставляет сомнения относительно того небольшого количества элементов, которые остались непокрытыми. Мы должны каждый из них внимательно изучить, и если они несущественны -- явно исключить их из рассмотрения, используя возможности инструмента. И тогда мы сможем с уверенностью сказать, глядя на замечательное число 100%, что покрыты все существенные элементы.

Простой пример кода
a = b/c
и никакое 100% покрытие не поможет отловить ошибку деления на ноль.

... а также покрытие строки типа:
FileReader in = new FileReader(filename)
не поможет отловить ошибку, вызванную отсутствием файла, отсутствием прав на чтение, неправильным типом файла (директория или устройство записи), недопустимыми символами в имени, и т.д.

А кто спорит? Разве я где-то сказал, что тесты, обеспечивающие полное покрытие по строкам, гарантируют обнаружение хотя бы каких-нибудь ошибок?

[barancev]

Теперь к 100%.

Вовсе нет, достижение 100% покрытия это очень хорошо, потому что любое числе меньше 100% оставляет сомнения относительно того небольшого количества элементов, которые остались непокрытыми. Мы должны каждый из них внимательно изучить, и если они несущественны -- явно исключить их из рассмотрения, используя возможности инструмента. И тогда мы сможем с уверенностью сказать, глядя на замечательное число 100%, что покрыты все существенные элементы.

Сперва хочу обратить на мое высказывание:

А что касается 100% покрытия, так оно, насколько я помню, вредно, с точки зренеия трудозатрат. Хотя опять же, смотря о каком покрытии вести речь :) И то что 100% покрытие ничего не гарантирует, я тоже согласен.

Конечно же 100% покрытие лучше чем 99% с точки зрения покрытия. Я даже не подвергаю это сомнению. Но иногда оно того не стоит. Например, когда для попадания в какую-то ветвь надо иметь устаревшее или дорогостоящее оборудование или когда надо работать с недоступными данными или ...

Вот именно поэтому нужно пойти и пометить эту ветвь специальным образом, чтобы она не учитывалась при подсчёте покрытия. Потому что иначе, если мы видим при очередном запуске, что покрыто 99%, мы не можем сказать, что же осталось непокрытым -- может быть эта ветвь, а может быть в этот раз она случайно покрылась, но зато непокрытой осталась другая ветвь, которая раньше покрывалась.

[barancev]

Хотелось бы может услышать пример построения автоматизации, оценки и контроля работы...

Менеджер -- не статистик, он должен уметь работать с людьми, а не с числами.

[LeshaL]

Вот именно поэтому нужно пойти и пометить эту ветвь специальным образом, чтобы она не учитывалась при подсчёте покрытия. Потому что иначе, если мы видим при очередном запуске, что покрыто 99%, мы не можем сказать, что же осталось непокрытым -- может быть эта ветвь, а может быть в этот раз она случайно покрылась, но зато непокрытой осталась другая ветвь, которая раньше покрывалась.

Иде интересная, реализаций не встречал. Также, я не видел инструментов подсчёта покрытия, которые бы позволяли отфильтровывать что-то более мелкое чем целиком класс. Допускаю, что может быть реализовано для методов. Но для куска кода (блок) или одного из ветвлений (ветвь) - представить сложно - я пока не придумал.

Проще diff генеретить...