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 >>
Las pruebas de integración se realizan después de las pruebas unitarias, con el objetivo de validar el diseño arquitectónico. Garantizan que las capacidades funcionales de nivel superior de los componentes de software, incluidos los subsistemas y no las unidades, se comporten y funcionen como se espera. Las pruebas de integraciones de software se pueden realizar de abajo hacia arriba y de arriba hacia abajo con una combinación de enfoques en muchas organizaciones de software.
Las pruebas de integración son un aspecto crítico del proceso de verificación de software en DO-178CLos requisitos explícitos para las pruebas de integración se pueden encontrar principalmente en la Sección 5.4 Proceso de integración y la Sección 6.4 Pruebas de software.
La Sección 6.4.3 Métodos de prueba basados en requisitos de la norma DO-178C exige pruebas basadas en requisitos de hardware y software, que incluyen pruebas de integración. La Sección 6.4.3 b es más específica y describe las pruebas de integración basadas en requisitos como un método que se concentra en las “interrelaciones entre los requisitos del software” y en la “implementación de los requisitos por parte de la arquitectura del software”.
DO-178C enumera los siguientes errores típicos revelados por las pruebas de integración.
Este enfoque comienza tomando un caso de prueba unitaria y eliminando fragmentos y/o simulacros para incorporar unidades de software adicionales para construir una funcionalidad de nivel superior que se pueda probar. La funcionalidad se corresponde con un requisito de alto nivel o es equivalente a él. Los casos de prueba de integración se utilizan para verificar y validar los requisitos de alto nivel.
En esta prueba, primero se prueban los componentes o módulos de software de nivel más alto. Progresivamente, se prueban los módulos de nivel inferior o se asignan las capacidades funcionales a los requisitos de nivel superior. Este enfoque supone que los subsistemas importantes están lo suficientemente completos como para probarlos en su totalidad.
El modelo en V es útil para ilustrar la relación entre las etapas de desarrollo y las etapas de validación. En cada etapa de prueba, se validan partes más completas del software en relación con la fase que lo define.
Para algunos, el modelo V puede implicar un método de desarrollo en cascada. Sin embargo, este no es el caso. DO-178C y las versiones anteriores de la norma no especifican una metodología de desarrollo. El modelo V muestra un conjunto obligatorio de fases de desarrollo. Las organizaciones determinan cómo abordar esas fases. Los equipos pueden adoptar una metodología de desarrollo en cascada, ágil, en espiral o cualquier otra y cumplir con la norma.
Si bien el acto de ejecutar pruebas y recopilar sus resultados se considera validación de software, está respaldado por un proceso de verificación paralelo que involucra las siguientes actividades para garantizar que los equipos estén construyendo el proceso y el producto correctamente.
El papel clave de la verificación es garantizar que la construcción de los artefactos entregados desde la etapa anterior a la especificación cumpla con las pautas de la empresa y la industria.
Realizar algún nivel de automatización de pruebas es fundamental para las pruebas continuas. Muchas organizaciones comienzan simplemente automatizando la integración manual y las pruebas del sistema (de arriba hacia abajo) o las pruebas unitarias (de abajo hacia arriba).
Para permitir pruebas continuas, las organizaciones deben centrarse en crear una práctica de automatización de pruebas escalable que se base en pruebas unitarias aisladas y más rápidas de ejecutar. Una vez que las pruebas unitarias están completamente automatizadas, el siguiente paso son las pruebas de integración y, eventualmente, las pruebas del sistema.
Las pruebas continuas aprovechan la automatización y los datos derivados de las pruebas para proporcionar una evaluación objetiva en tiempo real de los riesgos asociados con un sistema en desarrollo. Si se aplican de manera uniforme, permiten que tanto los gerentes comerciales como los técnicos tomen mejores decisiones sobre el equilibrio entre el alcance, el tiempo y la calidad de la versión.
Las pruebas continuas son una metodología de prueba poderosa que garantiza la calidad continua del código a través del ciclo de vida del desarrollo de software (SDLC). Refuerza el cumplimiento en el análisis de código estático y siempre identifica defectos de seguridad durante cada acción de confirmación del desarrollador al integrar también pruebas unitarias, de integración y del sistema en el ciclo.
El siguiente diagrama ilustra cómo las diferentes fases de prueba son parte de un proceso continuo que se basa en un ciclo de retroalimentación de resultados y análisis de pruebas.
Las herramientas de automatización de pruebas de Parasoft respaldan la validación (actividades de prueba de ejecución real) en términos de automatización de pruebas y pruebas continuas. Estas herramientas también respaldan la verificación de estas actividades, lo que significa respaldar el proceso y los requisitos estándar. Los aspectos clave del desarrollo de software crítico para la seguridad son la trazabilidad de los requisitos y la cobertura del código.
La DO-178C considera la trazabilidad como una actividad clave y un artefacto del proceso de desarrollo. Las secciones 5.4 Proceso de desarrollo de software y 6.4 Pruebas de software requieren una trazabilidad bidireccional entre los requisitos de alto y bajo nivel y la implementación, verificación y validación de activos, que incluyen:
Código fuente
Documentos de requisitos
Resultados de la prueba
Planes de desarrollo y más
El análisis de requisitos exige que “todos los requisitos del software se identifiquen de manera que sea posible demostrar la trazabilidad entre el requisito y la prueba del sistema de software”. Proporcionar una matriz de trazabilidad de requisitos ayuda a satisfacer este requisito.
Los requisitos del software crítico para la seguridad son el factor clave para el diseño y desarrollo de productos. Estos requisitos incluyen la seguridad funcional, los requisitos de la aplicación y los requisitos no funcionales que definen completamente el producto. Esta dependencia de los requisitos documentados tiene ventajas y desventajas, ya que los requisitos deficientes son una de las causas críticas de los incidentes de seguridad en el software. En otras palabras, la implementación no fue la culpable, sino los requisitos deficientes o inexistentes.
El mantenimiento de registros de trazabilidad a cualquier escala requiere automatización. Las herramientas de gestión del ciclo de vida de las aplicaciones incluyen capacidades de gestión de requisitos que están maduras y tienden a ser el centro de la trazabilidad.
Las herramientas de prueba de software integradas como Parasoft completan la verificación y validación de los requisitos al proporcionar una trazabilidad bidireccional automatizada hasta el caso de prueba ejecutable. Esto incluye el resultado de aprobación o rechazo y el seguimiento hasta el código fuente que implementa el requisito.
Parasoft se integra con herramientas de gestión de requisitos o sistemas ALM líderes del mercado, incluidos:
Atlassian Jira
Mucho mas
Como se muestra en la imagen a continuación, cada uno de los Parasoft soluciones de automatización de pruebas (C/C++test, C/C++test CT, Jtest, dotTEST, S0Atest y Selenic) utilizados dentro del ciclo de vida del desarrollo permiten asociar las pruebas con los elementos de trabajo definidos en estos sistemas, como requisitos, defectos y casos de prueba o ejecuciones de prueba. El panel central de análisis e informes, Parasoft DTP, gestiona la trazabilidad.
Parasoft DTP correlaciona los identificadores únicos del sistema de gestión con:
Los resultados se muestran en los informes de trazabilidad de Parasoft DTP y se envían al departamento de gestión de requisitos. Proporcionan trazabilidad y generación de informes bidireccionales completos como parte de la matriz de trazabilidad del sistema.
Los informes de trazabilidad en Parasoft DTP son altamente personalizables. La siguiente imagen muestra una plantilla de matriz de trazabilidad de requisitos para los requisitos creados en Polarion y los seguimientos de los casos de prueba, los hallazgos de análisis estáticos, los archivos de código fuente y las revisiones manuales de código.
La correlación bidireccional entre los resultados de las pruebas y los elementos de trabajo proporciona la base de trazabilidad de requisitosParasoft DTP incorpora análisis de pruebas y cobertura de código para evaluar la integridad de las pruebas. Mantener esta correlación bidireccional entre los requisitos, las pruebas y los artefactos que las implementan es un componente esencial de la trazabilidad.
Cobertura de código expresa el grado en que el código fuente de la aplicación es ejercitado por todas las prácticas de prueba, incluidas las pruebas unitarias, de integración y de sistema, tanto automatizadas como manuales.
La recopilación de datos de cobertura a lo largo del ciclo de vida permite obtener métricas de calidad y cobertura más precisas, al tiempo que expone partes no probadas o poco probadas de la aplicación.
Al igual que con la trazabilidad, la cobertura del código es una métrica clave en el desarrollo de sistemas aerotransportados. La DO-178C tiene requisitos específicos en la Sección 6.4.4 Análisis de la cobertura de pruebas. Estos requisitos se extienden más allá de la cobertura del código e incluyen la cobertura de pruebas de todos los requisitos de alto y bajo nivel, junto con la cobertura de pruebas de toda la estructura del software.
Sección 6.4.4.2 Análisis de código estructural requiere la cobertura de pruebas del código fuente más allá de lo que ya se puede cubrir con pruebas basadas en requisitos. Esto garantiza que todo el código se ejecute mediante pruebas antes de la certificación. Este análisis de cobertura de código puede revelar problemas como pruebas faltantes y código inactivo o desactivado. Sección 6.4.4.3 Análisis de cobertura estructural La resolución requiere la remediación de estas discrepancias descubiertas durante el análisis de cobertura.
La cobertura de la aplicación también puede ayudar a las organizaciones a centrar sus esfuerzos en las pruebas cuando las limitaciones de tiempo limitan su capacidad para ejecutar el conjunto completo de pruebas de regresión manuales. La captura de datos de cobertura del sistema en ejecución en su hardware de destino durante la integración y las pruebas del sistema completa la cobertura del código de las pruebas unitarias.
Los datos de cobertura capturados se aprovechan como parte del proceso de integración continua (CI), así como del flujo de trabajo del evaluador. Parasoft DTP realiza análisis avanzados sobre la cobertura del código de todas las pruebas, los cambios en el código fuente, los resultados de análisis estáticos y los resultados de las pruebas. Los resultados ayudan a identificar código no probado o poco probado y otras áreas de alto riesgo en el software.
Analizar el código, ejecutar pruebas, hacer un seguimiento de la cobertura y reportar los datos en un tablero o gráfico es un primer paso útil para evaluar el riesgo, pero los equipos aún deben dedicar tiempo y recursos importantes a leer las hojas de té y esperar haber interpretado los datos correctamente.
Comprender los riesgos potenciales de la aplicación requiere procesos de análisis avanzados que fusionen y correlacionen los datos. Esto proporciona una mayor visibilidad de la cobertura real del código y ayuda a identificar brechas en las pruebas y pruebas superpuestas. Por ejemplo, ¿cuál es la cobertura real de la aplicación que se está probando cuando las herramientas informan valores de cobertura diferentes para las pruebas unitarias, las pruebas funcionales automatizadas y las pruebas manuales?
Los porcentajes no se pueden sumar simplemente porque las pruebas se superponen. Este es un paso fundamental para comprender el nivel de riesgo asociado con la aplicación en desarrollo.
Análisis de impacto de prueba Utiliza datos recopilados durante las ejecuciones de pruebas y los cambios en el código entre compilaciones para determinar qué archivos han cambiado y qué pruebas específicas han afectado a esos archivos. El motor de análisis de Parasoft puede analizar la diferencia entre dos compilaciones e identificar el subconjunto de pruebas de regresión que se deben ejecutar. También comprende las dependencias de las unidades modificadas para determinar el efecto dominó que los cambios han tenido en otras unidades.
Parasoft Jtest y dotTEST brindan información sobre el impacto de los cambios de software y recomiendan dónde agregar pruebas y dónde se necesitan más pruebas de regresión.
Las herramientas de automatización de pruebas de software de Parasoft aceleran la verificación al automatizar los muchos aspectos tediosos del mantenimiento de registros, la documentación, los informes, el análisis y la elaboración de informes.
Explora los capítulos