Monitoraggio sintetico con Robotmk

Diversi componenti lavorano insieme per creare questo monitoraggio end-to-end: ecco una breve panoramica.

Lo scheduler di Robotmk si trova all'indirizzo Setup > Agent rules > Robotmk scheduler (Windows). Dato che la regola è piuttosto estesa, diamo un'occhiata alla configurazione vuota:

Per prima cosa, lo scheduler richiede la directory di base della suite di test: inserisci questo percorso arbitrario ed esplicito in Base directory of suites, ad esempio C:\robots.

Il sito Parallel plan groups che viene mostrato ora è un concetto specifico di Checkmk.

Per spiegarlo, dobbiamo prima scendere di un livello gerarchico: qui puoi vedere l'elemento Sequential plans. Un piano sequenziale di questo tipo definisce quali suite devono essere eseguite con quali parametri. Robot Framework processerà queste suite una dopo l'altra. Il motivo è semplice: nella pratica, a volte i test vengono eseguiti sul desktop e diverse suite di test potrebbero intralciarsi l'una con l'altra nello stesso momento (pensa se si rubassero il controllo del cursore del mouse).

I gruppi di piani sono ora un incapsulamento per i piani eseguiti in sequenza e vengono a loro volta eseguiti in parallelo. Anche in questo caso, il ragionamento è semplice: ciò consente alle suite di test che non si affidano al desktop di essere eseguite nei propri piani senza ritardi - la suite di test utilizzata in questo articolo è un buon esempio di processo di questo tipo.

Torniamo alla finestra di dialogo: L'unica impostazione esplicita è l'intervallo di esecuzione, che puoi impostare in Group execution interval.

Ora è il momento di configurare il primo piano. Puoi inserire qualsiasi nome alla voce Application name. Questo nome non deve essere univoco: il nome dell'applicazione da monitorare ha senso in questo caso, ad esempio OnlineShop, o in questo esempio semplicemente MyApplication. Naturalmente, può succedere che questo negozio online venga testato più volte, sia da altre suite di test che dalla stessa suite di test con parametri diversi. In questi casi, il campo Variant viene utilizzato per ottenere risultati non ambigui nonostante i nomi identici. Ad esempio, se l'applicazione OnlineShop viene testata una volta in tedesco e una volta in inglese (tramite parametri corrispondenti), si possono utilizzare le abbreviazioni corrispondenti. Il monitoraggio restituirà quindi i risultati per My OnlineShop_en e My OnlineShop_de.

Tuttavia, è necessario specificare la voce Relative path to test suite file or folder. Il percorso è relativo alla directory di base specificata in precedenza, ad es. mybot\test.robot per C:\robots\. In alternativa, è possibile specificare anche una directory (con diversi file robot ), nel qual caso sarebbe semplicemente mybot.

Continua con Execution configuration.In Limit per attempt definisci il tempo massimo trascorso - per ogni tentativo - che una suite di test può essere eseguita. Con Robot Framework re-executions puoi ora indicare a Robot Framework di ripetere le suite di test completamente o in modo incrementale se i test falliscono. Se i singoli test di una suite di test sono indipendenti l'uno dall'altro, la strategia incrementale è il modo migliore per risparmiare tempo. Se invece la suite di test verifica una sequenza logica, come ad esempio "Login → Richiama la pagina del prodotto → Prodotto nel carrello → Checkout", la suite di test deve essere ovviamente rielaborata completamente. Alla fine, il risultato è sempre uno solo.

Nel caso di tentativi completi, solo i risultati delle suite autonome vengono presi in considerazione per il risultato finale: Se un test fallisce all'ultimo tentativo, la suite di test viene considerata un fallimento. Nel caso dei tentativi incrementali, il risultato finale è composto dai migliori risultati parziali: Se alcuni test vengono eseguiti con successo solo al terzo tentativo, anche il risultato finale viene conteggiato come un successo. Ricorda: La combinazione di tentativi e tempi massimi di esecuzione di tutti i piani di un gruppo di piani determina il loro intervallo minimo di esecuzione.

Per impostazione predefinita, l'esecuzione tramite RCC è attivata sotto Automated environment setup (via RCC), per il quale devi inserire due valori. In primo luogo, RCC richiede di specificare dove si trova il file robot.yaml. Il suo scopo principale è quello di fare riferimento al file conda.yaml, che è responsabile dell'impostazione dell'ambiente Python, cioè dell'installazione di Python e delle dipendenze. Questa specifica è relativa alla directory di base che hai impostato in precedenza sotto Relative path to test suite file or folder. I file YAML possono essere salvati in sottodirectory, ma la prassi migliore è la directory di base della suite. Per la directory di base C:\robot\ e la directory della suite C:\robot\mybot è quindi mybot\robot.yaml.

Con il seguente limite di tempo per la creazione dell'ambiente Python, devi tenere presente che a volte è necessario scaricare e configurare grandi quantità di dati. Soprattutto per i browser richiesti, si accumulano rapidamente diverse centinaia di megabyte, ma solo per la prima esecuzione. RCC ricostruisce gli ambienti solo se il contenuto di conda.yaml è cambiato.

In Robot Framework parameters hai la possibilità di utilizzare alcuni dei parametri della riga di comando di Robot Framework (che vengono visualizzati anche dal comando robot --help). Se vuoi utilizzare altri parametri, l'opzione Argument files ti sarà d'aiuto. Un file specificato in questo punto può contenere qualsiasi parametro del robot. Ulteriori informazioni sui singoli parametri possono essere trovate nell'aiuto inline.

Nel nostro progetto di esempio, è stata attivata solo l'opzione Variables ed è stata impostata una variabile MYVAR con il valore My Value. Ricordi il comando Log ${MYVAR} all'inizio del file tests.robot? Questo è il riferimento corrispondente.

Alla fine della configurazione della suite, ci sono tre opzioni che si spiegano da sole.Execute plan as a specific user permette di eseguire Robotmk nel contesto di un account utente specifico. Sfondo: Per impostazione predefinita, Robotmk viene eseguito nel contesto dell'agente Checkmk(account LocalSystem), che non ha alcuna autorizzazione ad accedere al desktop. In questo caso è possibile specificare un utente che deve essere permanentemente logato in una sessione desktop e che ha accesso alle applicazioni grafiche del desktop.

Con Assign plan/test result to piggyback host i risultati del piano/test possono essere assegnati a un altro host. Ad esempio, se Robot Framework sta testando il processo di ordinazione di un negozio online, i risultati possono essere assegnati al server web corrispondente.

Ogni esecuzione di test produce dati che vengono archiviati in C:\ProgramData\checkmk\agent\robotmk_output\working\suites\. Per impostazione predefinita, vengono conservati i risultati degli ultimi 14 giorni, ma devi tenere presente che in questo caso si possono accumulare rapidamente grandi volumi di dati. Vengono generati almeno 500 kilobyte di dati per ogni esecuzione; con suite di test più complesse e screenshot incorporati, ad esempio, si possono sommare rapidamente diversi megabyte di dati. A seconda dell'intervallo di esecuzione, delle dimensioni del report e delle tue esigenze di documentazione, dovresti intervenire in questa situazione.

A questo punto, puoi creare altri piani in questo gruppo di piani o in altri gruppi di piani.

Alla fine ci sono altre due opzioni, che a loro volta riguardano la configurazione completa dello scheduler Robotmk.

RCC profile configuration ti permette di specificare i server proxy e gli host da escludere.

Grace period before scheduler starts può essere molto utile: Lo scheduler si avvia insieme all'agente Checkmk prima dell'accesso al desktop - il che, ovviamente, significa che qualsiasi test sul desktop deve fallire. L'avvio può essere ritardato manualmente utilizzando un periodo di grazia.

La configurazione è completata e puoi creare un nuovo agente con il plug-in e distribuirlo manualmente o tramite gli aggiornamenti automatici dell'agente.

Nel monitoraggio troverai servizi per lo stato dello scheduler Robotmk e per i singoli piani e test, anche se non hai creato uno stato del servizio separato.

Se lo scheduler non riceve alcun dato, è probabile che la creazione dell'ambiente non abbia funzionato. Un motivo comune per questo sono i problemi di rete, ad esempio, a causa dei quali non è possibile caricare alcune dipendenze. In questo caso, dai un'occhiata al file di log corrispondente sotto C:\ProgramData\checkmk\agent\robotmk_output\working\environment_building.

Si tratta di un errore particolarmente interessante che potresti riscontrare nei sistemi Windows di nuova generazione. conda.yaml può contenere anche istruzioni che devono essere eseguite dopo l'installazione delle dipendenze - ad esempio, l'inizializzazione del browser Robot Framework. I comandi Python devono quindi essere eseguiti qui. Per impostazione predefinita, Windows 11 ha degli alias per python.exe e python3.exe che fanno riferimento al Microsoft Store. Devi disattivare questi alias in "Impostazioni/Alias per l'esecuzione delle app".