¡Descubre GoogleTest, con certificación TÜV y la tecnología Agentic AI para pruebas de C/C++!
Obtenga los detalles »
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.
De calidad automotriz. El software debe desarrollarse conforme a 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 para satisfacer las exigencias de los vehículos conectados modernos. Esto abarca todo el ciclo de vida del vehículo, desde el concepto, el desarrollo, la producción y el mantenimiento hasta el final de su vida útil.
Normas de seguridad. El software debe cumplir con los más altos estándares de seguridad, incluyendo ISO 26262 para seguridad funcional e 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 independiente de la arquitectura, basarse en software de código abierto y, por lo tanto, cumplir con los mejores estándares de la industria y 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, así como el análisis semántico, son compatibles con herramientas modernas y avanzadas como Parasoft C/C++test. Además, las herramientas de análisis estático incluyen métricas y admiten la revisión de código por pares, con funcionalidades que facilitan 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, proporcionan a los equipos una forma práctica de detectar, prevenir y corregir errores en los sistemas de software automotriz . El verdadero potencial de las herramientas avanzadas de análisis estático reside en su capacidad para analizar el código según 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
Los estándares de codificación incorporan las mejores prácticas aprendidas a lo largo de años de experiencia y buscan fortalecer el código evitando malas prácticas que resultan en una calidad y seguridad deficientes, a la vez que promueven buenas prácticas que crean un código más robusto. En el caso de los estándares automotrices, se basan en las mejores prácticas, además de brindar orientación 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.
Aquí se muestran algunos ejemplos de estándares de codificación que probablemente sean importantes para el desarrollo de SDV. Estos estándares se pueden aplicar con herramientas de análisis estático como Parasoft C++test.
MISRA C 2023 / MISRA C 2025. Conjunto de directrices de codificación para el lenguaje de programación C. El objetivo principal de la norma es aumentar la seguridad del software, previniendo de forma preventiva que los programadores cometan errores de codificación que puedan provocar fallos en tiempo de ejecución y posibles problemas de seguridad, evitando así construcciones problemáticas conocidas en el lenguaje C.
MISRA C++ 2023. Proporciona una guía explícita para evitar todos los casos de comportamiento indefinido y no especificado, en apoyo del lenguaje de programación C++17, y está destinado a reemplazar a AUTOSAR C++14.
AUTOSAR C++14. AUTOMOTIVE Open System ARchitecture es una alianza de desarrollo global que reúne a fabricantes de equipos originales (OEM), proveedores automotrices de primer nivel, fabricantes de semiconductores, proveedores de software, proveedores de herramientas y otros, con el objetivo de establecer y estandarizar la arquitectura de software automotriz. Un componente clave de AUTOSAR Adaptive Platform es el estándar de codificación AUTOSAR C++14 , que define las directrices para el uso del lenguaje C++ moderno en sistemas críticos y relacionados con la seguridad. Este es el único estándar del mercado que admite C++ moderno.
Certificación SEI C y C++. El Equipo de Respuesta a Emergencias Informáticas (CERT) del Instituto de Ingeniería de Software (SEI) cuenta con un conjunto de directrices para ayudar a los desarrolladores a crear software más seguro y fiable. Iniciado en 2006 durante una reunión del Comité de Estándares C, el primer estándar CERT C se publicó en 2008 y se encuentra 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 para software automotriz es más compleja debido a la dificultad de iniciar y supervisar las pruebas en objetivos integrados. Sin mencionar el acceso limitado al hardware objetivo que tienen los equipos de software. Es fundamental registrar y mantener la trazabilidad entre los casos de prueba, los resultados de las pruebas, el código fuente y los requisitos. 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 IDE. Parasoft C/C++test ofrece integraciones específicas con IDE y depuradores integrados que facilitan y automatizan la ejecución de casos de prueba. Entre los entornos IDE compatibles se incluyen Eclipse, VS Code, Green Hills Multi, Wind River Workbench, IAR EW, ARM MDK, ARM DS-5, TI CCS, Visual Studio y muchos más.
Generación automatizada de casos de prueba. La generación y gestión de datos de prueba representan, sin duda, los mayores desafíos en las pruebas unitarias. Los casos de prueba son especialmente importantes en el desarrollo de software crítico para la seguridad, ya que deben garantizar los requisitos funcionales y probar el comportamiento impredecible, así como los requisitos de seguridad. Todo ello, cumpliendo con los criterios de cobertura de pruebas. Parasoft C/C++test genera automáticamente casos de prueba en el popular formato CppUnit.
Pruebas de regresión automatizadas. Parasoft DTP permite crear líneas base de pruebas de regresión como una colección organizada de pruebas y verifica automáticamente todos los resultados. Estas pruebas se ejecutan automáticamente de forma regular para comprobar si las modificaciones del código alteran o interrumpen la funcionalidad detectada en las pruebas de regresión. Si se introduce algún cambio, estos casos de prueba fallarán para alertar al equipo del problema. Durante las pruebas posteriores, DTP informará de las tareas si detecta cambios en el comportamiento detectado 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 necesarias para que el dispositivo bajo prueba pueda realizar pruebas completas del sistema. Esto incluye todas las conexiones y protocolos utilizados por el dispositivo, con respuestas de comunicación realistas. 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 manera, la virtualización puede simular un sistema dependiente, como datos de tráfico o meteorológicos, de forma realista.
Pruebas de servicio y API. Ofrecen una forma de controlar el sistema bajo prueba para garantizar que los servicios y las API que proporciona funcionen a la perfección. Estas pruebas se pueden manipular mediante la plataforma de automatización para realizar pruebas de rendimiento y seguridad según sea necesario.
Supervisión en 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. Proporciona un control integral de los laboratorios virtuales. Una vez virtualizados, la configuración completa del laboratorio se puede replicar según sea necesario, y las pruebas se pueden automatizar y repetir. El análisis ofrece un resumen de las actividades y los resultados.
Con Parasoft Virtualize , los desarrolladores crean integraciones con mayor rapidez, estabilizan las dependencias y obtienen control total sobre sus datos de prueba . Los equipos avanzan rápidamente sin tener que esperar el acceso a servicios dependientes que están incompletos o no disponibles. Las empresas pueden permitir que sus socios realicen pruebas con sus aplicaciones en un entorno de pruebas dedicado.
Parasoft SOAtest ofrece herramientas de prueba de API y servicios web totalmente integradas que automatizan las pruebas funcionales de API de extremo a extremo . Los 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 de forma exponencial, garantizando al mismo tiempo la seguridad. Un ejemplo de ello es el uso del análisis estático avanzado Parasoft C/C++test para detectar, prevenir y corregir errores en sistemas de software automotriz. Esta solución de pruebas para el desarrollo de software en C/C++ analiza el código según estándares de cumplimiento de codificación de la industria como MISRA y CERT, además de generar informes sobre reglas de código, infracciones de directivas, complejidad del código y 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 y Virtualize de Parasoft ofrecen soluciones para pruebas de nivel de servicio de SDV. Virtualize permite a los desarrolladores crear integraciones con antelación, 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?
