Файл: Этапы разработки тестирования и ввода в эксплуатацию мобильных приложений (Основные этапы формирования мобильного приложения).pdf

Нативное приложение может максимально использовать аппаратные и функциональные возможности смартфона или планшета, благодаря чему им очень удобно пользоваться. Но вместе с тем можно использовать оригинальные компоненты и шаблоны.

Плюсы нативных приложений:

• наиболее производительны;
• получают полную поддержку от сторов;
• интуитивно понятны, работают более плавно, привычны для пользователя и дарят больше эмоций;
• пользовательский интерфейс более удобный, чем у кроссплатформенных приложений;
• позволяют разработчикам получить доступ к полному набору функций операционной системы.

Минусы нативных приложений:

• требуют больших затрат на старте и при дальнейшей поддержке, чем кроссплатформенные приложения;
• не лучший вариант для простых приложений.

При создании кроссплатформенной разработки используются общие наборы средств разработки (SDK). Из-за этого кроссплатформенные сервисы не используют все нативные преимущества каждой платформы. Зато сделать такое приложение дешевле — это оптимальный вариант для проектов с ограниченным бюджетом.

Если нужно быстро проверить гипотезу или протестировать новый продукт, делайте кроссплатформенное приложение

Плюсы кроссплатформенных приложений:

• разработка и поддержка дешевле, чем у нативных приложений;
• использование одного и того же кода для создания сервисов для разных платформ. Ну

Минусы кроссплатформенных приложений:

• низкие производительность и отзывчивость;
• для качественного продукта нужны высококвалифицированные разработчики — их мало и они дорого стоят;
• требуют у разработчиков больше сил и времени, чтобы адаптировать сервис под разные платформы и устройства;
• обновления операционных систем и новые функции можно использовать не так быстро, как в случае с нативными приложениями.

Исходя из своих бизнес-потребностей можно ответить на следующие вопросы:

• Насколько быстрое и отзывчивое приложение вам нужно?
• Насколько важны бизнес-процессы, которые встроены в приложение?
• Насколько сложные функции будет выполнять ваше приложение?

Главное отличие между нативным и кроссплатформенным приложением — в скорости и отзывчивости работы. Это как сравнить болид формулы-1 и городской кроссовер. Оба этих автомобиля едут по дороге, разгоняются, маневрируют и входят в повороты. Но разница чувствуется сразу.

После того, как вы определились, какое приложение будете делать — нативное или кроссплатформенное — надо разобраться с серверной частью. Это будет бекэндом в разработке.

---

Любое приложение отображает данные: показывает, какие товары есть в наличии в интернет-магазине, сколько запасов лежит на складе и кто из контрагентов должен вам денег. Все эти данные хранятся на сервере. Чтобы создать сервер, который эффективно обменивается данными с внешним интерфейсом приложения, надо его тщательно продумать.

ТЕСТИРОВАНИЕ

Очевидно, что для понимания, анализа, разработки и управления системами создания приложений нужны количественные методы и модели, которые помогают оценить различные сценарии функционирования, исследовать структуру и состояние больших систем. Наблюдаются тенденции к постоянному росту спроса на Веб-службы. Таким образом, проблемы, связанные с недостаточной производительностью будут возникать и в будущем, и, в конце концов, они станут превалирующими при планировании и вводе в эксплуатацию новых приложений и увеличении пользователей Интернета. Мобильный софт становятся все более распространенными и все более сложными, играя, таким образом, основную роль в большинстве онлайновых проектов. Как и во всех системах, основанных на взаимодействии между клиентом и сервером, обычно возникают ошибки из-за некорректной обработки запросов клиента и/или недостаточной проверки входной информации со стороны разработчика.

Одновременно с началом этапа планирования и создания спецификаций требования разрабатывается стратегия тестирования. После утверждения спецификаций требований разрабатывается и детализируется план тестирования, создаются наборы тестов для проведения интеграционного и системного тестирования. Тестирование завершается созданием отчета о тестировании, в котором представляются все результаты его проведения. Отчет должен содержать следующие разделы:

1. Объект испытаний;
2. Цель испытаний;
3. Состав предъявляемой документации;
4. Технические требования;
5. Порядок проведения испытаний;
6. Методы испытаний.

В первых трех разделах указывают: наименование, область применения, обозначение испытуемой программной системы; цель проведения испытаний; перечень документации, предъявляемой перед проведением испытаний. Раздел «Технические требования» может состоять из двух подразделов: 1) требования к программной документации; 2) требования к техническим характеристикам. В первом подразделе должны быть указаны требования к комплектности, содержанию и качеству предъявляемой документации; второй подраздел содержит описание требований к характеристикам программы применительно к условиям эксплуатации и требований к информационной и программной совместимости. «Порядок проведения испытаний» предполагает указания: на последовательность испытаний, четкий порядок проведения каждого испытательного эксперимента, состав и структуру технических средств, с помощью которых будут проводиться испытания, перечень дополнительных программных и технических средств, необходимых для проведения испытаний. В разделе «Методы испытаний» приводятся описания используемых методов проведения испытаний. Методы следует приводить в последовательности, соответствующей последовательности перечисления технических характеристик в разделе «Технические требования». При этом должны быть приведены описания проверок с указанием результатов проведения испытаний, к которым могут относиться: перечень тестовых примеров, контрольных распечаток самих примеров и их результатов, таблиц, графиков и т.п. Сами тестовые примеры (распечатки, таблицы, графики и т.п.) даются в приложении. Заключение Содержит анализ выполненной работы, выводы о значимости проекта, рекомендации по использованию проекта, рекомендации, касающиеся возможности дальнейшей доработки или модернизации проекта и т.д. Практическим результатом работы над курсовым проектом является работоспособная программа и пакет документации, включающий в себя программные документы «Пояснительная записка» и «Руководство пользователя». Кроме того, на магнитном носителе должен быть представлен текст программы (исходный код) с необходимыми комментариями. Для защиты курсового проекта создается презентация из 10— 12 слайдов, в которой отражаются требования к программной системе, основные этапы ее разработки, диаграммы, модели данных, выводы по работе.

---

Модульное тестирование представляет собой процесс проверки отдельных программных процедур и подпрограмм, входящих в состав программ или подпрограммных систем. Модульное тестирование производится непосредственным разработчиком и позволяет проверять все внутренние структуры и потоки данных в каждом модуле. Этот вид тестирования является частью этапа разработки. При модульном тестировании выполняется набор тестов, определяемый разработчиком так, чтобы охват тестированием каждого модуля был не менее 70...75%.

Элементы модульного тестирования:

синтаксическая проверка — проверка с использованием некоторого инструментального средства для выявления синтаксических ошибок в программном коде;

проверка соответствия стандартам кодирования — проверка кода на соответствие стандартам кодирования компании;

технический обзор программного кода.

После успешного завершения модульного тестирования все измененные модули и наборы тестов сохраняются в базе данных проекта. Интеграционное тестирование проводится для проверки совместной работы отдельных модулей и предшествует тестированию всей системы как единого целого. В ходе интеграционного тестирования проверяются связи между модулями, их совместимость и функциональность. Оно осуществляется независимым тестировщиком и входит в состав этапа тестирования.

Элементы интеграционного тестирования:

проверка функциональности — проверка соответствия отдельных функций, выполняемых совокупностями модулей, функциям, заданным в спецификациях требований;

проверка промежуточных результатов — проверка всех промежуточных результатов и файлов на наличие и корректность;

проверка интеграции — проверка корректности взаимной передачи модулями информации.

Ошибки, выявленные в ходе интеграционного тестирования, заносятся в базу данных ошибок. Результаты интеграционного тестирования включаются в отчет о ходе тестирования при завершении цикла тестирования. Системное тестирование предназначено для проверки программной системы в целом, ее организации и функционирования на соответствие спецификациям требований заказчика. Его проводит независимый тестировщик после успешного завершения интеграционного тестирования. Элементы системного тестирования:

• граничное тестирование — тестирование в граничных условиях;
• прогоночное тестирование — тестирование всех функциональных характеристик реальной работы системы;
• целевое тестирование — тестирование на целевой платформе (по возможности);
• проверка документации — проверка пользовательской документации на корректность;
• другие тесты, определяемые тестировщиком. Ошибки, выявленные при системном тестировании, заносятся в базу данных проекта. Результаты системного тестирования включаются в отчет о ходе тестирования. Выходное тестирование — завершающий этап тестирования, на котором проверяется готовность ПП для поставки заказчику. Данный вид тестирования проводит независимый тестировщик.

---

Элементы выходного тестирования:

• проверка инсталляции — проверка на ясность и корректность инструкций по инсталляции;
• проверка документации — проверка того, что вся необходимая документация полностью подготовлена и готова к передаче заказчику.

Ошибки, выявленные при выходном тестировании, заносятся в базу данных проекта. При успешном завершении выходного тестирования ПП поставляется заказчику вместе с отчетом о результатах тестирования. Приемочное тестирование проводится организацией, отвечающей за инсталляцию, сопровождение программной системы и обучение конечного пользователя.

В ходе тестирования, ошибки возникающие в приложении разделяются на разные виды:

• Синтаксические – выявляемые статистическим контролем и диагностикой компиляторами и компоновщиком
• Ошибки выполнения, выявляемые автоматически: переполнение, защита памяти несоответствие типов зацикливание обнаруживаемые динамическим контролем: аппаратурой процессора run-time системы программирования операционной системой — по превышению лимита времени
• Программа не соответствует спецификации – выявляется целенаправленным тестированием
• Спецификация не соответствует требованиям - идентифицируется

испытаниями, бета-тестированием.

Иногда тестировщик предугадывает, на основе опыта, что определенный класс тестов вызовет сбой программы, хотя и не может это логически обосновать. Доверяя своей интуиции и обязательно включая подобные тесты в общий план, открывается целый ряд ситуаций и значений, которые, хотя и не являются граничными, но часто вызывают программные сбои. Типичным примером таких значений является 0. Не стоит тратить время на поиски обоснований того, почему определенное входное значение или место программы кажется вам подозрительным, просто протестируйте его.

Случается, что в сложных ситуациях интуиция подсказывает гораздо лучшую тактику тестирования, чем тривиальная логика. Бывает, что срабатывает и ассоциативная связь: мы уже находили ошибку в подобных обстоятельствах, хотя можем этого даже не помнить. Как бы там ни было, доверяя своему внутреннему чувству, мы учимся становиться все более развитым и надежным. Тестирование функциональной эквивалентности.

При тестировании функциональной эквивалентности сравниваются результаты вычислений разными программами одной и той же математической функции. Термин «функциональная эквивалентность» не имеет ничего общего с термином «классы эквивалентности». Если обе программы при вычислении одной и той же функции дают одинаковые результаты, значит, в них применены эквивалентные методы вычислений. Предположим, что тестируется программа, которая вычисляет математическую функцию и печатает результат. Это может быть простая тригонометрическая функция или гораздо более сложная функция, инвертирующая матрицу или возвращающая коэффициенты для построения кривой, отражающей некоторый набор данных. Обычно в таких случаях можно найти другую программу, выполняющую те же действия, и при этом достаточно надежную и проверенную временем. Обеим программам предлагается обработать одинаковые наборы входных данных. Если результаты совпадут, значит, тестируемая программа работает правильно

---

Технология тестирования, которая применяется на этапе разработки программного обеспечения, называется тестированием «стеклянного ящика» (glass box). Иногда эту технологию еще называют тестированием «белого ящика» (white box) в противоположность классическому понятию «черного ящика» (black box). При тестировании «черного ящика» программа рассматривается как объект, внутренняя структура которого неизвестна. Тестировщик вводит данные и анализирует результат, но он не знает, как именно работает программа. Подбирая тесты, специалист ищет интересные, с его точки зрения, входные данные и условия, способные привести к нестандартным результатам. Интересны для него прежде всего те представители каждого класса входных данных, при которых с наибольшей вероятностью могут проявиться ошибки тестируемой программы. При тестировании «стеклянного ящика» ситуация совершенно иная. Тестировщик (в данном случае сам программист) разрабатывает тесты, основываясь на знании исходного кода, к которому он имеет полный доступ. В результате он получает следующие преимущества.

1. Направленность тестирования. Программист может тестировать программу по частям, разрабатывать специальные тестовые подпрограммы, которые вызывают тестируемый модуль и передают ему интересующие программиста данные. Отдельный модуль гораздо легче протестировать именно как «стеклянный ящик».

2. Полный охват кода. Программист всегда может определить, какие именно фрагменты кода работают в каждом тесте. Он видит, какие еще ветви кода остались непротестированными, и может подобрать условия, в которых они будут протестированы. Ниже описано, как отслеживать степень охвата программного кода проведенными тестами.

3. Возможность управления потоком команд. Программист всегда знает, какая функция должна выполняться в программе следующей и каким должно быть ее текущее состояние. Чтобы выяснить, работает ли программа так, как он думает, программист может включить в нее отладочные команды, отображающие информацию о ходе ее выполнения, или воспользоваться для этого специальным программным средством, называемым отладчиком. Отладчик может отслеживать и менять последовательность выполнения команд программы, показывать содержимое ее переменных и их адреса в памяти, а также выполнять другие важные функции.

4. Возможность отслеживания целостности данных. Программисту известно, какая часть программы должна изменять каждый элемент данных. Отслеживая состояние данных (с помощью того же отладчика), он может выявить такие ошибки, как изменение данных не теми модулями, их неверная интерпретация или неудачная организация. Программист может и самостоятельно автоматизировать тестирование.

---