Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
L'integrazione continua (CI) è una pratica chiave nel settore. Le integrazioni sono frequenti e verificate con una compilazione automatizzata che esegue test di regressione per rilevare gli errori di integrazione il prima possibile. Tuttavia, man mano che la codebase cresce e matura, anche il gruppo di test di regressione tende a crescere, nella misura in cui l'esecuzione di un test di regressione completa potrebbe richiedere ore. Questo test rallenta la frequenza delle integrazioni e infine sconfigge lo scopo dell'integrazione continua.
Per avere una pipeline di integrazione continua che si completa rapidamente, alcuni team rinviano l'esecuzione dei test a esecuzione prolungata a una fase distinta nella pipeline. Tuttavia, questa azione serve solo per sconfiggere ulteriormente l'integrazione continua.
Abilitare invece Test Impact Analysis (TIA) quando si usa l'attività Test di Visual Studio in una pipeline di compilazione. TIA esegue la convalida incrementale mediante la selezione automatica dei test. Seleziona automaticamente solo il subset di test necessari per convalidare il commit del codice. Per un determinato commit del codice che entra nella pipeline CI/CD, TIA seleziona ed esegue solo i test pertinenti necessari per convalidare quel commit. Pertanto, l'esecuzione del test viene completata più rapidamente, se si verifica un errore si riceve un avviso prima e, poiché il tutto è valutato in base alla pertinenza, anche l'analisi è più veloce.
L'analisi dell'impatto dei test ha:
- Un solido meccanismo di selezione dei test. Include i test impattati esistenti, i test precedentemente falliti e infine i test appena aggiunti.
- Ripiego sicuro. Per i commit e gli scenari che TIA non può comprendere, TIA ricorre all'esecuzione di tutti i test. L'ambito tiA è attualmente limitato al codice gestito e alla topologia a computer singolo. Quindi, ad esempio, se il commit del codice contiene modifiche ai file HTML o CSS, non può prendere decisioni su di essi e ricorre all'esecuzione di tutti i test.
- Sostituzioni configurabili. È possibile eseguire tutti i test in una periodicità configurata.
Tenere tuttavia presente quanto segue quando si usa TIA con Visual Studio 2015:
- Esecuzione di test in parallelo. In questo caso, i test vengono eseguiti serialmente.
- Esecuzione di test con copertura del codice abilitata. In questo caso, i dati di code coverage non vengono raccolti.
Scenari supportati per l'analisi dell'impatto dei test
L'analisi dell'impatto dei test è supportata per gli scenari seguenti:
- A partire da TFS 2017 Update 1 e Azure Pipelines
- Versione 2.* dell'attività Test di Visual Studio nella pipeline di compilazione
- Compilare vNext, con più attività VSTest
- VS2015 Update 3 e versioni successive sull'agente di compilazione
- Agenti di compilazione locali e ospitati (sul cloud)
- Integrazione continua e nei flussi di lavoro delle richieste pull
- Git, GitHub, Altri repo Git, repo TFVC (inclusi i repo TFVC parzialmente mappati con una soluzione alternativa)
- Interazioni con IIS (su REST, API SOAP), tramite protocolli HTTP/HTTPS
- Test automatizzati
- Topologia a computer singolo. I test e le app (SUT) devono essere in esecuzione nello stesso computer.
- Codice gestito (qualsiasi app .NET Framework, qualsiasi servizio .NET)
TIA non è supportato per i seguenti scenari:
- Topologia multi-computer (in cui il test verifica un'applicazione distribuita su un diverso computer)
- Test basati sui dati
- Esecuzione di test paralleli specifici dell'adapter di test
- .NET Core
- UWP
Altre informazioni sull'ambito e le applicazioni TIA
Abilitare l'analisi dell'impatto dei test
TIA è supportato tramite la versione 2.* dell'attività Test di Visual Studio. Se l'app è un'applicazione monolivello, basta selezionare Esegui solo i test interessati nell'interfaccia utente attività. Lo strumento di raccolta dati dell'impatto del test viene configurato automaticamente. Non sono necessari altri passaggi.
Se l'applicazione interagisce con un servizio nel contesto di IIS, è necessario configurare anche il Data Collector di Test Impact per l'esecuzione nel contesto di IIS usando un file .runsettings. L'esempio seguente crea questa configurazione:
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<DataCollectionRunSettings>
<DataCollectors>
<!-- This is the TestImpact data collector.-->
<DataCollector uri="datacollector://microsoft/TestImpact/1.0" assemblyQualifiedName="Microsoft.VisualStudio.TraceCollector.TestImpactDataCollector, Microsoft.VisualStudio.TraceCollector, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" friendlyName="Test Impact">
<Configuration>
<!-- enable IIS data collection-->
<InstrumentIIS>True</InstrumentIIS>
<!-- file level data collection -->
<ImpactLevel>file</ImpactLevel>
<!-- any job agent related executable or any other service that the test is using needs to be profiled. -->
<ServicesToInstrument>
<Name>TeamFoundationSshService</Name>
</ServicesToInstrument>
</Configuration>
</DataCollector>
</DataCollectors>
</DataCollectionRunSettings>
</RunSettings>
Visualizzare il risultato dell'analisi dell'impatto dei test
TIA è integrato nei report di test esistenti sia a livello di riepilogo che di dettagli, inclusi i messaggi di posta elettronica di notifica.
Altre informazioni sull'integrazione di TIA e Azure Pipelines
Gestire il comportamento dell'analisi dell'impatto dei test
È possibile influenzare il modo in cui i test vengono inclusi o ignorati durante un'esecuzione di test:
- Tramite l'interfaccia utente VSTest. TiA può essere condizionata per eseguire tutti i test in una periodicità configurata. L'impostazione di questa opzione è consigliata ed è il modo per regolare la selezione dei test.
- Impostando una variabile di compilazione. Anche dopo l'abilitazione di TIA nell'attività VSTest, è possibile disabilitarla per una compilazione specifica impostando la variabile DisableTestImpactAnalysis su true. Questa override impone a TIA di eseguire tutti i test per la compilazione. Nelle build successive, TIA torna alla selezione di test ottimizzata.
Quando TIA apre un commit e rileva un tipo di file sconosciuto, esegue nuovamente l'esecuzione di tutti i test. Anche se questa azione è valida dal punto di vista della sicurezza, l'ottimizzazione di questo comportamento potrebbe essere utile in alcuni casi. Ad esempio:
- Impostare la variabile TI_IncludePathFilters su percorsi specifici in modo da includere solo questi percorsi in un repository per cui si vuole applicare TIA. Questa azione è utile quando i team usano un repository condiviso. L'impostazione di questa variabile disabilita TIA per tutti gli altri percorsi non inclusi nell'impostazione.
- Impostare la variabile TIA_IncludePathFilters per specificare i tipi di file che non influiscono sul risultato dei test e per cui le modifiche devono essere ignorate. Ad esempio, per ignorare le modifiche apportate ai file con estensione csproj impostare la variabile sul valore :
!\*\*\\\*.csproj
.
Usare il modello di minimatch quando si impostano variabili e separare più elementi con un punto e virgola.
Per valutare se TIA seleziona i test appropriati:
- Convalidare manualmente la selezione. Uno sviluppatore che sa come vengono progettato i test e SUT potrebbe convalidare manualmente la selezione dei test usando le funzionalità di creazione di report TIA.
- Esegui i test TIA selezionati e poi esegui tutti i test in sequenza. In una pipeline di compilazione, utilizzare due attività di test: una che esegue solo i test influenzati (T1) e una che esegue tutti i test (T2). Se T1 viene superato, verificare che anche T2 passi. Se si è verificato un test non riuscito in T1, verificare che T2 segnala lo stesso set di errori.
Altre informazioni sulla configurazione avanzata TIA
Fornire mapping di dipendenze personalizzato
TIA usa le mappe delle dipendenze del formato seguente.
TestMethod1
dependency1
dependency2
TestMethod2
dependency1
dependency3
TIA può generare una mappa delle dipendenze per l'esecuzione del codice gestito.
Se tali dipendenze risiedono nei file .cs
e .vb
, TIA può monitorare automaticamente i commit in tali file e quindi eseguire test che contengono questi file di origine nell'elenco delle loro dipendenze.
È possibile estendere l'ambito di TIA specificando in modo esplicito il mapping delle dipendenze come file XML. Ad esempio, è possibile supportare il codice in altri linguaggi, ad esempio JavaScript o C++, oppure supportare lo scenario in cui i test e il codice prodotto sono in esecuzione in computer diversi. Il mapping può anche essere approssimativo e il set di test da eseguire può essere specificato in termini di filtro dei casi di test, come forniresti tipicamente nei parametri dell'attività VSTest.
Il file XML deve essere archiviato nel repository, in genere a livello radice. Impostare quindi la variabile di compilazione TIA.UserMapFile per puntare a esso. Ad esempio, se il file è denominato TIAmap.xml, impostare la variabile su $(System.DefaultWorkingDirectory)/TIAmap.xml.
Per un esempio del formato di file XML, vedere il mapping delle dipendenze personalizzate TIA.
Vedi anche
- Panoramica di TIA e integrazione di VSTS
- Ambito e applicazioni TIA
- Configurazione avanzata TIA
- Mapping delle dipendenze TIA personalizzate
Assistenza e supporto
- Vedere la pagina relativa alla risoluzione dei problemi
- Ottenere consigli su Stack Overflow e ottenere supporto tramite la community degli sviluppatori