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

Публикации N.K.

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


#23716 IBM Rational Quantify

Отправлено автор: N.K. 11 января 2006 - 19:53 в IBM Rational - Functional Testing

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

заранее спасибо всем откликнувшимся



#23654 средство для ручного тестирования

Отправлено автор: N.K. 10 января 2006 - 20:07 в Выбор инструментов для тестирования ПО

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



#23557 средство для ручного тестирования

Отправлено автор: N.K. 06 января 2006 - 21:05 в Выбор инструментов для тестирования ПО

Вообще-то, отчёт можно строить не только по билдам, но и по тест-плану. В этом случае статус будет соответствовать статусу последнего прогона теста.

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



#23538 средство для ручного тестирования

Отправлено автор: N.K. 06 января 2006 - 11:47 в Выбор инструментов для тестирования ПО

Спасибо за хорошие ссылки!
мне не хватало в компоненте создать категорию :)

Просмотр сообщения


:shok: Вы что работаете первого числа? :victory:

Я бы не смог. :good: :ok: :drinks: => :bad:

нет, я дома понемножку маньячу :) у нас выходные до 10-го как у всех нормальных людей :)
просто очень и очень нужна такая система. у нас сейчас единственный вид отчетности - тест репорты во фрейм мейкере. это полный сакс :(

еще кстати вопрос по поводу просмотров результатов.
например, я протестила категорию1 в билде build01, нашла баги, сделала ретест в build02, новых проблем не нашла. потом были новые билды и я в них тестила другие категории(например, категорию2). я так понимаю, что результат Untested будет выставляться для категории1 во всех билдах, которые создавались после начала тестов? можно от этого как-то избавиться?

Всех случайно заглянувших сюда, с наступившим Новым Годом! :yahoo:

Просмотр сообщения

уже почти с Рождеством! :)



#23476 средство для ручного тестирования

Отправлено автор: N.K. 01 января 2006 - 19:35 в Выбор инструментов для тестирования ПО

Спасибо за хорошие ссылки!
мне не хватало в компоненте создать категорию :)



#23428 средство для ручного тестирования

Отправлено автор: N.K. 28 декабря 2005 - 19:34 в Выбор инструментов для тестирования ПО

Из бесплатного ищем по форуму...
Search:TestLink

Как раз им в точности и выполнялась, и выполняется поставленная Вами задача.
Или вот оригинал TestLink

Просмотр сообщения

я так и не поняла как там собственно создавать тест кейсы. как аттачить их к плану - понятно... а вот как создавать? можешь подсказать?



#22884 Сборка очередного билда

Отправлено автор: N.K. 14 декабря 2005 - 20:27 в Управление тестированием

по-моему, все ясно.
"отвечает" - значит получает от дизайна набор модулей и собирает всю систему.

Это называется выполняет, а не отвечает. Я поэтому и уточняю.

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

в процессе отлавливает ошибки билда, затем деливерит билд на тестрование. соответственно.

Если "ошибки билда" это ошибки при компиляции кода, то это делает компилятор, а не человек.

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

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

Отвечает это активность, а "чтобы не было" это цель.

Просмотр сообщения

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

ну а если в слово "отвечать" вы вкладываете значение "будет фиксить проблему", то это в любом случае будет делать девелопер, где бы эта проблема ни была найдена - при билде, при интеграционном тестировании, при функциональном, системном тестировании или при реальной работе на стороне заказчка. тогда получается - дизайн ответственен за всё?



#22791 Сборка очередного билда

Отправлено автор: N.K. 13 декабря 2005 - 20:15 в Управление тестированием

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

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

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

по поводу "пинает того, кто делает"... увы, это горькая правда :( правда, чаще всего "пинание" происходит с помощью баг-репортов в баг-трекинг системе %)



#22667 Тестирование пр вычисляющей площадь многоугольника

Отправлено автор: N.K. 11 декабря 2005 - 20:31 в Тест-дизайн и ручное тестирование

хмммм...
у нас в фирме такой вопрос задают на собеседовании %)
еще интересно какие параметры программа запрашивает. будем считать что это координаты вершин на плоскости. пожалуйста:
Nominal cases:
1. обычный кейс (выпуклый многоугольник - ребра, не имеющие общей вершины не пересекаются): подставляются валидные параметры и проверяется как считается площадь.
2. то же, но для многоугольника, у которого несоседние ребра пересекаются
Error cases:
1. проверка того, как обрабатывается нулевая длина ребра: вводим две(или более) совпадающих точки и проверяем как обрабатывается такая ситуация. (поправка: нужно смотреть requirements - нужно ли кастомеру, чтобы такая ситуация считалась ошибочной). как граничный случай все точки должны совпадать.
2. проверяем, как обрабатывает программа точки, лежащие на одной прямой.
3. проверяем, как программа обрабатывает меньше 3-х точек.

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

ну что, куда я прошла/провалилась? ;)



#22654 weekly/daily report

Отправлено автор: N.K. 09 декабря 2005 - 19:21 в Управление тестированием

По поводу "недельной активности" -- что за странная единица измерения времени? Почему именно недельная? Что, руководитель только по понедельникам на работе присутствует? Распределил -- и на покой. Я распределяю активность по мере необходимости. Не ждать же до следующего понедельника. :crazy:  Форма -- любая уместная в конкретной ситуации: через реквест-трекекер, по почте, устно, записка на клавиатуре, ...

Просмотр сообщения


активность "недельная" потому что у заказчиков такая единица измерения времени. мы уже привыкли жить "виками" ;) cейчас вот W49 :) естественно, и задания распределяются на неделю. конечно, в процессе выполнения они могут корректироваться и долгосрочное планирование тоже имеет место быть.

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



#22526 weekly/daily report

Отправлено автор: N.K. 07 декабря 2005 - 19:16 в Управление тестированием

уважаемый Yury,
я спрашиваю потому что это интересно. мне для общего развития. и вообще хочется узнать как нормальные люди пишут репорты. работаю тестером два года. сначала на крупную компанию N**, теперь на компанию E**. Аутсорсинг, естественно. требования - разные. причем, как правило, заказчику репорт каждого отдельного сотрудника, им интересен командный отчет. только вот кажется у нас тест-лидер не может определиться в каком виде ему это надо :/ скоро у меня в отчете будет что-то типа
Time reporting: 20% - weekly report presentation creating

так вот, есть ли какие-то шаблоны или общепринятые нормы?
а зачем вам, собственно, знать зачем мне это надо? помочь можете, или так, чтобы разговор поддержать?

Case, то есть у вас каждый таск создается в таск-трекинговой системе? а всякие мелкие вещи как то: чтение документации по тулам, чтение новых спецификаций, расстановка меток в клиркейсе, трекинг трабл-репортов и прочие мелочи на которые тратится куча времени, это позволяет отслеживать?

и у нас кстати отчеты по команде составляет не менеджер... а у тим-лидеров 30% времени отведено на составление всяких таких бумажек



#22474 weekly/daily report

Отправлено автор: N.K. 06 декабря 2005 - 21:23 в Управление тестированием

уважаемые менеджеры и тим-лидеры, в каком виде вы требуете от своих подчиненных $subj?
что туда должно включаться и что для вас особенно важно?
и еще вопрос: каким образом вы распределяете недельную активность? рассылка мейлов с конкретными задачами или просто показываете сотрудникам план?



#22222 Как тестировать мобильные телефоны?

Отправлено автор: N.K. 30 ноября 2005 - 13:55 в Тест-дизайн и ручное тестирование

еще непонятно что имеется в виду под "эффективностью" тестов...

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

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



#22216 Как тестировать мобильные телефоны?

Отправлено автор: N.K. 30 ноября 2005 - 11:44 в Тест-дизайн и ручное тестирование

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



#22149 Инженер по тестированию

Отправлено автор: N.K. 28 ноября 2005 - 19:35 в Ищу работу!

хммм... ну с тем, что как себя поставишь, так все и будет, я не спорю. но... до разумных пределов. и тем более с тем как наши компании относятся к деньгам... да и знаю я как люди на собеседования ходят (собеседующие, разумеется). им выгоднее взять новичка-стьюдента, который будет до ночи за 200 уёв сидеть, чем человека с опытом на приличные деньги. потому что "техническая экспертиза" (модное слово, ага ;) приходит с опытом. а суммарная стоимость проекта уменьшается ;)



#22147 Инженер по тестированию

Отправлено автор: N.K. 28 ноября 2005 - 17:09 в Ищу работу!

Желаемый уровень зарплаты - от $1000 и выше. Зарплата не "в конверте".

Комментарии и вопросы к анкете не запрещены и даже приветствуются. :)

Просмотр сообщения

думаю в Нижнем затруднительно 1000 и выше... да еще и "не в конветре". я через две остановки работаю ;) за два года не слышала чтобы у нас кто-то из тестеров столько получал :(



#22141 номера строк в логах Purify

Отправлено автор: N.K. 28 ноября 2005 - 14:53 в IBM Rational - Functional Testing

привет!
Запускаю бинарники, скомпилированные с Purify. Режим - не оконный, все логи пишутся в файл. как заставить логи содержать номера строк кода, в которых произошла ошибка или куски кода (как в оконном режиме)? знаю, что должны быть какие-то переменные окружения.
да. тесты идут под солярисом.
спасибо всем откликнувшимся :)