Winst:
- Mogelijkheid om snel mogelijke hoofdoorzaken te achterhalen door crashrecords (stacktraces) aan kunstmatige intelligentie te geven met de relevante code en scenariocontext
- Mogelijkheid om de hoofdoorzaak permanent op te lossen in plaats van de diagnose van de AI te valideren als een hypothese in code en het symptoom te testen en tot zwijgen te brengen
- Bescherming van de privacy tijdens het opsporen van fouten door persoonlijke gegevens in crashrecords en logboeken te maskeren
Elke applicatie geeft fouten; Wat een goede ontwikkelaar onderscheidt, is de snelheid waarmee hij bugs vindt en oplost. Mobiel debuggen – het vinden en oplossen van de oorzaak van een probleem – is bijzonder moeilijk omdat de fout optreedt op het apparaat van de gebruiker, in een omgeving die u niet kunt zien. Meestal heb je alleen maar een crashlogboek (crashlogboek / stacktrace - een technisch overzicht van waar de applicatie naartoe ging toen deze crashte). AI is buitengewoon krachtig in het lezen van deze cryptische gegevens, het opsommen van mogelijke oorzaken en het voorstellen van oplossingen. In deze unit leren we hoe we AI kunnen gebruiken als ‘bugdetective’, maar laten we jou de verantwoordelijkheid geven om de uiteindelijke diagnose te verifiëren en op te lossen.
Het crashlogboek lezen: waar AI het helderst schijnt
Een crashlogboek is een lange en intimiderende tekst; onervaren ontwikkelaar weet niet waar hij moet zoeken. AI parseert deze tekst binnen enkele seconden: op welke regel crashte hij, welke uitzondering werd gegenereerd, wat is de mogelijke reden. Veelvoorkomende mobiele fouten zijn duidelijk en de AI herkent ze snel: NullPointerException (probeert toegang te krijgen tot een nulwaarde), IndexOutOfBoundsException (toegang tot een niet-bestaand lijstelement) op Android, EXC_BAD_ACCESS (toegang tot vrijgemaakt geheugen) op iOS, onverwacht nul gevonden (forcering van een nul optioneel).
De meest voorkomende soorten mobiele crashes en hun typische oorzaken zijn als volgt:
Fout (uitzondering)
Platform
typische oorzaak
NullPointerException
Android
Toegang tot een nulwaarde
IndexOutOfBoundsException
Android
Toegang tot een niet-bestaand lijstelement
onverwacht nul bevonden
iOS
Forceer het uitpakken van een nul optioneel (!)
EXC_BAD_ACCESS
iOS
Toegang tot vrijgemaakt geheugen
ANR/bevriezen
Android
Lange/zware bewerking op hoofddraad
Stapsgewijze foutopsporingsstroom:
- Verzamel het record. Stel het crashlogboek, het foutbericht en de stappen samen om het indien mogelijk te reproduceren.
- Geef de AI-context. Vertel me niet alleen de fout, maar ook het relevante stukje code en waardoor het crashte.
- Vraag naar mogelijke oorzaken. "Vertel me de drie meest waarschijnlijke oorzaken en hoe ik ze kan verifiëren."
- Verifiëren. Bevestig de voorgestelde reden in code en testen; Los het niet op door te raden.
- Repareer het en test opnieuw. Controleer of de fout daadwerkelijk verdwenen is en er geen nieuwe fouten zijn gegenereerd.
Tip: Wanneer u het crashlogboek aan de AI geeft, neem dan ook het relevante codefragment op. Alleen met stacktrace doet AI algemene voorspellingen; Als je de code ziet, wordt de kans dat je de exacte regel en de echte oorzaak vindt enorm groter. Context bepaalt de kwaliteit van de diagnose.
Valkuil voor persoonlijke gegevens
Crashlogboeken en logboeken bevatten vaak gebruikersgegevens: e-mail, gebruikers-ID, locatie en zelfs formulierinhoud. Het plakken van dit record in de AI zoals het is, lekt persoonlijke gegevens naar de derde partij en is een overtreding van KVKK/AVG. Wis (masker) persoonlijke gebieden voordat u de opname verzendt. Zorg er ook voor dat u niet vanaf het begin persoonlijke gegevens naar de logboeken van uw toepassing schrijft; Een goed logboek beschrijft het probleem, maar onthult niet de identiteit.
Let op: de oplossing die door de AI wordt voorgesteld, kan de bug tot zwijgen brengen, maar lost mogelijk niet de hoofdoorzaak op. Als u bijvoorbeeld een NullPointerException inpakt met een null-controle, wordt de crash gestopt, maar als u niet weet waarom de waarde null is, blijft de feitelijke logische fout bestaan. Behandel de ziekte, niet het symptoom.
Analyse van de oorzaak
Het doel van professioneel debuggen is niet om de fout tot zwijgen te brengen, maar om de hoofdoorzaak te vinden. Ik vroeg de AI "waarom zou dit nul kunnen zijn, waar zou het verloren kunnen zijn gegaan in de datastroom?" met de vraag: “hoe kan ik dit het zwijgen opleggen?” Het is veel waardevoller dan vragen. Zodra de hoofdoorzaak is gevonden, worden tientallen varianten van dezelfde fout in één keer opgelost. AI is goed in deze ketenredenering: volg de data van input tot output en vraag hem na te denken over waar deze kapot gaat.
drie minikoffers
Geval 1 – 2 uur werk in 10 minuten. Een ontwikkelaar heeft twee uur lang gezocht naar een bug die alleen op een specifiek Samsung-model crashte. Gaf het crashlogboek (het opruimen van persoonlijke gebieden) aan de AI; YZ zei dat de fout wijst op een geheugenoverloop die optreedt bij een andere cameraresolutie van dat apparaat. Met de aanwijzing werd de reden binnen 10 minuten gevonden. AI versnelde de zoektocht, mensen verifieerden de oplossing.
Geval 2 – De tot zwijgen gebrachte bug is terug. Eén team kon een terugkerende crash tot zwijgen brengen door een AI-suggestie te gebruiken om deze te proberen op te vangen. Het crashen stopte, maar gebruikers begonnen te klagen dat "gegevens niet worden opgeslagen"; omdat het echte probleem (databaseverbinding) er nog steeds was, was het gewoon onzichtbaar geworden. Nadat de hoofdoorzaak was gevonden, werden zowel de crash als het gegevensverlies opgelost. Les: zwijgen is geen oplossing.
Geval 3 – Er zijn gegevens gelekt in het logboek. Uit een audit bleek dat de volledige namen en telefoonnummers van gebruikers in de crashlogboeken van de app waren geschreven. Ontwikkelaars plakten deze logs routinematig in de AI en repareerden bugs; Persoonlijke gegevens gaan dus al maanden de deur uit. Logboeken werden gemaskeerd en het proces werd gecorrigeerd. Les: vertrouwelijkheid geldt zelfs bij het debuggen.
Zwakke prompt/sterke prompt
Slechte prompt: "Waarom treedt deze fout op? [Stack Trace]"
Sterke prompt: "Deze crash vindt plaats in mijn Android-app. Context: - Terwijl ik bezig ben: gebruiker voegt toe aan winkelwagen vanuit productdetail - Alleen op sommige apparaten, modellen met weinig RAM - Gerelateerde code: [ViewModel en Repository-gedeelte] - Crashlog (persoonlijke gegevens gewist): [stack trace] Geef een lijst van de drie meest waarschijnlijke hoofdoorzaken. Voor elk: 1) Hoe verifieer ik dit, 2) Permanente oplossing (niet uitzetten). Geef uw veronderstelling aan als u het niet zeker weet. "
Kopieerbare sjablonen
Crashanalysesjabloon: "Analyseer de volgende crash. Context: [wat je doet, welk apparaat/versie]. Relevante code: [code]. Crashlog (persoonlijke gegevens gewist): [trace]. Geef drie meest waarschijnlijke hoofdoorzaken en verificatie + permanente oplossing voor elk. Markeer ook oplossingen die het symptoom tot zwijgen brengen."
Sjabloon voor hoofdoorzaak: "Deze waarde komt onverwachts [null/false]. Volg de gegevensstroom vanaf de invoer tot dit punt: waar kan deze verloren gaan of beschadigd raken? Vertel me waar ik in elke fase moet controleren. [code]"
Sjabloon voor het lezen van logbestanden: "Interpreteer deze loguitvoer: welke gebeurtenissen zijn in volgorde gebeurd, waar is de afwijking, wat was de laatste gezonde stap vóór de fout? [logboek - persoonlijke gegevens gewist]"
Reproductiesjabloon: "Welke stappen, apparaatstatussen en gegevens moet ik proberen om deze fout betrouwbaar te reproduceren? Geef de omstandigheden op die de fout kunnen veroorzaken, in volgorde van waarschijnlijkheid. [beschrijving]"
Veel voorkomende fouten
- Geeft contextvrije stacktrace. Zonder relevante code en scenario’s doet AI algemene voorspellingen.
- Persoonlijke gegevens samen met logs in de AI plakken. Schending van de vertrouwelijkheid; eerst maskeren.
- Leg het symptoom stil. Door de crash te verbergen met try-catch verdwijnt het kernprobleem en ontstaan er nieuwe problemen.
- De eerste suggestie toepassen zonder deze te verifiëren. De diagnose van AI is een hypothese; Bevestig met code.
- Ik probeer het in de emulator te reproduceren. Sommige fouten verschijnen alleen op het daadwerkelijke apparaat/de daadwerkelijke staat.
- Niet opnieuw testen na correctie. De oplossing heeft mogelijk iets anders kapot gemaakt; Controleer regressie.
Samengevat
Een van de gebieden waarop AI uitblinkt, is het lezen van crashlogs en het uitzoeken van mogelijke oorzaken; De kwaliteit van de diagnose wordt aanzienlijk verbeterd als de context wordt gegeven. Maar de uiteindelijke diagnose en correctie behoort de mens toe: de suggestie van de AI is een hypothese, geverifieerd in code en testen. Het doel is niet om het symptoom tot zwijgen te brengen, maar om de oorzaak op te lossen; De tot zwijgen gebrachte fout keert meestal in een andere vorm terug. Crashlogboeken kunnen persoonlijke gegevens bevatten; Maskeer het voordat u het aan AI geeft en schrijf geen persoonlijke gegevens vanaf het begin in uw logs.
Applicatie taak
Neem een crashlogboek dat je hebt (of het voorbeeld dat je genereert met de AI), maskeer eventuele persoonlijke/onderscheidende gegevens daarin en geef het aan de AI met de "Crashanalysesjabloon". Onderscheid welke van de hoofdoorzaken AI-lijsten daadwerkelijke oplossingen zijn en welke alleen maar het zwijgen opleggen. Pas de permanente oplossing toe die u hebt gekozen en controleer of de fout is verdwenen en er zich geen nieuwe problemen voordoen.
controlelijst
- [ ] Ik heb het crashlogboek gegeven met relevante code en scenariocontext
- [ ] Ik heb persoonlijke/onderscheidende gegevens in de logs gemaskeerd
- [ ] Ik vroeg AI om de hoofdoorzaak en om een permanente oplossing, niet om het stilleggen ervan
- [ ] Ik heb de diagnose in code en testen geverifieerd, ik heb deze niet blindelings toegepast
- [ ] Na de oplossing heb ik getest of de fout verdwenen was en er geen regressie was
- [ ] Ik heb gecontroleerd of mijn applicatie geen persoonlijke gegevens in de logbestanden schrijft