Quali sono i termini corretti per il test desk / utente?

Naviga le tue risposte
0

Esiste un termine comune e accettato per i test manuali eseguiti da programmatori o utenti sul software al posto o in aggiunta ai test automatici? Ad esempio, in una progressione come segue:

  1. "Desk Test" per i test non automatizzati eseguiti da un programmatore durante la scrittura del codice.
  2. "Test unità" per un test automatico per una particolare classe / metodo / funzione.
  3. "Test di integrazione" per un test automatico di più componenti che lavorano insieme.
  4. "Test di sistema" o "Test di accettazione" per test a livello di applicazione che sarebbero significativi nella conversazione con l'utente finale.
  5. "Test utente", per quando lo consegniamo all'utente e chiediamo loro di trovare i bug.

Esistono termini migliori per # 1 ("Desk Test") e # 5 ("Test utente")?

(E so che il TDD direbbe scrivere n. 2 prima del n. 1 ... ma fare quel punto è esattamente il motivo per cui voglio sapere la parola giusta per il n. 1).

    
posta DougM 15.01.2014 - 16:54
fonte

3 risposte

2

Credo che il termine che stai cercando sia "Test Ad-Hoc" . Quelli sono test che potresti scrivere mentre procedi, ma che non sono destinati a essere conservati o utilizzati come parte di test strutturati che potrebbero essere conservati e riutilizzati.

La sua utilità è dubbia e gran parte dell'attuale scuola di pensiero (o moda) è che, come una dimostrazione del concetto, se avessi bisogno di scrivere un test in primo luogo, vale la pena tenerlo anche solo per mostrare quanto lavoro che hai fatto?

    
risposta data 15.01.2014 - 18:29
fonte
0

La verifica della funzionalità durante la codifica è una categoria di Test della casella bianca . Nota la descrizione di Wikipedia:

White-box testing (also known as clear box testing, glass box testing, transparent box testing and structural testing) tests internal structures or workings of a program, as opposed to the functionality exposed to the end-user. In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. This is analogous to testing nodes in a circuit, e.g. in-circuit testing (ICT).

La maggior parte dei test unitari, se eseguiti correttamente, sono in realtà test della scatola nera; il test unitario non dovrebbe avere bisogno di conoscere le parti interne del metodo per completare il test.

Vedi anche Test di sviluppo , il processo di applicazione delle migliori pratiche al processo di sviluppo in ordine di ridurre i difetti. I test di sviluppo potrebbero includere analisi del codice statico, analisi delle metriche di analisi del flusso di dati, revisioni di peer code, test di unità, analisi della copertura del codice, tracciabilità e altre pratiche di verifica del software.

    
risposta data 15.01.2014 - 17:13
fonte
0

Mi affido al capitolo Test SWEBOK quando cerco definizioni generalmente accettate di livelli di test .

Detto questo, riconoscono solo tre livelli:

  • Unità
  • integrazione
  • Sistema

Ma riconoscono più obiettivi del test:

  • accettazione / qualifica
  • installazione
  • alpha & beta
  • conformità / funzionale / correttezza
  • raggiungimento e valutazione dell'affidabilità
  • regressione
  • prestazioni
  • lo stress
  • back-to-back
  • ripresa
  • Configurazione
  • usabilità

Il tuo primo elemento sembra essere una versione di test unitario, forse con un obiettivo di accettazione o conformità, ma la maggior parte delle organizzazioni inserisce tali test nella fase di test del sistema.

Il tuo quinto elemento potrebbe rientrare in una combinazione di obiettivi: accettazione, alpha, beta, conformità e / o usabilità.

    
risposta data 15.01.2014 - 22:54
fonte

Leggi altre domande sui tag

Buone pratiche che utilizzano segnali e sistemi guidati da eventi Design Pythonic per il controllo di più dispositivi tramite un bus I2C