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

Публикации Mila

57 публикаций создано Mila (учитываются публикации только с 29 марта 2023)



#70663 Видеозапись Теста

Отправлено автор: Mila 08 сентября 2009 - 09:22 в Тест-дизайн и ручное тестирование

Коллеги, возник вопрос из этой же серии. Видео записано, теперь стоит задача его воспроизвести. При этом необходимо видеть хронометраж в миллисекундах. Это нужно для измерения длительности процессов. Что можете порекоомендовать?


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



#69946 Свободное тестирование

Отправлено автор: Mila 18 августа 2009 - 10:36 в Тест-дизайн и ручное тестирование

Но цель хаотического тестирования (то, что я видела во многих небольших компаниях) - это "потестриуйте что-нибудь, у всех наших конкурентов есть тестеры" :) А каким в данном случае может быть критерий успешности тестов? Только количество багов, так как оценить покрытие невозможно и предугадать масштабы пропуска дефектов до выхода продукта в свет - тоже. Цели контроля качества не стоит, оценки статуса продукта не стоит. Только искать баги. А это цель, при которой подойдут любые способы и любые скиллы, и процесс достижения именно этой цели я называю ad hoc или хаотическим тестированием.


В более зрелых компаниях встречала другую интерпритацию ad hoc тестирования.
Самый простой пример: для графических компонент проводилось хаотичное кликание по произвольным координатам и ожидалось, когда все завалится.
Помимо графики есть еще медоборудование, мобильная связь, датчики движения, сканеры, распознаватели... Какой-то эталонный набор данных или тесткейзов может быть слишком узким или его очень долго создавать... И вот тогда можно на постоянной или временной основе проводить хаотичные тесты, особенно, если это все можно быстро реализовать. :)
Критерий везде успешности простой: справимся или нет + анализ логов на ошибки. Иногда возможно вывести и некие характеристики по результатам испытаний :)
Тест-кейзов действительно нет, вернее, они генерируются... и в принципе никогда не повторяются...



#69598 Как поступать с линками на эту же страницу

Отправлено автор: Mila 07 августа 2009 - 10:43 в Selenium - Functional Testing

Можно пройтись по html коду страницы и проверить, что в документе есть якорь... и в нужном абзаце. :)



#69544 Модули

Отправлено автор: Mila 05 августа 2009 - 12:48 в C/C++

Лично мне попадалось "модульное построение" = программа состоит из модулей, т.е. частей с определенной замкнутой функциональностью (ядро там иметь не обязательно, но оно чаще встречается).
По поводу подтягивания "модульного построения" к "ООП"... ИМХО, это разные уровни.



#69049 Новичок в QA

Отправлено автор: Mila 20 июля 2009 - 13:09 в Свободное общение

Поэтому сразу вопрос - что в первую очередь хочет услышать работодатель от кандидата-тестировщика на собеседовании?


Помимо адекватности в размере зарплаты, работодатель смотрит на знания и уровень, требуемые от кандидата. Как правило, все это указано в описании вакансии + из описания того, чем занимается фирма. Если Вы хоть как-то представляете, чем занимается контора и с чем предстоит столкнуться, то велик шанс, что все будет хорошо. :)



#68909 Скриншот

Отправлено автор: Mila 14 июля 2009 - 08:57 в IBM Rational - Functional Testing

Вот тут что-то есть по этому поводу :)
http://www.sql.ru/fo...aspx?tid=388412
В хелпе должно быть все подробно описано :)



#68880 Процесс тетирования документации

Отправлено автор: Mila 10 июля 2009 - 16:52 в Управление тестированием

И, не могу не удержаться, док-райтеры - они не лишние. Очень даже не лишние. ...

Я это писала по отношению только к отдельному этапу, а не в принципе :)

А вот уровень людей - не известен заранее. Да и любому человеку, какой-бы он професионал не был, при работе с чужим ПО, намного более приятно получить четкие, лаконичные и исчерпывающие инструкции, правда ведь?

Правда, но к сожалению не всегда угадывают, что именно писать.
Я бы одним из критериев взяла бы гугл: если на запрос есть куча ссылок, то можно и не особо разливаться мыслью по древу - программеры сами все найдут и прочтут во всех подробностях :)
Если брать API, то часто забывают описывать переменные связанные именно с простыми типами, типами а-ля Object или List. Например:
GetObjectWithType(string ObjType), где ObjType - тип объекта или его свойство.
Вроде и ежу понятно, но потом в коде приходится долго и упорно подбирать эту несчастную строку, перебирая малые и заглавные буквы и прочие фантазии.
Как-то так :)



#68782 Моделирование систем

Отправлено автор: Mila 06 июля 2009 - 11:02 в Бизнес-анализ и требования

Привет всем
Интересует вот какой вопрос:
Использует ли кто-то для анализа, а может и для каких других полезных нужд, некие модели систем, например структурированные деревья объектов со свойствами и связями. А может модель в виде диаграмм с теми же свойствами и связями объектов.
Вобщем интересует все по этому поводу: используемое ПО, методы, насколько полезно и удобно.
Заранее спасибо :)

PS может не совсем правильно где-то выразился - не спец в этой области - просьба не пинать а лучше переспросить :)
да... и я так же прекрасно понимаю что на создание и поддержание такой модели нужна уйма ресурсов, времени и сил :)


Все зависит от того, как используется у вас UML. Некоторые команды вобще все хранят в UML.

Если ближе к тестированию, то можно проводить тестирование на уровне модели некоторых фич системы, которые не зависят от кода. Например, мы разрабатывали решение: по MSC диаграммам + еще кое-что, генерились тесты для "прозвона" всех абонентов для UML модели АТС, проверяя что все соединяются друг с другом правильно. Решение получилось более удобным, чем тестирование через готовый код.
Самим фактом наличия каких-то элементов и атрибутов можно проверять, что разработчики ничего не забыли, что объекты побывали в нужных состояниях и т.п. - может оказаться проще, чем проверять это через запуск системы.
И т.д. и т.п.

Что касается тулов, использующих визуальное моделирование: их много, и они могут различаться по идеологии и с вариантами на тему использования UML. ИМХО, тут так же как и с тулами для тестирования.



#68360 Процесс тетирования документации

Отправлено автор: Mila 11 июня 2009 - 13:06 в Управление тестированием

Я знаю, что вы не знаете, что собой представляют наши продукты.
А в задачи тех-райтера входит написать документацию, как это не странно. Части документации присылаются ему разработчиками, и он, как нативный спикер, переводит с английского на английский :) Но это конечно не все, что делают наши док-райтеры. Но они не технические специалисты, а писатели - они пишут книгу, под названием User's Guide. За правильность технических деталей описанных там, отвечают разработчики и соотвественно мы тестеры, которые убеждаются, что эти детали описаны правильно.
=======
В документации к нашему продукту содержится изрядное количество технической информации совершенно новой для пользователей, т.к. мы работаем над новыми технологиями, которые только через год-два появляются, например, в сотовых телефонах. Зачастую, для использования наших продуктов требуется сложный процесс конфигурирования, причем не только самого продукта, но и environment-а (например создание IPv6 сети). Иногда, пользователям необходимо самим реализовать необходимые компоненты, которые мы просто не можем сделать за них. А как их сделать тоже описывается в доке.
В общем все не просто. Сделать скриншот, описать последовательность действий по какой-нибудь схеме и тому подобное, док-райтеры спокойно могут сделать сами. Но описать процесс создания каких-нибудь нативных библиотек в зависимости от операционки или описать организацию пользовательского канала связи они очевидно не могут.


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

И если девелопер, зная кучу подробностей, описал его кратко, то мне, чтобы понять его описание надо потратить несколько дней на изучение деталей. Поэтому я пытаюсь добиться того, чтобы процесс, который придется проходить пользователю был описан подробнее. Но иногда, есть альтернатива - не описывать вообще ничего, а сослаться на сторонние документы, детально объясняющие суть происходящего. Случаи разные бывают.

Тут надо внести ясность с целями, содержанием документа, целевой аудиторией и т.п и распространить эти постулаты на всю команду. Они и служат критериями для выбора. Например(!!!), если с этими технологиями будут работать спецы уровня заслуженный senior developer какого-нить Intel, то боюсь ему будет очень неудобно вытаскивать из 10 страниц три действительно полезных предложения, т.к. IPv6 сеть он может развернуть с закрытыми глазами без подсказок => оставляем только особенности настроек и ссылку на документацию.
Документация должна писаться для пользователя, а не для Васи Пупкина, который вчера узнал что такое С. Как-то так. :)



#68328 Процесс тетирования документации

Отправлено автор: Mila 10 июня 2009 - 13:41 в Управление тестированием

Вынужден вас огорчить. Все до единого ваши предположения неправильны. Да я и не о том спрашиваю в данной теме.

Хм... простите, а откуда мне знать подробности? Я вам озвучила часто встречающиеся ошибки.

ЗЫ2: "не своего поля" у нас не бывает, т.к. каждый наш продукт общий. Например описаный мною случай, к которому вы почему-то придрались, может быть такой. Есть непростой момент, который изначально хотели как-то объяснить пользователям, описав в документации. На взгляд разработчика (у которого в голове куча еще потаенных знаний) получилось понятно, на мой взгляд (человека глубоко не зарывавшегося в спецификации) - получилась ерунда. На взгляд техлида, который больше меня в теме, но меньше разработчика погружен в детали - тоже непонятно получилось. В результате я прошу, например, исправить на более понятное описание (2 абзца, вместо 2-х предложений, которые я сам, разобравшись, могу и написать), а тех лид просит вообще убрать все это нафиг и дать ссылку на спецификацию или сторонню техничекую документацию - типа мы все-равно лучше чем там не напишем. Т.к. ревью проходит независимо у док-райтера два мнения - одно от тех-лида, одно от qa-лида (есть еще старое, девелоперское) - кого ему слушать? Понятно, что потом мы сами уже договариваемся и во второй раз он получает окончательный вариант.

С Ваших же слов:
1. Разработчик - ему все понятно и комментариев нет.
2. Вы не в теме. Вы только попросили объяснить.
3. Техлид в теме и попросил вставить ссылку на стороннюю документацию в качестве объяснений.

Актуальны только пункты 2 и 3.

Теперь приведу два утверждения:
1. Пользователю не интересно читать двухдневные размышления непрофессионала, т.к. на изучение своей предметной области пользователь потратил несколько лет своей жизни.
2. Сторонняя документация никак не может объяснить поведение, узкие моменты и идеологию вашей системы.

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

ЗЫ: К счастью, программные продукты бывают разные, не всегда это окошечко с кнопочками, картинками и табличками. У нас линейка технически сложных продуктов, для ограниченного круга кустомеров. В задачи наших техрайтеров не входит доскональное изучение всех технических тонкостей - это задача девелоперов.

А что входит в задачи Ваших техрайтеров? Писать о том, о чем они вобще не имеют никакого представления, а потом растерянно хлопать глазами, что же делать с двумя предложениями? Вы отвлекитесь и посмотрите на ситуацию со стороны... увидите, что на самом деле я не злая :)
Все упомянутые "технические тонкости", которые нужно знать в предметной области, содержаться в Вашем продукте или очевидны из его функциональности. Об остальном в документации писать не стоит. :)

Вы вот лучше раскажите какой у вас процесс тестирования документации.

Уже описывала. Высказываюсь по озвученным проблемам.
Кстати, Вы уже признались, что предложение о налаживании процессов Вам не по вкусу. Что Вы ожидаете от аудитории? :)



#68286 Процесс тетирования документации

Отправлено автор: Mila 09 июня 2009 - 16:32 в Управление тестированием

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


В вашем примере я могу предположить:
- первый влез не в свое поле, раз не смог исправить.
- второй - молодец, т.к. следит именно за своими вещами, если он действительно внес нечто новое.
- техрайтер не знает кого слушать, т.к. ВСЕ ГЛАВНЫЕ ВО ВСЕМ. На самом деле техрайтер должен четко понимать от кого и какие содержательные комментарии он должен принимать: размышлизмы обычного девелопера о позиционировании продукта на рынке не нужно немедленно вносить в документацию, а надо передать на рассмотрение PR и т.п. ответственным членам команды... а еще лучше вобще не давать девелоперу этот кусок на рассмотрение, т.к. он все равно не сможет сказать ничего ценного - не та квалификация.
Вобщем, если каждый будет оценивать то, в чем он разбирается, то все в одном абзаце смогут увидеть свои коррективы.

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



#68162 Процесс тетирования документации

Отправлено автор: Mila 05 июня 2009 - 10:45 в Управление тестированием

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

Это не совсем нормальная ситуация, если все в порядке с процессами и т.п. Поясняю:
Спор по описанию фич самого продукта быть не может, т.к. фичи должны быть четко определены к этому моменту.
Все споры об общей идеологии продукта и фич среди команды должны быть разрешены ДО этапа составления документации - иначе не понятно что эта команда производит. Все улучшения и изменения, как правило, имеют свои планы реализации и т.п.
В спорах о стилистике и т.п. должен выигрывать ответственный за документацию, как более компетентный член команды. В спорах об идеологии продукта между техрайтером и девелопером/тестером должен выигрывать ответственный за идеологию продукта.
Можете привести свой пример спора. :)

- как тестируются случаи, когда продукт содержит одно и тоже руководство пользователя в разных ипостасях; у нас например обычное дело когда их три - PDF, HTML и online-help(неконтекстный) - зачитаться можно!
- как трэкаются и трэкаются ли изменения в продукте, сделаные в последнюю минуту.

Могу немного поделиться нашим опытом:
- Все используемые скриншоты, общие куски текста и т.п. лежат в одном месте, и оттуда автоматически попадают в разные документы, т.е. документация фактически генерится. И это спасает от многих проблем.
- Все баги и улучшения после разборок между девелоперами и тестерами обязательно проходят через техрайтера, который тут же вносит изменения в документацию. Техрайтер обычно успевает все завершить к моменту окончания регрессии. В зависимости от текущей ситуации с изменениями, которая ясна заранее, принимается решение о дополнительном времени на тестирование документации и т.п.
Постановка процесса сильно облегчает жизнь.



#68066 запись int в поле winedit

Отправлено автор: Mila 03 июня 2009 - 10:55 в Hewlett-Packard (Mercury) - Functional Testing

Приветствую.
Вкратце, ситуация такова. Дельфийское приложение, на QTP аддына не установлено. Соответственно, настроено все через object identification.
Есть поле ввода, контроль ввода - только цифры. Естественно, метод Set пролетает со свистом - он подает объекту string, в результате "The operation can not be performed".
Альтернатива - Type. Но замечал, что иногда, при длинных строках, он "проглатывает" символы...
Есть ли еще какие-либо варианты, как записать int в WinEdit?


Проглатывает может и в случае, если при преобразовании использовать тип с меньшей длинной, чем само значение. Посмотрите какие есть типы вообще.
Если речь только о сравнении, то можно сравнивать и строки.



#67970 Программинг

Отправлено автор: Mila 01 июня 2009 - 10:53 в Управление тестированием

Возникает вопрос, а какие же языки будут наиболее полезны тестировщику на практике? Вот список языков, которые мне встречались в вакансиях (сортирую по убыванию частоты упоминаний): С++, Java, C, C#, Perl, VBA, PHP, VB, JScript, VBScript, Python, Lua и др. Меня несколько удивило, что так часто встречался C++, а вот Python, наоборот, достаточно редко.


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

Уважаемые знатоки, за какой язык вы бы посоветовали взяться? Знание какого из языков будет наиболее полезно на практике? Добавлю, что в текущей моей тестерской деятельности знание программирования не требуется, поэтому собираюсь учиться "на будущее".


Многие работодатели хотят, чтобы тестер имел какое-то представление о том языке, на котором ведется разработка + умел писать какие-то вспомогательные скрипты (средства автоматизации я оставляю за скобками). Мягко говоря, пофиг на чем (perl или python) написан вспомогательный скрипт из 50 строк, который лезет на сервер, читает что-то там в логе, создает и убивает процессы и т.п, если в обоих языках есть эти возможности... гораздо страшнее, если вобще нет представления, что такое в принципе возможно.
Для начала можно осваивать то, что больше всего требуется, потом смотреть на остальное.



#67386 Хочу стать тестером или как поменять профессию?

Отправлено автор: Mila 09 мая 2009 - 14:38 в Ищу работу!

Для работы тестировщика, надо приобретать знания: по программированию, как работают и из чего состоят различные приложения, что и как устроено в операционных системах и т.п. Вобщем начинать с азбуки.
То, что вам легко давались какие-то пакеты - это хорошо. Но учтите, что разработчики ОЧЕНЬ старались, чтобы с ними было легко работать.

Могу дать пару советов от себя лично:
1. присмотреться к деятельности Quality Assurance - налаживать и улучшать процессы в больших компаниях.
2. Некоторые проекты (их довольно много.. и еще могут возникнуть) нуждаются в грамотной прослойке между программистами и заказчиками, чтобы облегчить всем жизнь. И по этому поводу существуют разные позиции: начиная от простого саппорта (если хочется относительно спокойной жизни, или наоборот любите командировки), заканчивая придумыванием новых фич и постановкой задач для развития проекта и подавления конкурентов (если есть амбиции и хочется работать головой). Если у вас есть идеи собственного проекта и его развития, то никто не запрещает предложить свои услуги "фирме-издателю".



#67379 Нагрузочное тестирование и ТК

Отправлено автор: Mila 08 мая 2009 - 12:05 в SmartBear (AutomatedQA) - Functional Testing

нашел нужный Task, в нем нужный connection и нужный запрос. (это из сгенеренных Recorder`oм)

а вот как поместить в этот запрос переменную?
или я не в том направлении рою?


Копируете тело запроса в переменную, потом делаете replace кусков строки, результат обратно присваиваете.
И еще внимательно почитайте хелп по редактированию запросов и по каким правилам живут копии запросов - сэкономите кучу времени на вопрос "почему выдает ошибку". :)



#67340 Нагрузочное тестирование и ТК

Отправлено автор: Mila 07 мая 2009 - 15:06 в SmartBear (AutomatedQA) - Functional Testing

Коллеги, подскажите плз, реально ли эмулировать на ТС 6.52 работу нескольких десятков пользователей, которая сводится к:
первый юзер:
кликанье по веб приложению (IE7),
вводу в поле значения, отличного от предыдущего (которое отображается рядом),
сохранение этого значения, и опять некоторое количество кликов.
второй юзер "забирает" при обновлении страницы это последнее значение и, при необходимости, изменяет его и сохраняет измененное (те же действия).
//при этом некоторое количество других юзеров использует другое, не связанное с первым, поле и делает то же самое.

также интересно было бы смоделировать попытки одновременного сохранения..

знаю, что в скрипте можно получать и изменять текущее значение, но вот как добиться отправки измененного в трафике?


На первый взгляд все выглядит реально. :)
Если делать проект, тестирующий GUI, то на сайте должна быть кнопка, которой юзеры отправляют свой трафик - ей и надо пользоваться.
Если у вас проект для нагрузочного тестирования, то меняете значения переменных в теле запроса - TC все отправит.

По поводу одновременного сохранения... честно говоря, сложно угадать, не зная архитектуры, работу какого модуля в вашем приложении вы хотите проверить... Может быть проще будет использовать другие средства.



#67292 Двунаправленные связанные списки

Отправлено автор: Mila 06 мая 2009 - 22:10 в IBM Rational - Functional Testing

Что задумали...
Пишу универсальные функции для тестирования ПО в своей компании, в процессе чего мне потребовалось хранилище данных, количество элементов в котором может быть самое разное, иногда не большое, иногда очень большое. В одном скрипте этих хранилищь может создаваться очень много. Элементы хранишища представляют собой тип:

Type Element    a1 as string    a2 as string    a3 as string    a4 as string    a5 as string    a6 as string    a7 as stringEnd Type
Если в качестве хранилища использовать массив, то для него нужно будет заранее задавать достаточно большой размер, чтобы хватило места для добавления всех элементов, т.е. каждое хранилище будет забирать заранее определенное фиксированное количество памяти. Если в каждом скрипте будет создаваться много хранилищь, да еще если на одном компе будет запущено несколько виртуальных машин выполняющих один и тот же скрипт, то может и памяти не хватить.
Если в качестве хранилища использовать связанные списки, думаю "в сухом остатке" :) удасться выиграть некоторое количество виртуальной памяти, так как тут уже размер каждого хранилища будет зависеть от количества элементов....


В SQABasic, судя по документации, есть ReDim, позволяющий изменить длину массива.

И еще хочу затронуть некоторые моменты в Вашем ответе - может и получу в итоге познавательную для себя дискуссию, т.к. тема универсальности весьма интересна :)
Для тестирования GUI используется не так уж много наборов данных, и акцент идет на разную длину строк, на данные, которые открывают какие-то новые формы, и делается все для одного пользователя. Запуск на виртуальных машинах похож на нагрузочное тестирование, но честно говоря, никогда не получалось получить серьезную нагрузку, используя тесты для GUI.
При нагрузочном тестировании на практике у меня все сводилось к вычислениям: в памяти болтаются массивы с "индексами" важных объектов, позволяющие их однозначно определить, а все свойства/связи зависят от порядкового номера/счетчика/условий/"и т.п.". Из преимуществ могу обозначить, что не надо лепить километры данных при увеличении числа пользователей или объектов, можно исследовать различные ситуации, просто поменяв некоторые константы (больше одного, меньше другого).
Как-то так, если кратенько. :blush:
Честно говоря, с универсальностью особо и не сталкивалась, но интересно.



#67258 Как набирать сотрудников?

Отправлено автор: Mila 06 мая 2009 - 10:49 в Свободное общение

Ясно, что однозначного ответа на мой вопрос нет. И я вовсе не призываю осудить ни ту, ни другую точку зрения.
Я просто хочу собрать некоторую информацию о том, какой подход преобладает в реальных условиях.
Не в абстрактных условиях, а в вашей конкретной компании -- кому отдаётся преимущество, узким или широким специалистам?


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

Вобщем-то оба высказывания верны, просто применимы к разным случаям жизни.



#67255 JavaScript

Отправлено автор: Mila 06 мая 2009 - 10:24 в Веб-технологии

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


Для начала лучше сосредоточиться на том, как организованы и как тестируют типы приложений, которые ваша команда собирается разрабатывать. Какие методы, какие инструменты можно использовать, что вы из этого сможете сделать по срокам с учетом этапов разработки. И в дополнение поизучайте язык и те технологии, которые будут использоваться: будете понимать обсуждения программистов + могут появиться новые идеи... и многие вопросы отпадут сами собой.
Как-то так.



#67228 Двунаправленные связанные списки

Отправлено автор: Mila 05 мая 2009 - 22:00 в IBM Rational - Functional Testing

Компилируемость и/или интерпретируемость не есть свойство языка и никак не связано с его убогостью. Убогость в том, что в языках используемых в авто тулах, некоторые очень простые вещи не получаются быстро-быстро и без заморочек. Богаством стандартных и не очень библиотек они тоже не отличаются. Данная тема это показывает.

Если хотите могу продолжить список интерпертируемыми языками Python, Ruby, Perl, Lua.


Есть еще всякие факторы: совместимость, надежность, поддержка старого кода юзеров, уровень знаний, скорость разработки и т.п... Выбирают какой-то минимум для обслуживания своих незатейливых по типам параметров функций, а умным предлагают самовыражаться через COM.
Мне, например, интересно посмотреть, что задумали с двунаправленными связанными списками в тестировании GUI, и какой выигрыш ожидают получить в сухом остатке :)



#67208 Сравнение rtf

Отправлено автор: Mila 05 мая 2009 - 11:12 в SmartBear (AutomatedQA) - Functional Testing

Бесплатному коню в зубы не смотрят :)
Конечно нет, а тут разве нужна поддержка макросов?


Да я так, расширяю кругозор всех и вся, в том числе и свой :)

PS я к чему веду: ворд при сохранении документа записывает в него ещё много всяких одному ему ведомых метаданных. Может, альтернативные продукты позволят избежать описанных проблем с rsid и insid.

Поэксперементировала 30 секунд с WordPad - insid не встретила, а rsid присутствуют. Думаю, если формат позволяет, то будут пихать все, на что лени не хватит.
У меня такое ощущение, что пора открывать базу с "полезными тулами" и самим накапливать всякие программки/макросы под разные языки и нужды - жизнь на форуме должна упроститься.



#67188 Сравнение rtf

Отправлено автор: Mila 05 мая 2009 - 08:10 в SmartBear (AutomatedQA) - Functional Testing

Я, может, сейчас глупость скажу, но почему именно MS Word? А не Open Office или AbiWord или WordPad?


Могу точно сказать, что OpenOffice у меня когда-то криво переводил в XML, вернее постоянно добавлялись новые стили и шрифты типа : Tahoma1, Tahoma11 и т.д. по нарастающей. Вобщем, заработал мою антипатию... хотя и хорошая вещь :)
А в WordPad можно писать макросы/скрипты? Давненько его не видела... :)



#67177 Сравнение rtf

Отправлено автор: Mila 04 мая 2009 - 17:30 в SmartBear (AutomatedQA) - Functional Testing

Я сторонник исключительно простых решений. Я не совсем понимаю фразы "просто заменив их константами".
Просто пример. Открываю rtf в фаре и пытаюсь заменить все rsid на пусто к примеру - не тут то было. К тому же кроме rsid там есть много еще других проблем. В общем вижу что путь по ртф неочень перспективный.


А что именно было, когда "не тут-то было"? Желательно с примерами.
Какие именно проблемы?

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


1. Создаете макрос, который вам все сохраняет.
2. Запускаете командную строку: <путь до ворда> /mname <путь к файлу>
(выделенное жирным name заменить на имя вашего макроса)

Еще можно попробовать подключить библиотеку Word и сравнить все интересующие места через API.



#67175 Двунаправленные связанные списки

Отправлено автор: Mila 04 мая 2009 - 16:43 в IBM Rational - Functional Testing

По сравнению с нормальными языками программирования (C/C++, Java, C#, etc). Вообщем понятно, не более убог чем остальные уродцы :).

Встраивать в тулы "нормальные языки программирования" никто и не собирался... там вобще другой принцип работы.
Скриптовые языки для того и нужны, чтобы "быстро, без заморочек + весь ужас-ужас!! за нас уже сделали..." (углубляться не буду).
А платить приходиться отсутствием удобств, доступных в нормальных языках, потому что местами их просто не реализовать.