C'est un problème commun. Je ferais attention à:
Comment vous nommez les éléments
Utilisez id ou classe css pour identifier les éléments. Privilégiez l'utilisation de l'ID CSS lorsque l'objet est unique. Tenez compte du cadre que vous utilisez, par exemple avec Ruby on Rails, l' nameattribut est attribué automatiquement et peut (de manière non intuitive) être meilleur que d'utiliser l'ID ou la classe CSS
Comment vous identifiez les éléments.
Évitez les identificateurs de position comme table/tr/td/tden faveur de formes telles que td[id="main_vehicle"ou td[class='alternates']. Envisagez d'utiliser des attributs de données lorsque cela est approprié. Encore mieux, essayez d'éviter les balises de mise en page telles que <td>tout à fait.Pour ce qui précède, vous pouvez soit ajouter une étendue et l'utiliser, par exemple, <span id="main_vehicle">soit un sélecteur générique tel que *[id="main_vehicle"]où *pourrait maintenant être un div, une étendue, un td, etc.
Utiliser des attributs de données spécifiques au test qui ne sont utilisés que pour qa et les tests.
Évitez la qualification inutile des éléments. Vous pourriez vous retrouver en utilisant les éléments suivants:
body.main div#vehicles > form#vehicle input#primary_vehicle_name
Cependant, cela nécessite que le champ de saisie reste dans un formulaire avec un identifiant exact de véhicule et sur une page avec un corps qui a une classe de principal et un div avec un identifiant de véhicules qui a un enfant immédiat d'un formulaire avec un identifiant de véhicule. Tout changement à l'une de ces structures et le test échoue. Dans ce cas, vous pourriez constater que
input#primary_vehicle_name
est suffisant pour identifier l'élément de manière unique.
Évitez les tests qui font référence à du texte visible. Le texte de la page qui est présenté à l'utilisateur change généralement au fil du temps au fur et à mesure que le site est mis à jour et mis à jour, utilisez donc des identifiants tels que css id et css class ou des attributs de données. Des éléments tels que form, inputet selectutilisés dans les formes sont aussi bonnes parties d'éléments d' identification, généralement en combinaison avec id ou de classe, par exemple , li.vehicleou input#first-vehicle
vous pouvez également ajouter vos propres identifiants, par exemple <div data-vehicle='dodge'>. De cette façon, vous pouvez éviter d'utiliser les ID d'élément ou les classes, qui sont susceptibles d'être modifiés par les développeurs et les concepteurs. Au fil du temps, j'ai trouvé qu'il valait mieux travailler avec les développeurs et les concepteurs et s'entendre sur les noms et les étendues. C'est difficile.
Comment les données fixes sont maintenues.
Semblable à l'identification d'éléments réels, essayez d'éviter que le sélecteur en ligne codé en dur n'identifie les valeurs en faveur des objets de page - de petits morceaux de texte qui sont conservés dans des variables ou des méthodes et peuvent ainsi être réutilisés et également gérés de manière centralisée. Exemples de variables javascript suivant ce modèle pour les valeurs codées en dur:
storedVars["eqv_auto_year"] = "2015";
storedVars["eqv_auto_make_1"] = "ALFA ROMEO";
storedVars["eqv_auto_make_2"] = "HONDA";`
Plus d'informations sur les objets de la page sur le sélénium wiki et les documents sur le sélénium
Communication avec les développeurs.
Indépendamment de l'approche technique en termes de «développeurs apportent des modifications et cassent l'automatisation de l'assurance qualité» qui est un problème de workflow. Vous devez vous assurer que: tout le monde est la même équipe; le développeur exécute les mêmes tests intégrés; les normes sont convenues et suivies par les deux groupes; la définition de done comprend l'exécution et éventuellement la mise à jour des tests d'interface utilisateur; Les développeurs et les testeurs s'appuient sur des plans de test et assistent tous deux au toilettage des tickets (si vous faites Agile) et parlent des tests d'interface utilisateur dans le cadre du toilettage. Vous devez vous assurer que l'approche et la stratégie que vous utilisez pour nommer sont coordonnées avec les développeurs d'applications. Si vous n'obtenez pas sur la même page, vous aimerez affronter la dénomination des objets. Quelques exemples de méthodes d'objet de page que j'ai récemment créées pour un projet ruby:
def css_email_opt_in_true
'auto_policy[email_opt_in][value=1]'
end
def css_phone_opt_in
'*[name="auto_policy[phone_opt_in]"]'
end
def css_phone_opt_in_true
'input[name=phone_opt_in][value=true]'
end
def css_credit_rating
'auto_policy[credit_rating]'
end
Voici les mêmes objets de page que les variables javascript:
storedVars["css_email_opt_in"] = "css=*[name='auto_policy[email_opt_in]']";
storedVars["css_phone_opt_in"]="css=*[name='auto_policy[phone_opt_in]']";
storedVars["css_phone_opt_in_true"]="css=input[name='phone_opt_in'][value=true]";
storedVars["css_credit_rating"]="css=select[name='auto_policy[credit_rating]']";