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

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

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

На клиентском уровне можно выделить:

Тип устройства: смартфон, планшет и т.д.

Конфигурация устройства: количество оперативной памяти, тип процессора, разрешение экрана, емкость аккумулятора и т.д.

Тип и версия операционной системы. iOS 6, 7; Android 4.2.2 и т.д.

Тип сети: Wi-Fi, GSM.

Перед проведением конфигурационного тестирования рекомендуется

Создавать матрицу покрытия (матрица покрытия — это таблица, в которую заносят все возможные конфигурации).

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

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

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

10.6. Тестирование на восстановление.

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

Проверка восстановления после сбоя системы и сбоя транзакций.

Проверка эффективного восстановления приложения после непредвиденных сценариев сбоя.

Проверка способности приложения обрабатывать транзакции в условиях сбоя питания (разряженная батарея / некорректное завершение работы приложения).

Проверка процесса восстановления данных после перерыва в соединении.

Другие важные области проверки:

Тестирование установки (быстрая, соответствующая требованиям установка приложения).

Тестирование удаления (быстрое, соответствующее требованиям удаление приложения).

Сетевые тест-кейсы (проверка адекватной работы сети в разных условиях загрузки, а также способности сети обеспечить функционирование всех приложений, используемых в ходе тестирования).

Проверка наличия нефункциональных клавиш.

Проверка экрана загрузки приложения.

Проверка возможности ввода с клавиатуры во время сбоев сети.

Проверка методов запуска приложения.

Проверка наличия эффекта зарядки в случае, если приложение находится в фоновом режиме.

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

Выявление последствий извлечения аккумулятора во время работы приложения.

Проверка уровня потребления энергии приложением.

Проверка побочных эффектов приложения.

Тема 11. Особенности алгоритмизации при разработке WEB-приложений.

11.1. Web-приложений в C#

C# (произносится си шарп) – объектно-ориентированный язык программирования. Разработан в 1998–2001 годах группой инженеров под руководством Андерса Хейлсберга в компании Microsoft как язык разработки приложений для платформы Microsoft .NET Framework и впоследствии был стандартизирован как ECMA- 22 334 и ISO/IEC 23270. C# относится к семье языков с C-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java.

С тех пор язык сильно вырос в плане популярности и стал чуть ли не самым предпочитаемым языком среди разработчиков Windows и Web-приложений, которые используют .NET Framework. Отчасти привлекательность языка С# связана с его понятным синтаксисом, который происходит от синтаксиса C/C++, но упрощает некоторые вещи. Несмотря на это упрощение, язык С# обладает той же мощью, что и C++

11.2 . Задачи Web-приложений

Формулирование критериев качества веб-приложений, и проведение критического анализа существующих методов разработки, хранения и взаимодействия веб-приложений.

2. Постановка и решение задачи оптимизации процесса разработки веб-приложений.

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

4. Разработка метода взаимного объектно-реляционного преобразования (ОРП) для организации взаимодействия ВП с БД и хранения данных, а также шаблона проектирования на его основе.

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

Объектом исследований являются ВП на платформе LAMP.

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

1. Проведён критический анализ существующих методов разработки, хранения и взаимодействия веб-приложений.

2. С помощью применения СКР-функции (среднестатистические колебания работоспособности) к определению дневного фокус-фактора (КПД) разработчика автор вычислил значение фокус-фактора (FFD) для новых команд, равное 0.72640625. Это значение может использоваться при планировании итерации новой команды, или индивидуальном планировании для нового члена команды разработки. Автором поставлена и решена оптимизационная задача по определению такого распределения задач по программистам, которое приведёт к максимизации показателя производительности (Рразр) всей команды.

3. Разработаны новая архитектура и алгоритмы функционирования ВП. Определены уровни абстракции ВП и их жизненный цикл. Метрический анализ разработанного ВП показал, что значение целевой функции метрик на 13% превосходит максимальное значение этой функции для других ВП. Применение предлагаемых методов позволяет увеличить количество повторно используемого кода на 16%. Как следствие, могут быть сокращены объем работ, бюджет, а также увеличена скорость разработки ВП. Качественные характеристики ВП (по ISO/IEC 9126) по данным экспертного анализа увеличиваются на 19% по сравнению с максимальным значением среди других ВП.

4. Создан новый метод объектно-реляционного преобразования «Активная модель», позволяющий взаимно преобразовывать объекты ЯП PHP в таблицы сервера баз данных. По результатам проведённых тестов можно заключить, что скорость работы на тестовой выборке увеличилась на 19 -27% для объектовозвращающего преобразования и на 16 - 25% для векторовозвращающего преобразования. Объем занимаемой памяти сократился на 16 - 24% для объектовозвращающего преобразования, и на 18 - 32% для векторовозвращающего преобразования по сравнению с системой Doctrine.

5. Разработаны методы решения практических задач синтеза ВП: методы загрузки ВП, методика работы со сторонними библиотеками, метод разграничения доступа к ВП, интернационализации данных и интерфейса, методика организации кэширования, методика аутентификации пользователя и взаимодействия со сторонними ВП. В результате тестирования было определено, что применение предлагаемых методов позволяет увеличить скорость обработки запросов ВП от 7% (при X = 15 и 35) до 35% (при X = 5).

6. Предлагаемая архитектура, алгоритмы функционирования ВП и ОРП-метод реализованы при создании нескольких ВП: системы публикации контента в сфере образования, визуального конструктора сайтов, системы управления сайтом, а также ВП, реализующего информационные процессы и структуры модели взаимодействия потребителя и производителя товаров и услуг (модель customer-supplier).

Тема 12. Критерии выбора средств разработки WEB-приложений.

12.1. Критерии выбора

Критерии выбора (в порядке важности):
0. Ориентация на stateless.
1. Качество.
2. Перспективность. Надеюсь что выбранный стэк технологий не умрет, пока я его учу.
3. Популярность. Важно, чтобы на эту тему было много вакансий (с убер большой З. П. разумеется).
4. Развитость. Не хочется ковыряться в багах инструментов. Было бы просто отлично, если бы я мог использовать уже готовые модули, а не делать свои для каждой задачи.
5. Быстродействие.
6. Грамотное сообщество, хорошие документации. Правда я верю, что для всех фрейворков в этом плане все хорошо, но мало-ли.
7. Отсутствие проблем с хостингом.

Тема 13. Критерии выбора средств разработки мобильных приложений.

13.1. Критерии выбора

Как правило, мобильные игры содержат большое количество элементов графики (картинки, анимация). Поэтому для сравнения Unity3D и ADT были выбраны уже готовые анимированные игры на Android Market, созданные с помощью этих пакетов. Игры оценивались по следующим критериям:

- время загрузки приложения (сек);

- размер памяти приложения (MB);

- средняя загрузка кэш памяти (MB);

- максимальная загрузка центрального процессора устройства (%);

- среднее время отклика приложения по запросу пользователя (мс);

- оценка использования анимации (мах 10);

- оценка управления (мах 10);

- оценка звуковых сопровождений (мах 10);

Тема 14. Этапы разработки, тестирования и ввода в эксплуатацию мобильных приложений

14.1. Тестирование

Тестирование – очень важный этап разработки мобильных приложений.

Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore несколько недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную негативную реакцию, пользователи оставляют низкие оценки и истерические отзывы. Новые пользователи, видя это, не устанавливают приложение.

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

Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.

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

Быстрое тестирование проводится после завершения итерации разработки, если сборка не пойдет в релиз.

Для начала проводятся smoke-тесты, чтобы понять имеет ли смысл тестировать сборку.

Затем берутся все выполненные задачи и пофикшенные баги за итерацию из Jira и скурпулезно проверяется соответствие результата описанию таска. Если задача включала в себя новые элементы интерфейса, она отправляется дизайнерам для сверки с макетами.

Некорректно выполненные задачи переоткрываются. Баги заносятся в Jira. К не UI багам обязательно прикладываются логи со смартфона. К UI багам скриншоты с пометками что не так.

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