Notizie PCB - Trovare difetti software nel processo di progettazione PCB

Questo articolo introdurrà come evitare quegli errori nascosti ma comuni e introdurrà diverse tecniche per aiutare gli ingegneri a trovare errori nascosti nel software di copia PCB. La maggior parte dei progetti di sviluppo software si basa su una combinazione di ispezione del codice, test strutturali e test funzionali per identificare i difetti del software. Sebbene queste tecniche tradizionali siano molto importanti e possano trovare la maggior parte dei problemi software, non possono rilevare molti errori comuni nei sistemi complessi di oggi.

I test strutturali o i test a scatola bianca possono trovare efficacemente errori di logica, flusso di controllo, calcolo e dati nel codice. Questo test richiede una panoramica completa del funzionamento interno del software (da qui il termine "scatola bianca" o "scatola di vetro") al fine di comprendere i dettagli della struttura del software. Controlla ogni espressione condizionale, operazione matematica, input e output. Grazie ai numerosi dettagli da testare, i test strutturali controllano un'unità software alla volta, solitamente una funzione o una classe. La revisione del codice utilizza anche le stesse tecniche complesse dei difetti di implementazione e dei potenziali problemi da individuare. Come i test white box, le revisioni vengono solitamente condotte per ogni unità del software, perché un processo di revisione efficace richiede ispezioni centralizzate e dettagliate. Diverso dal test di revisione e white box, dal test funzionale o dal test di black box presuppone che non si sappia nulla sull'implementazione del software. Testa l'uscita guidata dall'ingresso controllato. I test funzionali sono composti da procedure di test scritte da tester o sviluppatori, che specificano l'output previsto del programma corrispondente a un insieme di input specifici del programma. Dopo l'esecuzione del test, il tester confronta l'uscita effettiva con l'uscita prevista per trovare il problema. I test della scatola nera possono trovare efficacemente requisiti non soddisfatti, problemi di interfaccia, problemi di prestazioni e errori nelle funzioni più comunemente utilizzate del programma. Sebbene la combinazione di queste tecnologie possa trovare la maggior parte degli errori nascosti in un particolare programma software, hanno anche delle limitazioni. Revisione del codice e test white box mirano solo a una piccola parte del codice alla volta, ignorando il resto del sistema. Il test Black Box di solito tratta il sistema nel suo complesso, ignorando i dettagli di implementazione. Alcuni problemi importanti possono essere scoperti solo concentrandosi sui dettagli della loro interazione nell'intero sistema; i metodi tradizionali non possono identificare in modo affidabile questi problemi. Il sistema software deve essere controllato nel suo complesso per trovare la causa specifica del problema specifico. Poiché di solito è impossibile analizzare accuratamente ogni dettaglio del programma e la sua interazione con tutte le altre parti del codice, l'analisi dovrebbe essere mirata agli aspetti specifici del programma che sono noti per causare problemi. Questo articolo esplorerà tre potenziali aree problematiche:* stack overflow* Race conditions* deadlock I lettori possono leggere la seconda parte di questo articolo online, che esplorerà i seguenti problemi:* Temping issues* Reentrant conditions Tutti i problemi di cui sopra sono abbastanza comuni nei sistemi che utilizzano multi-task real-time design technology. Il processore utilizza lo stack per memorizzare variabili temporanee, passare parametri alla funzione chiamata, salvare il thread "stato", e così via. Se il sistema non utilizza memoria virtuale (in altre parole, non può trasferire pagine di memoria su disco per liberare spazio di memoria per altri usi), lo stack sarà fissato alle dimensioni del prodotto quando esce dalla fabbrica. Se per qualche motivo lo stack esce dall'intervallo assegnato dal programmatore, il programma diventerà incerto. Questa instabilità può causare gravi guasti al sistema. Pertanto, è essenziale garantire che il sistema possa allocare abbastanza stack nel peggiore dei casi. L'unico modo per garantire che un overflow di stack non si verifichi mai è analizzare il codice, determinare l'utilizzo massimo di stack del programma in varie condizioni possibili e quindi verificare se è allocato abbastanza stack. È improbabile che il test inneschi una combinazione specifica di input istantanei e causi lo scenario peggiore nel sistema. Il concetto di analisi della profondità dello stack è relativamente semplice: 1. Creare un albero di chiamata per ogni thread indipendente. 2. Determinare l'utilizzo dello stack di ogni funzione nell'albero delle chiamate.3. Controllare ogni albero di chiamata per determinare quale percorso di chiamata dalla radice dell'albero alla "foglia" esterna richiede più stack. 4. Aggiungere il massimo utilizzo dello stack di ogni albero di chiamata thread indipendente. 5. Determinare l'utilizzo massimo dello stack di ogni routine di servizio di interruzione (ISR) in ogni livello di priorità di interruzione e calcolare il totale. Tuttavia, se l'ISR stesso non ha uno stack e utilizza lo stack del thread interrotto, il numero massimo di stack utilizzato dall'ISR dovrebbe essere aggiunto allo stack di ogni thread.6. Per ogni livello di priorità, aggiungere il numero di stack utilizzati per salvare lo stato del processore quando si verifica un interrupt.7. Se si utilizza RTOS, aggiungere il numero massimo di stack necessari per l'uso interno dell'RTOS stesso (diverso dalla chiamata di sistema causata dal codice dell'applicazione, incluso nel passaggio 2). Inoltre, ci sono due cose importanti da considerare. In primo luogo, un albero delle chiamate costruito solo da codice sorgente di lingua di alto livello è probabile che sia incompleto. La maggior parte dei compilatori utilizza librerie run-time per ottimizzare le attività di calcolo comuni, come moltiplicazione e divisione di numeri interi di grande valore, operazioni in virgola mobile, ecc. Queste chiamate sono visibili solo nel linguaggio di assemblaggio generato dal compilatore. Le stesse funzioni della libreria runtime possono utilizzare molto spazio stack e devono essere incluse nell'analisi. Se si utilizza il linguaggio C++, tutti i seguenti tipi di funzioni (metodi) devono essere inclusi nell'albero delle chiamate: strutturatori, distruttori, operatori sovraccaricati, strutture di copia e funzioni di conversione. Tutti i puntatori di funzione devono essere analizzati e le funzioni che chiamano sono incluse nell'analisi.