Главное чтобы это было желаемое (кем?) и ожидаемое (кем?) свойство системы. Иначе это проблема, причем, возможно, очень серьезная.Ну а мы ему в ответ: "Это свойство системы. Именно такой она и разрабатывалась."
- Форум тестировщиков
- → Публикации OVA
Публикации OVA
162 публикаций создано OVA (учитываются публикации только с 02 июля 2023)
По типу контента
По пользователю
#100766 Здравый смысл и тестирование
#87696 кто что создал интересного
Под айфон с четвертой верии ои нативные редтва есть. Ну и еще тут гугль вкусного выдает + у Hathy на сайте няшки
Та тащемта и под симбиан есть. Вообще под мобилки средств расплодилось порядочно последнее время.
Та тащемта и под симбиан есть. Вообще под мобилки средств расплодилось порядочно последнее время.
#88648 кто что создал интересного
Мы пока тупо собираем статистику по тестам (время работы, падения, маркируем ручками ложные падения и ложные проходы когда найдем и т.п.) и всякие подозрительно ведущие себя тесты маркируем. Обычно такие тесты довольно шустро уходят в отдельную резервацию где и предаются анафеме.
#87742 кто что создал интересного
Про GUI:
Гугль говорит что для iOS4 оно уже в Interface Builder есть (можно считать фриварным?). Ну плюс всякие selenium iphone webdriver, FoneMonkey, Sikuli, UISPEC и т.п. в зависимости от специфики задачи. Для симбиана и ведроида халявные тоже есть. Для последнего так вообще тысячи их.
И я таки не понимаю почему не фриваря сразу плохо? SQUISH вполне секси выглядит. И стоит не сильно дорого.
ЗЫ: И для других тестов тоже есть средства. В том числе не функциональных.
Гугль говорит что для iOS4 оно уже в Interface Builder есть (можно считать фриварным?). Ну плюс всякие selenium iphone webdriver, FoneMonkey, Sikuli, UISPEC и т.п. в зависимости от специфики задачи. Для симбиана и ведроида халявные тоже есть. Для последнего так вообще тысячи их.
И я таки не понимаю почему не фриваря сразу плохо? SQUISH вполне секси выглядит. И стоит не сильно дорого.
ЗЫ: И для других тестов тоже есть средства. В том числе не функциональных.
#87877 кто что создал интересного
Ну увы коммунизма в тестировании еще не случилось и нет еще ни одного толкового инструмента с которым могла бы справиться даже моя бабушка. Ну и чем больше работаю, тем боле убеждаюсь что Win как платформа это скорее препятствие чем бонус (за исключением случаев когда вы по самые уши в дотнете).
Теперь по вопросам:
0. Почему плохо учить objective с?
1. Что такое платформа для запуска тестов? Вы под Win собрались приложения для iPhone пускать? Это нонсенс. Просто тесты и всякие эмуляторы стартовать? Скриптовые языки в руки и будет счастье. В конце концов есть PowerShell и просто весьма неплохая консолька у последних версий Win.
2. Много:
selenium iphone webdriver - селениум второй же. Правда только для тестирования веб-приложений на мобилках. Макоси не надо, вин вполне ок.
Sikuli - да, по рисункам. Но достаточно гибкий, чтобы для ряда простых приложений (а таких под мобилки большинство... если ваше взрывает мозг, то увы) можно было создавать неплохие и вполне легко поддерживаемые тесты. Работает под Win, если надо. Тотальная java + jython, насколько помню.
FoneMonkey - Objective-C or JavaScript-based tests. Record/playback правда и есть проблемы с гибкостью.
UISpec - BDD, да. Но таки Ruby. Ну иногда придется все же с objective с ковыряться.
Это так, Brief.
Просто мне довольно странным видится когда люди разрабатывают приложения под iPhone и прочее яблочное добро, но у них есть серьезные проблемы с работой под макосью, нет доступа до средств разработки тех же самых яблочных продуктов и стойкое отвращение к objective с. И я не очень понимаю почему производитель отказывается платить деньги за средства разработки, особенно если они хорошие и решают попутно целую кучу головняков.
Теперь по вопросам:
0. Почему плохо учить objective с?
1. Что такое платформа для запуска тестов? Вы под Win собрались приложения для iPhone пускать? Это нонсенс. Просто тесты и всякие эмуляторы стартовать? Скриптовые языки в руки и будет счастье. В конце концов есть PowerShell и просто весьма неплохая консолька у последних версий Win.
2. Много:
selenium iphone webdriver - селениум второй же. Правда только для тестирования веб-приложений на мобилках. Макоси не надо, вин вполне ок.
Sikuli - да, по рисункам. Но достаточно гибкий, чтобы для ряда простых приложений (а таких под мобилки большинство... если ваше взрывает мозг, то увы) можно было создавать неплохие и вполне легко поддерживаемые тесты. Работает под Win, если надо. Тотальная java + jython, насколько помню.
FoneMonkey - Objective-C or JavaScript-based tests. Record/playback правда и есть проблемы с гибкостью.
UISpec - BDD, да. Но таки Ruby. Ну иногда придется все же с objective с ковыряться.
Это так, Brief.
Просто мне довольно странным видится когда люди разрабатывают приложения под iPhone и прочее яблочное добро, но у них есть серьезные проблемы с работой под макосью, нет доступа до средств разработки тех же самых яблочных продуктов и стойкое отвращение к objective с. И я не очень понимаю почему производитель отказывается платить деньги за средства разработки, особенно если они хорошие и решают попутно целую кучу головняков.
#96837 Автоматизация мобильного тестирования (iPhone,Android). Нужно ли это в
Пробовали. Под те же Android и iPhone решения ничем не лучше того же Robotium и UI Automation. Хорошо если не хуже (бывают такие, не спорю). Если напишите чем m-eux лучше - будет о чем поспорить. Я пока никаких преимуществ не вижу (поддержка других платформ - ну оооок, но это out of scope).Вы пробывали хоть один нормальный инструмент для тестирования мобильного софта за деньги?
Я думаю вряд ли. То что стоит своих денег, с задачей справляется на ура. Тот же m-eux
+ зачастую платное решение предлагает нам делать для автоматики дополнительную сборку с инжектором, что для ряда тестов (потребление ресурсов, тащемта) неприемлимо.
Ваш m-eux фактически пользуется тем же чем пользуется Robotium и тесты с xcode на UI Automation. Зачем мне за это деньги платить? On-Device запуск на Ведроиде только запустили, а для iOS?
Еще одна проблема - ограничения по рабочей среде. Если работаете в MSVS, QTP или Eclipse - ок. Если нет - ой. В том же eclipse я могу и Robotium фигачить. Тестировать iOS не имея мак под рукой - тоже то еще извращение, имхо.
Нерешенная никем проблема - ненативные контролы. Впилите Android Qt приложение без единого нативного контрола на ведроид и попробуйте его автоматизировать через m-eux.
Третье - головняки с интеграцией своих thirdparty решений. Они будут и так и так, платное решение ничем не поможет.
Единственное, где я вижу смысл в таких решениях на данный момент - нам хочется фигачить в [вставить нужное IDE], но это получается что фактически мы платим деньги за возможность использовать любимую IDE.
#100216 Автоматизация мобильного тестирования (iPhone,Android). Нужно ли это в
Можно. Для UI автоматизации средств море и там и там. Платные или бесплатные - на ваш вкус.
По памяти:
На андроиде top через консольку (adb или прямо на устройстве) запускаете и будет вам счастье. Xcode примерно так: http://www.raywender...uments-tutorial
По памяти:
На андроиде top через консольку (adb или прямо на устройстве) запускаете и будет вам счастье. Xcode примерно так: http://www.raywender...uments-tutorial
#96788 Автоматизация мобильного тестирования (iPhone,Android). Нужно ли это в
Нативное с xcode.
#96833 Автоматизация мобильного тестирования (iPhone,Android). Нужно ли это в
Я боюсь тратить деньги на тот фарш который продают под видом софта для тестирования мобильного софта по меньшей мере нецелесообразно. Robotium и нативные средства iРазработки более чем достаточны для тестирования нативных морд (Fred и т.п. по желанию, но это инжекторы фактически). Для тестирования веба есть относительно нормально работающий WebDriver под обе платформы. Для тестирования вообще всего подноготного есть SL4A на ведроиде + adb консолька (под iPhone хуже, но вроде консолька тоже была какая-то).
Фемтосоты, мониторинг траффика на wi-fi точках (та тащемта местами можно и прямо на мобилках, но тут рутовать надо) и прочие средства адекватного замера производительности over da air по желанию.
Фемтосоты, мониторинг траффика на wi-fi точках (та тащемта местами можно и прямо на мобилках, но тут рутовать надо) и прочие средства адекватного замера производительности over da air по желанию.
#100518 Уровень абстракции тестов
Я не предлагаю следовать. Идеал он для того чтобы к нему стремиться. Мой опыт подсказывает что много ассертов в тесте зачастую хорошая эвристика для определения тестов на рефакторинг. Как правило такие тесты первые кандидаты в очереди на редизайн. Но мой опыт на то и мой, что не ваш.Зачем? Зачем я буду следовать синтетическому ограничению, которое в основном советуют люди, которые пишут книги, а не тесты?
Возможно (хотя я не верю) в "настоящих" юнит тестах такое ограничение имеет смысл. Но у меня же UI тесты имитирующие действия пользователя.
А откуда такая задача? Это в принципе очень непродуктивный подход к дизайну автоматических тестов.Более того, далее стоит задача покрывать сценарии, описанные в спеке, т.е. там сделал действие, проверил, сделал, проверил итд в одном тесте.
#100500 Уровень абстракции тестов
№2 еще бы допилить, чтобы ассерты были только в одном тесте, ну и в идеале - один ассерт = один тест.
#100601 Уровень абстракции тестов
Если покрыть все функции довольно плотно, то шансов на то что вместе оно не работает будет мало.В принципе, автоматизированно каждый шаг можно проверить и по отдельности. Однако, много раз встречал ситуацию, когда отдельно все работает, а вместе почему-то нет.
Если продолжать филосовствовать дальше, то можно сказать, что это своего рода системный тест на базе случаев использования (use cases), в то время как отдельные тесты - это аналог модульных тестов.
Такого рода сценарии мы называем end-2-end тестами и проводим их при каждой выдаче приложения в тест. Получается, что это автоматизированный Acceptance testing.
Да, согласен, риски еще останутся, но статичный сценарий для автоматических тестов их никуда не уберет. Мы просто прочертим себе дорожку по минному полю, где мины будут находиться легко и просто.
Я ничего не имею против простых сценариев. Т.к. они простые - они быстро выполняются и их проще поддерживать/дописывать/мониторить покрытие. В ряде случаев достаточно простые сценарии это очень дешевый способ отскочить. Но с усложнением сценария все эти бонусы начинают теряться.
Т.е. в вашем сценарии сразу можно выкинуть логин и всю навигацию - лучше проверять их отдельно, а остальные тесты делать без них.
Потом сделать пачки тестов для манипуляций с корзиной (небольшие, легковесные, легко рандомизируемые).
Потом сделать пачки тестов для оплаты разных корзин (нам же не обязателен UI чтобы получить точно такую же корзину?).
Это будет дешево и сердито. И придется постараться чтобы оправдать чем-то кроме паранойи наличие теста в котором будет производиться склейка всего вышеприведенного. Если вы боитесь что там в куки валится мусор - лучше проверять их. Это быстрее, дешевле и проще интерпретировать. Если боитесь что в разных ситуациях в базу пишутся разные вещи - улучшайте проверки в существующих тестах, сценарий тут не сильно поможет.
Собственно это я и имею ввиду утверждая, что автоматические тесты лучше дизайнить отдельно. Оправдание паранойи развесистыми сценарными тестами это очень дорогостоящее удовольствие. Иногда необходимое, но зачастую служащее как оправдание того, что кому-то лень заниматься Failure Model.
ЗЫ: А про Acceptance Testing есть старенькая и очень хорошая презентация от Болтона, кстати. В случае с автоматизацией ко всем бедам можно просто пририсовать, что приемочный тест будучи автоматизированным тупеет на глазах. Тем самым используя, например, всякие BDD фреймы (да и просто большие наборы приемочных тестов) стоит очень хорошо понимать с чем связались.
#100533 Уровень абстракции тестов
Давайте начнем с простых вопросов.Оппа... И чем же он не продуктивен? Как вы собираетесь писать скрипт на проверку некоевого сценария состоящего допустим из 7-8 шагов (а иногда и 10-15)?
Вам точно нужно проверять именно этот сценарий? Если да, то почему. Ответ "мне так начальник сказал" это плохой ответ.
Что происходит в ходе теста?
Что бы вы хотели узнать в ходе теста?
Точно ваш сценарий это самый простой и удобный способ получить ответы на предыдущие два вопроса?
В большинстве случаев перекладывание мануального сценария на робота это не дизайн теста под робота, а перекладывание с больной головы на еще более больную.
Если вам нужно писать тесты на какую-то функциональность - пишите тесты на нее и только на нее, сценарии тут в большинстве случаев лишь бесполезная трата времени и усложнение интерпритации теста (к тому же добавление лишних точек провала).
Если вам нужно писать тесты на workflow, пишите машину, которая будет уметь генерировать workflow, а не проходить один и тот же сценарий из раза в раз.
Если у вас есть какие-то более интересные вопросы, на которые куда проще отвечать при помощи большого и страшного компьютера - придумывайте хорошие тесты которые будут на эти вопросы отвечать.
#100603 Уровень абстракции тестов
Нет ничего что всегда оправдано.Всегда ли это оправдано? Например, система на движке ActiveBpel с наверченым сверху функционалом на десяток человеколет разработки. Как генерировать воркфлоу онлайн-магазина, я примерно представляю. Как генерировать воркфлоу вместе с проверками на такой системе - пока загадка для меня.
Писать полноценную машину это долго, но запчасти для таких роботов можно писать относительно просто, а профита с них много. Сколько у вас времени займет написание скрипта, который будет случайным образом наполнять корзину интернет-магазина и проверять что все ок? Сколько времени займет перевод скрипта на контролируемый ввод? Сколько времени займет построение графа состояний корзины (для дизайна же делается, чего уж там)? Сколько времени займет генератор сценариев из этого графа для вашего скрипта с контролируемым вводом?
Скрипт на тестирование автоподсказок в bing'е у Harry Robinson'а составил всего 40 (кажется) строк кода. А профита с него было много.
Есть частично готовые решения (не очень хорошо заточенные именно под workflow, но зато отлично работающие в плане покрытия графа состояний): http://crawljax.com/plugins/
Можно начать писать с простого набора автоматизированных оракулов (искать и читать на тему Oracle Based Test Automation).
В общем поле для творчества весьма богатое, да и много времени много там далеко не все кушает, особенно если слона не целиком кушать.
#96586 Приоритет дефекта
stmark, ящетаю не стоит нам скатываться в обсуждение того чем severity от priority отличается (это уже бюрократия, а не тестирование). Тем более что по работе я с первым вообще последние года четыре практически не сталкиваюсь. Договорились что не важно кто обнаружил и ладушки.
Wolonter, тогда в чем вопрос? Надо ли править ошибки приводящие к "красной лампочке"? Или надо ли подкрутить автоматическую репортилку с CI?
Wolonter, тогда в чем вопрос? Надо ли править ошибки приводящие к "красной лампочке"? Или надо ли подкрутить автоматическую репортилку с CI?
#96500 Приоритет дефекта
То кем оно обнаружено не важно.
С другой стороны не очень понятно зачем пихать в CI всякую ерунду, которая не имеет значения.
С другой стороны не очень понятно зачем пихать в CI всякую ерунду, которая не имеет значения.
#96612 Приоритет дефекта
В первую очередь они нужны чтобы получать более качественные сборки. Все. Гарантий что ничего не поломалось они никогда не дадут.
#96547 Приоритет дефекта
И severity тоже не стоило. Не у всех есть. Да и заказчик понятие растяжимое. А менеджера вообще может и не быть.
Мелкая проблема найденная заказчиком это мелкая проблема. А тотальный блокер всего и вся будет блокером вне зависимости от того кто его нашел. В целом, если у вас не 100500 приоритетов для разных багов с отдельными десятью полями для титулов, бэйджей и прочих ачивок, то способ обнаружения не влияет, т.к. групп мало.
Если у вас много жалоб пользователей на какую-то проблему, которую вы считаете незначительной, то, возможно, у вас просто что-то не так с приоритетами и стоит пересмотреть не только одну эту проблему, но и аналогичные, если есть. Точно так же с заказчиком. То что заказчик чего-то не нашел, а нашли другие не должно влиять на приоритет. И vice versa. Т.е. если оно обнаружено заказчиком и это влияет на приоритет, то или вы не пытаетесь осознать нужды заказчика или кто-то прячет от него аналогичные проблемы (есть еще много вариантов, но это долго перечислять).
Мелкая проблема найденная заказчиком это мелкая проблема. А тотальный блокер всего и вся будет блокером вне зависимости от того кто его нашел. В целом, если у вас не 100500 приоритетов для разных багов с отдельными десятью полями для титулов, бэйджей и прочих ачивок, то способ обнаружения не влияет, т.к. групп мало.
Если у вас много жалоб пользователей на какую-то проблему, которую вы считаете незначительной, то, возможно, у вас просто что-то не так с приоритетами и стоит пересмотреть не только одну эту проблему, но и аналогичные, если есть. Точно так же с заказчиком. То что заказчик чего-то не нашел, а нашли другие не должно влиять на приоритет. И vice versa. Т.е. если оно обнаружено заказчиком и это влияет на приоритет, то или вы не пытаетесь осознать нужды заказчика или кто-то прячет от него аналогичные проблемы (есть еще много вариантов, но это долго перечислять).
#96533 Приоритет дефекта
Интересно у вас дела обстоят, если любой чих главного получает максимальный приоритет.Мы с Вами видимо на разных планетах живём. "Приоритет" - это менеджерское поле и если багу нашёл самый-самый главный заказчик, человек, который за всё это дело платит, то важность правки именно этого дефекта взлетает до небес.
То кем оно обнаружено не важно.
Тут никто приорити с северети не путает?
(с) Velocity is Killing Agility by Jim HighsmithGiving the product owner/manager complete priority control makes the problem worse—we have gone from customer focus to customer control that further skews the balance of investing in new features versus the delivery engine.
Хотя... who cares?
#95334 loadUI?
А что нужно заменить? Генератор нагрузки не устраивает? Или работа с данными? Raw Data + R сильно лучше средне-бесполезных свистелок.
#100366 Быстрый способ создания большого кол-ва e-mailов для тестирования
Это быстро, особенно если надо только для себя. К тому же весьма небесполезное знание.в большинстве случаев, нашим некогда заниматься созданием почтового ящика и настраивать его, а нам проще завести 100500 ящиков на разных почтах, нежели дождаться когда снизойдут до существления нашей просьбы.
ЗЫ: Топикстартеру пофиг, флудим дальше.
#95337 loadUI?
Я тоже очень хочу чтобы я такой сидел и мне все делали хорошо забесплатно. Но так не бывает.
Большая часть готовых коробочных изделий отлично работает ровно до тех пор пока нет потребности или желания за рамки этой коробки выбраться (а оно возникает, если вы собираетесь серьезно заниматься своей работой, а не отчеты красивые рисовать). А дальше *ВНЕЗАПНО* начинается опять же то же что вы написали. И это в лучшем случае. Потому что обработку сырых данных написать достаточно один раз. Скрипты на R тоже не сильно сложно, если разобраться что и как там работает. Сборка любой метрики так же пишется ровно один раз. А если это все еще и не нужно прикручивать к уже существующему решению с закрытым кодом и/или уродским API, то занимает оно не так уж и много времени.
Генерацию графиков и прочее на R писать не надо. Оно само отлично с рядом задач справляется.
Ну и любимое - сколько времени у вас уходит на прогон тестов? сколько на их написание? сколько на дизайн? сколько на анализ результатов?
Большая часть готовых коробочных изделий отлично работает ровно до тех пор пока нет потребности или желания за рамки этой коробки выбраться (а оно возникает, если вы собираетесь серьезно заниматься своей работой, а не отчеты красивые рисовать). А дальше *ВНЕЗАПНО* начинается опять же то же что вы написали. И это в лучшем случае. Потому что обработку сырых данных написать достаточно один раз. Скрипты на R тоже не сильно сложно, если разобраться что и как там работает. Сборка любой метрики так же пишется ровно один раз. А если это все еще и не нужно прикручивать к уже существующему решению с закрытым кодом и/или уродским API, то занимает оно не так уж и много времени.
Генерацию графиков и прочее на R писать не надо. Оно само отлично с рядом задач справляется.
Ну и любимое - сколько времени у вас уходит на прогон тестов? сколько на их написание? сколько на дизайн? сколько на анализ результатов?
#100302 Быстрый способ создания большого кол-ва e-mailов для тестирования
А в чем смысл? Получать по этим адресам много почты или что?
Можно поднять свой почтовый сервер - дешево и сердито.
Если получать ничего не надо, то и создавать ничего не надо - просто слать письма с разными мылами и все.
Можно поднять свой почтовый сервер - дешево и сердито.
Если получать ничего не надо, то и создавать ничего не надо - просто слать письма с разными мылами и все.
#100404 Быстрый способ создания большого кол-ва e-mailов для тестирования
А один раз научиться это делать самим не вариант?ох ели бы)
наши разработчики самые занято-разрабатываемые в мире
нам реально в 100 раз проще и быстрее насоздавать себе обычных ящиков.)
#100499 Быстрый способ создания большого кол-ва e-mailов для тестирования
А зачем? Поднять почтовый сервер можно на рабочей машинке.нас не пускают на пушечный выстрел ни в базу данных, ни к серверу.
ЗЫ: А вообще читаю я вас и складывается картина организационно-политического "ада и израиляЪ".
