Главная цель программирования – это написание программы, но к сожалению, в большинстве случаев первый запуск приводит к ошибке. Какие же бывают ошибки?
Во-первых, программа может содержать синтаксические ошибки.
Во-вторых, при в воде корректных данных в программу, она может выдавать неправильный результат.
И в-третьих программа может неправильно реагировать на ввод некорректных данных.
Каким же образом нам найти ошибки в программе?
В этом поможет тестирование и отладка.
Отладка — это определение места ошибки и её исправление с использованием процессов выполнения его программ.
Тестирование — это процесс выполнения программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ.
Цель тестирования обнаружение ситуации, при которой результаты работы программы не соответствуют ожидаемому. Но все ситуации проверить невозможно, из-за их огромного числа.
Для уменьшения количества тестов необходимо распределить на группы все возможные варианты выполнения программы. Существует два подхода: подход «черного ящика» и «белого ящика». Критерии черного ящика не учитывают внутреннее устройство программы. Критерии белого ящика учитывают.
Тестирование НА ПРИМЕРЕ | Тестирую DEVBY
В начале тестирования необходимо использовать подход черного ящика. Если их оказывается недостаточно, они дополняются тестами белого ящика.
Глава 1. МЕТОДЫ ТЕСТИРОВАНИЯ
1.1 Критерии черного ящика
Существуют следующие критерии черного ящика:
1) тестирование функций;
2) тестирование классов входных данных;
3) тестирование классов выходных данных;
4) тестирование области допустимых значений (тестирование границ класса);
5) тестирование длины набора данных;
6) тестирование упорядоченности набора данных.
Критерий тестирования функций актуален для многофункциональных программ. Он требует выполнения хотя бы одного теста для каждой из функций, реализуемых программой.
Критерий тестирования классов входных данных требует классифицировать входные данные, разделить их на классы таким образом, чтобы все данные из одного класса были равнозначны с точки зрения проверки правильности программы. Считается, что если программа работает правильно на одном наборе входных данных из этого класса, то она будет правильно работать на любом другом наборе данных из этого же класса. Критерий требует выполнения хотя бы одного теста для каждого класса входных данных.
Критерий тестирования классов выходных данных выглядит аналогично предыдущему критерию, только проверяются не входные данные, а выходные.
Надо отметить, что часто эти три критерия хорошо согласуются друг с другом. При применении одного из них остальные будут удовлетворены автоматически. Если программа реализует несколько функций, то вполне естественно, что каждой из этих функций будет соответствовать свой класс входных и свой класс выходных данных. Часто существует соответствие между классами входных и выходных данных.
Топ программ для тестирования ПК
Тестирование области допустимых значений (тестирование границ класса). Если область допустимых значений переменной представляет собой простое перечисление (например, имена, цвет, пол т. п.), надо проверить, что программа правильно понимает все эти значения и не принимает вместо них никаких иных значений. Например, как программа отреагирует на попытку ввести несуществующую пол.
Если класс допустимых значений представляет собой числовой диапазон, то понадобится более серьезная проверка. В этом случае выделяются:
1) нормальные условия (в середине класса);
2) граничные (экстремальные) условия;
3) исключительные условия (выход за границу класса).
Например, пусть программа предназначена для обработки деканатом информации об одной студенческой группе. Нормальное число студентов в группе — 20–25. Но на младших курсах их часто бывает больше, а на старших — наоборот. Пусть максимальное число студентов в группе ограничено 30.
В этом случае имеет смысл проверить правильность работы программы с группой из 20 студентов (нормальные условия), с группой из 30 человек и с группой из одного человека (экстремальные условия). Необходимо проверить, как программа отреагирует на приказ о зачислении в группу 31-го студента и об отчислении последнего остававшегося в группе студента (исключительные условия).
Иногда требуется более тонкая градация. Возможна ситуация, когда вся область допустимых значений делится на отдельные подобласти, требующие от программы разной реакции. Например, пусть программа готовит сводный отчет о работе некоторой фирмы. Известно, что ежедневно фирма продает продукции примерно на 30 тыс. руб.
Как должна реагировать программа на сообщение о том, что доход за день 10 руб. или 1 000 000руб.? Теоретически можно допустить, что этот фирма сработала настолько плохо или, наоборот, потрясающе. Однако логично предположить, что в этих случаях при вводе данных возникли проблемы или данные введены не верно?
В результате вся область допустимых значений делится на 3 подобласти: подобласть нормальных значений, подобласть подозрительно больших значений и подобласть подозрительно маленьких значений. Нормальные данные программа должна просто обрабатывать. Подозрительно большие и подозрительно малые значения допустимы, однако при их получении имеет смысл затребовать подтверждения, действительно ли все верно введено.
Впрочем, вместо деления области допустимых значений на подобласти можно было бы просто выделить 3 класса входных данных: нормальные, слишком маленькие, слишком большие.
Следующие два критерия являются частными случаями, уточняющими ранее названные критерии. Но в силу их важности и частой применимости, они заслуживают отдельного упоминания.
Тестирование длины набора данных можно считать частным случаем тестирования области допустимых значений. В данном случае речь пойдет о допустимом количестве элементов в наборе. Если программа последовательно обрабатывает элементы некоторого набора данных, имеет смысл проверить следующие ситуации:
1) пустой набор (не содержит ни одного элемента);
2) единичный набор (состоит из одного-единственного элемента);
3) слишком короткий набор (если предусмотрена минимально допустимая длина);
4) набор минимально возможной длины (если предусмотрено);
5) нормальный набор (состоит из нескольких элементов);
6) набор из нескольких частей (если такое возможно. Например, если программа читает литеры из текстового файла или печатает текст, то как она отнесется к переходу на следующую строку? На следующую страницу?);
7) набор максимально возможной длины (если предусмотрено);
8) слишком длинный набор (с длиной больше максимально допустимой).
Тестирование упорядоченности входных данных важно для задач сортировки и поиска экстремумов. В этом случае имеет смысл проверить следующие ситуации (классы входных данных):
1) данные неупорядочены;
2) данные упорядочены в прямом порядке;
3) данные упорядочены в обратном порядке;
4) в наборе имеются повторяющиеся значения;
5) экстремальное значение находится в середине набора;
6) экстремальное значение находится в начале набора;
7) экстремальное значение находится в конце набора;
8) в наборе несколько совпадающих экстремальных значений.
1.2 Критерии белого ящика
Первый из критериев белого ящика — критерий покрытия операторов. Он требует подобрать такой набор тестов, чтобы каждый оператор в программе выполнился хотя бы один раз.
В качестве примера рассмотрим следующий фрагмент Java программы:
Для того чтобы удовлетворить критерию покрытия операторов, достаточно одного выполнения. Такого, чтобы x был больше 3. Очевидно, что ошибка в программе этим тестом обнаружена, не будет. Она проявится как раз в том случае, когда x
Итак, мы имеем программу, оттестированную с точки зрения критерия покрытия операторов и при этом содержащую ошибку.
Следуя критерию покрытия операторов, мы проверили только положительную ветвь развилки, но не затронули отрицательную.
Чтобы избавиться от указанного недостатка, введем второй критерий белого ящика — критерий покрытия ветвей (иначе его называют критерием покрытия решений). Он требует подобрать такой набор тестов, чтобы каждая ветвь в программе была выполнена хотя бы один раз. Тестирование с точки зрения этого критерия обнаружит ошибку в предыдущем примере.
Рассмотрим другой пример. На Java он будет выглядеть
Для того чтобы удовлетворить критерию покрытия ветвей, в данном случае достаточно одного теста. Например, чтобы x был равен 6 или 5. Все ветви программы будут пройдены (при x = 5 одна из ветвей — тело цикла — даже 2 раза). Но ошибка в программе обнаружена так и не будет! Она проявится в одном-единственном случае, когда x = 0. Но такого теста от
нас критерий покрытия ветвей не потребовал.
Итак, мы имеем программу, оттестированную с точки зрения критерия покрытия ветвей и при этом содержащую ошибку. Причина в том, что некоторые ветви в программе могут быть пройдены несколько раз, и результат выполнения зависит от количества проходов. Для того чтобы учесть этот факт, введем третий критерий белого ящика — критерий покрытия путей. Он требует подобрать такой набор тестов, чтобы каждый
путь в программе был выполнен хотя бы один раз. Тестирование с точки зрения этого критерия обнаружило бы ошибку в примере 2. Но из этого же примера виден принципиальный недостаток данного критерия. В примере 2 возможно бесконечно много путей. Проверить их все невозможно.
Значит, как только в программе появляются циклы с пред- или постусловием или цикл со счетчиком, но с вычисляемыми границами, количество путей в программе становится потенциально бесконечным, и критерий покрытия путей становится неприменимым. Необходим какой-то компромиссный критерий. Более жесткий, чем покрытие ветвей, но менее жесткий, чем
Кроме проблем с проверкой циклов существенные проблемы связаны с проверкой сложных условий — логических выражений, содержащих знаки дизъюнкции и/или конъюнкции.
И в том, и в другом операторе можно пройти по обеим ветвям, изменяя значение только одного из простых условий. Пусть c не равно 0. Меняя значение переменных a и b, можно пройти и по ветви «то», и по ветви «иначе». При этом ситуация, когда c = 0, останется непроверенной. Аналогично, пусть i n. Для того чтобы учесть подобные ситуации, были предложены следующие критерии:
-критерий покрытия условий;
-критерий покрытия решений/условий;
-критерий комбинаторного покрытия условий.
Критерий покрытия условий требует набор тестов, при котором каждое простое условие (слагаемое в дизъюнкции и сомножитель в конъюнкции) получит и значение «истина», и значение «ложь» хотя бы один раз.
Критерий пытается «в лоб» исправить вышеуказанный недостаток в тестировании сложных условий. Однако сам оказывается весьма слаб. Дело в том, что выполнение критерия покрытия условий не гарантирует покрытие ветвей. Пусть сложное условие представляет собой дизъюнкцию двух слагаемых.
При первом выполнении первое слагаемое истинно, второе ложно, вся дизъюнкция истинна. При втором выполнении первое слагаемое ложно, второе истинно, вся дизъюнкция истинна. Критерий покрытия условий выполнен, критерий покрытия ветвей — нет. Ошибка не найдена.
Чтобы исправить этот недостаток, критерии покрытия ветвей (решений) и условий объединяют в единый критерий покрытия решений/условий. Он требует набор тестов, при котом каждая ветвь в программе была пройдена хотя бы один раз и чтобы каждое простое условие (слагаемое в дизъюнкции и сомножитель в конъюнкции) получило и значение «истина», и значение «ложь» хотя бы один раз. Критерий надежнее, чем простое покрытие ветвей, но сохраняет его принципиальный недостаток: плохую проверку циклов. Приведенный выше пример 2, «ломающий» критерий покрытия ветвей, «сломает» и критерий покрытия решений/условий. Ошибка в данном случае проявится только при фиксированном количестве повторений цикла (в примере 2 — семикратном), а критерий покрытия решений/условий не гарантирует, что повторений будет именно столько.
Совмещение критериев покрытия ветвей и покрытия условий не решает также всех проблем, порождаемых сложными условиями. Ошибки могут быть связаны не со значением того или иного простого условия, а с их комбинацией.
В примере 3 шибка будет выявлена только при одновременном равенстве нулю двух переменных: a и b. Критерий покрытия решений/условий не гарантирует проверки такой ситуации.
Для решения данной проблемы был предложен критерий комбинаторного покрытия условий, который требует такой набор тестов, чтобы хотя бы один раз выполнялась любая комбинация простых условий. Критерий значительно более надежен, чем покрытие решений/условий, но обладает двумя существенными недостатками. Во-первых, он может потребовать очень большого числа тестов. Количество тестов, необходимых для проверки комбинации n простых условий, равно 2 в степени n . Комбинация двух условий потребует четырех тестов, трех условий — восьми, четырех условий — шестнадцати тестов и т. д. Во-вторых, даже комбинаторное покрытие условий не гарантирует надежную проверку циклов. Тот же самый пример 2, который демонстрировал недостатки покрытия ветвей и покрытия решений/условий, покажет и недостаток комбинаторного покрытия условий.
1.3 Минимальное грубое тестирование
Обзор критериев белого ящика, подводит к необходимости построения некоторого компромиссного критерия, который, с одной стороны, обеспечивал бы достаточную надежность тестирования, а с другой — имел приемлемую сложность. В качестве такого компромисса был предложен критерий минимально грубого тестирования (МГТ). МГТ представляет собой критерий покрытия решений/условий, усиленный дополнительными требованиями по проверке циклов. Проверка циклов организуется по следующим правилам:
1) для каждого цикла с предусловием должна быть проверена
правильность при кратном нулю, однократном и многократном повторении тела цикла. Многократным считается любое повторение более одного раза;
2) для каждого цикла с постусловием должна быть проверена
правильность при однократном и многократном повторении
3) проверка цикла со счетчиком зависит от того, фиксированы
ли границы изменения счетчика или вычисляются. Вообще
говоря, как и для цикла с предусловием, требуется проверка
при нулькратном, одно- и многократном повторении тела
Одно из преимуществ критерия МГТ состоит в том, что для него существует удобное представление в форме таблицы, которое позволяет контролировать степень выполнения критерия и придумывать тесты прицельно для проверки именно нужных частей программы. Строится таблица МГТ следующим образом.
Строки таблицы соответствуют проверяемым условиям, графы — тестам. Для каждого условного оператора в таблице МГТ создаются 2 строки: для ветви «то» и ветви «иначе».
Источник: www.evkova.org
Как лучше тестировать приложения
Приложений с багами слишком много. Возможно, вы тоже увеличиваете их количество. Рассказываем, как находить и исправлять больше ошибок.
Евгений Кучерявый
Пишет о программировании, в свободное время создаёт игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Недавно я прочитал рассылку Skillbox о простом способе стать профи, в которой Андрей Коновалов — наш главред — рассказывает о талантливом программисте, который придумывает хорошие решения, но никак не может сдать их с первого раза, потому что не проверяет их. Это мешает ему стать профессионалом.
Я хочу дополнить эту тему несколькими советами из личного опыта о том, как разработчику тестировать свои приложения.
Проверяйте абсолютно всё
Критический баг может затаиться в любом фрагменте кода. Если вы думаете, что какой-то кусочек вашей программы слишком прост, чтобы в нём была ошибка, то вы ошибаетесь. Яркий пример — уязвимость в программе «Блокнот» для Windows, которая позволяет получить доступ к компьютеру жертвы.
Даже если с безопасностью приложения всё в порядке, в нём могут затаиться мелкие ошибки или даже фатальные баги. Они либо ухудшат опыт пользователей, либо вовсе сделают ваш проект бесполезным.
Тестируйте каждую фичу несколько раз
Допустим, у вас есть функция загрузки аватара, которая идеально сработала во время тестирования. Вы можете забыть о ней и так и не узнаете, что если пользователь захочет поменять фотографию, то получит ошибку: приложение не сможет загрузить новый файл, потому что вы не удалили старый.
Чтобы избежать таких ситуаций, нужно несколько раз тестировать каждую функцию. Причём стоит использовать как разные данные, так и одинаковые, чтобы убедиться, что всё работает как часы.
Тестируйте фичи вместе
Бывает и так, что фичи работают отлично по отдельности, но ломаются, если комбинировать их. Допустим, вы написали систему комментариев, в которой можно форматировать текст: выделять его жирным или курсивом, добавлять ссылки и так далее.
Логично, что, написав функцию выделения жирным, нужно проверять именно её. То же самое касается и остальных функций. Но когда система будет готова, нужно протестировать сразу всё. Иначе вы вдруг узнаете, что если добавить ссылку на курсивный текст, а потом сделать всё это жирным, то можно получить доступ к панели администратора.
Вот только тогда будет уже поздно.
Проводите полное тестирование даже после небольшой модификации
Чаще всего я наступал на такие грабли:
- фича отлично работает при тестировании;
- добавляешь что-нибудь и тестируешь обновление;
- через некоторое время узнаёшь, что теперь не работает ничего, кроме самого обновления.
Такое может происходить, если вы сначала реализовали возможность добавления записи в базу данных, а потом добавили новое поле в таблицу. Например, вы создали функцию публикации постов, а позже вспомнили, что забыли добавить поле с количеством просмотров.
Теперь при добавлении поста будет выдаваться ошибка, потому что для нового поля не указано значение по умолчанию. Поэтому перед сдачей проекта нужно проверять все фичи, исправлять баги и проверять всё ещё раз.
Будьте новым пользователем
После того как реализуешь возможность регистрации и авторизации, всегда заходишь с одного и того же аккаунта. Из-за этой привычки я чуть не пропустил очень серьёзный баг — сломавшуюся регистрацию.
Поэтому во время каждого тестирования нужно проходить тот путь, который прошёл бы новый пользователь. Именно отсюда растут ноги отговорки «У меня всё работает».
Продумывайте архитектуру
По-хорошему, с этого нужно начинать. Но давайте будем честны сами с собой: мы прекрасно знаем этот совет, но всё равно каждый раз начинаем писать код, ничего не продумав как следует.
Именно из-за этого появляется куча несовместимого или повторяющегося кода. Особенно печально, если код повторяется, но в нём есть небольшие отличия.
Например, вы могли написать метод UploadProfileImage (), а потом вспомнить, что нужно ещё добавить метод UploadMessageAttachment (). Скорее всего, отличаться в этих методах будут только запросы к базе данных, пути и допустимые форматы.
Источник: skillbox.ru
Основные этапы тестирования мобильных приложений
24.06.2019
29675
Рейтинг: 5 . Проголосовало: 3
Вы проголосовали:
Для голосования нужно авторизироваться
- Этап 1: Планирование
- Этап 2. Определение необходимых типов тестирования мобильных приложений
- Этап 3: Тестовые случаи и разработка сценариев тестирования приложения
- Этап 4: Ручное и автоматическое тестирование
- Этап 5: Тестирование юзабилити и бета-тестирование
- Этап 6: Тестирование производительности
- Этап 7: Аттестационное тестирование и тестирование безопасности приложения
- Этап 8: Тестирование устройства
- Этап 9: контрольный этап и резюме
- Вывод
Ваш пошаговый алгоритм тестирования мобильных приложений
Обеспечение качества (QA, от английского — Quality Assurance) является неотъемлемой частью жизненного цикла разработки любых приложений, включая мобильные. К сожалению, многие упускают из виду критические особенности тестирования мобильных приложений, которые часто приводят к сбоям, ошибкам в работе приложения и плохому качеству обслуживания клиентов.
Чтобы обеспечить успешную разработку любого приложения, специалист-тестировщик должен принимать участие во всех этапах разработки — от создания концепции и анализа требований, до создания спецификаций тестирования и выпуска готового продукта. Обеспечение качества также является ключевым элементом в последующих, после прохождения этапов разработки, обзорах программного продукта.
Однако часто бывает сложно определить, с чего начать организацию процесса тестирования мобильного приложения. Для беспроблемного тестирования мы рекомендуем просто выполнить девять указанных ниже шагов.
Давайте рассмотрим особенности тестирования мобильных приложений.
Цикл жизни спринтов
Этап 1: Планирование
Когда этап разработки приложения почти завершен, вы должны снова поставить перед собой вопрос — чего вы пытаетесь достичь разработкой данного приложения и какие у вас есть ограничения.
Вы должны определить следующее:
- Взаимодействует ли ваше приложение с другими приложениями?
- Насколько функциональны все возможности приложения?
- Является ли тестируемое мобильное приложение нативным, Mobile-web или гибридным?
- Ограничена ли задача тестирования приложения тестированием только внешнего интерфейса?
- Стоят ли задачи на тестирование бэкенда?
- Какова должна быть совместимость с различными беспроводными сетями?
- Как сильно данные приложения и свободное пространство, занимаемое им, зависят от особенностей использования приложения?
- Насколько быстро загружается ваше приложение, насколько быстро происходит серфинг по меню приложения и его функциям?
- Как будет обрабатываться возможное увеличение нагрузки на приложение?
- Влияют ли различные изменения в статусе и состоянии телефона на работу мобильного приложения?
Убедитесь, что вы договорились с командой тестировщиков о роли каждого из них и о ваших ожиданиях от процесса тестирования. В конце концов, общение является ключом к поддержанию правильной рабочей среды в команде.
Правильное понимание ролей и задач также относится и к моменту прописывания списка тест кейсов. Вся команда QA должна поддерживать и обновлять этот документ с отчетами по тестированию всех функций, реализованных на протяжении всего процесса разработки.
Этап 2. Определение необходимых типов тестирования мобильных приложений
Перед тестированием любых мобильных приложений определите, что именно в данном мобильном приложении вы хотите протестировать: набор функциональности, удобство использования, совместимость, производительность, безопасность и т. д. На этом же этапе имеет смысл выбрать методы тестирования мобильного приложения.
Тема связана со специальностями:
Определите, на какие целевые устройства направлено данное приложение, и какие требования к функционалу следует проверить.
Вы также должны определить, какие целевые устройства нужно включить в список тестирования.
Вы можете сделать это следующим образом:
• Выяснить, какие устройства будет поддерживать приложение;
• Определить, какая версия операционной системы будет самой ранней из тех, что поддерживаются приложением;
• Выявить наиболее популярные модели мобильных устройств у целевой аудитории;
• Определить набор не основных (дополнительных) устройств с экранами разных размеров, потенциально поддерживаемых приложением;
• Решить, будете ли вы использовать для тестирования физические устройства или их эмуляторы.
Этап 3: Тестовые случаи и разработка сценариев тестирования приложения
Подготовьте документ, описывающий тестовые случаи (test cases) для каждой тестируемой функции и функциональности.
В дополнение к функциональным тестовым случаям, также должны быть охвачены некоторые отдельные моменты (кейсы):
• Особенность использование батареи;
• Скорость работы приложения;
• Требования к данным;
• Объем используемой памяти.
Также перед началом тестирования важно определиться, какое сочетание ручного и автоматического тестирования вы будете применять.
При необходимости подготовьте отдельные наборы ручных тестовых случаев и сценариев для автоматического тестирования и адаптируйте их согласно требованиям проекта.
Этап 4: Ручное и автоматическое тестирование
Теперь пришло время для выполнения ручных и автоматизированных тестов.
Ранее, на предыдущих этапах, вы уже определили, какие тесты и скрипты использовать и подготовили их. Теперь, на текущем этапе, вы выполняете запуск тестов для проверки механизмов основной функциональности, чтобы убедиться в отсутствии поломок.
Автоматизированное тестирование мобильных приложений хорошо экономит время и другие ресурсы тестировщиков.
Этап 5: Тестирование юзабилити и бета-тестирование
После того, как базовый функционал протестирован, настало время убедиться, что мобильное приложение является достаточно простым в использовании и обеспечивает удовлетворительный пользовательский опыт. На этом этапе необходимо поддерживать соответствие матрице кроссплатформенности, чтобы обеспечить охват пользователей различных платформ, достигнутый бета-тестерами.
Пример матрицы поддержки разных версий платформы iOs
После того, как приложение будет протестировано внутри компании, вы сможете выпустить бета-версию приложения на рынок.
Тестирование совместимости
Мобильные устройства различаются в зависимости от платформы, модели и версии их операционной системы. Важно выбрать такое подмножество устройств, которое будет соответствовать вашему приложению.
Тестирование пользовательского интерфейса
Пользовательский опыт является ключевым элементом, при тестировании приложения. Ведь наше приложение разрабатывается именно для конечных пользователей. Вам следует качественно проверить удобство использования приложения, навигацию по его элементам и контент. Тестируйте меню, опции, кнопки, закладки, историю, настройки и навигацию приложения.
Тестирование интерфейса
Тестирование пунктов меню, кнопок, закладок, истории, настроек и навигации по приложению.
Тестирование внешних факторов
Приложения для мобильных устройств не будут единственными приложениями на устройстве пользователя. Вместе с вашим приложением будут установлены приложения от сторонних разработчиков. Возможно десятки таких приложений. Следовательно, вашему приложению придётся взаимодействовать с этими сторонними приложениями и прерывать работу различных функций устройства, таких как различные типы сетевых подключений, обращение к SD-карте, телефонные звонки и другие функции устройства.
Тестирование доступности
Мобильными устройствами могут пользоваться различные люди с ограниченными возможностями. По этой причине важно протестировать возможность работы с приложением людей с дальтонизмом, нарушениями слуха, проблемами пожилого возраста и другими возможными проблемами. Такое тестирование является важной частью общего тестирования юзабилити.
Видео курсы по схожей тематике:
Web Testing automation on Java
Тестирование безопасности веб-приложений
Этап 6: Тестирование производительности
Мобильные устройства предоставляют для приложений меньший объем памяти и меньшую доступную мощность процессора, чем стационарные компьютеры и ноутбуки. По этой причине в работе мобильных приложений очень важна эффективность использования предоставляемых ресурсов. Вам следует проверить работоспособность тестируемого приложения, изменив соединение с 2G, 3G на WIFI, проверить скорость отклика, потребление заряда батареи, стабильность работы и т. д.
Рекомендуется проверять приложение на предмет масштабируемости применения и наличие возможных проблем с производительностью.
В рамках этого этапа важно пройти и нагрузочное тестирование мобильного приложения.
Функциональное тестирование
Функциональность приложения должна быть полностью протестирована. Особое внимание следует уделить установке, обновлениям, регистрации и входу в систему, обеспечению, работе со специфическими функциями устройства и сообщениям об ошибках.
Функциональное тестирование мобильного приложения, по большей части, может быть выполнено так же, как вы выполнили бы его для любого другого типа приложения. По этой причине мы не будем вдаваться в подробности этого типа тестирования. Однако следует указать области, которые имеют особое значение для мобильных приложений.
Имейте в виду, что функциональное тестирование должно включать в себя тестирование всех функций приложения и не должно быть излишне сосредоточено на какой-то одной функции.
В рамках функционального тестирования, вам следует выполнить следующие тесты:
• Тестирование процесса установки;
• Тестирование возможности обновлений;
• Эксплуатационное тестирование;
• Тестирование процесса регистрации и авторизации;
• Тестирование функций, специфических для устройства;
• Тестирование отправки и получения сообщений об ошибках;
• Низкоуровневое тестирование ресурсов: использование памяти, автоматическое освобождение ресурсов и т.д.
• Тестирование сервисов: функционирование как в режиме онлайн, так и в автономном режиме.
Этап 7: Аттестационное тестирование и тестирование безопасности приложения
Безопасность и конфиденциальность данных имеют огромное значение в наше время. Пользователи требуют, чтобы вся их информация хранилась безопасно и конфиденциально.
Убедитесь, что тестируемое приложение надежно защищено. Выполните проверку на возможность внедрения SQL инъекций, на возможность перехвата сеансов, анализа дампов данных, анализа пакетов и SSL трафика.
Очень важно проверить безопасность хранилища конфиденциальных данных вашего мобильного приложения и его поведение в соответствии с различными схемами разрешений для устройств.
Помимо проверки безусловного шифрования имен пользователей и паролей, задайте себе следующие вопросы:
• Есть ли у приложения сертификаты безопасности?
• Использует ли приложение безопасные сетевые протоколы?
• Существуют ли какие-либо ограничения, например количество попыток входа в систему до блокировки пользователей?
Этап 8: Тестирование устройства
Выполните тесты по тем алгоритмам, которые вы ранее прописали в тестовых случаях и сценариях тестирования на всех определенных для тестирования устройствах, в облаке и / или на физических устройствах.
Этап 9: контрольный этап и резюме
Этот этап включает в себя подробное и полное тестирование — от ранних итеративных этапов тестирования до регрессионных тестов, которые все еще могут потребоваться для стабилизации работы приложения и выявления незначительных дефектов.
На этом этапе тестирования вы можете добавить для проверки новые функции и изменить настройки на те, которых не будет в финальной версии.
После завершения тестирования приложения, дополнительные параметры и функции, добавленные для проверки на этом этапе, удаляются, и окончательная версия становится готовой для представления общественности.
Итоговый отчет о тестировании
Весь процесс тестирования мобильных приложений должен быть тщательно задокументирован. Проверьте дважды, сделаны ли нужные записи, и после этого сформируйте свой окончательный отчет о тестировании (test summary report).
Этот отчет должен включать:
• Важную информацию, выявленную в результате проведенных испытаний;
• Информацию о качестве проводимого тестирования;
• Сводную информацию о качестве тестируемого мобильного приложения;
• Статистику, полученную из отчетов об различных инцидентах;
• Информацию о видах тестирования и времени, затраченном на каждый из них.
Следует также указать в отчете, что:
• данное мобильное приложение пригодно для использования в том качестве, в котором заявлено;
• соответствует всем критериям приемлемости функционала и качества работы.
Бесплатные вебинары по схожей тематике:
QA практикум. Техники тест дизайна. 1
Автоматизация тестирования. Причины, цели, инструменты
Средства автоматизации тестирования REST API.
Вооружившись сводкой, руководство проекта теперь может решить, готово ли мобильное приложение к выпуску на рынок.
Тестирование мобильных приложений — сложная задача. Приспосабливая эти этапы тестирования к каждому разрабатываемому приложению и тщательно выполняя каждый шаг — вы гарантированно получите полнофункциональный качественный продукт.
В данной статье мы рассмотрели особенности тестирования мобильных приложений. Рассмотренные этапы тестирования важны и для тестирования андроид приложений и как ответ на вопрос как тестировать приложения для iphone.
Важно помнить, что тестирование приложений перед представлением на рынке – важный этап в разработке любых приложений. И, конечно же, тестирование мобильных приложений имеет свои особенности и важные моменты.
Ответственно подходите к вопросу разработки и тестирования мобильных приложений, своевременно изучая и применяя актуальные методики и технологии. С нашей стороны мы рекомендуем для изучения курс на ITVDN — Unit тестирование для Android разработчиков.
Также Вам могут быть интересны:
- Видео курсы по специальности Quality Assurance
- Видео курсы по специальности Android Developer
- Видео курсы по специальности iOS Developer
Источник: itvdn.com