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:
![datasource3[5]](http://www.lgmorand.com/blog/image.axd?picture=datasource3%5B5%5D_thumb.png "datasource3[5]")
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
Souscrire