Come testare lo stesso software su tutti i prodotti in una linea di prodotti?

7

Nel mio team abbiamo lavorato su un firmware per un prodotto. Il prodotto è stato rilasciato alcuni anni fa ma implementiamo ancora nuove funzionalità nel firmware e forniamo regolarmente un nuovo firmware per i nostri clienti. Recentemente abbiamo sviluppato un nuovo prodotto che utilizza lo stesso firmware del primo. Ovviamente, abbiamo dovuto cambiare il firmware per consentire alcune nuove funzionalità (mantenendo comunque intatte le funzionalità per il prodotto esistente).

Abbiamo una specifica del test di rilascio che contiene principalmente test manuali che eseguiamo prima di rilasciare nuovi software. Abbiamo adattato questo per il nuovo prodotto poiché ha funzionalità aggiuntive. Ma la maggior parte è comune.

So che i nuovi prodotti sono in cantiere e nel mio ragionamento semplicistico dobbiamo ripetere il nostro test di rilascio per ogni prodotto ogni volta che rilasciamo un firmware. Quindi sto cercando un nuovo approccio che richiede meno tempo. Una delle cose su cui stiamo già lavorando è l'automazione, ma a causa della natura del prodotto molti test devono essere manuali.

    
posta Vandhunden 02.01.2013 - 10:48
fonte

2 risposte

4

L'ambito più ampio dei test del software implica l'analisi di tutti i tuoi prodotti, piattaforme supportate e quindi l'identificazione di quali deve essere testato per fornire un particolare grado di sicurezza sui risultati.

L'aspetto più importante è document ciò che decidi e perché hai deciso che. Dovrai fornire tale documentazione ai tuoi clienti in modo che possano essere certi della tua procedura di test.

Per il tuo caso:

  1. Poiché ti stai espandendo, dovresti cercare la comunanza tra i prodotti e le versioni del firmware. Aspetti che sono veramente comuni non devono necessariamente essere testati su ogni singola piattaforma di destinazione. Un campione rappresentativo dovrebbe essere sufficiente.

  2. Fornisci una certa disciplina sul processo di rilascio in modo da poter capire cosa è cambiato tra le versioni. Se riesci a dimostrare che l'area funzionale XYZ non sarà influenzata da nessuna delle modifiche di questa versione, puoi eliminare o ridurre la quantità di test di quell'area. Il dominio del prodotto determinerà il punto di equilibrio tra l'eliminazione o la riduzione dei test per quel ciclo.

  3. Può essere costoso, ma prendere in considerazione l'aggiunta dell'automazione robotica ai processi di test. Tirare un cavo; premendo i pulsanti; lasciar cadere il dispositivo; ecc. possono essere tutti eseguiti con un'imbracatura di prova robotica. Questo approccio consente di eseguire test ventiquattr'ore su ventiquattro, che è l'altra soluzione per attività che richiedono molto tempo. In altre parole, hai trovato più tempo invece di diminuire la quantità di tempo necessaria.

risposta data 02.01.2013 - 14:38
fonte
2

Vorrei suddividere i tuoi test in tre categorie:

  1. (Unità) verifica su una piattaforma di riferimento (simulata) . Questi test dovrebbero riguardare tutto il software che non si interfaccia direttamente con i componenti hardware e dovrebbero includere sia i test unitari per i vari componenti software sia i test funzionali per tutte le funzionalità. La piattaforma di riferimento (simulata) dovrebbe essere in grado di supportare tutte le funzionalità (anche se non esiste un singolo prodotto che le abbia tutte) e dovrebbe essere in grado di simulare guasti hardware.
  2. Test delle interfacce hardware . Questi test dovrebbero darti sicurezza nell'interfaccia tra hardware e software. Per necessità, questi test devono essere eseguiti sull'hardware stesso e ripetuti per ciascun design hardware distinto. Potrebbe essere utile se questi test sono specificati / progettati da un team combinato di personale hardware e software.
  3. Test di sistema . Questi test dovrebbero dare la certezza che il sistema assemblato finale funzioni come progettato. Devono concentrarsi sulle funzionalità più utilizzate (e forse su alcuni scenari di errore facili da testare) e devono essere ripetute per ciascun prodotto con design hardware distinto o set di funzionalità non sovrapposte (se due prodotti sono tecnicamente identici, ma uno solo ha un set di funzionalità ridotto, non c'è bisogno di testare quello secondo come ampiamente).
risposta data 02.01.2013 - 15:52
fonte

Leggi altre domande sui tag