Стратегия отображения графического интерфейса в автоматизации тестирования

Question

В своей практике автоматизации тестирования я всегда использую стратегию графического отображения, которая сокращает затраты на обслуживание.

Так, например, если мне нужно определить кнопку " Google Search " (www.google.com), ее XPAth будет

//input[@name='q']

а не

/html/body/center/form/table/tbody/tr/td[2]/input[3]

Понятно, что во втором случае небольшое изменение в структуре страницы может сломать мой тест.

Но может я что-то упустил? Может быть, если структура документа изменится, я должен знать об этом, и некоторые из моих тестов не пройдут?

Как вы думаете? Какую лучшую практику вы порекомендуете?

Answer 1

Если элемент имеет идентификатор, который используется сценарием / css, мы используем этот идентификатор в тестировании. В противном случае мы активно применяем наш HTML для тестирования. Под этим я подразумеваю, что мы можем добавить идентификатор только для тестирования , чтобы избежать двусмысленности. Мы обычно даем префикс для обозначения этого, т.е. ID = "ftGoogleButton". Таким образом, люди, работающие только с HTML, поймут, что с этим элементом связано автоматическое тестирование. Это соглашение практично, потому что они обычно будут искать в css / js ссылки на данный идентификатор.

Answer 2

Я бы сделал то же самое, выбрал бы первую формулировку, а не вторую ... для большинства тестов.

Вы хотите, чтобы ваши тесты ломались при изменениях, относящихся к функциональности, охватываемой этими тестами, и вы хотите, чтобы те же самые тесты игнорировали большинство других изменений приложения.

Итак, если вы проверяете, что поиск "foo" должен возвращать больше нуля документов, это не имеет никакого отношения к структуре страницы и должно игнорировать такие изменения.

Однако в тесте, написанном для того, чтобы убедиться, что форма поиска снабжена кнопкой отправки, вы бы хотели включить эти предположения в XPath, используемый для перехода от формы к кнопке.

Answer 3

Как сказал Крозенволд, заставить разработчиков стандартизировать атрибуты html name и / или id и использовать их - одна из лучших стратегий. Моя статья Автоматизация тестирования как требование к разработке обсуждает эту тему и другие вещи, которые могут сделать разработчики, чтобы сделать приложения более удобными для автоматизации.

Вы также должны убедиться, что все ваши свойства идентификации объекта хранятся в одном центральном хранилище, чтобы упростить любое последующее обслуживание. В большинстве коммерческих инструментов эта функция встроена, но при использовании инструмента с открытым исходным кодом вам может понадобиться запустить собственный механизм.