Pull to refresh

Comments 18

Сколько программистов нужно, чтобы отладить программу? Один чтобы искать ошибки и второй — чтобы ему мешать.
Предположим, что вероятность обнаружения для естественных и искусственных ошибок одинакова. Тогда выполняется соотношение ...


Из первого, увы, не следует второе. См. тервер :).
Конечно не следует, но зачем усложнять модель. Да если расписывать «адекватность» модели, то это будет достаточно сложно и возможно статья вообще не появится :) А из первого только следует, что функция распределения одинаковы, то есть вероятность P_m,n (найти m ошибок из n) P_m,n=P_k,l при условии что m/n=k/l. Ну а сами числа зависят конечно от тестировщика, именно от него как раз и зависит адекватность этой модели.
Даже если предельно упростить, то ключевую фразу «для значений M и N достаточно больших, чтобы...» вырезать, увы, не удасться. Для выборки в десять или даже сто особей статистика и тервер, увы, не работают :)
Почему усложнять-то? Просто надо аккуратней выражаться. «Из чего сделаем допущение, что для программ с достаточно большим количеством ошибок выполняется соотношение» смотрелось бы гораздо лучше, чем категоричное «Тогда выполняется соотношение».

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

1. Чем должен руководствоваться перый программист при создании ошибок. Он может расставить кое-где в методах throw new RuntimeException, или, например, поменять рандомно арифметические и логические операторы, или поудалять кое-какие условия. На мой взгляд, все эти внесенные ошибки будут весьма неглубокими и легко локализуемыми. Чего, к сожалению, нельзя сказать о настоящих ошибках. Может быть есть какой-то другой способ?

2. Как определить, сколько времени нужно дать на поиск ошибок? Допустим, у нас их десять. По часу на каждую? Можем ли мы утверждать наверняка?

Кроме того, если покрытие кода тестами заметное, то и внести ошибки в код таким образом, чтобы не падали тесты, очень трудно. С другой стороны, смысла вносить ошибки, которые приводят к падению тестов, нет. Так что задача «вредителя» — человека, расставляющего ошибки — очень усложняется. То есть мы не можем просто так взять и решить в середине проекта, что мы хотим оценить общее число ошибок, не учтя при этом, что как минимум двум разработчикам — «вредителю» и «ищущему» придется затратить на это весьма заметное время.

Плюсы в этом, конечно, есть — можно оценить общий объем предстоящей работы, но и о временных затратах забывать нельзя.
Как я себе вижу, данная модель скорее оценивает качество тестов, и, косвенно, качество кода. Т.е. у Вас есть набор тестов. Вы вносите в тестируемый код некоторое количество ошибок, после прогоняете тесты. Получаете некоторое количество ошибок. По количеству пойманных искусственных ошибок рассчитывается число пропущенных естественных.
Я так понял применение данной модели.
Для оценки количества тестов существует другая модель. Даже не модель, а некоторая абстрактная формула. Однако, под неё нужен отдельный топик, так просто в комментарие её не напишешь, а в интернете эту информацию найти не могу.
У меня «качество тестов», у вас «количество тестов». Вы очепятались или говорите о другом?
Да, я неверно прочитал.
Он может расставить кое-где в методах throw new RuntimeException, или, например, поменять рандомно арифметические и логические операторы, или поудалять кое-какие условия.

Учитывая, что эта методика 72 года, вполне возможно, она ориентированна именно на такие ошибки и опечатки. Ведь тогда не было навороченных IDE и утилит анализа кода, что бы находить их. А в проектах использовалось меньше различных компонент и библиотек, которые могут породить сложные ошибки взаимодействия.
Только вчера читал про эту модель. Доверия конечно не внушает да и реализовать сложновато, но более адекватного способа, к сожалению, мне найти не удалось:(
Существует модель «Парная» оценка. На мой взгляд, она намного адекватнее миллсовой модели. Также есть способ «Исторический опыт», но он слишком специфичен.
Для 1972 года — вполне себе отличная работающая идея.

В современных реалиях: если код покрыт автотестами, то внести туда нетривиальную детерменированную багу таким образом, чтобы все автотесты проходились — кажется мне очень непростым делом.

расстановка таких рэндомов
if(someCondition || random*1000 == 42)
не в счёт)

+Ошибки многопоточности — остаются совсем в стороне

Очень смущает гипотеза о том что вероятность найти естественные и искусственные ошибки одинаковая. Методика их создания и процесс совершенно разные и потому вероятности тоже.
А существуют ли другие подобные модели для оценки количества ошибок?
Скажите, а зачем вообще нужно знать число N?
За всё моё время работы в тестировании мне ни разу не понадобилось это знать.

Более того, смотря в любой дефект-трэкер можно увидеть, что из числа найденных багов n, чинится только некоторое кол-во F. И на мой взгляд отношение F/n намного более интересно, чем абстрактная величина N или даже N-n.

PS: в любом случае было бы интересно узнать о других способах, о которых вы упомянули.
Sign up to leave a comment.

Articles