Header Ads Widget

Ticker

6/recent/ticker-posts

Pruebas automatizadas para Internet de las cosas

 

pruebas-automatizadas-para-Internet-de-las-cosas3

El Internet de las cosas (IoT) está sobre nosotros. Cada objeto que ve a su alrededor, ya sea su refrigerador, su cepillo de dientes eléctrico, su automóvil, incluso su ropa , está a punto de adquirir una forma de sensibilidad.

Algunos de ellos ya lo han hecho. Los relojes Fitbit, los termostatos Nest y los Apple TV son solo la punta del iceberg cuando se trata de nuestro futuro integrado. Sensores, sistemas integrados y backends en la nube se unen para otorgar inteligencia a una desconcertante variedad de objetos tontos e inanimados. IoT será un mercado de un billón de dólares para 2020 y cada gran jugador en el espacio del hardware está compitiendo por una posición, junto con una avalancha de nuevas empresas emergentes de IoT.

Si bien los sistemas integrados han existido durante mucho tiempo en forma de productos electrónicos de consumo, IoT les ha dado una nueva dimensión. Anteriormente, estos sistemas eran esencialmente autónomos y podían funcionar de forma aislada. Pero los objetos conectados ahora necesitan conversar entre sí para funcionar correctamente. Esto significa que los desarrolladores deben considerar formas de optimizar la comunicación de dispositivo a dispositivo (D2D) y de dispositivo a servidor (D2S), además de la interacción humana que entra en juego cuando los objetos cotidianos se convierten en una extensión de Internet.

IoT y pruebas

En el desarrollo de software tradicional, el código se puede construir y las pruebas se pueden automatizar en entornos de producción. El enfoque moderno que hace que este proceso sea repetible y predecible se llama Integración Continua . Su propósito es promover la calidad del código, detectar errores temprano, reducir el riesgo de regresiones y acelerar las iteraciones de desarrollo. Es muy maduro en el espacio de desarrollo web, y cada vez más también en el desarrollo de aplicaciones móviles. De hecho, la automatización de pruebas está tan arraigada en la mente de los desarrolladores que muchos han cambiado todo su enfoque de la programación, favoreciendo el desarrollo impulsado por pruebas , un paradigma en el que las pruebas impulsan el diseño y desarrollo del código, en lugar de al revés.

Aunque las cosas son cada vez más complicadas en el mundo integrado, las expectativas del usuario final son las mismas: los sistemas modernos deberían funcionar . Como nos han enseñado las recientes disfunciones del termostato Nest , los productos de IoT aún no son tan robustos como sus contrapartes más tradicionales.

Hasta hace poco, la integración continua nunca había sido un elemento fijo del desarrollo de software integrado, principalmente porque la interacción entre el hardware y el software dificultaba las cosas. Para solucionar esta brecha, los proveedores de IoT se están moviendo para integrar una mejor integración continua en sus prácticas diarias.

Consulte también nuestras ideas sobre el presente y el futuro de la gestión de la configuración

Qué hace que las aplicaciones de IoT sean más difíciles de probar

Las metodologías de desarrollo ágiles requieren un enfoque diferente cuando se trata de hardware. Se requiere un diseño más inicial y descartar iteraciones anteriores del producto tiene un costo mayor que en los proyectos puramente de software. Como mínimo, los tiempos de iteración son más largos.

Un supuesto que debe verificarse para lograr una integración continua en el IoT es la posibilidad de la automatización de pruebas . Si bien se puede lograr en el espacio integrado, es necesario superar una serie de obstáculos. No es tan fácil aislar el código debido a las dependencias con el hardware subyacente que difícilmente pueden pasarse por alto.

Los sistemas de IoT son aplicaciones compuestas que necesitan:

  • La capacidad de recopilar datos de sensores al reaccionar a una variedad de entradas como el seguimiento táctil, de voz y de movimiento.
  • Diferentes tipos de hardware interoperativo, algunos de ellos conocidos como placas Arduino o Raspberry Pi , otros más inusuales o específicos del contexto, como una máquina de café inteligente una cámara de video o un horno.
  • Servidores basados ​​en la nube, aplicaciones móviles y web desde las que se pueden monitorear y controlar los dispositivos
  • Una API de dispositivo para permitir la extracción de datos rutinarios y diagnósticos de dispositivos a servidores en la nube, así como la manipulación de funciones.

Para complicar aún más las cosas, IoT viene con sus propios protocolos como MQTT , CoAP y ZigBee, además de Wi-Fi y Bluetooth. Además, los sistemas integrados están sujetos a requisitos reglamentarios como IEC 61508 y MISRA para garantizar la seguridad y confiabilidad de los dispositivos electrónicos programables.

Los lenguajes de programación usados ​​en sistemas embebidos tienden a ser C o C ++. Estos lenguajes, de más bajo nivel que los que se utilizan en el desarrollo web, normalmente implican un mejor rendimiento en tiempo de ejecución, pero tiempos de programación más largos y más problemas debido a la necesidad de una gestión explícita de la memoria, por no hablar de menos talento disponible. La falta de portabilidad del código significa que se requiere una compilación cruzada entre los entornos de desarrollo y de destino.

Los proyectos independientes de Greenfield son relativamente raros en el software integrado; los proyectos a menudo tienen dependencias de código heredado monolítico en el que los principios de CI son difíciles de adaptar. Del mismo modo, los subsistemas de aplicaciones de IoT suelen ser propiedad de diferentes proveedores. ¿Qué sucede si se encuentra un error en un dispositivo proporcionado por un proveedor del que depende la configuración de la aplicación?

Los datos de prueba exhaustivos, incluidos los datos de telemetría, pueden ser difíciles de obtener para proyectos de IoT, ya que dependen de situaciones del mundo real en las que factores como las condiciones climáticas y la presión atmosférica pueden influir en los resultados.

Finalmente, los requisitos no funcionales tienden a ser difíciles de probar de manera sistemática. Estos requisitos pueden girar en torno a limitaciones de ancho de banda, fallas de la batería e interferencias.

Simulaciones, garantía de calidad y otros enfoques

A pesar de los problemas enumerados en la sección anterior, los equipos que construyen el futuro de IoT están tratando de lograr procesos de lanzamiento sistemáticos, repetibles y regulares en el mundo integrado.

Parte de las conjeturas en torno a la planificación de pruebas se pueden limitar tomando decisiones familiares siempre que sea posible en la arquitectura. Un ejemplo es usar Linux para todos los proyectos de software integrado, de modo que al menos la capa del sistema operativo siga siendo predecible. En general, la capacidad de desacoplar la lógica de programación del hardware facilita las pruebas del subsistema. Además, centrar los esfuerzos iniciales en prototipos o primeras iteraciones de bajo volumen puede ayudar a eliminar las conjeturas y facilitar la planificación adicional.

Para mitigar los problemas relacionados con la calidad de los datos de prueba, los profesionales de IoT registran datos de entrada de usuarios del mundo real y datos ambientales para reproducirlos en entornos de prueba. Esto ayuda a mantener los entornos de prueba tan parecidos a la producción como sea posible. Las pruebas de cumplimiento con los requisitos reglamentarios se pueden automatizar parcialmente mediante herramientas de análisis estático. Las soluciones de automatización DevOps como Electric Accelerator incluyen este tipo de comprobaciones listas para usar .

Pero sobre todo, los enfoques modernos para probar aplicaciones compuestas con software integrado implican alguna forma de simulación. Al igual que la forma en que los desarrolladores de aplicaciones móviles usan emuladores como Perfecto y Sauce Labs para recrear condiciones de prueba en una variedad de teléfonos inteligentes, los desarrolladores de software integrado recurren al software de simulación para abstraer partes de sus entornos de prueba continuos. En particular, las simulaciones resuelven los problemas de disponibilidad del hardware y aceleran las pruebas con varias versiones, tamaños de pantalla y otras propiedades del hardware.

Estos entornos virtualizados son específicos para cada aplicación y tienden a ser costosos de configurar, pero como es el caso de la integración continua tradicional, el esfuerzo inicial se amortiza muchas veces a medida que se extiende la vida del proyecto. No solo ofrecen mucha más flexibilidad en la configuración y escala de las pruebas, sino que también ayudan a que las pruebas sean el centro de las preocupaciones del equipo.

Un laboratorio de hardware generalmente seguirá el patrón de diseño Modelo-Conductor-Hardware (MCH). El modelo define la lógica abstracta que sustenta el sistema, mantiene el estado del sistema y expone una API al mundo exterior. El Conductor es un componente sin estado que organiza la interacción bidireccional entre el Modelo y el Hardware. El componente de hardware sirve como envoltorio del hardware físico. Se desencadena o reacciona a los eventos comunicándose con el Conductor.

En un laboratorio de hardware virtual, el hardware y el mundo exterior (y su relación con el modelo) se reemplazan por una simulación para que toda la configuración se base exclusivamente en software. Un pequeño número de proveedores ha creado ofertas de simulación como Simics de WindRiver, que ofrece hardware de destino virtual que se puede modificar o escalar a voluntad.

Estos simuladores se están volviendo cada vez más sofisticados y admiten pruebas de rendimiento y memoria, pruebas de seguridad e incluso permiten pruebas de casos extremos e inyección de fallas, como conexiones caídas o interferencias electromagnéticas que crean ruido en los datos del sensor.

No obstante, sigue siendo necesario un proceso de garantía de calidad decente que utilice hardware real al final de cada ciclo de prueba importante. Hay varias razones por las que los equipos nunca pueden depender completamente de las simulaciones. Por un lado, los errores y las aproximaciones en la simulación pueden causar imperfecciones que deben detectarse antes del envío. Además, las pruebas de interacción humana y los comportamientos emergentes no se pueden simular, y la respuesta emocional de una persona incluso a un sistema habilitado por hardware perfectamente funcional puede ser difícil de predecir. Por lo general, se emplea una combinación de pruebas de caja blanca y pruebas de caja negra durante la fase de control de calidad para detectar problemas que podrían haber pasado por las grietas de la simulación.

Quédese para ver nuestro próximo lanzamiento de eBook dedicado a DevOps basado en API

Nuevas fronteras

En la era de la Internet de las cosas, los ciclos de prueba lentos y los productos mal probados ya no son suficientes. Las empresas han adaptado sus procesos internos para reflejar estas nuevas expectativas para prosperar con productos que combinan software y hardware de última generación.

Los objetos inteligentes, como los drones aéreos no tripulados, estarán sujetos a un escrutinio y a regulaciones, y los usuarios aceptarán menos los fallos en sus electrodomésticos inteligentes. Más empresas ofrecerán software de prueba específico de IoT, como SmartBear, cuyo Ready! La solución API permite realizar pruebas API con soporte para MQTT y CoAP. Como efecto secundario, es probable que aumenten las oportunidades laborales de automatización de pruebas en el mundo integrado, creando nuevas perspectivas de carrera para los ingenieros que se encuentran a caballo entre el software y el hardware.

Las expectativas en torno a la implementación de nuevo software y la disponibilidad de nuevas capacidades en el hardware existente se han incrementado en gran medida gracias a los avances recientes en los procesos de entrega de firmware para móviles y automóviles . Hasta hace poco, comprar cualquier dispositivo electrónico constituía una propuesta de valor decreciente: el dispositivo perdería valor gradualmente con el tiempo y los consumidores se verían presionados a comprar nuevas versiones del hardware para beneficiarse de las nuevas funciones.

Pero las actualizaciones de firmware Over The Air (OTA) han cambiado eso. OTA es un método de implementación en el que las actualizaciones de software se envían desde un servicio en la nube central a una variedad de dispositivos en cualquier parte del mundo, generalmente a través de Wi-Fi, pero también a través de banda ancha móvil, o incluso protocolos específicos de IoT como ZigBee.

Los teléfonos inteligentes fueron los primeros dispositivos conectados que contaron con actualizaciones OTA, lo que dio lugar a dispositivos de mayor duración y una menor sensación de obsolescencia programada . Los automóviles llegaron después: Tesla diseña sus automóviles para que las actualizaciones de software puedan solucionar problemas y habilitar nuevas capacidades a través de actualizaciones OTA . Esto requiere una planificación cuidadosa y un enfoque sistemático para la entrega de software. Un ejemplo reciente es la función de piloto automático en el Tesla Model S que se puso a disposición de los automóviles existentes después de una actualización OTA. Los coches ya habían sido equipados con todo el hardware necesario para el funcionamiento del piloto automático (cámaras, sensores, radar), y una simple actualización de software fue suficiente para habilitar la nueva función.

El hecho de que puedan enviar con confianza estos cambios a un producto como un automóvil, para el cual la seguridad y la usabilidad son primordiales, dice mucho sobre el nivel de planificación y automatización de pruebas que han implementado. La sensibilidad de estas actualizaciones solo aumentará en la era de los vehículos autónomos, cuando la inteligencia artificial reemplazará a los humanos en los controles.

Tesla no puede arreglar todo con las actualizaciones OTA: ha tenido que retirar físicamente una gran cantidad de automóviles por problemas en el pasado, pero este nuevo y poderoso método de entrega ha dado a los clientes la expectativa de que el producto que compran mejorará con el tiempo.

El soporte de OTA debe estar integrado en todos los dispositivos compatibles, y los proveedores de IoT deben realizar una cuidadosa administración de versiones y pruebas en entornos simulados para lograr una entrega perfecta de esta manera. Para evitar tiempos de implementación prolongados, solo los archivos delta más pequeños posibles deben entregarse a través de actualizaciones OTA, y la seguridad también puede ser un problema. Empresas como Redbend y Resin ofrecen gestión de dispositivos y soluciones de flujo de trabajo de actualización OTA a los clientes de IoT.

Pensamiento final

El Internet de las cosas promete cambiar la forma en que nos relacionamos con los objetos que nos rodean, pero las altas expectativas establecidas por empresas como Apple y Tesla requerirán que las empresas de IoT evolucionen y eleven la cultura de las pruebas en electrónica de consumo a nuevos estándares.

Publicar un comentario

0 Comentarios