Pruebas de software en RTI

El software RTI está en el corazón de muchas misiones críticas sistemas. Por supuesto, nuestros clientes se preocupan profundamente por la fiabilidad y la calidad de sus sistemas. Entonces, cuando me reúno con los clientes y les presento el proceso de desarrollo de RTI, discutimos las prácticas de desarrollo, las herramientas que usamos y el laboratorio de RTI IIoT. Muchos sienten especial curiosidad por las pruebas de software que hacemos en RTI y los marcos de prueba que utilizamos. Siempre disfruto estas conversaciones; estamos orgullosos de nuestra atención a las pruebas. Esta publicación de blog resume las pruebas que realizamos.

Nuestro proceso de desarrollo y pruebas son comunes en todo el paquete de productos RTI Connext. La excepción es RTI Connext DDS CERT, que se dirige a aplicaciones que requieren certificación de seguridad y sigue un proceso de desarrollo diferente. Durante el desarrollo, y antes de que RTI lance cualquier software nuevo, ejecutamos una gran batería de pruebas para validar la funcionalidad correcta y asegurarnos de que el software funcione y escale bien.

Pruebas unitarias validar que las funciones individuales se desempeñen como se esperaba. Las pruebas unitarias se utilizan como mecanismo clave de prueba de regresión con cada lanzamiento de producto. El marco de pruebas unitarias hace más que probar funciones individuales. También permite un nivel de prueba de características de un solo nodo. En versiones más recientes, incluso hemos estado incorporando configuraciones de Calidad de servicio (QoS) proporcionadas por el cliente como parte de nuestra configuración de prueba. Nuestros procesos están diseñados para garantizar un funcionamiento correcto en entornos lo más realistas posible.

Como parte del desarrollo de nuevas funciones, creamos un plan de prueba de funciones e implementamos un conjunto de pruebas de funciones de un extremo a otro . Estas pruebas se implementan a través de un conjunto de pruebas a medida o, en el caso de Connext DDS Micro, en un nuevo marco de prueba distribuido. Este entorno de prueba utiliza una serie de "ejecutores de prueba" que ejecutan pruebas en diferentes máquinas y un "administrador de pruebas" que sincroniza la ejecución de pruebas entre los ejecutores de prueba. Se desarrolló un lenguaje de prueba DDS simple para describir las pruebas, y cada corredor de pruebas ejecuta una secuencia de comandos, publica los resultados (PASA / FALLA) y espera a que se ejecute la siguiente secuencia de comandos. El enfoque principal de las pruebas de funciones son:

• Pruebe las API de nivel de aplicación y las políticas de QoS de DDS (fecha límite, vivacidad, etc.)
• Pruebe los límites de recursos
• Pruebe el cross-endianness
• Prueba de descubrimiento
• Pruebe el rendimiento
• Garantice la estabilidad

Realizamos varios niveles de pruebas de interoperabilidad:

• Probamos la interoperabilidad con otros productos RTI durante el desarrollo y durante las pruebas de instalación. Desarrollamos un conjunto de pruebas de interoperabilidad automatizadas. Por ejemplo, Connext 6 introdujo una serie de características nuevas en común entre las bibliotecas Connext DDS Micro 3.0 y Connext DDS core 6.0. Generamos automáticamente miles de combinaciones de configuraciones y validamos el comportamiento correcto. La interoperabilidad con versiones anteriores de RTI se prueba cuando determinamos, después del análisis, que existe el riesgo de romper la interoperabilidad.
• Interoperabilidad de idiomas se hace de forma indirecta, ya que varias de nuestras herramientas están escritas en Java u otros lenguajes. Por ejemplo, probamos la interoperabilidad con una aplicación basada en Java cuando usamos las herramientas basadas en Java de RTI, como la Consola de administración de RTI, en combinación con aplicaciones en otros lenguajes.
• Un nivel básico de interoperabilidad con otros proveedores de DDS se realiza regularmente en las reuniones del DDS del Object Management Group (OMG). Los proveedores coordinan un conjunto de pruebas más en profundidad para validar la seguridad DDS, los tipos extensibles y el protocolo de cable DDS-RTPS (https://github.com/omg-dds).

Instalar pruebas capturar pruebas de integración e interoperabilidad entre varios productos. Estas pruebas se ejecutan tanto manualmente como mediante un conjunto de pruebas de instalación automatizado. Instalar prueba cubre una amplia variedad de problemas de integración e interoperabilidad:

• Instalación - ¿Están todos los archivos instalados correctamente?
• Interfaz gráfica de usuario (GUI) - Actualmente no hay pruebas de GUI automatizadas. Durante la prueba de instalación manual, verificamos que las integraciones funcionen correctamente:por ejemplo, entre RTI Launcher y rtiddsgen o rtiprototyper .
• Documentación - ¿Se envía la documentación correcta?
• Prueba de funcionalidad básica para todos los productos que utilizan los ejemplos enviados. Para algunos productos, revisamos toda la Guía de inicio. Esta prueba se repite en una variedad de plataformas.
• Pruebas básicas de interoperabilidad de productos e idiomas .

Para acelerar y ampliar estas pruebas, tenemos pruebas de instalación automatizadas para muchas funciones. Las pruebas actuales cubren:

• Instalación:verifique el archivo para asegurarse de que los archivos estén instalados correctamente.
• Ejecutar las utilidades, incluido rtiddsping , rtiddsspy y rtiprototyper.
• Ejecutar ejemplos generados por rtiddsgen en C, C ++, C ++ 03, C ++ 11, C ++ CLI, C # y Java, utilizando una combinación de bibliotecas DDS estáticas / dinámicas y de liberación / depuración.
• Ejecución de ejemplos enviados mediante una combinación de bibliotecas DDS estáticas / dinámicas y de liberación / depuración.
• Ejemplos de rendimiento en C ++ y Java.
• Ejemplos enviados por TCP en C.

Estas pruebas se ejecutan en 80 arquitecturas diferentes, incluidas las plataformas Windows, Linux, Solaris, Lynx, QNX, Darwin y VxWorks.

Tenemos una variedad de pruebas de perfiles de memoria y rendimiento. Crear una prueba de rendimiento distribuida válida y significativa es extremadamente desafiante. Los enfoques simples no pueden manejar ni medir de manera aproximada las compensaciones en búferes, rendimiento, latencia, entrega en tiempo real, pilas y sistema operativo. RTI tiene una amplia experiencia en la evaluación de las métricas de rendimiento más importantes para los sistemas del mundo real.

• Las pruebas unitarias capturan información sobre el rendimiento y la memoria para funciones específicas.
• Usamos nuestra prueba de rendimiento (perfTest) para caracterizar el rendimiento de Connext DDS. Tenemos una gran inversión en perfTest para que pueda realizar mediciones realistas. Se puede utilizar junto con otros productos, como el servicio de enrutamiento. Usamos PerfTest para recopilar nuestros datos públicos de latencia y rendimiento. Los resultados de rendimiento están disponibles en https://www.rti.com/products/dds/benchmarks.html.
• memTest fue creado para monitorear la huella de memoria de Connext DDS Core. Connext DDS Micro recopila información detallada de la huella de memoria como parte de las pruebas unitarias.
• Otras aplicaciones, como la Consola de administración de RTI y el Servicio de grabación de RTI, tienen capacidades de monitoreo de rendimiento integradas.

La integración continua de PerfTest y MemTest garantiza que no retrocedamos (más allá de un porcentaje preestablecido) a medida que se agregan nuevas funciones al producto Connext DDS.

Pruebas de resistencia emular escenarios de larga duración. Las pruebas de resistencia monitorean la memoria dinámica en varios casos de uso dinámicos, como crear y eliminar participantes remotos o crear y eliminar puntos finales remotos. El marco de prueba de resistencia también se ejecuta con complementos de seguridad RTI en un caso de uso de prueba fuzz donde los paquetes RTPS se alteran aleatoriamente. Las pruebas se ejecutan con la versión generalmente disponible (GAR) más reciente.

Pruebas de estrés y a gran escala se construye expresamente como parte del desarrollo de nuevas funciones. Por ejemplo, cuando presentamos Transport Mobility (también conocida como movilidad IP), creamos un conjunto de pruebas para emular la conexión y desconexión de varios puntos de acceso inalámbricos. Cuando mejoramos la implementación del descubrimiento, creamos un marco de prueba especial para simular miles de puntos finales y verificar automáticamente que fueron descubiertos por cada aplicación. Por lo general, estas pruebas no se vuelven a ejecutar con cada versión, en par

[1] [2] 下一页