Come elaborare un ambito complesso non testato?

Question

Come elaborare un ambito complesso non testato?

#1 da (2 voti)
#2 da (1 voti)

0

Lo scopo: fa parte di un grande sistema ERP che fornisce calcoli specifici. Si può pensare ad esso come un modulo di calcolo del salario in un CRM. Eppure questo è ben oltre sia nei punti di complessità che di integrazione. Quindi, ci sono molti debiti tecnologici, ma non immateriali. Esistono alcuni test di unità / integrazione scritti. è verificabile, ma non è stato fatto molto. È una parte vecchia di quel sistema ERP (3 anni), nel corso degli anni si era trasformato in quello che è ora, e c'è la volontà di provare a completarlo anche se costa qualche sforzo importante.

Il problema: l'ambito che fornisce molti calcoli diversi basati su un elenco specifico di oggetti e i risultati non sono corretti a volte.

Ci sono molte interessanti (non così comuni) funzionalità su questo ambito:

Formule C # dinamiche (caricate nel contesto e quindi incluse nei calcoli)
Un sacco di report che eseguono gli stessi calcoli ma sul database
L'ambito è instabile e intenso nel tempo (nuove funzionalità e correzioni di bug vengono inviate ogni mese)

Questo ambito ha molti parametri di input su tutti gli oggetti dipendenti. Moltiplicando tutti i valori dei parametri possibili abbiamo 1,62 * 10 ⁷ casi di possibili risultati. Non tutti i parametri si comportano tanto, ma molti di loro lo fanno. Quindi affettare la metà di quel numero è qualcosa che riguarda gli aspetti pratici possibili.

Questo ambito sta consumando molto tempo e denaro ed è tutt'altro che fatto nella sua forma attuale.

Mi piacerebbe sapere che cos'è ~~il proiettile d'argento~~ il modo più efficace per stabilizzare e portare a termine lo scope nello stato in cui si verificano solo bug minori e piacevole ad avere?

Prima di tutto stavo pensando che stabilire un DoD (definizione di fatto) sarebbe una cosa importante da fare. Poi sono arrivato al fatto che avere un numero enorme di output funzionanti è la metà di questo - tutto deve anche essere flessibile sull'ambito dell'interfaccia utente.

Sarà il caso di stabilire un piano di test, magari fare qualche test di bruteforcing? Dovrei considerare qualsiasi tipo di design pattern? Opzioni di convalida (come un solido servizio di validazione di terze parti, ecc.)? Sarà sufficiente o forse ho delle lacune nella mia modesta conoscenza che dovrei riempire?

Nota: l'applicazione non è quella che si chiamerebbe monolitica. Si basa su molti servizi diversi che possono essere facilmente estesi, ecc.

design

posta povilasp 26.03.2013 - 11:23

fonte

2 risposte

1

Questi due punti

new features and bugfixes are shipped every month

e

I would like to know what is the most viable way to stabilize and finish the scope

sono in conflitto. Se ci sono nuove funzionalità ogni mese, ci sono nuovi requisiti ogni mese, qualcuno sembra aver bisogno di quelle funzionalità, qualcun altro le sta programmando e questo è un nuovo software - che in genere contiene alcuni bug all'inizio e che andrà meglio con tempo attraverso test e feedback degli utenti. Inoltre, non c'è "fine" di questo processo, è "software vivente" in cui i cambiamenti sembrano essere parte del normale processo.

Sarebbe davvero utile se tu avessi perso qualche parola su come si presenta l'attuale sviluppo di questo "ambito", c'è uno sviluppatore, una squadra, ci sono molte persone che richiedono nuove funzionalità ecc.?

Il miglior consiglio che posso darti è provare a separare le parti in cui i requisiti sono stabili dalle parti con i requisiti instabili. Le parti in cui i requisiti sono stabili devono essere rese a prova di proiettile e ben collaudate mediante test di regressione automatizzati. Queste parti possono essere un po '"finite".

Le altre parti - beh, non so chi sta definendo quella parte di formula dinamica, ma suppongo che sia la parte che cambia ogni mese. È importante dare a coloro che stanno definendo quelle formule un feedback immediato se lo hanno fatto bene. Forse devi fornire una sorta di "ambiente di test interattivo" per quelle persone, in modo che possano provare le formule prima di introdurle nel sistema reale.

Ad esempio, pensate a un software di foglio di calcolo come MS Excel - il programma stesso è un software (più o meno) stabile, (si spera) ben testato, dove non si ottengono nuove versioni ogni mese. Può essere utilizzato come piattaforma per formule e report e l'utente di tali formule e report può inserire da solo le formule, testarle, ottenere feedback immediati e modificare tali cose 10 volte al giorno, se lo desidera. Se riesci a creare una "separazione di preoccupazioni" comparabile nel tuo "ambito" (qualunque cosa ciò significhi), allora sarai un grande passo avanti.

risposta data 27.03.2013 - 08:21

fonte

Leggi altre domande sui tag design

Dichiarazione IF a più condizioni più efficiente Che cos'è ServletUtilities?

score 2 · Accepted Answer

Devi trovare i "principi guida" dietro l'ambito. ax + by = c ha un numero infinito di soluzioni, ma è ancora un'equazione limitata. Si tratta di trovare casi di test sufficienti in cui tu e il cliente siete soddisfatti del fatto che ax + by = c sia soddisfatto. Ovviamente, non è necessario un test per ogni possibile valore di output. Ciò di cui hai bisogno sono sufficienti test per ottenere la certezza che il software funzioni come dovrebbe.

Quando inserisci una nuova condizione nel software da qualche parte, viene creata una biforcazione (un punto in cui la logica si dirama in due direzioni diverse). Per ottenere un'adeguata copertura del codice, creare un test case per ogni ramo in ogni biforcazione e test per coprire eventuali casi limite (come i limiti di precisione dei numeri critici). Vedi qui per un esempio di come funziona.

Chiedi al cliente di accettare una serie di casi di test che, una volta soddisfatti, ti consentiranno di dichiarare il successo. Quindi il tuo ambito sarà limitato dai tuoi casi di test.