Вызвать C#.Net dll в QuickTestPro (VBScript)


Есть у меня необходимость использования в рамках автоматизации внутренних библиотек dll, написанных на C#. Однажды гуглив столкнулся с фразой, что некомовские (non-COM) библиотеки нельзя использовать в VBScript. Тогда на этом шаге остановился и обошелся переносом кода тогда ещё маленькой функции на VBScript.

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

Стоит сказать, что попытки реализовать предоженный метод были и раньше, но почему-то они не увенчались успехом. Теперь же всё получилось, поэтому решил написать этот пост.
Создаем новую C# dll с кодом:
namespace namespacename
{
    public class classname
    {
        public int GetValue()
        {
            return 1;
        }
    }
}

Теперь в QTP пишем:
Set obj = DotNetFactory.CreateInstance("namespacename.classname", "c:\\namespacename.dll")
MsgBox obj.GetValue()
Вот и всё, теперь наша библиотека работает в QuickTest'e.
Есть небольшой нюанс: по своей глупости мне казалось необходимым после пути к dll ещё одним параметром ставить micString - тип возвращаемого значения. И в таком виде оно не работало - ругалось на меня почти матными словами.

Удач в использовании QTP ;)

Текст сообщения и комментарии...


Первые шаги в Google Wave


Тут давеча уважаемый Samat Jukeshov прислал приглашение в Google Wave. Уже много раз слышал про этот новый сервис от Google'a. Теперь пришло время пощупать.

Сейчас пользователям дана только Preview версия, но это только начало. Они обычно вообще не спешат выходить на релизы с такими штуками - помните сколько их почтовый сервис висел в Beta версии?

Тем, кто ещё не слышал про это, будет полезно посмотреть вот это видео (1 час 20 минут!! ).



Мой пост скорее направлен к тем, у кого аккаунт к этому чудо-сервису уже есть: давайте wave'иться, господа. Заодно и протестируем сей сервис! Мой Wave Address: maksim.hr@googlewave.com

Буду рад познакомиться и поговорить. Дабы не нести чепуху или флуд, предлагаю несколько тем для обсуждения (реальное использование - есть лучшее тестирование):
- внедрение автоматизации там, где её до сих пор не было: проблемы, known issues, know how, etc. Ссылка на волну
- внедрение процессов (создание отдела/группы/команды) тестирования там, где их до сих пор не было. Ссылка на волну.
Обе темы мне интересны самому, признанным экспертом не являюсь, поэтому ожидаю конструктивное общение.
- но можно-таки и просто пофлудить :)  (+ обсудить этот блог) Ссылка на волну.

Когда мне будет дана возможность раздавать приглашения - обязательно отпишусь.
Upd: т.к. меня самого пригласили в ближайшее время получить возможность раздавать приглашения у меня не будет :(

Судя по комментам всех беспокоит возможность получения приглашения. Его можно получить здесь www.inviter.ru

UPD2: Сейчас только ленивый не получил ещё приглашение. Но если Вы таков, то я готов Вас пригласить. Один момент: совсем незнакомых людей звать не буду. Вот вы бы хотя бы в читателях отметьтесь :).
Текст сообщения и комментарии...


Тестирование GUI или сферический конь в вакууме


Тестирование GUI (graphical user interface) очень редко проходит отдельно от основного функционального тестирования. Конечно:
- бывают большие проекты, где этому уделяется внимание;
- бывают пропущены серьезные проблемы, после которых все тестировщики проекта некоторое (зачастую недолгое) время тестируют ГУЙ / ГУИ / УЙ / УИ / UI / GUI
Вот скажите мне, разве можно тестировать то, принципы чего сам до конца не понимаешь? Разве можно найти ошибки в калькуляторе, если не знаешь таблицы умножения?
Многие менеджеры считают, что можно! И тогда все тестировщики становятся не только ГУИтестерами, они сразу ещё и ГУИтворители (ведь программисты исправят ровно так, как это скажет тестировщик).

Такая ситуация очень похожа на историю возникновения самих тестировщиков: программисты (или их начальники) поняли, что писать код и выпускать ПО без ошибок не одно и то же!
Я понимаю, должно пройти время, когда всем станет более-менее понятно: функциональное тестирование и тестирование графического интерфейса пользователя - должны делать разные по своей профессиональной подготовке люди!

Ладно, от теории перейдем к практике.

Предположим, что у нас есть окошко, где нужно выбрать период выпуска на прогулку сферического коня из вакуума. У нас есть два поля для ввода даты: Date From и Date To и кнока Submit.

Кроме дизайно-цветового решения всё выглядит даже ничего: можем задать даты и нажать кнопку Сабмит.
Умный тестировщик проверит эти поля на ввод разных значений: прошлый век, наше время, будущее время, (возможно) проверит ситуацию From >To и т.д. А вот когда этим начнет пользоваться конюх сферического коня в вакууме и реально захочет настроить даты выгула этого животного, он встретит реальные проблемы.

Одна из них - как мне настроить выгул коня только на один день? Поставить Date From = 10/07/2009 и Date To = 10/07/2009? Такое правило зачастую не сработает, ведь мудрые девелоперы сохраняют в базу данных ещё и время, а для обоих дат это будет 00:00:00. Можно поставить Date From = 10/07/2009 и Date To = 11/07/2009, но откуда мне как пользователю знать, что мой конь не будет гулять два дня, вместо одного?

Только методом проб и ошибок, запросов на изменение и приперательств с поставщиком ПО.

А вот если бы тестировщик посмотрел заранее в книгу про ГУИ тестирование, на минуту представил себя конюхом в штанах с кожей на жопе коленях, подумал о ежедневном выгуле любимого коня - все могло бы быть совсем иначе.

Не буду продолжать сей короткий опус, но скажу лишь одно - я сам попался на такое - мне не понравилось,  и теперь буду представлять себя ковбоем/конюхом/или другим пользователем тестрируемого софта.

Текст сообщения и комментарии...