Обнаружение ошибок спецификации

Общие положения

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

Эта система включает в себя следующие функции:

1. Администрирование и эксплуатация.
   1. Изменение абонентских данных. Эта задача состоит в установлении и снятии дополнительных видов обслуживания: организации и эксплуатации абонентских групп, обнаружение злонамеренных вызовов; обслуживание абонентских, соединительных линий и каналов — измерение их параметров, организация групп направлений; установка ограничений и слежение за перегрузкой, установка кода перехвата соединений для направления по другим маршрутам; запись и закрепление за терминалами стандартных сообщений, маршрутизация (назначение маршрутов, групп линий и отдельных каналов).
   2. Измерение трафика. Контроль и регулировка трафика.
   3. Тарификация. Установка и корректировка тарифов. Учет стоимости разговоров.
   4. Обеспечение документирования стоимости. Обеспечение надежности подсчета стоимости.
   5. Обслуживание системы ОКС. Установка пунктов сигнализации. Закрепление каналов за системой ОКС. Обслуживание подсистем пользователя. Обслуживание подсистемы управлени
      я сетью сигнализации.
2. Техническое обслуживание.
   1. Измерение и тестирование абонентских линий.
   2. Измерение и тестирование соединительных линий и каналов.
   3. Диагностика и устранение повреждений.
   4. Обслуживание и профилактика аппаратных средств.
   5. Ведение документации об аварийных состояниях.
   6. Модификация и обеспечение надежного функционирования программного обеспечения.
   7. Модификация и ведение баз данных.

Аппаратура и методы технической эксплуатации и обслуживания

Как правило, современные цифровые АТС не требуют постоянного присутствия обслуживающего персонала. Станции наблюдаются и обслуживаются с помощью центров технического обслуживания и посещаются операторами только при проведении работ по техническому обслуживанию. Системы технического обслуживания должны обеспечивать различные организационные формы обслуживания (например, со специализацией персонала по оборудованию или универсальных специалистов). При обеспечении дистанционного интерфейса предусматривается специализированный стык Q₃.

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

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

Диагностические программы позволяют оператору определить место повреждения и сводят восстановление к замене элемента (Типового Элемента Замены — ТЭЗ).

Все операции документируются. Для общения с человеком применяется либо рекомендованный МККТТ язык MML (Man Machine Language), либо система типовых окон и меню. Каждое вводимое сообщение контролируется на правильность, и выполнение подтверждается.

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

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

Для тестирования работы с внешним окружением на станциях предусматриваются тестовые приборы для испытания интерфейсов и измерения параметров линий и каналов.

В это комплекс обязательно должны входить:

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

Типовая процедура технического обслуживания

Типовая процедура обслуживания заключается в следующем.

1. Оповещение оператора визуальными и акустическими средствами. Визуальные сообщения указывают на адрес и характер повреждения.
2. Оператор подтверждает принятие аварийного сигнала для технического обслуживания.
3. Оператор начинает на дисплее процедуру технического обслуживания.
4. Система ведет оператора до момента локализации повреждения.
5. Оператор блокирует устройство и запускает программу диагностики, которая рекомендует ему ТЭЗ (Типовой Элемент Замены).
6. Оператор снимает ТЭЗ и ставит новый.
7. Проводится тестирование нового ТЭЗа.
8. При положительном результате тестирования снимается блокировка.
9. Станция вводит блок в конфигурацию и сообщает оператору об устранении отказа.

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

Сопровождение программного обеспечения

Сопровождение программного обеспечения требуется для устранения ошибок в программном обеспечении или при отклонениях в поведении внешней среды.

Кроме этого, периодически может проводиться коррекция или модернизация программного обеспечения по договору с поставщиком или из-за изменений в сети.

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

Меры по обеспечению надежности системы

Для поддержания надежности системы используются следующие принципы:

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

При этом возможно несколько уровней восстановления (таблица 7.1).

Вопросы поддержки сети

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

Документация

Для технического обслуживания и эксплуатации большое значение имеет документация.

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

• на уровне спецификации (specification — описание перечня задач, выполняемых программным обеспечением);
• на уровне описания (description — описание того, из чего состоит и как сделано программное обеспечение).

Должны быть составлены соответствующие руководства, сопровождаемые алгоритмами по основным разделам: Администрирование и техническое обслуживание; Эксплуатация.

Система документирования программного обеспечения на основе рекомендаций ITU рассмотрена в [12].

вопрос

Правильный ответ:

Комментарии:

Другие ответы на вопросы из темы сетевые технологии интуит.

• #

  1.Информация синхронизации цикла в ИКМ 30 переносится в__________ кадре

• #

  В процессе передачи команд медленными считаются устройства выполняющие команды за время _____

• #

  В случае освобождения исходящей соединительной линии передается сигнал_____.

• #

  Интерфейс _____ служит для взаимодействия систем с системами поддержки функционирования других сетей TMN

• #

  Для формата кодов пунктов сигнализации региональной сети – индикатор сети равен _________

I. Виды тестирования по цели

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

Функциональные виды тестирования

Функциональные тесты базируются на функциях и особенностях, а также на взаимодействии с другими системами и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing), приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов.

Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом.

1.Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).

Тестирование функциональности может проводиться в двух аспектах:

Тестирование в аспекте «требования» использует спецификацию функциональных требований к системе, как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.

Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этом аспекте тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

2. Тестирование безопасности (Security and Access Control Testing)

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

Общая стратегия безопасности основывается на трех основных принципах:

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

Существует два основных критерия при определении понятия целостности:

3. Тестирование взаимодействия или Interoperability Testing

Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование (integration testing).

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

Нефункциональные виды тестирования

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

1.Все виды тестирования производительности

Тестирование производительности ( Performance testing ).

Задачей тестирования производительности является определение масштабируемости приложения под нагрузкой, при этом происходит:

Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.

Определение количества пользователей, одновременно работающих с приложением.

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

Исследование производительности на высоких, предельных, стрессовых нагрузках.

Стрессовое тестирование ( Stress Testing )

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

Объемное тестирование ( Volume Testing )

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

Измерение времени выполнения выбранных операций при определенных интенсивностях выполнения этих операций.

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

Тестирование стабильности или надежности( Stability / Reliability Testing)

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

В англоязычной терминологии вы можете так же найти еще один вид тестирования — Load Testing — тестирование реакции системы на изменение нагрузки (в пределе допустимого). Нам показалось, что Load и Performance преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.

2. Тестирование установки (Installation Testing)

Тестирование установки направленно на проверку успешной инсталляции и настройки, а также на обновление или удаление программного обеспечения.

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

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

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

3. Тестирование удобства пользования (Usability Testing)

Иногда мы сталкиваемся с непонятными или нелогичными приложениями, многие функции и способы использования которых часто не очевидны. После такой работы редко возникает желание использовать приложение снова, и мы ищем более удобные аналоги. Для того, чтобы приложение было популярным, ему мало быть функциональным – оно должно быть еще и удобным. Если задуматься, интуитивно понятные приложения экономят нервы пользователям и затраты работодателя на обучение. Значит, они более конкурентоспособные! Поэтому тестирование удобства использования, о котором пойдет речь далее, является неотъемлемой частью тестирования любых массовых продуктов.

Тестирование удобства пользования — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.

Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:

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

Правильность ( accuracy) — сколько ошибок сделал пользователь во время работы с приложением (меньше — лучше).

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

Эмоциональная реакция ( emotional response ) – как пользователь себя чувствует после завершения задачи — растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция — лучше).

II. Виды тестирования по степени автоматизации

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

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

Мифы о ручном тестировании:

– кто угодно может провести ручное тестирование

Нет, выполнение любого вида тестирования требует специальных знаний и профессиональной подготовки.

– автоматизированное тестирование мощнее ручного

Полная автоматизация невозможна. Необходимо использовать также и ручное тестирование.

– ручное тестирование – это просто

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

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

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

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

Существует несколько основных видов автоматизированного тестирования:

– автоматизация тестирования кода (Code-driven testing) – тестирование на уровне программных модулей, классов и библиотек (фактически, автоматические юнит-тесты);

– автоматизация тестирования графического пользовательского интерфейса (Graphical user interface testing) – специальная программа (фреймворк автоматизации тестирования) позволяет генерировать пользовательские события – нажатия клавиш, клики мышкой, и отслеживать реакцию программы на эти действия – соответствует ли она спецификации.

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

Автоматические тесты – это полноценные программы, просто предназначенные для тестирования.

III. Виды тестирования по запуску кода

Статическое тестирование (static testing) — тестирование без запуска кода на исполнение.

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

Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации.

Можно поделить статическое тестирование на 2 типа:

1. Обзоры (Review)

2. Статический анализ (Static Analysis)

Обзоры

Обзоры (Review) – проверка обычно используется для поиска и устранения ошибок или неясностей в документах. Это могут быть требования, дизайн, тестовые случаи и так далее.

В свою очередь обзоры делятся на:

Статический анализ

Статический анализ (Static Analysis) – код, написанный разработчиками, анализируется на наличие структурных дефектов, которые могут привести к ошибкам.

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

— неиспользуемые переменные,

— мертвый код,

— бесконечные циклы,

— переменные с неопределенными значениями,

— неправильный синтаксис.