Definiera testfall

Senast uppdaterad: 4 maj 2023

Skapat för:

  • Developer
CAUTION
AEM 6.4 har nått slutet på den utökade supporten och denna dokumentation är inte längre uppdaterad. Mer information finns i teknisk supportperiod. Hitta de versioner som stöds här.

Dina testfall ska baseras på följande:

Användningsexempel

  • Dessa definierar den funktionalitet som krävs för interaktionen mellan Actors (roller som initierar vissa åtgärder) och systemet.
  • Användningsärenden ska definieras av kunden.

Detaljerad kravspecifikation

  • Alla funktions- och prestandakrav bör testas.

Provningarna bör tydligt definiera

  • Förutsättningar. dessa kan omfatta specifika system, konfigurationer eller provningsupplevelser.
  • Steg som skall följas. på en lämplig detaljnivå.
  • Förväntade resultat.
  • Tydliga kriterier för godkännande eller fel.

Möjligheten att automatisera testfall är uppenbart attraktiv eftersom den kan eliminera repetitiva uppgifter.

Manuella eller automatiserade tester

Automatisering av testfall är dock en betydande investering, så vissa aspekter bör beaktas:

  • Kräv tid, arbete och erfarenhet för att konfigurera och konfigurera.
  • Om webbläsarbaserade uppdateringar är installerade finns det en ökad risk för problem. behöver ytterligare tid för att korrigera.
  • Det är bara praktiskt för stora projekt.
  • Bra när flera releaser genereras antingen för testning eller i den långsiktiga releaseplanen.

Testa specifika aspekter

När AEM testas är det av särskilt intresse med vissa detaljer:

Skapa och publicera miljöer

Även om det omfattas av Miljö det är värt att betona en avgörande faktor för AEM när det gäller testning.

Du måste överväga AEM som två program:

  • den Upphovsman miljö Den här instansen tillåter författare att ange och publicera innehåll.
    Detta har en liten(er), förutsägbar uppsättning användare, för vilka specifika funktioner och prestanda är avgörande.
  • den Publicera miljö Den här instansen visar webbplatsen i dess publicerade form så att besökarna kan komma åt den.
    Detta har vanligtvis en större uppsättning användare, där trafikvolymen inte alltid är helt förutsägbar. Prestanda är fortfarande avgörande - vid svar på förfrågningar. Cachelagring och lastbalansering måste också beaktas.

Även om de är samma programvara:

  • har olika syften
  • har olika krav på funktionalitet och prestanda
  • har konfigurerats på ett annat sätt
  • justeras separat
  • ska var och en ha sin egen uppsättning godkännandetester

Med andra ord måste de testas separat och med olika testfall.

Personanpassning

Vid testning av personalisering ska varje enskilt användningsfall upprepas med flera användarkonton för att bevisa beteendet.

Cachelagring måste också kontrolleras för korrekt beteende.

Dispatcher

I de flesta projekt installeras Dispatcher för cachelagring och belastningsutjämning.

Testningen är svår (cachelagring sker på olika nivåer och på olika platser) och måste göras i svarta lådor. Viktiga aspekter att testa för är:

  • Noggrannhet; se till att webbplatsbesökaren kan se innehållsuppdateringar.

  • Kontinuitet; se till att webbplatsen fortfarande är tillgänglig när en server stängs av.

  • Kluster Klustren används för att tillhandahålla:

    • Redundans
      Om en server inte fungerar tar andra servrar i klustret över bearbetningen.
    • Prestanda
      Belastningsutjämning med fullständig failover ökar prestanda för ett kluster.

När det används för ett kundprojekt måste klustret testas för att bekräfta att konfigurationen fungerar korrekt.

Testar program från tredje part

Alla tredjepartsprogram som AEM interagerar med kommer att anges i Detaljerade kravspecifikationer.

Alla provningar som krävs (beroende på det definierade omfånget) ska analyseras och rena provningar utföras.

Föregående sida
Nästa sida

Experience Manager