Fabricación de PCB de precisión, PCB de alta frecuencia, PCB multicapa y montaje de PCB.
Es la fábrica de servicios personalizados más confiable de PCB y PCBA.
Este artículo explicará cómo evitar esos errores ocultos pero comunes y varias técnicas para ayudar a los ingenieros a detectar errores ocultos en el software de copia de pcb. La mayoría de los proyectos de desarrollo de software dependen de una combinación de inspección de código, pruebas estructurales y pruebas funcionales para identificar defectos de software. Aunque estas tecnologías tradicionales son muy importantes y permiten detectar la mayoría de los problemas de software, no pueden detectar muchos errores comunes en sistemas complejos hoy en día.
Las pruebas estructurales o las pruebas de caja blanca pueden detectar eficazmente errores de lógica, flujo de control, cálculo y datos en el Código. Esta prueba requiere una visión general completa del trabajo interno del software (por lo tanto, se llama "caja blanca" o "caja de vidrio") para conocer los detalles de la estructura del software. Revisa cada expresión condicional, operación matemática, entrada y salida. Debido a los muchos detalles a probar, las pruebas estructurales revisan una unidad de software a la vez, generalmente una función o clase. La revisión de código también utiliza las mismas técnicas complejas que la detección de defectos de implementación y problemas potenciales. Al igual que las pruebas de caja blanca, generalmente se revisa cada unidad del software, ya que un proceso de revisión válido requiere una inspección centralizada y detallada. A diferencia de las revisiones y las pruebas de caja blanca, las pruebas funcionales o las hipótesis de prueba de caja negra no saben nada sobre la implementación del software. Prueba la salida impulsada por la entrada controlada. Las pruebas funcionales se componen de procesos de prueba escritos por probadores o desarrolladores que especifican la salida esperada del programa correspondiente a un conjunto específico de entradas del programa. Después de la prueba, el probador compara la salida real con la salida esperada para encontrar el problema. Las pruebas de caja negra pueden detectar eficazmente necesidades no satisfechas, problemas de interfaz, problemas de rendimiento y errores en las funciones más utilizadas del programa. Aunque la combinación de estas tecnologías permite detectar la mayoría de los errores ocultos en programas de software específicos, también tienen limitaciones. La revisión de código y las pruebas de caja blanca solo están dirigidas a una pequeña parte del Código a la vez, ignorando el resto del sistema. Las pruebas de caja negra suelen considerar el sistema en su conjunto e ignorar los detalles de implementación. Algunas cuestiones importantes solo se pueden encontrar prestando atención a los detalles de su interacción en todo el sistema; Los métodos tradicionales no pueden identificar estos problemas de manera confiable. El sistema de software debe ser inspeccionado en su conjunto para encontrar las causas específicas de problemas específicos. Dado que normalmente no es posible analizar a fondo cada detalle del programa y su interacción con todas las demás partes del código, el análisis debe dirigirse a aspectos específicos del programa que se sabe que causa problemas. Este artículo explorará tres áreas de problemas potenciales: * desbordamiento de pila * condiciones de competencia * lectores bloqueados pueden leer la segunda parte de este artículo en línea, que explorará las siguientes preguntas: * preguntas de tiempo * condiciones de reentrada todas las preguntas anteriores son comunes en sistemas que utilizan tecnología de diseño en tiempo real multitarea. El procesador de desbordamiento de pila utiliza la pila para almacenar variables temporales, pasar parámetros a funciones llamadas, guardar el "estado" del hilo, etc. si el sistema no utiliza memoria virtual (en otras palabras, no puede transferir páginas de memoria al disco para liberar espacio de memoria para otros usos), la pila se fijará al tamaño del producto cuando salga de la fábrica. Si por alguna razón la pila está fuera del alcance asignado por el programador, el programa se volverá incierto. Esta inestabilidad puede causar fallas graves en el sistema. Por lo tanto, es fundamental garantizar que el sistema pueda asignar suficientes pilas en el peor de los casos. La única manera de asegurarse de que el desbordamiento de la pila nunca ocurra es analizar el código, determinar el uso máximo de la pila del programa en varias condiciones posibles y luego comprobar si se han asignado suficientes pilas. Es poco probable que la prueba desencadene una combinación específica de entradas instantáneas y provoque el peor escenario para el sistema. El concepto de análisis de profundidad apilada es relativamente simple: 1. Crear un árbol de llamadas para cada hilo independiente. 2. determina el uso de la pila de cada función en el árbol de llamadas. Revise cada árbol de llamadas para determinar qué ruta de llamada desde la raíz del árbol hasta la "hoja" externa requiere la pila más grande. 4. agregue el uso máximo de la pila de cada árbol de llamadas de hilo independiente. 5. determinar el uso máximo de la pila de cada rutina de servicio de interrupción (isr) en cada prioridad de interrupción y calcular el total. Sin embargo, si el ISR en sí no tiene pila, sino que utiliza una pila que interrumpe el hilo, se debe agregar el número máximo de pilas utilizadas por el ISR a la pila de cada hilo. 6. Para cada prioridad, agregue el número de pilas utilizadas para guardar el Estado del procesador cuando se produce la interrupción. Si utiliza rtos, agregue el número máximo de pilas necesarias para usar internamente el propio rtos (a diferencia de las llamadas al sistema causadas por el Código de aplicación contenidas en el paso 2). Además, hay dos cosas importantes que considerar. En primer lugar, el árbol de llamadas construido solo a partir del código fuente del lenguaje de alto nivel puede ser incompleto. La mayoría de los compiladores utilizan bibliotecas de tiempo de ejecución para optimizar tareas de cálculo comunes, como multiplicación y División de enteros de gran valor, operaciones de coma flotante, etc. estas llamadas solo son visibles en el lenguaje de montaje generado por el compilador. Las propias funciones de tiempo de ejecución pueden ocupar una gran cantidad de espacio de pila y deben incluirse en el análisis. Si se utiliza el lenguaje C +, el árbol de llamadas también debe incluir todos los siguientes tipos de funciones (métodos): estructura, destructor, operador de carga pesada, estructura de copia y función de conversión. Todos los punteros de función también deben ser analizados y las funciones que llaman están incluidas en el análisis.
