Come testare il software con requisiti quasi in tempo reale?

Question

Come testare il software con requisiti quasi in tempo reale?

#1 da (2 voti)

1

Quindi, ho eseguito il refactoring della mia applicazione di videoconferenza per un po ', coprendola con test unitari e generali. Infine, sono arrivato al punto in cui ho bisogno di scrivere un test di loopback con 1 client che invia lo streaming video a un altro client. Questo non dovrebbe funzionare come un processo, anche sulla stessa macchina. Tuttavia, ho bisogno di scrivere questo test per garantire che tutti i componenti separati funzionino correttamente insieme. Tuttavia, una volta messo insieme tutto questo, comincio a notare come alcune parti, precedentemente coperte da test unitari, inizino a comportarsi in modo leggermente diverso: in pratica, le scadenze vengono perse e i requisiti in tempo reale vengono violati. Tendo a credere che ciò stia accadendo a causa del fatto che il codice per due client funziona più lentamente in un eseguibile, a differenza del caso se i due client erano su macchine separate (come sarebbe nello scenario reale).

Quindi, come si dovrebbero progettare i test per un tale software e tenere conto di questi vincoli? Chiedendo le migliori pratiche qui.

unit-testing real-time multithreading high-performance

posta peetonn 15.07.2016 - 01:24

fonte

1 risposta

Leggi altre domande sui tag unit-testing real-time multithreading high-performance

L'ereditarietà è migliore o il modello di progettazione della composizione in questo scenario? chiave API google maps per i client

score 2 · Accepted Answer

Congratulazioni, i tuoi test sono ora passati alla fase in cui è richiesto "test di integrazione".

Hai menzionato che oltre a testare hai fatto anche alcuni test generali e ho anche messo tutto insieme e ho notato che il test rivela prestazioni indesiderate.

I test di integrazione riguardano il modo in cui tutti i singoli componenti operano insieme come componenti funzionali principali.

Direi che se stai testando i tuoi clienti tutti insieme (in un processo / applicazione?), stai essenzialmente testandolo come uno scenario. Se non lo farai nella "vita reale", allora non testare così.

Invece, configura la tua imbracatura di test in modo tale che in effetti stai testando i tuoi clienti in modo simile alla vita reale. E quindi ridurre ulteriormente l'ambito in aree specifiche. Un esempio. se la tua macchina è in grado di gestirlo, configura 2 client su eseguibili separati. Forse prima eseguire un test sull'invio dei dati. quindi eseguire un test su riceverlo. cioè, concentrati solo su alcune aree importanti, che è il punto di test di integrazione.

quindi cerca di chiarire. Non preoccuparti di ricevere dati da tutto in una volta. è possibile testare l'invio di dati creando un ricevitore fittizio e monitorare semplicemente il componente di invio. se vedi che è veramente veloce e tempestivo, allora sai come restringere i problemi quando un vero ricevitore inizia a limitare il flusso di invio.

quindi un'idea di alcuni elementi di test;

invio di dati
ricezione dati
forse inviando solo dati vocali

controlla la latenza, ecc. per ogni oggetto che vuoi testare. potrebbe essere solo voce, potrebbe essere solo un handshaking ..

Usa due macchine se non puoi tagliarle con due o più fili. Ma renditi conto di cosa potrebbe significare per le prestazioni dell'applicazione dell'utente finale. Nella fase di integrazione stai testando specificamente i requisiti funzionali e prestazionali.

Dopo aver testato l'integrazione di tutti questi componenti, è possibile passare alla verifica e al test del sistema in cui è end-to-end e verificare i requisiti / gli obiettivi di alto livello del progetto.