Vea cómo la solución de calidad continua de Parasoft ayuda a controlar y administrar los entornos de prueba para ofrecer software de alta calidad con confianza. Regístrese para la demostración >>
Tiempo de leer: 6 minutosComo le dirá cualquier codificador y evaluador de control de calidad, el análisis estático es una parte fundamental del flujo de trabajo. De la misma manera que las vacunas requieren múltiples ensayos, cualquier proyecto requiere un análisis de la calidad del código en múltiples frentes.
Con ese fin, Parasoft proporciona herramientas de análisis estático para ayudar a automatizar el proceso. Esto también aumenta las mejores prácticas para ser más ágiles en respuesta a los cambios y actualizaciones necesarios. Pero tener una comprensión fundamental del análisis estático, su herramienta y las mejores prácticas es un conocimiento fundamental crítico.
Edúquese o vuelva a familiarizarse con estos conceptos aquí. Este blog responde a las siguientes preguntas:
En pocas palabras, el proceso de análisis de código estático identifica defectos y errores en el código fuente. Si bien el análisis se puede automatizar, la revisión del código generalmente es un esfuerzo conjunto en nombre de los desarrolladores y los evaluadores de QA/QC por igual.
Pero el análisis estático permite una reparación más inmediata y es parte integral del proceso de desarrollo. Independientemente de la industria, la función o el lenguaje, el análisis estático sigue siendo una parte fundamental de cualquier flujo de trabajo de desarrollo.
La realización de un análisis estático requiere una serie de pasos sencillos.
Pero lo mejor del análisis estático es que no requiere la ejecución de código. Todo lo que hay que hacer es ejecutar el análisis para identificar los problemas que deben solucionarse sin riesgos indebidos.
La mejor práctica general sobre cuándo realizar un análisis estático es antes de la revisión del código y después de que se haya escrito el código. La auditoría del código fuente en esa etapa reduce la pérdida de tiempo al resolver errores más rápidamente.
Uno de los tipos más comunes de análisis de código estático es SAST o pruebas de seguridad de aplicaciones estáticas. Esto también se considera una práctica recomendada para las pruebas de seguridad de aplicaciones, pero se puede aplicar en otros lugares. Para identificar todas las clases de errores, es posible que sea necesario utilizar varios estándares de codificación (MISRA, AUTOSAR, CERT, CWE, etc.).
Como tal, es mejor familiarizarse con varios tipos de análisis de código estático y los errores que deben detectar.
Estos métodos son algunos de los más esenciales cuando se trata de pruebas de calidad de código. Los ingenieros pueden causar inadvertidamente fallas o daños en la memoria con un error. El análisis estático basado en patrones extrae las causas de estos problemas mediante patrones en el código que pueden ser errores.
Esto puede ser tan simple como verificadores de sintaxis o algo más sofisticado. Otra nota: estas pruebas de análisis estático rara vez arrojan falsos positivos.
Este método revisa el código en busca de construcciones problemáticas en un conjunto de reglas mediante la simulación de rutas de decisión. Úselo para encontrar desbordamientos de búfer, desreferencias de puntero nulo, datos contaminados y similares.
Aunque es una prueba menos compleja, el análisis de métricas ayuda a medir las características del código. Esto incluye la complejidad del código, la capacidad de mantenimiento, la capacidad de prueba y más.
Cada regla o directriz de análisis estático aborda diferentes cuestiones. Algunos problemas que afectan la confiabilidad pueden ser pérdidas de recursos para C o excepciones de puntero nulo en C ++. MISRA C: 2012 La Directiva 4.12 existe para evitar el uso de memoria dinámica que puede provocar fallas de tiempo de ejecución sin almacenamiento, lo cual no es deseable.
La directriz establece: "Los identificadores 'calloc', 'malloc', 'realloc', 'align_alloc' y 'free' no deben usarse y no se expandirá ninguna macro con uno de estos nombres". Por lo tanto, el siguiente código producirá una infracción.
int * p1 = (int *) malloc (10); / * Violación * / free (p1); /* Violación */
La solución recomendada es preasignar un bloque de memoria y administrarlo según sea necesario mediante su propio equivalente definido de "malloc" y "free". De manera similar, en C ++, la solución común es sobrecargar los operadores "nuevo" y "eliminar".
La intención del software, el lenguaje y la plataforma afectan los tipos de errores que puede detectar el análisis de código estático.
Hay algunos mitos que hay que disipar antes de entrar en las mejores prácticas de análisis de código estático. Por ejemplo, los analizadores estáticos no son productos de un solo uso ni el análisis dinámico es mejor o peor que el análisis estático.
Pero, en general, existen mejores prácticas concretas junto con las mejores prácticas emergentes que los desarrolladores deberían adoptar cuando se trata de análisis estático para la calidad del código.
Escribir código con todas estas cosas en mente asegura menos errores en general. Pero junto con el análisis de código estático, simplifica aún más la identificación de errores y el proceso de QA / QC.
Como se mencionó anteriormente, el análisis de código estático identifica errores basados en conjuntos de reglas dados. Eso significa que, si alguna línea desafía una regla, se marcará. Por supuesto, como en la vida real, existen algunas excepciones a estas reglas en diferentes tipos de software.
En situaciones como estas, los desarrolladores permiten desviaciones. Las reglas pueden ajustarse a las circunstancias y permitir problemas especiales. Un equipo puede decidir sí o no sobre si esa desviación es aceptable o no. Esto también se documenta ya que viola las reglas originales.
El análisis estático es lo que parece: una revisión aislada del código fuente. El análisis dinámico, por otro lado, prueba el código a medida que se ejecuta en una máquina / procesador virtual o incluso real.
Piense en el análisis estático como un pincel aquí y el análisis dinámico como un peine de dientes finos. Puede identificar defectos más sutiles, ya que revisa cómo el código interactúa con otros sistemas, sensores o periféricos.
La gran diferencia es que el análisis dinámico no puede encontrar fallas en una base de código completa. Solo puede encontrar problemas en extractos de código ejecutado. Otra práctica recomendada es utilizar métodos de prueba de análisis tanto estáticos como dinámicos para producir el código más eficaz y eficiente.
Conjunto de Parasoft de herramientas para automatizar las pruebas de software funciona en diversos flujos de trabajo y composiciones de equipo. Cuando se trata de análisis de código estático, eso suena igual de cierto. Hacerlo puede acelerar el ciclo de desarrollo, reducir las tasas de defectos y proporcionar una mejora continua. La identificación de qué herramienta podría funcionar mejor para sus necesidades comienza simplemente con el idioma base del código fuente.
No solo proporcionamos soluciones C / C ++, sino Parasoft también es compatible con Java con Jtest y el lenguaje .NET con dotTEST. ¿Por qué quedarse atascado haciendo más trabajo del necesario cuando puede acelerar el proceso y obtener mejores resultados?
“MISRA”, “MISRA C” y el logotipo del triángulo son marcas comerciales registradas de The MISRA Consortium Limited. © The MISRA Consortium Limited, 2021. Todos los derechos reservados.
Ricardo, gerente sénior de marketing técnico de productos para las soluciones de pruebas integradas de Parasoft, tiene experiencia en SDLC y automatización de pruebas de aplicaciones integradas en tiempo real, de seguridad y críticas para la seguridad, y cumplimiento de software con los estándares de la industria.