lurk

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

Что бы сделал я? Взял бы пару листов А3 и написал:
- Что вообще можно тестировать - вообще все знакомые слова - юзабилити, орфографию, логику, регрессию, безопасность, нагрузочное тестирование, боевой сервер, тестовый стенд. Слов 20.
- Как я могу тестировать: пецкать руками, найти рабов бета тестеров, написать автотесты, записать сценарии, столкнуть работу на коллегу,
- Когда я буду это делать? Ночами, по утрам, 4 часа в день, срок - ближайший месяц, день, год. Исходя из сроков вычеркнуть нереальное из первых двух пунктов.
- Узнать, на кой это все надо. Чего от меня ждут. Может ждут сто багов. Может ждут качество. Может ждут отчет. С учетом этой строки - пересортировать все, что выше.
- Представить себе конечный результат. Список багов? Где этот список? На листочке? В трекере? Налаженный процесс разработки и тестирования? Как выглядит налаженность? Отчет? В экселе, в ворде? Как выдадут бабло? На карту, налом, вебманями?

Ага, я понял. Сергей, Вы смешиваете два понятия -- анализ моделей (model checking) и тестирование на основе моделей (model-based testing).

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

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

Чтобы понять разницу более фактурно, представьте, что Вы разработали замечательную модель, включающую всё, что Вам хочется (в том числе стихийные бедствия, пожары и т.д. :)), потом проверили, что эта модель действительно удовлетворяет всем требованиям, короче -- конфетка. А потом Ваши программисты разработали реальную программную систему, которая ЯКОБЫ реализует эти требования и ЯКОБЫ должна соответствовать модели. А как проверить, соответствует ли на самом деле? Вот этим и занимается model-based testing.

Здравствуйте!

 

Давно интересует вопрос, использует ли кто-то на практике тестирование на основе моделей (Model-Based Testing). Я имею в виду, для действительно сложных случаев, когда автоматически сформированные тестовые последовательности было бы сложно реализовать вручную.

 

Фактически, MBT соответствует технике тест-дизайна с применением диаграммы состояний и переходов.

Так вот, на практике встречал 3 случая:

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

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

3) Юнит-тесты, которые проходят за мгновения, поэтому несколько тысяч тестов - не проблема.

 

Интересно, в каких случаях возможно применение MBT, так, чтобы диаграмма была и не слишком простая, и не астрономически сложная.

Или же это всё миф, и концепт не имеет практического применения для "медленных" UI-тестов.