Logotipo para GIGAOM 365x70

Vea qué solución de pruebas de API resultó ganadora en el informe GigaOm Radar. Obtenga su informe analítico gratuito >>

Cumplimiento de software DO-178C para la industria aeroespacial y de defensa

Examen de la unidad

La verificación de software es parte inherente del desarrollo de software crítico para la seguridad. La prueba, mediante la ejecución, es una forma clave de demostrar la implementación de los requisitos y la entrega de software de calidad. Prueba unitaria es la verificación de requisitos de bajo nivel. Garantiza que cada unidad de software haga lo que se le exige dentro de los requisitos de calidad de servicio esperados: seguridad, protección y confiabilidad. Los requisitos de seguridad y protección indican que las unidades de software no se comportan de manera imprevista, donde el sistema no es susceptible a secuestro, manipulación de datos, robo o corrupción.

Diagrama del modelo V en el desarrollo de software que muestra la relación entre cada fase y la validación inferida en cada etapa de pruebas.
El modelo V en el desarrollo de software que muestra la relación entre cada fase y la validación inferida en cada etapa de pruebas.

En términos del proceso clásico de desarrollo del modelo V, la ejecución de pruebas unitarias es una práctica de verificación para garantizar que el módulo esté diseñado correctamente. DO-178C no exige específicamente las pruebas unitarias por su nombre, sino que utiliza los términos pruebas basadas en requisitos de alto y bajo nivel.

Las pruebas de bajo nivel se entienden comúnmente como pruebas unitarias. En particular, los requisitos para este tipo de pruebas basadas en requisitos incluyen lo siguiente:

Icono dentro de un círculo azul que muestra un contorno blanco de una lista de verificación de pautas.

Pruebas de software, sección 6.4

La DO-178C describe el proceso de validación de software, que incluye varias actividades de prueba, como pruebas basadas en requisitos de software, pruebas de requisitos de bajo nivel y pruebas basadas en requisitos de alto nivel. Las pruebas unitarias suelen considerarse parte de las pruebas de requisitos de bajo nivel, Sección 0 c, donde las unidades de software individuales, como funciones, procedimientos o métodos, se prueban de forma aislada del resto del sistema.

DO-178C enumera los siguientes como errores típicos que revelan las pruebas unitarias.

  • Fallo de un algoritmo para satisfacer un requisito de software
  • Operaciones de bucle incorrectas
  • Decisiones lógicas incorrectas
  • No se pueden procesar correctamente las combinaciones legítimas de condiciones de entrada
  • Respuestas incorrectas a datos de entrada faltantes o corruptos
  • Manejo incorrecto de excepciones, como errores aritméticos o violaciones de los límites de la matriz
  • Secuencia de cálculo incorrecta
  • Precisión, exactitud o rendimiento inadecuados del algoritmo
Icono dentro de un círculo azul que muestra un contorno blanco de una lista de verificación de pautas.

Verificación del software y casos y procedimientos, sección 11.13

Detalla los requisitos para los casos y procedimientos de verificación, que incluyen los casos de prueba utilizados para diversas actividades de prueba, incluidas las pruebas unitarias.

Icono dentro de un círculo azul que muestra un contorno blanco de una lista de verificación de pautas.

Resultados de la verificación del software, sección 11.14

Cubre la documentación y el registro de los resultados de la verificación, que incluyen los resultados de las actividades de pruebas unitarias.

DO-178C No prescribe metodologías o herramientas de prueba específicas, pero sí enfatiza la necesidad de realizar pruebas exhaustivas para garantizar la seguridad y confiabilidad del software aerotransportado. Las pruebas deben realizarse en todos los niveles del sistema junto con la trazabilidad entre los requisitos, el diseño, el código fuente y las pruebas. Además, los planes de prueba, los casos de prueba y los resultados deben documentarse para la certificación.

Métodos de prueba unitaria

Pruebas basadas en requisitos

Estas pruebas prueban directamente la funcionalidad y la calidad del servicio según lo especificado en cada requisito. Las herramientas de automatización de pruebas deben admitir la trazabilidad bidireccional de los requisitos hasta sus pruebas y los informes de cobertura de las pruebas de requisitos para demostrar el cumplimiento.

Los requisitos de alto nivel se derivan de los requisitos de sistema de nivel superior. Descomponen un requisito de sistema en varios requisitos funcionales y no funcionales de alto nivel. Esta fase de la descomposición de requisitos ayuda en el diseño arquitectónico del sistema en desarrollo.

Los requisitos de alto nivel aclaran y ayudan a definir el comportamiento esperado, así como las tolerancias de seguridad, las expectativas de seguridad, la confiabilidad, el rendimiento, la portabilidad, la disponibilidad, la escalabilidad y más. Cada requisito de alto nivel se vincula con el requisito del sistema que satisface. Además, se crean casos de prueba de alto nivel y se vinculan con cada requisito de alto nivel con el fin de verificarlo y validarlo. Este proceso de análisis de requisitos de software continúa a medida que cada requisito de alto nivel se descompone en requisitos de bajo nivel.

Fotografía de un caza F35 Falcon volando de costado contra un cielo azul claro.

Los requisitos de bajo nivel son requisitos de software derivados de requisitos de alto nivel. Descomponen y refinan aún más la especificación del comportamiento del software y la calidad del servicio.

Estos requisitos se reducen a otro nivel de abstracción. Se asignan a unidades de software individuales y están escritos de una manera que facilita el diseño y la implementación de los detalles del software. La trazabilidad se establece desde cada requisito de bajo nivel hasta su requisito de alto nivel y hasta las pruebas de bajo nivel o los casos de prueba unitarios que lo verifican y lo validan.

Las pruebas unitarias consisten en aislar la función, el método o el procedimiento. Se realizan creando stubs y simulando dependencias y forzando rutas específicas de ejecución. Los stubs ocupan el lugar del código en la unidad que depende del código externo a la unidad. También proporcionan al desarrollador o al evaluador la capacidad de manipular la respuesta o el resultado para que la unidad pueda ser utilizada de diversas maneras y con diversos fines, por ejemplo, para garantizar que la unidad funcione de manera confiable, sea segura y también esté libre de vulnerabilidades de seguridad.

Pruebas de interfaz

Las pruebas de interfaz garantizan que las interfaces de programación se comporten y funcionen según lo especificado. Las herramientas de prueba deben crear fragmentos de funciones y fuentes de datos para emular el comportamiento de los componentes externos para la ejecución automática de pruebas unitarias.

Pruebas de inyección de fallas

Las pruebas de inyección de fallas utilizan entradas inesperadas e introducen fallas en la ejecución del código para examinar el manejo de fallas o la falta de este. Las herramientas de automatización de pruebas deben admitir la inyección de condiciones de falla mediante stubs de funciones y la generación automática de pruebas unitarias utilizando un conjunto diverso de condiciones previas, como pruebas de valor mínimo, medio, máximo y heurístico.

Evaluación del uso de recursos

Estas pruebas evalúan la cantidad de memoria, espacio de archivo, ejecución de CPU u otros recursos de hardware de destino utilizados por la aplicación.

Controladores de casos de prueba

Análisis de Requerimientos

Claramente, cada requisito genera, como mínimo, un único caso de prueba unitaria. Aunque las herramientas de automatización de pruebas no generan pruebas directamente a partir de los requisitos, deben admitir la trazabilidad bidireccional desde los requisitos hasta el código y desde los requisitos hasta las pruebas, y mantener la información sobre los requisitos, las pruebas y la cobertura del código.

Generación y Análisis de Clases de Equivalencia

Los casos de prueba deben garantizar que las unidades se comporten de la misma manera para una variedad de entradas, no solo entradas seleccionadas para cada unidad. Las herramientas de automatización de pruebas deben admitir la generación de casos de prueba utilizando fuentes de datos para usar de manera eficiente una amplia gama de valores de entrada. Parasoft C/C++test utiliza funciones de fábrica para preparar conjuntos de valores de parámetros de entrada para la generación automatizada de pruebas unitarias.

Análisis de valores límite

Los casos de prueba generados automáticamente, como los valores heurísticos y los valores límite, emplean fuentes de datos para utilizar una amplia gama de valores de entrada en las pruebas.

Error al adivinar

El método de adivinación de errores utiliza el mecanismo de stubs de función para inyectar condiciones de falla en los resultados del análisis del flujo de código probado y puede usarse para escribir pruebas adicionales.

Ejecución de pruebas automatizada y generación de casos de prueba

La automatización de pruebas ofrece grandes beneficios al software de dispositivos integrados que es crítico para la seguridad. Dejar de lado los conjuntos de pruebas que requieren mucha intervención manual significa que las pruebas se pueden realizar de manera más rápida, más fácil y con mayor frecuencia.

Al delegar este esfuerzo de prueba manual, se libera tiempo para una mejor cobertura de pruebas y otros objetivos de seguridad y calidad. Un requisito importante para la ejecución automatizada de conjuntos de pruebas es poder ejecutar estas pruebas tanto en entornos host como de destino.

Pruebas basadas en objetivos

La automatización de pruebas de software integrado es más desafiante debido a la complejidad de iniciar y observar pruebas en objetivos integrados, sin mencionar el acceso limitado al hardware de destino que tienen los equipos de software.

La DO-178C exige probar el software en un entorno representativo que refleje las condiciones reales de implementación. Esto incluye la realización de pruebas en el hardware de destino o utilizando un entorno de software que se asemeje lo más posible al entorno de destino final. Este enfoque es necesario para garantizar que el software funcione de forma correcta y fiable en la aeronave o el sistema aéreo reales.

La automatización de pruebas de software es esencial para que las pruebas integradas funcionen de manera continua desde el sistema de desarrollo anfitrión hasta el sistema de destino. Probar software integrado requiere mucho tiempo. La automatización del conjunto de pruebas de regresión proporciona un ahorro considerable de tiempo y costos. Además, Prueba C/C++CT y prueba C/C++ Realizar la recopilación de datos de cobertura de código del sistema de destino, lo cual es esencial para la validación y el cumplimiento de los estándares.

Es necesario registrar y mantener la trazabilidad entre los casos de prueba, los resultados de las pruebas, el código fuente y los requisitos. Por estos motivos, la recopilación de datos es fundamental en la ejecución de las pruebas.

Parasoft C/C++test se ofrece con su arnés de prueba optimizado para tomar una sobrecarga adicional mínima para el espacio binario y lo proporciona en forma de código fuente, donde se puede personalizar si se requieren modificaciones específicas de la plataforma.

A la izquierda, se muestra una imagen de una computadora portátil que muestra la prueba Parasoft C/C++. A la derecha, se muestra el hardware de destino. La imagen muestra la implementación, la ejecución y la observación de pruebas desde el host hasta el destino en las soluciones de prueba Parasoft C/C++.
Una vista de alto nivel de la implementación, ejecución y observación de pruebas desde el host hasta el destino en las soluciones de pruebas Parasoft C/C++.

Una de las grandes ventajas que ofrece la solución de pruebas Parasoft C/C++ es su integración exclusiva con IDE y depuradores integrados que hacen que el proceso de ejecución de casos de prueba sea sencillo y automático. Los entornos IDE compatibles incluyen:

Logotipo para VS Code

Código VS

Logotipo para Eclipse

eclipsar

Logotipo de Green Hills Software

Colinas Verdes Multi

Logotipo de Wind River

Banco de trabajo Wind River

Logotipo para IAR

EW IAR

Logotipo para ARM

BRAZO MDK

Logotipo para ARM

BRAZO DS-5

Logotipo de Texas Instruments

TI CCS

Logotipo para Visual Studio

Visual Studio

Círculo azul con un icono de signo más blanco

Mucho mas

Generación automatizada de casos de prueba

Las herramientas de automatización de pruebas unitarias admiten universalmente algún tipo de marco de pruebas, que proporciona la infraestructura necesaria para ejecutar unidades de forma aislada y, al mismo tiempo, satisfacer las dependencias mediante stubs. Parasoft C/C++test no es una excepción. Parte de su capacidad de pruebas unitarias es la generación automatizada de arneses de prueba y los componentes ejecutables necesarios para las pruebas basadas en host y destino.

Captura de pantalla que muestra el explorador de casos de prueba de Parasoft C/C++test, específicamente la generación automatizada de casos de prueba. En este caso, un conjunto de pruebas por función.
Generación automatizada de casos de prueba de Parasoft C/C++, en este caso, un conjunto de pruebas por función

La generación y gestión de datos de prueba es, con diferencia, el mayor desafío de 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 comprobar el comportamiento impredecible, la seguridad y los requisitos de protección. Todo ello sin dejar de satisfacer los criterios de cobertura de las pruebas.

Parasoft C/C++test genera automáticamente casos de prueba como el popular formato CppUnit. De forma predeterminada, C/C++test genera un conjunto de pruebas por archivo de origen/encabezado. También se puede configurar para generar un conjunto de pruebas por función o un conjunto de pruebas por archivo de origen.

Las definiciones de stubs seguras se generan automáticamente para reemplazar funciones “peligrosas”, que incluyen rutinas de E/S del sistema como rmdir(), remove(), rename(), etc. Además, se pueden generar stubs automáticamente para definiciones de funciones y variables faltantes. Se pueden agregar stubs definidos por el usuario según sea necesario.

Pancarta azul oscuro con imagen de un hombre hablando con una mujer sosteniendo una tableta en la mano en una sala de servidores.
Imagen de un hombre y una mujer con una tableta en la mano conversando en una sala de servidores.

Mejore sus pruebas de software con las soluciones de Parasoft.