Без заголовка

Обобщу тезисно свой опыт моделирования, применительно к задачам тестирования: 1. Понятно, что тесты писать рукам лень, надо их генерировать. Ибо если их тупо писать руками, то получается огромная масса кода (на порядок больше нежели тестируемый код), которую на порядок труднее сопровождать. 2. Следовательно нужны модели - т.е. какие-то компактные и понятные человеку (пусть и не всякому) описания, из которых можно генерить тесты. Ну и при изменениях обстановки, подправить модель и перегенерить всю массу тестов. 3. Генерить тесты из модели большой проблемы не составляет, есть куча тулзов и подходов, нетрудно самому генерировать. Проблема состоит в задании моделей. Еще есть проблема с прогоном этих тестов и донесением результатов до остальных - но будем считать, что это мелочи (грубо говоря, цели тестирования достигнуты, а это уже проблемы другого рода). 4. Одна из основных проблем при моделировании - императивность современных Си-подобных языков. Императивные модели - это полная жопа. Модели должны быть декларативными, иначе ими невозможно манипулировать/преобразовывать из-за наличия сайд-эффектов. Программист относительно легко учитывает последствия сайд-эффектов (не всегда корректно правда :)), компьютер пока их учитывает с трудом. 5. Лучше всего если модели не просто декларативные, а логические - т.е. вычисления идут в две стороны: и по параметрам вычисляем результат, и по результатам вычисляем параметры. Еще лучше, если модели задаются в ограничениях - это, по видимому, наиболее естественные для человека способ задания моделей. Ибо ограничения аддитивны. 6. Другая проблема моделирования - перво-порядковость. Если "язык" моделирования основывается на перво-порядковой концепции, то реализация очень сильно упрощается, следовательно, это должно быть желательное свойство таких моделей. К сожалению, это сильно затруднят жизнь программерам. Поэтому, практичные языки моделирования по большей части высокопорядковые. Иначе замучаешься работать. Ученого в борьбе за истину это конечно не остановит. Но инженер рано или поздно задолбается, и начнет вводить высокпорядковость так или иначе, путем генерации моделей и прочей меты-. 7. Вылезает другая проблема: у высокопорядковых языков имеются серьезные проблемы с реализацией/анализом. Частично они решаются путем устранения высокопорядковости, но это возможно не всегда. 8. В тестировании, вообще говоря, полный анализ, не нужен, достаточно протестировать просто очень много "разумных" случаев. Так что тут можно реализовать компромисс. Т.е. иметь с одной стороны высоко-порядковые описания, а с другой методы их анализа/перебора на определенную глубину, которые будут давать покрытие в районе 95-99%. За счет хитрых эвристик, можно исключать эквивалентные тестовые случаи, и сильно облегчать перебор таким образом. Теоретически, набор таких эвристик велик. На практике, они разрозненны и их нужно свести в единую систему (в данном случае, систему тестирования). Тут промышленно-применимых систем пока мало, но какие-то есть (взять тот же Coq).