Работа с БД из Rational Robot
#1
Отправлено 18 марта 2009 - 05:48
Если возможно, то комментарии про квалификацию тестеров опустим
#2
Отправлено 18 марта 2009 - 07:30
См. пример тутСтоит такая задача - проверять введенные данные не только на клиентсокй части ПО, но и с помощью запросов к БД серверной части. Понятно что можно все это сделать из скрипта, но похоже предстоит обучать этому некоторое количество тестеров которые не очень дружат с программированием. Может у кого-то есть наработки по похожим проблемам? как сделать это с минимальными правками записанного GUI срипта? Хочется минимизировать возможность правки скрипта руками тестера. В идеале конечно хотелось бы найти возможность создания подобной VP прямо в роботе :)
Если возможно, то комментарии про квалификацию тестеров опустим
#3
Отправлено 18 марта 2009 - 07:40
как раз от такого примера и хочется отказаться. Хочется минимизировать количество ручного ввода кода в скрипт. То есть тестер в идеале должен получить скрипт делая те же действия мышкой и клавой что и в обычной жизни. Например в TestComplete это делается очень удобно.См. пример тут
#4
Отправлено 18 марта 2009 - 10:17
Код (запросы к базе) в любом случае надо писать. Я тогда не очень понял, что вам надо. Сделайте проверку в другом инструменте, не в RFT. Если например вы хотите узнать, какой программный код выполняется по "тыканью" кнопок в GUI, воспользуйтесь SQL Monitor например, но это если к button-у прикреплена какая-нибудь API-шная функция/иикак раз от такого примера и хочется отказаться. Хочется минимизировать количество ручного ввода кода в скрипт. То есть тестер в идеале должен получить скрипт делая те же действия мышкой и клавой что и в обычной жизни. Например в TestComplete это делается очень удобно.См. пример тут
#5
Отправлено 19 марта 2009 - 04:53
Хочется придумать такой способ, при котором простой (рядовой) тестер не сильно владеющий навыками программирования сможет самостоятельно проверят корректность данных в БД. склоняюсь к мнению что это можно сделать только через стороннее приложение.Код (запросы к базе) в любом случае надо писать. Я тогда не очень понял, что вам надо. Сделайте проверку в другом инструменте, не в RFT. Если например вы хотите узнать, какой программный код выполняется по "тыканью" кнопок в GUI, воспользуйтесь SQL Monitor например, но это если к button-у прикреплена какая-нибудь API-шная функция/иикак раз от такого примера и хочется отказаться. Хочется минимизировать количество ручного ввода кода в скрипт. То есть тестер в идеале должен получить скрипт делая те же действия мышкой и клавой что и в обычной жизни. Например в TestComplete это делается очень удобно.См. пример тут
#6
Отправлено 19 марта 2009 - 05:16
Стоит такая задача - проверять введенные данные не только на клиентсокй части ПО, но и с помощью запросов к БД серверной части. Понятно что можно все это сделать из скрипта, но похоже предстоит обучать этому некоторое количество тестеров которые не очень дружат с программированием. Может у кого-то есть наработки по похожим проблемам? как сделать это с минимальными правками записанного GUI срипта? Хочется минимизировать возможность правки скрипта руками тестера. В идеале конечно хотелось бы найти возможность создания подобной VP прямо в роботе :)
Если возможно, то комментарии про квалификацию тестеров опустим
проблема даже не столько в квалификации, сколько в утомительности этого занятия. с большой вероятностью после 15 проверок базы, на 16й раз человек забудет это сделать.
К rational robot отношение тоже имеет слабое, по моему.
когда-то я проблему решал [схематично] так (на MS SQL):
пишется триггер(ы) на add/insert/delete который выполняет необходимые проверки data consistency. Если проверка не проходит, то триггер ругается raiserror-ом, на что приложение обязано среагировать (сообщение показать, лог записать и т.д.)
Использовать можно и при автоматизации, и при ручном тестировании.
#7
Отправлено 19 марта 2009 - 06:50
Стоит такая задача - проверять введенные данные не только на клиентсокй части ПО, но и с помощью запросов к БД серверной части. Понятно что можно все это сделать из скрипта, но похоже предстоит обучать этому некоторое количество тестеров которые не очень дружат с программированием. Может у кого-то есть наработки по похожим проблемам? как сделать это с минимальными правками записанного GUI срипта? Хочется минимизировать возможность правки скрипта руками тестера. В идеале конечно хотелось бы найти возможность создания подобной VP прямо в роботе :)
Если возможно, то комментарии про квалификацию тестеров опустим
проблема даже не столько в квалификации, сколько в утомительности этого занятия. с большой вероятностью после 15 проверок базы, на 16й раз человек забудет это сделать.
К rational robot отношение тоже имеет слабое, по моему.
когда-то я проблему решал [схематично] так (на MS SQL):
пишется триггер(ы) на add/insert/delete который выполняет необходимые проверки data consistency. Если проверка не проходит, то триггер ругается raiserror-ом, на что приложение обязано среагировать (сообщение показать, лог записать и т.д.)
Использовать можно и при автоматизации, и при ручном тестировании.
Уж если у них тестировщики запросов написать не могут, то какое им в триггерах разобраться.
#8
Отправлено 19 марта 2009 - 06:58
Если вы не "рядовой тестер", то напишите для ряловых функцию(пакет функций), которая будет(будут) выполнять небходимую проверку. Результатом будет: "зеленый" или "красный" цвет. Объсните, покажите, что значит каждый из параметров остальным. Подставляя свои параметры они получат результат проверки.Хочется придумать такой способ, при котором простой (рядовой) тестер не сильно владеющий навыками программирования сможет самостоятельно проверят корректность данных в БД. склоняюсь к мнению что это можно сделать только через стороннее приложение.Код (запросы к базе) в любом случае надо писать. Я тогда не очень понял, что вам надо. Сделайте проверку в другом инструменте, не в RFT. Если например вы хотите узнать, какой программный код выполняется по "тыканью" кнопок в GUI, воспользуйтесь SQL Monitor например, но это если к button-у прикреплена какая-нибудь API-шная функция/иикак раз от такого примера и хочется отказаться. Хочется минимизировать количество ручного ввода кода в скрипт. То есть тестер в идеале должен получить скрипт делая те же действия мышкой и клавой что и в обычной жизни. Например в TestComplete это делается очень удобно.См. пример тут
И еще, через запросы к ДБ вы не как не сможете отловить какие кноки на клавиатуре или мышке нажимал ваш тестировщик:)
Универсального средства, которое вы ищите - нету пока еще в природе. Есть много вспомогательных, но для работы с ними минимальные навыки программирования и языка знать надо
#9
Отправлено 19 марта 2009 - 08:02
Уж если у них тестировщики запросов написать не могут, то какое им в триггерах разобраться.
а Вы уверены, что Вы поняли как работает описанная мною схема? как она покрывает юзкейз "проверять корректность данных в БД"?
и откуда взялось предположение, что они каждый для себя будут писать триггеры?
#10
Отправлено 19 марта 2009 - 08:38
Немного не о том я речь веду. Когда тестер записывает скрипт, то по большому счету он совершает те же действия что и при ручном тестировании - возит мышкой, щелкает кнопочками. Все что остается сделать это научить его в правильных местах вставлять правильные VP. Тут вроде тоже все более менее просто. Но когда речь идет о проверке содержимого БД после каких-то операций на клиентсокй части, то тут надо уже писать код. А заставлять делать это тестеров совсем не хочется. Если написать для них пакет функций, то очень сложно соблюсти золотую середину между универсальностью и простотой использования.Если вы не "рядовой тестер", то напишите для ряловых функцию(пакет функций), которая будет(будут) выполнять небходимую проверку. Результатом будет: "зеленый" или "красный" цвет. Объсните, покажите, что значит каждый из параметров остальным. Подставляя свои параметры они получат результат проверки.
И еще, через запросы к ДБ вы не как не сможете отловить какие кноки на клавиатуре или мышке нажимал ваш тестировщик:)
Универсального средства, которое вы ищите - нету пока еще в природе. Есть много вспомогательных, но для работы с ними минимальные навыки программирования и языка знать надо
Главная мысль этой ветки - как можно свести к минимуму процесс ручного кодирования.
#11
Отправлено 19 марта 2009 - 10:35
Да. Триггеры будут проверять консистентность данных, но не корректность (разные вещи). Кто-то же триггеры писать будет и я так понял, что это должны делать тестировщики.Уж если у них тестировщики запросов написать не могут, то какое им в триггерах разобраться.
а Вы уверены, что Вы поняли как работает описанная мною схема? как она покрывает юзкейз "проверять корректность данных в БД"?
и откуда взялось предположение, что они каждый для себя будут писать триггеры?
#12
Отправлено 19 марта 2009 - 10:52
Немного не о том я речь веду. Когда тестер записывает скрипт, то по большому счету он совершает те же действия что и при ручном тестировании - возит мышкой, щелкает кнопочками. Все что остается сделать это научить его в правильных местах вставлять правильные VP. Тут вроде тоже все более менее просто. Но когда речь идет о проверке содержимого БД после каких-то операций на клиентсокй части, то тут надо уже писать код. А заставлять делать это тестеров совсем не хочется. Если написать для них пакет функций, то очень сложно соблюсти золотую середину между универсальностью и простотой использования.Если вы не "рядовой тестер", то напишите для ряловых функцию(пакет функций), которая будет(будут) выполнять небходимую проверку. Результатом будет: "зеленый" или "красный" цвет. Объсните, покажите, что значит каждый из параметров остальным. Подставляя свои параметры они получат результат проверки.
И еще, через запросы к ДБ вы не как не сможете отловить какие кноки на клавиатуре или мышке нажимал ваш тестировщик:)
Универсального средства, которое вы ищите - нету пока еще в природе. Есть много вспомогательных, но для работы с ними минимальные навыки программирования и языка знать надо
Главная мысль этой ветки - как можно свести к минимуму процесс ручного кодирования.
Начнем сначала: содержимое БД после каких-то операций на клиентсокой части можно проверить если были изменения в данных DML-операции(insert, update, delete). Отследить(верифицировать) это можно при помощи запросов к таблицам/вьюхам/... БД. Вы можете упростить жизнь тестировщикам в плане написанияэтих запросов (минимизировать их код), если Вы или программисты напишите(закодируете) для них шаблоны в виде функций/процедур/скриптов, но в любом случае код писать придется.
Количество пользователей, читающих эту тему: 1
0 пользователей, 1 гостей, 0 анонимных


