Planning planning

In dit document wordt beschreven wat u moet weten om uw test te plannen. Bovendien moet u deze vragen beantwoorden voordat u de tests uitvoert:

Voordat u begint before-you-start

Voordat u begint met de eigenlijke analyse en definitie van tests, bekijkt u de volgende informatie:

AEM architectuur - Zie Basisconcepten om uzelf te introduceren aan de architectuur en basisbeginselen van AEM.

Documentatie - Raadpleeg een van de documentatiesecties of Hoe kan ik-artikelen voor meer informatie.

Basisbeginselen van tests - U dient op de hoogte te zijn van de basisbeginselen van Software Testing en Quality Assurance. U hebt bij voorkeur ervaring met het testen van projecten.

Er zijn veel websites, boeken en cursussen die met dergelijke beginselen te maken hebben en die zullen dus niet in dit document in detail worden behandeld.

Veronderstellingen om te vermijden - De grootste veronderstelling (die regelmatig wordt gemaakt) is dat uw website miljoenen verzoeken elke dag zal moeten bedienen. In bepaalde omstandigheden kan dit waar zijn, maar het kan niet worden aangenomen.

Hoewel toekomstige getallen niet met 100% nauwkeurigheid kunnen worden voorspeld, geeft het observeren van uw bestaande site en het ervaren verkeer een goede indicatie. U kunt ramingen dan afhankelijk maken van de factor waardoor u verwacht/hoopt het verkeer zal stijgen.

Kwaliteit - Het is van het grootste belang dat iedereen die test neutraal blijft en alleen maar de resultaten van de uitgevoerde tests meldt.

Het is de verantwoordelijkheid van de projectbeheerder om afhankelijk van de resultaten een besluit te nemen over een actie of acties.

Betrokken worden - Hoewel het de verantwoordelijkheid van de projectbeheerder is om ervoor te zorgen dat alle partijen volledig betrokken zijn bij alle vergaderingen (status, workshops, enz.), moet u ook proberen zo vroeg mogelijk in de projectcyclus betrokken te raken, inclusief de processen voor het verzamelen van informatie en het analyseren van de vereisten.

De klant betrekken - Probeer bij een vergelijkbaar thema de klant (waar mogelijk) te betrekken bij het definiëren van uw testcase en -plan.

Typen tests types-of-tests

Er zijn verschillende standaardclassificaties van tests die geschikt zijn voor gebruik bij het testen van een AEM project. U zou met deze moeten vertrouwd zijn om te beslissen welke u zult gebruiken:

Eenheden testen - Tests (gewoonlijk) die door het ontwikkelingsteam worden uitgevoerd om ervoor te zorgen dat de afzonderlijke elementen zich correct gedragen - zij het afzonderlijk.

Integratietests - Tests modules indien gecombineerd. Deze tests worden uitgevoerd na het testen van de eenheid, maar vóór het testen van het systeem.

Rooktests - Dit zijn snelle en vuile tests die worden gebruikt om te bewijzen dat de software actief is en dat functionaliteit op hoog niveau beschikbaar is. De details worden niet getest.

Functionele tests - Deze worden gebruikt om de functionaliteit van de software te testen. Er wordt een serie tests ontworpen om alle functionele details te bestrijken, zowel met verwachte als met onverwachte en/of onjuiste input.

Zwartboxtests zijn functionele tests van een complete eenheid/onderdeel/module, uitgevoerd zonder kennis van de interne werking van het element in kwestie.

Systeemtests - Deze test het hele systeem nadat het volledig is geïntegreerd en op een geschikt platform is geïnstalleerd.

Ze testen de functionaliteit op een black-box-basis.

Prestatietests - Prestatietests zijn van cruciaal belang bij AEM.

Deze worden gebruikt om de prestaties onder verschillende omstandigheden te illustreren:

De resultaten worden vervolgens gebruikt om de toepassing af te stemmen.

Stresstests - Er worden stresstests uitgevoerd om te bevestigen hoe een onderdeel of toepassing zich gedraagt onder extreme omstandigheden. Deze tests worden met name gebruikt om aan te tonen hoe het gedrag verslechtert, wanneer het element zal mislukken - en hoe.

Regressietests - Regressietests worden gebruikt om te bevestigen dat de functionaliteit die al is bewezen in een eerdere versie van de software nog steeds correct werkt.

Regressietests zijn (indien mogelijk) goede kandidaten voor automatisering om ervoor te zorgen dat ze snel en consistent kunnen worden herhaald.

Acceptatietests - Acceptatietests zijn een speciale categorie, omdat ze worden gebruikt om aan te geven dat de klant het project accepteert.

De lijst van goedkeuringstests kan een combinatie van tests van de diverse hierboven vermelde categorieën bevatten, en wordt geselecteerd om te verifiëren dat het project aan de vereisten van de klant voldoet

Zie Aanvaarding en afmelding voor meer informatie .

Aan de slag getting-started

Voordat u begint met uw gedetailleerde testcase en testplan, kunt u:

De doelstellingen definiëren - Definieer uw doelstellingen op hoog niveau om als uitgangspunt te dienen voor fijnafstemming tijdens het testen. U wilt:

onder andere.

Verkeersstatistieken verzamelen van de bestaande website - Deze informatie kan uit de logboekdossiers worden gehaald - zie de Controle van Prestaties voor meer details.

Deze cijfers geven een indicatie van het huidige verkeer (volume en spread) op de bestaande website en kunnen worden gebruikt om een uitgangspunt te vormen voor de nieuwe website.

Verkeersstatistieken verzamelen van externe websites - Indien mogelijk kunt u proberen om verkeersstatistieken van andere websites te verzamelen ter vergelijking, maar deze cijfers worden niet altijd gepubliceerd.

Doelgegevens bevestigen - Metriek worden gebruikt om kwantitatieve metingen voor de kwaliteit van de website te definiëren, aangezien deze de te bereiken prestatiedoelstellingen vertegenwoordigen.

Zij zouden aan het begin van het project, samen met de klant moeten worden bepaald. Zie Doelwaarden voor meer informatie .