L’une des grandes forces des tests de charges réalisés à l’aide de Visual Studio Team Test est d’être paramétrables via des sources de données. Qu’il s’agisse de l’URL d’une requête, de paramètres GET/POST ou bien même d’un fichier à uploader, chaque donnée peut être rendue dynamique à chaque exécution du test simplement en définissant une (ou plusieurs) source de données. Pour cela, rien de bien compliqué, un simple clic droit sur votre Web Test > Ajouter une source de données et il ne vous reste plus qu’à choisir parmi une source de données SQL, un fichier CSV ou bien un fichier XML.

Cette source de données sera donc liée à votre test qu’il soit exécuté de façon unitaire ou bien de façon groupée lors d’un test de charge. La chose intéressante est qu’il est possible de paramétrer la façon dont cette source de données sera utilisée. Il existe quatre méthodes d’accès telles qu’affichées sur la capture suivante:

Chacune d’entre elle va permettre d’agir différemment à chaque itération du test web.

Do Not Move Cursos Automatically: (nouveauté de Visual Studio 2010). Comme son nom l’indique le curseur ne change pas d’enregistrement automatiquement et reste sur la première ligne. C’est au développeur d’appeler la méthode pour passer à l’enregistrement suivant de façon explicite

Random: Comme son nom l’indique, chaque accès retourne un enregistrement de façon aléatoire.

Sequential: Ici, la source de données est accédée de façon séquentielle ce qui signifie que chaque fois que la source de données est appelée, c’est l’enregistrement suivant qui est retourné. Une fois le curseur arrivé au bout des enregistrements, il repart du premier enregistrement et ainsi de suite jusqu’à ce que le test de charge s’arrête.

Unique: Cette option une version séquentielle avancée qui garantit que chaque enregistrement ne sera utilisé qu’une seule fois. Le fonctionnement est identique à l’accès séquentiel mais une fois au bout des enregistrements, le test s’arrête. Très utile pour les processus de création utilisant des ID uniques par exemple.

Ces options marchent de la même façon lorsque vous utilisez plusieurs agents. Pour Random et Sequential, chaque agent se reçoit une copie propre de la source de données (déployée automatiquement) mais pour Unique, la source est déployée tout en garantissant que chaque enregistrement ne soit utilisée qu’une seule fois quelque soit le nombre d’agents.

Ces options sont bien utiles mais ne répondront pas à tous les cas de figures dont vous pourriez avoir besoin. Ainsi, il m’est arrivé de rencontrer le cas où chaque source de données pouvait être utilisée de façon séquentielle mais tout en garantissant qu’à un moment donné, l’enregistrement ne puisse pas être utilisé plusieurs fois (il s’agissait de credentials de session qui devait être unique à un moment T). Pour cela, il me fallut utiliser la notion de drapeau (flag) pour indiquer qu’un enregistrement était utilisé à ce moment. Dans le cas où la donnée était utilisée, je passais à l’enregistrement suivant.

Un autre cas de figure, dont parle Sean Lumley sur son blog, est le cas où vous voulez que vos donnés soient partitionnées de façon égale entre vos agents, chacun ayant son “sac” de données propre. Ici, la solution consiste à gérer soit-même l’appel aux données et ne retourner que les lignes qui concerne l’agent en cours, principalement grâce à une petite formule mathématique utilisant un modulo. Vous placez le tout dans un Web Plugin que appelez en début de test unitaire et le tour est joué.

Voici le code de Sean pour résoudre cette problématique

using Microsoft.VisualStudio.TestTools.WebTesting;
namespace Example
{
    public class DatasourcePlugin : WebTestPlugin
    {
        static int counter = 0;        
 

        public override void PreWebTest(object sender, PreWebTestEventArgs e)
        {
            while ((counter++ % e.WebTest.Context.AgentCount) != (e.WebTest.Context.AgentId - 1))
            {
                e.WebTest.MoveDataTableCursor("DatasourceName", "TableName");
            }
        }
    }
}

Cette le sensiblement le même principe que vous appliquerez avec l’option Do Not Move Cursor Automatically, en appelant la méthode MoveDataTableCursor(). Bien entendu les deux chaines DataSourceName et TableName sont à éditer en fonction des noms que vous avez donné aux données que vous souhaitez remonter.

Pour créer un Web Plugin, un petit tutoriel se trouve sur la MSDN.

Bien sûr vous trouverez d’autres cas où il vous faudra ruser pour simuler vos tests comme il se doit mais le modèle de test donne suffisamment de liberté pour que toute chose soit possible.

Si vous avez des astuces à partager, je

Si jamais vous avez l’habitude de mettre en place une plateforme de test de charge et que vous avez industrialisé ces tests pour les faire tourner à chaque nouvelle version d’une application, vous êtes peut-être déjà tombé sur l’erreur indiquant que la base de données stockant les résultats de test de charge est pleine: “Error occurred running test. Result collection stopped due to the following error: The load test results repository is out  of space”.

Deux solutions s’offrent alors à vous:

• le nettoyage par le vide
• le nettoyage sélectif

Solution 1: le nettoyage  par le vide.

Le principe n’est pas réellement de tout supprimer mais de jeter tous les résultats de campagne ayant plus de N jours. Avec cette solution, nous gagnons “rapidement” beaucoup de place dans notre base de données pour ne garder que les toutes dernières campagnes. Cette solution se fait tout simplement par l’exécution d’un script SQL que vous trouverez un peu partout sur le net (notamment sur le blog de Bill Barnett) et qui peut être personnalisé sur le nombre de jours de résultats à gagner.

-- This script deletes all load test run older than two weeks
-- To change the timeframe, change the number of days from 14 to the desired number

USE LoadTest
DECLARE @LoadTestRunId int
DECLARE OldLoadTestsCursor CURSOR FOR
    SELECT LoadTestRunId FROM LoadTestRun WHERE datediff(dd, StartTime, getdate()) > 14

OPEN OldLoadTestsCursor
FETCH NEXT FROM OldLoadTestsCursor INTO @LoadTestRunId

WHILE @@FETCH_STATUS = 0
BEGIN
    EXEC Prc_DeleteLoadTestRun @LoadTestRunId
    FETCH NEXT FROM OldLoadTestsCursor INTO @LoadTestRunId
END

CLOSE OldLoadTestsCursor
DEALLOCATE OldLoadTestsCursor

/!\ A noter que ce script est très lent et peut prendre plusieurs heures!

Solution 2: le nettoyage sélectif

Si la première solution permet de répondre à un gain de place, elle a pour problématique majeure de ne pas permettre de la sélection des éléments que l’on supprime. La seule chose qu’il nous faudrait c’est donc une simple IHM permettant de visualiser les résultats de campagnes et pourquoi gérer certains d’entre eux pour soit les supprimer, soit les exporter.

Et par le plus grand des hasards, c’est exactement ce que nous propose Visual Studio! Puis y accéder, ouvrez un test de charge (fichier loadtest) et à l’aide du bouton droit, choisissez Open and Manage Results dans le menu contextuel.

Une fenêtre s’ouvre à vous permettant de filtrer tout d’abord par contrôleur (si vous en avez un), puis par test de charge. Ceci vous affiche alors toutes les campagnes terminées ou non, et vous permet d’agir sur chacune d’entre elles. Dans notre cas il suffit de sélectionner les campagnes à supprimer (ctrl + clic) puis de cliquer sur Remove. Comme le script plus haut, plus la campagne a enregistré d’information, plus la suppression est longue.

Ce process est encore plus lent que la première solution mais permet réellement de ne garder que ce que l’on souhaite.

Ces deux solutions permettent de corriger de façon temporaire notre problème de place disponible mais si vous voulez exécuter des campagnes de façon pérenne et éviter que l’erreur ne se déclenche en plein de milieu de campagne (vous obligeant à recommencer de zéro), pensez à revoir le sizing de la base de données. Par défaut, Visual Studio s’installe avec SQL Express qui limite la taille des bases de données à 4Go. Envisagez-donc d’utiliser SQL Server.