Tome un camino más rápido e inteligente hacia la automatización de pruebas C/C++ impulsada por IA. Descubra cómo >>
White Paper
Vea una vista previa de los avances fundamentales de nuestro documento técnico a continuación.
Los vehículos definidos por software representan un cambio de paradigma en el diseño automotriz, donde las características y funciones se habilitan principalmente mediante software, en lugar de componentes cableados. Este informe técnico explora la arquitectura de los vehículos definidos por software (SDV), los desafíos de desarrollo, los esfuerzos de estandarización y cómo la automatización de pruebas aborda los requisitos críticos de seguridad.
A medida que la electrónica automotriz y el software que la controla evolucionan, el concepto de vehículos definidos por software (SDV) llega para transformar la industria automotriz. En esencia, un SDV no es simplemente el código que se ejecuta en el vehículo, sino un nuevo paradigma donde las características y funciones del vehículo se habilitan principalmente mediante software, en lugar de estar integradas en sus componentes de hardware. Esta transición de lo fijo y lo cableado a los SDV implica un abanico de posibilidades y desafíos, pero muchos de los problemas de desarrollo de software persisten.
Un SDV opera en una plataforma de vehículo conectado basada en una arquitectura orientada a servicios (SOA). Los servicios se prestan a través de redes móviles y los proveedores pueden proporcionar fácilmente componentes de software nuevos o actualizados.
Una de las principales ventajas de este enfoque son las actualizaciones de software inalámbricas (OTA). Esto significa que los vehículos reciben nuevas funciones, mejoras de rendimiento e incluso parches de seguridad críticos sin necesidad de visitar el concesionario. Un SDV siempre puede estar actualizado y protegido. Por ejemplo, dado que el software es fundamental para las funciones y el rendimiento de los vehículos modernos, una OTA podría aumentar la velocidad máxima y la aceleración de su vehículo.
Con estos servicios proporcionados por proveedores OTA, se producirá una transición hacia unidades más pequeñas y manejables, o microservicios. Estos microservicios pueden desarrollarse, probarse e implementarse de forma independiente, lo que mejora la agilidad del proceso de desarrollo de software.
Los fabricantes de vehículos pueden ofrecer características y funcionalidades como servicios de suscripción, lo que permite un modelo de pago por uso. Si bien esto brinda flexibilidad a los consumidores para elegir las características que desean y cuándo las desean, también presenta la posibilidad de mayores costos a largo plazo y la fatiga de las suscripciones.
Los SDV están intrínsecamente vinculados al concepto de vehículos conectados. Por ello, el plan es aprovechar el potencial del internet móvil para compartir datos con otros vehículos e infraestructuras, lo que facilita la comunicación en tiempo real, una navegación optimizada y funciones de seguridad avanzadas.
Ya sea comunicación de vehículo a vehículo (V2V) o de vehículo a infraestructura (V2I), el SDV se convierte en un nodo de una red más amplia, contribuyendo a las advertencias de tráfico y accidentes y, en última instancia, posibilitando ciudades inteligentes.
Esta transición hacia los SDV también responde a la creciente conectividad, potencia de procesamiento y prestaciones que exigen los automóviles modernos. Los sistemas avanzados de asistencia al conductor (ADAS) y los sistemas de infoentretenimiento mejorados requieren una enorme capacidad de procesamiento.
Los SDV están diseñados para satisfacer estas demandas informáticas y adaptarse a las mejoras de estas tecnologías. Los ADAS aún se encuentran en sus primeras etapas. A medida que mejoran sus capacidades, por ejemplo, con una mejor detección de peligros, estas actualizaciones pueden implementarse en los vehículos sin necesidad de nuevo hardware.
La arquitectura de hardware de los SDV es una estructura en capas:
En las arquitecturas vehiculares tradicionales, las ECU se conectan mediante el bus CAN a sistemas centrales que soportan el control, la programación y el diagnóstico. Sin embargo, en los vehículos definidos por software, el enfoque está cambiando del uso de múltiples ECU al uso de ECU virtuales (vECU) o incluso de una sola supercomputadora a bordo.
Las ECU individuales se agrupan por funcionalidad similar y se conectan a un controlador de dominio central, como un IVI. Cada controlador de dominio se conecta a una puerta de enlace que puede transferir información entre dominios según sea necesario.
La arquitectura SDV está evolucionando de un enfoque basado en dominios a uno zonal. En una arquitectura de dominios, las ECU y el cableado se organizan en dominios funcionales específicos, como el dominio del tren motriz. La arquitectura de zonas agrupa las funciones del dominio según su ubicación física dentro del vehículo. Esta transformación de una arquitectura de dominios a una de zonas facilita la independencia de los sensores y actuadores del nodo central de computación del vehículo.
En cuanto a la tecnología de comunicación, Ethernet, una tecnología consolidada y estandarizada, está evolucionando rápidamente para dar soporte a mercados, como el automotriz, con requisitos específicos, como el determinismo y el alto ancho de banda, cruciales para los vehículos autónomos. Las puertas de enlace se utilizan para facilitar la comunicación entre diferentes dominios. Para lograr una comunicación determinista en tiempo real dentro del vehículo, las redes sensibles al tiempo (TSN) están ganando terreno en las aplicaciones automotrices.
La estandarización es un aspecto clave de la transición a las SDV. Implica alcanzar un consenso sobre la arquitectura y las interfaces, así como definir los parámetros de software y los componentes de hardware. Esto fomenta el desarrollo de un ecosistema de proveedores de tecnología que respalden el modelo.
La Fundación Eclipse ha creado el Grupo de Trabajo de Vehículos Definidos por Software (SDV). Este grupo proporciona un foro para que la organización desarrolle y promueva software de código abierto, especificaciones y colaboración abierta. El objetivo es una plataforma de software escalable, modular y extensible que facilite el desarrollo y la implementación de aplicaciones SDV. El grupo de trabajo busca el éxito seleccionando y logrando consenso sobre diversos subproyectos relevantes. Por ejemplo, el proyecto Eclipse openDuT se centra en la automatización de pruebas y validación de software automotriz.
La estandarización de los SDV impulsará la demanda de componentes de software reutilizables y de rápida integración. Existe una gran necesidad de incorporar tecnologías de vanguardia como la virtualización, los contenedores, Linux y el código abierto en general, todas ellas provenientes de áreas externas, al vehículo.
En los próximos años, veremos un cambio hacia la estandarización de las capas de abstracción de hardware (HAL), lo que impulsará la transición hacia la virtualización. Esto mejorará la portabilidad de las capas de software y permitirá el uso de componentes comunes compartidos entre diversas marcas. Esto forma parte de la tendencia general de extender el enfoque de "todo definido por software" a los automóviles.
La iniciativa SDV no es la única visión centrada en software para automóviles actualmente en desarrollo. Por ejemplo, China tiene su propia visión, basada en iniciativas de proveedores nacionales, que actualmente se centran en su propia versión de AUTOSAR, llamada NeuSAR, una plataforma de sistema basada en AUTOSAR desarrollada para automóviles de próxima generación. Esta especificación incluye funciones de seguridad, pilas de protocolos SOA, implementación dinámica de aplicaciones y soluciones de colaboración entre vehículos y la nube.
La intención y el propósito de NeuSAR y la visión de China coinciden con gran parte, si no con todos, los objetivos de SDV. Sin embargo, queda por ver si habrá compatibilidad entre ambas iniciativas.
Se espera que los estándares de seguridad necesarios para el software automotriz actual se mantengan y evolucionen con los SDV. Además, el software tendrá exigencias para cumplir con los objetivos de los SDV, como la portabilidad.
Grado automotriz. El software debe desarrollarse según los estándares de seguridad automotriz. Esto significa que debe ser capaz de funcionar en una amplia gama de condiciones y ser lo suficientemente robusto, fiable y seguro como para satisfacer las exigencias de los vehículos conectados modernos. Esto abarca todo el ciclo de vida del vehículo, desde el inicio hasta el final: desde la concepción, el desarrollo, la producción, el mantenimiento y el fin de su vida útil.
Normas de seguridad y protección. El software debe cumplir con los más altos estándares de seguridad y protección, incluidos ISO 26262 para seguridad funcional y ISO 21434 para ciberseguridad.
Estándares abiertos. Las soluciones deben utilizar estándares abiertos siempre que sea posible para promover la interoperabilidad y la portabilidad.
Desacoplar el software del hardware. El código debe ser agnóstico, basarse en código abierto y, como resultado, cumplir con los mejores estándares de la industria y los estándares de desarrollo de software.
Ciberseguridad. Con la creciente conectividad de los vehículos, la ciberseguridad es una preocupación constante. El software debe diseñarse con sólidas medidas de seguridad para protegerse contra posibles ciberamenazas.
La seguridad y la protección siguen siendo retos considerables para el desarrollo de software automotriz. Otros desafíos de software que enfrentan los SDV incluyen:
La transición del diseño automotriz basado en hardware a una arquitectura de vehículos definida por software es un proceso complejo. Las líneas de código necesarias para cada automóvil crecen exponencialmente, al igual que el esfuerzo de desarrollo.
El uso de IA en SDV presenta su propio conjunto de desafíos, entre ellos garantizar la confiabilidad y la seguridad de estos sistemas.
Integrar varios sistemas de software en un vehículo es una tarea compleja.
El presupuesto del vehículo es una preocupación importante en la transición a los SDV. Si estos no tienen un precio competitivo ni generan márgenes suficientes para los fabricantes, la transición se considerará un fracaso.
Los fabricantes de equipos originales (OEM) de automóviles tendrán que aprender a incorporar software en el proceso de desarrollo automotriz.
Inicialmente, la mayoría de los fabricantes de equipos originales (OEM) dependerán de proveedores de primer y segundo nivel para el suministro de las piezas necesarias para un vehículo. Para que la transición sea efectiva, estos fabricantes deberán dominar la transición del hardware al software.
Para que los SDV sean una realidad, un componente clave de su desarrollo gira en torno a la automatización. Esto incluye entornos de desarrollo, desarrollo basado en modelos, pipelines de CI/CD y pruebas. Las siguientes secciones abordan algunos aspectos clave de la automatización de pruebas y cómo puede mejorar la seguridad de los SDV.
La seguridad seguirá siendo una preocupación primordial para los SDV. Por lo tanto, el desarrollo del software vehicular estará sujeto a estándares y al cumplimiento de estos. Dos estándares importantes:
1. ISO 26262: Vehículos de carretera – Seguridad funcional
2. ISO/SAE 21434: Vehículos de carretera – Ingeniería de ciberseguridad
La norma ISO 26262 aborda los riesgos potenciales causados por el mal funcionamiento de los sistemas electrónicos y eléctricos de los vehículos. La norma proporciona un conjunto de directrices y requisitos detallados para su seguridad funcional, incluyendo un ciclo de vida de seguridad automotriz, aspectos de seguridad funcional de todo el proceso de desarrollo, niveles de integridad de seguridad automotriz (ASIL) y requisitos para las medidas de validación y confirmación. Estos ASIL se aplicarán a los sistemas de software de los SDV, al igual que a los vehículos actuales.
La norma ISO/SAE 21434 se basa en la norma ISO 26262 y proporciona un marco para todo el ciclo de vida de la seguridad de los vehículos. El objetivo de la norma ISO 21434 es proporcionar orientación sobre las mejores prácticas de desarrollo desde una perspectiva de ciberseguridad.
A medida que la industria automotriz se basa cada vez más en software y los SDV se centran, por definición, en el software, estos estándares se vuelven aún más cruciales. Garantizan que, a medida que los vehículos se vuelven más dependientes del software, se aborden exhaustivamente tanto la seguridad funcional como la ciberseguridad.
Análisis estático
Muchas de las tareas de calidad especificadas en la norma ISO 26262, incluyendo el análisis de flujo de datos y control, y el análisis semántico, son compatibles con herramientas modernas y avanzadas como Parasoft C/C++test. Además, herramientas de análisis estático incluye métricas y admite la revisión de código por pares con capacidades que ayudan en las pruebas unitarias y la detección de errores en tiempo de ejecución.
Los métodos de verificación como el análisis estático brindan a los equipos una forma práctica de exponer, prevenir y corregir errores en sistemas de software automotricesEl verdadero poder de las herramientas avanzadas de análisis estático proviene de la capacidad de analizar el código en función de estándares de cumplimiento de codificación de la industria como MISRA, CERT y AUTOSAR C++ 14.
El informe de análisis incluye no solo las reglas del código y las infracciones de directivas, sino también la complejidad del código y las métricas de calidad. Estos datos pueden controlarse en origen para fines históricos y de auditoría. Igualmente importante es el uso de un sistema de seguimiento y gestión de defectos para proporcionar perspectivas analíticas significativas y establecer prioridades, con el fin de resolver desde los problemas de mayor riesgo hasta los de menor.
Cumplimiento del estándar de codificación
Estándares de codificación Incorporan las mejores prácticas adquiridas durante años de experiencia y buscan fortalecer el código evitando malas prácticas que resulten en una calidad y seguridad inadecuadas, a la vez que promueven buenas prácticas que generan un código más resiliente. En el caso de los estándares automotrices, se basan en las mejores prácticas y en directrices para prevenir los tipos de fallas de software que se han observado a lo largo de los años.
Los estándares de codificación suelen definir un subconjunto de un lenguaje de programación que se considera más seguro y fiable de utilizar. El objetivo de esto es evitar comportamientos impredecibles en primer lugar, limitando las características riesgosas del lenguaje que los hacen posibles.
A continuación se presentan algunos ejemplos de estándares de codificación que probablemente sean importantes para el desarrollo de SDV. Estos estándares son aplicables con herramientas de análisis estático como Parasoft C++test.
MISRA C 2023/MISRA C 2025. Un conjunto de pautas de codificación para el lenguaje de programación C. El objetivo del estándar es aumentar la seguridad del software al evitar de forma preventiva que los programadores cometan errores de codificación que pueden provocar fallos en tiempo de ejecución y posibles problemas de seguridad al evitar construcciones problemáticas conocidas en el lenguaje C.
MISRA C ++ 2023. Proporciona una guía explícita para evitar todas las instancias de comportamiento indefinido y no especificado en apoyo del lenguaje de programación C++17 y pretende reemplazar a AUTOSAR C++14.
AUTOSAR C++14. AUTOMOTIVE Open System ARchitecture es una alianza mundial de desarrollo entre fabricantes de equipos originales (OEM), proveedores automotrices de primer nivel, fabricantes de semiconductores, proveedores de software, proveedores de herramientas y otros, que se centran en establecer y estandarizar la arquitectura de software automotriz. Un componente clave de la Plataforma Adaptativa AUTOSAR es Estándar de codificación AUTOSAR C++14 Que define las directrices para el uso del lenguaje C++ moderno en sistemas críticos y de seguridad. Este es el único estándar del mercado compatible con C++ moderno.
CERTIFICADO SEI C y C++. El Equipo de Respuesta a Emergencias Informáticas (CERT) del Instituto de Ingeniería de Software (SEI) tiene un conjunto de pautas para ayudar a los desarrolladores a crear software más seguro y confiable. La primera, que comenzó en 2006 en una reunión del Comité de Normas C, Norma CERT C Se publicó en 2008 y está en constante desarrollo y evolución.
Las reglas son directrices detectables mediante herramientas de análisis estático y que requieren una aplicación estricta, mientras que las recomendaciones son directrices de menor impacto y, en ocasiones, difíciles de analizar automáticamente. CERT incluye un sistema de evaluación de riesgos que combina la probabilidad de ocurrencia, la gravedad y la dificultad relativa de mitigación. Esto ayuda a los desarrolladores a priorizar qué infracciones de las directrices son las más importantes para investigar. La inclusión del esfuerzo de mitigación en la prioridad de las directrices es una importante incorporación a los estándares de codificación segura de CERT, algo de lo que carecen muchos otros estándares.
Automatización de pruebas unitarias de software
La norma ISO 26262 incluye directrices específicas para las pruebas según los niveles de integridad de seguridad, donde las pruebas basadas en requisitos y las pruebas de interfaz son muy recomendables para todos los niveles. Las pruebas de inyección de fallos y de uso de recursos se recomiendan para niveles de integridad inferiores y son muy recomendables para los niveles ASIL D (niveles de integridad de seguridad automotriz). Asimismo, se especifica el método para la conducción de casos de prueba con prácticas recomendadas.
La automatización de pruebas ofrece importantes ventajas al software automotriz integrado. Al prescindir de las suites de pruebas que requieren mucha intervención manual, las pruebas se pueden realizar de forma más rápida, sencilla y frecuente. Liberar este esfuerzo de pruebas manuales libera tiempo para una mejor cobertura de las pruebas y otros objetivos de seguridad y calidad. Un requisito importante para la ejecución automatizada de suites de pruebas es poder ejecutar estas pruebas tanto en el entorno host como en el de destino.
Pruebas basadas en objetivos para sistemas automotrices. La automatización de pruebas de software automotriz es más compleja debido a la complejidad de iniciar y observar pruebas en objetivos integrados. Además, el acceso limitado al hardware de destino que tienen los equipos de software es limitado. La trazabilidad entre los casos de prueba, los resultados de las pruebas, el código fuente y los requisitos debe registrarse y mantenerse. Por lo tanto, la recopilación de datos es crucial para la ejecución de las pruebas.
Parasoft C/C++test se ofrece con su arnés de prueba optimizado para asumir una sobrecarga adicional mínima para la huella binaria y lo proporciona en forma de código fuente, donde se puede personalizar si se requieren modificaciones específicas de la plataforma.
Integración con el IDE. Parasoft C/C++test ofrece integraciones dedicadas con IDEs y depuradores integrados que simplifican y automatizan la ejecución de casos de prueba. Los entornos IDE compatibles incluyen Eclipse, VS Code, Green Hills Multi, Wind River Workbench, IAR EW, ARM MDK, ARM DS-5, TI CCS, Visual Studio y muchos otros.
Generación automatizada de casos de prueba. La generación y gestión de datos de prueba son, con diferencia, los mayores desafíos en las pruebas unitarias. Los casos de prueba son especialmente importantes en desarrollo de software crítico para la seguridad Porque deben garantizar los requisitos funcionales y probar comportamientos impredecibles, así como requisitos de seguridad y protección. Todo ello, cumpliendo con los criterios de cobertura de las pruebas. Parasoft C/C++test genera automáticamente casos de prueba en el popular formato CppUnit.
Pruebas de regresión automatizadas. DTP de Parasoft Permite la creación de líneas base para pruebas de regresión como un conjunto organizado de pruebas y verifica automáticamente todos los resultados. Estas pruebas se ejecutan automáticamente de forma periódica para verificar si las modificaciones del código alteran o interrumpen la funcionalidad capturada en las pruebas de regresión. Si se introduce algún cambio, estos casos de prueba no alertarán al equipo sobre el problema. Durante las pruebas posteriores, DTP informará sobre las tareas si detecta cambios en el comportamiento capturado en la prueba inicial.
Una arquitectura orientada a servicios es fundamental para los SDV. Probar las interfaces de servicio de los vehículos se convertirá en una actividad de desarrollo nueva y crucial. La funcionalidad misma de los nuevos automóviles estará definida por los servicios que ofrecen y utilizan. La automatización de pruebas a nivel de servicio es crucial para el éxito de los SDV, ya que este enfoque facilitará la integración continua y continua (CI/CD), el cumplimiento normativo, las actualizaciones en servicio y la validación funcional.
En lugar de considerar la calidad del sistema en términos de cumplir con los requisitos individuales de cada dispositivo, el alcance se amplía para considerar la calidad de los servicios prestados. Las pruebas a nivel de servicio ayudan a garantizar el cumplimiento de los requisitos no funcionales. Por ejemplo, el rendimiento y la fiabilidad son difíciles de evaluar a nivel de unidad o durante las pruebas unitarias de software. Las pruebas basadas en servicios pueden simular el entorno operativo de un dispositivo para proporcionar cargas realistas. Por ejemplo, en un sistema de climatización (calefacción, ventilación y aire acondicionado), el sensor de temperatura puede probarse con diferentes tasas de solicitud para comprobar si cumple con los requisitos de rendimiento.
La seguridad también es una preocupación importante en los sistemas automotrices. Es muy probable que los ciberataques se originen en la propia red al atacar las API expuestas. Las pruebas basadas en servicios pueden crear entornos simulados para realizar pruebas de seguridad robustas, ya sea mediante fuzzing (entradas de datos aleatorias y erróneas) o ataques de denegación de servicio. En el ejemplo de HVAC, el sensor podría funcionar correctamente con las solicitudes esperadas, pero quedar expuesto al sobrecargarse. Un atacante podría explotar esta vulnerabilidad obteniendo acceso a los datos o controlando partes del sistema.
Un laboratorio de pruebas real requiere la manifestación física más cercana del entorno en el que se planea que funcione un automóvil. Incluso en el laboratorio más sofisticado, es difícil adaptarlo a un entorno realista. Un laboratorio virtual soluciona este problema.
Los laboratorios virtuales superan la necesidad de dependencias de hardware difíciles de encontrar o inexistentes. Utilizan una sofisticada virtualización de servicios junto con otras herramientas clave de automatización de pruebas.
Virtualización de servicios. Simula todas las dependencias que necesita el dispositivo bajo prueba para realizar pruebas completas del sistema. Esto incluye todas las conexiones y protocolos que utiliza el dispositivo con respuestas realistas a la comunicación. Por ejemplo, la virtualización de servicios puede simular el backend de un servidor empresarial con el que se comunica un automóvil. De igual forma, la virtualización puede simular un sistema dependiente, como datos de tráfico o meteorológicos, de forma realista.
Pruebas de servicios y API. Ofrecer una forma de controlar el sistema bajo prueba para garantizar el funcionamiento impecable de los servicios y API que proporciona. Estas pruebas se pueden manipular mediante la plataforma de automatización para realizar pruebas de rendimiento y seguridad según sea necesario.
Monitoreo del tiempo de ejecución. Detecta errores en tiempo real en el sistema bajo prueba y captura información de seguimiento importante.
Gestión y análisis de laboratorios de pruebas. Proporcionar el control general de los laboratorios virtuales. Una vez virtualizados, toda la configuración del laboratorio se puede replicar según sea necesario y las ejecuciones de prueba se pueden automatizar y repetir. Los análisis proporcionan el resumen necesario de las actividades y los resultados.
Los desarrolladores crean integraciones con mayor rapidez, estabilizan dependencias y obtienen control total de sus datos de prueba con Parasoft Virtualize. Los equipos avanzan rápidamente sin esperar el acceso a servicios dependientes que están incompletos o no están disponibles. Las empresas pueden permitir que sus socios realicen pruebas con sus aplicaciones mediante un entorno sandbox dedicado.
Prueba SOA de Parasoft entrega Herramientas de prueba de API y servicios web totalmente integradas que automatiza Pruebas de API funcionales de extremo a extremoLos equipos optimizan las pruebas automatizadas con capacidades avanzadas de creación de pruebas funcionales para aplicaciones con múltiples interfaces y protocolos.
Además, a medida que la estrategia de pruebas de API de un equipo escala, las bibliotecas de casos de prueba crecen. Cuando las API que se prueban cambian, las pruebas deben actualizarse. Normalmente, esto supone un obstáculo importante para escalar una estrategia de automatización de pruebas, pero con SOAtest, los equipos pueden gestionar los cambios de forma automatizada. Configure fácilmente el Asesor de Cambios de SOAtest para escanear automáticamente las interfaces de API, identificar cambios en los servicios y, a continuación, crear una plantilla que muestre cómo los recursos de prueba se ven afectados por dichos cambios y actualice automáticamente las pruebas para reflejarlos.
Los SDV representan una importante transición en la industria automotriz, donde las características y funciones de un vehículo se habilitan principalmente mediante software, en lugar de estar integradas en sus componentes de hardware. Sin embargo, este cambio hacia una mayor dependencia del software implica un enfoque aún mayor en el desarrollo de software para los fabricantes de automóviles, en particular en la automatización de pruebas de software.
La automatización de pruebas es un componente clave en el desarrollo de SDV, especialmente para mejorar la productividad de las pruebas considerablemente, garantizando al mismo tiempo la seguridad. Una de estas maneras es el uso del análisis estático avanzado de Parasoft C/C++test para detectar, prevenir y corregir errores en los sistemas de software automotriz. Esto Solución de prueba para el desarrollo de software C/C++ analiza el código según los estándares de cumplimiento de codificación de la industria, como MISRA y CERT, además de informar las reglas del código, las violaciones de directivas, la complejidad del código y las métricas de calidad.
Las pruebas basadas en servicios garantizan el cumplimiento de los requisitos no funcionales y pueden simular el entorno operativo de un dispositivo para proporcionar cargas realistas. También permiten realizar pruebas de seguridad robustas mediante métodos como fuzzing o ataques de denegación de servicio.
Los laboratorios virtuales, que utilizan una sofisticada virtualización de servicios y otras herramientas clave de automatización de pruebas, ofrecen una solución a los desafíos de las pruebas en un entorno realista. La virtualización de servicios simula todas las dependencias que necesita el dispositivo bajo prueba para realizar pruebas completas del sistema.
SOAtest de Parasoft y Virtualizar Ofrecemos soluciones para pruebas a nivel de servicio de SDV. Virtualize permite a los desarrolladores crear integraciones con mayor rapidez, estabilizar dependencias y obtener control total sobre sus datos de prueba. SOAtest proporciona herramientas de prueba de API y servicios web totalmente integradas que automatizan las pruebas funcionales de API de extremo a extremo.
¿Listo para sumergirte más profundamente?
