Вы находитесь на странице: 1из 4

Одновременный запуск тестов

Параллельный запуск сразу нескольких видов тестов экономит время на


тестирование, что критически важно в условиях короткого цикла разработки.

BDD-методологию

Test Driven Development

Алгоритм TDD довольно прост и весьма полезен:

1. Пишем тест, убеждаемся, что он падает, что означает, что тест реально что-то
тестирует и изменения в коде реально необходимы.
2. Пишем код, пока тест не перестанет падать, что означает, что мы выполнили все
требования.
3. Рефакторим код, убеждаясь, что тест не падает, что означает, что наш код по
прежнему соответствует требованиям.

Если мы пишем хрупкие тесты, то на шаге рефакторига они будут постоянно


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

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

о фреймворк находится над тестами, организуя их запуск. 


Самые заметные фреймворки в мобильном тестировании — xUnit и Cucumber.
утилиты на базе WebDriver: Appium и Selenium. Из фреймворков наиболее
популярны JUnit и Cucumber

Наиболее популярные драйвера для GUI в мобильном тестировании


— UIAutomator и Espresso для Android, XCUITest — для iOS.

UIAutomation
стандартного решения от Apple, которое входит в Instruments.
 Accessibility Label
FoneMonkey
Record&Play решение, интересно тем, что тесты записываются и редактируются (!) прямо
из тестируемого приложения на телефоне или эмуляторе.
Тем не менее, телефон должен быть подключен к компьютеру для сохранения тестов. И
само собой, в приложении нужно компилировать несколько дополнительных библиотек.

JamoSolution
jamoSolution позволяет тестировать iPhone, Android, Windows Mobile и BlackBerry
приложения. При этом для всех платформ поддерживается запись тестов (record&play) и
вы можете тестировать iPhone приложения на Windows!

android

Robotium

Absolute Black Box

Perfecto Mobile и Device Anywhere.

LOCATORS ?? XPATHS?
APPIUM
CROSSPLATFORM, don’t need to update the app
best for react/native
не нужен доступ к исходникам

giton/browser stack

nspredicates

right locators for right locators

predefined data
jenny motion
south lab
test object

selenid dependency injection juice

Как решаете проблемы с тестирование на андроиде?


Возможно достучаться до элемента, если вместо testID вставлять accessabilityLabel.
Но при таком подходе уже нельзя использовать testID для ios и приходится писать
«platform specific code», где в элемент вставляется либо testID, либо
accessabilityLabel.
Но даже в этом случае не соблюдается полная уникальность, так как идентификаторы
наследуются в финальном дереве представления.

Со временем и с увеличением количества тестов, мы будем устанавливать таймеры


чаще — запросы http, анимация, сам React Native — мост между нативным кодом и
JavaScript только усложняет ситуацию.

А нельзя делать поллинг, раз в N секунд проверяя появление какого-то элемента? 


"Implicit Wait"
На самом деле, немного оффтопа, за время, которое я провел за автотестами, у меня
выработался набор небольших правил:
— Композиция, никакого наследования, никаких гетеров/сеттеров, меньше тра/кетчей,
все только по тай-маутам (элемент должен появиться рано или поздно, если нет —
упали)
— PageObject не всегда хорош, Widget/Elements куда удобнее, особенно когда на
проекте 100500 разных Drop-Down листов и не только.
— Все проверки строго по данным, которые берутся из базы/мусора/бумажки. В
фреймворке только проверка перехода через страницу (деление страниц до тех пор,
пока не будет уникального идентификатора). Страница должна самодостаточно себя
определить, как абстрактный элемент теста: страница корзины одинакова — будет
она вызвана из личного кабинета, или из айтема покупки, а вот виджеты
«Добавленные покупки» уже будет другой, в таком случае в страницу Корзина я могу
добавить автопроверку в конструктор при переходе на нее, и если переход состоялся
куда я не ожидал (нет на страницы скажем h1 «Корзина») то я «заваливаюсь».
— Приучитесь писать run-конфигурации для тест-энвайромента: есть 100 тестов, они
все разрозненны, но есть тест сьюты, которые должны проверять функциональности.
Берем пачку тестов, засовываем в конфигурацию, прикрепляем в бранчу/тикету/ —
готово. Это облегчает запуск, и всегда из ранее готовых тестов можно «набрать»
нужную функциональность, обозвать для нее конфигурацию, и запускать.

 Widget/Elements?

 saw_tooth8 сентября 2017 в 16:29


o
o
o
o
0

Основная суть в том, что на момент создания каркаса приложения для тестирования,
вы не описываете страницы целиком, а делаете некую структуру модулей внутри
страницы. К примеру, есть страница товаров, она включает в себя:
— виджет Товар
— виджет калькулятор (общая цена зачеканных товаров)
— виджет препросмотр (ну например там фотки посмотреть)
Создаем три класса виджетов, и оперируем только входящими для них элементами, и
состояниями.
Например для товара это будет, чекбокс выбора, атрибут цены. Для других все точно
такое же (для калькулятора результирующая цена, для предпросмотра текущее фото,
общее кол. фоток)
Уточнение: Виджетом я называю какую либо активною, порождающую сущность,
иными словами, такую, которая может мне вернуть новую страницу, элементом же я
называю сущности, которые работают с текущей страницей: Айтем товара, это
виджет, так как он мне может вернуть страницу товара, а вот фильтр на странице
каталога (по цене например) уже будет элементом, так как он изменяет лишь
содержимое страницы, не меняя ее структуры
Далее вы пишите PageItemViewet класс (непосредственно PageObj, которая вам
реализует работу с каталогом) и создаете композицию из предопределенных
виджетов, при этом не забывая о согласовании интерфейсов между классами:
— pageobj должен сам иметь счетчик ссылок, на множества елементов (вы должны
хранить ссылку на каждый товар, и только при использовании товара (выделении,
проверки цены ) непосредственно пересоздавать ваш виджет.
— pageobj обязан знать, кто его вызвал, и где он находится, более того для каждого
pageobj при создании необходимо проверять текущее положение в веб-приложении, я
обычно проверяю в конструкторе уникальных элемент для данной страницы, как
пример: при создании при переходе на страницу каталога, я смотрю на заголовок
каталога, если он совпадает с тем, куда меня отправил предыдущий шаг — значит я
на верной странице. данное действие избавляет от необходимости в тестах, чекать
каждый чих переходов (но злоупотреблять им не следует, обычно это основные
страницы (каталог, о магазине, контакты, определенный товар)
— все елементы (не активные виджеты) обязательно должны иметь
автообновляемые свойства, иначе вы рискуете потерять целостность вашего
состояния (вы добавили товар, спрашиваете у калькулятора какова текущая общая
стоимость, он вернул 10, вы добавили еще один товар, спрашиваете у калькулятора,
а теперь? — он вернул 10, очевидная ошибка, сохраненное предыдущее состояние.)
— реализация getter-ов должна быть сугубо на стороне элементов, и только они
должны вам отдавать информацию со страницы. Pageobj являюется только
агрегатором виджетов, и хранилищем текущего состояния теста (страницей
выполнения).
Как то так. Спасибо за внимание)

Оценить