C'è un modo giusto per realizzare un miglioramento continuo (indurimento AKA software) processo?

StackOverflow https://stackoverflow.com/questions/1835622

Domanda

Ogni release sembra che i nostri clienti a trovare un paio di vecchi problemi con il nostro software. E lo fa apparire come ogni versione ha più bug, quando in realtà il nostro nuovo codice è generalmente solida.

Si è cercato di attuare alcune ulteriori test dove abbiamo tester fanno diverse ore di test di regressione mensile su una singola applicazione ogni mese, nel tentativo di stare al passo dei piccoli problemi. Ci riferiamo a questo processo come il nostro processo di indurimento Software, ma non sembra che stiamo recuperando abbastanza dei bug e ci si sente come un processo molto backburner poiché non v'è sempre nuovo codice da scrivere.

C'è un trucco a questo tipo di test? Ho bisogno di indirizzare una caratteristica specifica alla volta?

È stato utile?

Soluzione

Quando si sviluppano le procedure di collaudo, si consiglia di implementare questo tipo di test:

  • unit testing (test componenti invididual del progetto per testare la loro funzionalità), questi test sono importanti perché permettono di individuare in quale parte del software l'errore può venire da. In sostanza in queste prove si metterà alla prova una singola funzionalità e utilizzare gli oggetti mock per simulare il comportamento, valore di ritorno di altri oggetti / soggetti.

  • test di regressione, che lei ha citato

  • test di caratterizzazione, un esempio potrebbe essere in esecuzione automaticamente il programma sull'ingresso generato automaticamente (simulando l'input dell'utente), memorizzare i risultati e confronta i risultati di ogni versione contro questi risultati.

All'inizio questo sarà molto pesante da mettere in atto, ma con più uscite e più bug fix che viene aggiunto ai test di non regressione automatizzati, si dovrebbe essere iniziando a risparmiare tempo.

E 'molto importante che tu non cadere nella trappola di progettazione di un gran numero di test muti. Il test dovrebbe rendere la vita più facile, se si spendono comprensione troppo tempo in cui i test hanno rotto si dovrebbe ridisegnare i test, come ti danno messaggi migliori / comprensione del problema in modo da poter individuare il problema rapidamente.

A seconda del vostro ambiente, questi test possono essere collegati al processo di sviluppo.

Nel mio ambiente, usiamo SVN per il controllo delle versioni, un bot esegue i test contro ogni revisione e restituisce le prove di fallimento e messaggi con il nome della revisione, che spezzò e il contribuente (la sua login).

EDIT:

Nel mio ambiente, si usa una combinazione di C ++ e C # per fornire analisi utilizzati in finanza, il codice è stato C ++ ed è abbastanza vecchia, mentre stiamo cercando di migrare le interfacce verso C # e mantenere il nucleo delle analisi in C ++ ( soprattutto a causa di requisiti di velocità)

La maggior parte dei test del C ++ sono unit test scritto a mano e test di regressione.

Nella parte C # stiamo utilizzando NUnit per unit testing. Abbiamo un paio di test generale.

Abbiamo una politica di 0 avvertimenti, abbiamo esplicitamente vietare le persone a commettere il codice che sta generando avvisi a meno che possano giustificare il motivo per cui è utile per bypassare l'avviso per questa parte del codice. Abbiamo così convenzioni sulla sicurezza eccezioni, l'uso di modelli di progettazione e molti altri aspetti.

Impostazione esplicitamente le convenzioni e le best practice è un altro modo per migliorare la qualità del codice.

Altri suggerimenti

  

C'è un trucco a questo tipo di test?

Hai detto, "abbiamo tester fanno diverse ore di test di regressione mensile su una singola applicazione ogni mese, nel tentativo di stare al passo dei piccoli problemi."

Credo che per "test di regressione" intendi "esercitando manualmente antiche caratteristiche".

Si dovrebbe decidere se siete alla ricerca di vecchi bug che non sono mai stati trovati prima (il che significa, l'esecuzione di test che non hai mai eseguito prima); o , se si sta ripetendo i test eseguito in precedenza per verificare che la funzionalità precedentemente testato è invariato. Si tratta di due cose opposte.

"test di regressione" implica per me che si sta facendo la seconda.

Se il problema è che "i clienti a trovare un paio di vecchi problemi con il nostro software" allora o vostri clienti sono in esecuzione delle prove che non hai mai eseguito prima (in questo caso, per trovare questi problemi è necessario eseguire nuovo prove di vecchio software), o stanno trovando i bug che si sono precedente testato ed è risultato, ma che a quanto pare si mai aggiustata dopo che li ha trovati.

  

Ho bisogno di indirizzare una caratteristica specifica alla volta?

Che cosa stai cercando di fare, esattamente:

  • Trova i bug prima che i clienti li trovano?
  • convincere i clienti che c'è poco sbagliato con il nuovo di sviluppo?
  • trascorrere il minor tempo possibile sui test?

Molto consiglio generale è che i bug vivono in famiglie: in modo che quando si trova un bug, cercare i suoi genitori e fratelli e cugini, per esempio:

  • Si potrebbe avere questo esattamente lo stesso bug in altri moduli
  • Questo modulo potrebbe essere buggier rispetto ad altri moduli (scritto da somone in un giorno, forse), in modo da cercare ogni altro tipo di bug in questo modulo
  • Forse questo è uno di una classe di problemi (problemi di prestazioni, o problemi di bassa memoria) che suggerisce una intera area (o intero tipo di requisito) che necessita di una migliore copertura di test

Altro consiglio è che è a che fare con la gestione delle aspettative dei clienti: lei ha detto, "E lo fa apparire come ogni versione ha più bug, quando in realtà il nostro nuovo codice è generalmente solida", come se il vero problema è la percezione erronea che il bug è appena scritto.

  

ci si sente come un processo molto backburner poiché non v'è sempre nuovo codice per scrivere

develoment Software non avviene in background, su un bruciatore: o qualcuno sta lavorando su di esso, o non lo sono. La gestione deve decidere se assegnare a chiunque di questo compito (cioè cercare bug precedentemente-non trovati esistente o FIX-precedentemente-found-ma-non-ancora-segnalati bug), o se preferiscono concentrarsi sul nuovo sviluppo e lasciare che il i clienti fanno il bug-rilevamento.

Modifica Vale la pena ricordare che il test non è l'unico modo per trovare i bug. C'è anche:

  • informali revisioni di progetto (35%)
  • ispezioni di design di forma (55%)
  • recensioni informali del codice (25%)
  • ispezioni codice formale (60%)
  • controllo scrivania personale del Codice (40%)
  • Unità di prova (30%)
  • prova componente (30%)
  • test di integrazione (35%)
  • test della regressione (25%)
  • Test del sistema (40%)
  • basso volume di Beta test (<10 siti) (35%)
  • beta test-Alto volume (> 1000 siti) (70%)

La percentuale che ho messo accanto a ciascuna è una misura del tasso di difetto di rimozione per ogni tecnica (tratto da pagina 243 di McConnel di Software Stima libro). Le due tecniche più efficaci sembrano essere l'ispezione codice formale, e beta test ad alto volume.

Quindi potrebbe essere una buona idea di introdurre revisioni formali del codice:. Che potrebbe essere meglio a rilevare i difetti di test black-box è

Non appena i vostri scopi di codifica, in primo luogo si dovrebbe andare per l'unit testing. Vi si possono ottenere alcuni bug che dovrebbero essere fissati e si dovrebbe eseguire un altro round di test di unità da trovare se nuovi bug venuto o no. Dopo aver completato il test Unità si dovrebbe andare per i test funzionali.

Lei ha citato qui che il tester sta eseguendo test di regressione su base mensile e ancora ci sono vecchi bug in uscita. Quindi è meglio sedersi con il tester e rivedere i casi di test, come sento che hanno bisogno di essere aggiornato regolarmente. Anche durante la revisione mettere lo stress sul quale modulo o la funzionalità gli insetti stanno arrivando. Lo stress su quelle aree e aggiungere altri casi di test in quelle zone e aggiungere quelli nei vostri casi di test rgression modo che una volta nuova costruzione viene quei casi di test dovrebbero essere eseguiti.

Si può provare una cosa di più se il progetto è un lungo termine, allora si dovrebbe parlare con il tester per automatizzare i test di regressione. Essa vi aiuterà a eseguire i test in fase di fuori come la notte e il giorno successivo si ottengono i risultati. Anche i casi di test di regressione devono essere aggiornati come il problema maggiore arriva quando i test di regressione non vengono aggiornati regolarmente e eseguendo vecchi casi di test di regressione e di nuovi casi di test progressione si sta perdendo alcuni moduli che non sono testati.

C'è un gran parlare qui di test di unità e non ho potuto essere più d'accordo. Spero che Josh capisce che il test delle unità è un processo meccanizzato. Non sono d'accordo con il fatto che i PJ test di unità dovrebbe essere scritto prima di codifica l'applicazione e non dopo. Questo si chiama TDD o Test Driven Development.

Alcune persone scrivono test di unità che esercitano il codice livello intermedio ma trascurano testare il codice della GUI. Questo è imprudente. Si dovrebbe scrivere unit test per tutti i livelli nella vostra applicazione.

Dal test di unità sono anche il codice, c'è la questione del QA per la suite di test. È la copertura del codice buono? Ci sono falsi positivi / negativi errori nei test di unità? Stai provando per le cose giuste? Come assicurate la qualità del vostro processo di controllo qualità? In sostanza, la risposta a questo si riduce a peer review e dei valori culturali. Tutti i membri del team deve impegnarsi per una buona igiene test.

La prima un bug viene introdotto nel sistema, più a lungo rimane nel sistema, più difficile e più costoso è quello di rimuoverlo. È per questo che si dovrebbe guardare in quello che è conosciuto come l'integrazione continua. Quando è impostato correttamente, l'integrazione continua significa che il progetto viene compilato ed eseguito con la suite completa di test di unità, poco dopo il check-nelle modifiche per il giorno.

Se i test di compilazione o falliscano, e poi il codificatore incriminato e il maestro costruzione ottiene una notifica. Essi lavorano con il team guidato per determinare ciò che la correzione di rotta più appropriato dovrebbe essere. A volte è proprio così semplice come risolvere il problema e verificare la correzione in. Un maestro di build e piombo squadra ha bisogno di mettersi in gioco per identificare eventuali modelli globali che richiedono un intervento ulteriore. Ad esempio, una crisi familiare può causare la codifica di qualità di uno sviluppatore per toccare il fondo. Senza CI e qualche svista gestionale, potrebbe richiedere sei mesi di bug prima ti rendi conto che cosa sta succedendo e intraprendere azioni correttive.

Non hai parlato che cosa il vostro ambiente di sviluppo è. Se il vostro erano un negozio di J2EE, quindi vorrei suggerire che si guarda in quanto segue.

  • CruiseControl per l'integrazione continua
  • Subversion per il controllo delle versioni del codice sorgente perché si integra bene con CruiseControl
  • Primavera a causa DI rende più facile meccanizzare l'unità di test a scopo di integrazione continui
  • JUnit per unità di testare il livello intermedio
  • HttpUnit per unità di testare l'interfaccia grafica
  • jmeter per lo stress testing

Andando avanti e l'attuazione di una strategia di sperimentazione per (tutti) roba esistente è un dolore. E 'lungo, è difficile, e nessuno vorrà farlo. Tuttavia, vi consiglio vivamente come un nuovo bug entra, una prova di essere sviluppato intorno a quel bug. Se non si ottiene un bug report su di esso, allora o è (a) funziona o (b) l'utente non si preoccupa che non funziona. In entrambi i casi, un test è uno spreco di tempo.

Non appena la sua identificato, scrivere un test che va rossa . Proprio adesso. Poi correggere il bug. Confermare che venga fissata. Verificare che il test è ora verde . Ripetere come nuovi bug entrano.

Mi dispiace dire questo, ma forse sei solo non prova abbastanza, o troppo tardi, o entrambi.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top