Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Сколько программистов нужно, чтобы отладить программу? Один чтобы искать ошибки и второй — чтобы ему мешать.
Предположим, что вероятность обнаружения для естественных и искусственных ошибок одинакова. Тогда выполняется соотношение ...
Из первого, увы, не следует второе. См. тервер :).
Конечно не следует, но зачем усложнять модель. Да если расписывать «адекватность» модели, то это будет достаточно сложно и возможно статья вообще не появится :) А из первого только следует, что функция распределения одинаковы, то есть вероятность P_m,n (найти m ошибок из n) P_m,n=P_k,l при условии что m/n=k/l. Ну а сами числа зависят конечно от тестировщика, именно от него как раз и зависит адекватность этой модели.
Даже если предельно упростить, то ключевую фразу «для значений M и N достаточно больших, чтобы...» вырезать, увы, не удасться. Для выборки в десять или даже сто особей статистика и тервер, увы, не работают :)
Почему усложнять-то? Просто надо аккуратней выражаться. «Из чего сделаем допущение, что для программ с достаточно большим количеством ошибок выполняется соотношение» смотрелось бы гораздо лучше, чем категоричное «Тогда выполняется соотношение».
А то это просто дезинформация неосведомленного читателя, который вряд ли придет в восторг от теории, увидев, что она не работает. Откуда ему знать-то, что просто автор не потрудился указать рамки ее применимости?
А то это просто дезинформация неосведомленного читателя, который вряд ли придет в восторг от теории, увидев, что она не работает. Откуда ему знать-то, что просто автор не потрудился указать рамки ее применимости?
Метод сам по себе интересный, другое дело, что применить на практике его довольно сложно. Возмем сценарий: один программист расставляет в коде случайные ошибки, а второй их ищет. Возникают вопросы:
1. Чем должен руководствоваться перый программист при создании ошибок. Он может расставить кое-где в методах throw new RuntimeException, или, например, поменять рандомно арифметические и логические операторы, или поудалять кое-какие условия. На мой взгляд, все эти внесенные ошибки будут весьма неглубокими и легко локализуемыми. Чего, к сожалению, нельзя сказать о настоящих ошибках. Может быть есть какой-то другой способ?
2. Как определить, сколько времени нужно дать на поиск ошибок? Допустим, у нас их десять. По часу на каждую? Можем ли мы утверждать наверняка?
Кроме того, если покрытие кода тестами заметное, то и внести ошибки в код таким образом, чтобы не падали тесты, очень трудно. С другой стороны, смысла вносить ошибки, которые приводят к падению тестов, нет. Так что задача «вредителя» — человека, расставляющего ошибки — очень усложняется. То есть мы не можем просто так взять и решить в середине проекта, что мы хотим оценить общее число ошибок, не учтя при этом, что как минимум двум разработчикам — «вредителю» и «ищущему» придется затратить на это весьма заметное время.
Плюсы в этом, конечно, есть — можно оценить общий объем предстоящей работы, но и о временных затратах забывать нельзя.
1. Чем должен руководствоваться перый программист при создании ошибок. Он может расставить кое-где в методах throw new RuntimeException, или, например, поменять рандомно арифметические и логические операторы, или поудалять кое-какие условия. На мой взгляд, все эти внесенные ошибки будут весьма неглубокими и легко локализуемыми. Чего, к сожалению, нельзя сказать о настоящих ошибках. Может быть есть какой-то другой способ?
2. Как определить, сколько времени нужно дать на поиск ошибок? Допустим, у нас их десять. По часу на каждую? Можем ли мы утверждать наверняка?
Кроме того, если покрытие кода тестами заметное, то и внести ошибки в код таким образом, чтобы не падали тесты, очень трудно. С другой стороны, смысла вносить ошибки, которые приводят к падению тестов, нет. Так что задача «вредителя» — человека, расставляющего ошибки — очень усложняется. То есть мы не можем просто так взять и решить в середине проекта, что мы хотим оценить общее число ошибок, не учтя при этом, что как минимум двум разработчикам — «вредителю» и «ищущему» придется затратить на это весьма заметное время.
Плюсы в этом, конечно, есть — можно оценить общий объем предстоящей работы, но и о временных затратах забывать нельзя.
Как я себе вижу, данная модель скорее оценивает качество тестов, и, косвенно, качество кода. Т.е. у Вас есть набор тестов. Вы вносите в тестируемый код некоторое количество ошибок, после прогоняете тесты. Получаете некоторое количество ошибок. По количеству пойманных искусственных ошибок рассчитывается число пропущенных естественных.
Я так понял применение данной модели.
Я так понял применение данной модели.
Он может расставить кое-где в методах throw new RuntimeException, или, например, поменять рандомно арифметические и логические операторы, или поудалять кое-какие условия.
Учитывая, что эта методика 72 года, вполне возможно, она ориентированна именно на такие ошибки и опечатки. Ведь тогда не было навороченных IDE и утилит анализа кода, что бы находить их. А в проектах использовалось меньше различных компонент и библиотек, которые могут породить сложные ошибки взаимодействия.
Только вчера читал про эту модель. Доверия конечно не внушает да и реализовать сложновато, но более адекватного способа, к сожалению, мне найти не удалось:(
Для 1972 года — вполне себе отличная работающая идея.
В современных реалиях: если код покрыт автотестами, то внести туда нетривиальную детерменированную багу таким образом, чтобы все автотесты проходились — кажется мне очень непростым делом.
расстановка таких рэндомов
if(someCondition || random*1000 == 42)
не в счёт)
+Ошибки многопоточности — остаются совсем в стороне
В современных реалиях: если код покрыт автотестами, то внести туда нетривиальную детерменированную багу таким образом, чтобы все автотесты проходились — кажется мне очень непростым делом.
расстановка таких рэндомов
if(someCondition || random*1000 == 42)
не в счёт)
+Ошибки многопоточности — остаются совсем в стороне
Очень смущает гипотеза о том что вероятность найти естественные и искусственные ошибки одинаковая. Методика их создания и процесс совершенно разные и потому вероятности тоже.
А существуют ли другие подобные модели для оценки количества ошибок?
Скажите, а зачем вообще нужно знать число N?
За всё моё время работы в тестировании мне ни разу не понадобилось это знать.
Более того, смотря в любой дефект-трэкер можно увидеть, что из числа найденных багов n, чинится только некоторое кол-во F. И на мой взгляд отношение F/n намного более интересно, чем абстрактная величина N или даже N-n.
PS: в любом случае было бы интересно узнать о других способах, о которых вы упомянули.
За всё моё время работы в тестировании мне ни разу не понадобилось это знать.
Более того, смотря в любой дефект-трэкер можно увидеть, что из числа найденных багов n, чинится только некоторое кол-во F. И на мой взгляд отношение F/n намного более интересно, чем абстрактная величина N или даже N-n.
PS: в любом случае было бы интересно узнать о других способах, о которых вы упомянули.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оценка количества ошибок в программе. Модель Миллса