Разница между кодом руки и записанными сценариями в тестах автоматизации

Question

Пожалуйста, дайте мне знать разницу между написанным вручную текстом и записанными сценариями в инструментах автоматизации тестирования, таких как кодированные ui или любые другие инструменты. С уважением, Радж

Answer 1

По «рукописной» Я предполагаю, вы имеете в виду вручную закодированы ...

я вижу несколько причин. Опыт кодирования блистателен. Это будет достойная инвестиция, если вы будете кодировать свои собственные тесты, потому что вы можете много узнать о используемой структуре тестирования (CodedUI, Selenium и т. Д.), А также о языке, который вы используете (Java, C#). Вручную кодирование этих тестов, используя встроенные методы структуры, послужит вам хорошо и даст вам гораздо больше знаний, чем инструмент автоматического воспроизведения.

Автоматические инструменты воспроизведения могут создавать ужасающий код. Код, который является уродливым, плохо названным, передовой практики и ненадежными методами определения местоположения.

Инструменты воспроизведения просто используют самый простой способ поиска элемента. Это не всегда лучше. Классическим примером является XPath.

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

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

Инструмент воспроизведения может сделать очень странный XPath как: //div[1]/span[2]/table[1]/tbody[1]/tr[10]/[td[2]/a[text()='Test'].

Выглядит странно, правда?

Это будет работать несколько раз, но что произойдет, если приложение получит еще один элемент tr, расположенный в верхней части таблицы? Теперь, tr[10]wont быть элементом, который вы хотите, это будет tr[11].

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

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

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

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