Come testare correttamente una sostituzione completa del software

Question

Come testare correttamente una sostituzione completa del software

#1 da (3 voti)

3

Il Sistema A (un'applicazione e un database) è stato creato per un reparto aziendale specifico e, pertanto, ha un modello di dati e una struttura di tabelle allineati all'azienda. Il sistema A è un'applicazione mission-critical.
I sistemi a valle, come parte dei loro flussi di elaborazione aziendale, recuperano i dati dal sistema A tramite stored procedure
Abbiamo sviluppato il Sistema B che ha un modello di dati e una struttura di tabelle più generici per sostituire il Sistema A. Il Sistema B ha lo scopo di servire anche altri dipartimenti aziendali. Una volta che il sistema B diventa attivo, i sistemi downstream del sistema A reindirizzano la connessione del database al sistema B.
La stored procedure utilizzata dai sistemi downstream del sistema A è stata anche riscritta nel sistema B. Le firme (parametri di input e set di risultati restituiti) delle stored procedure sono state mantenute per non influire sui sistemi downstream che recuperano i dati Sistema A.

Quali sarebbero i test richiesti per il sistema B? Ecco i miei pensieri:

Per garantire completamente che tutte le funzionalità e la logica aziendale del sistema A siano state implementate e implementate correttamente nel sistema B, tutti i test case del sistema A devono essere eseguiti nel sistema B
I sistemi a valle dovrebbero testare tutti i flussi di elaborazione aziendale che sono interessati dalla riscrittura della stored procedure.

Un architetto sta spingendo che non è necessario che i sistemi a valle eseguano il # 2 e che solo lo scrutatore effettivo (in quanto le firme delle stored procedure non dovrebbero eseguire solo un test completo di scatola nera / scatola bianca / unità) sono cambiati). È un approccio logico per testare le stored procedure o questo metodo di prova è difettoso?

Qualche idea sull'approccio di test sopra soprattutto # 2?

testing unit-testing enterprise-architecture acceptance-testing functional-testing

posta rro 09.03.2016 - 15:04

fonte

1 risposta

Leggi altre domande sui tag testing unit-testing enterprise-architecture acceptance-testing functional-testing

Entity framework e Eager loading e enterprise application con approccio TDD Un oggetto può contenere una proprietà che è un altro oggetto?

score 3 · Answer 1

I am assuming that the test suite for System A has good test coverage.

Questo è forse una buona ipotesi. Ma sai cosa dicono delle ipotesi ...

Una domanda più fondamentale da porsi è: quali sono le implicazioni di errori o bug? La gravità dei bug (in termini di impatto sul business), la probabilità che vengano notati (un bug non notato che costa $ 1 a causa di errori di arrotondamento su una transazione che accade 100.000 volte al giorno è ... costoso), e l'abilità che devi risolvere in qualche modo lo impone.

Ad esempio, se tutti i casi di insuccesso saranno facilmente rilevati, risolti facilmente e avranno un impatto minimo sulla tua azienda, un test di integrazione completo è meno importante del contrario.

Questo non vuol dire che non dovresti preoccuparti dei bug. Ma se il tuo A - > B switch interesserà 50.000 dipendenti e potenzialmente li spegnerà per diversi giorni è molto più importante testare in modo completo di un sistema che interesserà 5 persone per pochi minuti alla volta.

Tutto questo per dire: il tuo impatto sull'attività reale dovrebbe guidare la tua decisione qui . Quindi per prima cosa determinalo.

Il mio punto di vista sarebbe che se hai un impatto aziendale non banale da eseguire attraverso i tuoi sistemi downstream serie completa di test di integrazione, supponendo che hai un buon modo per scambiare le dipendenze sul tuo database (questo è praticamente esattamente il tipo della situazione che lo rende desiderabile). Questa è probabilmente la situazione migliore: eseguire tutti questi test di integrazione sul nuovo sistema.

Assumendo impatti non banali sul business, probabilmente avrai una data "go live" definita. Per questo motivo suggerirei almeno alcuni test del sistema di integrazione prima di questa data su un sistema sandbox. Ancora una volta, a seconda dell'impatto sul business, proverei a identificare le transazioni chiave che hanno un impatto aziendale significativo e, perlomeno, controllarle.

Qualcosa che non vedo menzionato nella pianificazione del test sta verificando che il processo di migrazione dei dati abbia funzionato come previsto, quindi farei in modo di verificarlo in qualche modo. Potresti essere in grado di combinare ciò di cui hai bisogno per testare funzionalità e migrazione dei dati allo stesso tempo. Forse anche solo testando le query in A e B per verificare che abbiano risultati corrispondenti.