Come ingegnere e testare software mission-critical?

4

TL; DR : Il mio obiettivo è creare un framework con il quale potrei scoprire / testare tutti i possibili stati interni della mia applicazione in modo che possa avvicinarmi con sicurezza, ad esempio software di ingegneria per dispositivi medici, aerei ecc ...

Vorrei prima spiegare alcuni contesti ...

Stavo guardando il video sulla tecnica di mappatura di esempio interessante utilizzato in pratiche agili. Il video tratta di come esplorare lo spazio del dominio con esempi che stanno creando una mappa per lo spazio del dominio problematico. In parole più concrete hanno cercato di arrivare a modellare una soluzione per la user story: "prenotazione di un biglietto del treno". Dopo che la storia dell'utente è stata presentata, hanno regole o vincoli di layout per lo spazio della soluzione. Dopo di ciò, impaginano alcuni esempi di base in cui creano casi interessanti (esempi) in cui le entità dello spazio del dominio possono entrare ... Dalla sessione di brainstorming scoprono lo spazio dei problemi che prima non era noto e creavano domande come "cosa dovrebbe essere il sistema? fare se questo particolare stato può verificarsi ".

Ogni soluzione di programmazione che noi programmatori creiamo è essenzialmente quella di creare un comportamento per un elenco di casi d'uso. Molte volte non copriamo tutti gli stati in cui la nostra soluzione può entrare o perdiamo casi d'uso sconosciuti che stanno creando stati illegali e questo è il motivo per cui ulteriori interazioni stanno creando errori (comportamento indesiderato) del nostro sistema.

Quindi voglio incorporare test di simulazione di eventi discreti nella mia casella degli strumenti standard che analizzino il mio sistema nell'ambito della missione con la missione di esplorare lo spazio del problema e scoprire quel comportamento indesiderato. Molte volte è successo prima quando non avevo una conoscenza completa dello spazio del dominio che stavo imparando su quello spazio del dominio con la produzione di quegli errori, quindi l'utilizzo di alcuni test di simulazione di eventi discreti sarebbe un grande vantaggio per la mia pratica di ingegneria del software insieme a DDD e TDD .

Sono un grande fan di TDD ma spesso capita che non si copra tutti i casi a causa della conoscenza limitata del dominio ...

Quindi sto pensando di incorporare una qualche forma di framework di test white box in cui direi quali sono i vincoli input / output interni ed esterni per vari argomenti di input, chiamate database, chiamate di servizi esterni ecc ...) e il test il framework dovrebbe scoprire comportamenti inaspettati (bug, ecc ...) invece di creare tutti quei test di e2e che potrebbero essere coperti dal framework di test. E questa potrebbe essere una grande aggiunta al TDD ...

La mia domanda è come la NASA, ad esempio, testa il suo software di sistema a razzo? Devono incorporare qualche forma di simulazione di eventi discreti sul loro software in modo che siano sicuri di aver esplorato tutti gli stati in cui il sistema può entrare?

    
posta Uroš Jarc 01.12.2018 - 20:37
fonte

2 risposte

14

Ho lavorato in luoghi che producono software life-critical. Non "testiamo tutti i possibili stati interni". Invece noi:

  • Rivedi tutto il codice prima di accettarlo nel codice di base (vedi Peer Review & Revisione della sicurezza )
  • Verifica ogni lato di ogni limite nel nostro spazio di stato (vedi Boundary Testing )
  • Prova tutti i percorsi attraverso il codice (vedi Copertura del codice )
  • Verifica la leggibilità, la capacità di test e la correttezza del codice facendo in modo che i revisori peer integrino i test unitari degli autori con i propri (vedi Peer Testing )
  • Raccogli i requisiti verificabili che il controllo qualità può garantire siano stati soddisfatti.

Potrebbe sembrare una cascata, ma nella mia esperienza finché si può fare tutto ciò su una caratteristica minuscola entro due settimane, la gente si accontenta di chiamarla agile.

Personalmente mi piacciono gli sprint di una settimana, ma ogni squadra è diversa.

    
risposta data 02.12.2018 - 00:38
fonte
2

La risposta di @candied_orange è ottima. Inoltre, per prima cosa sono necessari buoni requisiti e test cases. Consiglio di dare un'occhiata al flusso di Cucumber e spec e simili per la comunicazione del dominio.

Di solito, i casi di test buoni e meticolosamente progettati, l'analisi chiara dei requisiti, la copertura del test% 100 nei test di unità e integrazione oltre ai casi limite e un codice ben documentato e pulito dovrebbero andare bene, anche per i sistemi vitali.

Se vuoi andare oltre, (cosa che fai sembra, nella tua nota "TL; DR") posso consigliare il test delle mutazioni. Fondamentalmente, consiste nel modificare casualmente il codice sorgente, il codice di test e le asserzioni, assicurandosi che i casi in conflitto con quelli inalterati non passino. È comunque necessario coprire manualmente tutti i casi limite. Questo metodo consente di identificare, ad esempio, le condizioni irrilevanti. Questo è un framework per java: link

    
risposta data 02.12.2018 - 03:25
fonte

Leggi altre domande sui tag