Перейти к содержимому

Аудит и оптимизация QA-процессов
онлайн, начало 4 декабря
Практикум по тест-дизайну 2.0
онлайн, начало 4 декабря
Школа Тест-Аналитика
онлайн, начало 9 декабря
Школа тест-менеджеров v. 2.0
онлайн, начало 9 декабря

Публикации yaha

10 публикаций создано yaha (учитываются публикации только с 04 декабря 2019)


#34952 Идея организовать встречу в оффлайн - Москва

Отправлено автор: yaha 27 октября 2006 - 11:55 в Свободное общение

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



#34332 Эффективно ли тестирование основанное на моделях ?

Отправлено автор: yaha 09 октября 2006 - 08:01 в Автоматизированное тестирование

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

Прикрепленные изображения

  • ModelBasedTestingGraph.JPG

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

  • Прикрепленный файл  MBT01.doc   33,5К   103 Количество загрузок:
  • Прикрепленный файл  MBT02.doc   48К   88 Количество загрузок:



#34189 Кто же такой хакер?

Отправлено автор: yaha 04 октября 2006 - 10:38 в Свободное общение

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

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



#34164 Кто же такой хакер?

Отправлено автор: yaha 04 октября 2006 - 08:12 в Свободное общение

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



#34156 Кто же такой хакер?

Отправлено автор: yaha 04 октября 2006 - 07:11 в Свободное общение

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

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

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

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

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

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



#25245 Создание и хранение Test Cases

Отправлено автор: yaha 17 февраля 2006 - 08:58 в Тест-дизайн и ручное тестирование

Недавно столкнулся с тулзой T-Plan.
На ощуп она вроде ничего. Умеет traceability, пошаговые тест-кейсы, отчеты Crystal Report, экспорт отчетов в любой другой формат, свой багтрекер, связь кейса с тестовыми скриптами, импорт требований из какой хочешь системы.
Отчеты, импорт/экспорт и связь со скриптами обеспечивается за счет Extensions (это типа Add-on, Plugin и пр.)
Просто всем хороша тулза.
А есть ли люди, которые внедрили её у себя в компании?



#24049 Система для хранения тест-кейсов

Отправлено автор: yaha 23 января 2006 - 12:19 в Тест-дизайн и ручное тестирование

Тест линк использую, замечания к программе есть, но с учетом OpenSource всё в вашик руках.

TestLog юзал раньше. Мне она нравилась, пока не наткнулся на предыдущую. Для вас минус в том, что в тест кейс нельзя вставлять картинки и пр.
Минусы её в том, что она никак не настраивается. В целом для начала неплохая тулза.

Про остальные ничего не слышал. Однако где-то были у меня ссылки на много фришных тулов. Например, была какая-то программа для Access. Была просто гуйня, распространяемая фри. Как найду, кину линки (если найду :help: )



#23882 История изменения testcaseов в TestLinke.

Отправлено автор: yaha 17 января 2006 - 15:29 в Тест-дизайн и ручное тестирование

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



#23776 а где же Testexecutor

Отправлено автор: yaha 13 января 2006 - 13:44 в Тест-дизайн и ручное тестирование

TestLink довольно бажная системка. То у нее билды не удаляются, то планы не сохраняются. Однако, поскольку она OpenSource, то можно всё подправить самому.
Я свою тестлинку так перелопатил, что теперь уж и не узнать )))



#22568 Задачка про продажу шапки

Отправлено автор: yaha 08 декабря 2005 - 14:31 в Свободное общение

Продавца обманули на 40 рублей. Походу ни один отдел верно не решил )))




Яндекс.Метрика
Реклама на портале