По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Вы готовы к тому, чтобы узнать больше о различных видах тестирования программного обеспечения?
Как тестировщики, мы знаем о самых разных видах тестирования программного обеспечения. К ним относятся: функциональное тестирование, нефункциональное тестирование, автоматизированное тестирование, гибкое тестирование и их подвиды и другие.
Каждый из нас, изучая процесс тестирования, так или иначе сталкивался в несколькими видами тестирования. Вы могли слышать о некоторых из них или даже могли с ними работать, но маловероятно, что вы знаете обо всех видах тестирования, как и многие другие.
Каждый вид тестирования имеет свои характерные особенности, свои преимущества и недостатки. Тем не менее, в этой статье мы рассмотрели по большей части все виды тестирования программного обеспечения, которые мы используем на регулярной основе.
Давайте взглянем на них!!
Различные виды тестирования программного обеспечения
Ниже представлена общая классификация видов тестирования программного обеспечения.
Мы рассмотрим каждый вид во всех подробностях и приведем примеры.
Функциональное тестирование
Существует четыре основных вида функционального тестирования.
#1) Модульное тестирование
Модульное тестирование – это вид тестирования программного обеспечения, которое проводится на отдельно взятом модуле или компоненте, чтобы проверить внесенные правки. В большинстве случаев разработчики проводят модульное тестирование на этапе разработки приложения. В качестве модуля может выступать метод, функция, процедура или объект. Часто разработчики используют инструменты для автоматизации модульного тестирования, такие как NUnit, Xunit, JUnit.
Модульное тестирование – это важный этап разработки, поскольку на этапе модульного тестирования можно обнаружить большую часть ошибок.
Например, пусть у нас есть самое простое приложение-калькулятор. Разработчик может написать модульный тест для того, чтобы проверить правильность выполнения функций. Например, если пользователь введет два числа, будет ли верно посчитана сумма.
а) Тестирование методом «белого ящика»
Тестирование методом «белого ящика» – это методика тестирования, при которой тестировщику доступны внутренняя структура или код приложения. При таком подходе достаточно легко найти уязвимость в архитектуре приложения или недочеты в логике его функционирования. Примерами такой методики являются покрытие операторов и покрытие альтернатив/покрытие ветвей.
б) Gorilla Testing (Gorilla-тестирование)
Gorilla Testing – это методика тестирование, при которой тестировщик совместно с разработчиком (или отдельно от разработчика) досконально тестирует какой-либо конкретный модуль приложения со всех сторон. Gorilla Testing проводится для того, чтобы узнать, насколько ваше приложение устойчиво к сбоям.
Например, тестировщик тестирует сайт некой компании по страхованию домашних животных, которая предоставляет услугу покупки страхового полиса, жетона для питомца и пожизненного права членства. Тестировщик выбирает какой-то один модуль и концентрирует на нем свое внимание. Допустим, это модуль покупки страхового полиса. И он досконально тестирует его с помощью положительных и негативных сценариев тестирования.
#2) Интеграционное тестирование
Интеграционное тестирование – это разновидность тестирования программного обеспечения, при котором тестируются два и более сгруппированных модулей (как одно целое). При этом виде тестирования основной фокус внимания направлен на поиск неисправностей в интерфейсе, передаче данных и потоке данных между модулями. При интеграции модулей в систему используется либо нисходящий подход, либо восходящий.
Такой вид тестирования проводится при интеграции модулей системы или между системами. Например, пользователь приобретает билет на самолет на сайте любой авиакомпании. При покупке билета пользователи могут видеть информацию о рейсе и о платеже, но системы, которые предоставляют информацию о рейсе и обрабатывают платежи, - это две разные системы. Именно поэтому при интеграции веб-сайта авиакомпании и системы обработки платежей нужно проводить интеграционное тестирование.
а) Тестирование методом «серого ящика»
Из названия уже можно понять, что данная методика тестирования – это комбинация двух методик: тестирования методом «белого ящика» и тестирования методом «черного ящика». При таком подходе тестировщики видят внутреннюю структуру или код приложения только частично.
#3) Системное тестирование
Системное тестирование – это разновидность тестирования программного обеспечения, при котором тестировщику нужно проанализировать всю систему на соответствие определенным требованиям.
а) Сквозное тестирование
Методика сквозного тестирования подразумевает тестирование всей среды приложения в ситуации, близкой к реальной. Это может быть взаимодействие с базой данных, передач данных по сети или взаимодействие с другим оборудованием, приложениями или системами.
Например, тестировщику необходимо протестировать веб-сайт для страхования домашних животных. Сквозное тестирование подразумевает тестирование следующих аспектов: процесса покупки страхового полиса, жетона, функции добавления другого домашнего животного, обновления информации о кредитной карте в учетной записи пользователя, обновления информации об адресе пользователя, получения электронных писем с подтверждением заказа и условий договора страхования.
б) Тестирование методом «черного ящика»
Тестирование методом «черного ящика» – это методика тестирования программного обеспечения, при которой тестировщик не видит внутренней структуры, архитектуры или код тестируемой системы. Их задача – сосредоточиться лишь на вводе и выводе объектов тестирования.
в) Smoke-тестирование
Smoke-тестирование предназначено для проверки основных и критически важных функций тестируемой системы на предмет высокоэффективной работы.
Всякий раз, когда команда разработчиков предоставляет новую сборку, команда тестировщиков программного обеспечения должна проверить сборку и гарантировать, что в ней нет никаких серьезных проблем. Когда команда тестировщиков подтвердит стабильность сборки, будет проведено более детальное тестирование.
Например, тестировщику необходимо протестировать веб-сайт для страхования домашних животных. Основные функции данного сайта – покупка страхового полиса, добавление еще одного домашнего животного и предоставление расценок. С помощью smoke-тестирования можно проверить, все ли эти функции работают полноценно, прежде чем переходить к более детальному тестированию.
г) Санитарное тестирование
Санитарное тестирование проводится для того, чтобы убедиться, что все новодобавленные функции и правки в систему работают отлично. Санитарное тестирование проводится только на стабильной сборке. Этот вид тестирования является разновидностью регрессионного тестирования.
Например, тестировщику необходимо протестировать веб-сайт для страхования домашних животных. Были внесены изменения касательно скидки на покупку полиса на второго домашнего животного. Тогда санитарное тестирование проводится лишь для модуля покупки страхового полиса.
д) Happy-path-тестирование
Happy-path-тестирование сосредоточено на тестировании потоков «положительной логики» приложения. При таком тестировании не ищутся условия возникновения негативных последствий или ошибок. Основное внимание уделяется только корректным входным данных, которые влекут за собой положительные сценарии и, получая которые, приложение выдает ожидаемый результат.
е) Бездумное тестирование (Monkey Testing)
Тестировщик проводит бездумное тестирование, предполагая, что приложение будет использовать обезьяна, то есть вводить данные будет именно обезьяна, не знающая ничего и не понимая принцип работы приложения.
Цель бездумного тестирования – проверить, произойдет ли сбой приложения или системы при случайных входных данных. Бездумное тестирование выполняется случайным образом, тестовые случаи нигде не фиксируются, а также для проведения такого тестирования не нужно знать о том, как функционирует система.
#4) Приёмочное тестирование
Приёмочное тестирование – это разновидность тестирования программного обеспечения, при котором клиент/предприятие/заказчик тестируют программное обеспечения с помощью реальных бизнес-сценариев.
Клиент принимает программное обеспечение только в том случае, если все функции работают так, как надо. Приёмочное тестирование – это последний этап, после которого программное обеспечение отправляется в производство. Его еще называют пользовательское приёмочное тестирование (UAT - User Acceptance Testing).
а) Альфа-тестирование
Альфа-тестирование – это разновидность приёмочного тестирования. Оно проводится командой от организации для того, чтобы выявить как можно больше неполадок перед тем, как программное обеспечение будет выпущено.
Например, сайт страхования домашних животных проверяется с помощью UAT. Команда UAT будет прогонять реальные сценарии, такие как покупка страхового полиса, покупка годового права на членство, изменение адреса пользователя, передача права собственности на домашнее животное. Все будет происходить так, как если бы реальный пользователь использовал настоящий веб-сайт. Для прогона сценариев, связанных с платежами, команда может использовать данные тестовой кредитной карты.
б) Бета-тестирование
Бета-тестирование – это разновидность тестирования программного обеспечения. Его проводят клиент/заказчики. Бета-тестирование проводится в реальной среде перед выпуском продукта на рынок, где его смогут приобрести реальные конечные пользователи.
Бета-тестирование необходимо для того, чтобы убедиться, что в программном обеспечении или продукте не происходят какие-то серьезные сбои и что оно удовлетворяет всем требованиям с позиции конечного пользователя со стороны заказчика. Считается, что бета-тестирование прошло успешно, если клиент принял программное обеспечение.
Как правило, бета-тестирование проводится непосредственно конечными пользователями. Это тестирование является последним перед выпуском приложения для коммерческого использования. В большинстве случаев бета-версия программного обеспечения используется ограниченным числом пользователей и в конкретной области.
Выходит, что конечный пользователь использует программное обеспечение, составляет отчет об ошибках и отправляет его компании. И затем, прежде чем выпустить программное обеспечение в общемировых масштабах, компания должна решить эти проблемы.
в) Эксплуатационное приёмочное тестирование (OAT - Operational acceptance testing)
Эксплуатационное приёмочное тестирование системы выполняется либо группой эксплуатации, либо системными администраторами в среде промышленной эксплуатации. Цель такого тестирования – убедиться в том, что системные администраторы в состоянии обеспечить корректную работу системы для пользователей в реальных условиях.
OAT сосредоточено на следующих моментах:
тестирование резервного копирования и восстановления;
установка, удаление и обновление программного обеспечения;
процесс восстановления в случае катастрофы природного характера;
пользовательское управление;
сопровождение программного обеспечения.
Нефункциональное тестирование
Существует четыре основных вида нефункционального тестирования.
#1) Тестирование безопасности
Тестирование безопасности проводится специальной командой. Любые несанкционированные действия хакеров могут преодолеть защиту системы.
Тестирование безопасности необходимо для проверки программного обеспечения, приложения или веб-сайта на предмет хорошей защиты от внутренних и/или внешних угроз. Это тестирование включает в себя проверку того, насколько программное обеспечение защищено от различного рода вредоносных программ, вирусов, а также насколько безопасны и надежны процессы авторизации и аутентификации.
Помимо всего прочего, тестирование безопасности позволяет узнать, как программное обеспечение ведет себя при различных хакерских атаках и при внедрении вредоносных программ, а также как обеспечивается безопасность данных после такой хакерской атаки.
а) Тестирование на возможность проникновения в систему
Тестирование на возможность проникновения в систему – это разновидность тестирования безопасности. Оно проводится путем санкционированной кибератаки на систему. Его цель – выявить слабые места системы с точки зрения безопасности.
Тестирование выполняется привлеченными третьими лицами (исполнителями), которые также известны как «белые хакеры». Соответственно, данный вид тестирования еще можно назвать «этичным взломом». Исполнители выполняют различные операции, такие как SQL-инъекции, подтасовки URL-адресов, повышение привилегий, завершение сеанса, после чего предоставляют организации отчет.
Примечание: Никогда не проводите тестирование на возможность проникновения в систему на своем ноутбуке/компьютере. Для проведения тестирования на возможность проникновения в систему у вас обязательно должно быть письменное согласие.
#2) Тестирование рабочих характеристик
Тестирование рабочих характеристик – это проверка стабильности приложения и времени отклика системы при прикладывании нагрузки.
«Стабильность» - это способность приложения выдерживать ту или иную нагрузку. «Время отклика» - то, как быстро пользователи могут начать пользоваться приложением. Тестирование рабочих характеристик проводится с помощью специальных инструментов, например, Loader.IO, JMeter, LoadRunner и т.д.
а) Нагрузочное тестирование
Нагрузочное тестирование – это проверка стабильности приложения и времени отклика системы при прикладывании нагрузки, эквивалентной тому, что приложение будут использовать такое количество пользователей, которое было предусмотрено или меньшее.
Например, ваше приложение может обслуживать 100 пользователей одновременно с временем отклика 3 секунды. Тогда мы можем провести нагрузочное тестирование с применением нагрузки, эквивалентной 100 и менее пользователям. Целью такого тестирования является гарантия того, что приложение отвечает всем пользователям в течение 3 секунд.
б) Стресс-тестирование
Стресс-тестирование – это проверка стабильности приложения и времени отклика системы при прикладывании нагрузки, эквивалентной тому, что приложение будут использовать количество пользователей, превышающее предусмотренное.
Например, ваше приложение может обслуживать 1000 пользователей одновременно с временем отклика 4 секунды. Тогда мы можем провести стресс-тестирование с применением нагрузки, эквивалентной более чем 1000 пользователям. Протестируйте приложения, приложив нагрузку в 1100, 1200, 1300 пользователей, и посмотрите на время отклика. Цель данного тестирования заключается в проверке стабильности приложения при стрессовой нагрузке.
в) Тестирование масштабируемости
Тестирование масштабируемости – это проверка стабильности приложения и времени отклика системы при прикладывании нагрузки, эквивалентной тому, что приложение будут использовать количество пользователей, превышающее предусмотренное.
Например, ваше приложение может обслуживать 1000 пользователей одновременно с временем отклика 2 секунды. Тогда мы можем провести тестирование масштабируемости с применением нагрузки, эквивалентной более чем 1000 пользователям. Постепенно увеличивая нагрузку, можно выяснить, когда приложение даст сбой.
Допустим время отклика для моего приложения для различной нагрузки следующее:
1000 пользователей – 2 секунды
1400 пользователей – 2 секунды
4000 пользователей – 3 секунды
5000 пользователей – 45 секунд
5150 пользователей – сбой – Именно этот момент мы определяем при проведении тестирования масштабируемости
г) Объемное тестирование (тестирование большим количеством запросов)
Объемное тестирование - это проверка стабильности приложения и времени отклика системы с помощью отправки большого количества данных в базу данных. Фактически, с помощью этого тестирования можно проверить способность базы данных обрабатывать данные.
д) Тестирование износостойкости (продолжительное тестирование)
Тестирование износостойкости - это проверка стабильности приложения и времени отклика системы при непрерывном прикладывании нагрузки в течение длительного периода времени. Цель этого тестирования – убедиться, что приложение работает хорошо.
Например, аналогичные тесты проводят автомобильные компании с целью убедиться, что водитель сможет управлять автомобилем в течение нескольких часов без остановок, и это не повлечет никаких проблем.
#3) Тестирование практичности
Тестирование практичности – это тестирование приложения с позиции пользователя. Его цель – определить впечатления и ощущения от использования приложения, а также проверить, удобно ли взаимодействовать пользователю с приложением.
Например, есть какое-то мобильное приложение для торговли на бирже. Тестировщик проводит тестирование практичности для данного приложения. Он может проверить самые различные сценарии, например, удобно ли пользоваться мобильным приложением, используя лишь одну руку или нет, удобно ли, что полоса прокрутки вертикальная, не отталкивает ли тот факт, что цвет фона черный, а цены и названия акций отображаются красным или зеленым цветом.
Основная идея тестирования практичности таких приложений состоит в том, чтобы, когда пользователь открывал приложение, он видел все, что необходимо.
а) Исследовательское тестирование
Исследовательское тестирование – это обычное тестирование, которое проводит команда тестировщиков. Цель этого тестирования – анализ приложения и поиск неисправностей. Для того, чтобы проводить такие тестирования, тестировщикам нужны знания предметной области. Для руководства исследовательским тестированием используются концепции тестирования.
б) Кросс-браузерное тестирование
Кросс-браузерное тестирование – это тестирование приложения в различных браузерах, на разных операционных системах и мобильных устройствах с целью оценить впечатление и ощущение от использования приложения и его производительность.
Для чего нужно кросс-браузерное тестирование? Ответ прост: разные пользователи используют разные операционные системы, разные браузеры и разные мобильные устройства. Целью любой компании является обеспечить приятное впечатление от использования приложения независимо от того, на каком устройстве оно установлено.
Такой инструмент, как Browser Stack, позволяет протестировать приложение на всех версиях различных браузеров и всех мобильных устройствах. В ознакомительных целях можно воспользоваться бесплатной пробной версией Browser Stack (она предоставляется на несколько дней).
в) Тестирование доступности использования
Цель тестирования доступности использования – определить, могут ли люди с ограниченными возможностями использовать программное обеспечение или приложение.
Здесь под понятием «ограниченные возможности» понимается следующее: нарушение слуха, неспособность различать цвета (дальтонизм), умственные недостатки, слепота, пожилой возраст и другие инвалидные группы. Данный вид тестирования подразумевает проверку размера шрифта (подходит ли он для слабовидящих), проверку цвета и контрастности картинки (для людей с нарушением восприятия цвета) и т.д.
#4) Тестирование совместимости
Когда проводится тестирование совместимости, проверяется то, как программное обеспечение ведет себя и как оно работает в другой среде, на других веб-серверах, на другом оборудовании и в другой сетевой среде.
Тестирование совместимости гарантирует, что программное обеспечение может работать в различных конфигурациях, с разными базами данных, в разных браузерах и их версиях. Тестирование совместимости должна проводить группа тестировщиков.
Другие виды тестирования
Свободное тестирование
Название само по себе подразумевает, что данное тестирование выполняется бессистемно, то есть без какого-либо набора тестовых данных, а также без какого-либо плана или документации.
Цель свободного тестирования – выявить изъяны и «сломать» приложение путем выполнения любых действий в приложении.
Свободное тестирование – это способ поиска неисправностей без каких-либо формальностей. Это тестирование может провести любой участник проекта. Конечно, непросто выявить какие-то ошибки без тестовых данных, но иногда ошибки, которые были обнаружены с помощью свободного тестирования, могли быть не найдены с помощью существующий тестовых наборов.
Backend-тестирование
Каждый раз, когда данные вводятся в клиентской части приложения, они сохраняются в базе данных, и ее тестирование так и называется – тестирование базы данных, или backend-тестирование.
Существует много разных баз данных, таких как SQL Server, MySQL, Oracle и т.д. Тестирование базы данных подразумевает тестирование структуры таблиц, схемы, хранимой процедуры, структуры данных и т.д. При backend-тестировании тестировщики не используют графический интерфейс, они подключаются к базе данных напрямую с надлежащим доступом. Тем самым они могут с легкостью проверять данные с помощью всего нескольких запросов к базе.
В процессе backend-тестирования могут быть выявлены такие проблемы, как потеря данных, зависание программы, повреждение данных и т.д. Все эти проблемы обязательно должны быть устранены до того, как система будет запущена в производство.
Тестирование совместимости браузера
Это разновидность тестирования совместимости (которое описано ниже). Тестирование совместимости браузера проводится командой тестировщиков.
Тестирование совместимости браузера необходимо для веб-приложений. Оно гарантирует, что программное обеспечение сможет работать с любыми браузерами и операционными системами. С помощью этого тестирования также можно проверить, будет ли работать приложение во всех версиях различных браузеров.
Тестирование обратной совместимости
Тестирование обратной совместимости позволяет убедиться, что недавно разработанное или обновленное программное обеспечение будет хорошо работать в старой версии среды.
Тестирование обратной совместимости позволяет проверить, правильно ли работает новая версия программного обеспечения с файлами, которые были созданы более старой его версией. К проверяемым файлам относятся таблицы данных, файлы данных и структуры данных, которые были созданы более старой версией программного обеспечения. Если программное обеспечение было обновлено, то оно должно хорошо работать со своими предыдущими версиями.
Тестирование методом «черного ящика»
При таком тестировании внутренняя структура системы не учитывается. Все тесты основываются только на требованиях и функциональных характеристиках.
Тестирование граничных значений
Это тестирование проверяет, как ведет себя приложение на пограничном уровне.
Тестирование граничных значений необходимо для того, чтобы выявить изъяны на граничных значениях. Оно используется для тестирования различных диапазонов чисел. Для каждого такого диапазона есть верхняя и нижняя границы, и тестирование проводится именно на этих граничных значениях.
Если тестовый диапазон от 1 до 500, то тестирование граничных значений выполняется для значений 0, 1, 2, 499, 500 и 501.
Тестирование ветвей
Тестирование ветвей также известно, как «покрытие ветвей» или «покрытие альтернатив». Это разновидность тестирования методом «белого ящика» – одно из модульных тестирований. Он необходим для того, чтобы каждый возможный путь от точки принятия решений выполнился хотя бы один раз для 100% тестового покрытия.
Пример:
Read number A, B
If (A>B) then
Print(“A is greater”)
Else
Print(“B is greater”)
Здесь есть две ветки – if и else. Для 100% покрытия нам нужно провести 2 теста с разными значениями А и В.
Тест №1: А=10, В=5. Этот тест охватит ветвь if.
Тест№2: А=7, В=15. Этот тест охватит ветвь else.
Сравнительное тестирование
Сравнительное тестирование – это сравнение сильных и слабых сторон продукта с его предыдущими версиями или другими подобными продуктами.
Эквивалентное разбиение
Это разновидность тестирования методом «черного ящика». Для проведения этого тестирования выбирается набор групп и несколько значений или чисел. При этом вполне понятно, что все значения из этой группы генерируют один и тот же результат.
Цель данного тестирования – исключение тестовых наборов данных из определенных групп, которые генерируют один и тот же результат, но при этом не выявляют никаких неисправностей.
Допустим, что приложение принимает значения от -10 до +10. Затем для эквивалентного разбиения выбираются значения: ноль, одно положительное значение и одно отрицательное значение. И таким образом, эквивалентное разбиение для данного теста будет таким: от -10 до -1, 0 и от 1 до 10.
Типовое тестирование
Типовое тестирование – это тестирование в реальных условиях. Оно подразумевает использование реальных сценариев и сценариев, основанных на опыте тестировщиков.
Такой вид тестирования также известен, как «тестирование на основе опыта», поскольку здесь требуются определенный опыт тестироващика, например, он должен знать о том, как приложение работало раньше, как можно «сломать» приложение и какие ошибки могут быть в приложении такого типа.
Тестирование графического пользовательского интерфейса (GUI - Graphical User Interface)
Цель тестирования GUI – убедиться, что графический интерфейс соответствует всем бизнес-требованиям. Графический интерфейс приложения, который хочет видеть заказчик, описан в рабочей документации и изображен на макете.
Тестирование GUI включает в себя следующее: проверка размера кнопок и полей ввода, размещенных на экране, выравнивание текста, таблиц и содержимого в таблицах.
С помощью данного тестирования также можно проверить меню приложения. Меню необходимо проверять для того, чтобы убедиться, что при выборе меню или подменю страница не съезжает, а при наведении курсора мыши на меню или подменю выравнивание не исчезает.
Тестирование поэлементной компоновки
Тестирование поэлементной компоновки – это тестирование с восходящим подходом, то есть это непрерывное тестирование приложения с добавлением новых функций.
При этом функции и модули должны быть достаточно независимы, чтобы их можно было тестировать и отдельно друг от друга. Это тестирование проводят либо программисты, либо тестировщики.
Тестирование настройки/удаления приложения
Тестирование настройки приложения выполняется для того, чтобы убедиться, что приложение может быть установлено и настроено и работает так, как должно. Это тестирование – это этап тестирования, который предшествует первому взаимодействию пользователей с реальным приложением. Тестирование настройки приложения еще называют «предэксплуатационным тестированием».
Тестирование удаления приложения выполняется для того, чтобы убедиться, что после удаления все компоненты программного обеспечения будут удалены из системы.
Данные виды тестирования выполняются для полных, частичных или обновленных процессов настройки/удаления приложения в разных операционных системах и в разных аппаратных или программных средах.
Мутационное тестирование
Мутационное тестирование – это разновидность тестирования методом «белого ящика», при котором меняется исходный код программы, а затем проверяется, способны ли существующие тестовые примеры выявить ошибки в системе.
Изменения в исходном коде не столь значительны, поэтому они не влияют на все приложение, только на его отдельную часть, и тестовые примеры должны уметь выявлять эти ошибки в системе.
Негативное тестирование
Установка тестировщика очень проста: «Необходимо сломать систему/приложение». Это можно сделать с помощью негативного тестирования.
Методика негативного тестирования заключается в том, что тестировщик вводит неверные или недопустимые данные и проверяет, выдает ли система ошибку неверного ввода.
Загрузка любой страницы или системы не должна занимать много времени и должна поддерживаться даже при пиковой нагрузке. Для этого тестирования используются различные средства оценки производительности и нагрузки.
Тестирование восстановления
Это разновидность тестирования, которое проводят для того, чтобы проверить, как хорошо приложение или система восстанавливаются после сбоев или аварий.
Тестирование восстановления определяет, способна ли будет система продолжить свою работу после аварийной ситуации. Допустим, что приложение получает данные через сетевой кабель, и вдруг этот сетевой кабель был отключен.
Через какое-то время сетевой кабель подключают обратно; система должна снова начать получать данные оттуда, откуда получала ранее до потери связи.
Регрессионное тестирование
Регрессионное тестирование – это тестирование неизменяемых функций приложения. Оно необходимо для того, чтобы убедиться, что любые правки, добавление любых новых функций, удаление или обновление уже существующих функций не повлияет на работу приложения.
Важная часть регрессионного тестирования - определение границ регрессии. Для того, чтобы выделить эти границы регрессии, тестировщик должен определить границы приложения, в которых произошли те или иные изменения, и то, как эти изменения повлияли на приложение.
Тестирование на базе рисков
При данном виде тестирования тестируются функциональные характеристики или требования, исходя из их приоритета. Тестирование на базе рисков включает в себя тестирование критически важных функциональных характеристик, от которых в большей степени зависит коммерческая деятельность и вероятность сбоя которых достаточно велика.
Решения о приоритете основываются на потребностях компании-заказчика. Как только приоритет будет установлен для всех функций, начинается тестирование функций сначала с высоким приоритетом, затем – со средний, а после – с низким.
Функции с низким приоритетом могут и не тестироваться вовсе (все зависит от времени, которым располагает тестировщик). Тестирование на базе рисков проводится тогда, когда на тестирование всего программного обеспечения не так много времени, но при этом его необходимо выпустить вовремя.
Этот подход должен быть утвержден клиентом и высшим руководством организации.
Статическое тестирование
Статическое тестирование – это разновидность тестирования, которое не требует выполнения кода. Критический просмотр, пошаговый разбор и инспектирование – вот методы проведения статического тестирования. Статическое тестирование должны пройти такие вещи, как просмотр рабочей документации, спецификации требований заказчика, архитектура высокого и низкого уровня, синтаксис кода, стандарты присвоения имен переменным и т.д.
Статическое тестирование также применяется к тестовым примерам, планам и сценариям. Оно проводится для того, чтобы предотвратить появление ошибки, а не выявлять ее на более позднем этапе. Именно поэтому статическое тестирование оправдывает затраты на него.
Например, тестировщик тестирует веб-сайт для страхования домашних животных. Логика расчета стоимости услуг описана в документации. В рамках статического тестирования тестировщик может просмотреть код разработчика, который предназначен для расчета стоимости, и сравнить его с документацией, чтобы предотвратить ошибку в расчете.
Тестирование чувствительности к воздействие внешних факторов
Тестирование чувствительности к воздействию внешних факторов – это тестирование, которые подразумевает выявление слабых мест в программном обеспечении, оборудовании и сети. С помощью вредоносны программ хакер может получить контроль над системой, если она уязвима для такого рода атак, вирусов и «червей».
Перед выпуском приложения, необходимо убедиться, что оно прошло это тестирование, поскольку оно может обнаружить опасные для системы бреши в безопасности.
Заключение
Все вышеупомянутые разновидности тестирования программного обеспечения – лишь часть всего процесса тестирования.
Все-таки есть еще более 100 видов тестирований, но они используются не для всех типов проектов. Здесь мы рассмотрели самые распространенные виды тестирования программного обеспечения; именно их в основном используют в процессе тестирования.
Помимо всего прочего, существуют альтернативные понятия и процессы, которые используются в различных организациях, но основная идея везде одинакова. Все эти виды тестирования, процессы и методы их реализации постоянно меняются по мере того, как меняется проект, требования и область.
Полиалфавитный шифр – это криптосистема, в которой используется несколько моноалфавитных шифров. Поэтому нам необходимо иметь как минимум 2 таблицы и шифрование текста происходит следующим образом. Первый символ шифруется с помощью первой таблицы, второй символ – с помощью второй таблицы и так далее.
Сильные стороны полиалфавитных шифров заключается в том, что атака по маске и атака частотным криптоанализом здесь не работает, потому что в таких шифрах две разные буквы могут быть зашифрованы одним и тем же символом.
Моноалфавитные шифры были популярны вплоть до конца 16 века, так как практически все научились их вскрывать. Необходимо было что-то менять и поэтому в 1585 году был создан шифр Виженера. С этого началась новая эпоха в истории криптографии, которая называется период полиалфавитных шифров, хотя попытки создать подобные криптосистемы были и раньше за пол века до этого, но ничего серьёзного из этого не получилось.
Шифр Гронсфельда
Данный шифр представляет собой модификацию шифра Цезаря и по своей структуре похож на шифр Виженера.
Принцип работы. Берём к примеру текст «РАБОТА» и ключ, например - «136». Ключ в данном случае не одно число, а набор цифр, для понимания можно представить в виде «1,3,6» и не важно какой длины. Далее каждой букве исходного текста присваиваем по 1 цифре ключа, например «Р(1) А(3) Б(6) О(1) Т(3) А(6)» и каждому символу исходного текста прибавляем значение ключа по методу Цезаря. Получается зашифрованный текст «СГЖПХЁ».
При расшифровании проделываем ту же логику, как при расшифровании по методу Цезаря.
Шифр Виженера
Шифр Виженера является самым популярным полиалфавитным шифров за всю историю.
Для начала создаётся квадрат Виженера.
Ключом в данном методе может быть любой длины и состоять из любых символов, которые есть в таблице 3. Например возьмём ключ «ШИНА» и исходный текст «РАБОТА».
Проделываем то же самое, что и при шифре Гронсфельда, к каждой букве исходного текста записываем исходную букву ключа – «Р(Ш) А(И) Б(Н) О(А) Т(Ш) А(И)». Согласно таблице 3 по диагонали находим букву исходного текста, а по вертикали находим букву ключа, их пересечение является зашифрованной буквой, таким образом проделываем для всех букв и шифруем текст, получается «СЙППКЙ».
Чтобы расшифровать нам нужно точно так же под каждой буквой закрытого текста записываем букву ключа - «С(Ш) Й(И) П(Н) П(А) К(Ш) Й(И)». По вертикали находим букву ключа и по этой строке находим зашифрованную букву, пересечение с буквой по горизонтальной строки – буква исходного текста, расшифровывает и получаем исходный текст.
Атака методом индекса совпадений
В данном случае рассмотрим криптоанализ шифра Виженера, его так же можно применять и к шифру Гронсфельда. Нижеприведённый метод криптоанализа называется методом индекса совпадений.
Атака методом индекса совпадений состоит из 2 шагов:
Определяет длину ключевого слова
Дешифрование текста
Рассмотрим каждый из этапов:
1. Для того, чтобы найти длину ключа воспользуемся методом индекса совпадений.
ИС = 0,0553
Индекс совпадений – это константа, вероятность того, что две наугад выбранные буквы в нормальном осмысленном произвольном русском тексте будут одинаковые.То есть вероятность, что две наугад выбранные буквы будут одинаковые, равна 5,53%.
При атаке на шифротекст необходимо ориентироваться именно на эту вероятность.
Если имеет шифротекст, зная о нём только то, что он зашифрован шифром Виженера, определяем длину ключа.
В шифре Виженера ключом выступает любая последовательность цифр, начиная с 2, потому что если была бы 1 буква, то это просто шифр Цезаря.
Итак, начиная с минимума, предполагаем, что длина ключа составляет 2 символа и проверяем это. Выбираем из шифротекста каждую вторую букву, начиная с первой и выписываем отдельно полученную строку. Предполагаемую длину ключа обозначаем k=2, а количество символов в этой строке за L. Далее из алфавита берём каждую букву и считаем для неё индекс совпадений, то есть берём определённую букву и подсчитываем сколько раз она встретилась в этой строке шифротекста (это число обозначаем – n), и так для всех букв. Далее высчитываем индекс совпадений по формуле
ИС = n(n-1)/L(L-1)
Далее высчитываем индекс совпадений для всего текста путем сложения всех индексов совпадений для всех букв отдельно. Получаем определённое значение и сравниваем его со значением константы. Если индекс совпадений очень близко к константе или больше, то это означает, что подобрана верная длина ключа. Если значение индекса намного отличается от константы, то значит подобранная длина ключа неверная и необходимо взять длину ключа 3 и выбирать из шифротекста каждую третью букву, начиная с первой и выполнять те же действия. Если индекс снова намного отличается от константы берем следующие значения ключа и выполняет те же действия, до тех пор, пока индекс совпадений будет очень близок к константе.
2. Вычислив длину ключевого слова возвращаемся к шифротексту.
Разбиваем текст на количество символов символов в ключе, например, при длине ключа k=3, делим текст на 3 части. В первую часть будет входить каждая третья буква, начиная с первой, во вторую часть – каждая третья буква, начиная со второй, и третья часть – каждая третья буква, начиная с третьей. После этого выписываем отдельно каждую часть. Отдельная часть представляет собой обычный шифр Цезаря. Далее дешифруем каждую часть методом частотного криптоанализа. Находим самую частую букву каждой части шифротекста, сравниваем её с буквой «О», так как она в русском алфавите самая частая и сравниваем шифрованную букву с буквой «О». Вычисляем разницу позиций между ними – в ответе получим число, равное ключу и дешифруем с помощью него по шифру Цезаря первую часть шифротекста. Такие же действия проделываем и для остальных частей, затем восстанавливаем части дешифрованного шифротекста и получаем исходный текст.
Автокорреляционный метод
Данный метод проще в реализации, чем метод индекса совпадений, но последовательность действий точно такая:
Определение ключа
Дешифрование текста
Имея шифротекст, необходимо посчитать количество букв в нём. Желательно весь шифротекст записать в одну строку, затем сделать копию и разместить под ней же.
Как и в случае с методом индекса совпадением предполагаем для начала минимальную длину ключа, то есть k=2. Затем в копии строки шифротекста убираем первые два символа и дописываем их в конец строки. Далее ищем количество совпадающих букв между этими двумя строками и находим долю количества совпадений от общего количества символов в тексте по формуле:
Y = n/L
Y - Доля количества совпадений
n – количество совпадений
L – количество символов в шифротексте
Полученное значение сравниваем со значением контанты индекса совпадений, так же – если это значение намного отличается, предполагаем длину ключа k=3 и делаем ту же процедуру до тех пор, пока доля количества совпадений будет близка к константе индекса совпадений.
После нахождения длины ключа проделываем то же самое, что и в методе индекса совпадений и дешифруем текст.
Шифр Тритемиуса
Шифр Тритемиуса позиционируется усиленным шифром Цезаря и описывается формулой:
C = (m+s(p))modN
C - номер зашифрованного символа в алфавите
m - номер символа открытого текста в алфавите
n - количество символов в алфавите
s(p) - это ключ, который представляет собой математическую функцию, например: s(p) = 2p+const
p - порядковый номер символа в исходном тексте
const - любое число, которое задаётся в ручную
Точно так же, как в шифре Цезаря каждый символ, перед тем, как шифровать, будет переводится в число, согласно определённой таблице.
Первое, что нужно сделать – пронумеровать все символы в исходном тексте, то есть каждый символ получается свой номер в зависимости от своей позиции в тексте. Шифрование происходит посимвольно.
Расшифрование происходит похожим способом и описывается формулой:
C = (m-s(p))modN
Шифр для своего времени очень неплох, потому что не смотря на свою простоту, то есть самая сложная часть – это выбрать функцию s(p). Он демонстрирует достаточно высокий криптоустойчивости, то есть не уступает ни шифру Виженера, ни шифру Гросфельда.
Книжный шифр
Книжный шифр – не является популярным шифром среди старых шифров, но при грамотном подходе к использованию, обеспечивает криптостойкость на порядки выше, чем шифр Виженера и Гронсфельда. Это симметричный шифр, в котором в качестве ключа используется любая книга на выбор, и процесс шифрования происходит посимвольно.
Выбираем первый символ исходного текста и находим его в нашей книге (с любого места). И в качестве зашифрованного символа используем комбинацию из 3 цифр (номер страницы, номер строки, номер символа в строке) и проделываем тоже самое с остальными символами исходного текста. При этом для повышения безопасности при повторении символа в исходном тексте выбирать для него другую комбинацию в книге, чтобы зашифрованные комбинации не повторялись.
Чтобы получатель смог расшифровать полученное сообщение должен обладать точно такой же книгой. Поочередно смотрит комбинацию и находит её в данной книге и расшифровывает полученное сообщение.
Недостаток этого шифра – это непрактичность и трудоёмкость при шифровании и расшифровании.
Данная статья будет посвящена продуктам унифицированных коммуникаций, разработанных компанией Cisco Systems. Для начала следует сказать, что же такое “унифицированные коммуникации”. Унифицированные коммуникации – это совокупность интегрированных технологий реального времени, таких как: телефония, видеоконференцсвязь (ВКС), обмен мгновенных сообщений (чат) и прочих технологий, представленных на базе единой программной или аппаратной платформы и направленных на повышение эффективности бизнес процессов компании.
Унифицированные технологии, разработанные компанией Cisco, представлены линейкой продуктов Business Edition. В зависимости от числа пользователей функционал данных продуктов может различаться. Существует три версии Business Edition: 3000, 6000 и 7000, рассчитанные на предприятия малого и среднего, среднего и крупного бизнеса соответственно.
Так как продукты Business Edition являются так называемыми “бандл” решениями, то есть поставляются в сборке, то в их состав входят (Рассмотрим на примере CMBE 6000):
Сервер Cisco UCS 220 M3 или M4 – аппаратная платформа, на которой, собственно, разворачиваются сервисы Business Edition;
Cisco Unified Communication Manager – Является ядром всех решений BE, представляет собой полноценную IP-PBX на 1000 пользователей и 1200 оконечных устройств, с поддержкой таких сервисов как: устройства аналоговой связи, IP-телефоны, VoIP-шлюзы, приложения обработки медиа данных, видеоконференцсвязь, мультимедийная система совместной работы, контактный центр и прочие.
Стоит отметить, что в отличие от отдельного CUCM, Cisco Unified Communications Manager Business Edition имеет очень удобный интерфейс, поэтому заниматься его управлением может менее подготовленный IT специалист.
Instant Messaging and Presence with the Cisco Jabber – сервер контроля доступности абонента и обмена мгновенных сообщений, на базе клиента Cisco Jabber;
Cisco Unity Connection – сервер унифицированной голосовой почты;
Cisco Unified Contact Center – позволяет развернуть работу контакт-центра для обслуживания голосовых сообщений и запросов через Интернет;
Cisco Unified Provisioning Manager – представляет собой решение на базе вэб-интерфейса для автоматизации управления и администрирования всех приложений системы.
В качестве дополнительных сервисов продукты CMBE позволяют активировать следующие (возможна закупка дополнительных лицензий):
Cisco TelePresence Video Communication Server – сервер видеоконференцсвязи;
Cisco Unified Contact Center Express – позволяет расширить базовый контакт центр до 100 агентов;
Cisco Unified Attendant Console (CUxAC) – сервер управления программными консолями секретаря (три редакции: Business, Department, Enterprise);
Paging – сервер системы оповещений;
Cisco Emergency Responder (CER) – сервер управления и мониторинга вызовов от экстренных служб;
Для большего понимания, типовая схема Cisco Unified Business Edition 6000, представлена на рисунке:
Решения Cisco Business Edition позволяют обеспечить предприятию:
Высококачественную голосовую связь, соединяющую все филиалы и офисы компании;
Повышение мобильности сотрудников, за счёт использования мобильных приложений, таких как Jabber;
Качественную видеоконференцсвязь и взаимодействие с системами Cisco TelePresence
Мгновенный обмен текстовыми сообщениями (Instant Messaging);
Контроль доступности абонентов (Presence), интегрированный с корпоративным календарем
Работу контакт центра, обслуживающего голосовые, видео- и Интернет-обращения
Унифицированную голосовую почту;
Простую систему управления, мониторинга и администрирования, интегрированную с внешними сервисами;
Сервис сбора статистической информации, которая позволяет оперативно проводить траблшутинг неисправностей всех компонентов системы.