Сообщений в теме: 2

[Vovka]

Вот, пытаюсь понять, оправданно ли тестирование основанное на моделях, расскажите кто сталкивался...

Пока есть сомнения в эффективности:
Создание модели - это те же затраты что разработка приложения, учесть все моменты, ifы, переходы... + разработка вспомогательных скриптов генерящих тесты на основе модели + модули непосредственно исполнения тестов.
Ирак получается что затраты больше чем разработка собственно приложения, а результат? - мы можем сравнить сложное разработанное приложение, со сложной разработанной моделью и найти отличия! И сколько тех же ошибок мы допустили в модели что и в приложении, ведь сложность разработки обоих велика ?

[Mike]

Если представить себе модель, полностью покрывающую всю функциональность приложения, то затраты действительно сравнимы. Всё зависит от Ваших потребностей в качестве и эффективности других подходов. Но тут есть несколько моментов:
- внедрение автоматизированной генерации тестовых данных даже при относительно слабой (неподробной) модели и самых простых оракулах кардинально увеличивает тестовое покрытие
- для достаточно сложных систем затраты на ручное тестирование (особенно временные) несопоставимо больше чем необходимые для автоматизации. Скажем так - при линейном росте затрат на разработку самого приложения, затраты на ручное тестирование (при неизменном качестве разработки) растут нелинейно (может, и не по экспоненте, но вроде того), а затраты на model-based автоматизацию по-прежнему растут линейно (понятно, до определённого придела, но предел этот много выше чем у ручного тестирования или "классической" автоматизации регрессионного тестирования).

[yaha]

Попытался применить Model-Based тестирование на одной из части приложения. Точнее говоря, не применить в полном смысле этого слова, а разработать хотя бы модель для дальнейшего использования для генерации тест-кейсов.
Итак, исходные данные. Есть два диалоговых окна, следующие одно за другим. В обоих окнах есть функция добавления элементов, так и буду их дальше называть – элементы. В целом это похоже на некий Install Wizard с кнопками Next и Prev.
Функции первого окна:
1. Next – открывает второй диалог. Если элемент был добавлен, то он отображается во втором диалоге.
2. Skip1 – открывает второй диалог. Если элемент был добавлен, то он не отображается во втором диалоге.
3. Cancel1 – закрывает диалог и возвращается в основное окно. Все изменения не сохраняются.
Функции второго окна:
1. Prev – возвращается в первый диалог. Если элемент был добавлен, то он не отображается в первом диалоге.
2. Save – закрывает диалог и на основном окне отображает все добавленные элементы или ни одного, если ничего не было добавлено.
3. Skip2 – закрывает диалог и на основном окне отображает все элементы, добавленные в первом окне или ни одного, если ничего не было добавлено.
4. Cancel2 – закрывает диалог и возвращается в основное окно. Все изменения не сохраняются.

Начал с того, что причитал статью Гарри Робинсона “Intelligent Test Automation”, где есть примеры, и начал делать по образу и подобию. Сначала разделил эту систему на части-состояния и начал устанавливать между ними связи. Всё было как по написанному – отвечаем на вопросы Когда и Что Будет.
Получилось у меня 6 (шесть) состояний:
1. Первый диалог пустой
2. Первый диалог с элементом
3. Второй диалог пустой
4. Второй диалог с элементом
5. Основное окно пусто
6. Основное окно с элементами
Из этого набора состояний и функций можно составить граф переходов, и, соответственно матрицу.
Матрица переходов (см. аттач MBT01.doc)

Сразу поясню, почему имеются неоднозначности в переходах, на примере состояния 1, когда по Next можно перейти в состояние 3 либо 4. Но если с переходом 1 – Next – 3 все понятно, то с 4 могут быть вопросы. Из состояния 4 по Prev мы можем вернуться в 1, далее, по Next опять попадем в состояние 4. По аналогии можно объяснить и остальные «двойные» случаи. Однако если мы начнем генерировать тест-кейсы, мы столкнемся с нетривиальной задачей поиска путей обхода вершин, поскольку алгоритм поиска может выдать неверный результат.
Например, нам нужно найти все возможные пути из начального состояния 1, в любое из конечных состояний 5 или 6. Путь не должен содержать повторяющиеся вершины. Один из найденных путей может быть таким: 1 – Next – 4 – Prev – 2 – Cancel1 – 5, и таких неверных путей может быть много. Следовательно, в алгоритм поиска нужно вставлять условия, по которым возможен тот или иной переход. Но в этом случае мы имеем не унифицированный и довольно сложный алгоритм, привязанный строго к текущей задаче. Даже при небольшом изменении в логике системы мы будем менять и модель и алгоритм.
Покумекал я недолго и решил избавляться от неоднозначности, что даст нам унифицированный алгоритм поиска для вообще любой подобной системы.
Оттолкнулся от того, что состояние одного из диалога зависит от состояния другого, т.е. при описании состояния диалога надо учитывать состояние другого. Отсюда для каждого диалога имеем 4 состояния
Для начала представим первый диалог:
1. Первый диалог без элемента, второй без элемента.
2. Первый диалог без элемента, второй с элементом.
3. Первый диалог с элементом, второй без элемента.
4. Первый диалог с элементом, второй без элемента.
Второй диалог совершенно аналогично:
5. Первый диалог без элемента, второй без элемента.
6. Первый диалог без элемента, второй с элементом.
7. Первый диалог с элементом, второй без элемента.
8. Первый диалог с элементом, второй без элемента.
Соответственно и главное окно тоже будет иметь больше состояний:
9. Основное окно пусто.
10. Основное окно содержит элемент из второго диалога.
11. Основное окно содержит элемент из первого диалога.
12. Основное окно содержит элемент из обоих диалогов.
Опять же был составлен граф переходов (см. аттач ModelBasedTestingGraph.JPG) и построена матрица (см. аттач MBT02.doc), но пришлось добавить новые переходы: Add1 – добавление элемента в первом диалоге, Del1 – удаление элемента из первого диалога, и, соответственно, Add2 и Del2.

Теперь у нас нет неоднозначностей, и алгоритм поиска путей будет одинаковым для любой реализации системы такого рода.
Естественно, что это, по сути, очень простая система, но стоит добавить третье подобное окно и состояний становится больше на 16, а переходов – на 6.
При автоматизации всего процесса тестирования мы все равно должны использовать стандартные средства, которые сильно привязаны к интерфейсу и дизайну системы. На первый взгляд затраты на поддержку скриптов в актуальном состоянии будут по-прежнему сравнимы с затратами и без использования подхода Modal-Based Testing. Если теоретически идеализировать процесс скриптизации, то все переходы можно оформлять как некие процедуры или функции, которые лишь вызываются в соответствии с путем, найденным алгоритмом поиска путей. Сам же путь есть ни что иное как тест-кейс.
Однако не стоит забывать и о технических проблемах – поддержка скриптов дело хлопотное в любом случае. Поддержка скриптов в случае Model-Based Testing сводится к изменению процедур переходов из состояния в состояние, при этом не затрагивается логика, которая представлена матрицей и сгенерированными путями. Это в идеале. На практике изменение скрипта всё же должно (или может) предполагать знание логики, что все же усложняет поддержку.
Здесь я не берусь точно утверждать в каких случаях поддержка сложнее, но плюсом описываемого подхода считаю отделение логики от процедур и, конечно, автоматическую генерацию кейсов.
Если даже не применять автоматизацию, то автоматическая генерация может дать некоторые пути в приложении, которые могут быть пропущены при ручном составлении кейсов, то есть, по-русски, увеличить тестовое покрытие.

Прикрепленные файлы

•  MBT01.doc   33,5К   103 Количество загрузок:
•  MBT02.doc   48К   88 Количество загрузок:
•  ModelBasedTestingGraph.JPG   47,88К   115 Количество загрузок: