Unit-тестирование (англ. unit testing) — это проверка корректности работы отдельных частей приложения в изолированной среде независимо друг от друга.
На практике unit-тесты пишутся для сложных функций, чтобы запускать их при внесении изменений в исходный код проекта с целью выявления регрессионных ошибок.
Регрессионная ошибка — ошибка, которая возникает в работе функции, при внесении изменений в другой части приложения.
Для unit-тестирования в Angular приложениях используется фреймворк Jasmine.
Созданное с помощью Angular CLI новое приложение по умолчанию устанавливает все инструменты, необходимые для unit-тестирования, и уже содержит тест для компонента AppComponent . Для его запуска из директории проекта выполните:
ng test
Команда собирает приложение в режиме отслеживания изменений и запускает все имеющиеся тесты. Файлы тестов должны быть названы в формате *.spec.ts . При создании элементов через Angular CLI эти файлы тестов создаются по умолчанию автоматически.
Что такое тестирование программного обеспечения (ПО)
Запуск в режиме отслеживания изменений означает, что при любом изменении исходного кода проекта тесты будут запускаться автоматически.
После выполнения команды ng test запустится браузер, в окне которого будет представлен результат тестирования. Отчет о тестировании также дублируется в консоль.
Рассмотрим структуру теста. Откройте файл /src/app/app.component.spec.ts для наглядности.
Общая структура теста:
1 2 3 4 5 6 7 8 9 10 11 12
import from ‘. ‘; . describe(‘related tests group’, () => beforeEach(() => ); it(‘test description’, async(() => expect(. ).toBe(. ); >)); . >);
Далее описываются сами тесты.
Функция describe() объединяет в себе группу взаимосвязанных тестов. Первым параметром она принимает текстовое описание группы, вторым — функцию, которая содержит конфигурацию и набор тестов.
Общепринято объединять в группу тесты, относящиеся к одному компоненту, сервису и т. д., а саму группу называть именем компонента, сервиса и т. д.
1 2 3
describe(‘AppComponent’, () => // >)
В describe() сам тест описывается функцией it() . Она также принимает в качестве параметров текстовое описание и функцию, в которой описана вся логика.
Проверка результата выполнения осуществляется с помощью функции expect() , принимающей итоговое значение, в связке с одной из функций соответствия
1 2 3 4 5 6
it(‘expect example’, () => let a = 5 a = a + 7 expect(a).toBe(12) >)
Функция beforeEach() используется для задания исходного состояния и вызывается перед каждой функцией it() . Например, перед запуском каждого теста необходимо создать экземпляр класса тестируемого компонента, и чтобы не делать это в каждой функции it() , можно использовать beforeEach() .
1 2 3 4 5
beforeEach(async(() => TestBed.configureTestingModule( declarations: [AppComponent], >).compileComponents() >))
Источник: angdev.ru
Тестировщик с нуля / Урок 1 / Что такое тестирование по
6 шагов для успешного тестирования приложений под Android
В связи с большой популяризацией мобильных приложений мы все чаще и чаще начинаем пользоваться мобильными устройствами. Такси, погода, новости, заказ еды и прочее, практически для всего уже существуют свои мобильные сервисы.
А раз количество приложений растет, то растет и потребность в качестве выпускаемых приложений. Это факт! Все больше и больше организаций приходят к тому, чтобы тестировать свои мобильные приложения. Конечно, зачастую, это делаем не мы с вами (тестировщики), а пользователи, заказчики. Но тем не менее, если приложение имеет большую аудиторию, то цена дефекта растет, а значит нужно уже не просто тыкать кнопочки, а прикладывать голову и знания для своевременного нахождения дефектов.
Так к чему я это?
Ах да! Есть просто куча материала, который говорит нам о том, что такое мобильное тестирование, как его проводить, как должен быть устроен процесс и куча куча всякой мукулатуры . Но мы ведь не просто тестируем мобилки, мы тестируем их на различных платформах!
На фоне это мы поговорим, какие особенности есть в тестировании мобильных приложений и на что нужно обратить внимание в первую очередь, прежде чем приступать к тестированию. И нашим объектом будет платформа Android.
Ну и раз я начал говорить о шагах к качественному выпуску мобильного продукта, то одними из первых шагов будет подготовка мобильной лаборатории.
В связи с тем, что количество мобильных устройств под платформой Android постоянно растет, важной составляющей при тестировании является работоспособность приложения под большим количеством устройств. Согласно официальной статистике Android, сегодня более чем в 190 странах доступны устройства на платформе Android, а количество всех устройств достигает сотни миллионов. Естественно, при таком огромной популярности платформы, каждое устройство имеет свои собственные специфические требования, такие как физический дизайн и пользовательский интерфейс различных атрибутов.
Если вы тестируете, то помните, что ваш парк должен включать не одно, не два и даже не десять устройств.
Часто на собеседования ко мне приходят тестироващики мобилок, и, когда разговор заходит о парке мобильных устройств, в 90% случае я слышу максимум 4-5 устройств, на которых принято тестировать в их компании.
Нельзя отталкиваться при выборе устройств от версии платформы.
Многие же считают, что если мы проверили приложение на Android 5.0 Lollipop на SAMSUNG Galaxy S6, то значит приложение работает.
Помимо платформы, есть ряд составляющих, таких как CPU, диагональ и разрешение экрана, ОЗУ, которые могут серьезно влиять на работоспособность Вашего приложения.
В среднем по статистике, которую мы сделали в результате нашего исследования, для полноценного тестирования мобильных приложений на Android нужно порядка 69 устройств на платформе Android.
Полные результаты исследования можно посмотреть тут:
При этом нужно всегда помнить, что многие программы могут быть доступны на еще большем количестве устройств, в том числе на низкобюджетных смартфонах, которые все чаще и чаще начинают появляться во многих рынках, особенно в Китае.
Если у Вас есть планы по расширению и выходу на международный рынок, нужно обязательно учитывать этот фактор и постоянно проводить аналитику для расширения парка устройств.
Если про размер экрана все понятно, то обычные тестировщики не всегда сталкиваются с понятием плотности.
Итак, плотность экрана (Screen density) — это количество физических пикселей дисплея.
По сравнению с достаточно малым количеством экранов на iOS, вариаций по размеру экрана и его плотности для платформ Android добавляют дополнительную сложность в тестировании. Несмотря на то, что существует более 12 000 различных устройств, официально Android их разделяет на 4 класса по размеру экрана и 6 классов по плотности.
Как мы видим, самые популярным размером экрана является «Normal» с плотностью hdpi, xhdpi, xxhdpi и mdpi, что важно учитывать при подготовке парка устройств для тестирования мобильных приложений.
Также отмечу, что эти данные постоянно обновляются на официальном сайте разработчиков Android, поэтому периодически перед тестированием проверяйте актуальность информации, т.к. мобильный рынок растет постоянно.
Официально Android поддерживает 10 платформ/версий, начиная с «Froyo» 2.2 и заканчивая «Marshmallow» 6.0. Но если говорить о сегодняшнем дне, то не все мобильные приложения поддерживают все версии и платформы. Поэтому, если и планировать тестирование, то нужно обязательно учитывать выполнение тест-кейсов на нескольких версиях Android.
Так, например, если мы посмотрим на текущий рынок, то уже давно вышли такие версии, как «Lollipop» 5.0-5.1 (которая вышла еще в декабре 2014 года) и «Marshmallow» 6.0, но лидером по прежнему является «KitKat» 4.4.
В чем важности использования различных платформ?
С одной стороны, не стоит тестировать на последних версиях платформы, т.к. именно таким тестированием можно буквально изолировать большое количество пользователей от приятной работы с Вашим продуктом.
С другой, если у вас приложение не обновляется до новых версий платформ Android, то есть риск потерять текущих пользователей, после того, как они обновят свою версию платформы Android.
Я как то просматривал Play Market и меня удивило, что практически для каждого приложения пользователи пишут о том, что на том или ином устройстве их приложение работает не правильно!
И иногда это действительно вымораживает нервирует. Когда вы скачиваете приложение особенно не через wi — fi и метров под 900 , запускаете его, а в ответ приложение не открывается!
Отсюда могу сказать, что важно протестировать продукт как минимум на 4-х, а лучше 5-ти версиях Android.
На этом мое творческое повествование о формировании парка мобильных устройств закончено.
Можем идти дальше!
Все, о чем я рассказал ранее, было этапом подготовки. Теперь поговорим о самом приятном, о мобильном тестировании. Я расскажу об основных проблемах, с которыми можно столкнуться при тестировании мобильных приложений.
На самом деле, многие могут посчитать, что это обычные и легкие задачи. Я не скрываю, да, это так, но если мы не проведем качественное тестирования, то при выпуске/обновлении нас будет ждать полный крах.
Начнем по порядку.
- Регистрация и вход в систему.
Пожалуй, более явного кейса для тестирования не найти, но тем не менее я не могу не остановится на этом. Тестирование любого мобильного приложения должно полностью покрывать процессы регистрации и входа в систему. Особое внимание можно обратить на то, что при тестировании данных процессов нужно выполнять их от начала до конца, при этом максимально генерируя всевозможные негативные тесты, начиная с некорректного ввода пароля и заканчивая SQL –иньекциями.
Если рассматривать мобильное тестирование на множестве устройств с различными разрешениями экранов, то всегда можно столкнуться с ситуацией, когда стандартные пункты меню, такие как, Справка, О нас, и другое будет просто недоступны, как визуально, так и физически при нажатии пальцем. Особенно это касается устройств с небольшими экранами, когда пытаешь попасть своим широким пальцем на ссылку. В итоге приходится прицеливаться и аккуратно нажимать
Любые функции, которые особенно связаны с текстовым набором, скроллингом, кнопкой «Назад» и другие, без которых функционирование приложение просто невозможно для нормального пользователя, должны обязательно проверяться в ходе тестирования. Кроме того, необходимо обязательно проверить, что приложение будет корректно работать при последовательном использовании физических кнопок и тачскрина.
Недавно скачал себе приложение KFC. Моей злости не было предела! Мало того, что у меня просто не нажимались кнопки добавления в корзину, так он еще и загружается минуту! И ресторан я свой искал руками, т.к. приложение упорно говорило мне, что я нахожусь в противоположной части города!
Как ведет себя приложение, когда батарея телефона на полном, среднем и низком заряде? Может ли пользователь воспользоваться вызовами или тестовыми сообщениями? Вы всегда должны знать, насколько работа других приложений (зачастую стандартных) может повлиять на работу Вашего приложения. Для этого очень полезен анализ crashlog.
Например, у меня на Lenovo, когда работает музыка через Bluetooth, постоянно при повторном запуске Яндекс Навигатора и при нажатии на кнопку GPS перезагружается телефон. Это ужасно, особенно когда ты едешь на скорости 100км/ч и у тебя пропал GPS, а нужно его перезагрузить. Начинается паника, куда ехать… И напоследок разработчики Android будут аплодировать сто я, самое крутое, что перезагружается телефон вот в таком формате:
И тут начинается лотерея! Физически тачскрин работает в портретной ориентации, а экран обрезан на половину и отображается в альбомной ориентации. Когда я первый раз наткнулся на такой баг, я 30 минут пытался попасть по кнопке перезагрузить телефон!
Но вернемся к теме мобильного тестирования.
Очень важно помнить, что зачастую приложение возможно использовать не только в портретной ориентации, но и в альбомной. Многие пользователи зачастую используют портретную ориентацию, но, вот лично мне, использовать навигатор или видео проигрыватель удобнее в альбомном режиме. Поэтому, при тестировании необходимо проверять, что функциональность и юзабилити мобильного приложения не изменяются при переходе из портретного режима в альбомный. Ниже покажу пример на все том же яндекс навигаторе:
Как видно, клавиатура закрывает всю возможность выбрать предыдущие адреса! Поэтому либо выбираем первый адрес, либо вводим его. Ну или тратим 5 минут, на то, что бы попробовать прокрутить адреса, при этом не нажав случайно на адрес или клавиатуру.
При тестировании мобильного приложения обязательно нужно проверять влияние настроек приложения на его производительность, в том числе эффект мобильного приложения на заряд батареи. Многие пользователи хотят использовать свое мобильное устройство минимум один день, при этом используя любимые ими приложения. Если ваше приложение пользуется большой аудиторией, то вы обязательно должны знать, как оно влияет на ресурс питания телефона. Для этого рекомендуется проводить тесты эксплуатации.
- Влияние на работу устройства.
Говоря об эксплуатации, подразумевается работа приложения в обычном режиме. Для тестирования необходимо запустить приложение и использовать его в течении 6-12 часов. При использовании необходимо каждые 30 минут или 1 час измерять уровень заряда батареи. Зачастую такая проверка автоматизирована, чтобы не тратить время тестировщика на сбор данных. Если результаты теста показывают, что снижение уровня заряда батареи происходит раньше 6 часов при условии работы со всеми фоновыми функциями вашего телефона, то это явно указывает на проблемы в приложении.
Я думаю у каждого была ситуация, когда вы скачиваете приложение, а потом оно сжирает у вас за 30 минут 20% аккумулятора. Я не помню их названия, но такие были точно!
Помимо основной функциональности существует ряд проблем, с которыми можно столкнуться при тестировании мобильных приложений на Android. Обязательно при тестировании нужно обратить внимание на:
Спец символы. Если приложение, которые вы тестируете включает поля поиска или формы ввода, обязательно нужно проверить на возможность ввода спецсимволов.
Длительное нажатие на экран. Обязательно нужно проверить, что при нажатии и удерживании тачскрина в полях ввода работают стандартные функции Android на копирование и вставку. Нужно удостовериться, во-первых, что эти функции работают и они не перепутаны, а во-вторых, что долгое нажатие на экран приложения не приводит к сбоям.
Виртуальная клавиатура. В большинстве устройств, работающих на Android, клавиатуры виртуальные. Если пользователь изменяет размер и визуальную обложку клавиатуры нужно убедиться, что эти изменения не влияют использование мобильного приложения, и, что хуже, не искажают его до невозможности использования.
Дополнительно всегда ставьте себя на место реального пользователя и тестируйте приложение с точки зрения потенциально реальных ситуаций в работе пользователей.
Помните, что любые отказы ведут к недовольству пользователя приложения.
В целом я не считаю себя специалистом по тестированию безопасности, но тем не менее есть определенные проверки, которые нужно выполнять, чтобы обезопасить конечных пользователей.
Любая система должна обеспечивать соблюдение требований к информации:
- Конфиденциальность. Недоступны ли личные данные пользователей?
- Целостность. Нет ли возможности извне изменить личные данные при их передаче?
- Аутентификация. Как приложение проверяет, что именно я являюсь владельцем аккаунта?
- Доступность. Как и при каких условия возможность сломать/ сделать неработоспособным приложение?
- Отказоустойчивость. Как ведется учет всех отказов системы?
Если специалисты по безопасности предусмотрели все эти пункты, а также проверили методы шифрования информации при передаче, а также протестировали возможно подключения к стандартным функциям устройства через API (контакты, камера или GPS), то можно считать, что Ваше приложение пригодно для использования пользователями.
И помните, что излишняя навязчивость пользователю политики конфиденциальности тоже может отбить желание пользоваться мобильным приложением!
Ну и напоследок….
Мне пришлось изрядно порыться в Google Play, но это оказалось очень полезным.
Удалось относительно определить основные проблемы, с которыми сталкиваются пользователи:
- 55% жалуются на установку
- 24% жалуются на производительность
- 13% говорят об отказах приложения
- 5% пишут, что их приложение подтормаживает или зависает.
- 2% жалуются на UI
- 1% на проблемы с конфиденциальностью или безопасностью.
И как всегда негативных отзывов больше чем положительным, а это говорит о том, что очень мало в России компаний, которые полноценно тестируют свои мобильные продукты. Плохие отзывы могут просто слить выход приложения, прежде, чем оно начнет успешно работать.
Тестируйте мобильные приложения, как на эмуляторах на стадии разработки, так и на реальных девайсах на стадии полноценного тестирования. Такие функции, как акселерометр, использование сенсорного экрана или отображение расположения просто невозможно проверить на эмуляторах.
Не гонитесь за дешевыми эмуляторами, клавиатура и мышь никогда не заменит полноценного использования реального девайса руками.
Надеюсь было полезно!
Источник: www.performance-lab.ru
Автоматизированное тестирование сайта — за и против. С расчетами
Там мы делимся «квинтэссенцией» своей экспертизы— постим выжимки статей, анализируем UX-решения, делаем разборы продуктов, делимся образовательными курсами и чек-листами.
Тестирование — заключительный этап разработки сайтов и программного обеспечения. Он позволяет ответить на три важных вопроса: соответствует ли продукт изначальной задумке, все ли работает как надо и что нужно сделать, чтобы ответ на первые два вопроса был положительным.
Передача проекта тестировщику — по сути, репетиция финального согласования с клиентом и отправки продукта в массы. То есть тестировщик — это тот же клиент и пользователь, только на стороне агентства. И его задача — сделать так, чтобы на выходе получить качественный продукт, который соответствует ожиданиям или превосходит их.
Есть два типа тестирования: ручное и автоматизированное. В первом случае контроль качества производит человек — тестировщик (или QA-инженер) — посредством моделирования действий пользователя. Специальные программы для проверки сайта не применяются.
Во втором случае запуск, инициализация, выполнение, анализ и выдача результата производятся автоматически с помощью специальных инструментов. Тестировщик обрабатывает полученные результаты.
Рассмотрим оба типа подробнее.
Преимущества и недостатки ручного и автоматизированного тестирования
В маленьких компаниях тестированием занимаются сами менеджеры проектов. В компаниях побольше — тестировщики (QA-инженеры), которые применяют ручные методы проверки продуктов. Дальнейший рост компании подразумевает рост количества проектов, а значит есть 2 решения: или увеличить штат специалистов, или сделать так, чтобы при том же количестве тестировщиков сохранилось (а лучше — чтобы улучшилось) качество на выходе. Какое решение выбрать — дело за вами. Чтобы вам было проще сориентироваться, мы сравнили оба типа тестирования.
Ручное тестирование
Преимущества
- Тестировщик оценивает продукт как обычный пользователь и может предоставить максимально развернутый и понятный отчет о работе функционала.
- Специалист смотрит не только функционал, но и дизайн, поэтому может оценить удобство сайта. Программа — нет.
- Возможна реализация нетипичных сценариев — человек может найти баг, который не найдет программа.
- Ручная проверка нетипичных сценариев обходится дешевле, чем их автоматизация.
- Несущественные изменения тестировщик может проверять сразу после их реализации.
Недостатки
- Присутствует человеческий фактор — каким бы профессионалом ни был тестировщик, он может допустить ошибку.
- Нет возможности моделировать высокую нагрузку, а значит нельзя объективно оценить, как поведет себя сайт при большом количестве пользователей.
- Ручное тестирование занимает больше времени, чем автоматизированное.
Источник: www.uplab.ru