yaha

Народ!! Это было 2 года назад, смотрите даты сообщений :))

Попытался применить 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 сводится к изменению процедур переходов из состояния в состояние, при этом не затрагивается логика, которая представлена матрицей и сгенерированными путями. Это в идеале. На практике изменение скрипта всё же должно (или может) предполагать знание логики, что все же усложняет поддержку.
Здесь я не берусь точно утверждать в каких случаях поддержка сложнее, но плюсом описываемого подхода считаю отделение логики от процедур и, конечно, автоматическую генерацию кейсов.
Если даже не применять автоматизацию, то автоматическая генерация может дать некоторые пути в приложении, которые могут быть пропущены при ручном составлении кейсов, то есть, по-русски, увеличить тестовое покрытие.

Если из A=>B, то это не значит, что из B=>A

Совершенно верно! Значит с этим мы уяснили.
Но я категорически не согласен с вашим утверждением, что в высший класс входит умение сломать web-интерфейс.

Тогда встречный вопрос и завяжем с вопросами.
Человек, который может привести Web-интерфейс в неработоспособность является ли тестировщиком высшего класса?

Каковы Ваши мнения по идеальному работнику и относится ли к ним хакер?

Идеальный работник определенно может не быть да и не обязан быть хакером. В свою очередь хакер может быть далеко не идеальным работником.
Отсюда приходим к выводу что идеальный работник и хакер вещи не сравнимые и не коррелируемые.

А по поводу этого:

Тестировщик высшего класса - знает как привести Web-интерфейс в неработоспособность;

Если тестировщик имеет огромный опыт автоматизации и нагрузочного тестирования, обладает знаниями стандартов и методологий разработки ПО, и просто эрудированный человек, но (вот незадача) не умеет приводить в неработоспособность Web-интерфейс, то он не тестировщик высшего класса? Простите, несогласен.
Здесь вы ошибочно приписали наличие частного знания (взломать Web) как критерий, определяющий более общее понятие (высший класс в тестировании).

PS: Профессионал от слова профессия