Dans un test WebTest de Visual Studio Team Test, on peut demander la validation du retour d’une page grâce à une ou plusieurs règles de validation. On pourra ainsi automatiquement valider le temps de réponse, l’url de retour, la présence d’une balise HTML, etc.
Dans le cadre de l’extensibilité de fonctionnalités du framework de test, on a notamment la possibilité de créer de nouvelles règles de validation. De mon point de vue, celle dont l’absence se fait le plus sentir est celle qui permettrait de valider la taille de la page retournée, mais on peut imaginer tout type de règle de validation, selon nos besoins.
Ajouter une telle règle est extrêmement simple. Il suffit de créer une classe qui hérite de la classe abstraite « ValidationRule ».
On surcharge la méthode « Validate » et on implémente la logique de validation. On ajoute les propriétés dont on a besoin et le tour est joué !
Voici un exemple d’implémentation de la règle de validation de taille d’une page :
[DisplayName("Page Size Validation Rule")]
public class PageSizeValidationRule : ValidationRule
{
[DefaultValue(0), DisplayName("Maximum Page Size (Bytes)")]
public int MaxSize { get; set; }
public override void Validate(object sender, ValidationEventArgs e)
{
if (MaxSize > 0 && e.Response.ContentLength > MaxSize)
{
e.IsValid = false;
e.Message = string.Format("The page size ({0} Bytes) was higher than the maximum allowed ({1} Bytes).",
e.Response.ContentLength, MaxSize);
}
}
}
Il suffit de mettre à jour la propriété « IsValid » de l’objet ValidationEventArgs que l’on récupère.
Notez également les attributs au niveau de la classe et de la propriété pour personnaliser le texte qu’on retrouvera dans l’interface d’édition lors de l’ajout de cette règle dans un test web.
Enfin, pour utiliser cette règle, il suffit de référencer la librairie la contenant, elle sera automatiquement detectée par Visual Studio lorsque vous demanderez l’ajout d’une règle sur une requète d’un test web.
.Dispose() ;
Vous savez certainement que les fichiers de test de charge utilisés par Visual Studio sont au format XML. Ce que vous ne savez peut être pas c’est qu’on a la possibilité de paramétrer certains aspects d’un test auquels nous n'avons pas accès graphiquement en modifiant « à la main » ces fichiers, directement dans l’XML.
NB : Pour modifier facilement le contenu XML d’un fichier de LoadTest dans Visual Studio, faire « Clic droit » sur l’élément dans l’explorateur de solutions puis « Open With » > « XML Editor ». Double cliquez sur l’élément dans l’explorateur de solutions pour ré-ouvrez le en mode graphique.
Globalement, un fichier XML de test de charge est structuré de la même manière que ce que l’on retrouve au niveau de l’interface graphique d’édition : en 3 sections (Scénarios, CountersSets, RunConfigurations).
Ce billet est une liste non exhaustive des petites modifications que l’on peut faire, et que je trouve utiles.
1) Adapter le Thinktime au niveau des scénarios de charge
Lorsque l’on utilise la notion « Thinktime » dans un test de charge, on a 2 modes disponibles :
- La distribution réelle, pour laquelle les agents vont simuler le temps de réflexion tel qu’il a été enregistré
- La distribution « normale » pour laquelle on aura un temps de réflexion légèrement varié à chaque requête.
Cette légère variation du mode de distribution normale est définie dans le fichier de description XML. On retrouvera donc un nœud ThinkProfile dans lequel on va pouvoir modifier le maximum de variation qu’on pourra avoir sur chaque thinktime enregistré.
<ThinkProfile Value="0.2" Pattern="NormalDistribution" />
Par défaut la valeur est de 0.2 secondes, a vous de le modifier selon vos besoins.
2) Ajouter un nouveau type de navigateur
Qu’est ce qu’un type de navigateur à simuler ? Tout simplement un ensemble de variables d’entête http à envoyer au serveur.
Si on s’intéresse à celle d’Internet Explorer 7, on peut voir ceci :
<BrowserProfile Percentage="100">
<Browser Name="Internet Explorer 7.0">
<Headers>
<Header Name="User-Agent" Value="Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)" />
<Header Name="Accept" Value="*/*" />
<Header Name="Accept-Language" Value="{{$IEAcceptLanguage}}" />
<Header Name="Accept-Encoding" Value="GZIP" />
</Headers>
</Browser>
</BrowserProfile>
On peut donc très facilement personnaliser un type de navigateur en simulant un Internet Explorer 7 qui n’accepterait que le français en langage. La variable de contexte {{$IEAcceptLanguage}} est liée automatiquement à la configuration de votre navigateur local. On peut donc très bien imaginer modifier ceci et saisir en dur ce que l’on veut :
<Header Name="Accept-Language" Value="fr-FR" />
On peut bien entendu imaginer tout autre type de modification, voir l’ajout d’un type de navigateur non proposé par défaut.
3) Ajouter un nouveau type de réseau
De la même manière que dans le cas du type de navigateur simulé, le type de réseau est modifiable directement via le fichier XML.
Qu’est-ce qu’un type de réseau ? Tout simplement une vitesse de transfert.
<NetworkProfile Percentage="100">
<Network Name="LAN" BandwidthInKbps="0" />
</NetworkProfile>
On remarque ici que 0 signifie illimité. On peut donc très facilement modifier cette valeur pour obtenir exactement le débit que l’on veut simuler.
4) Sauvegarder un set de compteurs
Une opération récurrente et assez rébarbative lorsque l’on effectue des tests de charge est de créer les sets de compteurs que l’on va vouloir suivre tout au long du test. D’autant plus que ces sets sont très souvent les mêmes en fonction du type d’application que l’on charge.
Via l’édition XML pas de problème ! On peut très facilement sauvegarder dans un fichier texte ses sets de compteurs et les réutiliser dans n’importe quel autre test en les copiant directement dans l’XML.
<CounterSet Name="IIS" CounterSetType="IIS">
<CounterCategories>
<CounterCategory Name="Network Interface">
<Counters>
<Counter Name="Bytes Received/sec" />
<Counter Name="Bytes Sent/sec" />
</Counters>
<Instances>
<Instance Name="*" />
</Instances>
</CounterCategory>
</CounterCategories>
<DefaultCountersForAutomaticGraphs>
<DefaultCounter CategoryName=" Network Interface " CounterName="Available MBytes" InstanceName="" GraphName="" />
</DefaultCountersForAutomaticGraphs>
</CounterSet>
On remarque au passage que c’est à cet endroit que sont définis les graphiques par défaut, donc si vous sauvegardez un set de compteurs, vous sauvegardez sa présentation également !
On peut évidemment modifier d’autres paramètres directement dans le fichier XML mais la plupart de ces modifications peuvent également être faites via l’interface graphique.
Une dernière chose : Il existe des templates par défaut qui sont ceux présents lors de la création d’un nouveau test de charge, notamment pour les sets de compteurs et les types de navigateurs/réseaux. Vous pouvez facilement modifier ces templates en modifiant les fichiers contenant les « morceaux » d’XML. Ils sont situés ici : <root>:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Templates\LoadTest dans les répertoires « Browsers », « CounterSets », « Networks ».
En espérant que tout ceci pourra vous être utile ! :-)
.Dispose() ;
Vous êtes intéressés par les tests de montées en charge et l'optimisation de d'applications via le profiling ?
Venez assister le 25 Juin 2008 à une présentation sur le sujet à l'occasion d'un petit déjeuner technique que j'anime avec Florent Santin, manager du pôle Génie logiciel et Team System de Winwise dont je fais partie.
Vous pourrez découvrir comment :
- Modéliser des tests web fonctionnels
- Mener une campagne de charge
- Analyser les résultats
- Automatiser l'exécution des campagnes
- Analyser les performances via l'outil de Profiling
N'hésitez pas à vous inscrire, directement sur le site de Winwise, où vous retrouverez tous les détails de cette présentation : http://www.winwise.fr/articles/petitsdejeuners.aspx
Pour information, le pôle Business Intelligence/Data de Winwise organise également un petit déjeuner sur le produit Performance Point Server 2007 le 2 Juillet 2008. Vous trouverez des informations sur cet évennement à la même adresse.
Ces petits déjeuners auront tous les deux lieu dans les locaux de Microsoft (148, rue de l'université 75007 PARIS).
Si vous êtes intéressés par la création de tests et plus particulièrement de tests de charge pour une application WCF, j'ai rédigé un article traitant du sujet. Il vient d'être publié sur le site de la MSDN (merci à Eric Le Loc'h et Lucas Riedberger) et vous pouvez le retrouver à l'adresse suivante : http://msdn.microsoft.com/fr-fr/teamsystem/cc535009.aspx
L'article couvre la création de tests unitaires pour un service WCF, soit manuellement, soit à l'aide de l'outil WCF Load Test (http://www.codeplex.com/WCFLoadTest), mais également la création d'un test de charge qui les exploite et les indicateurs qui vous permettront d'analyser les résultats.
Certaines parties de l'article sont générales à tout type de test de charge et sont susceptible de vous intéresser même si vous n'envisagez pas un test d'application WCF spécifiquement.
.Dispose();
Visual studio Team Edition for Software Testers offre la possibilité de revenir sur un rapport de test de montée en charge si on a conservé les données dans la base 'LoadTest' et le fichier XML .trx qui définit la mise en forme et les compteurs concernés par ce test.
Load Test Report Generator est un projet à été débuté sur codeplex depuis bientôt 1 an. L'idée est de pouvoir exploiter les données issues de la base dans laquelle sont stockés les résultats des tests. Grâce à cet ensemble d'outils, on peut générer de nouveaux rapports, plus complets et surtout réutilisables en s'appuiant sur des Requêtes Reporting Services. Le grand avantage par rapport à l'éditeur de rapport intégré à Visual Studio est qu'on peut créer des rapports Multi-Exécution de tests (ce que je trouve extrêmement intéressant) !
Depuis quelques jours, un nouvel outil est venu compléter ce "pack". Il permet de générer des rapports au format HTML, MHT et Doc le tout configuré via une application windows forms.
Dès que j'ai le temps, j'écrirais un article de test plus en détails de ces outils.
Le projet sur codeplex : http://www.codeplex.com/loadtestreports
.Dispose();
James Whittaker, un des principaux architectes de Visual Studio Team Edition for Software Testers, nous parle avec passion de sa vision des tests d'applications lors d'une interview sur Channel9.
Il met notamment en avant le manque d'outils et l'inaboutissement de ceux existant qui ne donnent pas toutes les armes aux chasseurs de bugs :-)
Voir l'interview sur channel9 (13min.)
.Dispose();
Lorsque l'on écrit une méthode d'un test unitaire, on a la possibilité de lier automatiquement la méthode à une source de données. Lors son exécution, le test sera lancé autant de fois qu'il y a d'enregistrements dans la table de la source liée et les valeurs de la ligne courante seront récupérables via des variables de contexte du test.
Lorsque ce test unitaire est inclu dans un test de charge et que certaines exécution du test unitaire échouent lors de l'exécution du test de charge, le détail des erreurs n'est pas stocké dans le Repository, et on y a pas accès (Dans Tables > Tests > Click sur le nombre de test "Failed").
Ce bug semble résolu dans la version 2008.
Si quelqu'un à une solution pour la version 2005, qu'il n'hésite pas à en faire part dans les commentaires :-)
.Dispose();
MSLive.fr vient "d'ouvrir ses portes".
En concordance avec la sortie de la ligne de produit 2008 de Microsoft, 3 personnes ont décidé de mettre en place un site communautaire pour partager leur connaissance des produits Microsoft. Plutôt orienté administration et non développement, je vous invite tout de même à aller y jeter un coup d'oeil.
Je leur souhaite bonne chance dans leur aventure :-)
Lorsqu'on créé un test web, il y a parfois des requêtes qui font partie de l'application en production et qu'on aimerait ne pas exécuter lors d'un test. C'est par exemple le cas des pages de partenaires, des pages de publicités, etc.
Pour éviter cela, on créé en général le test et on passe ensuite en revue l'ensemble des requêtes de celui-ci pour supprimer le superflu.
Dans ma quête perpétuelle de simplification de ma vie quotidienne, je me suis dis qu'on pouvait faire plus simple et surtout moins manuel. La solution que je vous propose est de créer un plugin de test web pour intercepter les requêtes indésirables et ne pas les exécuter.
La création d'un plugin de test web est très simple. Il suffit de créer une classe qui dérive de Microsoft.VisualStudio.TestTools.WebTesting.WebTestPlugin.
On a alors la possibilité d'interagir à plusieurs moments de l'exécution d'un test :
- Avant et après l'exécution du test (redéfinir les méthodes PreWebTest et PostWebTest)
- Avant et après l'exécution de chaque requête du test (redéfinir les méthodes PreRequest et PostRequest)
Une fois ces méthodes redéfinies, on créé une instance du plugin de test dans le test qui doit l'utiliser et on abonne une ou plusieurs de ces méthodes aux événements correspondant dans ce dernier.
Commençons par créer le squelette de notre plugin de test (de préférence dans une belle librairie de classes, pour pouvoir la réutiliser facilement dans toutes nos solutions de tests).
using Microsoft.VisualStudio.TestTools.WebTesting;
public class WebTestFilterPlugin : WebTestPlugin
{
public override void PreRequest(object sender, PreRequestEventArgs e)
{
//Here will be the filtering code base.PreRequest(sender, e);
}
}
Pour ce plugin, nous avons besoin d'interagir avant chaque requête, nous avons donc besoin de ne redéfinir que la méthode PreRequest.
La classe PreRequestEventArgs offre un certain nombre de moyen d'intervenir sur la requête qui est sur le point de s'exécuter. On peut modifier la méthode HTTP utilisée, le thinktime simulé, le temps d'exécution avant de lever un timeout, etc. Ce qui nous intéresse pour notre filtre est la propriété Instruction. C'est une énumération qui permet d'indiquer si on doit exécuter ou abandonner la requête.
Voici la version complète du plugin :
public class WebTestFilterPlugin : WebTestPlugin
{
private List<string> _filters = new List<string>();
public List<string> Filters
{
get { return this._filters; }
set { this._filters = value; }
}
public override void PreRequest(object sender, PreRequestEventArgs e)
{
foreach (string filter in this.Filters)
{
if (e.Request.Url.Contains(filter))
{
e.WebTest.AddCommentToResult(string.Format("Request {0} has been skipped", e.Request.Url));
//Skip the request
e.Instruction = WebTestExecutionInstruction.Skip;
}
}
base.PreRequest(sender, e);
}
}
Le fonctionnement du plugin est très simple. Il possède une liste de chaînes de caractères et annule l'exécution des requêtes dont l'url contient un des filtres.
L'utilisation dans un test web est la suivante :
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.VisualStudio.TestTools.WebTesting;
using Microsoft.VisualStudio.TestTools.WebTesting.Rules;
using WebTestPlugins; //The plugin library we created
public class FilterPluginDemoCoded : WebTest
{
private WebTestFilterPlugin filterplugin = new WebTestFilterPlugin();
public FilterPluginDemoCoded()
{
this.PreAuthenticate = true;
//Register the plugin to the web test event(s)
this.PreRequest += new EventHandler<PreRequestEventArgs>(filterplugin.PreRequest);
filterplugin.Filters.Add("prodserver");
}
public override IEnumerator<WebTestRequest> GetRequestEnumerator()
{
WebTestRequest request1 = new WebTestRequest("http://prodserver/index.html");
yield return request1;
request1 = null;
WebTestRequest request1 = new WebTestRequest("http://testserver/index.html");
yield return request1;
request1 = null;
}
}
Vous l'avez deviné, ici seule la requête http://testserver/index.html sera exécutée.
On peut ensuite imaginer plusieurs améliorations, comme par exemple ne filtrer que sur les noms de domaines plutôt que sur l'intégralité de l'url ou encore de permettre l'utilisation d'expressions régulières.
Pour plus d'informations sur les plugins de test web et sur les tests dans Visual Studio en général, je vous invite à consulter la documentation de la MSDN : http://msdn2.microsoft.com/en-us/library/ms182409(VS.80).aspx
Edit : Désolé pour la mise en page bizzare pour le code, j'ai voulu tester la fonction publish de Word 2007 et on dirait bien que je ne maîtrise pas encore toutes les subtilités ;-)
Hello à tous,
Je sais, un seul billet en 3 mois, c'est pas énorme, mais je compte bien y remédier, et je commence de suite :-)
Vous le savez certainement les résultats d'un test de charge effectué avec Visual Studio (2005/2008) Team Test peuvent être sauvegardés pour être consultés ultérieurement. Les informations contenant ces résultats sont stockés à la fois dans une base SQL Server et dans un fichier XML d'extension .trx contenant des informations complémentaires.
Imaginons la situation suivante : vous effectuez un test de charge à partir de votre machine et vous voulez transmettre les résultats à un ami/collègue pour qu'il puisse les consulter. Vous lui donnez la solution contenant les tests ainsi que les .mdf et .ldf de la base de données et les fichiers trx. Il monte la base de données dans un SQL Server local, il configure le Test Controller pour qu'il utilise la bonne chaîne de connexion, il charge le fichier .trx et il se retrouve nez à nez avec un magnifique message d'erreur :
"Could not read result repository: Could not access the load test results repository: Une erreur s'est produite lors de l'établissement d'une connexion au serveur. Lors de la connexion à SQL Server 2005, cet échec peut être dû au fait que les paramètres par défaut de SQL Server n'autorisent pas les connexions à distance. (provider: Interfaces réseau SQL, error: 26 - Erreur lors de la localisation du serveur/de l'instance spécifiés)"
Malgré l'effort visible de messages d'erreur apparement issus de source différentes, on peut avoir du mal à trouver l'origine du problème instantanément...
La raison est en fait la suivante:
La chaîne de connexion définissant le repository est encryptée et stockée dans le champ XML "resultsRepositoryConnectString" de la balise <LoadTestResult ... /> des fichiers .trx. Elle est générée lors du test et correspond donc au informations de connexion à la source de données sur la machine de test.
La solution que je vous propose est la suivante. Sur la machine d'où vous voulez consulter les résultats et dans la solution utilisée pour les tests :
- Configurer la chaîne de connexion correcte au niveau du Test Controller
- Créer un faux test de charge (Un webtest sur un petit fichier html local dans un LoadTest)
- L'exécuter et l'arrêter dès que possible (choisir d'enregistrer les résultats)
- Ouvrir le fichier .trx généré, copier la valeur du champ "resultsRepositoryConnectString"
- Ouvrir le fichier .trx que vous voulez consulter, remplacer la valeur du champ "resultsRepositoryConnectString" avec celle du .trx qui vient d'être générer
- Charger le fichier corrigé dans Visual Studio et le tour est joué !
C'est un peu fastidieux à mettre en oeuvre et si quelqu'un à une autre solution, qu'il n'hésites pas à l'indiquer en commentaire !
Voilà mon blog tout neuf (merci nix :)). Je vais essayer de poster assez régulièrement sur mes découvertes autour de l'uinvers .NET et des infos que je trouve intéressantes.
On commence avec une première news intéressante, l'apparition de 6 webcast sur la prise en main d'Expression Web, le tout en français.
(Source : msdn).
Les 10 derniers blogs postés
-
ssdl view et TPT par
Matthieu MEZIL le il y a 16 heures et 1 minutes
-
L'injection SQL n'est PAS un problème QUE pour les développeurs web ! par
CoqBlog le il y a 16 heures et 57 minutes
-
Un outil pour réaliser des animations WPF basées sur des équations de Bézier par
Perspective le il y a 20 heures et 20 minutes
-
Sandcastle et CodePlex : le verdict par
CoqBlog le il y a 21 heures et 11 minutes
-
ssdl view et TPH par
Matthieu MEZIL le il y a 22 heures et 53 minutes
-
Webcasts sur le Parallel Framework disponibles par
Matthieu MEZIL le 07-04-2008, 17:26
-
[Silverlight] - Comprendre et Débuter avec Silverlight par
Danuz le 07-04-2008, 12:41
-
SharePoint : Nouvel article sur l'exportation et Importation de sites SharePoint par
Blog Technique de Romelard Fabrice le 07-04-2008, 01:00
-
ImagineCup 2008 Final in Paris: Day 1 par
Richard Clark le 07-03-2008, 22:48
-
PowerShell : Comment utiliser un ENUM .NET dans un script PowerShell par
Blog Technique de Romelard Fabrice le 07-03-2008, 18:09
