Тестовые прогоны и обработка признаков ошибок. Базовые проверки системы и процедура тестового прогона
Страницы работы
Фрагмент текста работы
5. Тестовые прогоны и обработка признаков ошибок
В данной главе описаны процедуры тестовых прогонов операций CPM1, функций самодиагностики и обработка признаков ошибок для идентификации и исправления аппаратных и программных ошибок, которые могут произойти при работе ПЛК.
5.1 Базовые проверки системы и процедура тестового прогона
5.1.1 Базовые проверки системы
После настройки и подключения CPM1 проверьте следующие параметры. Перед тестовым прогоном обязательно проверьте подключения.
Питание и подключение входов/выходов
Клеммы надежно зажаты?
Между наконечниками или проводами нет замыкания?
Все кабеля правильно подключены и закреплены?
5.1.2 Процедура тестового прогона CPM1
1. Подключение питания
a) проверьте напряжение питания и подключения клеммника CPM1.
b) проверьте напряжение питания и подключения клеммника устройств входа/выхода.
c) включите питание и проверьте, чтобы горел индикатор POWER.
d) Используйте программатор для установления CPM1 в режим PROGRAM.
2. Проверка подключения входов/выходов
a) В режиме CPM1 PROGRAM проверьте подключение выходов, принудительно включая и выключая выходные биты.
Подробности см. 4.3.22.
b) Проверьте подключение входов с помощью входных индикаторов или просмотра с программатора.
a) Используйте программатор для установки CPM1 в режим RUN или MONITOR и проверьте, горит ли индикатор RUN.
b) Проверьте последовательность операций путем принудительной установки/сброса битов и т. д.
Исправьте обнаруженные ошибки.
5. Сохранение программы
a) Используйте программатор для записи программы на дискету
b) Выведите на принтер бумажный экземпляр.
Подробности об использовании программатора и SSS см. гл. 4
5.1.3 Предосторожности при обращении с памятью FLASH
Для защиты памяти FLASH соблюдайте следующие меры предосторожности.
Данные изменения будут потеряны, если они не записаны в память FLASH и питание отключилось более, чем на 20 дней (при 25 0 С), поскольку конденсатор поддержки ОЗУ разряжается.
Данные изменения можно сохранить путем переключения CPM1 в режим RUN или MONITOR или включения CPM1 вскоре после сделанных изменений.
3. Если одна из трех следующих операций выполняется в режиме MONITOR или RUN, CPM1 увеличит время цикла до 600 мс и прерывания будут запрещены, пока программа или установочные параметры переписываются.
· Программа изменяется он-лайновыми опрециями.
Сообщение об ошибке SСAN TIME OVER (превышено время цикла) при данных операциях не появляется. При он-лайновых операциях они могут оказать влияние на время реакции на вход.
5.2 Цикл CPM1
Общий алгоритм работы СPM1 показан на схеме. Инициализаци CPM1 вызывается при включении питания. Если ошибок не обнаружено, последовательно (циклически) выполняеются операции диспетчеризации, исполнения программы, обновления входов/выходов и обслуживания периферийных устройств. Среднее время цикла можно наблюдать с программатора.
Процессы инициализации включают очистку областей IR, SR, и AR, установку системных таймеров и проверка блоков входов/выходов.
5.3 Функции самодиагностики
В CPM1 есть различные функции самодиагностики для идентификации и исправления ошибок, которые могут произойти.
5.3.1 Нефатальные ошибки
Работа ПЛК и отработка программы продолжается после появления одного или нескольких признаков таких ошибок. Хотя работа ПЛК продолжается, причину неисправности нужно выявить и устранить как можно быстрее.
При появлении такой неисправности индикаторы POWER (СЕТЬ) и RUN (РАБОТА
а) первым делом убедитесь, что в начале скрипта закомментирована строка
(т.е. необходимо поставить точку с запятой в начале этой строки); б) компилим проект и запускаем на установку. Это и будет нашим тестовым проходом. Все операции должны дойти до конца и завершиться удачно. Прогрессбар будет зашкаливать и все компоненты будут извлечены вне зависимости от того выбраны они, или нет. Все так и должно быть! в) после тестового прогона в указанной папке создастся файл records.inf (имя и путь назначается в процедуре инициализации. О ней см. «подробное описание функций» ниже), его необходимо добавить в проект, раскомметировав, или добавив в начале скрипта строку:
Так же стоит отметить, что если сам скрипт находится в папке отличной от той, в которую компилится проект (например в скрипте NFS:Undercover откомпиленный файл сохраняется в Output\setup.exe), то records.inf создастся в папке с setup.exe и его необходимо будет перенести непосредственно к скрипту, или же подправить в секции [Files] его истинное расположение, например:
#ifdef records Source: Output\records.inf; DestDir: ; Flags: dontcopy #endif
г) снова откомпилить проект. После этого инсталлер готов к работе. При запуске процесс выполнения операций будет равномерно и корректно отображаться на прогрессбаре.
ExPlayer
Старожил
Shift85, все работает, спасибо, остался только 1 маленький минус.
Самый верхний прогрессбар (который под словами «Распаковка архивов»), вообще не двигается, т.е. после распаковки основных архивов, который я жал ARC’ом, должна идти распаковка игровых файлов, и прогрессбар должен двигаться, а он не двигается, в чем может быть проблема?
Shift85
Старожил
Он и не будет двигаться это ведь прогресс бар ProgressGauge. Ты ведь юзаешь прогресс бары от ISDone.
Для этого о тут и скрыт:
ExPlayer
Старожил
Shift85
Старожил
ExPlayer
Старожил
nik1967
Old Men
Где у тебя прописана «распаковка игровых файлов»?
Shift85
Старожил
nik1967
Old Men
Shift85
Старожил
ExPlayer
Старожил
Где у тебя прописана «распаковка игровых файлов»?
Нет, не много хочешь. Можно сделать. Но вначале ответь на вопрос.
Я имел ввиду основные файлы, т.е. через ISDone у меня распаковывается отдельный архив(ы), которые я сжал в ARC’е, а затем уже идет распаковка остальных файлов. я надеюсь ответил на твой вопрос (если я его правильно понял)
Я даже процитирую (а то не поверите, скажите там такого нет или не нашли):
ISDone » Описание скрипта:
определяет будет ли включен в компиляцию файл records.inf. Он служит для автоматического определения процентных соотношений между операциями. Создается в первом прогоне установки, далее включается в установщик раскомментированием выше указанной строки. Более подробную информацию об этом файле и тестовом прогоне см. раздел «Работа с библиотекой»;
распакует все *.arc архивы из в , при чем весь прогрессбар будет поделен на кусочки пропрорциональные размерам архивов. В общем тут все так же как в скрипте распаковки FreeArc.iss и ему подобным. Таким образом при распаковке нескольких архивов одного типа проще пользоваться ручной расстановкой, т.к. отличие расперделения процентов от автоматической будет совсем небольшим, но за то не требуется тестовый проход.
Тестирование – очень важный этап разработки мобильных приложений.
Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore несколько недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную негативную реакцию, пользователи оставляют низкие оценки и истерические отзывы. Новые пользователи, видя это, не устанавливают приложение.
Мобильное тестирование сложный процесс: десятки различных разрешений экрана, аппаратные отличия, несколько версий операционных систем, разные типы подключения к интернету, внезапные обрывы связи.
Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.
Под катом я расскажу как мы тестируем мобильные приложения.
Тестирование требований
Тестирование начинается до разработки. Отдел дизайна передает тестировщикам навигационную схему и макеты экранов, менеджер проекта – требования невидимые на дизайне. Если дизайн предоставляет заказчик, макеты до передачи в отдел тестирования проверяются нашими дизайнерами.
Тестировщик анализирует требования на полноту и противоречивость. В каждом проекте исходные требования содержат противоречивую информацию. Мы их решаем еще до начала разработки. Так же в каждом проекте требования неполны: не хватает макетов второстепенных экранов, ограничений на поля ввода, отображения ошибок, кнопки никуда не ведут. Неочевидны невидимые на макетах вещи: анимации, кеширование картинок и содержимого экранов, работа в нестандартных ситуациях.
Недостатки требований обсуждаются с менеджером проекта, разработчиками и дизайнерами. После 2-3 итераций, вся команда гораздо лучше понимает проект, вспоминает забытый функционал, фиксирует решения по спорным вопросам.
В основном на этом этапе используется basecamp.
Когда требования стали полны и непротиворечивы, тестировщик составляет smoke-тесты и функциональные тесты, покрывающие исходные данные. Тесты деляется на общие и специфические для разных платформ. Для хранения и прогона тестов мы используем Sitechсo.
Например, для проекта Trava на этом этапе было написано 1856 тестов.
Первый шаг тестирования закончен. Проект уходит в разработку.
Билд-сервер
Все наши проекты собираются на TeamCity билд-сервере.
Если менеджер проекта поставит галочку «для тестирования», тестировщикам уходит письмо о новой сборке для тестирования. Ее номер отображается на мониторе в кабинете тестировщиков. Красным отображаются билды выпущенные за последние сутки, их нужно тестировать активнее, чем белые.
Без «волшебного монитора» (кстати, работает на андроиде) часто тестировали старые билды. А новый билд с багами попадал заказчику. Теперь перед прогоном тест-кейсов достаточно взглянуть на монитор, путаница разрешилась.
Тестирование билдов бывает быстрое и полное.
Быстрое тестирование
Быстрое тестирование проводится после завершения итерации разработки, если сборка не пойдет в релиз.
Для начала проводятся smoke-тесты, чтобы понять имеет ли смысл тестировать сборку.
Затем берутся все выполненные задачи и пофикшенные баги за итерацию из Jira и скурпулезно проверяется соответствие результата описанию таска. Если задача включала в себя новые элементы интерфейса, она отправляется дизайнерам для сверки с макетами.
Некорректно выполненные задачи переоткрываются. Баги заносятся в Jira. К не UI багам обязательно прикладываются логи со смартфона. К UI багам скриншоты с пометками что не так.
После этого выполняются функциональные тесты этой итерации. Если были найдены баги не покрытые тест-кейсами, создается новый тест-кейс.
Для андроид приложений запускаются monkey тесты.
По окончании тестирования ставится галочка «тестирование багов пройдено» в билд-сервере (да, название галочки не очень правильное :).
Если в процессе тестирования не было найдено blocker, critical и major багов, ставится галочка «можно показывать заказчику». Ни один билд не отсылается заказчику без одобрения отдела тестирования. (По согласованию с заказчиком иногда высылаются билды с major багами).
Критичность бага определяется по таблице.
После завершения тестирования PM получает подробное письмо-отчет.
Полное тестирование
Полное тестирование проводится перед релизом. Включает себя в себя быстрое тестирование, регресионное тестирование, monkey-тестирование на 100 устройствах и тестирование обновлений.
Регрессионное тестирование подразумевает прогон ВСЕХ тест-кейсов по проекту. Тест-кейсов не только за последнюю итерацию, но и за все предыдущие и общие тест кейсы по требованиям. Это занимает день-три на одно устройство в зависимости от проекта.
Очень важный шаг — тестирование обновлений. Почти все приложения хранят данные локально (даже если это кука логина) и важно удостовериться, что после обновления приложения все данные пользователя сохранятся. Тестировщик скачивает билд из маркета, создает сохраняемые данные (логин, плейлисты, транзации учета финансов), обновляет приложение на тестовую сборку и проверяет, что все на месте. Затем прогоняет smoke-тест. Процесс повторяется на 2-3 устройствах.
Разработчики часто забывают о миграции данных со старых версий и тестирование обновлений позволило нам выявить множество критических ошибок с падениями, удалением пользовательских данных о покупках. Это спасло не одно приложение от гневных отзывов и потери аудитории.
Релизный monkey-тест мы проводим на 10 iOS и 80 Android устройствах при помощи сервиса Appthwack.
В конце полного тестирования, кроме письма, вручную составляется подробный отчет.
Сборка уходит в релиз только при 100% прохождении всех тест-кейсов.
Тестирование внешних сервисов
Тестировать интеграцию с Google Analytics, Flurry или системой статистики заказчика непросто. Бывало, что в релиз уходили сборки с нерабочим Google Analytics и никто не обращал на это внимания.
Поэтому в обязательно порядке для внешних сервисов создается тестовый аккаунт и он проверяется при полном тестировании. Кроме того отправка статистики фиксируется в логах, которые проверяются тестировщиками. При релизе тестовый аккаунт подменяется боевым.
Учет времени
Учет времени тестировщиков производится в отдельном Jira проекте. На составление тест-кейсов, прогон тестов, написание отчетов по проекту заводится отдельная задача и стандартными средствами в ней отмечается затраченное время.
UPD: а расскажите как устроено тестирование у вас, хотя бы сколько тестировщиков на разработчика
Подписывайтесь на наш хабра-блог. Каждый четверг полезные статьи о мобильной разработке, маркетинге и бизнесе мобильной студии.
Профиль | Отправить PM | Цитировать
