как протестировать приложение dumb
Изучение процесса тестирования ПО, Создание тестовых сценариев и тестирование на основании документации
Страницы работы
Содержание работы
Лабораторная работа №5.
Тема: Изучение процесса тестирования ПО. Создание тестовых сценариев и тестирование на основании документации.
Цель: Получить практические навыки анализа требований, проектирования тестовых сценариев и тестирования реального приложения.
1. Изучить весь функционал программы Text Filter (не только свой вариант), воспользовавшись help файлом dumb.chm.
2. На основании информации из dumb.chm, общепризнанных стандартов программ, ваших знаний и опыта: сформулировать список требований к программе Text Filter для вашего варианта задания. Присвоить требованиям идентификаторы (короткие, но смысловые) и внести их в приложенный шаблон (вкладка «Требования»).
3. Написать и внести в шаблон набор тестовых сценариев (вкладка «Тестовые сценарии»), обеспечивающий тестирование всех требований из вашего списка. Заполнив вкладку шаблона «Требования Тестовые сценарии», доказать, что все требования покрыты тестовыми сценариями.
4. Провести тестирование по созданным тестовым сценариям и занести результаты в шаблон во вкладку «Результаты тестирования».
5. Занести дефект (вкладка «Дефекты») на каждый непройденный шаг тестового сценария в ходе тестирования. Таким образом каждому шагу со статусом «Не пройден» вкладки «Результаты тестирования» должно соответствовать не менее одного дефекта.
Внимание: Правильное тестирование правильных тестовых сценариев обязательно приведет к обнаружению нескольких дефектов в программе Text Filter для каждого варианта.
Исходная информация для формулирования требований берется из help файла dumb.chm из указанного ниже раздела. Обратите внимание, что информация из указанных разделов неразрывно связана с основным описанием программы «Принцип работы программы 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. Эту работу можно будет сдавать и на зачетной неделе тоже
2. У тех у кого 9-ый вариант – делают 8-ой.
Помогите протестировать примитивную программу или расскажите как это с
Помогите протестировать примитивную программу или расскажите как это сделать. Проблема в том, что нужно пройти тест на стажёра по тестированию, я много прочитал различной информации по этому поводу, но не могу найти не одного примера как это оформляеться или как на практике пошагово это делаеться, или есть програмка которой можно решить эту приметивную задачку то скиньте ссылку? Спасибо.
Прикрепленные файлы
Я бы посоветовала разбить программу на функциональности и поочередно к каждй из них писать набор тестов.
Так как вы претендуете на позицию «стажер», то думаю стилья кейсов можно не придерживаться, а пишите в свободной форме.
Можно писать просто какие бы проверки вы сделали.
Например
1) Создание нового файла
2) Открытие файла с диска
2) Сохранение файла на диск
2) Копирование в буфер
3) Вставка из буфера
ну и подобное далее
Каждый из пунктов оснастить тестовыми сценариями в такой же форме
Еще можно в таком виде тест-кейсов оформить:
Название теста:
Открытие информации о программе
Действие:
Из главного меню «Help» выбрать подменю «About»
Результат:
После выбора пункта «About»откроется окно с информацией о имени продукта и версии.
ну и так далее. Только побольше тестовых сценариев добавить.
Все тут написано «на коленке». Но этот шаблон вполне можно использовать.
Прикрепленные файлы
Некоторые баги зависят напрямую от порядка предыдущих действий и введенных значений.
Как только обнаружили ошибку, отматываешь в памяти назад все свои действия, добиваешься минимального набора действий для падения/ошибки с момента запуска приложения (но тратить на это полдня не стоит) и записываем последовательности этих действий: на что нажимать, что и куда вводить. ну или более кратко, но чтобы было понятно сразу в чем проблема.
Я бы посоветовала разбить программу на функциональности и поочередно к каждй из них писать набор тестов.
Так как вы претендуете на позицию «стажер», то думаю стилья кейсов можно не придерживаться, а пишите в свободной форме.
Можно писать просто какие бы проверки вы сделали.
Например
1) Создание нового файла
2) Открытие файла с диска
2) Сохранение файла на диск
2) Копирование в буфер
3) Вставка из буфера
ну и подобное далее
Каждый из пунктов оснастить тестовыми сценариями в такой же форме
Еще можно в таком виде тест-кейсов оформить:
Название теста:
Открытие информации о программе
Действие:
Из главного меню «Help» выбрать подменю «About»
Результат:
После выбора пункта «About»откроется окно с информацией о имени продукта и версии.
ну и так далее. Только побольше тестовых сценариев добавить.
Все тут написано «на коленке». Но этот шаблон вполне можно использовать.
Я бы посоветовал прочесть dumb.chm(Help) это так сказать тех документация что и как должно быть.
По нему написать тест-кейсы и проверить как существующая функциональность соответствует требованиям описаным в Хелпе.
В программе так же есть отклонения от стандартов в пользовательском интерфейсе.
Нестандартный порядок пунктов меню, названия некоторых пунктов начинается с маленькой буквы.
В каком виде это можно оформить?
Если кто-то может, приведите, пожалуйста пример того, как должен выглядеть отчет.
В программе так же есть отклонения от стандартов в пользовательском интерфейсе.
Нестандартный порядок пунктов меню, названия некоторых пунктов начинается с маленькой буквы.
В каком виде это можно оформить?
Если кто-то может, приведите, пожалуйста пример того, как должен выглядеть отчет.
Тестируем Android-приложение правильно
Меня зовут Андрей Рыжкин, я CTO AGIMA.
Сегодня я расскажу о том, как мы тестируем приложения на Android, а также поделюсь нашим чек-листом.
Чек-лист от команды AGIMA
В 2020 году количество приложений для Android вплотную приблизилось к трём миллионам (по данным Appbrain на 28 марта). И это число продолжает расти – каждый день появляются сотни новых программ для этой операционной системы. В том числе благодаря AGIMA. Мы создаем самые разные приложения для Android – простые и сложные, узкоспециализированные и «для всех». И можем немало рассказать о нюансах их разработки.
Конечно, главное в Android-приложении – его функционал. Недочеты вёрстки редко бросаются в глаза, но качество любого продукта – в мелочах. Поэтому мы всегда тщательно тестируем приложения перед запуском. А для того, чтобы тестирование занимало минимум времени и приносило максимум пользы, мы разработали специальный чек-лист, которым рады поделиться с вами!
Но сначала перечислим шесть наиболее распространенных проблем вёрстки, избежать которых поможет наш чек-лист.
1. Сдвиг элемента страницы
При вёрстке страницы можно применить три вида выравнивания по вертикали (Align Top, Align Middle и Align Bottom) и три – по горизонтали (Align Left, Align Center, Align Right). Но если использовать их несогласованно, отдельные элементы страницы начинают «съезжать» со своих мест.
На рисунке слева всё хорошо, но стоит изменить разрешение – и заголовок сдвигается вправо.
2. Обрезка текста
Проблема появляется, когда компоненты GUI пытаются сжать, чтобы «втиснуть» в маленький экран.
Слева всё в порядке, справа часть текста обрезана из-за изменения ориентации устройства.
3. Отсутствие элемента страницы
При снижении разрешения экрана элементы увеличиваются в размере. И при неправильной вёрстке некоторые из них могут просто «исчезнуть».
4. Пересечение элементов
Иногда, также при снижении разрешения или уменьшении размера экрана, компоненты GUI «наезжают» друг на друга. В итоге на странице воцаряется полный хаос.
5. Выход элементов за границы экрана
Причина всё та же – при изменении разрешения элементы страницы увеличиваются, и экрана банально «не хватает» для их отображения. В итоге страница ужасно выглядит (и это в лучшем случае, в худшем ей становится просто невозможно пользоваться).
6. Артефакты адаптивного дизайна
При увеличении разрешения экрана может возникнуть «обратная» ситуация – компоненты GUI и текстовые символы могут уменьшиться до абсолютно нечитабельных размеров.
Согласно Material Design, размер любого элемента, с которым взаимодействует пользователь, будь то кнопка, чекбокс или радиобаттон, не должен составлять меньше 48 пикселей по любому измерению.
Гайдлайн не дает четких рекомендаций по размеру текста, однако по результатам исследования комфортным считается шрифт в 16 пикселей высотой, а приемлемым для чтения – 12-14 пикселей.
Перечисленные проблемы часто «наслаиваются» друг на друга – как известно, беда не приходит одна. И результаты таких сочетаний могут быть самыми непредсказуемыми. Но это – тема для отдельной статьи.
А теперь – обещанный чек-лист. Используйте его во время тестирования Android-приложения – и от вас не «ускользнет» ни одна ошибка!
Чек-лист
Запуск и выход из приложения:
Вёрстка (на всех заявленных в ограничениях устройствах и разрешениях):
И напоследок важный вопрос для всех читателей. Какие пункты вы добавили бы к нашему чек-листу? Будем рады вашим идеям!
Статья написана с ex-head QA AGIMA Рамилем Усмановым.
Чек-лист тестирования мобильных приложений
У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда они приходят в компанию, где нет документации на проекте, либо это только что появившийся стартап. Чтобы ответить на эти вопросы была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого приложения.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Чек-лист для тестирования мобильных приложений состоит из восьми разделов:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
1. Установка/удаление/накатка версий
2. Запуск приложения (отображение Splash Screen)
3. Работоспособность основного функционала приложения
3.1 Авторизация (по номеру телефона/через соц. сети/e-mail)
3.2 Регистрация (по номеру телефона/через соц. сети/e-mail)
3.3 Онбординг новых пользователей
3.4 Валидация обязательных полей
3.5 Навигация между разделами приложения
3.6 Редактирование данных в профиле пользователя
3.7 Проверка оплаты
3.8 Тестирование фильтров
3.9 Бонусы
4. Корректное отображение ошибок
5. Работа с файлами (отправка/получение/просмотр)
6. Тестирование тайм-аутов
7. Тестирование заглушек (не соединения с интернетом/нет, например, товаров и т.д)
8. Тестирование pop-up, алертов
9. Тестирование WebView
10. Скролл/свайп элементов
11. Тестирование PUSH уведомлений
12. Сворачивание/разворачивание приложения
13. Разные типы подключений (сотовая связь/Wi-Fi)
14. Ориентация экрана (альбомная/портретная)
15. Темная/светлая темы
16. Реклама в приложении
17. Шаринг контента в соц. сети
18. Работа приложения в фоне
19. Пагинация страниц
20. Политики конфиденциальности и прочие ссылки на документы
Тестирование совместимости
Тестирование совместимости используется, чтобы убедиться, что ваше приложение совместимо с другими версиями ОС, различными оболочками и сторонними сервисами, а также аппаратным обеспечением устройства.
Что проверяем?
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. В поисковых строках присутствуют плейсхолдеры
7. Неактивные элементы отображаются серым
8. Ссылки на документы ведут на соответствующий раздел на сайте
9. Анимация между переходами
10. Корректный возврат на предыдущий экран
11. Поддерживаются основные жесты при работе с сенсорными экранами (swipe back и т.д.)
12. Пиксель-перфект
Стрессовое тестирование
Стрессовое тестирование направлено на определение эффективности производительности приложения в условиях повышенной нагрузки. Стресс-тест в этом контексте ориентирован только на мобильные устройства.
Что проверяем?
1. Высокая загрузка центрального процессора
2. Нехватка памяти
3. Загрузка батареи
4. Отказы
5. Низкая пропускная способность сети
6. Большое количество взаимодействий пользователя с приложением (для этого может понадобиться имитация реальных условий состояния сети)
Кросс-платформенное тестирование
Важный вид тестирования, который необходимо проводить для понимания того, будет ли должным образом отображаться тестируемый продукт на различных платформах, используемых целевой аудиторией.
Что проверяем?
— Работоспособность приложения на различных устройствах разных производителей
Тестирование производительности
Если пользователь устанавливает приложение, и оно не отображается достаточно быстро (например, в течение трех секунд), оно может быть удалено в пользу другого приложения. Аспекты потребления времени и ресурсов являются важными факторами успеха для приложения, и для измерения этих аспектов проводится тестирование производительности.
Что проверяем?
1. Время загрузки приложения
2. Обработка запросов
3. Кэширование данных
4. Потребление ресурсов приложением (например расход заряда батареи)
FlaNium: как сделать тестирование Desktop-приложений под Windows проще
На рынке так много программных продуктов для тестирования, что может показаться, будто для всего найдется готовое решение и нет необходимости тратить время и усилия на разработку инструментов тестирования. На самом деле это не так. Мы в «ЛАНИТ Экспертизе» убедились в этом, когда появилась задача тестирования Desktop-приложений, и теперь делимся с вами опытом.
Источник: kotomatrix.ru
Когда есть доступ к исходному коду и тестирование с разработкой производятся параллельно, то никаких трудностей не возникает, но что делать, когда этого доступа нет и приходится тестировать уже готовый продукт?
В отличие от автоматизации WEB, API или мобильных приложений, тестирование Desktop в некоторой степени – «экзотика», и на это есть несколько причин:
Анализ готовых инструментов
Обзор предлагаемых решений показал, что Open source продуктов не так уж много. Сначала мы испытали Winium – Automation framework for Windows platforms.
Winium – это фреймворк для тестирования Desktop Windows приложений на базе Selenium. Он обладает всеми основными требованиями, которые были необходимы для работы с предстоящим проектом:
Следующим, что показалось нам интересным в плане возможностей, оказалась библиотека FlaUI. Библиотека была написана на C# и не имела какого-либо API для взаимодействия извне. По сути это некая оболочка над библиотеками автоматизации Microsoft Windows Automation API, которая упрощает написание тестов. В отличие от Winium данная библиотека обладает полным функционалом взаимодействия с WinForms и WPF-приложениями, но требует написания тестов на языке C#. Поскольку у нас уже был готовый фреймворк тестирования, реализованный на языке Java, данная библиотека не удовлетворяла наши потребности.
Дальнейший анализ инструментов тестирования показал, что наиболее оптимальный вариант – это реализация своего инструмента. Имеющиеся продукты обладали теми или иными серьезными недостатками, а комбинировать несколько решений не представлялось возможным. Так как абсолютно все Open source решения использовали взаимодействие со стандартной библиотекой Windows Automation API, то было принято решение взять за основу ядро FlaUI Core, построенное на основе взаимодействия с данной библиотекой, и обладающее полным функционалом взаимодействия с элементами тестируемого приложения. Затем добавить поддержку Selenium REST API, аналогично Winium. Так родился проект FlaNium.
Что представляет из себя FlaNium
На данный момент в состав проекта входят пока только два компонента.
FlaNium.Desktop.Driver – основной компонент, представляющий из себя драйвер взаимодействия с тестируемым приложением посредством Windows Automation API и использующий протокол взаимодействия Selenium REST API.
FlaNium.WinAPI – Java-библиотека, расширяющая протокол Selenium REST API и добавляющая дополнительные возможности по настройке и взаимодействию с FlaNium драйвером. Также данная библиотека позволяет типизировать стандартный Selenium WebElement и привести его к компонентам тестируемого приложения, добавляя дополнительные методы взаимодействия, характерные определенному типу элемента.
Рассмотрим пример работы с FlaNium драйвером на базе Selenium Java
Кто хоть немного сталкивался с тестированием, а особенно с тестированием Web-приложений знает, что такое Selenium WebDriver. Есть много информации про Selenium, поэтому в статье мы не будем рассматривать плюсы и минусы, а также особенности работы с Selenium, а рассмотрим лишь особенности работы с FlaNium драйвером.
Перед началом работы с FlaNium драйвером необходимо загрузить последнюю версию драйвера, а также прописать следующие зависимости в pom.xml:
Далее производим настройку и инициализацию драйвера:
После получения экземпляра FlaniumDriver можно осуществлять поиск контролов приложения и взаимодействовать с ними через стандартные методы библиотеки Selenium.
Есть возможность поиска элементов по XPath, Name, Id (AutomationId) и ClassName, а также поддерживаются пять параметров поиска с помощью XPath – AutomationId, Name, ClassName, HelpText, ControlType.
Для более комфортной работы лучше воспользоваться такими инструментами как FlaUInspect, UISpy и подобными, так как они значительно упрощают написание тестов приложения, позволяя визуально отобразить структуру и параметры элементов приложения. Данные инструменты также позволяют понять, как можно обратиться к различным элементам или какие паттерны поддерживает конкретный из них.
Благодаря расширению протокола Selenium есть возможность типизировать любой WebElement и получить дополнительные возможности для работы. Для этого необходимо создать экземпляр требуемого класса и передать WebElement в качестве параметра:
Рассмотрим на примере, для чего нужна типизация и что нам даёт расширение протокола Selenium. Возьмем для примера выбор значения из выпадающего списка:
На рисунке ниже изображено тестируемое приложение (слева) и инспектор (справа):
У нас есть элемент ComboBox, согласно инспектору, доступа к элементам списка у нас нет, чтобы его получить необходимо раскрыть список нажав на кнопку «Открыть».
После раскрытия списка мы получаем доступ ко всем вложенным элементам и можем осуществлять поиск и выбор необходимого элемента.
Вот так будет выглядеть код при использовании стандартных Selenium-методов:
А вот так будет выглядеть то же самое, но при использовании методов типизированных элементов библиотеки FlaNium.WinAPI:
Как мы видим, использование данных методов значительно упрощает взаимодействие и сокращает код. С полным списком поддерживаемых элементов и реализованных методов можно ознакомиться по ссылке.
Мы не изобретали ничего кардинально нового, но взяв в основу преимущества Winium и FlaUI, скомпоновали продукт с удобным универсальным интерфейсом и широкими возможностями взаимодействия с тестируемым приложением. Удалось объединить протокол Selenium REST и библиотеки Windows Automation API.
Давайте рассмотрим, чем же обязан FlaNium этим двум проектам:
На момент написания статьи драйвер уже внедрен в один из наших проектов и успешно работает. Вложив силы и время в разработку собственного драйвера, удалось значительно сократить время и потратить меньше усилий на создание фреймворка и его внедрение, а также сильно упростить написание тестов.
Поскольку драйвер использует универсальный протокол взаимодействия, стало возможным использовать уже имеющийся фреймворк тестирования с некоторыми изменениями. Была добавлена работа с элементами посредством библиотеки FlaNium.WinAPI и реализована логика работы с конкретным тестируемым приложением. Также удалось избежать сложностей при работе с элементами приложения, поскольку используется полноценная библиотека взаимодействия и не возникало ситуаций, когда нет доступа к какому-либо параметру элемента.
Кроме всего перечисленного, внедрение данного драйвера позволило отказаться от вендорского ПО для тестирования, сократив стоимость автоматизации и её поддержки на значительную сумму, а также унифицировать стек технологий и требования к квалификации автоматизаторов.
Мы не останавливаемся на достигнутом и продолжаем развивать данный проект. Помимо взаимодействия с приложениями посредством Windows API ведется разработка технологии взаимодействия с приложением «изнутри» посредством инжекта исполняемой библиотеки в код тестируемого приложения. Данная технология необходима, например, для полноценного тестирования Delphi приложений, чего нельзя добиться с помощью стандартного Windows API.