Lovable kopplar appen till varje användares egna verktyg – prova med två låtsasanvändare

Två sorters koppling som ser lika ut i början

Lovables dokumentation om app user connectors skiljer mellan två fall. En standardkoppling ansluts en gång av byggaren eller en administratör och använder sedan samma externa konto för alla besökare. En användarkoppling godkänns i stället av varje appanvändare och ska använda den inloggade personens konto och behörigheter.

Det här är också skälet till att appen normalt behöver inloggning innan anslutningsknappen visas: kopplingen måste ha en appidentitet att höra till. Om testperson A och B bara byter namn i samma inloggade session har du inte provat två användare. Du har provat två etiketter på samma användare.

Bygg minsta möjliga funktion

Välj en funktion vars resultat går att se utan tolkning. En lista över dagens kalenderposter fungerar bättre än en sammanfattning som en AI ska formulera, eftersom du då kan jämföra exakt text och tid. Gör inget med riktiga möten. Använd två externa testkonton som du har rätt att använda och lägg in en syntetisk post i varje:

Lovables verifieringsguide säger att en extern Google-app kan byggas och provas med en begränsad grupp testanvändare före verifiering. Det är ett exempel för Google, inte ett löfte om alla leverantörer. Använd därför bara testkonton som den aktuella leverantörens inställning faktiskt tillåter. Frågan om offentlig verifiering hör till lanseringen och ligger utanför det här beteendeprovet.

Bygg en liten kalendervy för inloggade användare.

Varje användare ska kunna ansluta sitt eget kalenderkonto med en app user
connector. När anslutningen finns ska sidan visa dagens kalenderposter med
rubrik, starttid och sluttid. Visa också en knapp för att koppla från kontot.

Om användaren inte är ansluten ska inga kalenderposter visas. Visa i stället
en knapp för att ansluta. Använd inte min byggarkoppling som gemensam datakälla.

Ändra inga andra delar av appen. Förklara efteråt var jag hittar anslutning,
frånkoppling och listan som visar posterna.

Prompten beställer tre synliga lägen: frånkopplad, ansluten med en lista och frånkopplad igen. Provet nedan mäter samma tre lägen. Det är viktigt. Om prompten bara ber om ”kalenderintegration” men provet kräver två separata identiteter har du lagt till ett krav efter bygget och kan inte avgöra om Lovable missförstod eller om kravet saknades i beställningen.

Använd två riktiga sessioner, inte bara två flikar

Öppna appen i två isolerade webbläsarsessioner, exempelvis ett vanligt fönster och ett privat fönster. Logga in som Anna i den ena och Bo i den andra. Kontrollera e-postadressen eller användarnamnet som appen visar innan du ansluter något. Två flikar i samma vanliga fönster kan dela inloggningskakor och då kan båda i praktiken vara Anna.

Skriv resultatet som sex rutor: Anna ser blå, Anna ser inte röd, Bo ser röd, Bo ser inte blå, oansluten ser ingen post, omladdning bevarar rätt resultat. En skärmbild från varje session räcker som arbetsanteckning. För en bredare kontroll av begriplighet med en annan person finns femminuterstestet; den här gången mäter du däremot dataseparation, inte om gränssnittet känns självklart.

Frånkopplingen är ett eget prov

Dokumentationen skiljer tre handlingar som är lätta att blanda ihop. Att återkalla byggaråtkomst stoppar Lovable från att använda ditt konto medan det bygger, men kopplar inte loss personerna i den publicerade appen. Att radera klienten tar bort åtkomsten för alla användare i de länkade projekten. I det här provet ska du inte göra någon av dem. Anna ska använda appens egen knapp för att koppla från sitt konto.

Lovable skriver att en användares frånkoppling återkallar den lagrade token för just den användaren. Det synliga provet kan däremot bara visa följden i appen. Om den blå posten ligger kvar efter omladdning är beteendet underkänt, men om den försvinner har du fortfarande inte bevisat hur varje intern lagringsyta rensades.

Ett godkänt prov är inte en säkerhetsstämpel

Lovable uppger att gatewayen isolerar anslutningar och att en användares åtkomst inte kan användas för att agera som en annan. Tvåanvändarprovet kontrollerar om din färdiga app beter sig i linje med det påståendet i sex avgränsade situationer. Det granskar inte koden, loggarna, databastabellerna, behörighetsreglerna eller alla felvägar.

Lovables guide om tredjepartsdata drar dessutom en tydlig ansvarsgräns: om appen lagrar, loggar, delar eller på annat sätt behandlar uppgifterna som kommer tillbaka ansvarar byggaren fortfarande för åtkomstkontroll, lagring, radering och information till användaren. Börja därför med den bredare guiden om data och inloggning innan du använder riktiga personuppgifter. En teknisk säkerhetsgranskning är en annan uppgift än den här nyhetens synliga prov.

Ändra då en sak i taget och gör om exakt samma sex rutor. Metoden finns utförligare i En sak i taget. Byter du samtidigt autentisering, datakälla och anslutningsflöde vet du inte vilken ändring som löste problemet – eller vilken som skapade nästa.

Testidentiteterna, kalenderposterna och de sex kontrollrutorna är Perestrojkas arbetsmetod, inte Lovables officiella testprotokoll. Artikeln anger inga priser och återger ingen fullständig leverantörslista. Kontrollera Connectors-vyn på ditt eget konto och leverantörens regler den dag du sätter upp provet.