Тестирование Mobile Web в чем-то похоже на тестирование Desktop Web. С одной стороны это те же HTML, CSS, JavaScript и прочие прелести, которые мы привыкли видеть. Те же проблемные места и типичные баги. С другой стороны, отличия все же имеются.
В этой статье я собрал небольшой чек-лист тех особенностей, которые важно проверять на Mobile Web проекте.
Начать хотелось бы с того, что у нас есть как минимум два способа тестировать Mobile Web проекты. Первый — эмулировать мобильный браузер средствами Chrome DevTools (или другими браузерами в их инструментах разработчика, но это менее популярный способ). Второй — тестировать на реальном девайсе, используя настоящий мобильный браузер.
Большую часть функционала вполне возможно проверить без девайса, но все же не все. Потому я разбил проверки на две больших части — то, что мы проверяем на ПК, а что только с мобильным устройством в руках.
Chrome DevTools
Итак, как было сказано выше, мобильное тестирование можно провести на ПК, не используя мобильное устройство. Браузер Chrome умеет работать в мобильном режиме.
Get user-agent of your WebView/browser and HTML5 test, run on KitKat
Мобильный режим
Для того, чтобы перейти в мобильный режим просмотра веб-страницы, необходимо открыть Chrome DevTools и нажать на вот этот символ:
Перед нами откроется веб-приложение так, словно оно было открыто с мобильного девайса:
Мы можем выбирать из списка тип девайса, работу с которым мы эмулируем:
User Agent
Важно помнить, что некоторые веб-приложения помимо размера экрана еще ориентируются на User Agent. Такое приложение в мобильном режиме может визуально отличаться от того, что мы увидим на реальном девайсе.
Для того, чтобы все сделать правильно, необходимо в Chrome DevTools дополнительно настроить Network conditions, выставив мобильный User Agent:
После чего перезагрузить страницу и получить необходимый результат.
Network throttling
При помощи Chrome можно проверить работу приложения как на медленном интернете, так и вовсе оффлайн. Для этого на той же вкладке Network Conditions можно выбрать параметр network throttling:
Это важно в том случае, если пользователи часто используют приложение в условиях плохого интернета, например навигатор.
Это не все, что есть в Chrome DevTools. Это отличный инструмент как для работы с Desktop Web, так и для Mobile Web. По нему есть отличная документация от Google, in English of course.
У нас есть двухнедельный онлайн-курс по Chrome DevTools на русском. Вся информация на странице профиля. Движемся дальше. 🙂
Understanding WebViews
Тестирование Mobile Web с помощью Chrome DevTools имеет ряд преимуществ. Это просто, быстро, не требует наличия реальных девайсов и позволяет выявить самые очевидные баги приложения. Но, увы, не все.
Производительность
Первая причина, почему стоит взять в руки мобильное устройство: необходимость проверить работоспособность приложения на слабом девайсе.
Современные веб-приложения перегружены всякого рода анимациями, сложными вычислениями на стороне клиента и так далее. Если на десктопе все это добро может работать гладко и красиво (хотя тоже не всегда), на каком-нибудь Samsung J-линейки (например, J2) могут быть лаги.
Мобильные браузеры
Вторая причина — мобильные браузеры. Речь о тех браузерах, которые встроены в систему и являются дефолтными. Многие люди используют их и не утруждают себя установкой мобильного Chrome.
Одним из представителей такого браузера является Samsung Internet Browser. На нем стоит проверить работу своего веб-приложения. Особенно если нет статистики, показывающей “с чего сидят” ваши пользователи. Если такая статистика есть и она утверждает, что с этих браузеров никто на приложение не заходит, то скорее всего тестировать его не надо. Хотя… а что, если они не заходят потому, что оно как раз сломано? 🙂
Стоит об этом подумать.
Работа в Background
Mobile Web приложение работает в мобильном браузере, что логично. При этом мобильные девайсы устроены так, что приложение может быть как в активном режиме, так и в бэкграунде. Например, если мы переключились на другое приложение или у нас входящий звонок.
Теперь предположим, что по какой-то причине наш пользователь перевел браузер с открытым приложением в бэкграунд. А затем вернулся. Вот несколько примеров того, что может быть не так. Например, у нас приложение-чат и вся история переписки потерялась. Теперь требуется перезагрузка страницы.
Плохо? Конечно! Или у нас приложение “записная книжка”. Пользователь не успел что-то дописать, когда его прервал входящий звонок. Вернувшись, он обнаружил, что написанное им стерлось. Теперь придется писать все заново.
А может лучше не пользоваться таким приложением?
Обязательно проверяйте, как ключевой функционал приложения работает после бэкграунда.
Электронная клавиатура
Чаще всего пользователи Mobile Web используют электронную клавиатуру для ввода текста. Бывает такое, что при ее появлении верстка приложения ломается. Обычно эта проблема связана с тем, как рассчитываются пропорции экрана и как они влияют на эту самую верстку.
Стоит обратить особое внимание на те страницы приложения, где пользователю приходится заполнять много данных: страница регистрации, какие-нибудь опросники и так далее.
Ориентация экрана
У мобильных приложений есть два типа ориентации экрана: portrait и landscape. Об этом можно почитать тут.
Если мы “положим на бок” наш девайс, большая часть мобильных приложений “перерисуется” под новые пропорции экрана. Это касается и мобильных браузеров. В этот момент верстка нашего веб-приложения также может сломаться в самых непредсказуемых местах.
Chrome DevTools умеет эмулировать оба режима, но все же сам процесс переворота и дальнейшая перерисовка веб-приложения происходит иначе, чем на настоящем мобильном браузере.
То, как наше приложение будет выглядеть после перерисовки обязательно стоит проверить. Причем, желательно, в обе стороны: из portrait в landscape и из landscape в portrait.
Веб-страница в нативном приложении
Еще один распространенный кейс: когда у приложения есть как Mobile Web версия, так и нативное приложение. В этом случае бывает так, что часть страниц в нативное приложение не переносят, а просто отображают их как WebView.
WebView — это компонент, который позволяет встраивать веб-страницы в приложение. Встроенный браузер просто рендерит внутри приложения то, что мы бы увидели на Mobile Web. Довольно часто это экономит время при разработке нативного приложения.
В таком случае стоит проверять изменения Mobile Web не только в браузере, но и внутри нативных приложений тоже. Конечно, тут без мобильного девайса никак не обойтись.
Обработка тапов
В отличие от Desktop Web, где есть только клик мышью, в мобильном приложении существует несколько способов взаимодействия с интерфейсом: touch, tap, flick и так далее. Об этом много где можно почитать, например тут.
Chrome DevTools умеет эмулировать часть этих действий. Но, во-первых, не все. А, во-вторых, не всегда результат во время эмуляции такой же, как во время использования реального девайса.
Даже если ваше мобильное веб-приложение не заточено под специальные действия, все равно стоит проверить взаимодействие интерфейса хотя бы с tap’ом. Особенно такие места, как меню или какие-нибудь переключатели. Суть в том, что tap не попадает в какие-то конкретные координаты. Он попадает на целую область. Если ваши элементы управления находятся рядом, tap может влиять на несколько элементов сразу и доставлять неудобство пользователю.
Итого
Я рассказал об основных особенностях тестирования Mobile Web проектов. Если вы пришли из тестирования Desktop Web, этот список скорее всего вам пригодится.
Источник: www.learnqa.ru
WebView Tester
Test your web application in Android web view with JavaScript logs shown directly in the application. Enables web view debugging and setting custom User-Agent string.
Logs can be filtered directly in app or shared to any other application. Tested URL can be saved so you don’t have to type every time and for long URLs there is a QR scanner.
Works on Android 4.0 and above. No ads and free as in speech.
Visit project repository at https://github.com/lsrom/webview-tester
Показать больше
WebView Tester Varies with device APK для Android Varies with device+
| Версия | Varies with device для Android Varies with device+ |
| Обновить | 2021-06-21 |
| Устанавливает | 5.000++ |
| Размер файла | 1.933.615 bytes |
| Разрешения | просматривать разрешения |
| Какие новости | Update to Android 30 build target. |
История версий:
- 1. LATEST. WebView Tester Varies with device APK (2021-06-21, 2 MB)
- 2. WebView Tester 2.2 APK (2020-12-09, 2 MB)
- 3. WebView Tester 2.1 APK (2020-02-28, 2 MB)
- 4. WebView Tester 2.0 APK (2020-02-23, 2 MB)
- 5. WebView Tester 1.0.6 APK (2018-12-31, 2 MB)
- 6. WebView Tester 1.0.5 APK (2018-10-16, 2 MB)
Источник: apkdownload.com
How to…Appium: Testing Web Views with Appium
Welcome to a our addition to our How..To Series. The How..To series is designed to help you with you specific testing tool problems. Each month a new post will be published with a guide on a specific problem that you might need help with. On the second Tuesday of each month, Anuja will publish a post on a particular aspect of Appium. This post examines testing webviews with Appium.
If you have suggestion of any future posts, please comment below and we will add them to the list.
There are two types of apps Native Apps and Hybrid apps. Native app means apps developed using native APIs and Hybrid apps means apps containing Web Views. As we know Appium supports Webviews and hence we can test Hybrid Applications using Appium very effectively. Web View is nothing but an Android/iOS application opening a web page inside their application.Before we start with our test case we need to know how to inspect HTML code of an Webview, How to Locate web elements and how to perform actions on web elements.
How to Inspect Webviews in Chrome Browser –
1. Go to Chrome browser
2. Type this url -chrome://inspect/devices#devices
3. click on any url listed on web page.
4. Then click on any UI element and you will get associated html source code which you can use to write your own xpath.
How To Locate Webview Elements
Locating Webview elements is very easy as because it has same APIs like findElementById(). Hence we can use find elements by id,class name,xpath etc to locate our web elements before performing any kind of actions on it.
How to Switch To Webview
Check out the code sample given below which switched to web view and then test cases perform actions mentioned in your code on directly on the Web Views.
// Switch to WebView SetString> contextNames = driver.getContextHandles(); System.out.println(contextNames.
size()); for (String contextName : contextNames) System.out.println(contextName); if (contextName.
contains(«WEBVIEW»)) driver.context(contextName); >
Sample Webview Test Case Example –
Consider you have an app which has web view for Registration. Where you need to perform below test case
1. Check web view displays text message “Welcome To My Page”
2. Enter Username
3. Enter Password
4. Click on Submit
5. Assert that text message saying “Successfully Registered” is Displayed
In the below test case we need to set up desired capabilities for test case execution. Then inside you webview test case add the code to switch to Web View and then start with your test case code. Before and After Test are JUnit Annotations used to define the flow of execution.
public class TestWebViews
About The Author
Anuja works as QA Engineer. Anuja started her blog to share her experience regarding automation testing for Mobile Applications https://huddle.eurostarsoftwaretesting.com/appium-testing-web-views-appium/» target=»_blank»]huddle.eurostarsoftwaretesting.com[/mask_link]