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

WishAway

Регистрация: 13 дек 2004
Offline Активность: 20 ноя 2013 10:14
-----

Мои сообщения

В теме: «2 метода идентификации объектов в TestComplete», бесплатный вебинар

10 сентября 2013 - 08:17

Будет ли мне интересен этот вебинар, если я уже прошла тренинг?


Да, полезным точно будет. На тренинге мы не рассматривали маппинг в деталях. Эта тема в курсе по подходам в автоматизации немного out of scope. На этом вебинаре я расскажу и покажу в деталях обычный маппинг, extended mapping, маппинг по child-объектам и работу с функциями поиска FindChild и FindAllChildren с обертками над этими методами для удобной работы.

Если не найдете для себя ничего нового - можно ведь отключиться от вебинара :)

Приходите :)

В теме: Новый курс "Подходы к разработке тестового фреймворка"

21 декабря 2012 - 09:52


Как вы думаете, какой способ лучше? Или где балланс?

Как по мне, киворды "низкого уровня" (типа кликнуть по кнопке или выбрать пункт в списке) нужны, но пользоваться ими надо пореже, по мере крайней необходимости. А в остальном пользоваться кивордами более высокого уровня.


Гена, все верно. Но на практике обычно KDT тесты пишут те, кто не разбирается в автоматизации и им тяжело понять, что можно использовать, а что не стоит и почему. Когда составляются тесты из кейвордов, люди (учитываем, что это не опытные автоматизаторы, а либо люди от бизнеса, либо ручные тестировщики) при малейшей проблеме готовы использовать все, что угодно, лишь бы заработало...
Поэтому на моей практике обычно список кейвордов фиксируется жестко на каком-то уровне. А вот как выбрать этот уровень - это уже задачка не из легких и однозначного ответа тут нет. В любом выбранном уровне будут плюсы и минусы. Вопрос в том, что перевешивает :)

В теме: Новый курс "Подходы к разработке тестового фреймворка"

21 декабря 2012 - 09:46

Имхо, понятие баланс - размыто. Все зависит от целей тестирования и текущей ситуации: насколько нужен KDT, перспективы, покрытие и проч.

Верно. Баланс выбирается в зависимости от проекта и задач. Но общие параметры для его выбора есть и их можно формализовать. Часто это помогает на начальных этапах проекта, чтобы выбрать оптимальный подход.

От меня требуется написание тестов как позитивных, так и негативных. Сделать отдельным параметром тип теста (позитив/негатив), в зависимости от этого параметра обрабатывать ошибочные сообщения там где надо. Т.е. если тест - негатив, то несохранившаяся сущность из-за незаполненности обязательных параметров - это, к примеру, успешный тест.

Я похожую задачу буду рассматривать на тренинге, но немного с другой стороны и с другим подходом

Набор данных у меня пока хранится в Dictionary, в сам тест передается именно словарь с набором данных. Далее я рассматриваю 2 варианта - таблица (excel) или XML.
Пока не знаю насколько все реально.

Вполне реально. На моей практике лучше таблица (excel) - удобнее и нагляднее. На тренинге я как раз на экселе буду все показывать. На реальных проектах также везде использую эксель и пока проблем не было. Так что вполне работает :)
Тем более в тест комплите есть "генерилка" данных для экселя. Вполне удобно для написания рандомных DDT-тестов для увеличения покрытия и для тестов надежности.

В теме: Новый курс "Подходы к разработке тестового фреймворка"

19 декабря 2012 - 15:00

Ну видите как здорово, уже почти раскрыли тему =)
Хотел бы я посмотреть все же на KDT. С TestComplete что идет в связке? Excel? В табличном редакторе пишется последовательность функций (сценарий), мб тестовый набор, разветвление..?

Я буду показывать на примере Excel. Хотя можно где угодно это хранить. В реальных проектах это часто интегрируется с тест-менеджмент системами и эти тесты из кейвордов пишутся прямо там. В этом есть и плюсы, и минусы.
Это больше последовательность кейвордов, а не функций. Да, они потом трассируются на функции в скриптах. Но не один к одному.
Ветвления в кейворд-тестах не желательны. Их можно реализовать (тот же кейворд по сути), но это может добавить путаницу.

чтобы ручной тестер мог написать тест сам, составляя его из готовых кубиков-функций.

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

Как вы думаете, какой способ лучше? Или где балланс?

Раз уж тема живая, давайте пообсуждаем :)

В теме: Новый курс "Подходы к разработке тестового фреймворка"

19 декабря 2012 - 13:39

а также
http://www.slideshar...riven-framework


Это ближе всего к тому, что я буду показывать на тренинге в рамках KDT. Только в упрощенной форме и на простых примерах. TAF - отличный инструмент, у меня была возможность на него посмореть (поскольку работаем с Мишей в одной компании), пример правильно реализованного KDT подхода.