Всем привет!
В этой статье я хочу рассказать о том, как можно выжать максимум из IP-камеры, организовав на ее базе не просто видеонаблюдения, а уже нечто, приближенное к пожарно-охранному комплексу, по средством подключения различных датчиков (PIR, тепла, воды и т.д.). Речь пойдёт о подключении, настройке ip-камер и датчиков, о том, насколько это может быть полезно в обеспечении бытовой безопасности.
Читать полностью »
Прежде чем начать рассказ про наш очередной opensource-инструмент, давайте я поясню, для чего мы его сделали. Я довольно много общаюсь с коллегами-тестировщиками и разработчиками из разных компаний. И, по моему опыту, автоматизация тестирования ─ один из самых непрозрачных процессов в цикле разработки ПО. Посмотрим на типичный процесс разработки функциональных автотестов: ручные тестировщики пишут тест-кейсы, которые нужно автоматизировать; автоматизаторы что-то делают, дают кнопку для запуска; тесты падают, автоматизаторы разгребают проблемы.
![Allure — фреймворк от Яндекса для создания простых и понятных отчётов автотестов [для любого языка]](https://www.pvsm.ru/images/2014/08/08/Allure-freimvork-ot-yandeksa-dlya-sozdaniya-prostyh-i-ponyatnyh-otchyotov-avtotestov-dlya-lyubogo-yazyka.jpg "Allure — фреймворк от Яндекса для создания простых и понятных отчётов автотестов [для любого языка]")
Я вижу здесь сразу несколько проблем: ручные тестировщики не знают, насколько автотесты соответствуют написанным тест-кейсам; ручные тестировщики не знают, что именно покрывается автотестами; автоматизаторы тратят время на разбор отчётов. Как ни странно, но все три проблемы вытекают из одной: результаты выполнения тестов понятны только автоматизаторам — тем, кто эти тесты писал. Именно это я и называю непрозрачностью.
Однако существуют и прозрачные процессы. Они построены таким образом, что вся необходимая информация доступна в любой момент. Создание таких процессов может потребовать некоторых усилий на старте, но эти затраты быстро окупаются.
Именно поэтому мы разработали Allure — инструмент, позволяющий внести прозрачность в процесс создания и выполнения функциональных тестов. Красивые и понятные отчёты Allure помогают команде решить перечисленные выше проблемы и начать наконец разговаривать на одном языке. Инструмент имеет модульную структуру, позволяющую легко интегрировать его с уже используемыми инструментами автоматизации тестирования.
Читать полностью »
Компания, в которой я работаю, разрабатывает ПО на заказ, в том числе мобильные приложения на базе Android и iOS. В связи с тем, что конкуренция в этом сегменте рынка довольно высока, тестировщики не только отвечают за соответствие конечного продукта спецификациям и ожиданиям клиента, но еще и поставлены в жесткие рамки по бюджету и срокам тестирования. Это побуждает нас исследовать новые инструменты и методы, которые позволили бы нам уменьшать затраты на тестирование и повышать качество продуктов.
Imagrium — это результат одного из таких исследований. Технически это Jython фреймворк для кросс-платформенного тестирования мобильных Android/iOS приложений с помощью распознавания изображений, написанный нашей компанией. Он представлен в виде рабочего PyDev проекта, который вы можете изменить под свои нужды. Код распространяется под MIT лицензией и доступен на Github. В этой статье я расскажу о принципах работы фреймворка и его устройстве.
Читать полностью »
Добрый день, уважаемые читатели! Хочу рассказать о сервисе для быстрой аренды виртуальных серверов, особенностях его создания, поставленных задачах и о том, что в итоге получилось.. А заодно поделиться радостью от его запуска и пригласить попробовать!
Сразу хочу заметить – это не реклама. Ниже только сухие факты.
Для всех желающих кинуть в меня булыжником – принимаю на e-mail*
Для остальных: «welcome под кат».Читать полностью »
Вы знаете, что такое Selenium и/или PhantomJS? И с чем их едят? Тогда, возможно, вам будет интересен проект Dalek.js — кроссбраузерная утилита для тестирования веб-приложений.
Dalek.js позволяет писать тесты, которые ходят по веб-страничкам, щелкают ссылки, заполняют формы, отправляют данные и делают скриншоты. То же самое и даже больше делают тесты, написанные с использованием Selenium'а или Phantom.js, в чем подвох?
Доброе время суток! В этом посте я бы хотел рассказать о тестовых окружениях, что такое чистое и грязное окружение, какие тесты в них выполняются и какие задачи достигаются. Если вы не равнодушны к этим вопросам, добро пожаловать под кат.
Читать полностью »
Хотя LoadRunner обладает неплохим API для различной текстовой обработки, иногда его всё же не хватает, и тогда приходится расширять его самописными функциями. Часто такие реализации становятся изобретением велосипеда, поскольку почти все задачи, как известно, уже когда-то кем-то решены. Кроме того, поскольку у меня неплохой бэкграунд в C#, при решении какой-либо задачи часто возникают мысли, что эта задача легко бы решилась, будь у меня под рукой библиотека классов .NET Framework. В принципе, если бы я был Java-программистом, у меня возникали бы аналогичный мысли и про Java (где тоже есть почти всё), но поскольку мне ближе .NET, то речь пойдёт именно о нём. В качестве побочного эффекта статья будет полезна тем, кто хочет узнать, как вызывать CLR-код из native-кода. Также приводится небольшое исследование производительности этого варианта и прилагается рабочий шаблон проекта Visual Studio и скрипт LoadRunner.
Читать полностью »
Как-то раз мы съездили на конференцию SQA days, где мне довелось попасть на доклад «Джентельменский набор тестировщика». Хотелось бы продолжить эту тему и рассказать о своих тулзах, облегчающих жизнь тестировщика.
Справедливости ради стоит отметить, что у нас, в Zeptolab, работает всего несколько QA Lead’ов, а всю основную работу делают аутсорсеры. Тем не менее, на нашу долю приходится обширный список обязанностей, требующий глубоких знаний о продукте, работе различных sdk и методов диагностики работы приложений.
Чтобы сильно не раздувать статью, я ограничусь лишь небольшим описанием работы инструментов. Если у вас возникнут вопросы — можем обсудить их в комментариях.
Читать полностью »
Я работаю в компании, которая делает достаточно большое и, не побоюсь этого слово, громоздкое мобильное приложение с солидной для мобильного приложения историей в несколько лет и, соответственно с довольно солидным и монструозным кодом.
Поток пожеланий от заказчика разнообразен и обилен и в связи с этим время от времени приходится вносить изменения даже в те места, которые для этого, вроде как, не предназначены. Некоторые, возникающие при этом проблемы — регрессионные баги — доставляют время от времени немало сложных часов.
При этом, по тем или иным причинам на проекте существует лишь ручное тестирование и довольно внушительного количество тестировщиков, а довольно наивные попытки автоматизации оного остались лишь на уровне нескольких довольно тривиальных юнит-тестов на уровне «Hello world».
В частности — у отдела тестирования есть внушительный цикл тестов для поиска регрессии, который проводится достаточно регулярно и занимает приличное количество времени. Соответственно, однажды возникла задача как-то оптимизировать этот процесс. Об этом и пойдет речь.
Честно, я не помню, какие средства для автоматизированного приемочного тестирования я смотрел и почему они мне не подошли. (Буду очень благодарен, если кто-то в комментариях подскажет интересные варианты решения этого — наверняка я пропустил что-то очень стоящее) Одно могу сказать точно — так как наше приложение, фактически тонкий клиент — очень многие кейсы невозможно(ну или как минимум, я не знаю как) покрыть юнит-тестами и нужно что-то еще. Так или иначе было решено написать свою библиотеку для автоматизации приемочного тестирования.
Читать полностью »
Как известно из книги «Путеводитель для путешествующих автостопом по галактике», ответ на главный вопрос жизни, вселенной и всего такого — 42. Процент покрытия кода по линиям на одном из моих проектов — 81, дает ли эта цифра ответ на главный вопрос тестирования «cколько тестов достаточно для определения качества продукта»?
В течении своей работы в айти-сфере и тестировании я видела мало команд и проектов, где тестировщики реально используют code coverage в своей работе. Связано это на мой взгляд с двумя вещами:
1. Тем, что тестируем мы прежде всего требования;
2. Далеко не все понимают, как считать и использовать покрытие.
Интересующимся предлагаю свой взгляд на эти 2 пункта.
Читать полностью »
