Guadagni:
- Capacità di progettare il ruolo dell'intelligenza artificiale e dei punti di approvazione umani nel flusso di QA end-to-end dall'idea al rilascio nel contesto di CI/CD
- In CI/CD, non si autorizza l'IA a "superare" automaticamente il test, ma si applicano limiti per proteggere dati e chiavi riservati
- Capacità di eseguire test di sicurezza all'interno dell'autorità e per scopi difensivi e di adottare principi di divulgazione responsabile e trasparenza etica.
Nelle dieci unità precedenti, abbiamo utilizzato l'intelligenza artificiale in compiti individuali: generazione di scenari, codice di automazione, segnalazione di bug, analisi di copertura, test di mutazione. Questa unità finale li combina tutti in un unico flusso di lavoro responsabile. Il QA moderno non è un lavoro che finisce alla scrivania di una persona; È un processo che vive all'interno di CI/CD (Continuous Integration/Continuous Delivery: la pipeline in cui il codice viene costantemente combinato, testato automaticamente e preparato per la pubblicazione frequente e sicura). L’intelligenza artificiale può toccare ogni fase di questo processo. Ma man mano che cresce il potere dell’intelligenza artificiale, aumenta anche l’importanza di usarla in modo responsabile: privacy, autorità nei test di sicurezza, etica e, soprattutto, lasciare che la decisione sulla qualità sia affidata all’essere umano. In questa unità imparerai il flusso e i confini end-to-end.
Flusso di QA end-to-end basato sull'intelligenza artificiale
Il ruolo dell'intelligenza artificiale nel percorso di una funzionalità dall'idea al rilascio:
1. Analisi dei requisiti. L'intelligenza artificiale segnala le ambiguità nei requisiti e i criteri di accettazione mancanti ("questa regola non dice il numero minimo di caratteri della password").
2. Progettazione del test. Bozze di scenari e casi (unità 2), casi limite (unità 3) sono tra i criteri di accettazione.
3. Automazione. Bozze di codice di prova Unità (6), API (5) e UI (4); ciascuno è confermato dalla mutazione (10).
4. Integrazione CI/CD. I test vengono eseguiti automaticamente ad ogni unione del codice. L'intelligenza artificiale elabora una bozza della configurazione della pipeline (YAML), riassume i registri dei test falliti e suggerisce la possibile causa principale.
5. Decisione di rilascio. Vengono raccolti i risultati dell'analisi del rischio (8) e della regressione (9), ma l'esperto decide se può avere successo.
6. Monitoraggio e feedback della produzione. Gli errori dal vivo diventano test futuri; L'intelligenza artificiale propone un caso di regressione da un difetto di fabbricazione.
Suggerimento: configura l’intelligenza artificiale come un livello in CI/CD che “accelera le bozze revisionate da persone” anziché “scrive test e prende decisioni”. Nessun test generato automaticamente dovrebbe entrare nella pipeline senza che un essere umano li abbia revisionati e approvati.
AI in CI/CD: dove sì, dove no
Palcoscenico
Adatta all'intelligenza artificiale
umano è essenziale
Testare la bozza del codice
Sì
Revisione + mutazione
Bozza YAML della pipeline
Sì
Autenticazione + controllo della chiave segreta
Riepilogo del registro non riuscito
Sì
Conferma della causa principale
Diagnosi del test fragile
Sì
Decisione di soluzione permanente
"Può esistere una versione?"
no
Giudizio e responsabilità degli esperti
"Supera" automaticamente il test
mai
—
Attenzione: non dare mai all'IA un mandato come "aggiustarlo per superare il test di fallimento" in CI/CD. Ciò vanifica lo scopo del test e nasconde automaticamente gli errori. L'intelligenza artificiale può spiegare l'errore, suggerire la correzione; ma "dipingere il test in verde" deve essere una decisione consapevole e ragionata di una persona.
Privacy, dati e sicurezza: confini immutabili
Privacy. Nell'ambiente di test, i dati reali dei clienti, le copie del database di produzione, le chiavi API e le informazioni di sistema interne sono sensibili. Non fornirli agli strumenti pubblici di intelligenza artificiale. I dati personali sono soggetti alla KVKK e normative simili; Maschera log e screenshot. Utilizzare dati di test sintetici (fittizi) ove possibile.
Test di sicurezza: difensivi e autorizzati. I test di sicurezza appresi in questo modulo (test di autorizzazione/IDOR, limiti di caricamento dei file, convalida dell'input) servono solo per testare il proprio prodotto entro l'autorizzazione scritta e l'ambito definito. Utilizzare l'intelligenza artificiale per accedere al sistema di qualcun altro senza autorizzazione, sfruttare come armi vulnerabilità reali o eseguire test fuori ambito è sia immorale che illegale. Quando trovi una vulnerabilità nella sicurezza, rispetta il principio della divulgazione responsabile, mantenendo la vulnerabilità riservata e segnalandola alla parte interessata in modo che possa essere risolta.
Etica e trasparenza. Non presentare i test prodotti dall’IA come opera tua; Dichiarare che si utilizza l’intelligenza artificiale all’interno del team è trasparenza. Sei responsabile dell’inesattezza di un output prodotto dall’intelligenza artificiale: “l’ha scritto l’intelligenza artificiale” non è una scusa.
Prompt debole / Prompt forte
Debole: "Imposta pipeline di test per CI".
Forte: "Crea un flusso di lavoro CI YAML per le azioni GitHub: esegui test unità + API su ogni PR, genera report di copertura, esegui test di mutazione (Stryker) settimanalmente. Non incorporare segreti nel codice; usa solo riferimento ai segreti. Blocca l'unione se i test sono rossi. Questa è una BOZZA; esaminerò e modificherò i passaggi di gestione e convalida delle chiavi segrete. NON AGGIUNGERE un passaggio di "correzione" o "migrazione" di test automatizzato."
Prompt potente; Impone limiti alla riservatezza, alla revisione umana e al "nessun test automatizzato".
Quattro modelli copiabili
1) Piano di test end-to-end:
Il tuo ruolo: leader senior del controllo qualità. Redigere un piano di test end-to-end dall'idea al rilascio per la seguente funzionalità: [funzionalità + criteri di accettazione]. Fasi: analisi dei requisiti (incertezze), progettazione del test, livelli di automazione (unità/API/UI), integrazione CI/CD, criteri decisionali sul rilascio, monitoraggio della produzione. Specificare il ruolo dei punti di approvazione AI e UMANI in ciascuna fase separatamente.
2) Schema della pipeline CI/CD:
Bozza CI YAML per [GitHub Actions/GitLab CI/Azure Pipelines]:- Unità + test API + ambito in PR- Impedisci l'unione nel test rosso- Valori segreti solo con segreti; incorporamento nel codiceQuesta è una bozza; Esaminerò le principali fasi di gestione e approvazione. Aggiunta di una fase di correzione automatica/superamento del test.
3) Analisi del registro dei test non riuscita:
In quella stampa CI, i test sono rossi. Esaminare il registro; raggruppare i fallimenti, distinguere la possibile causa principale e QUALE potrebbe essere il vero fallimento e quale potrebbe essere un problema di test/ambiente fragile. Se ci sono dati personali, mascherateli. La decisione e la correzione saranno mie. Registro: [incolla]
4) Pre-controllo sicurezza/privacy:
Prima che questi dati/registri di test vengano inviati allo strumento AI, verificare: contiene dati personali, chiave API, indirizzo di sistema interno, dati di produzione? Elenca quali aree, se presenti, devono essere mascherate/rimosse. Elaborazione così com'è. Contenuto: [incolla]
tre mini custodie
Caso 1 — Velocità del flusso end-to-end. Un team ha affrontato una nuova funzionalità di “rinnovo dell’abbonamento” con un flusso end-to-end basato sull’intelligenza artificiale: le incertezze sui requisiti sono state segnalate in anticipo, test a tre livelli redatti e convalidati dalle mutazioni, legati all’IC. La funzionalità ha ridotto il ciclo di test, che nel processo tradizionale richiedeva 5 giorni, a 2 giorni; ma l'approvazione umana è stata preservata in ogni fase e un'incertezza sui requisiti (cosa succede se l'aggiornamento fallisce) è stata risolta prima della pubblicazione.
Caso 2: ritorno dalla perdita della chiave. Uno sviluppatore ha chiesto all'IA di generare CI YAML e l'IA ha incorporato una chiave API dall'aspetto reale nello YAML come esempio. La fase di “precontrollo sicurezza/privacy” ha catturato questo aspetto; chiave convertita in riferimento ai segreti. Senza la fase di audit, la chiave finirebbe nel controllo della versione (cronologia git).
Caso 3 — Limite dell'autorità. Un membro del team voleva applicare il test IDOR imparato al sistema live di un partner commerciale tramite "Ero curioso". Il responsabile del QA si è fermato: è illegale eseguire test di sicurezza su un altro sistema senza autorizzazione scritta e ambito definito. I test sono stati eseguiti solo nell'ambiente di test dei propri prodotti, con autorità; La parte responsabile aperta è stata notificata al team competente.
Errori comuni
- Fare in modo che l’IA prenda decisioni sul rilascio. Porre la domanda "Può essere rilasciato?" all'IA e mettendo la risposta al posto della firma.
- "Superamento" del test automatizzato. In CI, far dipingere il test in verde dall'IA; coprire gli errori.
- Fornitura di dati/chiavi confidenziali del veicolo. Condivisione di dati di produzione, dati personali o chiavi API senza supervisione.
- Test di sicurezza non autorizzati. Test dell'autore dell'attacco su un altro sistema senza ambito e autorizzazione.
- Introdurre test nella pipeline senza revisione. Esegui automaticamente lo schizzo AI senza l'approvazione umana.
- Dare la colpa all'intelligenza artificiale. Difendere l'output errato dicendo "L'ha scritto l'AI".
In sintesi
Il QA end-to-end è un processo che si estende dai requisiti al monitoraggio della produzione e vive all'interno di CI/CD; In ogni fase, l’intelligenza artificiale produce bozze, riassume il registro e suggerisce le cause principali. Ma i confini sono immutabili: gli esseri umani prendono decisioni sui test e rilasciano l’approvazione; All’IA non viene mai data l’autorità di “superare” automaticamente il test; i dati riservati e le chiavi non entrano nel veicolo; I test di sicurezza vengono eseguiti solo sul vostro prodotto, nell'ambito dell'autorizzazione scritta e dell'ambito definito, per scopi difensivi, e i risultati vengono riportati con divulgazione responsabile. Sii trasparente quando usi l'intelligenza artificiale; Sei responsabile dell'accuratezza dell'output. L'intelligenza artificiale accelera; Garantisci qualità ed etica.
Compito dell'applicazione
Elabora un piano dall'idea al rilascio con un modello di "piano di test end-to-end" per una funzionalità del tuo progetto; Contrassegnare separatamente il ruolo dell'intelligenza artificiale e dei punti di approvazione umana in ciascuna fase. Quindi genera un YAML con "schema pipeline CI/CD" e applica il "precontrollo sicurezza/privacy" a questo YAML per verificare la presenza di dati chiave/segreti incorporati. Infine, elenca tutti i punti “decisioni umane” nel tuo piano e giustifica in una frase il motivo per cui queste decisioni non possono essere delegate all’IA.
lista di controllo
- [] Attribuisco le decisioni di rilascio e test all'approvazione umana; Non l'ho consegnato all'AI.
- [ ] In CI/CD non ho dato il permesso all'AI di "passare/correggere" automaticamente il test.
- [ ] Ho controllato e mascherato i dati riservati, i dati personali e le chiavi prima di inviarli al veicolo.
- [ ] Ho preso in considerazione solo i test di sicurezza sul mio prodotto, nell'ambito dell'autorizzazione e dell'ambito scritti.
- [ ] Ho affrontato le vulnerabilità riscontrate con il principio della divulgazione responsabile.
- [] Ho dichiarato in modo trasparente di aver utilizzato l'intelligenza artificiale e mi sono ritenuto responsabile dell'accuratezza dell'output.
Esame del modulo
1. Come viene definito più accuratamente il "falso superamento" nel contesto del QA?
- R) Anche se il test diventa verde, in realtà non conferma alcun comportamento; ✔ Non diventa rosso anche se il codice è corrotto
- B) Il test viene eseguito molto lentamente e scade.
- C) Il test rileva un errore reale e diventa rosso
- D) Il test viene eseguito solo nell'ambiente di produzione
Spiegazione: uno pseudo-superato si verifica quando un test dice "superato" ma in realtà non conferma nulla di significativo; Il test è verde, ma anche se il software è difettoso, non lo rileverà. Questo è il rischio numero uno dell’intelligenza artificiale nel QA perché l’intelligenza artificiale tende a produrre test che sembrano puliti ma sono vuoti.
2. Qual è il posizionamento più accurato dell'intelligenza artificiale nel processo di test e QA?
- R) L'intelligenza artificiale può decidere se la versione può essere rilasciata senza l'approvazione umana
- B) L'intelligenza artificiale è un assistente che genera bozze e idee; La decisione e la responsabilità di "è pronto per la pubblicazione" spetta all'esperto ✔
- C) L'intelligenza artificiale scrive solo testo e non può gestire affatto il codice di test
- D) L'intelligenza artificiale scrive sempre test corretti rispetto a quelli umani, quindi la revisione non è necessaria
Descrizione: L'intelligenza artificiale è un assistente ai test, un generatore di bozze e un moltiplicatore di idee; produce scenari di test, codice di automazione e bozze di report. Tuttavia, la responsabilità e l'approvazione finale delle decisioni di qualità come "questo software è pronto per la pubblicazione" o "questo test è stato superato" spetta all'esperto competente.
3. Considerando che gli errori si verificano soprattutto ai valori soglia, quale tecnica di progettazione del test consiste nel testare 17, 18 e 19 separatamente per il limite di età di 18 anni?
- A) Test di transizione di stato
- B) Tabella decisionale
- C) Analisi del valore limite ✔
- D) Test esplorativi
Spiegazione: L'analisi dei valori limite si basa sull'osservazione che gli errori si verificano più frequentemente ai limiti e testa i valori soglia (appena sotto, appena sopra e appena sopra il limite) separatamente. È una tecnica potente che integra le classi di equivalenza.
4. Quale approccio dovrebbe essere preferito nella selezione degli elementi per ridurre la fragilità nel codice di automazione dei test dell'interfaccia utente prodotto con l'intelligenza artificiale?
- A) Utilizzando il percorso XPath più lungo possibile
- B) Selezionare l'elemento in base alla sua posizione in pixel sullo schermo
- C) Utilizzo di selettori basati sui nomi delle classi CSS
- D) Utilizzo degli attributi stabili (data-testid) aggiunti per il test ✔
Spiegazione: i percorsi XPath lunghi e i nomi delle classi CSS dipendono estremamente dalla struttura e dal design della pagina; Si rompe al minimo cambiamento dell'interfaccia. Gli attributi stabili aggiunti specificatamente per i test (ad esempio data-testid) non sono influenzati dalle modifiche di progettazione e rendono i test robusti.
5. Perché per un test API non è sufficiente controllare solo il codice di stato HTTP (ad esempio 200)?
- R) Perché i dati del corpo con il codice di stato corretto potrebbero essere danneggiati e il solo controllo dello stato non sarà in grado di individuare questo problema (pseudo-fiducia) ✔
- B) Perché i codici di stato non sono affatto affidabili nei test API
- C) Perché il controllo del codice di stato rallenta molto il test
- D) Perché il codice di stato non viene mai restituito nei test API
Spiegazione: Sebbene il server restituisca il codice di stato corretto, potrebbe restituire dati danneggiati nel corpo (tipo errato, campo mancante, valore calcolato in modo errato). Il test che guarda solo alla situazione non può vederlo e dà falsa fiducia. Pertanto è necessario aggiungere anche la convalida dello schema/contratto e delle regole aziendali.
6. Perché è fondamentale dire all'IA di "calcolare manualmente il valore atteso in base alla regola di accettazione, di non fare riferimento all'output corrente della funzione" quando si stampano i test unitari?
- R) Perché il calcolo manuale esegue i test più velocemente
- B) Perché altrimenti il test accetta il comportamento attuale (forse difettoso) del codice come "corretto" e conferma il bug ✔
- C) Perché l'intelligenza artificiale non è affatto in grado di calcolare i numeri decimali
- D) Perché le regole di accettazione non vengono mai utilizzate nei test
Spiegazione: Se l'AI ricava il valore atteso dall'output della funzione sotto test, farà 'superare' il test anche se la funzione è difettosa; Cioè, qualunque cosa produca il codice, il test conta come vero. Il calcolo del valore atteso indipendentemente dalla regola di accettazione garantisce che il test sia un guardiano della regola, non uno specchio del codice.
7. Quale delle seguenti è la caratteristica più distintiva di una buona segnalazione di bug?
- A) Essere il più lungo e tecnico possibile
- B) Scritto dall'intelligenza artificiale
- C) Contiene passaggi di riproduzione deterministica che lo sviluppatore può seguire in modo indipendente e produrre l'errore ✔
- D) E' solo uno screenshot
Spiegazione: il vero valore di una segnalazione di bug è che lo sviluppatore può riprodurre il bug senza il tuo aiuto. Ciò è garantito da passaggi di riproduzione deterministici e tracciabili da zero; Se mancano questi passaggi, il report spesso si chiude con la dicitura "impossibile produrre".
8. Qual è l'espressione più corretta per il rapporto tra gravità e priorità nell'errore di ortografia del nome dell'azienda in home page?
- R) Intensità e priorità dovrebbero avere sempre lo stesso valore
- B) Sia la gravità che la priorità di questo errore sono decisamente basse
- C) Gravità e priorità sono lo stesso concetto, una sola etichetta è sufficiente
- D) L'intensità tecnica può essere bassa ma la priorità aziendale (reputazione) può essere alta; I due vengono valutati diversamente ✔
Spiegazione: la gravità è l'impatto tecnico dell'errore (errore di battitura tecnicamente basso), la priorità è l'urgenza con cui deve essere corretto (alta perché è un elemento di reputazione che ogni visitatore vede). I due non vanno sempre nella stessa direzione; Questo esempio è una situazione a bassa gravità e alta priorità.
9. Qual è l'interpretazione più accurata di una suite di test con una copertura di linea del 90%?
- A) Mostra che le linee vengono eseguite ma non prova che si comportino correttamente; ✔ un'elevata copertura può dare falsa fiducia
- B) Dimostra in modo definitivo che il 90% del software è privo di bug
- C) È una misura definitiva di eccellente qualità del test.
- D) Indica che non è più necessario scrivere ulteriori test
Spiegazione: La copertura delle righe indica che sono state eseguite solo le righe; Non dimostra che produca risultati corretti. Anche con test privi di assertività è possibile ottenere una copertura del 90%. Scope è una mappa "mai guardato dove", non una garanzia "tutto è stato testato"; la protezione effettiva viene misurata mediante test di mutazione.
10. Nei test basati sul rischio, come viene calcolato il rischio di una funzionalità per indirizzare uno sforzo di test limitato?
- A) Solo per numero di righe di codice
- B) Moltiplicando la probabilità di guasto e l'effetto che si avrà in caso di guasto ✔
- C) Solo nell'ordine in cui è stata sviluppata la funzionalità
- D) Dare priorità solo alla funzionalità per la quale è più semplice scrivere test
Spiegazione: nei test basati sul rischio, il rischio viene valutato come probabilità = probabilità (probabilità di guasto) × impatto (danno in caso di rottura). I domini ad alta probabilità e ad alto impatto (pagamento, autenticazione) meritano i test più intensi, mentre i domini basso×basso ricevono test leggeri.
11. Qual è il rischio principale di aggiungere un nuovo tentativo a un test che a volte passa e a volte fallisce (fragile/instabile) anche se il codice non è cambiato?
- A) Ridurre la durata del test
- B) Diminuisce la percentuale di copertura
- C) Nascondere un vero errore di concorrenza o una causa principale ed eliminare il sintomo ✔
- D) Modificare il nome del test
Spiegazione: Il nuovo tentativo è uno strumento diagnostico, non un trattamento. L'indecisione spesso deriva da una reale condizione razziale o da una dipendenza; Far 'superare' il test riprovando nasconde questo errore reale e può causare seri problemi dal vivo. Bisogna prima trovare la causa principale.
12. Come funziona il test di mutazione, il metodo più onesto per misurare se una suite di test protegge effettivamente?
- A) Misurando la velocità di esecuzione delle prove
- B) Contando quante righe di codice sono state scritte
- C) Eseguendo i test in ordini diversi
- D) Creando deliberatamente piccole interruzioni nel codice e misurando se i test le rilevano ✔
Descrizione: il test di mutazione produce piccole distorsioni intenzionali (mutazioni) nel codice sorgente; Una buona suite di test dovrebbe rilevare queste distorsioni e diventare rossa. Le mutazioni che non vengono rilevate (sopravvissute) indicano che i test non preservano quel comportamento. Il punteggio di mutazione è una misura della qualità molto più onesta rispetto alla copertura percentuale.
13. Qual è il limite principale da seguire quando si eseguono test di sicurezza (ad esempio test di autorizzazione/IDOR)?
- A) Dovrebbe essere fatto solo sul proprio prodotto, entro l'autorizzazione scritta e l'ambito definito, per scopi difensivi ✔
- B) Può essere liberamente applicato a qualsiasi sistema di interesse
- C) Può essere provato sui sistemi live dei partner commerciali senza autorizzazione
- D) Eventuali vulnerabilità rilevate dovrebbero essere pubblicate pubblicamente immediatamente.
Descrizione: i test di sicurezza appresi in questo modulo servono solo per testare il proprio prodotto a fini difensivi, entro l'autorizzazione scritta e l'ambito definito. Accedere al sistema di qualcun altro senza autorizzazione o eseguire test fuori ambito è sia non etico che illegale; Eventuali vulnerabilità riscontrate vengono segnalate attraverso un'informativa responsabile.
14. Quale autorità non dovrebbe mai essere data all’IA nella pipeline CI/CD?
- A) Riepilogo dei registri dei test falliti
- B) L'autorità di "superare" automaticamente un test fallito (rosso) o di dipingerlo di verde ✔
- C) Suggerire una bozza di codice di prova
- D) Stesura del file YAML della pipeline
Descrizione: l'intelligenza artificiale può produrre una struttura del codice di test, YAML della pipeline e un riepilogo del registro in CI/CD; tuttavia, la possibilità di "superare/correggere" automaticamente un test fallito non dovrebbe mai essere fornita. Ciò vanifica lo scopo del test e nasconde automaticamente gli errori. Dipingere il test in verde dovrebbe essere una decisione consapevole e ragionata di una persona.