Quali scenari di test sono necessari e sufficienti per testare in modo esauriente un modello di appuntamento ricorrente?

Question

Ho un modello django per un appuntamento in un calendario per il quale sto tentando di scrivere un driver di prova molto completo. L'appuntamento ricorrente si verifica in un determinato momento e può essere eseguito all'infinito o ripetersi per un determinato numero di volte. L'appuntamento rispecchia la funzionalità disponibile per un appuntamento di Google Calendar (può ripetersi mensilmente / annualmente / settimanalmente, ogni due settimane, ogni 3 anni.)

Sto cercando di elaborare un unit test che testerà esaurientemente le basi di questa implementazione. Sto cercando i casi limite che definiranno i test più elementari.

Ne ho molti di base, ma sto cercando suggerimenti per aiutare a identificare i casi più importanti: 1) Crea un singolo appuntamento 2) Creare un appuntamento che si ripete settimanalmente 3) ... ricorre mensilmente 4) ricorre ogni 2 settimane 5) ricorre ogni 2 mesi 6) ricorre annualmente

Answer 1

Prova con gli ultimi giorni di mesi, anni bisestili e se diventerà pazzo quando l'anno avrà un secondo in più (questo ha colpito un pilota nel giocatore zune).

Test si comporta bene quando attraversano anni.

Detto questo, considera se stai testando nuovamente qualcosa che fa parte del framework. La logica della data del test può diventare brutta molto velocemente, quindi vuoi tracciare una linea su ciò che fa parte della tua applicazione e ciò che fa parte del framework.

Answer 2

Non dimenticare di testare la ricorrenza annuale per il 29 febbraio in un anno bisestile;)

Answer 3

Prima di iniziare a scuotere gli scenari, devi davvero elaborare un piano di test basato sulla tua comprensione dei Requisiti.

Considera la tua base di utenti e qualsiasi altra base di utenti possibile / futura (come una priorità inferiore). Per cosa lo useranno principalmente e per quanto valgono quei casi d'uso che valgono per loro nella loro attività?

Idealmente, crea un modello dell'app e inizia da lì.

Vieni con un'analisi del rischio di ciò che pensi di fare. Quindi pianificare di eseguire test funzionali, di sicurezza, di localizzazione, ecc.

Quindi puoi iniziare a pensare a scenari basati su come "rischioso" sono (dall'analisi dei rischi). Concentrati sulla scrittura e l'esecuzione del "più rischioso" prima quelli.

Ottieni input aziendali (firma se possibile) sull'analisi del rischio e su come intende utilizzarlo.

Basta lanciare scenari casuali non è una buona pratica di test e merita tutto il ridicolo che puoi ottenere dagli sviluppatori. I test dovrebbero essere un esercizio più ingegnerizzato e pianificato. Possono assumere chiunque fuori strada per eseguire scenari che arrivano in cima alla loro testa.

Detto questo, concordo sul fatto che gli scenari precedentemente menzionati siano provati e veri. Buone idee. Inoltre, esegui il test dell'ora legale. Utilizzare client di posta elettronica diversi. Prova a pubblicare la data di disponibilità. Chiedi agli sviluppatori di spiegare come stanno pubblicando queste informazioni. È attraverso un servizio web? Si aspettano che solo gli utenti di Exchange lo utilizzino? Qualcuno in diversi paesi in cui le date sono formattate in modo diverso? È quindi possibile trovare punti deboli e trovare più bug.

Happy Testing.