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

Vea qué solución de pruebas de API resultó ganadora en el informe GigaOm Radar. Obtenga su informe analítico gratuito >>
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
Código VS
eclipsar
Colinas Verdes Multi
Banco de trabajo Wind River
EW IAR
BRAZO MDK
BRAZO DS-5
TI CCS
Visual Studio
Mucho mas
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.
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.
Explora los capítulos