Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1515 сообщений
Cообщения с меткой

автоматизация - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Функциональная безопасность – старшая сестра информационной безопасности

Пятница, 26 Августа 2016 г. 20:14 (ссылка)

image



Безопасности на хабре посвящен целый хаб, и, пожалуй, никто особенно не задумывается, что именно вкладывается в понятие «безопасность», и так все ясно: информационная безопасность (security). Однако, есть еще и другая сторона безопасности, safety, связанная с рисками для здоровья и жизни людей, а также окружающей среды. Поскольку информационные технологии сами по себе опасности не представляют, то обычно говорят о функциональной составляющей, то есть о безопасности, связанной с правильным функционированием компьютерной системы. Если информационная безопасность стала критична с появлением интернета, то функциональная безопасность рассматривалась и до появления цифрового управления, ведь аварии происходили всегда. Информационной безопасности АСУ ТП посвящено немало статей на хабре. Функциональной безопасности авторы тоже касались, как в хабе по SCADA, так и в хабе по промышленному программированию АСУ ТП, но, как мне показалось, несколько вскользь. Поэтому я предлагаю короткую информацию об этом важном свойстве, от которого напрямую зависит, получит ли SkyNET контроль над человечеством.

В статье сделаны некоторые обобщения для АСУ ТП, а также для встроенных и кибер-физических систем.





Заслуживает ли внимания функциональная безопасность?

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

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

В статье «Интернет вещей (IoT) – вызовы новой реальности» проведен анализ киберугроз и методов обеспечения информационной безопасности для интернета вещей (Internet of Things, IoT). Одним из потенциальных рисков является перехват управления на уровне физических устройств. Тогда злоумышленник может заставить систему управления выполнять опасные функции. В этом случае информационная и функциональная безопасность являются двумя сторонами одного и того же явления. Свойство информационной безопасности должно обеспечить доступность, целостность и конфиденциальность данных системы управления. Свойство функциональной безопасности должно обеспечить корректное выполнение функций системы управления, а при возникновении отказов перевести объект управления в так называемое безопасное состояние.

Еще одним мотивом знакомства с функциональной безопасностью является понимание процесса сертификации и лицензирования. Объекты, которыми управляют компьютерные системы, зачастую создают риски для окружающей среды и людей (химическое производство, газовая и нефтяная промышленность, медицинские устройства, атомные и другие электростанции, железнодорожный, автомобильный, авиационный транспорт и т.д.). Компьютерные системы управления такими объектами должны выполнять функции безопасности и обладать определенными характеристиками (резервирование, отказоустойчивость, самодиагностика, устойчивость к внешним экстремальным воздействиям и т.п.). Контроль за разработкой, внедрением и эксплуатацией компьютерных систем управления, важных для безопасности, осуществляется государственными органами сертификации и лицензирования. Таким образом, разработчикам систем приходится знакомиться с требованиями к функциональной безопасности.



Архитектура систем управления

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

Для обобщения взглянем на очевидную структуру идеального контура управления.



image



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



image



Подобная архитектура реализуется для встроенных систем (Embedded Systems), широко применяемых в промышленной автоматизации, бытовых устройствах, автомобильных системах, медицинских устройствах, коммуникационных сетях, роботах, дронах и т.п.

В АСУ ТП (Industrial Control Systems) применяется более разветвленная архитектура, включающая объединенные в сеть датчики, программируемые логические контроллеры (ПЛК), исполнительные механизмы, хранилища данных, сервера и рабочие станции.





Schneider Electric – Modicon Quantum PLC



Наиболее сложной является типовая архитектура IoT, я вкратце о ней рассказал в статье на хабре.







Управляющая система реализуется на уровне Device Layer. Ее программно-аппаратная реализация может быть аналогична встроенной системе. С точки зрения информационной безопасности критическими являются интерфейсы DL-NL & DL-AL доступа к уровню Device Layer.

Таким образом, к системам управления, для которых важно рассматривать свойство функциональной безопасности, относятся АСУ ТП, встроенные системы и IoT.



Стандарты, относящиеся к функциональной безопасности

В области стандартизации существует такое понятие, как “umbrella standard”, т.е. основополагающий «вертикальный» стандарт верхнего уровня. Для функциональной безопасности таковым является МЭК 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems), включающий семь частей. Данный стандарт переведен на русский язык и внедрен в Российской Федерации в виде ГОСТа.

Дальше я постарался кратко интерпретировать основные положения МЭК 61508. Они, скажем так, неидеальны, однако, здравый смысл в них имеется. Ниже следует авторская обработка с учетом личного опыта в сфере функциональной безопасности.

Согласно положениям МЭК 61508, под функциональной безопасностью (functional safety) подразумевается корректное функционирование, как системы управления, так и управляемого ею оборудования. Таким образом, для обеспечения функциональной безопасности необходимо сначала определить функции безопасности (safety functions), необходимые для снижения риска управляемого оборудования, а также для достижения и сохранения этим оборудованием безопасного состояния (например, функции противоаварийной защиты). Далее, система управления должна обладать свойством так называемой полноты безопасности (safety integrity), под которым МЭК 61508 подразумевает вероятность того, что система будет корректно выполнять функции безопасности при всех заданных условиях в течение заданного интервала времени.

При обеспечении полноты безопасности (safety integrity) учитываются два типа отказов: случайные (random failures) и систематические (systematic failures).

Случайные отказы вызваны выходом из строя аппаратных компонентов и парируются такими методами, как резервирование, самодиагностика, физическое и электрическое разделение компонентов, повышение устойчивости к внешним воздействиям и т.п.

Систематические отказы вызваны ошибками проектирования, в том числе, и ошибками программного обеспечения. Устранение систематических отказов возможно путем совершенствования процессов проектирования и разработки, тестирования, управления конфигурацией, проектного менеджмента и т.п. Кроме того, поскольку классическое резервирование не позволяет избежать систематических отказов, применяется так называемое диверсное (diversity) резервирование, когда резервные каналы разработаны с применением различного программного и аппаратного обеспечения. Дорого, неудобно, но иногда помогает.

Положения МЭК 61508 детализированы для потенциально опасных областей. Существуют, например, следующие стандарты:

IEC 61511, Functional safety – Safety instrumented systems for the process industry sector;

IEC 62061, Safety of machinery – Functional safety of electrical, electronic and programmable electronic control systems;

IEC 61513, Nuclear power plants – Instrumentation and control for systems important to safety;

ISO 26262, Road vehicles – Functional safety;

EN 50129, Railway Industry Specific – System Safety in Electronic Systems;

IEC 62304, Medical Device Software;

В аэрокосмической отрасли на МЭК 61508 не ссылаются, тем не менее, подход похожий:

для авионики разработан стандарт RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification;

в космической отрасли стандарты разрабатываются космическими агентствами, например NASA использует стандарт STD 8719.13, Software Safety Standard.



Выводы

В дружной, но непредсказуемой семье «безопасность», борющейся за свободу информационных технологий от неприемлемых рисков, живут себе две сестры: старшая, функциональная безопасность (safety), и младшая, информационная безопасность (security).

Для управляющих систем, к которым относятся такие архитектуры, как АСУ ТП, встроенные системы и интернет вещей (Device Layer), основополагающим свойством является функциональная безопасность.

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

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

Для объяснения основных аспектов функциональной безопасности планируется следующий цикл статей:

Теория надежности и функциональная безопасность: основные термины и показатели;

Методы обеспечения функциональной безопасности систем управления;

Жизненный цикл безопасности для системы управления;

Тестирование систем управления, важных для безопасности.

Тематика может корректироваться в зависимости от полученных комментариев.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308634/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Что такое исполнимые бизнес-процессы. Введение в предметную область

Понедельник, 22 Августа 2016 г. 15:30 (ссылка)





Недавно на Хабре были опубликованы несколько статей ( раз, два ) на тему бизнес-процессов. Там утверждается, что в этой области всё настолько усложнено и запутанно, что разобраться в этом нельзя. Также было высказано подозрение, что теория процессного управления — по сути чистый пиар и маркетинг, не имеющий практической пользы.



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



Термин «процессное управление» применяется к двум разным сферам деятельности:


  1. В случае, когда не производится автоматизация исполнения бизнес-процессов. Задача — составить описание бизнеса в виде графических диаграмм, которые легко воспринимаются людьми. Такие диаграммы фактически представляют собой специальный язык общения менеджеров, бизнес-аналитиков и руководителей предприятий и используются для выработки и объяснения базовых решений по организации бизнеса предприятия.

  2. В случае, когда бизнес-процессы непосредственно исполняются в компьютерной среде предприятия. Будем называть процессы этого вида — исполнимые бизнес-процессы. Для исполнения таких бизнес-процессов на предприятии устанавливается специальная компьютерная система — BPMS (Business Process Managrment System) в английском варианте наименования, или СУБП (Система Управления Бизнес-Процессами) в русском варианте. Этим бизнес-процессам и посвящена данная статья.







Эволюция развития BPMS и «естественный отбор» за примерно 15 — 20 лет привели к тому, что в существующих на рынке BPMS используется одна и та же базовая концепция. В ней к бизнес-процессам относятся два понятия: определение бизнес-процесса и экземпляр бизнес-процесса. Иногда определение бизнес-процесса также называют шаблоном бизнес-процесса. Определение бизнес-процесса содержит схему бизнес-процесса, роли бизнес-процесса, правила назначения исполнителей на роли. Также определение бизнес-процесса содержит описание структур хранения данных.



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



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



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



Фактически основная функция BPMS — раздавать задания исполнителем в соответствии с перемещением точек управления по схеме бизнес-процесса и контролировать выполнение этих заданий.



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



Есть определенное сходство между исполнимым бизнес-процессом и компьютерной программой. В основе и исполнимого бизнес-процесса и компьютерной программы лежат алгоритмы. Для компьютерных программ, так же как для бизнес-процессов для аналитического моделирования, существуют графические нотации (Например, диаграмма классов UML), которые программисты и программные архитекторы используют для объяснения различных программных и архитектурных решений. Однако, сами компьютерные программы пока все-таки массово не разрабатываются в форме графических объектов, они в основном пишутся в виде текстов на языках программирования. В чем ситуация для исполнимых бизнес-процессов отличается от компьютерных программ? В отличие от программы, команды которой выполняет компьютер, часть действий бизнес-процесса выполняют люди. Они делают это существенно дольше компьютера, поэтому экземпляры бизнес-процессов выполняются относительно долго, их состояние меняется медленно. Более того, в отличие от компьютерной программы, во время выполнения бизнес-процессов менеджмент предприятия может заметно влиять на их выполнение, например, увеличивать или уменьшать количество работников, выполняющих те, или иные действия.



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



Процессный подход в случае исполнимых бизнес-процессов



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



Процессным управлением в случае исполнимых бизнес-процессов можно назвать следующую деятельность:


  1. На предприятии бизнес-процессы выделены, построены в исполнимом виде и внедрены в эксплуатацию путем загрузки в BPMS. Процессное управление в этом случае является результатом:


    • Действий бизнес-аналитиков, разработавших исполнимые бизнес-процессы, в частности — схемы бизнес-процессов

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

    • Принятия управленческих решений исполнителями заданий при вводе в экземпляры бизнес-процессов данных (от которых существенно зависит их дальнейшее поведение).


  2. К процессному управлению относится оперативное изменение схем и других элементов определений бизнес-процессов в ответ на изменение условий бизнеса предприятия.

  3. Также к процессному управлению относится косвенное административное влияние на выполнение конкретных экземпляров бизнес-процессов. Например, влияние по «человеческим ресурсам» — менеджмент предприятия может увеличивать или уменьшать количество работников, выполняющих определенные операции, или изменять требования к квалификации работников, выполняющих некоторые действия, а также принимать конкретные кадровые решения, назначая сотрудников на те, или иные роли. Также менеджеры могут анализировать состояния исполняющиеся экземпляров бизнес-процессов, проводить разбор возникающих коллизий и принимать различные административные решения, влияющие на эффективность исполнения экземпляров бизнес-процессов, не изменяя при этом схемы бизнес-процессов.



Основные преимущества процессного подхода в случае исполнимых бизнес-процессов



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


  • Получение от других работников необходимых для выполнения задания данных

  • Передачу результатов своего труда другим работникам

  • Изучение должностных инструкций



Все необходимое для выполнения задания возникает перед работником на экране компьютера.



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

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



Более подробное описание исполнимых бизнес-процессов



Схема бизнес-процесса



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



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



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



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



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



Узел «начало» соответствует точке начала исполнения бизнес-процесса. У него нет входящих ребер (переходов) и есть только одно исходящее ребро. В момент запуска экземпляра бизнес-процесса в узел помещается точка управления, которая тут же выходит из него по исходящему ребру. В бизнес-процессе должен существовать единственный узел «начало». Обозначается «тонкой» окружностью (Рис. 1 а)





Рисунок 1. Обозначения узлов: а – начало; б – завершение потока; в – окончание; г – действие



Узел «завершение потока» должен иметь одно или более входящих ребер и ни одного исходящего. При попадании какой-либо точки управления в этот узел она удаляется. Экземпляр бизнес-процесса, в котором не осталось ни одной точки управления, считается завершившимся. В бизнес-процессе может существовать несколько узлов «завершение потока». Этот узел не обязателен, если в бизнес-процессе существует хотя бы один узел «окончание». Обозначается «жирной» окружностью (Рис. 1 б).



Узел «окончание» соответствует точке окончания исполнения бизнес-процесса. Узел «окончание» должен иметь один или более входящих ребер (переходов) и ни одного исходящего ребра. При попадании управления в узел «окончание» удаляются все точки управления в этом экземпляре процесса, а также во всех его подпроцессах. В бизнес-процессе может существовать несколько узлов «окончание». Этот узел не обязателен, если в бизнес-процессе существует хотя бы один узлел «завершение потока». Обозначается черной окружностью внутри окружности (Рис. 1, в).



Узел «действие» генерирует задание исполнителю, обозначается прямоугольником со скругленными углами, в центре которого пишется имя узла (Рис. 1 г)



Узел «исключающий шлюз» может иметь несколько входящих и несколько исходящих ребер. Для каждой пришедшей в него точки управления выбирается, по какому из исходящих ребер она будет перемещена далее. Обозначается ромбом, в котором изображен «крестик» (Рис. 2 а).





Рисунок 2. Обозначения узлов: а – исключающий шлюз; б – параллельный шлюз



Узел «параллельный шлюз» обозначается ромбом, в котором изображен «плюс» (Рис.2 б). Может иметь несколько входящих и несколько исходящих ребер. Для каждого входящего ребра пришедшая по нему в параллельный шлюз точка управления ставится в очередь. Если для всех входящих ребер их очереди заполнены хотя бы одной точкой управления, то все точки управления, находящиеся на первой позиции очереди каждого входящего ребра, удаляются, а на каждом исходящем ребре генерируется точка управления.





Рисунок 3. Пример (упрощенный) схемы бизнес-процесса “Оплата счета поставщика”



Переменные бизнес-процесса



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



Роли бизнес-процесса



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



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



Системы управления бизнес-процессами и их основные компоненты



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



Для выполнения этих функций в BPMS служат следующие графические интерфейсы:


  • интерфейсы для работы с заданиями исполнителей

  • интерфейсы для работы с загруженными в BPMS определениями бизнес-процессов

  • интерфейсы для работы с выполняющимися в BPMS экземплярами процессов

  • интерфейсы для администрирования пользователей и групп пользователей

  • интерфейсы для настройки замещений исполнителей заданий



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



Типичная BPMS состоит из следующих основных компонентов:


  • Среда исполнения бизнес-процессов

  • Среда разработки бизнес-процессов и связанных с ними объектов

  • Клиент-оповещатель о поступивших заданиях

  • Компонент-коннектор к другим информационным системам



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



Среда исполнения бизнес-процессов – это основной компонент BPMS. Она реализует исполнение экземпляра бизнес-процесса в соответствии с его определением. Этот компонент содержит определения загруженных в него бизнес-процессов и выполняющиеся экземпляры бизнес-процессов. Генерирует списки заданий и визуальные формы, соответствующие заданиям. Как правило, среда исполнения бизнес-процессов позволяет создавать и изменять свойства пользователей, а также дает возможность устанавливать различные права на объекты системы.



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



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



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



При помощи интерфейсов для работы с заданиями исполнителей пользователь может:


  • Получать, фильтровать, выполнять задачи, генерируемые экземплярами бизнес-процессов

  • Запускать новые экземпляры бизнес-процессов

  • Просматривать состояния выполняющихся экземпляров бизнес-процессов

  • Загружать в среду исполнения новые определения бизнес-процессов, или новые версии уже содержащихся в среде исполнения определений бизнес-процессов





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



Рисунок 5 Пример интерфейса, в котором можно запускать новые экземпляры бизнес-процессов и загружать новые определения бизнес-процессов



При помощи интерфейсов для администрирования системы администратор может:


  • Создавать-удалять пользователей и группы пользователей

  • Включать (исключать) пользователей в группы

  • Раздавать права на объекты системы пользователям и группам пользователей

  • Принудительно останавливать экземпляры бизнес-процессов

  • Добавлять, изменять правила замещения пользователей





Рисунок 6. Пример интерфейса, в котором можно просматривать состояния выполняющихся экземпляров бизнес-процессов



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



Рисунок 7. Пример интерфейса, в котором можно разрабатывать бизнес-процессы



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



Описание работы пользователей и компонентов BPMS



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



На клиентских компьютерах пользователей запускается клиент-оповещатель о поступивших заданиях или браузер, в котором открывается web-интерфейс BPMS.



На клиентских компьютерах аналитиков запускается среда разработки бизнес-процессов и связанных с ними объектов. Также на клиентских компьютерах аналитиков запускается симулятор бизнес-процессов.



В среде исполнения выполняются экземпляры бизнес-процессов.



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



Web-интерфейсы и клиенты-оповещатели периодически обращаются к среде исполнения и отображают задачи пользователей.



Пользуясь web-интерфейсом BPMS пользователи:


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

  • Запускают новые экземпляры бизнес-процессов

  • Просматривают состояния выполняющихся экземпляров бизнес-процессов



Пользуясь web-нтерфейсом BPMS администраторы:


  • Загружают или изменяют определения бизнес-процессов

  • Создают или изменяют параметры пользователей и групп пользователей

  • Раздают права на объекты системы

  • Изменяют параметры ботов и бот-станций



При помощи среды разработки аналитики:


  • разрабатывают и модифицируют бизнес-процессы



Для разработки бизнес-процесса аналитику надо:


  • при помощи «мыши» нарисовать схему бизнес-процесса

  • определить участвующие в процессе роли, назначить для ролей исполнителей

  • задать данные бизнес-процесса (переменные процесса)

  • определить графические элементы форм заданий бизнес-процесса

  • связать узлы схемы бизнес-процесса с соответствующими ролями пользователей или ботов (автоматических исполнителей)



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



При помощи симулятора бизнес-процессов аналитики тестируют разработанные бизнес-процессы на условной конфигурации перед загрузкой их в промышленную BPMS.



Клиенты-оповещатели сигнализируют пользователям о появлении новых заданий.



Реинжиниринг и эволюционное управление бизнес-процессами



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



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



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



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



Для образного понимания того, как бизнес-процессы используются в качестве инструмента управления бизнесом в случае эволюционного управления с использованием КПЭ А. Белайчук (председатель Ассоциации профессионалов по управлению бизнес-процессами) предложил следующую аналогию: Управление предприятием можно образно сравнить с управлением автомобилем. В этом случае КПЭ являются аналогом того, что видит водитель — вид через лобовое стекло автомобиля и значения показателей датчиков (скорость, давление масла, количество оборотов двигателя, количество бензина и т.п.), а бизнес-процессы выполняют роль руля, педалей (газ, тормоз, сцепление) и рычага переключения передач автомобиля. То есть, служат для непосредственного управления траекторией в пространстве и времени.



Современный взгляд на процессное управление предполагает разнесение управления по нескольким уровням.



На первом уровне рассматривается общее стратегическое управление предприятием. На этом уровне используются бизнес-процессы для аналитического моделирования. Задача бизнес-процессов данного уровня – формирование общих представлений об основных бизнес-процессах предприятия и обмен этими представлениями между управленцами. Этот уровень не предполагает реальное исполнение разработанных бизнес-процессов.



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



На верхнем уровне процессного управления также используются средства имитационного моделирования. Этот класс программ не предусматривает реального исполнения бизнес-процессов предприятия в компьютерной среде. Системы имитационного моделирования содержат настраиваемую статистическую модель бизнес-процессов организации. Задавая различные параметры этой модели и многократно «проигрывая» бизнес-процессы на условных автоматических пользователях, можно получить значения различных показателей деятельности и таким образом прогнозировать изменение реальных показателей предприятия в будущем в зависимости от тех или иных изменений в бизнес-процессах. Если статистическая модель построена правильно, то имитационное моделирование может быть средством определения оптимальных параметров бизнес-процессов.



На следующем уровне стратегические бизнес-процессы предприятия переводятся в исполнимые бизнес-процессы. На этом уровне схемы бизнес-процессов принято изображать в нотациях BPMN, UML (Диаграмма деятельности) и родственных им. На этом уровне текущая деятельность предприятия представляется в виде множества выполняющихся экземпляров бизнес-процессов.



Следующий (третий) уровень процессного управления соответствует бизнес-объектам предприятия. Состояние всего предприятия на текущий момент времени определяется состоянием всех бизнес-объектов предприятия на этот момент временя. Процессный подход предполагает, что состояния бизнес-объектов изменяются экземплярами бизнес-процессов второго уровня при выполнении соответствующих заданий. Для этого слоя в качестве хранилищ традиционно используются системы управления контентом (ECM-системы), или системы управления базами данных. Также возможно на этом уровне использовать ERP-системы. Для объяснения концепции бизнес-объектов можно воспользоваться аналогией с бухгалтерским учетом: бухгалтерское состояние предприятия на фиксированный момент времени определяется денежными остатками на счетах бухгалтерского учета, а изменение состояния предприятия определяется бухгалтерскими проводками. В рамках данной аналогии проводки будут соответствовать бизнес-процессам, а остатки на счетах — бизнес-объектам.



Математические основы исполнимых бизнес-процессов



Успех языка запросов к реляционным базам данных SQL обычно связывают с тем, что в основе его лежит солидная математическая теория — реляционная алгебра. Разработчики языков описания исполнимых бизнес-процессов также стараются положить в основу языка серьезную математическую теорию.



Большинство существующих языков описания исполнимых бизнес-процессов в той или иной степени относят к одной из двух математических теорий:


  • теория сетей Петри

  • концепция Пи-исчисления



Теория сетей Петри основана на классической теории графов, является расширением теории конечных автоматов. Она возникла в 60-х годах ХХ века и с тех пор постоянно развивается. Теория сетей Петри — сложная, очень хорошо разработанная теория, в ней строго определены такие понятия, как состояния, условия, переходы и т. п. Также теория включает графическую нотацию (систему графических обозначений, на основе которых можно рисовать соответствующие графы). Сети Петри хорошо исследованы математиками — установлены многие их свойства, доказано большое количество теорем.



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



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



Наследниками теории сетей Петри стали первые языки определения бизнес-процессов (например, WPDL и XPDL коалиции WfMC). Они основаны на теории графов и концептуально включают в себя многие понятия и концепции сетей Петри: узлы, переходы, условия и т.д. Однако, в отличие от сетей Петри, эти языки не являются строгими — в ряде случаев можно составить такие предложения языка, которые будут синтаксически допустимыми, однако поведение порожденного бизнес-процесса не будет определено однозначно.



Концепция Пи-исчисления (Pi calculus) была разработана в конце 80-х годов ХХ века Робином Милнером и основана на алгебре параллельных процессов. В отличие от сетей Петри, математическими объектами Пи-исчисления являются не графы, а выражения над элементами специальных множеств и преобразования над этими выражениями. В настоящее время Пи-исчисление является перспективной, но еще молодой и развивающейся теорией, в ней много открытых вопросов и нерешенных проблем. Математически было доказано, что функциональные возможности Пи-исчисления выше, чем сетей Петри.



Разработчики языков BPEL и BPML утверждают, что эти языки обладают более высокой выразительной мощностью, чем языки, основанные на сетях Петри, так как в основе этих языков лежит Пи-исчисление. Однако существуют и скептики, считающие, что связь этих языков с концепцией Пи-исчисления не очевидна, и предполагающих, что эти утверждения ближе к маркетинговому ходу, чем к реальному использованию этой теории при построении данных языков.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308200/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Интегрируйся или умри! Первый маркетплейс околоресторанных сервисов в СНГ

Понедельник, 22 Августа 2016 г. 11:53 (ссылка)

Привет, Хабр! Меня зовут Родион, я соучредитель компании Poster POS. Это облачная система автоматизации на планшете (point-of-sale за рубежом, касса — у нас).



Мы уже рассказывали о том, как все начиналось и как Poster стали одним из самых больших игроков среди облачных POS-систем в СНГ. Cейчас мы хотим попробовать развить всю SaaS-отрасль для такого консервативного рынка как HoReCa, в целом. И без ваших крутых толковых проектов тут не обойтись.



Но обо всем по порядку. Прошу под кат.



Рынок HoReCa очень интересный. Сейчас он активно реформируется. С одной стороны кризис, который уводит с рынка огромные неповоротливые компании, открытые в 90-е на сомнительные деньги, и на их место приводит молодые стартапы. С другой стороны — государство пытается отбелить бизнес, вводит для этого обязательную фискализацию или придумывает такие неоднозначные вещи как ЕГАИС, подталкивая тем самым бизнес все больше и больше к автоматизации.







Тем не менее, HoReCa остается одним из самых консервативных рынков, на котором немногим удается научиться работать и удержаться. За последние пять лет я видел огромное количество стартапов, которые решают задачи предзаказа, лояльности, доставки, аналитики и т.д., но только несколько из них смогли достичь отметки в 100 платных клиентов.



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



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







Для нас Маркетплейс — это возможность значительно расширить свой функционал и помочь нашим клиентам, кафе, ресторанам и магазинам, быстро подключить сторонние сервисы. Для IT-стартапов — это аудитория в 5000+ заведений, которая увеличивается каждый день и на которую они могут выйти в считанные дни, используя наш API.



iPhone никогда не стал бы iPhone, если бы Apple не запустил AppStore. Android бы никогда не догнал Apple, если бы не армия крутых разработчиков, создающих великолепные приложения в Google Play.



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



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









Итог



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



Мы готовы предоставить API, а для перспективных проектов — отдельного специалиста в помощь. Сейчас API еще в процессе разработки, мы постоянно добавляем новые функции. У вас есть возможность участвовать в приоритете их внедрения. В четвертом квартале мы планируем добавить поддержку REST API.



Если у вас уже есть готовый проект — пишите мне на yeroshek@joinposter.com. Если у вас нет проекта — хватит читать комментарии, у вас есть великолепная возможность поучаствовать в создании чего-то крутого :)
Original source: habrahabr.ru.

https://habrahabr.ru/post/305980/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Генератор конфигураций для сетевого оборудования и не только

Среда, 03 Августа 2016 г. 20:43 (ссылка)





Многие хранят шаблоны конфигураций сетевых устройств (прим. да и не только сетевых) в обычных текстовых файлах. И когда приходит время настраивать новое оборудование, достают эти файлики и начинают в них что-то менять. Повседневные типовые операционные задачи не являются исключением и бой с этими задачами обычно ведётся с помощью фалов-шаблонов конфигураций. Безусловно, есть приложения по управлению сетью, но увы их используют далеко не все, потому что многим они не по карману или задачи по конфигурированию оборудования выполняются достаточно редко, в связи с чем обосновать покупку такого ПО очень сложно. Хочу предложить Вам решение по реализации генератора конфигураций на базе HTML/JS, а так же небольшой DIY набор для быстрого старта.



Некоторые админы пишут генераторы конфигураций на Bash/Python, а затем обучают подающего надежды паренька из техподдержки пользоваться этими «самописными приблудами». Далее передают всю рутину и типовые задачи на первую линию поддержки. Проблема здесь только в том, что зачастую, приложение представляет из себя черный экран с мигающим курсором и предложением ввести данные строго по порядку и без ошибок. Соответственно далее эти данные будут использоваться для создания конфигурации или набора команд.



Компания, в которой я работаю, не исключение, и у нас так же хватает рутинных задач, которые хотелось бы упростить и автоматизировать. Было принято решение сделать кроссплатформенный генератор конфигураций Cisco с GUI. Естественно взгляд упал на веб-технологии, но перспектива поднимать веб-сервер (по крайней мере на начальном этапе) не очень радовала. Нашлись умные люди, которые подсказали, что всё это можно реализовать локально на стеке технологий HTML/JS, что я в итоге и сделал. Некоторые части приложения возможно выглядят не очень элегантно (в частности хранение шаблонов), но есть и неоспоримые плюсы, HTML и JS знают почти все, а если трудности и возникнут, то их всегда поможет решить гигантское сообщество. И так, к делу.



Архитектурно, генератор представляет собой веб-страничку написанную на HTML. Шаблоны конфигураций хранятся в файлах JS в виде текстовых переменных. Данные заносятся в веб-форму и на их основе происходит создание конфигурации. Давайте разберем как это происходит на конкретном примере.



Для начала давайте поставим задачу по созданию набора команд для конфигурации VLAN и его IP адреса. Для создания шаблона я взял такой кусок конфигурации.



interface Vlan555

description === LAN ===

ip nat inside

ip virtual-reassembly in

ip address 10.47.3.1 255.255.255.0

ip tcp adjust-mss 1442

exit




Есть простая веб страничка, которая содержит поля ввода информации generator.html:












Генератор конфигураций





/



Конфиг для Cisco |








К страничке подключены два скрипта (в принципе ничего не мешает всё писать в одном файле, но я разделил для наглядности):

// обработка введённых данных



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

function begin() {
confcreate.onclick = function() {
var vlan = document.getElementById('vlan');
var ip = document.getElementById('ip');
var mask = document.getElementById('mask');
var config = document.getElementById('config');
var template = config_template;
template = template.replace(new RegExp('{{VLAN}}','g'),vlan.value);
template = template.replace(new RegExp('{{IP_ADDR}}','g'),ip.value);
template = template.replace(new RegExp('{{MASK}}','g'),mask.value);
config.innerHTML = template;
};

download.onclick = function() {
downloadInnerText('cisco_config.txt', 'config','text/plain');
};

function downloadInnerText(filename, elId, mimeType) {
var el = document.getElementById(elId);
var link = document.createElement('a');
mimeType = mimeType || 'text/plain';
link.setAttribute('download', filename);
link.setAttribute('href', 'data:' + mimeType + ';charset=utf-8,' + encodeURIComponent(el.innerText));
link.click();
}
};
document.addEventListener("DOMContentLoaded", begin);


//шаблон конфигурации устройства



Шаблон можно составить по-разному, но обязательно все части конфигурации должны содержатся в переменных. JavaScript воспринимает конец строки как конец переменной, поэтому приходится экранировать каждую строку обратной чертой. К тому же, в конце каждой строки добавлен HTML тег br для правильного отображения конфигурации на странице и символ окончания текстовой строки \n для корректного экспорта в тестовый файл. Кому-то такой шаблон может показаться не очень эстетичным, но несмотря на кучу «лишних» символов, создавать шаблоны и вносить в него изменения достаточно просто. Большинство текстовых редакторов имеют функцию добавления символов в конец строки. Символами {{}} в шаблоне обрамлены места куда будут подставляться данные. Ниже листинг самого шаблона config_tempalte.js:

var config_template = "\
!===КОНФИГУРАЦИЯ===\n\
conf t\n\
!\n\
interface Vlan{{VLAN}}\n\
description === LAN ===\n\
ip nat inside\n\
ip virtual-reassembly in\n\
ip address {{IP_ADDR}} {{MASK}}\n\
ip tcp adjust-mss 1442\n\
exit\n\
!\n\
wr mem\n\
!\n\
";


Генератор конфигураций готов. Создав три файла и наполнив их указанными мной строчками вы получите такое приложение:





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



Исходники можно взять отсюда: https://github.com/bravoavo/cisco-config-generator



Обратите внимание, что это всего лишь пример, на основе которого каждый может сделать для себя приложение. Я попытался описать общий подход к решению задачи генерации конфигураций на примере оборудования Cisco. JavaScript очень мощный язык программирования и приложив немного усилий вы может доработать данный конфигуратор под свои нужды. В приложении, которое использую я, реализована валидация вводимой информации, генерация паролей, расчет часового пояса, IP адреса и маски сети. Кроме прочего я подключил Bootstrap что бы приложении выглядело более современно и JQuery для большей динамики и анимации. В моем случае это выглядит так:


Original source: habrahabr.ru.

https://habrahabr.ru/post/307054/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
kiev2376393

Домашняя автоматизация с ioBroker

Пятница, 29 Июля 2016 г. 19:19 (ссылка)

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

Читать далее...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Автоматизация лабораторных измерений

Вторник, 26 Июля 2016 г. 14:58 (ссылка)

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







Постановка задачи



Разработать программное обеспечение для управления подготовкой и проведением эксперимента на автоматизированном оптическом эллипсометре.



Программное обеспечение должно предоставлять возможность



  • задания начальных установок и параметров эксперимента;




  • проведения измерений оптических характеристик образцов;




  • набор первичных данных [массивы данных I(

https://habrahabr.ru/post/306434/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Автоматизация работы с серверами при помощи Hewlett Packard Enterprise Server Automation

Вторник, 26 Июля 2016 г. 14:27 (ссылка)

Современные предприятия в своей работе используют все больше серверов. Из-за этого существенно увеличивается количество рутинных задач, необходимых для их выполнения инструментов, стандартов, которые необходимо соблюдать в работе системы. Это, в свою очередь, увеличивает расходы на обслуживание, а также потери из-за разнообразных сбоев. Как решение большинства проблем можна использовать средства автоматизации. Одно из них — Hewlett Packard Enterprise (HPE) Server Automation. Это программное обеспечение для предназначенное для централизации управления и постановки на поток множества функций дата-центров, а также автоматизации критически важных мест в управлении ИТ-инфраструктурой.











Знакомство с сервером



HPE Server Automation сканирует сеть на предмет наличия серверов, которые не находятся под управлением программы и отображает их в специальном списке. Затем администратор подключает эти сервера к системе установив на каждом из них программные модули. После того, как это сделано, вы можете выполнять задачи управления на них, в том числе следующие:



Развертывание операционной системы на выделенных ресурсах: позволяет выделять физическое пространство на сервере или создавать виртуальные сервера под предварительно настроенные ОС и вводить их в управляемый пул серверов. После этого HPE Server Automation может управлять вновь созданными ресурсами.



Автоматический апгрейд ОС: HPE Server Automation умеет проводить автоматизированное, централизованное и гибкое обновление операционных систем и устанавливать необходимые патчи. Это касается серверов на базе ОС семейства Windows, Linux и Solaris. Вы можете выбирать необходимые патчи из тех, что предлагаются поставщиком операционной системы, а также настроить процесс установки, чтобы не учитывать патчи, которые несовместимы с серверной средой.



Инициализация программного обеспечения: после того, как сервер вошел в управляемый пул вы можете устанавливать и настраивать приложения с помощью специальных шаблонов, более известных как политика программного обеспечения (Software Policies). Эти шаблоны определяют, какое ПО устанавливать, какие конфигурации при этому будут применяться, а также скрипты, которые будут использоваться во время установки. Эти шаблоны позволяют определить базовую конфигурацию серверов, которая будет развернута на всех управляемых единицах в соответствии с функциями по соблюдению правил HPE Server Automation Software. Например, вы сможете установить базовую версию Apache как на всех серверах, которые находятся под управлением HPE Server Automation, так и на заданной их части.



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



Конфигурация ПО: вы можете создавать шаблоны конфигурации приложений и разворачивать их на всех серверах под управлением HPE Server Automation. Также вы можете проверять стандартизацию конфигурационных файлов на всех серверах в пуле.



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



Проверка соответствия ПО: при помощи инструмента Policy Compliance Scan можно определить, соответствуют ли спецификация политики программного обеспечения управляемого сервера конфигурации установленного на нем программного обеспечения.



Получение отчетности: HPE Server Automation предоставляет обширный набор комплексных отчетов о состоянии управляемых серверов. Эти отчеты можно гибко настраивать, что позволяет предоставлять их различным категориям пользователей.



HPE Server Automation позволяет вносить изменения в работу различных систем более безопасно и гибко. Это происходит благодаря тому, что вы можете моделировать и проверять вносимые изменения прежде, чем действительно осуществите их. Благодаря этому существенно сокращается время простоя серверов, так как вносимые впервые изменения уже проверены на работоспособность. Вам не нужно отлаживать их и и исправлять ошибки непосредственно после внесения изменений или установки обновлений.



Конфигурация HPE Server Automation



Простой установочный пакет HPE Server Automation состоит из ядра системы, его компонентов, а также базы данных Oracle, размещенных на одном сервере. Более продвинутые пакеты могут иметь дополнительные элементы:



— вторичные ядра, которые дополняют основное ядро и увеличивают мощность для управления серверами;



— сателлиты, схожие по функциональности с обычными ядрами, но имеющие более ограниченные возможности. Они используются для дата-центров и ИТ-инфраструктуры с ограниченными требованиями или ресурсами;



— соединение Multi-master, которое позволяет двум независимым системам обмениваться данными и осуществлять совместное управление серверами.



HPE Server Automation поддерживает установку в восьми обозначенных конфигурациях. Для других конфигураций требуется пакет HPE Professional Services.



Простая конфигурация



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







Самый простой случай установки — развертывание системы для одного дата-центра или объекта. Он состоит из всех компонентов автоматизации HPE Server Automation установленный на одном хосте управления серверами в одной сети.



База данных Oracle



Все варианты развертывания системы требуют наличия базы данных Oracle, настроенной специально для HPE Server Automation. Один из ее компонентов используется для хранения информации о вашей сети, устройствах хранения данных, управляемых серверах (вместе с операционными системами и приложениями, установленными на них) и так далее. Эта база данных является компонентом установочного пакета, однако вы можете использовать и существующую базу данных Oracle, которая была сконфигурирована для использования с HPE Server Automation.



Развертывание приложений



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



— моделировать такие компоненты приложений, как код, скрипты, конфигурационные файлы;



— управлять несколькими параллельными выпусками и версиями ваших приложений;



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



— моделировать целевые сервера, работающие под управлением элементов необходимых для приложений;



— наладить удобное и быстрое общение между разработчиками, тестировщиками, системными администраторами и другим уполномоченным персоналом;



— планировать и реализовывать циклы разработки приложений начиная от написания кода и заканчивая релизом продукта. Вы можете настроить Hewlett Packard Enterprise Server Automation в зависимости от типа вашего предприятия, принятых на нем стандартов и способов работы.



Аудит и исправление



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



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



Используя клиент HPE Server Automation вы можете проверять значения параметров конфигурации серверов на основании работающего сервера с правильными параметрами или же образа подобного сервера. Также вы можете делать проверку опираясь на заданные собственноручно настройки или на основе предварительно настроенных политик аудита. Кроме этого есть возможность получать отчеты о состоянии конкретных серверов для проверки текущего состояния системы и для сравнения с другими серверами.



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



Используя аудит средства исправления и восстановления, вы также можете выполнить следующие задачи:



— сравнивать сервера и снимки системы с заданными серверами и снимками;

— создавать проверки, которые будут исполняться регулярно;

— создавать политики проверки, которые устанавливают стандарты совместимости и безопасности для вашей организации;

— создавать специфические проверки для конкретных серверов или серверных групп.

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



Возможности Hewlett Packard Enterprise Server Automation



Рассматриваемый продукт представляет набор возможностей, которые позволяют автоматизировать многие ИТ-процессы. Среди них такие инструменты как Service Automation Visualizer, Storage Visibility and Automation, а также система отчетов.



Service Automation Visualizer (SAV)



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



Storage Visibility and Automation



Этот инструмент позволяет управлять хранением данных благодаря визуализации от начала до конца всей цепочки поступления данных в хранилище. Это очень полезно для выполнения рутинных задач системных администраторов. Им предоставляются средства, которые помогают экономить место (и как следствие — денежные средства) за счет рассмотрения имеющихся ресурсов, проводить аудит хранилищ, анализировать тенденции использования ресурсов, создавать разнообразные сценарии и автоматизировать процессы.



Reports



Система отчетов HPE Server Automation в режиме реального времени обеспечивает пользователя разнообразной информацией касательно управляемых серверов, сетевых устройств, программного обеспечения, патчей, операционных систем, клиентов и объектов (виртуальных и физических) и применении разнообразных политик. Также можно получить отчеты по безопасности и о действиях пользователей.



Система развертывания ресурсов



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



— Интеграцию с другими функциями и инструментами HPE Server Automation. Так как система развертывания ресурсов тесно интегрирована с набором инструментов автоматизации (включая автоматическое управление патчами, управление программным обеспечением, выполнение скриптов и т. д.), это обеспечивает гладкую передачу работы между различными отделами. Это гарантирует, что различные группы ИТ-отделов будут работать с пониманием протекающих процессов, общего состояния рабочей среды. Это является одним из залогов продуктивной работы и надежный контроль за внедрением изменений.



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



— Гибкую архитектуру предназначенную для работы во многих средах. Система развертывания HPE Server Automation поддерживает множество различных типов серверов, сетей, архитектур безопасности и операционных процессов. Такая гибкость гарантирует, что вы сможете развернуть необходимые операционные системы в соответствии с потребностями вашей организации.



Вы можете выполнять функции HPE Server Automation как из обычного, так и из веб-клиента. Система автоматизирует все типичные задачи развертывания, а именно:



— Подготовка оборудования для установки операционной системы с использованием подготовленного профиля установки ОС и использования заданных последовательностей;



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



— Установка базовой и дефолтной конфигурации операционной системы в соответствии с заданной последовательностью или планом построения.

— Установка всех последних патчей для операционных систем (список зависит от приложений, работающих на сервере);



— Выполнение определенных скриптов до и после установки ОС, которые задают определенные параметры конфигурации, например пароль root;



— Установка системных компонентов и утилит, таких как например Secure Shell, PC Anywhere, антивирусное ПО и программы для резервного копирования данных, средства мониторинга системы;



— Установка распространенного системного ПО, как, например, Java Virtual Machine.



Система развертывания HPE Server Automation поддерживает:



— Windows, Solaris и Linux;

— сетевую установку и установку с физических носителей (CD/DVD);

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



Система также интегрируется с родными технологиями установки применяемых в разных операционных системах:



— Windows answer files: unattend.txt, unattend.xml, sysprep.inf

— Red Hat Kickstart

— SuSE YaST (Yet another Setup Tool)

— Solaris Jumpstart

— WINPE/WIN-BCOM/UNDI



Вы можете развернуть операционную систему на:



— физических серверах, на которых не установлен агент HPE Server Automation и нет операционной системы;

— виртуальных серверах;

— серверах, входящих в пул не управляющихся HPE Server Automation серверов и имеющих установленные ОС;

— серверах, входящих в пул управляющихся HPE Server Automation серверов и имеющих установленные ОС (переразвертывание).



Выполнение скриптов



Использование функции выполнения скриптов HPE Server Automation позволяет запускать одноразовые или сохраненные сценарии по всему пулу управляемых серверов в автоматическом режиме, а не вручную. Для системных администраторов это дает такие преимущества:



— параллельное выполнение скриптов на многих UNIX и/или Windows-серверах, что существенно экономит время и обеспечивает высокую степень согласованности;



— управление доступом осуществляется по принципу, когда только авторизованные администраторы могут выполнять сценарии на хостах, к которым они имеют доступ;



— возможность контролировать доступ к скриптам, храня их в частных или общих библиотеках;



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



— комплексный журнал отчетов, который показывает, когда и где конкретный скрипт был выполнен и кто за это ответственный.



Поскольку средства выполнения скриптов являются неотъемлемой частью HPE Server Automation, системные администраторы получают уникальные преимущества по сравнению со сторонними инструментами:



— Используя информацию о состоянии системы и ее конфигурации для настройки скриптов также можно адаптировать скрипты под конкретные задачи узнав дополнительную информацию благодаря простой ссылке в HPE Server Automation. Это могут быть данные о пользователе или предприятии, которое владеет сервером, является ли сервер простым хранилищем или используется для вычислений, на каком объекте он находится и т. д.



— Пользователи могут совместно использовать скрипты без угрозы для безопасности, так как HPE Server Automation следит за тем, кто и на каких серверах может запускать выполнение скриптов, а также ведет комплексный аудит выполнения скриптов.



Информация об устройствах



Входящий в состав HPE Server Automation инструмент Device Explorer позволяет просматривать информацию о серверах в управляемой среде. С помощью этого обозревателя можно выполнять следующие задачи:



— делать снимки состояния серверов, подготавливать их аудит, проверять конфигурации приложений, создавать пакеты и открывать удаленные сеансы на удаленных серверах;



— просматривать файловую систему серверов, реестр, оборудование, программное обеспечение, список патчей и сервисов;



— узнавать информацию о свойствах сервера и его истории;



В обозревателе групп можно выполнять следующие задачи:



— проводить аудит системной информации, делать снимки состояние серверов и настроек приложений;



— просматривать и получать доступ к группам членов — серверам и другим группам;



— просматривать краткое описание группы и ее историю.



Управление виртуализацией



HPE сотрудничает с поставщиками облачных услуг и средств виртуализации. HPE поддерживает работу с VMware vCenter Server и Microsoft System Center Virtual Machine Manager (SCVMM). Также HPE имеет ограниченную интеграцию с облачным сервисом OpenStack, работающим по схеме Инфраструктура как сервис (IaaS).



Управление виртуализацией HPE Server Automation дает:



— наглядность в вашем дата-центре и удобный просмотр всех ваших физических и виртуальных машин;

— простое создание виртуальных машин;

— соблюдение всех нормативных и корпоративных политик;

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







Обнаружение серверов без агента и проведение его установки



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



С ее помощью вы можете выполнить следующие задачи:



— просканировать сеть на наличие безагентных серверов;

— выбрать сервера для установки агента HPE SA;

— задать инструмент для связи и установить комбинацию логин/пароль;

— выбрать параметры установки и развертывания агентов.



Дополнительные информационные материалы вы можете найти на официальном сайте, а также YouTube-канале.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306426/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как настроить расширяемую систему для регрессионного тестирования на телефонах: опыт мобильной Почты Mail.Ru

Пятница, 22 Июля 2016 г. 15:07 (ссылка)





Привет, Хабр! Сегодня я хочу рассказать, как мы построили с нуля гибкую и расширяемую систему для выполнения автотестов на Android-смартфонах. Сейчас у нас используется около 60 устройств для регрессионного тестирования мобильного приложения Почты Mail.Ru. В среднем они тестируют около 20 сборок приложения ежедневно. Для каждой сборки выполняется около 600 UI-тестов и более 3500 unit-тестов.



Автотесты доступны круглосуточно — они экономят очень много времени тестировщиков и позволяют нам выпускать качественное приложение. Без них мы бы тестировали каждую сборку 36 часов (с учетом ожидания) или примерно 13 часов без ожидания. Вместе со сборкой, актуализацией переводов, при рабочей загрузке агентов с автотестами тестирование в среднем занимает 1.5 часа, что ежедневно позволяет нам экономить недели работы тестировщиков.



Мы рассмотрим, как всё делать с самого начала тем, кто занимается написанием автотестов, а не инфраструктурой: начиная от покупки телефона, его перепрошивки и заканчивая созданием docker-контейнеров, внутри которых будет доступен телефон для автотестов.



Какие телефоны выбрать для автотестов на Андроиде?





Когда Android только-только становился популярным, у разработчиков тестов был выбор из двух зол: покупать дорогой зоопарк телефонов либо работать с медленными и глючными виртуалками. Сегодня всё несколько проще, на рынке появились дешёвые аппараты «эконом»-класса, а виртуальный Андроид обзавёлся образом для x86 и HAXM. Однако выбор всё ещё остался, многие предпочитают для автотестов виртуальные машины, но телефоны уже стали вполне доступной опцией даже для скромного бюджета на автотестирование. Так как же выбрать телефон для регрессионных автотестов и какое оборудование ещё нужно, чтобы всё вместе оно могло работать 24/7?



Рынок телефонов очень большой — глаза разбегаются. Какие же критерии выставить при выборе телефона? У меня после череды проб и ошибок вышел такой список (цену на аппарат опускаю, с ней, надеюсь, всё понятно):




  1. Есть возможность получить права root.

  2. Есть возможность анлока boot-раздела телефона.

  3. На телефоне стоит версия Андроида, максимально близкая к стоковой, или подобные можно установить (чтобы не пришлось лопатить кучу вариантов теста под разные интерфейсы).

  4. Оперативная память на телефоне желательно должна быть размером от 1 Гб (можно работать и на меньшей, но, даже если тесты написаны стабильно, различные проверки отображения «тяжёлых» объектов на телефоне с низкой оперативной памятью окажутся долгими).

  5. Совсем здорово, если у телефона будет долгий саппорт от производителя/пользователей, тогда у нас остаётся шанс продлить ему жизнь новыми версиями ОС.



Основная часть критериев достаточно прозрачна. Если окажется, что на телефоне что-то работает не так, то мы должны хотя бы иметь шанс заставить это работать сами. :) К сожалению, большая часть критериев — это не те вещи, о которых можно спросить продавца при покупке, поэтому в первую очередь наш путь лежит на forum.xda-developers.com и 4pda.ru/forum, где о рыночной модели можно узнать все подробности. Плюс ко всем перечисленным критериям, если модель уже долго продаётся, обращайте на форумах внимание на отзывы о браке и времени ресурса памяти и батареек, без них ваше устройство превратится в тыкву. Проблемы экрана, кнопок, корпуса, динамиков и прочего, что обычно интересует пользователя, вас, как правило, пугать не должны: телефон прекрасно будет работать с браком этих элементов, хотя всё зависит от специфики проекта.



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



1. Модель телефона имеет кучу региональных подвидов, при этом только на части из них можно получить рут или разлочить бутлоадер. Мало того что наткнуться на российский сертифицированный телефон в неофициальном магазине сложно — серые и белые телефоны выглядят одинаково, — так ещё и многие продавцы или их поставщики перепрописывают названия моделей, характеристики железа, регионы и даже версии операционных систем. Вполне возможен случай, когда внутри «Настроек» в Андроиде вы видите одну модель, внутри бутлоадера другую, а в шелле, когда набираете getprop и получаете айдишники, — третью. Просто телефон прошёл пару рук и пару регионов до вас. Сначала его хозяином был пользователь Веризона из Южной Дакоты, потом тот сдал его, в refurbished-состоянии аппарат как-то попал торговцу в Тель-Авиве, который его криво перепрошил на их версию операционной системы, а через ещё какое-то время телефон перекупил продавец в Москве, который уже стал продавать его как новый. Вам привозит его курьер, вы берёте в руки своё новое восьмиядерное перепрошиваемое российское устройство, не подозревая, что это шестиядерный залоченный региональный эксклюзив для контрактных пользователей оператора сотовой связи из США.





Элементы коробки и телефона с «современной» начинкой и высокой ценой, который по внутренним характеристикам оказался перепрошитой младшей моделью от AT&T



2. Один и тот же серийный номер. Здесь определить проблему попроще, но, к сожалению, даже официальные продавцы этим страдают, отсутствие серийного номера — это напасть многих бюджетных девайсов. Если при работе ваших автотестов используется adb, а к машине подключено несколько устройств, нужно либо переписывать код adb (так он увидит только один девайс), либо, если покупка совершалась по критериям выше, вписывать уникальный серийник самому.





Типичные значения серийников у бюджетных телефонов



3. Псевдослучайный MAC-адрес у Wi-Fi-модуля после перезагрузки телефона. Это была довольно серьёзная проблема, потому что мы узнали о ней, когда я убедился, что «всё хорошо», телефон нам подходит, и мы заказали 20 штук точно таких же. :) В процессе работы автотестов телефоны иногда перезагружаются, через какое-то время тесты начали падать из-за отсутствия доступа к сети по Wi-Fi, хотя всё при этом выглядело нормально: соединение с сетью было и после включения/выключения Wi-Fi-модуля всё работало корректно. Просто после ребутов в какой-то момент у пары телефонов оказывался одинаковый MAC, Wi-Fi-точка доступа же пускала только последний присоединившийся. На тех телефонах, где в итоге генерился MAC-адрес, я, к сожалению, не нашёл, пришлось в загрузочном разделе поместить скрипт, который устанавливал его насильно на уникальный.





Телефон демонстрирует чудеса spoofing’а из коробки



Тем не менее, если соблюдать при выборе телефона перечисленные выше критерии, эти проблемы не должны быть фатальными — всё это можно исправить руками и заставить телефон работать как нужно.



Кроме телефонов, для запуска автотестов понадобится сам компьютер и USB-хабы, тут тоже есть несколько нюансов. Постоянно работающим телефонам нужно хорошее питание (минимум 0,5 А на устройство, лучше больше), многие хабы на рынке идут со слабыми адаптерами и никак не рассчитаны на то, что в каждый порт будет подключён постоянно работающий телефон. С планшетами ещё сложнее, девятидюймовые планшеты при постоянной работе разряжаются, экран слишком большой, приходится выбирать из семидюймовых. Из практики у нас вышло, что на адаптер в 4 А можно подключить 6–7 телефонов (в зависимости от их загрузки работой), т. е. большая часть многопортовых хабов с характеристиками типа «адаптер на 3 А, 20 USB-портов», мягко говоря, бесполезны. Самые крутые — серверные решения, но цена у них зашкаливает, так что ограничимся пользовательским рынком. Чтобы телефоны не разряжались, стоит брать хабы на четыре порта с питанием в 3 А, либо хабы на шесть портов с питанием на 4 А. Если есть хабы с хорошим питанием, но с большим количеством портов, — часть портов можно просто не использовать.



Готовим телефон к работе



Давайте для примера возьмём одну модель телефона, решим одну из проблем его операционной системы, а дальше попробуем собрать эти устройства в примитивный тестовый стенд для автотестов. Телефон сам по себе дешёвый и хороший, но с некоторыми недостатками (описанными выше). В частности, у этих телефонов одинаковый iSerial, adb видит только одно устройство. :( Совсем везде на телефоне его менять не будем, но сделаем так, чтобы adb отдельные телефоны отличал.



Для этого нам нужно будет перепрошить у телефона boot-раздел и установить на устройстве кастомный раздел восстановления — так вы сможете уберечься от неудачных экспериментов. У наших телефонов стоит МТ6580, т. е. процессор фирмы Mediatek, значит, для перепрошивки можно использовать SP Flash Tool. Ещё нужны готовый образ recovery.img и scatter-файл устройства. Почти для всех устройств их можно найти в интернете, на тех же самых ресурсах XDA и 4PDA, но при желании recovery можно перекомпилировать для своего устройства, взяв за основу TWRP, а scatter-файл создать самому. В любом случае берём наши готовые файлы и перепрошиваем:







После установки раздела восстановления сохраните через него бэкап boot-раздела и переместите его к себе на машину, обычно в этом разделе располагаются конфигурационные файлы ОС. Чтобы захардкодить свой iSerial, нужно распаковать образ загрузочного раздела телефона, это можно сделать с помощью Android Image Kitchen. Запускаем unpackimg.sh и получаем распакованный образ в папке ramdisk:







Здесь много init-файлов, в которых указываются различные переменные, в том числе и серийный номер.







Находим файл, где устанавливается серийный номер ${ro.serialno}, и заменяем его на свой номер, например 999222333019:



find ramdisk/ -maxdepth 1 -name "init.mt*" -exec sed -i 's/${ro.serialno}/999222333019/g' {} +


Запаковываем образ обратно с помощью repackimg.sh, перекидываем его на телефон и устанавливаем с помощью кастомного рекавери. Теперь adb будет отличать устройства, нам остаётся включить режим разработчика на телефоне и разрешить debug в меню разработчика. Любые подобные проблемы можно решать точно таким же путём, практически всё в телефоне можно перепрошить или поправить, если этого потребуют задачи тестирования.



Настройка тестовой машины



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



При заказе/сборке машины, к которой будут подключены телефоны, есть специфика. Кроме стандартных HDD/RAM/CPU, нужно обратить внимание на количество USB-контроллеров на материнской плате и поддерживаемый протокол USB. Телефоны, работающие на USB 3.0 (xHCI), могут существенно ограничить максимальное количество устройств на машине (обычно 8 на контроллер, в итоге 16 устройств на машину с двумя контроллерами), поэтому стоит проверить, есть ли возможность его отключить и использовать только EHCI. Такие опции есть в биосе или ОС, лучше всего насильно отключить xHCI в биосе, если вам не нужны высокоскоростные устройства.



Создаём контейнер для телефона



Если нужно, чтобы слейв / агент системы интеграции работал с отдельным телефоном, то их следует как-то разделить. У нас агенты запускаются в отдельных docker-контейнерах, каждому из которых доступно по одному устройству, — так мы можем распределять задачи в CI на отдельные устройства, а точнее на их возможности (например, контейнер с планшетом может выполнять тесты, для которых требуется широкая диагональ экрана, а контейнер с телефоном — тесты, для которых нужна возможность принимать SMS-сообщения). Пример установки и настройки системы на Ubuntu описан далее. Устанавливаем сам Docker:



sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
echo 'deb https://apt.dockerproject.org/repo <версия ubuntu> main' >> /etc/apt/sources.list.d/docker.list
sudo apt-get update
sudo apt-get install docker-engine


В качестве сторадж-драйвера будем использовать overlayFS (работает быстрее дефолтного):



echo 'DOCKER_OPTS="-s overlay"' >> /etc/default/docker


Создаем dockerfile, из которого будем делать образы. Добавим в него Android SDK:



FROM ubuntu:trusty
ARG DEBIAN_FRONTEND=noninteractive

RUN apt-get update -y && \
apt-get install -y software-properties-common && \
add-apt-repository ppa:webupd8team/java -y && \
apt-get update -y && \
echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | /usr/bin/debconf-set-selections && \
apt-get install -y oracle-java8-installer && \
apt-get remove software-properties-common -y && \
apt-get autoremove -y && \
apt-get clean
ENV JAVA_HOME /usr/lib/jvm/java-8-oracle
ENV ANT_VERSION 1.9.4

RUN cd && \
wget -q http://archive.apache.org/dist/ant/binaries/apache-ant-${ANT_VERSION}-bin.tar.gz && \ tar -xzf apache-ant-${ANT_VERSION}-bin.tar.gz && \ mv apache-ant-${ANT_VERSION} /opt/ant && \ rm apache-ant-${ANT_VERSION}-bin.tar.gz

ENV ANT_HOME /opt/ant
ENV PATH ${PATH}:/opt/ant/bin

ENV ANDROID_SDK_VERSION r24.4.1
ENV ANDROID_BUILD_TOOLS_VERSION 23.0.3

RUN dpkg --add-architecture i386 && \
apt-get update -y && \
apt-get install -y libc6:i386 libncurses5:i386 libstdc++6:i386 lib32z1 && \
rm -rf /var/lib/apt/lists/* && \
apt-get autoremove -y && \
apt-get clean

ENV ANDROID_SDK_FILENAME android-sdk_${ANDROID_SDK_VERSION}-linux.tgz
ENV ANDROID_SDK_URL http://dl.google.com/android/${ANDROID_SDK_FILENAME}
ENV ANDROID_API_LEVELS android-15,android-16,android-17,android-18,android-19,android-20,android-21,android-22,android-23
ENV ANDROID_HOME /opt/android-sdk-linux
ENV PATH ${PATH}:${ANDROID_HOME}/tools:${ANDROID_HOME}/platform-tools
RUN cd /opt && \
wget -q ${ANDROID_SDK_URL} && \
tar -xzf ${ANDROID_SDK_FILENAME} && \
rm ${ANDROID_SDK_FILENAME} && \
echo y | android update sdk --no-ui -a --filter tools,platform-tools,${ANDROID_API_LEVELS},build-tools-${ANDROID_BUILD_TOOLS_VERSION}

###Добавим файл системы интеграции, это может быть слейв дженкинса, агент Bamboo и т. п., в зависимости от того, с чем вы работаете
ADD moyagent.sh /agentCI/


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



docker build .


Теперь у нас есть образ с Android SDK, осталось сделать так, чтобы он видел только одно устройство. Для этого будем цеплять его через симлинк c помощью udev:



echo ‘"SUBSYSTEM=="usb", ATTRS{serial}=="$DEVICE_SERIAL", SYMLINK+="androidDevice1"’ >> /etc/udev/rules.d/90-usb-symlink-phones.rules


Вместо $DEVICE_SERIAL вписываем наш свежепрошитый серийник. Перезапускаем определение правил устройств:



udevadm control --reload
udevadm trigger


Теперь в пути /dev/androidDevice1 у нас будет симлинк на устройство, осталось передать его в контейнер при запуске:



docker run -i -t --rm --device=/dev/androidDevice1:/dev/bus/usb/001/1 android-docker-image:latest adb devices


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



docker run -i -t --rm --device= /dev/androidDevice1:/dev/bus/usb/001/1 android-docker-image:latest /bin/sh /agentCI/moyagent.sh


Кстати, ключ --device стал работать с симлинками относительно недавно (master-ветка на Гитхабе), до этого приходилось генерить из симлинка realpath c помощью скрипта и уже его передавать Докеру, так что если у вас не выходит подключение устройства, то добавьте в udev в параметр RUN+= такой скрипт:



realpath /dev/androidDevice1 | xargs -I linkpath link linkpath /dev/bus/usb/010/1


После этого в старых версиях Docker добавить телефон можно так:



docker run --privileged -v /dev/bus/usb/010/:/dev/bus/usb/100/ -i -t  android-docker-image:latest adb devices


Всё, можно подключать свой слейв к системе интеграции и работать с ним.



Заключение



Физические мобильные устройства в системе интеграции рано или поздно появляются у любого более-менее крупного проекта на Андроиде — неизбежно возникают необходимость покрытия ошибок, нестандартные тестовые случаи или просто фичи, которые требуют реального устройства. Кроме всего этого, устройства не используют ресурсы ваших серверов, так как процессоры и память у них свои, а хост для телефонов не должен быть супермощным, «домашний» десктоп со всем этим вполне справится. Соизмеряйте плюсы и минусы, считайте, что выгоднее, — наверняка в вашей системе автоматизированного тестирования есть место реальным устройствам. Желаю вам поменьше багов и побольше тестового покрытия. :)
Original source: habrahabr.ru.

https://habrahabr.ru/post/306236/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] ZigBee и Intel Edison: практика автоматизации переговорных комнат

Пятница, 01 Июля 2016 г. 14:35 (ссылка)

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





Мы создали интеллектуальную систему бронирования переговорных комнат (Smart Conference Room System, SCR) для того, чтобы помочь всем желающим с этими проблемами справиться.



Общий обзор



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



Система построена на основе следующих аппаратных компонентов:




  • Плата Intel Edison.

  • Плата расширения Arduino.

  • Модуль XBee ZB S2 ZigBee.

  • Android-смартфон.

  • Push-сервер.

  • Датчик освещённости ZigBee.

  • Инфракрасный датчик присутствия ZigBee.

  • Интеллектуальная розетка ZigBee.

  • Сигнализация ZigBee.



ZigBee – это спецификация набора высокоуровневых коммуникационных протоколов, которые используются для создания персональных сетей, в основе которых – небольшие маломощные цифровые передатчики. Протоколы ZigBee базируются на стандарте IEEE 802.15.4 и предназначены для использования во встраиваемых устройствах, которые требуют низкого энергопотребления и способны нормально работать при невысоких скоростях передачи данных. Сеть, построенная на основе ZigBee, будет весьма экономичной в плане потребления энергии. Для того, чтобы пройти сертификацию ZigBee, устройство должно работать от батарей не менее двух лет. Типичные применения таких устройств – это домашняя автоматизация. Например, интеллектуальные датчики присутствия, системы освещения, терморегуляторы.



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



Важный аспект платформы Arduino – это стандартизированные коннекторы, которые позволяют подключать к основному блоку с микроконтроллером множество взаимозаменяемых модулей расширения, известных как шилды (shields). Плата Intel Edison также поддерживает Arduino. Это делает Edison совместимым с тысячами модулей для Arduino, например, с XBee ZigBee.



XBee – это название марки семейства радиомодулей от Digi International, выпускаемых в стандартных форм-факторах. XBee ZB поддерживает протокол ZigBee PRO для создания сетей с ячеистой топологией.



С программной точки зрения система состоит из следующих частей:




  • Серверное ПО.

  • Приложение для Android-смартфона.

  • Прошивка для Intel Edison.



Вот как, в самых общих чертах, выглядит работа Smart Conference Room System.





Схема работы SCR



Аппаратное обеспечение



Остановимся подробнее на аппаратном обеспечении, на котором основан наш проект.



Intel Edison с коммутационной платой Arduino – это ядро системы. Так как Edison совместим с Arduino, устройства, которые могут работать с Arduino, подходят и для Edison. Например, это радиомодуль XBee ZB S2, который подключается к Edison с помощью платы расширения Arduino.





Intel Edison и радиомодуль XBee



В качестве Push-сервера мы использовали Windows-планшет Fujitsu STYLISTIC Q702 с процессором Intel Core i5-3427U (частота 1.80 ГГц), оснащённый 4 Гб оперативной памяти.





Планшет Fujitsu STYLISTIC Q702



Для того, чтобы с нашей системой было удобнее работать, мы создали для неё мобильное Android-приложение. Его испытания проводились на смартфоне Lenovo K900. Он оснащён процессором Intel Atom Z2580 (частота 2 ГГц) и 2 Гб оперативной памяти.





Смартфон Lenovo K900



Роль координатора ZigBee играет радиомодуль XBee ZB S2, выполненный в форм-факторе платы расширения для Arduino и соответствующий требованиям протокола ZigBee. Он управляет подключёнными к нему ZigBee-датчиками.





Радиомодуль XBee ZB S2



В проекте задействован датчик освещённости Netvox Z311X. Он соответствует требованиям стандарта ZigBee и отвечает за измерение уровня освещённости в помещении.





Датчик освещённости



В качестве датчика присутствия используется инфракрасный сенсор Netvox ZB11D. Он так же поддерживает работу по протоколу ZigBee и играет роль конечного сетевого устройства.





Датчик присутствия



В системе используется модуль сигнализации Netvox Z602A. Это устройство совмещает в себе средства звукового и светового оповещения и применяется в экстренных ситуациях. Модуль основан на стандарте ZigBee HA.





Сигнализация



Интеллектуальная ZigBee-розетка, применяемая в проекте, это Netvox Z809AG. Устройство совмещает функции учёта электроэнергии и управления электрическими цепями. С его помощью можно включать и выключать питание различных электроприборов в комнате.





Интеллектуальная розетка



Аппаратная инфраструктура



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





Схема устройства системы



Аппаратную архитектуру системы можно разбить на следующие четыре части:




  • Смартфон.

  • Push-сервер.

  • Шлюз на базе Intel Edison.

  • Набор ZigBee-датчиков.



Эти аппаратные блоки ориентированы на три основные функции SCR.




  1. Наблюдение за комнатой и оценка ситуации. ZigBee-датчики освещённости и присутствия, в режиме реального времени, поставляют сведения о ситуации в комнате шлюзу на базе Intel Edison. Для связи датчиков и шлюза используется сеть ZigBee. Edison анализирует показания, определяет, есть ли кто-нибудь в комнате, а затем отправляет свои выводы push-серверу по Wi-Fi.




  2. Бронирование комнаты и интеллектуальное расписание. Сотрудники могут резервировать переговорные, которые, по оценке системы, свободны. Делается это с помощью Android-смартфона. Если доступных переговорных нет, сотрудник может выбрать занятую комнату и включить режим ожидания освобождения переговорной. Как только система, в частности – Intel Edison, сочтёт, что выбранная комната свободна, сообщение об этом поступит на сервер, который отправит уведомление приложению на смартфоне.




  3. Удалённый доступ и управление. Приложения могут запрашивать сведения о состоянии зарезервированной комнаты по Wi-Fi через push-сервер для того, чтобы управлять устройствами в комнате, например, включать и выключать свет, и получать, в режиме реального времени, сведения с ZigBee-датчиков.



Программное обеспечение



Как мы уже говорили, многие ресурсы организаций, такие, как переговорные комнаты, используются не самым эффективным образом. Особенно это относится к большим компаниям. Например, сотрудник А, с помощью корпоративного веб-сайта, зарезервировал комнату для совещаний с 8.00 до 10.00. Встреча окончилась в 9.00, то есть, с этого момента помещение свободно, им вполне может воспользоваться кто-то ещё. Предположим, что в это же время сотрудник В, пользуясь тем же сайтом, ищет свободную комнату. Но ту, которую резервировал сотрудник А, он выбрать не может, ведь в базе данных она значится как занятая, хотя по факту свободна. Поэтому сотруднику В придётся искать другой вариант, а освобождённая комната будет пустовать.



На рисунке ниже показана структурная схема используемого программного решения.





Архитектура программного решения



Push-сервер



В качестве push-сервера мы использовали GlassFish 4.0. Вот, как выглядит архитектура сервера.





Архитектура сервера



Системная диаграмма сервера показана ниже. Когда Edison, пользуясь сведениями с ZigBee-датчиков, определит, что состояние помещения изменилось со «свободно» на «занято», или наоборот, он оповестит об этом сервер. Сервер, в свою очередь, изменит соответствующую запись в базе данных, а затем, если комната пуста, отправит сообщение Android-приложению.





Рабочий процесс Push-сервера



Intel Edison и ZigBee



В Arduino интерфейс между Intel Edison и координатором XBee эмулируется в виде последовательного порта. Приложение, запущенное на Intel Edison, работает как ZigBee-шлюз. С его помощью мы можем отправлять команды ZigBee-датчикам и принимать ответы от них.

Координатор ZigBee, кроме того, отвечает за передачу сведений с датчиков push-серверу.





Устройство стека ZigBee в Arduino



Мы спроектировали и реализовали в среде Arduino простой стек ZigBee, который используется для взаимодействия с датчиками. Плата работает в режиме координатора, который наблюдает за состоянием датчиков, и, если такая возможность предусмотрена, позволяет управлять ими.



Классы стека ZigBee














































Класс

Функция

XBeeAddress

Базовый класс адреса устройства ZigBee

XBeeAddress64

64-битный IEEE-адрес устройства ZigBee

XBeeAddress16

16-битный сетевой адрес устройства ZigBee

Payload

Полезная нагрузка командного кадра ZigBee

ExplicitAddressCommand

Командный кадр ZigBee, используемый в спецификации домашней автоматики

ExplicitAddressCommandResponse

Ответ на команду на явно заданный адрес

XBeeSensor

Базовый класс ZigBee-датчика

XBeeLightSensor

Датчик освещённости ZigBee

XBeeInfraSensor

Датчик присутствия ZigBee

XBeeAlarm

Сигнализация ZigBee



Основные функции ArduinoXBee



Главный класс ArduinoXBee – это XBeeCoordinator. Этот класс отвечает за управление ZigBee-датчиками. Его основные задачи заключаются в сборе сведений с датчиков и в отправке им команд для удалённого управления их поведением. Вот описание функций, применяемых для работы с датчиками.



Int getLightValue(XBeeLightSensor lightSensor). Эта функция используется для получения сведений с датчика освещённости. На её вход подаётся объект датчика освещённости, на выходе получаем целое число в диапазоне от 0 до 65535.



bool getInfraValue(XBeeInfraSensor infraSensor). Функция получает показания заданного датчика присутствия. При вызове ей передаётся объект датчика присутствия, а возвращает она логическое значение. True указывает на то, что в комнате кто-то есть, False – на то, что комната пуста.



void turnOnAlarm(XBeeAlarm alarm) и void turnOffAlarm(XBeeAlarm alarm). Эти функции, соответственно, включают и выключают сигнализацию. При их вызове используется объект, символизирующий нужное устройство, они ничего не возвращают.



void turnOnSwitch(XBeeSmartPlug plug) и void turnOffSwitch(XBeeSmartPlug plug). Эти функции позволяют включать и отключать подачу электричества интеллектуальными розетками. При вызове функций им передают объект, соответствующий розетке, они не возвращают ничего.



Приложение для Android



Когда пользователь запускает приложение, у него есть возможность создать новое расписание или управлять существующим, а именно – удалить его. Создавая новое расписание, пользователь может выполнять поиск переговорных по времени и расположению. Если комната свободна, её можно тут же зарезервировать. Если комната занята, пользователь может выбрать вариант ожидания освобождения комнаты. Как только датчики ZigBee зафиксируют освобождение комнаты в пределах заданного временного диапазона, push-сервер отправит уведомление приложению, и пользователь, который это уведомление получит, может зарезервировать комнату.





Системная диаграмма работы с Android-приложением



Пользовательский интерфейс Android-приложения



Приложение для Android мы назвали «Smart Conference Room System». Пользуясь им, сотрудник организации может забронировать переговорную и управлять зарезервированными комнатами. Вот, как выглядит главный экран приложения.





Главный экран приложения



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



Используя команду My Scheduling, пользователи могут бронировать переговорные (синий цвет используется для указания на то, что комната свободна, серый – на то, что уже забронирована). Если комната не свободна, пользователь может включить режим ожидания её освобождения.





Бронирование комнаты



Пользователи могут проверять состояние комнат, которые они забронировали, или тех, освобождения которых ожидают. Синим цветом выводятся успешно забронированные комнаты, серым – те, освобождения которых ожидает сотрудник. Здесь же можно управлять своим расписанием.





Управление расписанием



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





Уведомление об освобождении комнаты



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



Выводы



Мы разработали интеллектуальную систему управления комнатами для переговоров, в основе которой – простой ZigBee-стек для Arduino. Система может определять, в режиме реального времени, свободна комната или занята. Это позволяет упростить бронирование помещений, сделать его удобнее, повысить эффективность использования переговорных комнат.



Многое уже сделано, но мы, однако, всё ещё сталкиваемся с некоторыми сложностями. Это касается разных аспектов работы системы. Так, если говорить о её внутреннем устройстве, о стеке, на котором она основана, это ограничения функций API стека и всего комплекса. Кроме того, нужно улучшить стабильность работы системы и другие аспекты её функционирования. Мы планируем создание следующей версии Smart Conference Room System, которая будет более функциональной, стабильной и удобной, а значит позволит лучше решать её основную задачу: оптимизацию использования переговорных комнат в организациях.
Original source: habrahabr.ru.

https://habrahabr.ru/post/304546/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Teaser_Advertising

«Умный дом» от Disystems – исключительный комфорт!

Четверг, 30 Июня 2016 г. 16:07 (ссылка)


5684778_Home_500x327 (500x327, 40Kb)



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



СпециалистыDisystems используют в работе технологии «Умный дом» от американского бренда AMX. Широчайший ассортимент продуктов АМХ и их модульность позволяют нам предлагать максимально гибкие решения, прекрасно адаптируемые к любым требованиям заказчика. Благодаря этому стоимость системы автоматизации «Умный дом» может быть доступной для любого клиента - все зависит от индивидуальных пожеланий!



Автоматизация дома и превращение его в интеллектуальное здание – достижимая мечта, которую можно исполнить!



Хотите шагнуть в будущее уже сейчас? Звоните: (044) 362-00-55 // (067) 770-93-33 // (067) 658-33-95!



А также приезжайте в наш шоу-рум, который находится по адресу: пр-т В. Лобановского (Краснозвездный), 150д.



Disystems



http://www.disystems.com.ua/



info@disystems.com.ua

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

О том как я помечал пороги Хабра, Майла, ОнлиОфиса и прихожую В Кругу Друзей

Понедельник, 20 Июня 2016 г. 14:12 (ссылка)





Здравствуйте, товарищи! В опубликованных вчера предыдущих двух материалах: на Гиктаймсе и на Хабре — я рассказал о том, что такое технокоммунизм и своё видение того, как нужно к нему двигаться не политическими битвами, а развитием технологий, общественными проектами и т.д., за счёт создания всемирной автоматизированной системы «Технокоммунизм», которую нужно начинать внедрять с того места где сейчас находятся люди, а именно с полезных интернет-сервисов. Как и ожидалось, кроме нашедшихся сторонников, некоторые товарищи выразили своё непонимание того, о чём я говорю. Поэтому, теперь моя задача планомерно, серией статей, раскрывать различные вопросы более подробно, но самое главное — осуществлять реальное движение по реализации всего озвученного.



В этом материале, я начну рассказывать своё видение того, как нужно продвигать свою идею, о том, что не нужно бесконечно долго ждать, что нужно находить способы действовать как можно раньше. Расскажу о том, как я общался с представителями крупнейших интернет-компаний, на самом начальном этапе рассказывал им о проекте ВАС Технокоммунизм и почему я называю это «помечать пороги».



Начну с «помечания». На заглавной картинке изображён лев, который как раз этим занимается с сосредоточенно-довольной мордой, поскольку моя фамилия Левадный, я решил провести вот такую хулиганскую ассоциацию. История того, как я стал использовать такой термин, вот такая. До того как я бросил почти всё и начал заниматься в основном общественной деятельностью, и до того как я продался крупным компаниям, в Омске у меня была небольшая ИТ-компания. Небольшая, но во многом крутая. Офис в центре города с душевыми, кухней и местами отдыха, крупные (по местным меркам) клиенты и всё-такое. Это был мой третий бизнес, первые два были неудачными. Почему был этот удачный? Потому, что я научился не сидеть и не ждать пока кто-то ко мне придёт и скажет что-то вроде: «Мы принесли вам деньги, возьмите их и ничего не делайте». Я перестал быть социопатом (не сразу и не полностью конечно) и начал бывать в разных местах, рассказывать о себе и о друзьях, о своей компании, знакомиться с людьми. В общем налаживать те самые деловые контакты ну и просто новые социальные связи.



Термин, этот, в голове у меня появился когда мы шли с другом-коллегой по улице со стоянки к офису, шли немного с другой стороны здания, не где обычно, я вижу вывеска с названием компании и говорю, давай по пути сейчас зайдём со словами: «УРААА, свершилось!!!». А когда они офигевшие на нас буду смотреть, мы скажем: «А знаете ли вы, что наша прекрасная компания занимающаяся техподдержкой и вообще комплексной автоматизацией, теперь находится с вами прямо в одном здании?». Друг говорит, что может не будет пугать людей, я ему говорю, что да давай зайдём, вроде как территорию пометим, скажем, что мы теперь тут. Даже если сразу с нами договор не заключат, то потом вспомнят. Вот так и возник у меня этот термин. В общем зашли, дверь не туда как-то пытались открыть, когда зашли на нас уже все пялились, поэтому кричать уже не надо было. Я рассказал, что мы ИТ-компания и мы тут в здании. Они сказали, что-то типа, что на ловца и зверь бежит, у них был мальчик, которых их админил, теперь ушел работать в какую-то компанию, им как раз мы и нужны. Вот так оно происходит.







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



Ну вот, а теперь когда наша задача осуществить всемирную автоматизацию, как было сказано раньше, начиная с полезных сервисов и с подведения интерфейса взаимодействия туда где находятся люди прямо сейчас, в том числе в социальные сети, компьютерные игры и т.д., нужно чтобы об этом сначала просто узнали. Идти конечно, нужно с чем-то цельным, из всего, что у нас было на тот момент, была цельная концепция «Каждое действие — на общее благо», вот её я и упаковал в «Рационализаторское предложение» о том как можно улучшить существующие социальные сети, чтобы быть более полезными людям. Записал такое видео-обращение, хоть я и много писал всяких видео и давно, но видео-обращения как-то не записывал, пришлось учится, вроде даже нормально получилось. Применил там имеющийся ресурс в виде друзей в разных странах, в конце ролика они свою заинтересованность проектом проявляют.









Хорошо было бы, если бы ты такой понял, что у тебя есть гениальная идея, пришёл сразу в самую крупную компанию по близости, заходишь внутрь и говоришь охране, что у тебя гениальная идея. Охранник поднимает руку, но не для того, чтобы дать тебе по физиономии, а даёт тебе карточку-ключ от всех дверей и говорит, что вам нужно к самому главном директору, он на 16-ом этаже, вы пока поднимайтесь к нему, а я предупрежу его телохранителей, что у вас гениальная идея, чтобы они вас пропустили. Вы такой поднимаетесь на 16-й этаж, видите там большую дверь рядом с которой стоят телохранители, вы подходите к ней и хотите открыть её с ноги, но не успеваете, потому что телохранители её вам услужливо открывают. Вы такой говорите им, типа вы что, решили помешать внедрению моей гениальной идеи? Они со страхом в глазах отрицательно машут головами, тогда закройте дверь — говорите вы им. Они закрывают и вы, как и было запланировано, открываете с ноги дверь самого главного директора, заходите в его приёмную. Там сидит красивая секретарша и от громкого стука из своего помещения выглядывает, тот самый, главный директор, вы ему говорите: «У меня гениальная идея». Директор практически со слезами на глазах произносит: «Ну вот и дождались… я сейчас позвоню, отменю встречу с мэром нашего города, скажу, что не до него сейчас, а вы пока располагайтесь». А секретарша такая говорит: «Похоже меняется руководство компании, я тогда пока быстро схожу кружевное нижнее бельё одену». «Не надо, вы нужны мне как профессионал своего дела» — шутите вы ей, а жестом показываете чтобы она не забыла ещё и в душ забежать. Тут прибегает самый главный директор, со взглядом любящей собаки и открытом ртом смотри на вас… Но пока в этом мире всё не так.



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



1. Сначала обратился в Хабр



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



На первое письмо не ответили, на второе ответили почти дословно, немного утрировано повторю: «Когда мы отвечаем, то мы отвечаем, а когда не отвечаем, то не отвечаем». Потом подавал заявку на корпоративный блог для стартапа, ответили, что пока не видят функционала, только статьи про космос. Сейчас, я кстати, снова подал заявку, функционала теперь стало побольше, посмотрим результат.



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



2. Маил.Ру Групп



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



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



Внутри компании я бы развивал идею сделать её народным предприятием. Даже не находясь сейчас внутри компании, считаю, что Майл — одна из тех компаний, которая в России уже сейчас в основном готова стать народной. Через некоторое время начну закидывать видео-обращениями и другими материалами главного владельца Майла, олигарха Алишера Усманова, чтобы он осознал происходящие эволюционные процессы и встал на сторону трудящихся. Будет весело.



3. ОнлиОфис



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



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



4. В конечном итоге были «в Кругу Друзей»



Помните о такой соц. сети? Это, которая бывшая odnoklassniki.KM.ru. Которая соц. сеть от портала «Кирилл и Мефодий». Помните их диски с энциклопедиями? Вот с ними я продвинулся дальше всех, им понравилось, но сказали, что их компанию сейчас захватывают рейдеры, поэтому сейчас все силы уходят на то, чтобы биться с ними. Там можно было бы внедрить всё то, что я в Майле предлагал.



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



Результат



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



Так же, появились различные другие наработки. Вот для примера первые листы нашего бизнес-плана адаптированного для Mail.Ru Group. Сейчас там уже многое что нужно дорабатывать и помните, что это экспериментальный бизнес-план нашего совершенно невероятного не совсем стандартного проекта. Конечно, не нужно забывать главное правило бизнеспланостроения: хороший бизнес-план не тот, который красивше выглядит, а тот, который поддержали инвесторы. На первом листе тут замазан квадратиками блок информации, это связано с тем, что информация не актуальна, а второй блок замазан, потому что я не хочу чтобы мне по ночам звонили и дышали в трубку.



Рекомендую всем к прочтению, особенно раздел «Лучший маркетинг для „Технокоммунизма“» (третий и четвёртый лист). Все картинки с листами бизнес-плана кликабельны.



Лист 0 (заглавный)

image



Лист 1 (оглавление-резюме)

image



Лист 2 (краткое описание проекта, концепция и история — начало)

image



Лист 3 (краткое описание проекта — окончание, никакого нытья, лучший маркетинг — начало)

image



Лист 4 (лучший маркетинг — окончание, что нам стало понятно? — начало)

image




Помните те времена, когда всякие большие энциклопедии и игры были на 4 и даже на 8 дисках?




























Проголосовало 3 человека. Воздержался 1 человек.





Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/298344/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Опыт автоматизации тестирования серверного REST API с помощью Jmeter

Суббота, 18 Июня 2016 г. 21:58 (ссылка)

В данной статье речь пойдёт об опыте автоматизации функционального и нагрузочного тестирования API протокола RTLSCP. Серверная часть системы локального позиционирования RealTrac состоит из основного (core) сервера, который связывается с устройствами по протоколу INCP (InterNanoCom Protocol) и сервера приложений (appserver). Сервер приложений общается с внешними клиентами и основным сервером по протоколу RTLSCP (Real Track Location System Communication Protocol). Клиенты также могут напрямую обращаться к основному серверу по RTLSCP.



RTLSCP реализует архитектуру REST и позволяет в запросах и ответах передавать данные в форматах JSON, KML и PNG. Причем общение по нему может происходить как по HTTP/HTTPS, так и по WS/WSS (Websocket). Этот протокол обеспечивает внешнего клиента обширным функционалом:




  • получение различной информации об устройствах — локация, статусы, состояние и т. д.;

  • передача управляющих команд на сервер — изменение параметров устройств, настроек сервера, отправка оповещений на устройства, загрузка карты и т. д.;

  • получение отчетов по устройствам, статуса работы системы от Quality of Service.

  • множество других полезных функций.



Важно, что протокол, со стороны сервера приложений обрастает дополнительным клиент-специфик функционалом от проекта к проекту. Как же это всё тестировать? Вручную получается долго и муторно, тестировщик скорее возненавидит весь мир пока пройдётся по всем командам спецификации RTLSCP API более чем в 120 страниц. Очевидно, этот процесс необходимо автоматизировать.



Тестирование системы проводится под Linux. Изначально мы пытались написать автотесты “на коленке“. Перепробовали несколько вариантов. Генерация запросов со случайными данными и отправка их на вход утилиты для нагрузочного тестирования Siege. В этом случае мы получаем только нагрузочное тестирование без возможности анализа содержимого ответа от сервера. Реализация автотестов на Python и простая отправка запросов через urllib. Тут всё веселее с анализом ответа, но получается громоздкий код, в который сложно вникать стороннему человеку и долго модифицировать.



Решением всех наших проблем стал неожиданно найденный Jmeter от Apache. Хоть на первый взгляд его графический интерфейс вызывает страх у обывателя, на деле этот инструмент помог найти большое количество багов и сэкономить много времени на тестировании RTLSCP API.



Рис. 1. Графический интерфейс Jmeter.



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



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



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





Рис. 2. Так выглядит реализация проверки создания аккаунтов.



С помощью BeanShell PostProcessor (Post тут означает, что скрипт запускается после выполнения запроса) обрабатываем ответ на запрос всех доступных в системе ресурсов. Получаем их количество и генерируем случайные Id ресурсов для последующего присвоения созданным аккаунтам прав доступа к ним. Это осуществляется следующим кодом на BeanShell:

import java.util.regex.*;
import java.util.*;
import java.util.Random;

String response = prev.getResponseDataAsString();
Pattern pattern = Pattern.compile("id");
Matcher matcher = pattern.matcher(response);
int count = 0;
while (matcher.find())
count++;
Random rd=new Random();
Set resSet = new HashSet();
while (resSet.size()<4)
resSet.add(rd.nextInt(count));
int i=1;
Iterator iterator = resSet.iterator();
while (iterator.hasNext()) {
vars.put("resForCombo"+i,iterator.next().toString());
i++;
}




Затем из ответа на запрос информации о ресурсе по его Id получаем его URL с помощью Regular Expression Extractor:





Рис. 3. Использование Regular Expression Extractor.



Тут всё очевидно, в переменную res1Addr помещается содержимое ответа, вырезанное по регулярному выражени. В конце проводим проверку всех созданных аккаунтов и их права доступа к ресурсам. Кстати, обработка Cookies для авторизации в Jmeter реализуется простым добавлением элемента HTTP Cookie Manager.



Элементы типа check AUTH_ACCOUNT_ADDED_INTO_GROUP на рисунке 2 нужны для проверки того, что каждое действие пользователя, совершенное над аккаунтами записалось в соответствующее событие в истории событий (Получаемой также через RTLSCP).



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



${__Random(300,180000)}




Или сгенерировать строку определенного размера и случайного содержания:



${__RandomString(${__Random(3,30)},ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789,)}




Понравилось, что в Jmeter любое действие можно реализовать как в коде BeanShell, так и с помощью встроенных инструментов. К примеру, получить количество доступных в системе ресурсов (выше мы это делаем через BeanShell PostProcessor ) можно реализовав Regular Expression Extractor, в котором в поле Match No. следует просто указать -1. В этом случае создаётся переменная {Reference Name}_matchNr, содержащая количество найденных в ответе по регулярному выражения строк. Так и ответ на любой запрос можно анализировать в коде BeanShell и выставлять флаги статуса выполнения элемента:



//Get response
response = prev.getResponseDataAsString();
//Check login
if (!response.contains("\"login\":\"${ulogin_g1}\"")) {
log.error("### login NOK!");
Failure= true;
//Check timestamp
} else if(!response.contains("\"create_ts\":${createTS_g1}")) {
log.error("### create_ts NOK!");
Failure= true;




Возможность комментирования каждого элемента делает автотест читабельным и позволяет ссылаться на тикет в багтрекере, например, Redmine:





Рис. 4. Комментирование элементов.



Отключение ресурсоемких проверок и добавление в Thread Group автотеста пользователей в поле Number of Treads (users) превращает наш функциональный автотест в нагрузочный. Теперь проект запускается одновременно из указанного количества потоков и нагружает сервер.





Рис. 5 Нагрузочное тестирование.



Результаты выполнения автотеста можно получить в любом удобном виде, как просмотреть в графической оболочке через View Results Tree, так и файлами логов с различными настройками:





Рис. 6 Получение результатов.



Также стоит отметить возможность в режиме реального времени отправлять результаты или любую другую информацию о статусе автотеста в различные сервисы (JDBC, JMS, Webservice). Например, на Graphite с последующим отображением в Grafana:





Рис. 7 Отправка результатов.



Естественно, у Jmeter существует некоторое количество отрицательных свойств. Например, не всегда удобный графический интерфейс и баги в нём. Но в нашей ситуации, когда срочно (и самое важное, бесплатно) требуется покрыть автоматическими тестами большое количество функций общения клиентов с сервером через протокол, Jmeter оказался незаменимым инструментом тестировщика.
Original source: habrahabr.ru.

https://habrahabr.ru/post/303584/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Опыт автоматизации тестирования серверного REST API с помощью Jmeter

Суббота, 18 Июня 2016 г. 21:58 (ссылка)

В данной статье речь пойдёт об опыте автоматизации функционального и нагрузочного тестирования API протокола RTLSCP. Серверная часть системы локального позиционирования RealTrac состоит из основного (core) сервера, который связывается с устройствами по протоколу INCP (InterNanoCom Protocol) и сервера приложений (appserver). Сервер приложений общается с внешними клиентами и основным сервером по протоколу RTLSCP (Real Track Location System Communication Protocol). Клиенты также могут напрямую обращаться к основному серверу по RTLSCP.



RTLSCP реализует архитектуру REST и позволяет в запросах и ответах передавать данные в форматах JSON, KML и PNG. Причем общение по нему может происходить как по HTTP/HTTPS, так и по WS/WSS (Websocket). Этот протокол обеспечивает внешнего клиента обширным функционалом:




  • получение различной информации об устройствах — локация, статусы, состояние и т. д.;

  • передача управляющих команд на сервер — изменение параметров устройств, настроек сервера, отправка оповещений на устройства, загрузка карты и т. д.;

  • получение отчетов по устройствам, статуса работы системы от Quality of Service.

  • множество других полезных функций.



Важно, что протокол, со стороны сервера приложений обрастает дополнительным клиент-специфик функционалом от проекта к проекту. Как же это всё тестировать? Вручную получается долго и муторно, тестировщик скорее возненавидит весь мир пока пройдётся по всем командам спецификации RTLSCP API более чем в 120 страниц. Очевидно, этот процесс необходимо автоматизировать.



Тестирование системы проводится под Linux. Изначально мы пытались написать автотесты “на коленке“. Перепробовали несколько вариантов. Генерация запросов со случайными данными и отправка их на вход утилиты для нагрузочного тестирования Siege. В этом случае мы получаем только нагрузочное тестирование без возможности анализа содержимого ответа от сервера. Реализация автотестов на Python и простая отправка запросов через urllib. Тут всё веселее с анализом ответа, но получается громоздкий код, в который сложно вникать стороннему человеку и долго модифицировать.



Решением всех наших проблем стал неожиданно найденный Jmeter от Apache. Хоть на первый взгляд его графический интерфейс вызывает страх у обывателя, на деле этот инструмент помог найти большое количество багов и сэкономить много времени на тестировании RTLSCP API.



Рис. 1. Графический интерфейс Jmeter.



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



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



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



image

Рис. 2. Так выглядит реализация проверки создания аккаунтов.



С помощью BeanShell PostProcessor (Post тут означает, что скрипт запускается после выполнения запроса) обрабатываем ответ на запрос всех доступных в системе ресурсов. Получаем их количество и генерируем случайные Id ресурсов для последующего присвоения созданным аккаунтам прав доступа к ним. Это осуществляется следующим кодом на BeanShell:

import java.util.regex.*;
import java.util.*;
import java.util.Random;

String response = prev.getResponseDataAsString();
Pattern pattern = Pattern.compile("id");
Matcher matcher = pattern.matcher(response);
int count = 0;
while (matcher.find())
count++;
Random rd=new Random();
Set resSet = new HashSet();
while (resSet.size()<4)
resSet.add(rd.nextInt(count));
int i=1;
Iterator iterator = resSet.iterator();
while (iterator.hasNext()) {
vars.put("resForCombo"+i,iterator.next().toString());
i++;
}




Затем из ответа на запрос информации о ресурсе по его Id получаем его URL с помощью Regular Expression Extractor:



image

Рис. 3. Использование Regular Expression Extractor.



Тут всё очевидно, в переменную res1Addr помещается содержимое ответа, вырезанное по регулярному выражени. В конце проводим проверку всех созданных аккаунтов и их права доступа к ресурсам. Кстати, обработка Cookies для авторизации в Jmeter реализуется простым добавлением элемента HTTP Cookie Manager.



Элементы типа check AUTH_ACCOUNT_ADDED_INTO_GROUP на рисунке 2 нужны для проверки того, что каждое действие пользователя, совершенное над аккаунтами записалось в соответствующее событие в истории событий (Получаемой также через RTLSCP).



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



${__Random(300,180000)}




Или сгенерировать строку определенного размера и случайного содержания:



${__RandomString(${__Random(3,30)},ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789,)}




Понравилось, что в Jmeter любое действие можно реализовать как в коде BeanShell, так и с помощью встроенных инструментов. К примеру, получить количество доступных в системе ресурсов (выше мы это делаем через BeanShell PostProcessor ) можно реализовав Regular Expression Extractor, в котором в поле Match No. следует просто указать -1. В этом случае создаётся переменная {Reference Name}_matchNr, содержащая количество найденных в ответе по регулярному выражения строк. Так и ответ на любой запрос можно анализировать в коде BeanShell и выставлять флаги статуса выполнения элемента:



//Get response
response = prev.getResponseDataAsString();
//Check login
if (!response.contains("\"login\":\"${ulogin_g1}\"")) {
log.error("### login NOK!");
Failure= true;
//Check timestamp
} else if(!response.contains("\"create_ts\":${createTS_g1}")) {
log.error("### create_ts NOK!");
Failure= true;




Возможность комментирования каждого элемента делает автотест читабельным и позволяет ссылаться на тикет в багтрекере, например, Redmine:



image

Рис. 4. Комментирование элементов.



Отключение ресурсоемких проверок и добавление в Thread Group автотеста пользователей в поле Number of Treads (users) превращает наш функциональный автотест в нагрузочный. Теперь проект запускается одновременно из указанного количества потоков и нагружает сервер.



image

Рис. 5 Нагрузочное тестирование.



Результаты выполнения автотеста можно получить в любом удобном виде, как просмотреть в графической оболочке через View Results Tree, так и файлами логов с различными настройками:



image image

Рис. 6 Получение результатов.



Также стоит отметить возможность в режиме реального времени отправлять результаты или любую другую информацию о статусе автотеста в различные сервисы (JDBC, JMS, Webservice). Например, на Graphite с последующим отображением в Grafana:



image

Рис. 7 Отправка результатов.



Естественно, у Jmeter существует некоторое количество отрицательных свойств. Например, не всегда удобный графический интерфейс и баги в нём. Но в нашей ситуации, когда срочно (и самое важное, бесплатно) требуется покрыть автоматическими тестами большое количество функций общения клиентов с сервером через протокол, Jmeter оказался незаменимым инструментом тестировщика.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303584/

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<автоматизация - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda