Strategia di test per l'ambiente di produzione [chiuso]

Question

Strategia di test per l'ambiente di produzione [chiuso]

#1 da (6 voti)
#2 da (4 voti)

7

In un mondo ideale, gli sviluppatori / ops stanno lavorando insieme come una squadra per pubblicare qualcosa sulla produzione.

Tuttavia, ci sono organizzazioni con limitazioni in modo che gli ingegneri / team di rilascio siano tenuti completamente fuori dai team di sviluppo / progetto.

Questo non solo ha aggiunto il dolore alla comunicazione per le pubblicazioni, ma ha anche reso l'ambiente di produzione quasi "invisibile" al team di progetto. In una certa misura, c'è una "crisi di fiducia" tra il progetto e il team di implementazione.

Anche noi disponiamo di buoni e affidabili test di accettazione / funzionamento nell'ambiente UAT, ma non siamo sicuri che il processo di distribuzione sia stato eseguito correttamente e se tutto funziona esattamente come UAT. Quindi l'unico modo per verificarlo è attraverso alcuni test sull'ambiente di produzione.

Alcuni semplici test del fumo potrebbero essere utili per identificare i problemi di connettività.

Quindi la mia domanda è: qual è la tua opinione sull'applicazione di tutti i test che abbiamo avuto su UAT alla produzione (con la configurazione per disabilitare i bit che non vogliamo accadere in produzione come la rimozione di dati, ecc.)

Se hai fatto qualcosa di simile, come giochi i dati sull'ambiente di produzione senza che le tracce di audit siano macchiate (una cosa ovvia sarebbe basata sull'account, ma supponiamo che non vi sia una segregazione per account).

EDIT: non intendevo testare l'ambiente di produzione tutto il tempo, ma solo subito dopo la distribuzione. Inoltre non smetteremo di provare a risolvere il problema dalla relazione root - dev / op. Ma allo stesso tempo vorrebbe esplorare altre possibilità.

testing production acceptance-testing

posta user2001850 07.08.2014 - 00:21

fonte

2 risposte

Leggi altre domande sui tag testing production acceptance-testing

È considerata una cattiva pratica compilare in Javascript come una questione di preferenza linguistica? [chiuso] Esiste una teoria matematica o un modello dietro la progettazione dei linguaggi di programmazione

score 6 · Answer 1

Di solito, i test vengono eseguiti all'esterno dei server di produzione per tre motivi:

Sicurezza. Se qualcosa va storto e tutti i dati della messa in scena vengono rimossi accidentalmente, non ti interessa. Se succede in produzione, è ... diciamo fastidioso .
Prestazioni. Una vasta gamma di test può facilmente utilizzare la CPU al 100% su diversi server per diversi minuti. Non puoi permetterti di rallentare i server di produzione per alcuni minuti dieci volte all'ora.
Obiettivo. L'obiettivo del test è prevenire problemi di produzione. Se trovi un problema quando l'applicazione è già distribuita, è troppo tardi. Inoltre, tornare alla revisione precedente può essere complicato. Ad esempio, cosa succede se la nuova versione ha creato una colonna nel database e, nel frattempo, hai nuovi record in cui è stata utilizzata questa nuova colonna?

Per questi motivi, ti consiglio vivamente di non utilizzare l'ambiente di produzione per i test. Inoltre, non penso che l'esecuzione di test in produzione e l'invio dei risultati al tuo team contribuiranno a conquistare la fiducia degli amministratori di sistema; possono percepirlo come un tentativo di eludere le limitazioni che hanno impostato per proteggere la loro infrastruttura dalla tua squadra .

Invece, affronta il problema originale, ovvero la mancanza di fiducia tra sviluppatori e amministratori di sistema. Fino a quando i problemi di comunicazione e affidabilità non esistono a questo livello, il processo di test e distribuzione sarà doloroso, a prescindere dai trucchi che utilizzerai per renderlo più semplice.

score 4 · Answer 2

A patto che tu abbia implementato un robusto sistema di controllo della versione, estendi i test in modo tale che devi solo confermare la funzionalità di base.

Ad esempio i seguenti sono fatti nei quattro ambienti (semplificato per brevità):

DEV: test unitari, alcuni test comportamentali
FAT: test di integrazione, test di regressione, test di installazione
UAT: test di distribuzione su LIVE (possibilmente con dati falsi)
LIVE: funzionalità comuni, possibili test dell'ambiente

Ambiente DEV (sviluppo)

Il focus è sui test unitari per testare la nuova funzionalità, le correzioni dei bug e i test precedenti; alcuni test comportamentali possono essere eseguiti se richiesto per funzionalità nuove / modificate.

Ambiente FAT (Factory Acceptance Test)

Metti alla prova i tuoi programmi di installazione e permetti ai tuoi tester di eseguire l'applicazione e testare le nuove funzioni, le correzioni dei bug e assicurarti che la vecchia funzionalità non venga interrotta attraverso i test di regressione.

Ambiente UAT (User Acceptance Test)

I tuoi clienti / clienti / utenti verificano la tua applicazione per assicurarti che funzioni in base alle loro aspettative. Da notare che UAT dovrebbe essere identico a LIVE quindi ciò che funziona qui dovrebbe funzionare in LIVE.

Ambiente LIVE (Produzione)

Devi solo aggiornare la versione più recente e ricontrollare le basi (smoke-test): accedere ai dati, aprire report, visualizzare documenti, esportare / importare dati, ecc.

Quando il software raggiunge l'ambiente LIVE, ha passato tutti gli ambienti precedenti senza problemi, quindi non è necessario ripetere il test; se un qualsiasi ambiente non riesce, per qualsiasi motivo, la versione del software torna a DEV, vengono apportate modifiche e l'intero processo ricomincia con un nuovo numero di versione, ad es. 1.2.3.0 - > 1.2.3.1 .

Costruisci la fiducia nel tuo rilascio su LIVE passando attraverso ciascun ambiente e completando i test in modo che non sia necessario ripetere il test in LIVE.