Test di qualità del codice

Il testing della qualità del codice valuta la qualità del codice dell’applicazione. Si tratta dell’obiettivo principale di una pipeline di sola qualità del codice e viene eseguita immediatamente dopo la fase di compilazione in tutte le pipeline non di produzione e produzione.

Per ulteriori informazioni sui diversi tipi di pipeline, consulta Configurazione della pipeline CI-CD .

Regole per la qualità del codice

Nel testing della qualità del codice, il codice sorgente viene analizzato per garantire che soddisfi alcuni criteri di qualità. Attualmente, questo è implementato da una combinazione di SonarQube e l'esame a livello di pacchetto di contenuti utilizzando OakPAL. Ci sono più di 100 regole che combinano regole Java generiche e regole specifiche per AEM. Alcune delle regole specifiche AEM vengono create in base alle best practice di AEM Engineering e sono denominate Regole per la qualità del codice personalizzato.

NOTA

È possibile scaricare l'elenco completo delle regole qui.

Cancello a tre livelli

In questa fase di test della qualità del codice è presente una struttura a tre livelli per i problemi identificati:

  • Critico: Si tratta di problemi identificati dal gate che causano un errore immediato della pipeline.

  • Importante: Questi sono problemi identificati dal gate che fanno sì che la pipeline entri in uno stato di pausa. Un manager distribuzione, un project manager o un proprietario business possono ignorare i problemi, nel qual caso la pipeline procede, oppure possono accettare i problemi, nel qual caso la pipeline si interrompe con un errore.

  • Informazioni: Si tratta di questioni individuate dal cancello che sono fornite a scopo puramente informativo e non hanno alcun impatto sull’esecuzione della pipeline

I risultati di questo passaggio vengono consegnati come Valutazioni.

Nella tabella seguente sono riepilogati i rating e le soglie di errore per ciascuna categoria critica, importante e informativa:

Nome Definizione Categoria Soglia errore
Valutazione della sicurezza A = 0 Vulnerabilità
B = almeno 1 Vulnerabilità minore
C = almeno 1 Vulnerabilità principale
D = almeno 1 Vulnerabilità critica
E = almeno 1 Vulnerabilità del blocco
Critico < B
Valutazione dell'affidabilità A = 0 Bug
B = almeno 1 Bug secondario
C = almeno 1 Bug principale
D = almeno 1 Bug critico E = almeno 1 Bug blocco
Importante < C
Valutazione della manutenzione Il costo eccezionale di riparazione per gli odori di codice è:
  • <>
  • tra il 6% e il 10% il rating è a B
  • tra l'11 e il 20% il rating è a C
  • tra il 21 e il 50% il rating è un D
  • qualsiasi cosa superiore al 50% è un E
Importante < A
Copertura Una combinazione di copertura della linea di prova di unità e copertura della condizione utilizzando questa formula:
Coverage = (CT + CF + LC)/(2*B + EL)
dove: CT = condizioni che sono state valutate come "true" almeno una volta durante l'esecuzione di unit test
CF = condizioni che sono state valutate come "false" almeno una volta durante l'esecuzione di unit test
LC = linee coperte = line_to_cover - uncover_lines

B = numero totale di condizioni
EL = numero totale di linee eseguibili (lines_to_cover)
Importante < 50%
Test di unità ignorati Numero di prove di unità saltate. Info > 1
Problemi aperti Tipi di problemi generali - Vulnerabilità, Bug e Odori di Codice Info > 0
Linee duplicate Numero di righe interessate dai blocchi duplicati.
Affinché un blocco di codice sia considerato duplicato:
  • Progetti non Java:
  • Ci dovrebbero essere almeno 100 token successivi e duplicati.
  • Tali gettoni dovrebbero essere distribuiti almeno su:
  • 30 righe di codice per COBOL
  • 20 righe di codice per ABAP
  • 10 righe di codice per altre lingue
  • Progetti Java:
  • Ci dovrebbero essere almeno 10 istruzioni successive e duplicate indipendentemente dal numero di token e righe.

Le differenze nel rientro e nei valori letterali stringa vengono ignorate durante il rilevamento di duplicati.
Info > 1%
Compatibilità Cloud Service Numero di problemi di compatibilità Cloud Service identificati. Info > 0
NOTA

Per definizioni più dettagliate, fai riferimento a Definizioni metriche .

NOTA

Per ulteriori informazioni sulle regole per la qualità del codice personalizzato eseguite da Cloud Manager, consulta Regole per la qualità del codice personalizzato.

Gestione dei falsi positivi

Il processo di scansione della qualità non è perfetto e talvolta identificherà erroneamente problemi che non sono effettivamente problematici. Questo viene indicato come falso positivo.

In questi casi, il codice sorgente può essere annotato con l’annotazione Java standard @SuppressWarnings che specifica l’ID regola come attributo dell’annotazione. Ad esempio, un problema comune è che la regola SonarQube per rilevare le password codificate può essere aggressiva riguardo a come viene identificata una password hardcoded.

Per osservare un esempio specifico, questo codice è abbastanza comune in un progetto AEM con codice per la connessione a un servizio esterno:

@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

SonarQube solleverà quindi una vulnerabilità di blocco. Dopo aver esaminato il codice, identifichi che questa non è una vulnerabilità e puoi annotarla con l’ID regola appropriato.

@SuppressWarnings("squid:S2068")
@Property(label = "Service Password")
private static final String PROP_SERVICE_PASSWORD = "password";

Tuttavia, se il codice era effettivamente questo:

@Property(label = "Service Password", value = "mysecretpassword")
private static final String PROP_SERVICE_PASSWORD = "password";

Quindi la soluzione corretta è quella di rimuovere la password hardcoded.

NOTA

È buona norma rendere l’annotazione @SuppressWarnings il più specifica possibile, ovvero annotare solo l’istruzione o il blocco specifici che causa il problema, ma è possibile annotarla a livello di classe.

NOTA

Anche se non esiste un passaggio esplicito di test della sicurezza, durante il passaggio sulla qualità del codice sono ancora presenti regole di qualità del codice relative alla sicurezza valutate. Per ulteriori informazioni sulla sicurezza nel Cloud Service, consulta Panoramica sulla sicurezza per AEM as a Cloud Service .

In questa pagina