La verifica è il processo di controllo di un prodotto software. Il posto della verifica tra i processi di sviluppo del software Nei metodi di verifica del software
La verifica e l'attestazione si riferiscono ai processi di verifica e revisione in cui viene verificata la conformità. Software le sue specifiche e le esigenze del cliente. La verifica e la qualificazione copre l'intero ciclo vitale Software: iniziano nella fase di analisi dei requisiti e terminano con la verifica del codice del programma nella fase di test del prodotto finito sistema software.
Verifica e attestazione non sono la stessa cosa, anche se è facile confonderle. In breve, la differenza tra loro può essere definita come segue:
La verifica risponde alla domanda se il sistema è progettato correttamente;
La certificazione risponde alla domanda se il sistema funziona correttamente.
Secondo queste definizioni, la verifica controlla che il software sia conforme alle specifiche del sistema, in particolare ai requisiti funzionali e non funzionali. Certificazione - altro processo generale. Durante la convalida, è necessario assicurarsi che il prodotto software soddisfi le aspettative del cliente. La convalida viene eseguita dopo la verifica al fine di determinare in che modo il sistema soddisfa non solo le specifiche, ma anche le aspettative del cliente.
Come notato in precedenza, la convalida dei requisiti di sistema è molto importante nelle prime fasi dello sviluppo del software. Ci sono spesso errori ed omissioni nei requisiti; in tali casi prodotto finale, probabilmente non soddisferà le aspettative del cliente. Ma, naturalmente, la convalida dei requisiti non può rivelare tutti i problemi nella specifica dei requisiti. A volte le lacune e gli errori nei requisiti vengono scoperti solo dopo che l'implementazione del sistema è stata completata.
I processi di verifica e validazione utilizzano due tecniche principali per il controllo e l'analisi dei sistemi.
1. Ispezione del software. Analisi e convalida di varie viste del sistema, come documentazione delle specifiche dei requisiti, diagrammi architetturali o codice sorgente programmi. L'ispezione viene eseguita in tutte le fasi del processo di sviluppo del sistema software. Parallelamente all'ispezione, può essere eseguita l'analisi automatica del codice sorgente dei programmi e dei relativi documenti. L'ispezione e l'analisi automatizzata sono metodi di verifica statica e validazione perché non richiedono un sistema eseguibile.
2. Test del software. Esecuzione di codice eseguibile con dati di test ed esame di output e prestazioni prodotto software per verificare il corretto funzionamento del sistema. Il test è un metodo dinamico di verifica e convalida perché viene applicato al sistema in esecuzione.
Sulla fig. La Figura 20.1 mostra il luogo dell'ispezione e del test nel processo di sviluppo del software. Le frecce indicano le fasi del processo di sviluppo in cui questi metodi possono essere applicati. Secondo questo schema, l'ispezione può essere eseguita in tutte le fasi del processo di sviluppo del sistema e il test - quando viene creato un prototipo o un programma eseguibile.
I metodi di ispezione includono: ispezione del programma, analisi automatica del codice sorgente e verifica formale. Ma i metodi statici possono solo controllare la conformità dei programmi alle specifiche, non possono essere utilizzati per controllare il corretto funzionamento del sistema. Inoltre, le caratteristiche non funzionali come le prestazioni e l'affidabilità non possono essere testate con metodi statici. Pertanto, per valutare le caratteristiche non funzionali, viene eseguito il test del sistema.
Riso. 20.1. Verifica e attestazione statica e dinamica
Nonostante l'uso diffuso dell'ispezione del software, il test è ancora il metodo predominante di verifica e certificazione. Il test è una verifica del funzionamento di programmi con dati simili a quelli reali, che verranno elaborati durante il funzionamento del sistema. La presenza nel programma di difetti e incongruenze con i requisiti viene rilevata esaminando i dati di output e individuando tra di essi quelli anomali. I test vengono eseguiti durante la fase di implementazione del sistema (per verificare che il sistema soddisfi le aspettative degli sviluppatori) e dopo che la sua implementazione è stata completata.
Nelle varie fasi del processo di sviluppo del software, diversi tipi test.
1. Test dei difetti condotto per rilevare incongruenze tra il programma e le sue specifiche, che sono dovute a errori o difetti nei programmi. Tali test sono progettati per rilevare errori nel sistema e non per simularne il funzionamento.
2. Test statistici valuta le prestazioni e l'affidabilità dei programmi, nonché il funzionamento del sistema in varie modalità operative. I test sono progettati per simulare il funzionamento effettivo del sistema con dati di input reali. L'affidabilità del sistema è valutata dal numero di guasti rilevati nel lavoro dei programmi. Le prestazioni vengono valutate misurando il tempo di funzionamento totale e il tempo di risposta del sistema durante l'elaborazione dei dati di test.
l'obiettivo principale Verifica e qualificazione - per garantire che il sistema sia "adatto allo scopo". L'idoneità di un sistema software per lo scopo previsto non implica che sia assolutamente privo di errori. Piuttosto, il sistema dovrebbe essere ragionevolmente adatto agli scopi per i quali era destinato. Necessario validità della conformità dipende dallo scopo del sistema, dalle aspettative degli utenti e dalle condizioni di mercato per i prodotti software.
1. Scopo del software. Il livello di affidabilità della conformità dipende dalla criticità del software sviluppato secondo determinati criteri. Ad esempio, il livello di confidenza per i sistemi critici per la sicurezza dovrebbe essere significativamente più alto di quello per i sistemi software prototipo sviluppati per dimostrare qualche nuova idea.
2. Aspettative degli utenti. Va notato con tristezza che al momento la maggior parte degli utenti ha bassi requisiti per il software. Gli utenti sono così abituati ai guasti che si verificano durante l'esecuzione dei programmi che non ne sono sorpresi. Sono disposti a tollerare i guasti del sistema se i vantaggi dell'utilizzo superano gli svantaggi. Tuttavia, dall'inizio degli anni '90, la tolleranza degli utenti per i guasti nei sistemi software è andata gradualmente diminuendo. Recentemente, la creazione di sistemi inaffidabili è diventata quasi inaccettabile, quindi le società di sviluppo software devono prestare sempre più attenzione alla verifica e alla convalida del software.
3. Condizioni del mercato del software. Quando si valuta un sistema software, il venditore deve conoscere i sistemi concorrenti, il prezzo che l'acquirente è disposto a pagare per il sistema e il tempo di commercializzazione previsto per tale sistema. Se la società di sviluppo ha diversi concorrenti, è necessario determinare la data di ingresso del sistema nel mercato prima della fine del test e del debug completi, altrimenti i concorrenti potrebbero essere i primi ad entrare nel mercato. Se i clienti non desiderano acquistare il software su alto prezzo forse sono disposti a tollerare più errori di sistema. Nel determinare i costi del processo di verifica e qualificazione, tutti questi fattori devono essere presi in considerazione.
Di norma, gli errori vengono rilevati nel sistema durante la verifica e l'attestazione. Vengono apportate modifiche al sistema per correggere gli errori. Questo processo di debug solitamente integrato con altri processi di verifica e attestazione. Tuttavia, il test (o più in generale la verifica e la convalida) e il debugging sono processi diversi che hanno obiettivi diversi.
1. La verifica e la convalida sono il processo di rilevamento dei difetti in un sistema software.
2. Debug: il processo di localizzazione dei difetti (errori) e correzione (Fig. 20.2).
Riso. 20.2. Processo di debug
Non esistono metodi semplici per il debug dei programmi. I debugger esperti trovano i bug confrontando i modelli di output del test con l'output dei sistemi sottoposti a test. Per individuare un errore è necessaria la conoscenza dei tipi di errore, dei modelli di output, del linguaggio di programmazione e del processo di programmazione. La conoscenza del processo di sviluppo del software è molto importante. I debugger sono a conoscenza degli errori di programmazione più comuni (come l'incremento di un contatore). Tiene inoltre conto degli errori tipici di alcuni linguaggi di programmazione, ad esempio quelli associati all'uso dei puntatori nel linguaggio C.
Individuare i bug nel codice del programma non è sempre un processo semplice perché il bug non si trova necessariamente vicino al punto nel codice del programma in cui si è verificato il crash. Per isolare i bug, il debugger sviluppa test software aggiuntivi che aiutano a identificare l'origine del bug nel programma. Potrebbe essere necessario tracciare manualmente l'esecuzione del programma.
Gli strumenti di debug interattivi fanno parte di un insieme di strumenti di supporto del linguaggio integrati con il sistema di compilazione del codice. Forniscono uno speciale ambiente di esecuzione del programma attraverso il quale è possibile accedere alla tabella degli identificatori e da lì ai valori delle variabili. Gli utenti spesso controllano l'esecuzione di un programma in modo graduale, passando da un'istruzione all'altra in sequenza. Dopo l'esecuzione di ogni istruzione, vengono controllati i valori delle variabili e vengono identificati eventuali errori.
L'errore riscontrato nel programma viene corretto, dopodiché è necessario ricontrollare il programma. Per fare ciò, puoi ricontrollare il programma o ripetere il test precedente. Il retesting viene utilizzato per assicurarsi che le modifiche apportate al programma non introducano nuovi bug nel sistema, perché in pratica un'alta percentuale di "correzioni di bug" o non si completano completamente o introducono nuovi bug nel programma.
In linea di principio, è necessario eseguire nuovamente tutti i test durante la ripetizione del test dopo ogni correzione, ma in pratica questo approccio è troppo costoso. Pertanto, durante la pianificazione del processo di test, vengono determinate le dipendenze tra le parti del sistema e vengono assegnati i test per ciascuna parte. Quindi è possibile tracciare gli elementi del programma utilizzando casi di test speciali (dati di controllo) selezionati per questi elementi. Se i risultati della traccia sono documentati, solo un sottoinsieme del set totale di dati di test può essere utilizzato per testare l'elemento di programma modificato ei suoi componenti dipendenti.
Pianificazione per la verifica e l'attestazione
La verifica e la convalida sono un processo costoso. Per i sistemi di grandi dimensioni, come i sistemi in tempo reale con complessi vincoli non funzionali, metà del budget di sviluppo del sistema viene speso per il processo di verifica e convalida. Pertanto, la necessità di un'attenta pianificazione di questo processo è evidente.
La pianificazione per la verifica e la convalida, come parte dello sviluppo dei sistemi software, dovrebbe iniziare il prima possibile. Sulla fig. La Figura 20.3 mostra un modello di sviluppo software che tiene conto del processo di pianificazione dei test. È qui che inizia la pianificazione già nelle fasi di specifica e progettazione del sistema. Questo modello è talvolta indicato come modello a V (per vedere la V, ruotare la Figura 20.3 di 90°). Questo diagramma mostra anche la suddivisione del processo di verifica e attestazione in più fasi, con i test corrispondenti eseguiti in ciascuna fase.
Riso. 20.3. Pianificazione dei test durante lo sviluppo e il test
Nel processo di pianificazione della verifica e della certificazione, è necessario determinare la relazione tra metodi statici e dinamici per il controllo del sistema, determinare standard e procedure per l'ispezione e il test del software, approvare mappa tecnologica revisione del software (vedere Sezione 19.2) e sviluppo di un piano di test del software. L'importanza dell'ispezione o del collaudo dipende dal tipo di sistema sviluppato e dall'esperienza dell'organizzazione. Quanto più il sistema è critico, tanto più occorre prestare attenzione ai metodi di verifica statica.
Il piano di verifica e convalida si concentra sugli standard del processo di test piuttosto che sulla descrizione di test specifici. Questo piano non è solo una guida, è destinato principalmente ai professionisti dello sviluppo e del test del sistema. Il piano lo consente staff tecnico ottieni un quadro completo dei test di sistema e pianifica il tuo lavoro in questo contesto. Inoltre, il piano fornisce informazioni ai manager che hanno la responsabilità di garantire che il team di test disponga di tutto l'hardware e il software necessari.
Il piano di test non è un documento fisso. Dovrebbe essere rivisto regolarmente poiché i test dipendono dal processo di implementazione del sistema. Ad esempio, se l'implementazione di alcune parti del sistema non è stata completata, è impossibile testare l'assemblaggio del sistema. Pertanto, il piano deve essere rivisto periodicamente in modo che il personale addetto ai test possa essere utilizzato in altri lavori.
San Pietroburgo
Università Statale Elettrotecnica
Dipartimento di MOEM
per disciplina
"Processo di sviluppo del software"
"Verifica software"
San Pietroburgo
Scopo della verifica………………………………………………………………… pag. 3
Premessa……………………………………………………………….. pag. 3
Obiettivi Speciali e Generali………………………………………….. pag. 4
Prassi prevista per target……………………………………… pag. 4
SG1 Preparazione alla verifica…………………………………………………..... pag. 4
SG2 Svolgimento esami (peer assessment)………………………… pag. 7
SG3 Attuazione della verifica………………………………………………..... pag. 9
Appendice 1. Panoramica degli strumenti di automazione per il processo di verifica……….. pagina 11
Allegato 2. Principale approcci moderni alla verifica…………….. pag. 12
Elenco della letteratura utilizzata……………………………………………….. pag. 14
Un modello integrato di eccellenza e maturità
Verifica (livello di maturità 3)
Bersaglio
Lo scopo della verifica è fornire la garanzia che il middleware selezionato o il prodotto finale soddisfi i requisiti specificati.
note d'acqua
La verifica dei prodotti software è verifica del prodotto finito o delle sue versioni intermedie per soddisfare i requisiti originari. Ciò implica non solo testare il programma stesso, ma anche controllare il progetto, l'utente e la documentazione tecnica, ecc.
Lo scopo della verifica del sistema software è identificare e segnalare gli errori che possono essere commessi durante le fasi del ciclo di vita. Principali compiti di verifica:
determinare la conformità dei requisiti di alto livello con i requisiti di sistema;
tenendo conto dei requisiti di alto livello nell'architettura del sistema;
rispetto dell'architettura e dei relativi requisiti nel codice sorgente;
determinare la conformità del codice eseguibile ai requisiti del sistema;
determinazione dei mezzi utilizzati per risolvere i compiti di cui sopra, che sono tecnicamente corretti e sufficientemente completi.
La verifica include la verifica dei prodotti finiti e la verifica dei prodotti intermedi rispetto a tutti i requisiti selezionati, inclusi i requisiti del cliente, i requisiti per i prodotti finiti e i requisiti per i suoi singoli componenti.
La verifica è intrinsecamente un processo incrementale (incrementale) dal momento del suo inizio attraverso lo sviluppo dei prodotti e tutto il lavoro sui prodotti. La verifica inizia con la verifica dei requisiti, quindi segue la verifica di tutti i prodotti intermedi nelle varie fasi del loro sviluppo e fabbricazione e termina con la verifica del prodotto finale.
La verifica dei prodotti intermedi in ogni fase del loro sviluppo e fabbricazione aumenta significativamente la probabilità che il prodotto finale soddisfi i requisiti del cliente, i requisiti del prodotto finito e i requisiti dei suoi singoli componenti.
La Verifica e la Validazione dei processi sono essenzialmente processi correlati, finalizzati però ad ottenere risultati diversi. Lo scopo della convalida è dimostrare che il prodotto finito soddisfa effettivamente il suo scopo originale. La verifica ha lo scopo di assicurarsi che il prodotto soddisfi esattamente determinati requisiti. In altre parole, Verification garantisce che “ lo fai bene", e la convalida è che" stai facendo la cosa giusta”.
La verifica dovrebbe essere implementata il prima possibile nei processi pertinenti (come la consegna, lo sviluppo, il funzionamento o la manutenzione) per valutare l'efficacia in termini di costi e le prestazioni. Questo processo può includere analisi, verifica e test (testing).
Questo processo può essere eseguito con vari gradi di indipendenza degli esecutori. Il grado di indipendenza degli esecutori può essere distribuito sia tra diverse entità dell'organizzazione stessa, sia tra entità di un'altra organizzazione, con diversi gradi di distribuzione delle responsabilità. Questo processo è chiamato il processo verifica indipendente se l'organizzazione di implementazione è indipendente dal fornitore, dallo sviluppatore, dall'operatore o dai manutentori.
Valutazioni di esperti (competenza) sono una parte importante della verifica in quanto strumento consolidato per un'efficace eliminazione dei difetti. Un aspetto importante da ciò è la necessità di sviluppare una comprensione e una comprensione più approfondite delle versioni funzionanti del prodotto, nonché dei flussi di lavoro utilizzati per identificare possibili difetti e creare un'opportunità di miglioramento, se necessario.
Gli esami includono uno studio metodico del lavoro svolto da esperti al fine di identificare difetti e altre modifiche richieste.
I principali metodi di valutazione degli esperti sono:
ispezione
controllo strutturale end-to-end
Come sapete, i computer universali possono essere programmati per risolvere i problemi più diversi: questa è una delle loro caratteristiche principali, che ha un grande valore pratico. Uno stesso computer, a seconda di quale programma è nella sua memoria, è in grado di eseguire calcoli aritmetici, dimostrare teoremi e modificare testi, gestire il corso di un esperimento e creare un progetto per un'auto del futuro, giocare a scacchi e insegnare lingua straniera. Tuttavia, la soluzione di successo di tutti questi e molti altri problemi è possibile solo a condizione che programmi per computer non contengono errori che possono portare a risultati errati.
Si può affermare che il requisito dell'assenza di errori nel software è del tutto naturale e non necessita di giustificazione. Ma come puoi essere sicuro che non ci siano errori? La questione non è così semplice come potrebbe sembrare a prima vista.
I metodi informali per dimostrare la correttezza dei programmi includono debug e test, che sono una componente necessaria in tutte le fasi del processo di programmazione, sebbene non risolvano completamente il problema della correttezza. Gli errori significativi sono facili da trovare se si utilizzano le tecniche di debug appropriate (stampe di controllo, tracce).
Test Il processo di esecuzione di un programma con l'intenzione di trovare un errore piuttosto che confermare che il programma sia corretto. La sua essenza è la seguente. Il programma da testare viene eseguito ripetutamente con quegli input per i quali il risultato è noto in anticipo. Quindi il risultato ottenuto dalla macchina viene confrontato con quello atteso. Se in tutti i casi di test c'è una coincidenza di questi risultati, c'è una certa sicurezza che i calcoli successivi non porteranno a un risultato errato, ad es. che il programma originale funzioni correttamente.
Abbiamo già discusso il concetto di correttezza di un programma in termini di assenza di errori in esso. Da un punto di vista intuitivo, il programma sarà corretto se, a seguito della sua esecuzione, si raggiunge il risultato, con l'obiettivo di ottenere quello che il programma è stato scritto. Di per sé, il fatto che il programma sia terminato senza crash non dice nulla: è del tutto possibile che il programma faccia effettivamente qualcosa di completamente diverso da quello previsto. Errori di questo tipo possono verificarsi per vari motivi.
Di seguito, assumeremo che i programmi in discussione non contengano errori sintattici, pertanto, nel comprovare la loro correttezza, si presterà attenzione solo al lato contenuto della questione, relativo alla questione se questo obiettivo specifico sia raggiunto con l'aiuto di questo programma. L'obiettivo può essere considerato la ricerca di una soluzione al problema e il programma può essere considerato un modo per risolverlo. Il programma lo farà corretto, Se lei risolve il problema dato.
Il metodo per stabilire la correttezza dei programmi con mezzi rigorosi è noto come verifica del programma.
A differenza del test del programma, in cui vengono analizzate le proprietà dei singoli processi di esecuzione del programma, la verifica si occupa di con proprietà programmi.
Il metodo di verifica si basa sul presupposto che esista una documentazione di programma la cui conformità deve essere provata. La documentazione deve contenere:
specifica input-output (descrizione dei dati che non dipendono dal processo di elaborazione);
proprietà delle relazioni tra elementi di vettori di stato in punti selezionati del programma;
specifiche e proprietà dei sottocomponenti strutturali del programma;
specifica delle strutture dati in funzione del processo di elaborazione.
Questo metodo per dimostrare la correttezza dei programmi è Metodo delle affermazioni induttive, formulato indipendentemente da K. Floyd e P. Naur.
L'essenza di questo metodo è la seguente:
1) vengono formulate istruzioni di input e output: l'istruzione di input descrive tutte le condizioni di input necessarie per il programma (o frammento di programma), l'istruzione di output descrive il risultato atteso;
2) supponendo che l'affermazione di input sia vera, viene costruita un'affermazione intermedia, che viene derivata in base alla semantica degli operatori situati tra l'input e l'output (dichiarazioni di input e output); tale affermazione è chiamata affermazione derivata;
3) si formula un teorema (condizioni di verifica):
l'istruzione di output segue dall'istruzione dedotta;
4) il teorema è dimostrato; la prova testimonia la correttezza del programma (frammento di programma).
La dimostrazione viene eseguita utilizzando metodi matematici ben sviluppati utilizzando il calcolo dei predicati del primo ordine.
Le condizioni di verifica possono anche essere costruite nella direzione opposta, cioè, supponendo che l'affermazione di output sia vera, ottenere l'affermazione di input e dimostrare il teorema:
l'istruzione di output segue dall'istruzione di input.
Questo metodo di costruzione delle condizioni di verifica simula l'esecuzione del programma nella direzione opposta. In altre parole, le condizioni di verifica dovrebbero rispondere alla seguente domanda: se qualche affermazione è vera dopo l'esecuzione dell'istruzione del programma, allora quale affermazione deve essere vera prima dell'affermazione?
La costruzione di enunciati induttivi aiuta a formalizzare intuizioni sulla logica del programma. È il più difficile nel processo di dimostrare la correttezza del programma. Ciò è spiegato, in primo luogo, dal fatto che è necessario descrivere tutte le condizioni sostanziali e, in secondo luogo, dal fatto che è necessaria una descrizione assiomatica della semantica del linguaggio di programmazione.
Un passaggio importante nel processo di prova è la prova della chiusura del programma, per la quale è sufficiente un ragionamento informale.
Pertanto, l'algoritmo per dimostrare la correttezza del programma con il metodo delle asserzioni induttive è presentato nella seguente forma:
1) Costruisci la struttura del programma.
2) Scrivi le istruzioni di input e output.
3) Formulare affermazioni induttive per tutti i cicli.
4) Crea un elenco di percorsi selezionati.
5) Costruire le condizioni di verifica.
6) Dimostrare la condizione di verifica.
7) Dimostrare che l'esecuzione del programma terminerà.
Questo metodo è paragonabile al normale processo di lettura del testo del programma (il metodo di controllo end-to-end). La differenza sta nel grado di formalizzazione.
Il vantaggio della verifica è che il processo di prova è così formalizzato da poter essere eseguito su un computer. In questa direzione negli anni ottanta sono state condotte ricerche, sono stati creati anche sistemi di dialogo automatizzati, ma non hanno trovato applicazione pratica.
Per un sistema di dialogo automatizzato, il programmatore deve specificare affermazioni induttive nel linguaggio del calcolo dei predicati. La sintassi e la semantica di un linguaggio di programmazione devono essere memorizzate nel sistema sotto forma di assiomi nel linguaggio del calcolo dei predicati. Il sistema dovrebbe determinare i percorsi nel programma e costruire le condizioni di verifica.
Il componente principale del sistema di dimostrazione è il generatore di condizioni di verifica, che contiene operazioni per manipolare predicati, algoritmi per interpretare le istruzioni del programma. Il secondo componente del sistema è il sottosistema per la dimostrazione di teoremi.
Notiamo le difficoltà associate al metodo delle asserzioni induttive. È difficile costruire "un insieme di assiomi di base, abbastanza limitato da evitare contraddizioni, ma abbastanza ricco da servire come punto di partenza per dimostrare affermazioni sui programmi" (E. Dijkstra). La seconda difficoltà è semantica, consistente nella formazione degli enunciati stessi da provare. Se il problema per il quale è scritto il programma non ha una rigorosa descrizione matematica, allora è più difficile formulare condizioni di verifica per esso.
I metodi elencati hanno una cosa in comune: considerano il programma come un oggetto già esistente e poi ne provano la correttezza.
Il metodo formulato da K. Hoare e E. Dijkstra si basa sulla derivazione formale dei programmi dalla formulazione matematica del problema.
Verifica e validazione ( verifica e validazione-V& v) sono progettati per analizzare, verificare la corretta esecuzione e la conformità del software alle specifiche e ai requisiti del cliente. Questi metodi di controllo della correttezza dei programmi e dei sistemi significano rispettivamente:
- la verifica è la verifica della correttezza della creazione del sistema in conformità con le sue specifiche;
- La convalida è una verifica della correttezza del rispetto dei requisiti specificati per il sistema.
La verifica aiuta a trarre una conclusione sulla correttezza del sistema creato dopo il completamento della sua progettazione e sviluppo. La convalida consente di stabilire la fattibilità dei requisiti specificati e include una serie di azioni per ottenere i programmi e i sistemi corretti, vale a dire:
- procedure di pianificazione per il controllo e il controllo delle decisioni e dei requisiti di progettazione;
- fornire il livello di automazione della progettazione del programma con i mezzi CASE;
- verificare il corretto funzionamento dei programmi testando i metodi su set di target test;
- adattamento del prodotto all'ambiente operativo, ecc.
La convalida esegue queste attività esaminando e ispezionando le specifiche e gli output di progettazione nelle fasi del ciclo di vita per confermare che vi sia una corretta implementazione dei requisiti iniziali e che le condizioni e i vincoli specificati siano soddisfatti. I compiti di verifica e validazione comprendono il controllo della completezza, coerenza e univocità della specifica dei requisiti e della correttezza dello svolgimento delle funzioni del sistema.
La verifica e la convalida sono soggette a:
- i componenti principali del sistema;
- interfacce di componenti (software, tecniche e informative) e interazioni di oggetti (protocolli e messaggi) che assicurano l'implementazione del sistema in ambienti distribuiti;
- modalità di accesso al database e ai file (transazioni e messaggi) e verifica dei mezzi di protezione contro l'accesso non autorizzato ai dati di diversi utenti;
- documentazione per il software e per il sistema nel suo complesso;
- test, procedure di test e dati di input.
In altre parole, i principali metodi sistematici di correttezza del programma sono:
- verifica Componenti PS e convalida delle specifiche dei requisiti;
- Ispezione PS stabilire la conformità del programma alle specifiche date;
- test codice di output del PS sui dati di test in un ambiente operativo specifico per identificare errori e difetti causati da vari difetti, anomalie, guasti delle apparecchiature o crash del sistema (vedere Capitolo 9).
ISO/IEC 3918-99 e 12207 includono processi di verifica e convalida. Per loro vengono definiti obiettivi, compiti e azioni per verificare la correttezza del prodotto creato (comprese le lavorazioni, i prodotti intermedi) nelle fasi del ciclo di vita e la conformità ai suoi requisiti.
Il compito principale dei processi di verifica e convalida è quello di controlla e conferma che il software finale sia adatto allo scopo e soddisfi i requisiti del cliente. Questi processi consentono di identificare errori nei prodotti di lavoro delle fasi del ciclo di vita, senza scoprire i motivi del loro verificarsi, nonché di stabilire la correttezza del software in relazione alle sue specifiche.
Questi processi sono correlati e sono definiti da un termine: "verifica e convalida" (V&V 7).
La verifica viene eseguita:
- verifica della correttezza della traduzione dei singoli componenti nel codice di output, nonché delle descrizioni dell'interfaccia tracciando le relazioni dei componenti in conformità con i requisiti specificati dal cliente;
- analisi della correttezza degli accessi ad archivi o banche dati, tenuto conto delle procedure adottate negli strumenti di sistema utilizzati per la manipolazione dei dati e la trasmissione dei risultati;
- verifica dei mezzi di protezione dei componenti per la rispondenza ai requisiti del cliente e loro rintracciabilità.
Dopo aver verificato i singoli componenti del sistema, viene effettuata la loro integrazione, nonché la verifica e la validazione del sistema integrato. Il sistema viene testato su una pluralità di suite di test per determinare se le suite di test sono adeguate e sufficienti per completare il test e stabilire la correttezza del sistema.
L'idea di creare un progetto internazionale sulla verifica formale è stata proposta da T. Hoare, è stata discussa in un simposio sul software verificato nel febbraio 2005 in California. Poi, nell'ottobre dello stesso anno, alla conferenza IFIP di Zurigo, è stato adottato un progetto internazionale per un periodo di 15 anni per sviluppare un "insieme olistico automatizzato di strumenti per il controllo della correttezza del PS".
Ha formulato i seguenti compiti principali:
- sviluppo di una teoria unificata di costruzione e analisi dei programmi;
- costruire un insieme completo e integrato di strumenti di verifica per tutti fasi di produzione, compreso lo sviluppo di specifiche e la loro verifica, la generazione di casi di test, il perfezionamento, l'analisi e la verifica dei programmi;
- creazione di un repository di specifiche formali e oggetti software verificati tipi diversi e tipologie.
IN questo progetto Si presume che la verifica riguarderà tutti gli aspetti della creazione e del controllo della correttezza del software e diventerà una panacea per tutti i problemi associati al costante verificarsi di errori nei programmi creati.
Molti metodi formali per dimostrare e verificare programmi specifici sono stati testati nella pratica. Molto lavoro è stato svolto dal comitato internazionale ISO/IEC all'interno del Norma ISO/ IEC 12207:2002 sulla standardizzazione dei processi di verifica e validazione del software. Il controllo della correttezza con metodi formali di diversi oggetti di programmazione è promettente.
Il repository è un repository di programmi, specifiche e strumenti utilizzati nello sviluppo e test, valutazione di componenti finiti, strumenti e metodi grezzi. Ha i seguenti compiti generali:
- accumulo di specifiche verificate, metodi di prova, oggetti di programma e implementazioni di codice per applicazioni complesse;
- accumulo di vari metodi di verifica, loro progettazione in una forma adatta alla ricerca e alla selezione di un'idea teorica realizzata per un'ulteriore applicazione;
- sviluppo di moduli standard per l'impostazione e lo scambio di specifiche formali di vari oggetti di programmazione, nonché strumenti e sistemi già pronti;
- sviluppo di meccanismi di interoperabilità e interazione per trasferire prodotti finiti verificati dal repository a nuovi ambienti distribuiti e di rete per creare nuovi PS.
Questo progetto dovrebbe essere sviluppato entro 50 anni. I progetti precedenti si prefiggevano obiettivi simili: migliorare la qualità del software, formalizzare i modelli di servizio, ridurre la complessità attraverso l'uso di PIC, creare strumenti di debug per diagnosticare visivamente gli errori ed eliminarli, ecc. Il processo di sviluppo continua.
Un nuovo progetto internazionale di verifica del software richiede ai suoi partecipanti non solo la conoscenza aspetti teorici specifiche del programma, ma anche programmatori altamente qualificati per la sua attuazione nei prossimi anni.
20. Verifica e convalida del software
La verifica e la convalida si riferiscono ai processi di verifica e analisi che verificano che il software sia conforme alle specifiche e ai requisiti del cliente. La verifica e la convalida coprono l'intero ciclo di vita del software: iniziano nella fase di analisi dei requisiti e terminano con la verifica del codice del programma nella fase di test del sistema software finito.
Verifica e attestazione non sono la stessa cosa, anche se è facile confonderle. In breve, la differenza tra loro può essere definita come segue:
La verifica risponde alla domanda se il sistema è progettato correttamente;
La certificazione risponde alla domanda se il sistema funziona correttamente.
Secondo queste definizioni, la verifica controlla che il software sia conforme alle specifiche del sistema, in particolare ai requisiti funzionali e non funzionali. La certificazione è un processo più generale. Durante la convalida, è necessario assicurarsi che il prodotto software soddisfi le aspettative del cliente. La convalida viene eseguita dopo la verifica al fine di determinare in che modo il sistema soddisfa non solo le specifiche, ma anche le aspettative del cliente.
Come notato in precedenza, la convalida dei requisiti di sistema è molto importante nelle prime fasi dello sviluppo del software. Ci sono spesso errori ed omissioni nei requisiti; in tali casi, il prodotto finale probabilmente non soddisferà le aspettative del cliente. Ma, naturalmente, la convalida dei requisiti non può rivelare tutti i problemi nella specifica dei requisiti. A volte le lacune e gli errori nei requisiti vengono scoperti solo dopo che l'implementazione del sistema è stata completata.
I processi di verifica e validazione utilizzano due tecniche principali per il controllo e l'analisi dei sistemi.
1. Ispezione del software. Analisi e verifica di varie rappresentazioni del sistema, come la documentazione delle specifiche dei requisiti, i diagrammi architetturali o il codice sorgente del programma. L'ispezione viene eseguita in tutte le fasi del processo di sviluppo del sistema software. Parallelamente all'ispezione, può essere eseguita l'analisi automatica del codice sorgente dei programmi e dei relativi documenti. L'ispezione e l'analisi automatizzata sono metodi di verifica statica e validazione perché non richiedono un sistema eseguibile.
2. Test del software. Esecuzione di codice eseguibile con dati di test ed esame dell'output e delle prestazioni del prodotto software per verificare che il sistema funzioni correttamente. Il test è un metodo dinamico di verifica e convalida perché viene applicato al sistema in esecuzione.
Sulla fig. La Figura 20.1 mostra il luogo dell'ispezione e del test nel processo di sviluppo del software. Le frecce indicano le fasi del processo di sviluppo in cui questi metodi possono essere applicati. Secondo questo schema, l'ispezione può essere eseguita in tutte le fasi del processo di sviluppo del sistema e il test - quando viene creato un prototipo o un programma eseguibile.
I metodi di ispezione includono: ispezione del programma, analisi automatica del codice sorgente e verifica formale. Ma i metodi statici possono solo controllare la conformità dei programmi alle specifiche, non possono essere utilizzati per controllare il corretto funzionamento del sistema. Inoltre, le caratteristiche non funzionali come le prestazioni e l'affidabilità non possono essere testate con metodi statici. Pertanto, per valutare le caratteristiche non funzionali, viene eseguito il test del sistema.
Riso. 20.1. Verifica e attestazione statica e dinamica
Nonostante l'uso diffuso dell'ispezione del software, il test è ancora il metodo predominante di verifica e certificazione. Il test è una verifica del funzionamento di programmi con dati simili a quelli reali, che verranno elaborati durante il funzionamento del sistema. La presenza nel programma di difetti e incongruenze con i requisiti viene rilevata esaminando i dati di output e individuando tra di essi quelli anomali. I test vengono eseguiti durante la fase di implementazione del sistema (per verificare che il sistema soddisfi le aspettative degli sviluppatori) e dopo che la sua implementazione è stata completata.
Diversi tipi di test vengono utilizzati in diverse fasi del processo di sviluppo del software.
1. Test dei difetti condotto per rilevare incongruenze tra il programma e le sue specifiche, che sono dovute a errori o difetti nei programmi. Tali test sono progettati per rilevare errori nel sistema e non per simularne il funzionamento.
2. Test statistici valuta le prestazioni e l'affidabilità dei programmi, nonché il funzionamento del sistema in varie modalità operative. I test sono progettati per simulare il funzionamento effettivo del sistema con dati di input reali. L'affidabilità del sistema è valutata dal numero di guasti rilevati nel lavoro dei programmi. Le prestazioni vengono valutate misurando il tempo di funzionamento totale e il tempo di risposta del sistema durante l'elaborazione dei dati di test.
Lo scopo principale della verifica e della qualificazione è assicurarsi che il sistema sia "adatto allo scopo". L'idoneità di un sistema software per lo scopo previsto non implica che sia assolutamente privo di errori. Piuttosto, il sistema dovrebbe essere ragionevolmente adatto agli scopi per i quali era destinato. Necessario validità della conformità dipende dallo scopo del sistema, dalle aspettative degli utenti e dalle condizioni di mercato per i prodotti software.
1. Scopo del software. Il livello di affidabilità della conformità dipende dalla criticità del software sviluppato secondo determinati criteri. Ad esempio, il livello di confidenza per i sistemi critici per la sicurezza dovrebbe essere significativamente più alto di quello per i sistemi software prototipo sviluppati per dimostrare qualche nuova idea.
2. Aspettative degli utenti. Va notato con tristezza che al momento la maggior parte degli utenti ha bassi requisiti per il software. Gli utenti sono così abituati ai guasti che si verificano durante l'esecuzione dei programmi che non ne sono sorpresi. Sono disposti a tollerare i guasti del sistema se i vantaggi dell'utilizzo superano gli svantaggi. Tuttavia, dall'inizio degli anni '90, la tolleranza degli utenti per i guasti nei sistemi software è andata gradualmente diminuendo. Recentemente, la creazione di sistemi inaffidabili è diventata quasi inaccettabile, quindi le società di sviluppo software devono prestare sempre più attenzione alla verifica e alla convalida del software.
3. Condizioni del mercato del software. Quando si valuta un sistema software, il venditore deve conoscere i sistemi concorrenti, il prezzo che l'acquirente è disposto a pagare per il sistema e il tempo di commercializzazione previsto per tale sistema. Se la società di sviluppo ha diversi concorrenti, è necessario determinare la data di ingresso del sistema nel mercato prima della fine del test e del debug completi, altrimenti i concorrenti potrebbero essere i primi ad entrare nel mercato. Se i clienti non sono disposti ad acquistare software a un prezzo elevato, potrebbero essere disposti a tollerare più errori di sistema. Nel determinare i costi del processo di verifica e qualificazione, tutti questi fattori devono essere presi in considerazione.
Di norma, gli errori vengono rilevati nel sistema durante la verifica e l'attestazione. Vengono apportate modifiche al sistema per correggere gli errori. Questo processo di debug solitamente integrato con altri processi di verifica e attestazione. Tuttavia, il test (o più in generale la verifica e la convalida) e il debugging sono processi diversi che hanno obiettivi diversi.
1. La verifica e la convalida sono il processo di rilevamento dei difetti in un sistema software.
2. Debug: il processo di localizzazione dei difetti (errori) e correzione (Fig. 20.2).
Riso. 20.2. Processo di debug
Non esistono metodi semplici per il debug dei programmi. I debugger esperti trovano i bug confrontando i modelli di output del test con l'output dei sistemi sottoposti a test. Per individuare un errore è necessaria la conoscenza dei tipi di errore, dei modelli di output, del linguaggio di programmazione e del processo di programmazione. La conoscenza del processo di sviluppo del software è molto importante. I debugger sono a conoscenza degli errori di programmazione più comuni (come l'incremento di un contatore). Tiene inoltre conto degli errori tipici di alcuni linguaggi di programmazione, ad esempio quelli associati all'uso dei puntatori nel linguaggio C.
Individuare i bug nel codice del programma non è sempre un processo semplice perché il bug non si trova necessariamente vicino al punto nel codice del programma in cui si è verificato il crash. Per isolare i bug, il debugger sviluppa test software aggiuntivi che aiutano a identificare l'origine del bug nel programma. Potrebbe essere necessario tracciare manualmente l'esecuzione del programma.
Gli strumenti di debug interattivi fanno parte di un insieme di strumenti di supporto del linguaggio integrati con il sistema di compilazione del codice. Forniscono uno speciale ambiente di esecuzione del programma attraverso il quale è possibile accedere alla tabella degli identificatori e da lì ai valori delle variabili. Gli utenti spesso controllano l'esecuzione di un programma in modo graduale, passando da un'istruzione all'altra in sequenza. Dopo l'esecuzione di ogni istruzione, vengono controllati i valori delle variabili e vengono identificati eventuali errori.
L'errore riscontrato nel programma viene corretto, dopodiché è necessario ricontrollare il programma. Per fare ciò, puoi ricontrollare il programma o ripetere il test precedente. Il retesting viene utilizzato per assicurarsi che le modifiche apportate al programma non introducano nuovi bug nel sistema, perché in pratica un'alta percentuale di "correzioni di bug" o non si completano completamente o introducono nuovi bug nel programma.
In linea di principio, è necessario eseguire nuovamente tutti i test durante la ripetizione del test dopo ogni correzione, ma in pratica questo approccio è troppo costoso. Pertanto, durante la pianificazione del processo di test, vengono determinate le dipendenze tra le parti del sistema e vengono assegnati i test per ciascuna parte. Quindi è possibile tracciare gli elementi del programma utilizzando casi di test speciali (dati di controllo) selezionati per questi elementi. Se i risultati della traccia sono documentati, solo un sottoinsieme del set totale di dati di test può essere utilizzato per testare l'elemento di programma modificato ei suoi componenti dipendenti.
Popolare
- Creare un brand da zero: l'esperienza dei marketer
- SMM (SMM) Social media marketing
- Metodo di rotazione nelle vendite, esempi
- Notevoli imprenditori
- Come aprire da zero un centro di sviluppo per bambini
- Come aprire una stazione di servizio: un business di seri investimenti e profitti
- Come aprire un centro di sviluppo per bambini
- Alcuni consigli su cosa vendere per guadagnare
- Attrezzature per il negozio di prodotti di carne semilavorati
- Azienda di spedizioni: come aprire un'attività da zero