Как протестировать приложение dumb
Вы, как создатель своего продукта или услуги, понимаете как он работает, какие связи между процессами и чего хотят клиенты. Поэтому при тестировании хорошо определяете ошибки и недочеты.
Конечно, ваши возможности ограничены — как знаниями и навыками, так и техническим оснащением. Вы не сможете проверить работу приложения на разных устройствах или его безопасность, наличие ошибки в коде. Но вам подвластно проверить, как работает функционал и какие упущения во внешнем виде, удобство приложения.
Сценарии тестирования
Ваша задача — встать на место пользователя и пройти его путь от входа в приложение до закрытия, при этом выполнить все действия, которые ему доступны. В ходе прохождения выявить проблемы, с которыми пользователь не должен сталкиваться, или найти изъяны в дизайне, которые водят его в заблуждение. В профессиональной среде такие сценарии называются «функциональное тестирование» и «тестирование удобства пользования». Для каждого мы написали принципы и основные моменты, на которые нужно обратить внимание.
Функциональное тестирование
Обязательно нужно тестировать приложение на пограничных состояниях.Мы разработали веб-приложение для сервиса грузоперевозок Shustrikoff. Стоимость доставки зависит от удаленности от центра города, поэтому при тестировании проверяли адреса на границе Казани и другого района. Также можно проверить заявки в разных районах города, заказ назначенный на границе дневного и ночного тарифа и т.п.
Тестирование удобства пользования
- Как обозначены обязательные и необязательные поля для заполнения? Можно ли их отличить друг от друга?
- Понятно ли, как действовать дальше и куда нажимать? Если вы всматриваетесь в экран в поисках следующего шага или кнопки, зафиксируйте этот момент. Интерфейс должен быть интуитивно понятен, вести пользователя по конкретному маршруту в назначенную точку. Важную роль в этом играют как расположение элементов на экране, так и их стиль.
- Можно ли продолжить работу в приложении после того как свернул и обратно развернул его? Не выкидывает ли пользователя?
- Цвет кнопок с одинаковой функцией совпадает.
- Как воспринимается текст на экране: заголовок заметнее всех, шрифт не напрягает, текст читается легко, смысл понятен, поля учтены.
- Звук в приложении: что с ним происходит и как он звучит в разных состояниях приложения. Например, как работает приложение, когда подключена гарнитура или включается сторонний проигрыватель либо при сворачивании приложения.
- Сколько времени и шагов понадобилось для завершения основных задач приложения? Можно ли упростить этот путь?
Оформляем и передаем информацию разработчикам
Включаем режим «бюрократии», потому что правильно оформленная ошибка сэкономит вам и разработчикам часы работы.
Представьте: разработчики не будут уточнять детали каждой ошибки, переспрашивать, для разъяснений не понадобятся эти звонки по телефону, которые мало кто любит (Привет миллениалам!). В ваших отношениях с командой будет процветать гармония и полное взаимопонимание.
- Дайте название ошибке. Будет легче ориентироваться по списку и в разговоре с командой.
- Опишите ошибку. Что конкретно не так? Как задумывалось и должно быть?
- Приложите скриншот или запись экрана, если ошибка происходит при конкретной последовательности действий.
- Какая версия: десктоп или мобильная?
- Какая платформа: iOS или Android?
- Какой браузер и какая версия браузера?
- Дайте подробный путь к странице/экрану с ошибкой.
Скорее всего команда уже использует определенный сервис для работы с задачами, где и собирает всю информацию по приложению. Поэтому они могут дать внешний доступ, чтобы вы в этом же пространстве вносили информацию по результатам своего тестирования. Собирайте все в единой структуре в одном месте.
Тема: Изучение процесса тестирования ПО. Создание тестовых сценариев и тестирование на основании документации.
Цель: Получить практические навыки анализа требований, проектирования тестовых сценариев и тестирования реального приложения.
3. Написать и внести в шаблон набор тестовых сценариев (вкладка «Тестовые сценарии»), обеспечивающий тестирование всех требований из вашего списка. Заполнив вкладку шаблона «Требования<->Тестовые сценарии», доказать, что все требования покрыты тестовыми сценариями.
4. Провести тестирование по созданным тестовым сценариям и занести результаты в шаблон во вкладку «Результаты тестирования».
5. Занести дефект (вкладка «Дефекты») на каждый непройденный шаг тестового сценария в ходе тестирования. Таким образом каждому шагу со статусом «Не пройден» вкладки «Результаты тестирования» должно соответствовать не менее одного дефекта.
Внимание: Правильное тестирование правильных тестовых сценариев обязательно приведет к обнаружению нескольких дефектов в программе Text Filter для каждого варианта.
1. Раздел «Меню File»
2. Раздел «Меню Edit»
3. Раздел «Работа со списком строк»
4. Раздел «Работа с группами фильтров», только первый тип фильтров («с головы»)
5. Раздел «Работа с группами фильтров», только второй тип фильтров («внутри»)
6. Раздел «Работа с группами фильтров», только третий тип фильтров («на хвосте»)
7. Ваша задача особенная: описать требования для проверки соответствия интерфейса программы общепризнанным стандартам: название элементов управления, их взаимное расположение, функционал и т.д. Например: кнопка «Х» должна корретно и немедленно закрывать окно, пункт меню «Вставить» обычно идет после пункта меню «Вырезать». Обратите внимание, что введенные в поля данные могут отражаться на поведении стандартных элементов интерфейса.
8. Ваша задача тоже особенная: описать требования для smoke (он же sanity, он же build acceptance) теста. Этот тест должен включать в себя основной набор функциональности без погружения в детали и должен давать ответ на вопрос можно ли начинать полномасштабное тестирование данной версии программного продукта или нет.
Примерные вопросы для подготовки защите:
1. См. лабораторные работы №1 и 2
2. Что представляет себя отчет о результатах тестирования?
3. Что такое дефект ПО?
4. Что такое серьезность (важность, severity) дефекта? Какие вы знаете severity? Чем они отличаются?
5. Каков жизненный цикл дефекта?
6. Назовите возможные статусы дефекта. Чем они отличаются?
7. Что такое система багтрекинга? Приведите названия программ.
Содержание отчета:
1. Титульный лист с названием курса, номером и темой лабораторной работы, номером группы и Ф.И.О. авторов.
2. Цель и задание работы.
3. Заполненный шаблон в читаемом виде.
4. Выводы: достигли ли цели работы, что сделали, чему научились и т.д.
Органиционные вопросы:
1. Эту работу можно будет сдавать и на зачетной неделе тоже
3. В группе 5512 варианты для 5-ой работы у некоторых студентов отличаются от 2-ой работы: в колонке «Вар.» в журнале на сайте это показано в виде a->b, где a - вариант ко 2-ой работе, b - к 5-ой.
У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда они приходят в компанию, где нет документации на проекте, либо это только что появившийся стартап. Чтобы ответить на эти вопросы была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого приложения.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Чек-лист для тестирования мобильных приложений состоит из восьми разделов:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
Тестирование совместимости
Тестирование совместимости используется, чтобы убедиться, что ваше приложение совместимо с другими версиями ОС, различными оболочками и сторонними сервисами, а также аппаратным обеспечением устройства.
Что проверяем?
1. Корректное отображение гео
2. Информации об операциях (чеки и т.д.)
3. Различные способы оплаты (Google Pay, Apple Pay)
4. Тестирование датчиков (освещенности, температуры устройства, гироскоп и т.д.)
5. Тестирование прерываний (входящий звонок/смс/push/будильник/режим «Не беспокоить» и т.д.)
6. Подключение внешних устройств (карта памяти/наушники и т.д.)
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности приложения.
Что проверяем?
1. Тестирование разрешений (доступ к камере/микрофону/галерее/и т.д.)
2. Данные пользователя (пароли) не передаются в открытом виде
3. В полях, с вводом пароля и подтверждением пароля, данные скрываются астерисками
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют, а также замену фактических строк псевдостроками. Тестирование локализации включает тестирование приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Что проверяем?
1. Все элементы в приложении переведены на соответствующий язык
2. Тексты зашиты внутри приложения и пользователь в настройках приложения может выставить необходимый язык
3. Тексты зависят от языка в системных настройках
4. Тексты приходят с сервера
5. Корректное отображение форматов дат (ГОД — МЕСЯЦ — ДЕНЬ или ДЕНЬ — МЕСЯЦ — ГОД.)
6. Корректное отображение времени в зависимости от часового пояса
Тестирование удобства использования
Тестирование удобства использования помогает удостовериться в простоте и эффективности использования продукта пользователем, с целью достижения поставленных целей. Иными словами, это не что иное, как тестирование дружелюбности приложения для пользователя.
Что проверяем?
Стрессовое тестирование
Стрессовое тестирование направлено на определение эффективности производительности приложения в условиях повышенной нагрузки. Стресс-тест в этом контексте ориентирован только на мобильные устройства.
Что проверяем?
1. Высокая загрузка центрального процессора
2. Нехватка памяти
3. Загрузка батареи
4. Отказы
5. Низкая пропускная способность сети
6. Большое количество взаимодействий пользователя с приложением (для этого может понадобиться имитация реальных условий состояния сети)
Кросс-платформенное тестирование
Важный вид тестирования, который необходимо проводить для понимания того, будет ли должным образом отображаться тестируемый продукт на различных платформах, используемых целевой аудиторией.
Что проверяем?
— Работоспособность приложения на различных устройствах разных производителей
Тестирование производительности
Если пользователь устанавливает приложение, и оно не отображается достаточно быстро (например, в течение трех секунд), оно может быть удалено в пользу другого приложения. Аспекты потребления времени и ресурсов являются важными факторами успеха для приложения, и для измерения этих аспектов проводится тестирование производительности.
Что проверяем?
1. Время загрузки приложения
2. Обработка запросов
3. Кэширование данных
4. Потребление ресурсов приложением (например расход заряда батареи)
Помогите протестировать примитивную программу или расскажите как это сделать. Проблема в том, что нужно пройти тест на стажёра по тестированию, я много прочитал различной информации по этому поводу, но не могу найти не одного примера как это оформляеться или как на практике пошагово это делаеться, или есть програмка которой можно решить эту приметивную задачку то скиньте ссылку? Спасибо.
Прикрепленные файлы
Я бы посоветовала разбить программу на функциональности и поочередно к каждй из них писать набор тестов.
Так как вы претендуете на позицию "стажер", то думаю стилья кейсов можно не придерживаться, а пишите в свободной форме.
Можно писать просто какие бы проверки вы сделали.
Например
1) Создание нового файла
2) Открытие файла с диска
2) Сохранение файла на диск
2) Копирование в буфер
3) Вставка из буфера
ну и подобное далее
Каждый из пунктов оснастить тестовыми сценариями в такой же форме
Еще можно в таком виде тест-кейсов оформить:
Название теста:
Открытие информации о программе
Действие:
Из главного меню "Help" выбрать подменю "About"
Результат:
После выбора пункта "About"откроется окно с информацией о имени продукта и версии.
ну и так далее. Только побольше тестовых сценариев добавить.
Все тут написано "на коленке". Но этот шаблон вполне можно использовать.
А что вас смущает? Вы же читали массу литературы - должны хоть примерно знать что Вам делать.
После установки это програмулинки сразу бросается в глаза ее проблемы, кроме того тыцканьем на 1 кнопачку получаются грубейшие баги (а втвче скрин).
Задавайте вопросы конкретнее. Что Вам нужно: чтобы за Вас потестировали или рассказали ка оформлять найденные баги? или еще что?:)
Оформляйте как можете : войти туда-то, тыцнуть то-то, получил в результате багу :). Главная идея: другой человек должен воспроизвести по Вашему сочинению баг :)
Прикрепленные файлы
Необходимо протестировать программу и составить отчёт об ишибках, так написанно в заданииНа скока я поняла, тесткейсы тут не нужны. Необходимо всего-то - протестировать программу. Зачем человеку жисть усложнять :).
А что вас смущает? Вы же читали массу литературы - должны хоть примерно знать что Вам делать.
После установки это програмулинки сразу бросается в глаза ее проблемы, кроме того тыцканьем на 1 кнопачку получаются грубейшие баги (а втвче скрин).
Задавайте вопросы конкретнее. Что Вам нужно: чтобы за Вас потестировали или рассказали ка оформлять найденные баги? или еще что?:)
Оформляйте как можете : войти туда-то, тыцнуть то-то, получил в результате багу :). Главная идея: другой человек должен воспроизвести по Вашему сочинению баг :)
На скока я поняла, тесткейсы тут не нужны. Необходимо всего-то - протестировать программу. Зачем человеку жисть усложнять :).
А что вас смущает? Вы же читали массу литературы - должны хоть примерно знать что Вам делать.
После установки это програмулинки сразу бросается в глаза ее проблемы, кроме того тыцканьем на 1 кнопачку получаются грубейшие баги (а втвче скрин).
Задавайте вопросы конкретнее. Что Вам нужно: чтобы за Вас потестировали или рассказали ка оформлять найденные баги? или еще что?:)
Оформляйте как можете : войти туда-то, тыцнуть то-то, получил в результате багу :). Главная идея: другой человек должен воспроизвести по Вашему сочинению баг :)
Как получился этот баг, у меня 1 раз вышел, 2-ой раз не получаеться, кроме него 3 шт нашёл
Некоторые баги зависят напрямую от порядка предыдущих действий и введенных значений.
Как только обнаружили ошибку, отматываешь в памяти назад все свои действия, добиваешься минимального набора действий для падения/ошибки с момента запуска приложения (но тратить на это полдня не стоит) и записываем последовательности этих действий: на что нажимать, что и куда вводить. ну или более кратко, но чтобы было понятно сразу в чем проблема.
"Как получился этот баг" - ежели хочешь успешно пройти стажировку и расти дальше, то ищи сам. :)
Я бы посоветовала разбить программу на функциональности и поочередно к каждй из них писать набор тестов.
Так как вы претендуете на позицию "стажер", то думаю стилья кейсов можно не придерживаться, а пишите в свободной форме.
Можно писать просто какие бы проверки вы сделали.
Например
1) Создание нового файла
2) Открытие файла с диска
2) Сохранение файла на диск
2) Копирование в буфер
3) Вставка из буфера
ну и подобное далее
Каждый из пунктов оснастить тестовыми сценариями в такой же форме
Еще можно в таком виде тест-кейсов оформить:
Название теста:
Открытие информации о программе
Действие:
Из главного меню "Help" выбрать подменю "About"
Результат:
После выбора пункта "About"откроется окно с информацией о имени продукта и версии.
ну и так далее. Только побольше тестовых сценариев добавить.
Все тут написано "на коленке". Но этот шаблон вполне можно использовать.
Во-первых, если вы будете узнавать об ошибках и несовершенствах приложения из негативных отзывов о вашей разработке, это вряд ли положительно скажется на количестве установок.
Во-вторых, выявление ошибки пользователем не раскроет тайны ее происхождения. Вам придется долго мучиться в попытках найти истоки того бага, который гневит первых испытателей проекта.
Чуть ранее мы рассмотрели вопросы проектирования интерфейса, нейминга и создания иконки приложения, и завершаем цикл публикаций на тему базовых знаний вокруг разработки тестированием.
Тестирование - процесс не самый простой и быстрый, требующий определенного инструментария и навыков работы с ним, а также специфичных знаний. Тем не менее, в условиях любительской разработки и быстрого запуска можно самостоятельно проделать минимальный набор действий, позволяющий выявить весомое количество ошибок и недоработок.
Рассмотрим способы быстрых тестов мобильного приложения. Что тестируем?
Интерфейс
Обратите внимание на:
- визуальное соответствие макетам;
- правильное функционирование элементов интерфейса (всплывающее должно всплывать, листающееся - листаться, подсвечивающееся - подсвечиваться); правильное отображение активных и неактивных кнопок;
- возможности отменить действие или вернуться назад; прочие каноны;
- удобство использования интерфейса.
Сервисы в помощь:
Совершает клики, жесты, касания и т.д.:
Monkey
Проверяет адаптивность:
Mattkersley
Protofluid
Качество работы приложения
Необходимо пройти все пути, доступные в приложении, чтобы проверить его работу на наличие непредвиденных сбоев и проработанность сценариев.
Так же важно:
- формы ввода данных и работа клавиатуры;
- корректная загрузка элементов, отображение изображений, скроллинг;
- работа с интегрированными социальными сетями и другими приложениями;
- функции поиска.
Работа с сетью
Работа на различных устройствах
- Можно ли найти в магазинах, установить приложение на различные устройства и удалить его?
- Корректно ли работают все кнопки в приложении и другие элементы интерфейса,
правильно ли оно сворачивается и разворачивается, переживает блокировку экрана и переход в спящий режим (выход из него)?
- Все ли хорошо с работой уведомлений, в том числе от других приложений?
- Корректна ли работа приложения при отключении звука на устройстве?
Все перечисленное выше должно работать на всех популярных платформах и устройствах.
По возможности рекомендуется делать захват видео с экрана - это позволит увидеть, что именно работает некорректно, и где проявляются неудобства пользования интерфейсом.
Способы тестирования
Не рассматриваем ручное тестирование :)
1. Эмуляторы
Программы, позволяющие использовать функции одного устройства на другом; в нашем случае - мобильного на ПК. Вы можете запустить эмулятор с нужной операционной системой и проверить работу своего приложения, какой бы она была на ряде интересующих устройств.
Самые популярные эмуляторы для проверки работы приложений:
Genymotion
Бесплатно для персонального использования. Имеются 20 готовых конфигураций для разных телефонов.
Bluestacks
Самый популярный десктопный эмулятор ОС Android
2. Удаленный доступ к реальным устройствам
Более показательными по сравнению с тестами на эмуляторах будут попытки запустить приложения на реальных устройствах, поскольку эмулятор может исказить результаты за счет своих, но не ваших ошибок. Есть отличные сервисы, которые предлагают эту услугу, например:
Testobject
Тестирование приложений на 120 устройствах по заданным сценариям прямо из браузера. Автоматический сбор ошибок.
Стоимость: $89 в месяц.
3. Скриптовые тесты
Взаимодействуют с вашим кодом и собирают данные об ошибках. Хорошая альтернатива написанию собственых тестировочных скриптов.
Robotium
Автоматизированное тестирование для Android
Telerik
Программа для тестирования приложений на iOS (да, можно пользоваться бесплатно 30 дней)
4. Нагрузочные тесты
Тесты на выносливость приложением больших объемов трафика. Будет ли ваш проект популярным, виднее вам, но проверить работоспособность приложения при высоких нагрузках лишним не будет.
HP VuGen
Для тестирования необходимо создать скрипт и запустить его на устройстве, после чего HP VuGen перехватит трафик и повторит запрос одновременно с нескольких тысяч или даже миллионов устройств.
5. Бета-тестирование
Ubertesters
Инструмент для проведения бета-тестов. Синхронизирован с внешними багтрекинг-системами. Бесплатно для 5 и менее пользователей.
6. Подключение к аналитическим инструментам
Appcelerator
Как вариант, можно создать приложение на этой облачной платформе, в функции которой входит и автоматическое тестирование.
square.github.io/spoon
Помогает оптимизировать получение результатов тестов.
Тем, кто хочет разрабатывать под мобильные устройства, рекомендуем профессию «Разработчик мобильных приложений».
Читайте также: