Архив рубрики: Публикации

Bash: использование команды tree для отображения структуры папок

Цель этого руководства — понять данные JSON и понять, как анализировать данные JSON в C ++. Мы обсудим данные JSON, объект, массив, синтаксис JSON, а затем рассмотрим несколько рабочих примеров, чтобы понять механизм анализа данных JSON в C ++.

Команда «tree» — это очень широко используемая команда Bash в Linux. Он используется для отображения содержимого любого желаемого каталога вашей компьютерной системы в виде древовидной структуры. Используя эту древовидную структуру, вы можете легко узнать пути к своим файлам и каталогам, проверить их права доступа и просмотреть скрытые файлы и каталоги. Поэтому сегодня мы поговорим об использовании команды Bash «tree» в Linux Mint 20, поделившись с вами некоторыми примерами.

Команда Bash Tree в Linux Mint 20

Чтобы использовать команду Bash «tree» в Linux Mint 20, вам сначала необходимо установить ее, выполнив эту команду:

$ sudo apt install tree

Было бы неплохо, если бы вы могли обновить свою систему перед запуском этой команды. После успешной установки команды tree в вашей системе Linux Mint 20 вы получите следующие сообщения на своем терминале:

Теперь, чтобы проверить, действительно ли команда Bash «tree» находится в вашей системе Linux Mint 20 или нет, вы можете проверить ее версию, выполнив команду, указанную ниже:

$ tree --version

Версия команды Bash «tree», которую нам удалось установить только что, выделена на следующем изображении:

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

$ tree --help

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

После выполнения этих шагов мы хотели бы поделиться с вами некоторыми из наиболее полезных примеров использования команды Bash «tree» в Linux Mint 20.

Пример №1: Отображение содержимого каталога в древовидной структуре

Древовидные структуры обычно легче визуализировать и интерпретировать по сравнению с обычным текстовым представлением. Следовательно, если у вас есть каталог, содержащий множество разных файлов и подкаталогов, вам следует предпочесть просматривать его содержимое в древовидной структуре. Это легко сделать, выполнив команду tree, как показано ниже:

$ sudo tree

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

Пример № 2: Отображение скрытых файлов и каталогов с помощью древовидной команды

В отличие от простого «дерева», вы также можете просмотреть скрытые файлы и каталоги. Вы можете сделать это просто, запустив команду «tree» с флагом «-a», как показано ниже:

$ sudo tree –a

Вы можете сравнить вывод этой команды с выводом, показанным в примере № 1, и вы сможете понять, что количество файлов и каталогов намного больше, чем показано выше. Это потому, что на этот раз команда «tree» также показала скрытые файлы и каталоги.

Пример № 3: Отображение файлов и каталогов вместе с их полными путями

Вместо того, чтобы отображать только имена файлов и каталогов, вы также можете узнать их точные пути. Вы можете сделать это, просто объединив команду «tree» с флагом «-f» следующим образом:

$ sudo tree –f

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

Пример №4: Распечатать дерево каталогов в XML-представлении

XML или Extensible Markup Language имеет особый синтаксис, в котором он представляет наши файлы и каталоги. Следовательно, если вы хотите распечатать свое дерево каталогов в XML-представлении, вы можете сделать это, объединив флаг «-X» с командой «tree» следующим образом:

$ sudo tree –X

XML-представление нашего дерева каталогов показано на изображении ниже:

Пример № 5: Отображение файлов и каталогов вместе с их разрешениями на доступ

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

$ sudo tree –p

Разрешения на «чтение», «запись» и «выполнение» показаны перед каждым именем файла и каталога в нашей структуре каталогов, как показано на следующем изображении. Кроме того, права доступа к каталогу также включают флаг «d», который указывает, что следующее имя относится к каталогу, а не к файлу.

Заключение

В сегодняшней статье мы рассказали вам о методе установки команды Bash «tree» в вашей системе Linux Mint 20. Мы продемонстрировали метод проверки его установки, а также доступ к страницам справки. Затем мы поделились с вами пятью наиболее важными сценариями, в которых команда «tree» может использоваться очень эффективно. Помимо этих пяти сценариев, существует множество других вариантов использования команды Bash «tree». Вкратце, эта команда Bash считается чрезвычайно полезной при работе с операционными системами на базе Linux.

https://www.youtube.com/watch?v=s2ZlKAyFpLs



2020-12-15T12:33:50
Вопросы читателей

Можно ли изменить имя компьютера в Linux?

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

Hostname в Linux

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

Для изменения имени хоста в Linux можно использовать несколько методов, и эти методы можно разделить на две категории: методы интерфейса командной строки (CLI) и методы графического интерфейса пользователя (GUI).

Методы CLI

Чтобы изменить имя хоста устройства в Linux, мы рекомендуем использовать инструменты командной строки. Эти методы универсальны и работают практически в любом дистрибутиве Linux. Кроме того, нет необходимости устанавливать какие-либо дополнительные пакеты.

Проверить имя хоста

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

$ hostname

$ hostnamectl

Изменить имя хоста с помощью hostname

Команду hostname можно использовать для изменения имени хоста системы, используя следующую структуру команд.

$ sudo hostname

Наконец, проверьте изменение.

$ hostname

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

Измените имя хоста с помощью hostnamectl

Инструмент hostnamectl контролирует имя хоста системы. Этот инструмент может выполнять широкий спектр действий; например, его можно использовать для отображения текущего имени хоста, для изменения имени хоста, для настройки описания среды и для управления системной строкой LOCATION.

Чтобы использовать hostnamectl для изменения имени хоста, выполните следующую команду.

$ sudo hostnamectl set-hostname

Затем проверьте изменение.

$ hostname

Затем нам нужно вручную обновить файл хоста. Для этого откройте файл в текстовом редакторе.

$ sudo vim /etc/hosts

Измените старое имя хоста на новое имя хоста.

$ 127.0.1.1 localhost

$ 127.0.1.1

Если вы используете более старый дистрибутив Linux, то после внесения изменений вам может потребоваться выполнить следующую команду.

$ /etc/init.d/hostname restart

Изменить имя хоста (для системы инициализации)

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

$ sudo vim /etc/hostname

На изображении ниже показано старое имя хоста.

Отредактируйте содержимое, чтобы обновить имя хоста.

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

$ hostname

GUI методы

В этом разделе мы будем использовать GNOME для изменения имени хоста устройства. Однако вы можете использовать YaST для изменения имени хоста в openSUSE.

Изменить имя хоста в GNOME

GNOME — мощная среда рабочего стола. Если вы используете GNOME, вы можете изменить имя хоста без выполнения каких-либо команд, открыв приложение «Настройки».

На левой панели прокрутите вниз и выберите «О программе». В этом примере имя хоста системы находится в поле «Имя устройства».

Щелкните «Имя устройства», чтобы открыть запрос на изменение имени хоста.

Введите новое имя хоста и нажмите «Переименовать», чтобы сохранить изменения.

Последние мысли

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

https://www.youtube.com/watch?v=gfX0gKuPrH4



2020-12-15T12:09:37
Вопросы читателей

Типы тестирования программного обеспечения

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

 

Модульное тестирование

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

 

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

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

 

Интеграционное тестирование

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

 

Стресс-тестирование

Подумайте о стресс-тестах, как о космическом шаттле или самолете. Что значит поместить ваше программное обеспечение или систему в режим «СТРЕСС»? Стресс — это не что иное, как интенсивная нагрузка определенного типа, которая, скорее всего, сломает вашу систему. Это может быть похоже на «нагрузочное тестирование» в том смысле, что ваша система подвергается высокому параллелизму, когда к системе обращается множество пользователей. Но напряжение системы может происходить и на других векторах. Например, запуск микропрограммы на аппаратном компоненте, когда аппаратное обеспечение имеет физический износ и работает в ухудшенном режиме. Стресс является уникальным для всех типов программного обеспечения, и при разработке систем и при разработке стресс-тестов следует учитывать, какие естественные или неестественные причины с наибольшей вероятностью могут вызвать нагрузку на ваше программное обеспечение или систему.

 

Нагрузочное тестирование

Нагрузочное тестирование — это особый тип стресс-тестирования, как обсуждалось выше, при котором большое количество одновременных пользовательских подключений и обращений автоматизировано для создания имитации эффекта одновременного доступа большого количества подлинных пользователей к вашей программной системе. Цель состоит в том, чтобы выяснить, сколько пользователей могут получить доступ к вашей системе одновременно без нарушения работы вашей программной системы. Если ваша система может легко обрабатывать обычный трафик 10 000 пользователей, что произойдет, если ваш веб-сайт или программное обеспечение станут вирусными и привлекут 1 миллион пользователей? Сможет ли эта неожиданная «НАГРУЗКА» сломать ваш сайт или систему? Нагрузочное тестирование будет имитировать это, поэтому вы можете быть уверены в будущем увеличении числа пользователей, потому что знаете, что ваша система может выдержать возросшую нагрузку.

 

Тестирование производительности

Люди могут полностью разочароваться и впасть в отчаяние, если программное обеспечение не соответствует их требованиям к производительности. Производительность, как правило, означает, насколько быстро могут быть выполнены важные функции. Чем более сложные и динамичные функции доступны в системе, тем более важным и неочевидным становится проверка ее производительности. Давайте возьмем базовый пример — операционная система Windows или Linux. Операционная система — это очень сложный программный продукт, и тестирование производительности в ее системе может включать скорость и синхронизацию таких функций, как загрузка, установка приложения, поиск файла, выполнение вычислений на графическом процессоре и/или любые другие из миллионы действий, которые можно выполнить. При выборе тестовых сценариев производительности следует проявлять осторожность, чтобы убедиться, что проверены важные и потенциально неисправные функции производительности.

 

Тестирование масштабируемости

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

 

Статический анализ тестирования

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

 

Тестирование методом впрыска неисправностей

Некоторые ошибки очень сложно моделировать или запускать, поэтому программное обеспечение может быть разработано так, чтобы искусственно вводить проблему или сбой в систему без естественного возникновения дефекта. Цель тестирования с внесением неисправностей — увидеть, как программное обеспечение обрабатывает эти неожиданные неисправности. Изящно ли он реагирует на ситуацию, дает ли он сбой или дает неожиданные и непредсказуемые проблемные результаты? Например, предположим, что у нас есть банковская система, и есть модуль для внутреннего перевода средств со СЧЕТА A на СЧЕТ B. Однако эта операция перевода вызывается только после того, как система уже проверила, что эти учетные записи существуют, до вызова операции перевода. . Несмотря на то, что мы предполагаем, что обе учетные записи действительно существуют, операция передачи имеет сбой, когда одна целевая или исходная учетная запись не существует, и что это может вызвать ошибку. Поскольку в нормальных условиях мы никогда не получаем эту ошибку из-за предварительного тестирования входных данных, поэтому для проверки поведения системы при сбое передачи из-за несуществующей учетной записи мы вводим ложную ошибку в систему, которая возвращает несуществующую учетную запись. для передачи и проверьте, как остальная система реагирует в этом случае. Очень важно, чтобы код внедрения неисправности был доступен только в сценариях тестирования и не выпускался в производство, где он мог бы создать хаос.

 

Тестирование переполнения памяти

При использовании таких языков, как C или C ++, программист несет большую ответственность за прямую адресацию памяти, и это может вызвать фатальные ошибки в программном обеспечении, если будут сделаны ошибки. Например, если указатель равен нулю и разыменован, программное обеспечение выйдет из строя. Если для объекта выделяется память, а затем строка копируется в пространство памяти объекта, обращение к объекту может вызвать сбой или даже неопределенное неправильное поведение. Поэтому очень важно использовать инструмент, чтобы попытаться обнаружить ошибки доступа к памяти в программном обеспечении, использующем такие языки, как C или C ++, которые могут иметь эти потенциальные проблемы. Инструменты, которые могут выполнять этот тип тестирования, включают Valgrind с открытым исходным кодом или проприетарные инструменты, такие как PurifyPlus.. Эти инструменты могут спасти ситуацию, когда непонятно, почему программное обеспечение дает сбой или работает неправильно, и напрямую указывают на то место в коде, где есть ошибка. Классно, правда?

 

Граничное тестирование

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

If ( amt < 300 ) {

startWithdrawl ( )

}

else {

error ( «Вы можете снять % s», amt ) ;

}

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

 

Fuzz-тестирование

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

 

Исследовательское тестирование

Закройте глаза и представьте себе, что означает слово «исследовать». Вы наблюдаете и исследуете систему, чтобы узнать, как она действительно функционирует. Представьте, что вы получили по почте новое рабочее кресло, состоящее из 28 частей в отдельных пластиковых пакетах без каких-либо инструкций. Вы должны изучить свое новое прибытие, чтобы понять, как оно функционирует и как устроено. Обладая этим духом, вы можете стать исследовательским тестером. У вас не будет четко определенного плана тестирования тестовых случаев. Вы исследуете и исследуете свое программное обеспечение в поисках вещей, которые заставят вас сказать замечательное слово: «ИНТЕРЕСНО!». Узнав, вы исследуете дальше и найдете способы взломать программное обеспечение, о котором никогда не думали разработчики, а затем предоставите отчет, в котором подробно описаны многочисленные неверные предположения, ошибки и риски в программном обеспечении.

Тестирование на проникновение

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

 

Регрессионное тестирование

После того, как у вас есть работающее программное обеспечение, которое развернуто в полевых условиях, крайне важно предотвратить внесение ошибок в функциональность, которая уже работала. Целью разработки программного обеспечения является повышение возможностей вашего продукта, внесение ошибок или прекращение работы старых функций, что называется РЕГРЕССИЕЙ. Регрессия — это ошибка или дефект, появившийся, когда ранее возможность работала должным образом. Ничто не может испортить репутацию вашего программного обеспечения или бренда быстрее, чем внесение регрессионных ошибок в ваше программное обеспечение и предоставление реальным пользователям возможности найти эти ошибки после выпуска.

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

 

Тестирование исходного кода пополам

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

 

Тестирование локализации

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

 

Тестирование доступности

Некоторые граждане нашего сообщества имеют инвалидность и, следовательно, могут испытывать проблемы с использованием создаваемого программного обеспечения, поэтому проводится тестирование доступности, чтобы гарантировать, что люди с ограниченными возможностями по-прежнему могут получить доступ к функциям системы. Например, если мы предположим, что 1% населения страдает дальтонизмом, а наш программный интерфейс предполагает, что пользователи могут различать красный и зеленый, но эти люди с дальтонизмом НЕ МОГУТ увидеть разницу. Следовательно, хорошо продуманный программный интерфейс помимо цвета будет иметь дополнительные подсказки для обозначения значения. Другие сценарии, помимо тестирования на дальтонизм, также будут включены в тестирование доступности программного обеспечения, например, полная зрительная слепота, глухота и многие другие сценарии. Хороший программный продукт должен быть доступен максимальному проценту потенциальных пользователей.

 

Обновление тестирования

Простые приложения на телефоне, операционные системы, такие как Ubuntu, Windows или Linux Mint, а также программное обеспечение, работающее на атомных подводных лодках, нуждаются в частом обновлении. Сам процесс обновления может привести к ошибкам и дефектам, которых не было бы при новой установке, потому что состояние среды было другим, и процесс внедрения нового программного обеспечения поверх старого мог привести к ошибкам. Рассмотрим простой пример: у нас есть ноутбук с Ubuntu 18.04, и мы хотим перейти на Ubuntu 20.04. Этот процесс установки операционной системы отличается от непосредственной очистки жесткого диска и установки Ubuntu 20.04. Следовательно, после установки программного обеспечения или любой из его производных функций оно может не работать на 100%, как ожидалось, или так же, как при новой установке программного обеспечения. Так, мы должны сначала рассмотреть возможность тестирования самого обновления во многих различных случаях и сценариях, чтобы убедиться, что обновление работает до конца. И затем мы также должны рассмотреть возможность тестирования фактической системы после обновления, чтобы убедиться, что программное обеспечение установлено и функционирует должным образом. Мы не будем повторять все тестовые примеры для только что установленной системы, что было бы пустой тратой времени, но мы будем тщательно продумывать, зная, что система МОЖЕТ сломаться во время обновления, и стратегически добавлять тестовые примеры для этих функций.

 

Тестирование черного и белого ящиков

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



2020-12-14T21:13:55
Программирование

3 Лучшие Биткоин-Миксеры

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

Владельцы биткойнов встречаются через распределенную книгу под названием block chain, где адреса отправителя и получателя можно легко отслеживать. Этот вопрос конфиденциальности технологии вводит принятие Биткойн-миксеров, также известных как тумблеры. Читать →

OSPF LSA описание

LSA содержат в себе информацию о маршруте передается внутри Link State Update (LSU) пакета. Каждый LSU пакет содержит в себе один или несколько LSA, и когда LSU отправляется между маршрутизаторами OSPF, он распространяет информацию LSA через сеть. Каждый LSA используется в определенных границах сети OSPF.

 

ТИПЫ LSA

OSPF в настоящее время определяет 11 различных типов LSA, однако, несмотря на большое разнообразие LSA, только около половины из них обычно встречаются в сетях OSPF, но мы рассмотрим их все.

LSA ТИП 1 – OSPF ROUTER LSA

Пакеты LSA Type 1 (Router LSA) отправляются между маршрутизаторами в пределах одной и той же зоны (area) где они были созданы и не покидают эту зону. Маршрутизатор OSPF использует пакеты LSA Type 1 для описания своих собственных интерфейсов, а также передает информацию о своих соседях соседним маршрутизаторам в той же зоне.

 

LSA ТИП 2 – OSPF NETWORK LSA

Пакеты LSA Type 2 (Network LSA) генерируются Designated Router’ом (DR) для описания всех маршрутизаторов, подключенных к его сегменту напрямую. Пакеты LSA Type 2 рассылаются между соседями в одной и той же зоны где они были созданы и остаются в пределах этой зоны.

LSA ТИП 3 – OSPF SUMMARY LSA

Пакеты LSA Type 3 (Summary LSA) генерируются с помощью пограничных маршрутизаторов Area Border Routers (ABR) и содержат суммарное сообщение о непосредственно подключенной к ним зоне и сообщают информацию в другие зоны, к которым подключен ABR. Пакеты LSA Type 3 отправляются в несколько зон по всей сети.

На рисунке показано как маршрутизатор R2 ABR создает Type 3 Summary LSA и отправляет их в зону Area 0. Таким же образом R3 ABR роутер создает пакеты Type 3 и отправляет их в Area 2. В таблице маршрутизации маршруты, полученные таким образом, отображаются как “O IA”

LSA ТИП 4 – OSPF ASBR SUMMARY LSA

Пакеты LSA Type 4 (ASBR Summary LSA) – это LSA, которые объявляют присутствие автономного пограничного маршрутизатора Autonomous System Border Router (ASBR) в других областях.

На схеме, когда R2 (ABR) принимает пакет LSA Type 1 от R1, он создаст пакет LSA Type 4 (Summary ASBR LSA), который передает маршрут ASBR, полученный из Area 1, и вводит его в Area 0. Хотя пакеты LSA Type 4 используются ABR для объявления маршрута ASBR через их зоны, он не будет использоваться самим ASBR в пределах его локальной зоны (Area 1); ASBR использует LSA Type 1 для информирования своих соседей (в данном случае R2) в своих сетях.

LSA ТИП 5 – OSPF ASBR EXTERNAL LSA

Пакеты LSA Type 5 (ASBR External LSA) генерируются ASBR для передачи внешних перераспределенных маршрутов в автономную систему (AS) OSPF. Типичным примером LSA Type 5 будет внешний префикс или маршрут по умолчанию (default router), как показано на схеме.

Этот внешний маршрут/префикс перераспределяется в OSPF-сеть ASBR (R1) и в таблице маршрутизации будет отображаться как “O E1” или “O E2“.

LSA ТИП 6 – OSPF GROUP MEMBERSHIP LSA

Пакеты LSA Type 6 (Group Membership LSA) были разработаны для протокола Multicast OSPF (MOSPF) , который поддерживает многоадресную маршрутизацию через OSPF. MOSPF не поддерживается Cisco и не пользуется широкой популярностью.

LSA ТИП 7 – OSPF NOT SO STUBBY AREA (NSSA) EXTERNAL LSA

Пакеты LSA Type 7 (NSSA External LSA) используются для некоторых специальных типов зон, которые не позволяют внешним распределенным маршрутам проходить через них и таким образом блокируют распространение в них LSA Type 5. LSA Type 7 действуют как маска для LSA Type 5 пакетов, позволяя им перемещаться по этим специальным зоам и достигать ABR, который может переводить пакеты LSA Type 7 обратно в пакеты LSA Type 5.

На схеме ABR R2 переводит LSA Type 7 в LSA Type 5 и рассылает его в сеть OSPF.

LSA ТИП 8 – OSPF EXTERNAL ATTRIBUTES LSA (OSPFV2) / LINK LOCAL LSA (OSPFV3)

Пакеты LSA Type 8 в OSPFv2 (IPv4) называются внешними атрибутами LSA и используются для передачи атрибутов BGP через сеть OSPF, в то время как адреса BGP передаются через LSA Type 5 пакеты, однако, эта функция не поддерживается большинством маршрутизаторов. С OSPFv3 (IPv6) , LSA Type 8 переопределяется для передачи информации IPv6 через сеть OSPF.

LSA ТИП 9, 10 И 11

Обычно LSA этих типов используются для расширения возможностей OSPF. Практическое применение этих LSA заключается в Traffic Engineering’е MPLS, где они используются для передачи параметров интерфейса, таких как максимальная пропускная способность, незанятая полоса пропускания и т.д.

LSA ТИП 9 – OSPF LINK SCOPE OPAQUE (OSPFV2) / INTRA AREA PREFIX LSA (OSPFV3)

LSA Type 9 в OSPFv2 (IPv4) определяется как Link Scope Opaque LSA для передачи OSPF информации. Для OSPFv3 он переопределяется для обработки префикса связи для специального типа зоны, называемого Stub Area.

LSA ТИП 10 – OSPF AREA SCOPE OPAQUE LSA

Пакеты LSA Type 10 используются для потоковой передачи информации OSPF через маршрутизаторы других областей. Даже если эти маршрутизаторы не обрабатывают эту информацию, чтобы расширить функциональность OSPF, этот LSA используется для Traffic Engineering’а для объявлений MPLS и других протоколов.

LSA ТИП 11– OSPF AS SCOPE OPAQUE LSA

Пакеты LSA Type 11 выполняют ту же задачу, что и пакеты LSA Type 10, но не пересылаются в специальные зоны (Stub зоны)

Источник



2020-12-14T16:24:15
other

🐧 Операторы Bash if: if, elif, else, then, fi

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

Другими словами, условные операторы определяют «если условие истинно или ложно, то сделать то или это, а если верно противоположное, сделать что-нибудь еще».

Это самая основная функция любого условного оператора.

Эта статья познакомит вас с пятью основными предложениями оператора if , а именно if, elif, else, then и fi. Читать →