mobile ui testing tutorial gui testing ios
Ръководство за тестване на потребителския интерфейс за мобилни приложения: Научете как да извършвате тестване на потребителски интерфейс на iOS и Android
С процъфтяващия пазар на мобилни телефони тестването на мобилни приложения става вълнуващо от ден на ден.
фази на жизнения цикъл на разработването на софтуер
Само като стартирате функционални тестове в мобилно приложение, не можете да излезете от приложението. Има няколко други типа тестване, като тестване на място, тестване на мрежата, тестване на потребителския интерфейс, тестване на живота на батерията и т.н., които трябва да бъдат направени.
Тестването на потребителския интерфейс е един от важните тестове при тестването на мобилни приложения и не трябва да се приема лекомислено.
Графичният потребителски интерфейс създава голяма разлика в това колко интересен и интерактивен потребител намира вашето приложение. Значението на приличния и атрактивен GUI може да се усети по-значително в интелигентна среда на устройство, където размерът на екрана е далеч по-малък в сравнение с екрана на лаптоп или настолен компютър.
Какво ще научите:
- Важност на тестването на потребителския интерфейс на мобилното приложение
- Как да реша колко тестване на потребителския интерфейс е необходимо?
- Указания: Какво да тествате при тестване на потребителския интерфейс на мобилното приложение
- Как да тествате вариации на потребителския интерфейс в различни версии на операционната система?
- Реални устройства или емулатори: Какво да изберем за тестване на потребителския интерфейс?
- Ръчно или автоматизирано тестване на потребителския интерфейс?
- Инструменти за тестване на потребителския интерфейс на мобилното приложение
- Контролен списък за тестване на потребителския интерфейс на мобилното приложение
- 5 мита за автоматизирано тестване на мобилен потребителски интерфейс
- Митът и реалността
- Заключение
- Препоръчително четене
Важност на тестването на потребителския интерфейс на мобилното приложение
Като потребител ще се чувствате ли като да използвате приложение, което няма взаимодействие с потребителя и затруднява разбирането как да го използвате?
Когато потребителите използват мобилно приложение за първи път, не само производителността открадва вниманието, но и привлекателният потребителски интерфейс. Приложението, удобно за потребителския интерфейс, продава повече в сравнение с приложението, което е най-добре разработено, но с гаден потребителски интерфейс.
Ако приложението има перфектен и прекрасен потребителски интерфейс на едно устройство, но на другото устройство е напълно изкривено, само защото има различен размер или различна ОС, тогава ще остави много лошо впечатление. Търговският успех на приложението ще бъде силно засегнат.
Ще популяризирате ли приложение, при което бутонът е твърде малък, за да щракне, блокиращ целия набор от функционалности?
Това не са ли неприятни преживявания за потребителите? Поради гореспоменатите случаи става много важно да тествате потребителския интерфейс на приложение. Двете основни проверки, които трябва да се направят за мобилни приложения, са удобството за потребителя и външният вид при различни модели и версии на операционната система.
Следва пример за това как потребителският интерфейс трябва да бъде перфектен при различни размери на екрана:
Как да реша колко тестване на потребителския интерфейс е необходимо?
Следващата диаграма обозначава различните вертикали, в които мобилните приложения могат да бъдат категоризирани:
(изображение източник )
От горната диаграма можете да разберете, че приложенията за игри заемат по-голямата част от пазарния дял от около 24,43%, а след това последвани от приложения за бизнес и образование.
- Приложенията, разработени като приложения за игри, се нуждаят от задълбочено тестване във всеки аспект, тъй като потребителският интерфейс има най-голям принос за постигане на успех, независимо дали е естествено или хибридно приложение
- Бизнес приложението може да не разчита напълно на потребителския интерфейс за своя успех, тъй като в повечето случаи целевите аудитории са обучени да използват приложението. Следователно такива приложения могат да имат прост потребителски интерфейс.
- Приложенията, разработени с образователна цел, се нуждаят от задълбочено тестване на потребителския интерфейс.
- Търговските приложения като пазаруване, пътувания и т.н. също се нуждаят от цялостно тестване на потребителския интерфейс на различни устройства и различни версии на операционната система.
Накратко, в зависимост от целта на приложението, може да се реши дълбочината на тестване на потребителския интерфейс, но тестването на потребителския интерфейс винаги трябва да се извършва на поне 3 различни версии на ОС.
Указания: Какво да тествате при тестване на потребителския интерфейс на мобилното приложение
Докато тествате потребителския интерфейс на мобилно приложение, трябва да бъдат проверени различни характеристики.
Следват някои от характеристиките, които трябва да бъдат тествани за всяко приложение:
# 1) Резолюция на екрана
Следват някои от често срещаните разделителни способности на екрана, които се вземат предвид при създаването на тестови площадки:
- 640 × 480
- 800 × 600
- 1024 × 768
- 1280 × 800
- 1366 × 768
- 1400 × 900
- 1680 × 1050
Всички тези резолюции са задължителни за тестване, когато имате приложение с няколко колони в приложението си.
Следователно трябва да се извърши проверка, започвайки от най-малката до най-голямата резолюция. Освен това, ако приложението ви има дълъг списък с карти с информация, те също трябва да бъдат тествани с различна разделителна способност за опаковане на информацията.
# 2) Размер на екрана
Има твърде много вариации в размерите на екрана и наличните резолюции. Особено при смарт устройствата размерите на контролите не са статични, те имат отношение към наличния размер на екрана.
Докато тествате, уверете се, че размерът на контролите изглежда естетически добре и контролът е напълно видим на екрана, без никакво превъртане. Тествайте GUI на различни устройства с различни размери на екрана и резолюции.
Емулаторите са добри за тази цел, но нищо не съвпада с реалното устройство. Така че не забравяйте да тествате на поне две или три реални устройства. Също така, не забравяйте да тествате върху пейзажна и портретна ориентация, ако устройството го поддържа.
Трябва да тествате приложението при често използвани резолюции, за да гарантирате неговата използваемост.
Малко неща, които трябва да разберете тук, са:
Разликата между размера на екрана и разделителната способност: Размерът на екрана е дължината на екрана в инчове, измерена по диагонал или от един ъгъл до друг ъгъл на екрана. Разделителната способност на екрана е ширината и височината, Пример 640w × 480h, който представлява броят на пикселите, преминаващи през екрана, умножен по няколко пиксела надолу.
# 3) Различни елементи на потребителския интерфейс
Елементите на потребителския интерфейс като бутони, заглавия, икони, изображения, полета за избор, текстови полета, квадратчета за отметка и т.н., са някои от различните елементи, които трябва да бъдат проверени за външния им вид и размер на екрана.
По-специално за текстовите полета, ако меката клавиатура се появи на допир в текстовото поле, трябва да бъде тествана и проверена.
Най-важното е задълбочено тестване на размерите на бутоните, защото си спомням, че в нашето приложение, докато тествахме на телефон Galaxy S, открихме блокиращо устройство, при което един бутон е блокирал цялото приложение, само защото бутонът изглежда твърде малък, за да щракнете върху него.
Позицията на елементите на потребителския интерфейс също трябва да бъде проверена спрямо изискването, т.е. ако всички трябва да бъдат подравнени по центъра или вляво и т.н.
# 4) Стил: Цветова и тематична схема на устройството
Потребителският интерфейс и цветовата схема на приложението трябва да съответстват на различни цветове и схеми на темата на телефона. Цветът и темата на телефон Samsung са много различни от тези на Nokia или на телефона MI .
Следователно трябва да проверите дали приложението изглежда последователно на такива телефони.
Вашето приложение има специфичен дизайн. И стилът на контролите трябва да съвпада с този дизайн. Може да сте виждали много приложения, където някои контроли, напр. панелите имат кръгли ръбове и други контроли, напр. текстовите полета имат остри ръбове.
Въпреки че този тип проблеми не засягат използваемостта или функционалността на приложението, все пак постоянният външен вид на приложението помага да се изгради приятелска връзка между приложението и потребителя.
Едно от най-важните неща в стила е шрифтът на различните страници. Шрифтът трябва да бъде тестван добре, за да се избегне несъответствие във външния вид и усещането на приложението.
През повечето време се фокусираме върху текста, който се вижда в нормални ситуации, и игнорираме текста, който се появява в конкретни ситуации. Съобщенията за успех и неуспех са пример за такъв тип текст.
Друг важен за стила фактор е връзката между цвета на шрифта и ситуацията, в която се показва текстът.
Например, Червеният цвят се използва за съобщения за грешки, зелен за успех, жълт за предупреждения и син за хипервръзки.
# 5) Multi-touch или Single touch
Ако приложението ви поддържа мултитъч функцията, като притискане за мащабиране или притискане за свиване и т.н., тогава трябва да тествате щателно тази функция и да създадете много тестови случаи за това за всички приложими екрани.
# 6) Дълго или кратко натискане
Продължително натискане на икона показва контекстното меню, докато кратко докосване изпълнява първото действие на менюто. Ако тази функция е предоставена във вашето приложение, трябва да проверите тази функционалност и всички функции около нея.
# 7) Местоположение
Местоположение и позиция са двете думи, които се използват алтернативно и, което е интересно, те се използват по-нататък, за да предадат две различни концепции, които са обяснени по-долу:
1) Понякога това е областта на екрана, където се появява контрола.
Например, Хедърът е разположен на връх на страницата, Етикетите са Ляво подравнено , а текстовите кутии са Дясно подравнен, и т.н. Тук „отгоре“, „ляво подравнено“ и „дясно подравнено“ са относителни позиции на контролите.
две) Понякога това е редът на контрола сред другите контроли.
Например, докато получавате лична информация, Името е последва по фамилия. Или форматът на контролите, за да поискате адрес в САЩ, трябва да бъде в поръчка - ZIP, Град, Щат.
И за двете ситуации говорим за местоположението на контролите.
Докато тествате за местоположение и позиция на контролите, уверете се, че всичко е логично поставено на екрана и показва добър естетически усет.
Има ситуации, при които един или повече контроли се появяват на повече от един екран. В тази ситуация трябва да се уверите, че те се показват на едно и също място и в един и същ относителен ред на всички страници.
Как да тествате вариации на потребителския интерфейс в различни версии на операционната система?
Потребителският интерфейс варира в зависимост от версията на операционната система и с пускането на нова версия се правят подобрения в потребителския интерфейс.
Нека да наблюдаваме потребителския интерфейс на 3-те най-нови операционни системи, които в момента са налични, и да разберем как тези вариации влияят на мобилното приложение.
Те са:
- Близалка
- Зефир
- Нуга
Разглеждайки горния списък с нови функции за потребителски интерфейс или функционалност, като QA трябва да проектирате тестови случаи около това.
1) близалка:
- Създайте тестови случаи за ефекта на новия дизайн върху вашето приложение.
- Не е задължително за всички екрани, но създайте тестови случаи за достъп до новите преки пътища на вашето приложение.
2) Зефир:
- Ако приложението ви се занимава с емотикони, създайте тестови случаи, за да проверите новите емоджи. Приложенията, които позволяват на потребителите да пишат отзиви или да чат, са тези, които често използват емотикони.
- Когато приложението ви е публикувано и инсталирано за първи път, може да се наложи да поиска разрешение, поради което трябва да се направи необходимостта от тестване на потребителския интерфейс на новия екран с разрешения. И създайте тестови случаи за същото.
- Ако приложението ви използва Google Now, трябва да създадете тестови случаи, за да тествате потребителския интерфейс на актуализираната функция на Google Now.
3) Нуга:
- Трябва да се направи задълбочено тестване на вашето приложение за режима на реалността на мечтите и следователно да се създадат тестови случаи съответно.
- Създайте тестови случаи, за да проверите опциите на менюто за вашето приложение.
- Ако приложението ви се занимава с емотикони и GIF файлове, създайте тестови случаи, за да проверите новите емотикони и опцията за изпращане на GIF файлове.
Реални устройства или емулатори: Какво да изберем за тестване на потребителския интерфейс?
Когато трябва да тествате мобилно приложение, може да се замислите какъв трябва да бъде тестът?
Дали да тествате на реално устройство или емулатор или и двете? Няма категоричен отговор на това, защото изборът зависи от това, което искате да тествате.
За да тествате функционалността, производителността, мрежовия отговор, полевия тест и т.н., винаги трябва да предпочитате истинско устройство. Но за неща като потребителския интерфейс трябва да изберете емулатори заедно с някои реални устройства.
Професионалисти
Плюсовете на използването на емулатори за тестване на потребителски интерфейс са:
1) На практика не е възможно да се съберат устройствата с всички резолюции и това също би струвало огромна сума пари. Но емулаторите не струват нищо.
две) С емулатор можете да създадете всички разделителни способности на екрана и комбинации от ОС.
3) Ако имате само един набор от реални устройства, но екипът за QA е от повече от 1 човек, тогава всички QA не могат да тестват паралелно за една и съща проба. С емулатор всеки QA може да създаде същата комбинация на своята машина и да тества паралелно.
4) Тестването на емулатор отнема по-малко време и е по-бързо в сравнение с реално устройство.
5) Често срещани грешки, свързани с потребителския интерфейс като подравняване и т.н., могат лесно да бъдат уловени на емулатори.
Минуси
Недостатъците включват:
1) Жестовете не могат да бъдат тествани на емулатори. Едновременно може да се емулира само един жест.
две) Физическите входове на GPS, падаща или слаба мрежа и т.н. също не могат да бъдат тествани.
3) Няма начин да създадете емулатор за телефони Sony, LG, Nexus и др.
4) Не е възможно да създадете реална среда с ниска батерия или малко памет и т.н. на емулатора.
Следователно решението трябва да се вземе в зависимост от вашето приложение и изискването за тестване.
Ръчно или автоматизирано тестване на потребителския интерфейс?
Никой продукт, независимо дали е настолно приложение или уеб приложение или мобилно приложение, не може да бъде пуснат без тестване. Като QA се борим да открием и докладваме всеки дефект, но въпреки това те се отчитат от клиентите.
Знаеш ли защо?
Защото продължителни тестове, които често се избягват или пропускат, като по този начин остават неоткрити грешки. Също така 100% покритие, задълбочено изпълнение не е възможно при ръчно тестване.
Тестването на потребителския интерфейс е доста просто и ясно и просто трябва да погледнете как изглежда на вашето око. Сега, ако това се прави ръчно, това отнема много време. Също така, в повечето случаи трябва да създадем огромни данни за тестване на потребителския интерфейс като превъртане, ще се появи само ако редовете от карти пресичат определен брой.
Създаването на големи данни отнема много време. Наличието на автоматизиран пакет може да реши и двата проблема.
Напротив, ако функционалностите или потребителският интерфейс на приложението все още са във фаза на промяна, тогава няма смисъл да инвестирате в автоматизация. По същия начин, ако функционалностите на приложението са жизненоважни, тогава е по-добре да тествате ръчно.
Следователно, в зависимост от следните указатели, трябва да решите дали да тествате ръчно или да автоматизирате:
- Естеството на вашето приложение.
- Стабилността на приложението ви.
- Наличните ресурси като работна ръка за проучване на инструментите и сравняването им.
- Колко време е инвестирано за проучване и увеличаване на необходимия инструмент за автоматизация?
- Готов ли е клиентът да инвестира време в нарастването и проучването?
Инструменти за тестване на потребителския интерфейс на мобилното приложение
Следва списък с 5 инструмента, които могат да се използват за тестване на потребителски интерфейс на мобилно приложение за Android и / или iOS.
(За инструменти за тестване на функционалност y Можете да се обърнете към списъка с инструменти за автоматизация на нашата автоматизация инструменти за тестване на приложения за Android страница).
# 1) Selendroid
Selendroid е един от най-добрите и препоръчвани инструменти за автоматизация на мобилни приложения за тестване на потребителския интерфейс.
Може да се използва както за естествени, така и за хибридни приложения. Може да се използва само за приложения за Android и тестовете на API на клиента се пишат с помощта на Selendroid 2. Може да се използва и с повече от едно устройство и е напълно съвместим с JSON.
# 2) Testdroid
Това е инструмент, базиран на облак, и може да се използва за различни устройства, различни резолюции на екрана и версии на операционната система на Android и iOS. Паралелното тестване на устройства е голямо предимство на този инструмент и е добър инструмент за тестване на потребителския интерфейс. Помага на разработчиците да подобрят времето за пускане на пазара.
хвърли char в низ c ++
# 3) SeeTest
Това е платен инструмент и може да се използва за Android, iOS, Windows, Symbian и др.
Това е инструмент за различни платформи и следователно предимството е, че един и същ тест може да се проведе на всички платформи. Може да се използва за всички мобилни приложения и тестовете могат да се изпълняват паралелно на повече от едно устройство.
# 4) Автоматизация на потребителския интерфейс
Това е официалният инструмент за тестване на потребителски интерфейс за Apple и е най-добрият инструмент за автоматизиране на iOS приложения. Въпреки че е трудно да се научи, той предлага голямо предимство с библиотеки, производителност, тестване на потребителския интерфейс и т.н.
# 5) Калабаш
Може да се използва както за тестване на Android, така и за iOS за естествени или хибридни приложения. Това е инструмент за различни платформи и най-добре се използва за автоматизиране на жестове, екранни снимки, твърдения и др. Може да се използва на истински сензорни устройства. Също така има поддръжка за краставица.
Когато разработчиците тестват единично приложението, те могат също да правят тестване на потребителския интерфейс с помощта на Android Studio, но то може да се използва само за приложения на Android.
Препоръчително четене => Автоматизирайте тестовете на потребителския интерфейс
Контролен списък за тестване на потребителския интерфейс на мобилното приложение
По-долу е даден контролен списък за тестери, за да се гарантира, че GUI е тестван напълно добре на интелигентни устройства:
| ✅ | Тествайте цялостната цветова схема и тема на приложението на устройството. |
| ✅ | Ориентацията на екрана се тества както в портретен, така и в пейзажен режим. |
| ✅ | Проверете стила и цвета на иконите. |
| ✅ | Тествайте външния вид на уеб съдържанието в различни устройства и мрежови условия. |
| ✅ | Тест за оформление с няколко колони - проверете дали колоните са подравнени правилно и видими ли са дори при по-ниска резолюция. |
| ✅ | Тествайте дали индикаторите за напредък са видими, когато страниците се зареждат. |
| ✅ | Проверете менютата и как те се извикват. |
| ✅ | Проверете елементите, съдържащи се в менюто. |
| ✅ | Проверете използването на виртуална клавиатура, докато променяте режима на екрана. |
| ✅ | Проверете ефекта на притискане за мащабиране чрез сензорни екрани и топки - детайлите не трябва да се изкривяват при мащабиране. |
| ✅ | Тествайте плъзгащия ефект - трябва да работи с един удар; следващият екран трябва да влезе в разделителната способност на екрана без изкривяване |
| ✅ | Тествайте чувствителността на бутоните - трябва да може да се кликва с всякакъв вид докосване (голям пръст или стилус). |
| ✅ | Виртуалната клавиатура се отваря автоматично, когато потребителят иска да въведе текст във всяко текстово поле. |
| ✅ | Тествайте дали приложението е интегрирано добре с мобилните твърди клавиши - бутони за старт, начало, меню, назад. |
| ✅ | Проверете дали навигацията по страницата и превъртането работят добре през проследяващата топка. |
| ✅ | Тествайте цялостната реакция на приложението на устройството. |
5 мита за автоматизирано тестване на мобилен потребителски интерфейс
Автоматизираното тестване на мобилен потребителски интерфейс се счита за много решаващо, когато възникне въпросът за успеха на приложението. Но има някои митове, свързани с автоматизираното тестване.
Такива митове може да не са верни, защото може да са повърхностни. Навлизането дълбоко в процеса на автоматизираното тестване го кара да изчезне. Нека да се задълбочим в тях.
Мит 1: Скорост
Този мит е много разпространен. Повечето хора, свързани с ИТ индустрии, имат мит, че извършването на „тестване за автоматизация“ отнема повече време в сравнение с „ръчно тестване“. Този факт е верен до известна степен в няколко сценария.
Причината е, че ръчното тестване дава бързи резултати в сравнение с автоматизираното тестване на мобилния потребителски интерфейс. Но това е така само в предварителни и начални етапи.
При многократен вид тестване се изисква или добавяне на много повече функции на тестване, или намаляващи качества на тестване. Докато при автоматизираното тестване винаги изпълнявате подобни нива на тестване всеки път, като по този начин се спестява време в дългосрочен план.
Мит 2: Покритие
В днешния сценарий новите устройства с Android се пускат редовно на пазарите. И броят на приложенията на такива операционни системи (ОС) се увеличава. След това има операционни системи като iOS, които имат още повече приложения, създадени за ежедневна употреба.
Ръчното тестване за толкова много приложения става много трудно. Но в случаите на автоматизирано тестване е достатъчна поддръжката на облачните сървъри. С помощта на автоматизирано тестване са възможни пълни и пълни тестови покрития на приложенията.
Мит 3: Разходи
Факт е, че автоматизираното тестване на приложенията струва повече в сравнение с разходите за ръчно тестване. Това обаче е вярно само ако се правят тестове за най-важните неща на приложението. Тъй като средата на приложението и софтуерът се усложняват, ръчното тестване става по-скъпо.
Това е така, защото са необходими по-сложни инструменти за оптимални резултати от теста. Наред с тези усъвършенствани инструменти за тестване, има нужда от висококвалифициран персонал, който би могъл да управлява такива инструменти. Това изисква обучението им.
Така ръчното тестване става по-скъпо в сравнение с автоматизираното.
Мит 4: Последователност
В случай на ръчно тестване, винаги има място за различни възприятия, които варират от един тестер до друг. Това зависи и от разглежданите тестове, среди и приложения, заедно с операционната система (OS).
Когато прилагате ръчно тестване към софтуера, има дупки, през които могат да преминат малко грешки. Следователно ръчното тестване е добро само за откриване на основни грешки. Автоматизираното тестване се изпълнява върху скриптовете без място за различно възприятие, което го прави надежден.
Мит 5: Нежелание
Не е вярно, че автоматизираното тестване е заменило хората, по-скоро е за подобряване на ръчния тестер. Автоматизираните тестове предоставят автоматизирани резултати многократно, многократно с максимална точност. Така възниква въпрос, защо има нужда от хората?
Автоматизираното тестване се нуждае от писане на скриптове и планиране на цялата процедура за тестване. Тази задача изисква човешки усилия. Процедурата на автоматизираното тестване помага да спестите време и пари, така че да използвате такива ресурси за подобряване на процедурите на ръчно тестване. Развитието на по-добри инструменти от своя страна ще помогне за напредъка на вече съществуващите процедури за автоматизирано тестване.
Гореспоменатите са няколко от най-популярните митове, преобладаващи в индустрията на автоматизираното тестване. Това трябва да бъде премахнато за подобряване на автоматизираното тестване на мобилния потребителски интерфейс.
Митът и реалността
Факт е, че дори и най-сложните компании за развитие използват ръчно тестване за мобилни телефони или изобщо не провеждат пълни тестове. Според проучванията на Xamarin 2014, 13,2% от разработчиците на мобилни телефони извършват тестване като автоматизиран потребителски интерфейс. Според проучванията на Forrester Research, само 53% от разработчиците извършват повърхностни тестове на отделни устройства.
Пет най-често срещани фактора защо екипите на мобилни телефони не са автоматизирали качествата на мобилните приложения и пет причини защо те не просто имат истински смисъл са следните:
а) Скоростта е първият мит.
Човек не може да отдели време за автоматизация. През 2014 г. доставчиците представиха 7000 нови типа устройства с Android. Тогава имаше 10000 API, които са специфични за мобилни телефони. Приложението на мобилни устройства се доставя по-бързо и се модифицира бързо. С осигуряването на качеството (QA) в постоянни режими на смачкване, няма време за създаване на тестови скриптове, от своя страна, поддържайки ги в синхрон с редовно променящите се функции.
Практическият сценарий на първия мит:
В момента човек губи ценно време. Много е вярно. Тестването ръчно е по-бързо от тестването за автоматизация. Но това е за първото тестване. При следващи писти, каквито и да са незначителни ползи, ръчното тестване води до ерозии. Това е почти веднага. Заедно с всички повтарящи се тестови пускания или добавки на функции, разработчиците на приложения трябва или да намалят обхвата на тестване, или допълнителни ресурси за тестване.
Заедно с ограниченото бюджетиране това в крайна сметка води до порочните цикли на онези качества, които намаляват. В отговор на ангажиментите за данни и отрицателните отзиви на потребители от непроверени устройства, екипите желаят разширяване на покритието на устройството. Това допълнително увеличава стреса върху отделите за осигуряване на качеството вече като капацитет.
Това е, че бизнесът се бори за поддържане, проучване и набавяне на устройства, докато прави тестови изпълнения. Дори най-добре финансираните програми за ръчно тестване на потребителския интерфейс се съкращават към завършено покритие.
В САЩ мобилните екипи изискват тестване на 188 устройства, за да покрият 100 процента от маркетинговите дялове. Според изследванията на Xamarin от 2014 г., повечето от екипите за разработки тестват често на 25 или по-малко устройства.
Повече от една четвърт от тези общности на разработчици са насочени към пет или по-малко устройства. В реални ситуации на тестване автоматизацията се изплаща почти моментално и незабавно. Още при първото тестване се наблюдава, че потребителите ускоряват сроковете за тестване с 4 пъти. Това е над цялото ръчно тестване, когато се изпълнява срещу петдесет или устройства повече от това.
Проучванията, които са впоследствие, са били много по-бързи. И все пак съкращаването е за почти пълна седмица на изпитване, за да се използват само няколко часа.
б) Покритието е вторият мит.
Фрагментацията е причина за липсата на възможност за разширяване на покритието на устройството. Заедно с повече от 19000 устройства с уникални Android и пермутация от десетки за формиране на операционни системи и фактори за iOS, много екипи смятат, че не е възможно да се обхванат повечето устройства на предоставени пазари.
Така че има тестване по подразбиране на шепата от тези устройства като достатъчно добри.
Реалността на втория мит:
Човек би могъл да завърши покритието на устройството. В случай, че хората поддържат устройства вътре в шепи, те правят много. Доставката на устройства е трудна.
Поддържането на парите, разходите и времето, от своя страна, осигуряването на достъпност на тестерите им, когато и когато се усети нуждата от тях, създава логистични лоджии. От Gartner заявиха, че мобилните разработчици трябва да намерят начини за постигане на високи нива на автоматизация, за да бъдат в крак с темповете на платформата и разпространението на промяната. Това беше в хостинг. Използвани са различни функции за вътрешно управление.
Пътят към такава автоматизация е чрез облачни услуги на трети страни. Облачните услуги на трети страни помагат за автоматизация на процесите на зареждане на приложения, изпълнение на тестови скриптове, отчитане на резултатите и пренастройване на защитата на устройства за стандартите на фабриките. Подмножества от тестове на приложения се изпълняват паралелно, като по този начин ускоряват резултатите.
Докато тестват напред в широк диапазон от реални устройства, тестовите облаци позволяват на всички екипи да знаят точно как функционира приложението, от своя страна, елиминирайки типичните предположения за мобилни разработки.
Пример: Продуктовите мениджъри задават по-малко системни изисквания заедно с поверителност, която е оправдана при работата на устройствата. Разработчиците получават визуални обективни потвърждения за отстраняване на грешки преди ангажирането на по-новите версии. Това е независимо къде и кога работят.
в) Цената е третият мит.
Хората могат да си позволят само ръчно тестване. Тестовете за автоматизация се нуждаят от създаване на тестови скриптове, криви на обучение за персонала за осигуряване на качеството и инфраструктура. Много отбори вече се борят за спазване на крайните срокове. Те вече надхвърлят бюджета. Така че тестовете за автоматизация изглежда са на много голямо разстояние.
Практическият сценарий за третия мит:
Ръчното тестване спестява пари само в случай, че хората жертват покрития. Тестването ръчно изглежда по-евтино само в повечето среди, които са без кости.
В случай, че тестването включва бърза „проверка на червата“ на основните функционалности на по-малко устройства, тогава ръчното тестване изглежда като изгодни оферти. Но всякакви прилики с покритие на теста и изчерпателно устройство ще направят ръчното тестване много по-скъпо от тестването за автоматизация. Това може да е бързо дори.
Ръчното тестване само се мащабира чрез добавяне на повече хора и маси. Разходите нямат истинска линейност. Мащабирането на персонала за удовлетворяване на изискванията поражда огромни режийни разходи под формата на координация и обучение. Разделянето на тестови случаи по този начин намалява ефективността на всички тестери, като извършва премахване на перспективите.
Освен това тестерите, които имат достатъчно усъвършенстване, за да копаят отвъд поведението на потребителите, като по този начин проучват и очакват причини защо приложенията могат да се провалят, може да не са в изобилие, нито евтини. Тестовете за автоматизация винаги изискват малко повече режийни разходи по време на първоначалната настройка.
Но както беше посочено по-горе, това може да доведе до печалби и печалби драстично при тестови скорости. Той също така произвежда съответно намаляване на персонала в рамките на няколко дни. Облачните базирани тестови среди допълнително намаляват разходите. Това става чрез елиминиране на недостатъчно използваната и скъпа локална инфраструктура за тестване.
г) Последователността трябва да бъде четвъртият мит.
Достатъчно добре трябва да бъде проведено, екзекутирано и експлоатирано. За различните екипи за тестване готовите внедрявания са субективни решения, изградени върху възприятията за много различни ръчни тестери. Те знаят, че смисълът е в това, че бъговете попадат през пукнатини.
Припокриващите се тестови покрития трябва да улавят най-често срещаните и критични проблеми преди изданията. Останалите грешки чакат издания за поддръжка.
Истинският сценарий на четвъртия мит:
Качествата не са качествени. Готовността на продукции не трябва да бъде фактори и въпроси на мненията. В чисто ръчна среда за тестване възприятията варират от един тест до друг тест и един тестер до друг тестер. Това води до непостоянни резултати от тестове и несъвместима документация.
Решенията се усложняват, когато присъстват съображения за готовност на продуктите. Това води до провали в спазването, масово разочарование и загуба на приходи. Освен това има създаване на джобове на племенни незаловени разбирания, които се губят, когато хората и служителите излязат от вратата.
Автоматизацията от своя страна създава количествено измерими показатели. Това служи като обективни източници на истината за информиране на решения относно обосновката на бизнес решението, готовността на продукта и напредъка на екипите от таблици.
д) Нежеланието е петият мит.
Ръчното тестване е заменено с тестване за автоматизация. Много различни разработчици имат достъп до автоматизацията на тестовете, защото те очакват да заменят тестерите, които са ръчни, с машини.
В случай че автоматизацията на тестовете повтаря подобни тестове 1000 пъти със 100 процента точност, тогава възникват запитвания защо има нужда от хора за целите на тестването. Автоматизацията на тестовите скриптове може да се извърши и от машини.
Картината в реално време на петия мит:
Ръчните тестери стават по-добри с тестовете за автоматизация. Машините и хората притежават добри сценарии за много различни неща и фактори. Тестерите, които правят ръчно тестване, винаги могат да тестват по-креативно.
Тестовете за автоматизация ги освобождават от това. Докато хората се радват на по-нови начини за разбиване на приложения, автоматизацията осигурява съответствие в широк спектър от устройства. Това е от единични тестове до пълни регресионни тестове. Не е необходимо два подхода да работят поотделно.
За да се извършват тестове, това е изследователски ръчно, докато системите с обратна връзка не са били под натоварване от автоматизирано тестване. Това са отлични начини за откриване на грешки, които се появяват в производствени среди. Тестването за автоматизация не замества изпитателите, които са хора. Това им позволява да водят полезна и интересна работа.
По-добрата последователност, покритие, цена и скорост се добавят към тези качества, които се подобряват. Спестяването на пари и време означава, че човек може да направи повече тестове и не по-малко. Това е случаят, когато човек достигне ключови етапи. Това позволява тестването да бъде в крак с екипите от пъргави разработки, вместо да стои на пътя.
Така организациите пускат код много по-често. Това намалява въздействията и количеството на дефектите се изгражда. Това означава, че разработчиците работят с чисти кодове. Поправянето на грешки е по-малко сложно драматично. Това освобождава тестерите чрез подметка, действаща като вратари, фокусирани върху творчеството. По този начин проучвателните тестове подобряват качествата на продуктите.
Автоматизираното тестване на мобилни потребителски интерфейси предлага предимства по отношение на времената и качествата. Инструменти, които са автоматизирани, улесняващи тестерите за оценка на потребителските интерфейси на приложения чрез разширен обхват на мобилните устройства, заедно с извършване на модификации за лесно повишаване на потребителския опит.
Заключение
Лошият GUI е неприятно изживяване за потребителя. Тестването на GUI е силно препоръчително и важно, особено когато става въпрос за интелигентни устройства, тъй като тук размерът на екрана е сравнително малък и на пазара се предлагат много вариации на устройствата.
Вашето приложение може да изглежда и да се държи по различен начин на различни устройства. Така че е важно да тествате приложението поне на някои стандартни размери и вариации на устройства.
Всички мобилни приложения се нуждаят от тестване на потребителския интерфейс, но задълбочеността на необходимото тестване се определя от категорията или целта на приложението. Трябва да направите пълен анализ на функциите на потребителския интерфейс на приложението спрямо модела на телефона или версиите на операционната система, преди да финализирате тестовото си поле.
Въз основа на този анализ трябва да създадете вашите тестови случаи за тестване. Използвайте автоматизация навсякъде, където е възможно, за да спестите време.
Дръжте отворено око, докато тествате потребителския интерфейс, защото е прост, но има голям ефект върху продажбата на вашето приложение.
когато трябва да се извърши регресионно тестване
Разгледайте нашия предстоящ урок за подробна информация относно Мобилен реагиращ тест .
Препоръчително четене
- Урок за Appium за тестване на мобилни приложения за Android и iOS
- ТОП 15 най-добри инструмента за мобилно тестване през 2021 г. за Android и iOS
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Услуги за бета тестване на мобилни приложения (Инструменти за бета тестване на iOS и Android)
- Защо мобилното тестване е трудно?
- Първи стъпки с Robotium - най-популярният инструмент за тестване на потребителския интерфейс на приложението за Android
- Изтегляне на eBook за тестване на Primer
- 11 най-добри инструменти за автоматизация за тестване на приложения за Android (инструменти за тестване на приложения за Android)