- Форум тестировщиков
- → Публикации OVA
Публикации OVA
162 публикаций создано OVA (учитываются публикации только с 25 апреля 2023)
По типу контента
По пользователю
#103828 Как узнать HTTP Заголовки?
Отправлено автор: OVA 10 апреля 2012 - 04:30 в Автоматизированное тестирование
Берете прокси и подсовываете в вашу тестовую среду. Selenium вообще для таких вещей не предназначен, он для того чтобы браузером управлять. Не стоит его заставлять делать противоестественные вещи - получатся страшные кадавры которые не работают.
#103827 Инструменты тестирования геолокации
Отправлено автор: OVA 10 апреля 2012 - 04:26 в Тест-дизайн и ручное тестирование
А зачем менять ip клиента? Request lib в руки и копать.
#102773 Как устроиться тестировщиком без опыта работы
Отправлено автор: OVA 22 марта 2012 - 05:55 в Личный рост, карьера, развитие
Я знаю как минимум одного филолога из тайги который в NativeDriver репы коммитит...До ваших переходов по факультетам никому нет дела. У нас есть парень, который в принципе - археолог, однако адекватно тестирует и не парит себе самосознание.
Другое дело, что многие начальства почему-то убеждены что в IT можно только технарям.
#100795 Проблемы с локализацией багов
Отправлено автор: OVA 09 февраля 2012 - 15:13 в Тест-дизайн и ручное тестирование
"Я могу печатать до 9000 знаков в минуту, правда фигня какая-то получается" (с)Не знаю)
возможно, но сомнительно.
#100766 Здравый смысл и тестирование
Отправлено автор: OVA 09 февраля 2012 - 09:11 в Управление тестированием
Главное чтобы это было желаемое (кем?) и ожидаемое (кем?) свойство системы. Иначе это проблема, причем, возможно, очень серьезная.Ну а мы ему в ответ: "Это свойство системы. Именно такой она и разрабатывалась."
#100765 Проблемы с локализацией багов
Отправлено автор: OVA 09 февраля 2012 - 09:08 в Тест-дизайн и ручное тестирование
Смотря какойКонечно :) Писать код намного проще :)
#100603 Уровень абстракции тестов
Отправлено автор: OVA 07 февраля 2012 - 06:40 в Автоматизированное тестирование
Нет ничего что всегда оправдано.Всегда ли это оправдано? Например, система на движке ActiveBpel с наверченым сверху функционалом на десяток человеколет разработки. Как генерировать воркфлоу онлайн-магазина, я примерно представляю. Как генерировать воркфлоу вместе с проверками на такой системе - пока загадка для меня.
Писать полноценную машину это долго, но запчасти для таких роботов можно писать относительно просто, а профита с них много. Сколько у вас времени займет написание скрипта, который будет случайным образом наполнять корзину интернет-магазина и проверять что все ок? Сколько времени займет перевод скрипта на контролируемый ввод? Сколько времени займет построение графа состояний корзины (для дизайна же делается, чего уж там)? Сколько времени займет генератор сценариев из этого графа для вашего скрипта с контролируемым вводом?
Скрипт на тестирование автоподсказок в bing'е у Harry Robinson'а составил всего 40 (кажется) строк кода. А профита с него было много.
Есть частично готовые решения (не очень хорошо заточенные именно под workflow, но зато отлично работающие в плане покрытия графа состояний): http://crawljax.com/plugins/
Можно начать писать с простого набора автоматизированных оракулов (искать и читать на тему Oracle Based Test Automation).
В общем поле для творчества весьма богатое, да и много времени много там далеко не все кушает, особенно если слона не целиком кушать.
#100601 Уровень абстракции тестов
Отправлено автор: OVA 07 февраля 2012 - 05:42 в Автоматизированное тестирование
Если покрыть все функции довольно плотно, то шансов на то что вместе оно не работает будет мало.В принципе, автоматизированно каждый шаг можно проверить и по отдельности. Однако, много раз встречал ситуацию, когда отдельно все работает, а вместе почему-то нет.
Если продолжать филосовствовать дальше, то можно сказать, что это своего рода системный тест на базе случаев использования (use cases), в то время как отдельные тесты - это аналог модульных тестов.
Такого рода сценарии мы называем end-2-end тестами и проводим их при каждой выдаче приложения в тест. Получается, что это автоматизированный Acceptance testing.
Да, согласен, риски еще останутся, но статичный сценарий для автоматических тестов их никуда не уберет. Мы просто прочертим себе дорожку по минному полю, где мины будут находиться легко и просто.
Я ничего не имею против простых сценариев. Т.к. они простые - они быстро выполняются и их проще поддерживать/дописывать/мониторить покрытие. В ряде случаев достаточно простые сценарии это очень дешевый способ отскочить. Но с усложнением сценария все эти бонусы начинают теряться.
Т.е. в вашем сценарии сразу можно выкинуть логин и всю навигацию - лучше проверять их отдельно, а остальные тесты делать без них.
Потом сделать пачки тестов для манипуляций с корзиной (небольшие, легковесные, легко рандомизируемые).
Потом сделать пачки тестов для оплаты разных корзин (нам же не обязателен UI чтобы получить точно такую же корзину?).
Это будет дешево и сердито. И придется постараться чтобы оправдать чем-то кроме паранойи наличие теста в котором будет производиться склейка всего вышеприведенного. Если вы боитесь что там в куки валится мусор - лучше проверять их. Это быстрее, дешевле и проще интерпретировать. Если боитесь что в разных ситуациях в базу пишутся разные вещи - улучшайте проверки в существующих тестах, сценарий тут не сильно поможет.
Собственно это я и имею ввиду утверждая, что автоматические тесты лучше дизайнить отдельно. Оправдание паранойи развесистыми сценарными тестами это очень дорогостоящее удовольствие. Иногда необходимое, но зачастую служащее как оправдание того, что кому-то лень заниматься Failure Model.
ЗЫ: А про Acceptance Testing есть старенькая и очень хорошая презентация от Болтона, кстати. В случае с автоматизацией ко всем бедам можно просто пририсовать, что приемочный тест будучи автоматизированным тупеет на глазах. Тем самым используя, например, всякие BDD фреймы (да и просто большие наборы приемочных тестов) стоит очень хорошо понимать с чем связались.
#100599 Проблемы с локализацией багов
Отправлено автор: OVA 07 февраля 2012 - 04:57 в Тест-дизайн и ручное тестирование
Потому что читать я его могу. Писать на нем желания не возникает от слова "вообще".почему именно на перле?)
мало ли кто с чем и как работает то)
У меня есть команда, мы с ними уж сами как-нибудь разберемся что стоит делать, а чего нет. Если я решил потратить на что-то солидный кусок времени, то у меня на это есть серьезные причины. Мы с вами можем долго кидаться примерами и контрпримерами, но давайте начнем с простого - я не маленький мальчик у которого молоко альма матер на губах еще не обсохло и меня не надо бить палкой чтобы я больше лучше работал (я от этого только разозлюсь, ровно как и от бессмысленной бюрократии и шатания по начальникам).И вполне нормально, что если у вас куча работы, и условно вы занимаетесь только черноящичным тестированием, а вам захотелось /приспичило полезть в серый ящик - вам начальство даст по голове и будет право. Если вы предварительно с ним это не обсудили.
А уж если вы сидите ковыряетесь в коде пытаясь понять баг Х, когда у вас там еще куча не протестированного функционала = это вообще фейл.
Я занимаюсь очень разным тестированием. В том числе не очень автоматизированным тестированием в местах где GUI не светит.Вы не поймете если вы занимаетесь только автоматизированным тестированием.
#100533 Уровень абстракции тестов
Отправлено автор: OVA 06 февраля 2012 - 10:50 в Автоматизированное тестирование
Давайте начнем с простых вопросов.Оппа... И чем же он не продуктивен? Как вы собираетесь писать скрипт на проверку некоевого сценария состоящего допустим из 7-8 шагов (а иногда и 10-15)?
Вам точно нужно проверять именно этот сценарий? Если да, то почему. Ответ "мне так начальник сказал" это плохой ответ.
Что происходит в ходе теста?
Что бы вы хотели узнать в ходе теста?
Точно ваш сценарий это самый простой и удобный способ получить ответы на предыдущие два вопроса?
В большинстве случаев перекладывание мануального сценария на робота это не дизайн теста под робота, а перекладывание с больной головы на еще более больную.
Если вам нужно писать тесты на какую-то функциональность - пишите тесты на нее и только на нее, сценарии тут в большинстве случаев лишь бесполезная трата времени и усложнение интерпритации теста (к тому же добавление лишних точек провала).
Если вам нужно писать тесты на workflow, пишите машину, которая будет уметь генерировать workflow, а не проходить один и тот же сценарий из раза в раз.
Если у вас есть какие-то более интересные вопросы, на которые куда проще отвечать при помощи большого и страшного компьютера - придумывайте хорошие тесты которые будут на эти вопросы отвечать.
#100518 Уровень абстракции тестов
Отправлено автор: OVA 06 февраля 2012 - 09:13 в Автоматизированное тестирование
Я не предлагаю следовать. Идеал он для того чтобы к нему стремиться. Мой опыт подсказывает что много ассертов в тесте зачастую хорошая эвристика для определения тестов на рефакторинг. Как правило такие тесты первые кандидаты в очереди на редизайн. Но мой опыт на то и мой, что не ваш.Зачем? Зачем я буду следовать синтетическому ограничению, которое в основном советуют люди, которые пишут книги, а не тесты?
Возможно (хотя я не верю) в "настоящих" юнит тестах такое ограничение имеет смысл. Но у меня же UI тесты имитирующие действия пользователя.
А откуда такая задача? Это в принципе очень непродуктивный подход к дизайну автоматических тестов.Более того, далее стоит задача покрывать сценарии, описанные в спеке, т.е. там сделал действие, проверил, сделал, проверил итд в одном тесте.
#100500 Уровень абстракции тестов
Отправлено автор: OVA 06 февраля 2012 - 04:10 в Автоматизированное тестирование
№2 еще бы допилить, чтобы ассерты были только в одном тесте, ну и в идеале - один ассерт = один тест.
#100499 Быстрый способ создания большого кол-ва e-mailов для тестирования
Отправлено автор: OVA 06 февраля 2012 - 04:03 в Тест-дизайн и ручное тестирование
А зачем? Поднять почтовый сервер можно на рабочей машинке.нас не пускают на пушечный выстрел ни в базу данных, ни к серверу.
ЗЫ: А вообще читаю я вас и складывается картина организационно-политического "ада и израиляЪ".
#100498 Проблемы с локализацией багов
Отправлено автор: OVA 06 февраля 2012 - 04:01 в Тест-дизайн и ручное тестирование
Писать на перле? Боженька упаси!но когда умеешь читать, хочется попробовать писать и т.д.
Вот это, кстати, я категорически не понимаю.но когда изначально говорится - вы тестируете ТОЛЬКО функционал, и не дай вам бог сунуться на территорию клиентского отдела - программеры голову отгрызут чужаку на своей полянке - при этом ко мне приходят и заявляют мол, слушай, ты вот баг написала, но он нифига не так воспроизводиться и не тут, а вот смотри в коде вот тут вот.
надеюсь понятно обьяснила.
#100453 Тестирование сервисов
Отправлено автор: OVA 03 февраля 2012 - 17:16 в JMeter - Тестирование производительности
А что такое xml-запрос? *trollface.jpg*
#100452 Проблемы с локализацией багов
Отправлено автор: OVA 03 февраля 2012 - 17:14 в Тест-дизайн и ручное тестирование
Основной инструмент тестировщика это его мозг. Все остальные инструменты применяются когда мозга уже явно недостаточно (я не про наркотики!)Суть поста в том, что хотелось бы иметь какой-то инструмент (если таковой имеется), чтобы лучше локализовывать баги.
#100451 Проблемы с локализацией багов
Отправлено автор: OVA 03 февраля 2012 - 17:12 в Тест-дизайн и ручное тестирование
Вы не поверите, но читать код и писать код это две большие разницы.Да, если у вас есть желание, возможность и время для вникания в продукт до уровня разработчика - это круто.
Но если я вникну до уровня разработчика - может я и фиксить сама буду?
что будет в итоге?
я стану разработчиком.
вы этого хотите?
вам это нужно - окей, вперед.
ЗЫ: У меня нет должностной инструкции. У меня теперь нет обязанностей? Или есть? Можно я буду считать что мои обязанности это кушать пончики и смотреть телек? "Если в ваши обязанности не входит..." - аж ругаться хочется от такого рудимента.
#100412 Проблемы с локализацией багов
Отправлено автор: OVA 03 февраля 2012 - 10:20 в Тест-дизайн и ручное тестирование
Баги вида "НИЧЕГО НЕ РАБОТАЕТ!" (общий случай бага "крутится круглый значок и ничего не появляется") это в худшем случае совершенно бесполезная паника (читать как "вредительство"), а в лучшем просто флажок вида "копать тут". ответ на вопрос кому копать во многом зависит от задач, которые ставятся. Если нужно посмотреть (поверхностно) как можно больше в сжатые сроки - тогда копать разработчику (тут, правда, предполагается что его время не казенное). Если нужно искать проблемы, причем проблемы серьезные - копать тестировщику.Ну а вообще, дефекты вида "Не отрабатывает ajax-запрос на записях с NULL в таблице REFERENCES" нравятся разработчикам на порядок больше, чем описание "крутится круглый значок и ничего не появляется". Хотя конечно всегда приходится искать баланс между своим временем и трудозатратами разработчиков.
#100404 Быстрый способ создания большого кол-ва e-mailов для тестирования
Отправлено автор: OVA 03 февраля 2012 - 08:19 в Тест-дизайн и ручное тестирование
А один раз научиться это делать самим не вариант?ох ели бы)
наши разработчики самые занято-разрабатываемые в мире
нам реально в 100 раз проще и быстрее насоздавать себе обычных ящиков.)
#100396 Проблемы с локализацией багов
Отправлено автор: OVA 03 февраля 2012 - 05:45 в Тест-дизайн и ручное тестирование
Изучайте используемые технологии, изучайте внутреннее устройство продукта. Со временем придет понимание как оно работает, как оно устроено. Выгода, кстати, не только в том, что вам будет проще локализировать и описывать проблемы (а в ряде случаев и фиксить всякую мелочь), но и в том, что вы получите отличный дополнительный арсенал для моделирования отказов и сбоев.Проходит время и мне возвращают багу с комментарием, что она будет исправлена, а причина ошибки совершена в другом, а не в том, что указана в тикете. В данном случае был виноват фильтр, который зашит внутри кода, который требуется девелоперу для реализации других сторонних задач.
Так вот и получается, что бага все-таки локализована была неправильно
#100366 Быстрый способ создания большого кол-ва e-mailов для тестирования
Отправлено автор: OVA 02 февраля 2012 - 10:52 в Тест-дизайн и ручное тестирование
Это быстро, особенно если надо только для себя. К тому же весьма небесполезное знание.в большинстве случаев, нашим некогда заниматься созданием почтового ящика и настраивать его, а нам проще завести 100500 ящиков на разных почтах, нежели дождаться когда снизойдут до существления нашей просьбы.
ЗЫ: Топикстартеру пофиг, флудим дальше.
#100353 Нужен Совет по методам тестирования
Отправлено автор: OVA 02 февраля 2012 - 08:00 в Тест-дизайн и ручное тестирование
Нененнененене! Врагу не пожелаю заниматься функциональщиной через нагрузочные инструменты!Ок, давайте автору линки, или вы думаете, он так сходу и поймет, где ему взять нагрузочные инструменты, а также как с ними работать? :)
Это все - время...
#100342 Быстрый способ создания большого кол-ва e-mailов для тестирования
Отправлено автор: OVA 01 февраля 2012 - 17:20 в Тест-дизайн и ручное тестирование
Я к тому что:не ерунда , увы)
на практике проверено и не единожды.)
1. В половине случаев это тестирование чужого сервера/клиента вашими письмами (как правило HTML формат и все такое).
2. В другой половине случаев это проверка интернетов.
Выполнять надо соответственно. Регистрация совсем не обязательна, достаточно письма отправлять.
Для тестирования того что ваша софтина работает корректно сама по себе достаточно локального почтового сервера (можно и без него, но тут объяснять дольше).
#100339 Быстрый способ создания большого кол-ва e-mailов для тестирования
Отправлено автор: OVA 01 февраля 2012 - 15:58 в Тест-дизайн и ручное тестирование
Это, простите меня, ерунда полная.вы сможете гарантировать что пользователи отправившие запрос на регистрацию в яхо, яндекс, рамблер и пр получат письма? -нет
что там корректно распознается текст?- нет
что там корректно сработает переход по ссылке ?-нет
что приложенные изображения корректны, и открываются? - нет
что письмо пришло через Х секунд а не Х часов? -нет
POP3 как был POP3 так им и останется. И локальный это сервер или сервер Яндекса - ничего не изменится.
А все остальные ваши страхи проверять кроме как с продакшен ноды смысла нет - потому что интернет роутинг такой интернет роутинг. Кстати, пытаясь ответить на большую часть этих вопросов проверять вы будете в именно его. Но это сомнительное развлечение на долгосрочную перспективу, т.к. Сеть меняется не уведомляя вас и ведет себя плохо тоже без спросу.
Это была ваша проблема или проблема чужого сервера?на моей практике была ситуация когда на почте 15 (именно 15-ое) отправленное письмо приходило через 24 часа.
проверить это можно было только создав 15,30, 45 и + ящиков на данной почте к примеру.
При этом работающее приложение вам в принципе не нужно для этого, т.к. фактически вы проверяете thirdparty клиенты (имеет смысл, наверное) и сервера + как до них идет ваша почта.получение ответов каких то писем, рассылок, исходя из моей практики нужно тестировать именно вручную "наживо" в Х почтах и ящиках.
#100313 Нужен Совет по методам тестирования
Отправлено автор: OVA 01 февраля 2012 - 04:36 в Тест-дизайн и ручное тестирование
Обычно такое кино выливается в функциональное тестирование на нагрузочном стенде нагрузочными же инструментами.Когда он поймет, что надо изучить для проведения этого тестирования :) А может, есть более приоритетные задачи? На текущий момент? Глупо ведь отдавать неработающую по функциям систему, но зато "она выдержит 1000 юзеров сразу!". Приоритеты, расставляйте приоритеты!
- Форум тестировщиков
- → Публикации OVA
- Политика Конфиденциальности
- Правила форума ·