Análisis de cobertura de código para proyectos de C ++ incrustado [cerrado]

Question

Recientemente comencé a trabajar en un proyecto de C ++ muy grande que, después de completar el 90% de la implementación, determinó que necesitan demostrar una cobertura de sucursales del 100% durante las pruebas. El proyecto está alojado en una plataforma integrada (Green Hills Integrity). Estoy buscando sugerencias y experiencias de otros en StackOverflow que hayan usado productos de cobertura de código en entornos similares. Me interesan los comentarios positivos y negativos sobre este tipo de herramientas.

Answer 1

¿100% de cobertura de sucursal? Ese es el requisito, especialmente porque algunas sucursales (los valores predeterminados en declaraciones de casos para máquinas de estado, por ejemplo) no deberían ser posibles de ejecutar. Espero que haya algunas excepciones, y si no es así, es posible que deba comprender qué pueden y qué no pueden realizar las pruebas de cobertura antes de comenzar (de lo contrario, terminará sacándose el pelo o, lo que es peor) dando datos incorrectos.

La mayoría de las pruebas de cobertura para sistemas integrados se realizan en PC. El código se transporta, ciertos aspectos del microcontrolador se emulan en el software y Bullseye u otro código de PC similar. Se ejecuta la utilidad. La razón por la que se hace esto es que hay demasiados microcontroladores y compiladores / depuradores / entornos de prueba para desarrollar herramientas de cobertura de código para cada uno.

Cuando existen herramientas de cobertura de código para una plataforma integrada específica, no son tan potentes, configurables, fáciles de usar y libres de errores como las desarrolladas para la plataforma de PC. Los procesadores a menudo no tienen la capacidad de rastreo (sin hardware de emulación de gama alta) necesaria para realizar una buena cobertura de código sin insertar código de depuración adicional en su firmware, que luego tiene consecuencias y efectos secundarios que son difíciles de controlar, especialmente con problemas de tiempo en sistemas en tiempo real.

La transferencia del código no es muy difícil, siempre y cuando puedas abstraer el código específico del hardware (y como estás usando C ++ correctamente, debería ser fácil, ¿verdad? ;-D). El mayor problema con el que se encontrará es el tipo, que, aunque está mejor especificado en C ++ que en C, aún presenta algunos problemas. Asegúrate de que estás utilizando una configuración tipo.h o similar para decirle específicamente al compilador qué es exactamente cada tipo que usas y cómo se debe interpretar.

Después de eso, puedes ir a la ciudad para probar la lógica central en la PC. Incluso puede probar los controladores de hardware de bajo nivel si está interesado en desarrollar la emulación de software requerida para eso, aunque los problemas de tiempo pueden ser un poco problemáticos.

Las herramientas de prueba de software como MxVDev realizan gran parte de la emulación del microcontrolador para usted y le ayudan a resolver los problemas de tiempo como bien, pero aún tendrá un poco de trabajo incluso con esa ayuda.

Si debe hacer esto en el propio sistema, deberá comprar un emulador para el procesador con capacidad de cobertura, no una propuesta económica (muchos emuladores cuestan más de $ 30k para el conjunto completo de herramientas y hardware de emulación) , pero es una de las muchas herramientas utilizadas en entornos de alta confiabilidad, como las industrias automotriz y aeroespacial.

-Adam

Descargo de responsabilidad: trabajo para la empresa que produce MxVDev.

Answer 2

Hemos utilizado Cantata y vectorcast en el pasado para pruebas de unidades y cobertura de códigos. También utilizamos las herramientas de Greenhills y ambas herramientas funcionan con las herramientas de desarrollo de greenhills. Ejecutamos la mayoría de nuestras pruebas en el simulador de PPC y solo ejecutamos pruebas que dependen del hardware en el hardware de Target a través de un pod JTAG. Canatata y Vector cast son muy similares, ya que catata es un poco más fácil de usar y tiene un poco más de funciones, pero los pequeños extras hacen una gran diferencia en la experiencia del usuario.

Generalmente, si desea lograr un alto nivel de cobertura de sucursal, necesita diseñar su código para que sea comprobable. Cuanto más prueba, más aprende acerca de cómo escribir código verificable.

También probamos pruebas de PC frente a pruebas integradas que nos dieron problemas debido a la endianess, pero esto es solo un problema en la capa de hardware.

Además, estas herramientas están certificadas según el estándar RTCA / DO-178B.

Answer 3

Al igual que con Adam, portamos nuestro código incorporado a un arnés basado en PC y realizamos la mayor parte de la cobertura y la creación de perfiles allí. He utilizado AutomatedQA AQTime y Compuwares DevPartner, que son buenos productos,

Si tuviera que hacer un control de cobertura, tendría que usar un perfilador de cobertura que creó una versión instrumentada de la fuente. Hay herramientas comerciales y de código abierto disponibles para hacer esto, pero OMI, agrega mucho trabajo sin mucho beneficio.

El 100% de cobertura es ambicioso, ya que necesitará mucha inyección de fallas para acceder a todos sus controladores de errores y controladores de excepciones. OMI, esto también sería más fácil de hacer en un arnés que a bordo.

También vale la pena señalar a quien haya solicitado una cobertura de código del 100%, mientras que la cobertura de código del 100% de ninguna manera equivale a una cobertura de prueba del 100% . Considere, por ejemplo, la siguiente función;

int div(int a, int b)
{
return (a/b);
}

La cobertura de código al 100% solo requiere que llamemos a esta función una vez, la cobertura de prueba al 100% requeriría muchas más llamadas. Mi propia estrategia de prueba implica el desarrollo de casos de prueba automatizados para obtener un nivel aceptable de cobertura de prueba y usar una herramienta de cobertura de código únicamente como ayuda para buscar áreas no probadas. Hasta cierto punto, depende de su presupuesto de prueba; Para mí, la cobertura de código al 100% es demasiado cara para lo que ofrece.

Answer 4

Consulte Cobertura de prueba de SD C ++ . Esta es una familia de herramientas de cobertura de prueba (ramificada) para una variedad de dialectos de C ++ (ANSI, GNU, MS ...) que se reproducen bien incluso en el hardware de sistemas embebidos reales en virtud de tener una huella muy pequeña y tener un fácil Manera de exportar datos de cobertura de prueba recopilados. Hay una pantalla de cobertura GUI que no depende de su hardware integrado real, que también producirá un resumen completo del informe de cobertura.

[Soy un director de la empresa que proporciona estas herramientas.]