casa › Installazione e configurazione › Test di prodotti software. Come testare la funzionalità di una funzione che utilizza altre funzioni al suo interno? Modificare i test correlati

Test di prodotti software. Come testare la funzionalità di una funzione che utilizza altre funzioni al suo interno? Modificare i test correlati

Anche se sei così tollerante da poter riavviare il programma 18 volte dopo un crash entro mezz'ora e solo allora lanciare il monitor direttamente contro la finestra, sarai d'accordo che lavorare con questo programma sarebbe più comodo se non andasse in crash ".

Come puoi assicurarti che i casi di crash, blocco o mancata esecuzione delle azioni necessarie del programma che hai sviluppato diventino molto rari?

La risposta esatta a questa domanda NO. Ma nel corso dei secoli, gli scienziati più saggi hanno riflettuto per anni su questo argomento e sono riusciti a trovare un rimedio che, se non elimina tutti gli errori del programma, almeno crea l'illusione di un'azione per eliminarli.

E questo rimedio si chiama TEST prodotto software .

Secondo i saggi, il test è uno dei modi più consolidati per garantire la qualità dello sviluppo Software ed è incluso nel set mezzi efficaci sistema moderno garantire la qualità del prodotto software.

La qualità di un prodotto software è caratterizzata da un insieme di proprietà che determinano quanto “buono” è il prodotto dal punto di vista delle parti interessate, come il cliente del prodotto, lo sponsor, l’utente finale, gli sviluppatori e i tester del prodotto, gli ingegneri di supporto, il marketing , formazione e personale di vendita. Ciascuno dei partecipanti può avere un'idea diversa del prodotto e di quanto sia buono o cattivo, ovvero di quanto sia alta la qualità del prodotto. Pertanto, impostare il problema di garantire la qualità del prodotto comporta il compito di identificare le parti interessate, i loro criteri di qualità e quindi trovare la soluzione ottimale che soddisfi questi criteri.

Quando e chi?

Secondo gli sviluppatori esperti, il test di un prodotto software dovrebbe essere effettuato fin dall'inizio della sua creazione. Ma allo stesso tempo, gli stessi sviluppatori esperti non dovrebbero prendere parte ai test, poiché questa non è una questione reale. Il prodotto software deve essere testato da dipendenti appositamente formati chiamati tester, perché anche lo sviluppatore più esperto non sarà in grado di vedere il suo errore, anche utilizzando gli strumenti ottici più recenti.

Tuttavia, tutti gli sviluppatori concordano sul fatto che testare un prodotto software dal punto di vista della classificazione per scopo dovrebbe essere diviso in due classi:

Test funzionale
Test non funzionali

Test funzionale

Test funzionale significa verificare la conformità di un prodotto software ai requisiti funzionali specificati nelle specifiche tecniche per la realizzazione di tale prodotto. In parole povere, il test funzionale verifica se il prodotto software esegue tutte le funzioni previste.

Quindi, alla fine hai deciso di condurre test funzionali. Guardi le specifiche tecniche, leggi i requisiti funzionali e ti rendi conto che almeno non sono nell'ordine in cui è possibile eseguire i test. Rimarrai sorpreso dal fatto che molto tempo fa altri hanno già notato questa discrepanza e hanno capito come superarla.

Per condurre test funzionali, il personale del dipartimento di controllo tecnico sta sviluppando un programma documentale e una metodologia per testare la funzionalità dell'applicazione (API). Il documento PMI contiene un elenco di scenari di test dei prodotti software (casi di test) con descrizione dettagliata passi. Ogni fase dello scenario di test è caratterizzata dalle azioni dell'utente (specialista del test) e dai risultati attesi: la risposta del programma a queste azioni. Il programma e la metodologia di test devono simulare il funzionamento del prodotto software in modalità reale. Ciò significa che lo scenario di test dovrebbe essere costruito sulla base di un'analisi delle operazioni che verranno eseguite dai futuri utenti del sistema e non essere una sequenza di manipolazioni compilata artificialmente e comprensibile solo allo sviluppatore.

Tipicamente, i test funzionali vengono eseguiti a due livelli:

Test dei componenti (unità). Test dei singoli componenti di un prodotto software, focalizzato sulle loro specifiche, scopo e caratteristiche funzionali.
Test d'integrazione. Questo tipo i test vengono eseguiti dopo il test dei componenti e mirano a identificare i difetti nell'interazione di vari sottosistemi a livello di flussi di controllo e scambio di dati.

Test non funzionali

I test non funzionali valutano le qualità di un prodotto software, come l'ergonomia o le prestazioni.

Penso che l’importanza di questo tipo di test sia chiara e non richieda giustificazione. Dopotutto, tutti capiscono che se, ad esempio, le prestazioni del sistema non sono sufficienti, gli utenti dovranno attendere mezza giornata per una risposta alle loro azioni, il che può portare al loro letargo di massa.

Come suggerisce il nome, i test non funzionali verificano che un prodotto software soddisfi i requisiti non funzionali di termine di paragone per la sua creazione. E, come nel caso dei test funzionali, vengono sviluppati un programma e una metodologia di test per i test non funzionali.

Test e conformità del software integrato nell'era agile

La conformità agli standard di settore non è qualcosa che puoi trascurare o fare in seguito; è parte integrante del processo di sviluppo del software incorporato (software). Per alcuni settori, come quello avionico, automobilistico e sanitario, il rigoroso rispetto degli standard di qualità nello sviluppo di sistemi integrati complessi e privi di problemi è vitale per portare un prodotto sul mercato. Tradizionalmente, i test hanno svolto un ruolo importante nello sviluppo di sistemi embedded per le industrie regolamentate da standard. Tuttavia, negli ultimi anni, le pratiche e i processi di test consolidati, il loro posto e il loro ruolo in tali progetti, sono cambiati in modo significativo. È stato un punto di svolta e quando le regole del gioco cambiano, devi cambiare con loro per vincere.

Con il costante sviluppo di nuove tecnologie all'avanguardia, le aziende devono offrire rapidamente al mercato prodotti affidabili, sicuri, facili da usare e compatibili con altri sistemi, solo per evitare di perdersi nel mondo tecnologico in rapida evoluzione. In una situazione del genere, il tradizionale modello a cascata, in cui il processo di sviluppo del software è strettamente sequenziale e i test vengono eseguiti alla fine, diventa un ricordo del passato. I metodi DevOps e Agile stanno diventando sempre più popolari perché consentono agli ingegneri di completare attività che prima si susseguivano simultaneamente.

Test delle prestazioni

Durante la fase di test delle prestazioni, il primo passo è il test di carico, il cui scopo è verificare se il sistema risponderà adeguatamente alle influenze esterne in una modalità vicina al funzionamento reale.

Oltre ai test di carico, i test vengono eseguiti in condizioni di hardware minimo e carico massimo - test di stress, nonché test in condizioni di volumi massimi di informazioni elaborate - test volumetrici.

Esiste un altro tipo di test: test di stabilità e affidabilità, che include non solo test a lungo termine di un prodotto software in condizioni normali, ma anche la sua capacità di tornare al normale funzionamento dopo brevi periodi di carichi stressanti.

Documentazione per i test

Come accennato in precedenza, i test vengono eseguiti in conformità con il programma e la metodologia di test, sviluppati in conformità con GOST 34.603-92.

Per eseguire il test viene sviluppato un test case che deve contenere dati sufficienti per testare tutte le modalità di funzionamento del prodotto software. In genere, un caso di test viene creato congiuntamente dal cliente e dall'appaltatore sulla base di dati reali.

Per eseguire tutti i tipi di test delle prestazioni, molto spesso viene creato un cosiddetto generatore di dati, che consente Modalità automatica creare una quantità di dati sufficiente per ottenere un risultato oggettivo nella valutazione delle prestazioni.

Durante il test viene redatto un protocollo di test che contiene informazioni sul completamento di tutte le fasi e passaggi del test e i commenti ricevuti durante il test.

Se il risultato del test è negativo, le carenze vengono corrette e riesaminate.

Test esplorativi

Test esplorativi (il test ad hoc è un sottotipo di test funzionale. Viene utilizzato in progetti in rapida crescita con metodi di sviluppo flessibili, dove non esistono documentazione e requisiti chiari. Il test esplorativo è la massima acrobazia nel test del software. Il test qualitativo è disponibile per specialisti altamente qualificati e dipende quasi interamente dall'esecutore, dalla sua esperienza, conoscenza (sia nell'argomento che nei metodi di prova) e dalla capacità di arrivare rapidamente all'essenza.

Prove di stress

Il test di carico è il processo di analisi delle prestazioni del sistema sottoposto a test sotto carico. Lo scopo del test di carico è determinare la capacità dell'applicazione di resistere a carichi esterni. In genere, i test vengono eseguiti in più fasi.

1. Generazione di script di test

Per un'analisi efficace, gli scenari devono essere il più vicino possibile ai casi d'uso reali. È importante comprendere che le eccezioni sono sempre possibili e che anche il piano di test più dettagliato potrebbe non coprire un singolo caso.

2. Sviluppo di una configurazione di prova

Avendo scenari di test, è importante distribuire l'ordine di carico crescente. Affinché l'analisi abbia successo è necessario individuare criteri di valutazione delle prestazioni (velocità di risposta, tempo di elaborazione della richiesta, ecc.).

3. Esecuzione di una prova di prova

Quando si eseguono test, è importante monitorare tempestivamente l'esecuzione degli scenari e la risposta del sistema sottoposto a test. L'emulazione di carichi elevati richiede un'infrastruttura hardware e software seria. In alcuni casi, vengono utilizzati metodi di modellazione matematica per ridurre il costo del lavoro. I dati ottenuti a bassi carichi vengono presi come base e approssimati. Maggiore è il livello di carico simulato, minore è la precisione della stima. Tuttavia, questo metodo riduce significativamente i costi.

Testare l'automazione

La caratteristica principale dei test automatizzati è la capacità di condurre rapidamente test di regressione. I principali vantaggi dell'automazione (secondo un rapporto di Worksoft) sono una maggiore efficienza del personale, il rilevamento precoce dei difetti e altro ancora alta qualità processi di business. Questi vantaggi sono controbilanciati da uno svantaggio significativo: i costi elevati: a causa degli elevati costi di implementazione e supporto dell’automazione dei test, circa il 50% delle aziende utilizza ancora principalmente test manuali.

Test di usabilità

Qualsiasi applicazione viene creata per essere utilizzata. La facilità d'uso è un importante indicatore di qualità di un programma. Il settore IT conosce molti esempi di progetti che prendono il via dopo una soluzione di usabilità riuscita. Più ampio è il pubblico, più importante è il fattore usabilità. I test di usabilità comportano un'analisi dettagliata del comportamento dell'utente. Per valutare l’ergonomia, è importante disporre di dati non solo sulla velocità di completamento di un’attività aziendale, ma anche sulle emozioni, sulle espressioni facciali e sul timbro della voce dell’utente.

Test di configurazione

Il test di configurazione dà la certezza che l'applicazione funzionerà su piattaforme diverse e quindi per il numero massimo di utenti. Per le applicazioni WEB, viene solitamente scelto il test cross-browser. Per le applicazioni Windows: test su vari sistemi operativi e dimensioni in bit (x86, x64). Una componente importante del test di configurazione è l'infrastruttura di test: per condurre i test è necessario mantenere costantemente una flotta di macchine di test. Il loro numero varia da 5 a diverse dozzine.

Test d'integrazione

Se il tuo progetto ha più di un componente, necessita di test di integrazione. In un'architettura applicativa complessa, una condizione necessaria per il controllo della qualità è il controllo dell'interazione delle parti del programma. I test vengono eseguiti sviluppando e conducendo casi “end-to-end”. Il test di integrazione viene eseguito dopo il test dei componenti. Pertanto, è molto importante tenere conto dell'esperienza dei test dei componenti, rispettando al contempo l'orientamento aziendale dei casi di test.

Prove di stress

Ogni sistema ha un limite funzionamento normale. Quando il limite viene superato, il sistema entra in uno stato di stress e modifica sensibilmente il suo comportamento. Lo stress test verifica il funzionamento di un'applicazione in condizioni che superano i normali limiti di funzionamento. Ciò è particolarmente importante per i programmi “critici”: software bancario, programmi dell’industria aeronautica, medicina. Lo stress test viene effettuato non solo nella fase di sviluppo del software, ma anche durante l'intero ciclo operativo al fine di ottenere ed elaborare dati sul comportamento del sistema su un lungo periodo di tempo.

Supponiamo che esista una funzione get-data, che restituisce una mappa di informazioni sull'ID utente trasmesso. Ora questa funzione utilizza 3 funzioni source-a , source-b e source-c per produrre tre diversi tipi di mappe. Ora combineremo tutte queste mappe in un'unica mappa e torneremo da get-data.

Quando provo get-datadevo verificare la disponibilità dei dati per le chiavi? Ha senso che questa funzione fallisca gli unit test se uno tra source-a , source-b e source-c fallisce? Se il compito di questa funzione è unire i dati, e lo fa, dovrebbe essere sufficiente, giusto?

2 risposte

Supponiamo che esista una funzione get-data che restituisce una mappa di informazioni sull'ID utente a cui è passata.

Grande. Allora dovresti controllarlo. Per un determinato ID, stai restituendo i dati corretti?

ora questa funzione utilizza 3 funzioni source-a, source-b e source-c per produrre tre diversi tipi di mappe.

Quale dettaglio di implementazione dovresti ignorare nel test. Tutto quello che stai testando è che la tua unità di lavoro (questo metodo) fa quello che dovrebbe fare (prendere un ID e restituire i dati XYZ per quell'ID). Come questo metodo non ha molta importanza: dopo tutto, il vantaggio principale di questo test unitario è che puoi eseguire il refactoring dell'implementazione del metodo e il test controllerà che tu lo abbia fatto correttamente.

Tuttavia, probabilmente dovrai deridere le origini dati, quindi ad un certo punto il test probabilmente avrà bisogno di sapere come funziona questo codice. È necessario bilanciare tre obiettivi concorrenti qui: rendere il test isolato (deridendo i dati), mentre fare in modo che il test si concentri sui requisiti e sul pragmatismo.

Dopotutto, questo è un codice importante. Esistono test per supportare il codice vero e proprio, impiegare molto tempo e il fastidio di controllare la lucidatura non è utile quanto i test fabbricazione .

Nel test unitario dovresti testare solo la funzionalità di una classe, se i tuoi metodi source-a, source-b e source-c chiamano altre classi dovresti deriderle (dovrebbero essere testate in unità nelle loro classi).

Nei test di integrazione, stai testando il comportamento di più classi che interagiscono tra loro, ciò significa che la tua funzione get-data deve verificare che i dati che vengono recuperati siano corretti (source-a, source-b e source-c sono corretti e i dati sono collegati correttamente).

I test unitari sono più semplici e mirati e dovrebbero essere scritti dagli sviluppatori. I test di integrazione di solito diventano obsoleti in tempi relativamente brevi (se presenti componente internoè stato modificato), rendendoli più difficili da eseguire. Deve essere creato da un profilo QA.

Come puoi assicurarti che i casi di crash, blocco o mancata esecuzione delle azioni necessarie del programma che hai sviluppato diventino molto rari?

Non esiste una risposta esatta a questa domanda. Ma nel corso dei secoli, gli scienziati più saggi hanno riflettuto per anni su questo argomento e sono riusciti a trovare un rimedio che, se non elimina tutti gli errori del programma, almeno crea l'illusione di un'azione per eliminarli.

E questo rimedio si chiama TESTARE il prodotto software.

Secondo le persone sagge, il test è uno dei modi più consolidati per garantire la qualità dello sviluppo del software ed è incluso nell'insieme di strumenti efficaci di un moderno sistema di garanzia della qualità del prodotto software.

Quando e chi?

Tuttavia, tutti gli sviluppatori concordano sul fatto che testare un prodotto software dal punto di vista della classificazione per scopo dovrebbe essere diviso in due classi:

Test funzionale
Test non funzionali

Test funzionale

Per condurre test funzionali, il personale del dipartimento di controllo tecnico sta sviluppando un programma documentale e una metodologia per testare la funzionalità dell'applicazione (API). Il documento PMI contiene un elenco di scenari di test dei prodotti software (casi di test) con una descrizione dettagliata dei passaggi. Ogni fase dello scenario di test è caratterizzata dalle azioni dell'utente (specialista del test) e dai risultati attesi: la risposta del programma a queste azioni. Il programma e la metodologia di test devono simulare il funzionamento del prodotto software in modalità reale. Ciò significa che lo scenario di test dovrebbe essere costruito sulla base di un'analisi delle operazioni che verranno eseguite dai futuri utenti del sistema e non essere una sequenza di manipolazioni compilata artificialmente e comprensibile solo allo sviluppatore.

Tipicamente, i test funzionali vengono eseguiti a due livelli:

Test dei componenti (unità). Test dei singoli componenti di un prodotto software, focalizzato sulle loro specifiche, scopo e caratteristiche funzionali.
Test d'integrazione. Questo tipo di test viene effettuato dopo il test dei componenti e mira a identificare difetti nell'interazione di vari sottosistemi a livello di flussi di controllo e scambio di dati.

Test non funzionali

I test non funzionali valutano le qualità di un prodotto software, come l'ergonomia o le prestazioni.

Come suggerisce il nome, il test non funzionale verifica la conformità di un prodotto software ai requisiti non funzionali previsti dalle specifiche tecniche per la sua creazione. E, come nel caso dei test funzionali, vengono sviluppati un programma e una metodologia di test per i test non funzionali.

Test e conformità del software integrato nell'era agile

Test delle prestazioni

Documentazione per i test

Come accennato in precedenza, i test vengono eseguiti in conformità con il programma e la metodologia di test, sviluppati in conformità con GOST 34.603-92.

Per condurre tutti i tipi di test delle prestazioni, molto spesso viene creato un cosiddetto generatore di dati, che consente di creare automaticamente una quantità sufficiente di dati per ottenere un risultato oggettivo nella valutazione delle prestazioni.

Durante il test viene redatto un protocollo di test che contiene informazioni sul completamento di tutte le fasi e passaggi del test e i commenti ricevuti durante il test.

Se il risultato del test è negativo, le carenze vengono corrette e riesaminate.

Test esplorativi

Prove di stress

1. Generazione di script di test

2. Sviluppo di una configurazione di prova

3. Esecuzione di una prova di prova

Testare l'automazione

La caratteristica principale dei test automatizzati è la capacità di condurre rapidamente test di regressione. I principali vantaggi dell'automazione (secondo un rapporto di Worksoft) sono l'aumento dell'efficienza del personale, il rilevamento tempestivo dei difetti e una migliore qualità dei processi aziendali. Questi vantaggi sono controbilanciati da uno svantaggio significativo: i costi elevati: a causa degli elevati costi di implementazione e supporto dell’automazione dei test, circa il 50% delle aziende utilizza ancora principalmente test manuali.

Test di usabilità

Test di configurazione

Il test di configurazione dà la certezza che l'applicazione funzionerà su piattaforme diverse e quindi per il numero massimo di utenti. Per le applicazioni WEB, viene solitamente scelto il test cross-browser. Per applicazioni Windows: test su vari sistemi operativi e velocità in bit (x86, x64). Una componente importante del test di configurazione è l'infrastruttura di test: per condurre i test è necessario mantenere costantemente una flotta di macchine di test. Il loro numero varia da 5 a diverse dozzine.

Test d'integrazione

Prove di stress

Qualsiasi sistema ha un limite al suo normale funzionamento. Quando il limite viene superato, il sistema entra in uno stato di stress e modifica sensibilmente il suo comportamento. Lo stress testing verifica il funzionamento di un'applicazione in condizioni che superano i normali limiti di funzionamento. Ciò è particolarmente importante per i programmi “critici”: software bancario, programmi dell’industria aeronautica, medicina. Lo stress test viene effettuato non solo nella fase di sviluppo del software, ma anche durante l'intero ciclo operativo al fine di ottenere ed elaborare dati sul comportamento del sistema su un lungo periodo di tempo.

Tra tutti i tipi, il test funzionale occupa giustamente una posizione di leadership, poiché il programma deve prima di tutto funzionare correttamente, altrimenti la facilità d'uso, la sicurezza e la velocità sufficiente non serviranno assolutamente a niente. Oltre a padroneggiare varie tecniche di test, ogni specialista deve capire come condurre correttamente un test per ottenere il risultato più efficace.

Test funzionali: dove indirizzare gli sforzi principali?

Per test di unità e sistemi;

Per selezionare la casella “bianca” o “nera”;

Per test manuali e automazione;

Per testare nuove funzionalità o;

Per test “negativi” o “positivi”.

Tra tutte queste aree di attività, è importante trovare la strada giusta, che sarà quella “di mezzo”, in modo da bilanciare gli sforzi, sfruttando al massimo i vantaggi di ciascuna area.

Viene eseguita la verifica del software diversi modi, uno dei quali è la scatola nera o il test basato sui dati.

Il programma in questo caso viene presentato dal punto di vista di una “scatola nera”, e il test viene effettuato per determinare le circostanze in cui il comportamento del programma non sarà conforme alle specifiche. Tutti gli errori vengono identificati attraverso la gestione dei dati, che viene effettuata attraverso test approfonditi, ovvero utilizzando tutto il possibile

Se per un programma l'esecuzione di un comando dipende dagli eventi che lo precedono, allora sarà necessario verificare tutte le possibili sequenze. È abbastanza ovvio che nella maggior parte dei casi è semplicemente impossibile eseguire test esaustivi, quindi più spesso si sceglie un'opzione accettabile o ragionevole che si limita a eseguire il programma su un piccolo sottoinsieme di tutti i dati di input. Questa opzione garantisce pienamente l'assenza di deviazioni dalle specifiche.

Il test funzionale implica la scelta del test giusto. Allo stesso tempo, è consuetudine distinguere tra i seguenti metodi per generare gruppi per loro:

Analisi del valore limite;

Partizione equivalente;

Presupposto dell'errore;

Analisi delle connessioni tra cause ed effetti.

Puoi considerarli ciascuno separatamente.

Analisi del valore limite. I valori limite sono generalmente intesi come quelli situati ai confini delle classi di equivalenza. In tali luoghi è molto probabile che si trovi un errore. L'uso di tale metodo richiede una certa creatività da parte dello specialista, nonché la specializzazione in questo specifico problema in esame.

Partizione equivalente. Tutti i possibili insiemi di parametri di input sono suddivisi in diverse classi di equivalenza. I dati vengono combinati in base al principio del rilevamento di errori simili. È generalmente accettato che se un insieme di una classe mostra un errore, anche quelli equivalenti lo indicheranno. Test funzionali a cura di questo metodo si svolge in due fasi: nella prima vengono individuate le classi di equivalenza, nella seconda vengono già formate le prove apposite.

Analisi delle relazioni di causa ed effetto. Il sistema può selezionare test con prestazioni elevate eseguendo tali controlli. In questo caso, una condizione di input separata viene considerata come causa e la condizione di output viene vista come effetto. Il metodo si basa sull’idea di attribuire tutti i tipi di cause a determinate conseguenze, cioè sul chiarire quelle stesse relazioni di causa-effetto. Il test di un prodotto software viene effettuato in più fasi, da cui risulta un elenco di cause e conseguenti conseguenze.

deviazioni involontarie degli sviluppatori dagli standard di lavoro o dai piani di implementazione;
le specifiche dei requisiti funzionali e di interfaccia vengono effettuate senza rispettare gli standard di sviluppo, il che porta all'interruzione del funzionamento dei programmi;
organizzazione del processo di sviluppo - gestione imperfetta o insufficiente delle risorse del project manager (umane, tecniche, software, ecc.) e questioni di test e integrazione degli elementi del progetto.

Esaminiamo il processo di test in base alle raccomandazioni dello standard ISO/IEC 12207 e forniamo i tipi di errori rilevati in ciascun processo del ciclo di vita.

Processo di sviluppo dei requisiti. Nel determinare il concetto iniziale del sistema e i requisiti iniziali del sistema, gli analisti commettono errori di specifica livello superiore sistemi e costruendo un modello concettuale dell’area tematica.

Errori tipici in questo processo sono:

inadeguatezza della specificazione dei requisiti per gli utenti finali; - errata specificazione dell'interazione del software con l'ambiente operativo o con gli utenti;
non conformità con i requisiti del cliente per le proprietà software individuali e generali;
descrizione errata delle caratteristiche funzionali;
mancanza di disponibilità di strumenti per tutti gli aspetti dell’implementazione dei requisiti del cliente, ecc.

Processo di progettazione.Errori nella progettazione dei componenti possono verificarsi quando si descrivono algoritmi, logica di controllo, strutture dati, interfacce, logica di modellazione del flusso di dati, formati di input/output, ecc. Questi errori si basano su difetti nelle specifiche degli analisti e su difetti di progettazione. Questi includono errori relativi a:

con la definizione dell'interfaccia utente con l'ambiente;
con una descrizione delle funzioni (inadeguatezza degli scopi e degli obiettivi dei componenti che viene rilevata durante il controllo di un insieme di componenti);
con la definizione del processo di elaborazione delle informazioni e dell'interazione tra processi (il risultato di un'errata determinazione delle relazioni tra componenti e processi);
con indicazione errata dei dati e delle loro strutture nella descrizione dei singoli componenti e del software nel suo insieme;
con descrizione errata degli algoritmi del modulo;
con determinazione delle condizioni di accadimento possibili errori in un programma;
in violazione degli standard e delle tecnologie adottate per il progetto.

Fase di codifica.In questa fase sorgono errori che sono il risultato di difetti di progettazione, errori di programmatori e manager durante lo sviluppo e il debug del sistema. Le cause degli errori sono:

mancanza di controllo sui valori dei parametri di input, indici di array, parametri di loop, risultati di output, divisione per 0, ecc.;
gestione errata di situazioni irregolari durante l'analisi dei codici di ritorno da subroutine, funzioni, ecc. richiamate;
violazione degli standard di codifica (commenti negativi, irrazionali assegnazione dei moduli e componente, ecc.);
l'uso di un nome per designare oggetti diversi o nomi diversi di un oggetto, mnemonici dei nomi inadeguati; - modifiche incoerenti al programma da parte di diversi sviluppatori, ecc.

Processo di test.In questo processo, programmatori e tester commettono errori durante l'esecuzione della tecnologia di assemblaggio e test, la selezione di set di test e scenari di test, ecc. I guasti nel software causati da questo tipo di errori devono essere identificati, eliminati e non influiscono sulle statistiche dei componenti e errori software in generale.

Processo di manutenzione.Durante il processo di manutenzione vengono scoperti errori causati da carenze e difetti della documentazione operativa, indicatori insufficienti di modificabilità e leggibilità, nonché dall'incompetenza delle persone responsabili della manutenzione e/o del miglioramento del software. A seconda della natura delle modifiche apportate, in questa fase potrebbero verificarsi quasi tutti gli errori simili agli errori precedentemente elencati nelle fasi precedenti.

Tutti gli errori che si verificano nei programmi sono generalmente suddivisi nelle seguenti classi [7.12]:

errori logici e funzionali;
errori di calcolo e di runtime;
errori di input/output e di manipolazione dei dati;
errori di interfaccia;
errori nel volume dei dati, ecc.

Errori logici sono la causa della violazione della logica dell'algoritmo, dell'incoerenza interna di variabili e operatori, nonché delle regole di programmazione. Gli errori funzionali sono una conseguenza di funzioni definite in modo errato, violazione dell'ordine della loro applicazione o mancanza di completezza della loro implementazione, ecc.

Errori di calcolo si verificano a causa di imprecisioni dei dati di origine e delle formule implementate, errori di metodo, applicazione errata di operazioni di calcolo o operandi. Gli errori di runtime sono associati alla mancata fornitura della velocità di elaborazione della richiesta richiesta o del tempo di ripristino del programma.

Errori di I/O e la manipolazione dei dati sono una conseguenza della scarsa qualità della preparazione dei dati per l'esecuzione del programma, degli errori durante l'inserimento nei database o nel recupero da essi.

Errori di interfaccia si riferiscono a errori nella relazione dei singoli elementi tra loro, che si manifesta durante il trasferimento di dati tra loro, nonché durante l'interazione con l'ambiente operativo.

Errori di volume riguardano i dati e sono una conseguenza del fatto che le modalità di accesso implementate e le dimensioni dei database non soddisfano i reali volumi di informazioni del sistema né l'intensità della loro elaborazione.

Le principali classi di errori indicate sono caratteristiche di diversi tipi di componenti software e si manifestano nei programmi in modi diversi. Pertanto, quando si lavora con un database, si verificano errori nella presentazione e nella manipolazione dei dati, errori logici nella specificazione delle procedure di elaborazione dei dati applicate, ecc. Nei programmi di calcolo predominano gli errori di calcolo e nei programmi di controllo ed elaborazione predominano gli errori logici e funzionali. Il software, composto da molti programmi diversi che implementano funzioni diverse, può contenere errori tipi diversi. Errori di interfaccia e violazioni del volume sono tipici di qualsiasi tipo di sistema.

L'analisi dei tipi di errori nei programmi è un prerequisito per creare piani di test e metodi di test per garantire la correttezza del software.

Nell'attuale fase di sviluppo degli strumenti di supporto allo sviluppo del software (tecnologie CASE, metodi orientati agli oggetti e strumenti per la progettazione di modelli e programmi), viene effettuata una progettazione in cui il software è protetto dagli errori più comuni e quindi previene il verificarsi di difetti del software.

Rapporto tra errore e fallimento.La presenza di un errore in un programma, di norma, porta al guasto del software durante il suo funzionamento. Per analizzare le relazioni di causa-effetto di "errore-guasto", vengono eseguite le seguenti azioni:

identificazione di difetti nelle tecnologie di progettazione e programmazione;
il rapporto tra difetti nel processo di progettazione ed errori umani;
classificazione di fallimenti, difetti e possibili errori, nonché difetti in ciascuna fase di sviluppo; - confronto tra errori umani commessi in un determinato processo di sviluppo e difetti nell'oggetto, come conseguenza di errori nelle specifiche del progetto, nei modelli di programma;
verifica e protezione dagli errori in tutte le fasi del ciclo di vita, nonché rilevamento dei difetti in ogni fase di sviluppo;
confronto di difetti e guasti nel software per sviluppare un sistema di interconnessioni e metodi per localizzare, raccogliere e analizzare informazioni su guasti e difetti;
sviluppo di approcci ai processi di documentazione e test del software.

L'obiettivo finale della causazione errore-fallimento è definire metodi e mezzi per testare e rilevare errori di determinate classi, nonché criteri per completare il test su più set di dati; nell'individuare modalità per migliorare l'organizzazione del processo di sviluppo, test e manutenzione del software.

Ecco la seguente classificazione dei tipi di guasto:

hardware, in cui il software a livello di sistema non è utilizzabile;
informativo, causato da errori nei dati di input e nella trasmissione dei dati tramite canali di comunicazione, nonché guasto dei dispositivi di input (una conseguenza di guasti hardware);
ergonomico, causato da errori dell'operatore durante la sua interazione con la macchina (questo guasto è un guasto secondario e può portare a guasti informativi o funzionali);
software, se sono presenti errori nei componenti, ecc.

Alcuni errori possono essere il risultato di carenze nella definizione dei requisiti, nella progettazione, nella generazione del codice di output o nella documentazione. Vengono invece generati durante lo sviluppo di un programma o durante lo sviluppo delle interfacce dei singoli elementi del programma (violazione dell'ordine dei parametri, più o meno parametri, ecc.).

Fonti di errori.Errori possono essere generati durante lo sviluppo del progetto, dei componenti, del codice e della documentazione. Di norma vengono scoperti durante l'esecuzione o la manutenzione del software nei punti più inaspettati e diversi.

Alcuni errori in un programma possono essere il risultato di carenze nella definizione dei requisiti, nella progettazione, nella generazione del codice o nella documentazione. D'altra parte, gli errori vengono generati durante lo sviluppo di un programma o delle interfacce dei suoi elementi (ad esempio, quando viene violato l'ordine di impostazione dei parametri di comunicazione - meno o più di quanto richiesto, ecc.).

Il motivo degli errori è la mancata comprensione delle esigenze del cliente; specificazione imprecisa dei requisiti nei documenti di progetto, ecc. Ciò porta al fatto che vengono implementate alcune funzioni del sistema che non funzioneranno come proposto dal cliente. A questo proposito, viene effettuata una discussione congiunta tra il cliente e lo sviluppatore su alcuni dettagli dei requisiti per chiarirli.

Il team di sviluppo del sistema può anche modificare la sintassi e la semantica della descrizione del sistema. Tuttavia, alcuni errori potrebbero non essere rilevati (ad esempio, gli indici o i valori delle variabili di queste istruzioni sono impostati in modo errato).

Popolare nella categoria: