Dies ist ein häufiges Problem. Ich würde auf Folgendes achten:
Wie Sie Elemente benennen
Verwenden Sie die CSS-ID oder -Klasse, um Elemente zu identifizieren. Bevorzugen Sie die Verwendung der CSS-ID, wenn das Objekt eindeutig ist. Berücksichtigen Sie das von Ihnen verwendete Framework. Beispielsweise wird das nameAttribut bei Ruby on Rails automatisch zugewiesen und kann (nicht intuitiv) besser sein als die Verwendung der CSS-ID oder -Klasse
Wie Sie Elemente identifizieren.
Vermeiden Sie Positionskennungen wie table/tr/td/tdzu Gunsten von Formularen wie td[id="main_vehicle"oder td[class='alternates']. Erwägen Sie gegebenenfalls die Verwendung von Datenattributen. Auch versuchen , besser zu vermeiden Layout - Tags wie <td>ganz so für die oben Sie entweder eine Spannweite und Nutzung könnten hinzufügen , dass, zum Beispiel <span id="main_vehicle">oder einen Platzhalter Wähler wie in *[id="main_vehicle"]dem den *könnte jetzt ein div sein, spannt, td, usw.
Mit Test spezifische Datenattributen , die nur für qa und Tests verwendet werden.
Vermeiden Sie unnötige Qualifikationen für Elemente. Möglicherweise verwenden Sie Folgendes:
body.main div#vehicles > form#vehicle input#primary_vehicle_name
Dies erfordert jedoch, dass das Eingabefeld in einem Formular mit einer genauen ID des Fahrzeugs und auf einer Seite mit einem Hauptteil mit der Klasse main und einem Hauptteil mit der ID des Fahrzeugs verbleibt, das ein unmittelbares Kind eines Formulars mit der ID von hat Fahrzeug. Jede Änderung dieser Struktur und der Test wird abgebrochen. In diesem Fall könnten Sie das finden
input#primary_vehicle_name
reicht aus, um das Element eindeutig zu identifizieren.
Vermeiden Sie Tests, die sich auf sichtbaren Text beziehen. Der Text auf der Seite, der dem Benutzer angezeigt wird, ändert sich normalerweise im Laufe der Zeit, wenn die Site gewartet und aktualisiert wird. Verwenden Sie daher Bezeichner wie CSS-ID und CSS-Klasse oder Datenattribute. Elemente wie form, inputund selectin Formen verwendet werden , sind auch gute Teile zu identifizieren Elemente, in der Regel in Kombination mit der ID oder Klasse, zB li.vehicleoder input#first-vehicle
Sie können auch Ihre eigenen Kennungen hinzufügen, zum Beispiel <div data-vehicle='dodge'>. Auf diese Weise können Sie die Verwendung von Element-IDs oder -Klassen vermeiden, die wahrscheinlich von Entwicklern und Designern geändert werden. Ich habe im Laufe der Zeit herausgefunden, dass es besser ist, nur mit Entwicklern und Designern zusammenzuarbeiten und sich über Namen und Geltungsbereiche zu einigen. Es ist schwer.
Wie feste Daten gepflegt werden
Versuchen Sie, ähnlich wie bei der Identifizierung tatsächlicher Elemente, zu vermeiden, dass der fest codierte Selektor Werte zugunsten von Seitenobjekten identifiziert - kleine Textteile, die in Variablen oder Methoden enthalten sind und somit wiederverwendet und auch zentral verwaltet werden können. Beispiele für Javascript-Variablen nach diesem Muster für fest codierte Werte:
storedVars["eqv_auto_year"] = "2015";
storedVars["eqv_auto_make_1"] = "ALFA ROMEO";
storedVars["eqv_auto_make_2"] = "HONDA";`
Weitere Informationen zu Seitenobjekten finden Sie im Selen-Wiki und in den Selen-Dokumenten
Kommunikation mit Entwicklern.
Unabhängig von der technischen Herangehensweise in Bezug auf "Entwickler nehmen Änderungen vor und brechen die QS-Automatisierung", die ein Workflow-Problem darstellt. Sie müssen sicherstellen, dass: jeder ein und dasselbe Team ist; Entwickler führen dieselben integrierten Tests durch; Standards werden von beiden Gruppen vereinbart und befolgt; Die Definition von "erledigt" umfasst das Ausführen und möglicherweise Aktualisieren der UI-Tests. Entwickler und Tester arbeiten gemeinsam an Testplänen und beide nehmen an der Ticketbereinigung teil (wenn sie Agile ausführen) und sprechen im Rahmen der Bereinigung über das Testen der Benutzeroberfläche. Sie sollten sicherstellen, dass der Ansatz und die Strategie, die Sie für die Benennung verwenden, mit den Anwendungsentwicklern abgestimmt sind. Wenn Sie nicht auf der gleichen Seite sind, wird es Ihnen gefallen, über die Benennung von Objekten zu streiten. Einige Beispiele für Seitenobjektmethoden, die ich kürzlich für ein Ruby-Projekt erstellt habe:
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
Hier sind die gleichen Seitenobjekte wie bei Javascript-Variablen:
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]']";