Zephyrnet-logo

Dekkingsanalyse in Questa Visualizer

Datum:

Dekkingsanalyse is hoe u de vraag "heb ik genoeg getest?" beantwoordt. U hebt een manier nodig om de volledigheid van onze tests te kwantificeren; dekking is hoe je dat doet. Direct uit de poort is dit een beetje bedrieglijk. Om echt een ontwerp te dekken, zouden onze tests elke toegankelijke staat en staatsovergang moeten dekken. De complexiteit van die taak roept routinematig vergelijkingen op met het aantal protonen in het universum, dus in plaats daarvan gebruik je proxy's voor dekking. Elke regel in de RTL aanraken, elke tak uitoefenen, elke functie, elke bewering enzovoort. Elk is verre van uitputtende dekking., maar als heuristieken werken ze verrassend goed.

Waar begint de op dekking gebaseerde analyse?

Toegegeven dat testen niet uitputtend kan zijn, het moet op zijn minst compleet zijn tegen een specificatie op hoog niveau, het moet redelijk uniform zijn (geen gaten) en het moet efficiënt zijn.

Specificatiedekking wordt bepaald door het testplan. Elke eis in de specificatie moet worden toegewezen aan een overeenkomstige sectie in het plan, wat op zijn beurt meerdere subvereisten zal genereren. Alle functionele testen beginnen hier. Dekking op dit niveau is afhankelijk van architectuur en ontwerpexpertise bij het bepalen van het testplan. Het kan ook vaak gebruikmaken van eerdere testplannen en leren van eerdere ontwerpen. Tussen expertise en hergebruik bouwen productteams vertrouwen op dat het testplan de specificatie adequaat dekt. Dit proces is enigszins subjectief, hoewel traceerbaarheidsanalyses waardevolle kwantificering en controleerbaarheid hebben toegevoegd bij het verbinden tussen vereisten en testplannen.

Testen en dekkingsanalyse vallen vervolgens hiërarchisch uiteen in implementatietestontwikkeling, en dat is waar de meesten van ons beginnen na te denken over dekkingsanalyse. Elk regelitem in het testplan wordt toegewezen aan een of meer functionele tests. Deze zullen worden aangevuld met implementatiespecifieke tests rond volledigheid en sequencing voor besturingssignalen, registers, test- en debug-infrastructuur, enzovoort.

Implementatiedekking verfijnen

Hier worden uniformiteit en efficiëntie belangrijk. Wanneer je begint met het schrijven van tests, schrijf je ze om het testplan en de bekende big-ticket implementatietests te dekken. U denkt nog niet veel na over implementatiedekking. Op een gegeven moment begin je aandacht te besteden aan de dekking en besef je dat er grote gaten zijn. Stukjes code die helemaal niet worden gedekt door uw testen. Natuurlijk is uitputtend testen niet mogelijk, maar dat is geen excuus om code die je meteen kunt zien in een dekkingsanalyse niet te testen.

Vervolgens voegt u nieuwe tests toe of hergebruikt u oude tests van een eerder ontwerp. U voegt beperkte willekeurige tests toe, allemaal om de dekking te vergroten, hoe u deze ook wilt meten (meestal over meerdere statistieken: functie, lijn, vertakking bijvoorbeeld). Het doel hier is om een ​​redelijk uniforme dekking over het ontwerp naar een haalbaar niveau te brengen, zonder onverklaarbare hiaten.

Efficiëntie is ook belangrijk. Vrij snel (hoop ik) kom je op een punt waarop het toevoegen van meer tests de dekking niet veel lijkt te verbeteren. U wilt natuurlijk de weinige speciale tests vinden die u kunt toevoegen die uw dekking verder zullen verbeteren, maar u wilt ook weten welke tests u kunt laten vallen. Omdat ze u dure regressie-runtime kosten zonder enig voordeel bij te dragen aan de verbetering van de dekking.

Questa Visualizer voegt dekkingsanalyse toe

Het moet duidelijk zijn dat dekkingsanalyse de leidende maatstaf is voor volledigheid bij verificatie. Questa heeft onlangs dekkingsvisualisatie uitgebracht in hun Visualizer-product om u te begeleiden bij de analyse en optimalisatie van de dekking, tijdens verificatie en foutopsporing. Ontdek meer.

Deel dit bericht via:

spot_img

Laatste intelligentie

spot_img