Miércoles , septiembre 26 2018

Suscribete gratis a nuestro boletin semanal

VISIONA . DESARROLLADORES . CONECTADOS .

Suscribete nuestro boletin semanal

PATROCINADORES
.
Home / Medición y Pruebas / Importancia de aplicar herramientas unificadas de pruebas C y C++

Importancia de aplicar herramientas unificadas de pruebas C y C++

El uso del lenguaje de programación más utilizado para crear software de sistemas, también hace patente su efectividad en tareas de medición y pruebas de alto nivel como un modelo unificado.

ElectronicosOnline.com Magazine / Oswaldo Barajas

La estructura de datos estáticos que es alimentada por la semántica de librerías y la flexibilidad para programar a bajo y alto nivel, ha hecho que el lenguaje C basado en UNIX continúe demostrando una hegemonía en el sector de sistemas embebidos, y ahora también en el segmento de medición y pruebas como una herramienta unificada.

     

Para la compañía Parasoft, dedicada desarrollar soluciones en automatización y software de instrumentación para mediciones y pruebas con sede en Monrovia, California, la implementación de herramientas unificadas de pruebas basadas en C y C++, se han vuelto esenciales en las estrategias de verificación y validación de proyectos de desarrollo de software.

En el documento compartido por la compañía bajo el nombre de “The Value of Using an Unified C/C++ Testing Tool” en los presupuestos dedicados a las fases de verificación y validación es necesario considerar diversos factores para conseguir un verdadero ahorro, y una parte primordial es la elección de las herramientas de prueba las cuales ayudarán a que se reduzcan los riesgos de errores y se promueva un menor trabajo en la culminación del sistema y sus relativas campañas de mantenimiento.

 

Defectos del Software y sus deficiencias. (Imágenes: Parasoft, 2018).

   

“Obviamente, no todos los proyectos de software necesitan de tecnologías para pruebas y mejoras de la calidad, así que las organizaciones enfrentan un dilema al decidir cómo van a balancear el presupuesto y la calidad. Por ejemplo, los proyectos que están relacionados con la seguridad funcional probablemente seleccionarán todas las tecnologías disponibles para garantizar una calidad que no los comprometa y al mismo tiempo alinearse a normas de seguridad del software como la ISO26262”, apunta el documento de Parasoft, y agrega: “Otros equipos pueden elegir solo el análisis estático y las pruebas unitarias, ya que parecen cubrir una porción significativa de los defectos del software, mientras que algunos equipos pueden encontrar suficiente aplicar un ‘framework’ de pruebas unitarias de fuente abierta.”

De acuerdo a los especialistas de la compañía, la implementación de herramientas de pruebas unificadas en C y C++, son variadas, pero entre otras cosas puede ayudar a definir la ruta que tomará el proyecto conforme a los requerimientos y necesidades de las empresas. Para esto, enlistan las siguientes recomendaciones para tomar en consideración al momento de elegir las propias herramientas unificadas:

- Asegurarse que sean compatibles con múltiples tecnologías de pruebas.
- Sean fáciles de utilizar.
- Que sean capaces de detectar problemas funcionales y ejecutar regresiones.
- Que puedan medir la complejidad, portabilidad y mantenimiento del código.
- Que puedan orientar a los desarrolladores con retroalimentaciones instantáneas a medida que ellos escriben el código.
- Que combinen los resultados de diferentes técnicas para obtener analíticas avanzadas.

El documento rescata que al obtener una herramienta unificada que reúna todos los anteriores atributos, los desarrolladores podrán prevenir diversos problemas a futuro, problemas que a la postre pueden representar grandes pérdidas económicas para la compañía, y principalmente de tiempo al volver a someter al equipo a las indeseadas facetas de depuración y detección de errores.

 

Código con inconsistencias capaces de impedir que los métodos convencionales los detecten.

   

De acuerdo al documento de la compañía, en la anterior ilustración, se observan algunos problemas en las líneas de código. Por ejemplo, en la línea 16 el desarrollador intenta inicializar el búfer global utilizando el valor del índice calculado dentro de la función calculateIdx(), pero no se percatado si se encuentra o no dentro del rango establecido.

- PUBLICIDAD -

Al correr este fragmento de código, los programadores podrían correr el riesgo de involucrarse en un ciclo de pruebas estresantes para identificar la causa, y esto puede ser complejo con todo y ejecutar docenas de pruebas manuales, ya que al escribir un valor entero (int) con ubicación en memoria aleatoria dificulta su detección al estar dependiente a un segmento de almacenamiento dinámico.

Si este error no es corregido y llegase a filtrarse al sistema general una vez que sea mostrado el prototipo final, esta línea 16 se convertirá en el dolor de cabeza del equipo de ingeniería, ya que la operación de este fragmento bloqueará el sistema y no permitirá que se ejecute.

Tomando como referencia el análisis estático para revelar el mismo error, el documento de Parasoft refiere que incluso con este método se arriesga a no ser detectado, debido al propio bucle o ciclo que es utilizado para calcular el índice. Esto tiene relación con características de rendimiento del sistema, puesto que ciertos analizadores de flujo de datos incorporados como funciones dentro de las herramientas de análisis estático, suelen utilizar heurísticas y técnicas de simplificación para acelerar las tareas de diagnóstico del código y son a menudo recomendados para ejecutarse en bucles.

¿Por qué sostiene el documento técnico que regularmente los analizadores de flujo tienden a centrarse poco en los ciclos del código? Porque la mayoría de estas herramientas están configuradas para analizar pocas iteraciones del código, y ejecutan planes de revisión superficial para poner más atención en aquellas que definan como más interesantes según sus parámetros operativos.

“Cualquiera que sea el enfoque aplicado, puede funcionar para un caso y para otro no. Por esta razón, el análisis de flujo puede ser impráctico para un ejemplo en particular donde no será capaz de hallar el problema”, sostuvo el artículo.

 

Ejemplo de código framework con características unificadas.

   

Para reforzar la comprensión sobre las implicaciones al filtrarse líneas con bugs, el documento sugiere como ejemplo una herramienta de monitoreo de memoria, la cual instruye al código para inyectar ciclos de revisión y que finalmente reporta operaciones inapropiadas. Aunque puede ser efectiva, estos análisis tendrán mejores resultados solo en los fragmentos de código donde sean ejecutados, y esto resulta en una ventaja con respecto a las pruebas estáticas ya que no se contemplan parámetros como las suposiciones.

En la siguiente ilustración, Parasoft expone que una buena herramienta unificada de pruebas como los módulos de detección de errores en los tiempos de ejecución. Y también subraya que contrariamente al anterior ejemplo, puede suceder que un analizador estático revele errores que un revisor de memoria no, tal como el siguiente caso apreciable en la siguiente ilustración:

 

Ejemplo de código con errores que pueden infiltrarse en las fases de pruebas y a la postre ocasionar que el sistema no funcione adecuadamente.

   

De forma general, Parasoft hace un llamado a considerar los anteriores elementos al momento de elegir las herramientas unificadas de pruebas en C y asegurarse que cumplan con los requisitos que hasta el momento han sido contemplados como los más valorados al momento de realizar las fases de verificación y pruebas.

- PUBLICIDAD -

Revisa también ...

Análisis binario ayuda a corregir posibles riesgos en códigos reciclados

Abrimos el baúl de contenido técnico para un área en la que cada vez más …

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *