mfp: Late night discussions on software development #3: Unit testing

[gl00mie]

Такие вот рассуждения, как в приведенной публикации из блога, и приводят, кроме прочего, к осознанию, что программирование - это не только знание синтаксиса, определенных API/технологий и неких Best Practices, завещанных предыдущими поколениями программистов без каких-либо комментариев и разъяснений Касаемо тестирования можно вспомнить рассуждения из одной очень хорошей книги (пусть кто-то и считает, что в ней 95% воды):

Цитата:

Ограничения тестирования, выполняемого разработчиками.
Разработчкики обычно выполняют «чистые тесты». Разработчики склонны тестирвовать код на предмет того, работает ли он (чистые тесты), а не пытаться нарушить его работу всевозможными способами (грязные тесты).

возможно, это и пытался сказать S?ren, рассуждая о бесполезности и даже контрпродуктивности тестов, которые всегда проходят успешно

Цитата:

В организациях с незрелым процесом тестирования обычно выполняют около пяти чистых тестов на каждый грязный. В организациях со зрелым процессом тестирования на каждый чистый тест обычно приходится пять грязых тестов. Это отношение изменяется на противоположное не за счет снижения числа чистых тестов, а за счет создания в 25 раз большего числа грязных тестов.
Разработчики часто имеют слишком оптимистичное представление о покрытии кода тестами. Как правило, программисты считают, что они достигают 95%-го покрытия кода тестами, но на самом деле они обычно достигают в лучшем случае примерно 80%-го покрытия, в худшем - 30%-го, а в среднем - где-то на 50-60% (по данным Boris Beizer, 1990, «Software Testing Techniques», 2nd ed, NY: Van Nostradam Reinhold).
Разработчики часто упускают из виду более сложные аспекты покрытия кода тестами. Большинство разработчиков считают тип покрытия кода тестами, известный как «100%-е покрытие операторов», адекватным. Это хорошее начало, но такого покрытия едва ли достаточно. Лучший тип покрытия - так называемое «100%-е покрытие ветвей», требующее, чтобы каждой переменной каждого предиката при тестировании было присвоено хотя бы одно истинное и одно ложное значение.
Эти ограничения не уменьшают важность тестирования, выполняемого разработчиками, - они лишь помогают получить о нем более адекватное представление.

А также

Цитата:

Некоторые методики более эффективны в обнаружении дефектов, чем другие, к тому же разные методики приводят к обнаружению разных дефектов. Одним из способов оценки методик обнаружения дефектов является определение процента обнаруженных дефектов из общего количества дефектов, имеющихся в программе на конкретном этапе. Показатели эффективности обнаружения дефектов при использовании некоторых популярных методик указаны в таблице:

Методика устранения дефектов		Минимальная	Типичная	Максимальная
					эффективность	эффективность	эффективность
Неформальные обзоры проекта		25%		35%		40%
Формальные инспекции проекта		45%		55%		65%
Неформальные обзоры кода		20%		25%		35%
Формальные инспекции кода		45%		60%		70%
Моделирование или прототипирование	35%		65%		80%
Самостоятельная проверка кода		20%		40%		60%
Блочное тестирование			15%		30%		50%
Тестирование новых функций/компонентов	20%		40%		60%
Интеграционное тестирование		25%		35%		40%
Регрессионное тестирование		15%		25%		30%
Тестирование системы			25%		40%		55%
Ограниченное бета-тестирование		25%		35%		40%
(менее чем в 10 организациях)
Крупномасштабное бета-тестирование	60%		75%		85%
(более чем в 1000 организаций)

Источники: Capers Jones, 1986, «Programming Productivity», NY: McGraw-Hill; Capers Jones, 1996, «Software Defect-Removal Efficiency», IEEE Computer; Shull, et al., 2002, «What We Have Learned About Fighting Defects», Proceedings, Metrics 2002. IEEE; 249-258.
Самое интересное в этих данных то, что типичная эффективность обнаружения дефектов при использовании любой методики не превышает 75% и что в среднем она равна примерно 40%. Более того, самые популярные методики - блочное тестирование и интеграционное тестирование - позволяют найти обычно только около 30-35% дефектов. Как правило, используется подход, основанный на интенсивном тестировании, что позволяет устранить лишь около 85% дефектов. Ведущие организации используют более широкий диапазон методик, достигая при этом 95%-ой или более высокой эффективности устранения дефектов (Capers Jones, 2000, «Software Assessments, Benchmarks, and Best Practices», Reading MA: Addison-Wasley). Итак, если разработчики хотят достигнуть более высокой эффективности обнаружения дефектов, они должны полагаться на комбинацию методик.