По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Файл CSV (Comma Separated Values - значения, разделенные запятыми) использует запятые для разделения различных значений в файле. Файл CSV является стандартным форматом при переносе таблицы в другую систему или ее импорте в другое приложение базы данных.
Это подробное руководство покажет вам, как экспортировать базу данных MySQL в файл CSV и импортировать файл CSV обратно в базу данных MySQL.
Экспорт MySQL в CSV
Нам понадобится:
Доступ к командной строке или окну терминала
Учетная запись пользователя с привилегиями root или sudo
Учетная запись пользователя MySQL с правами root
Предварительно настроенная учетная запись phpMyAdmin (необязательно)
Экспорт MySQL в CSV с phpMyAdmin
Инструмент phpMyAdmin предоставляет бесплатный графический интерфейс для управления базами данных MySQL. Вы можете использовать его для экспорта любой из отслеживаемых баз данных в файл CSV.
Войдите в phpMyAdmin.
Затем нажмите кнопку Databases (Базы данных) в верхней части баннера.
В списке баз данных щелкните ссылку на базу данных, которую вы хотите экспортировать. В этом примере мы выбрали базу данных user.
На следующем экране отображается список таблиц в этой базе данных. Установите флажки для таблиц, которые вы хотите экспортировать.
Нажмите кнопку Export на баннере внизу.
Оставьте метод экспорта установленным как есть. Используйте раскрывающееся меню Format, чтобы выбрать CSV, затем нажмите Go.
Диалоговое окно предлагает указать место, где вы хотите сохранить файл CSV.
Экспорт из MySQL в CSV с помощью командной строки
Вы можете выполнить экспорт без излишеств через CLI, выбрав все данные в таблице и указав место, куда их нужно сохранить.
Начните с открытия оболочки MySQL, затем переключитесь на базу данных, которую вы хотите экспортировать.
Введите следующую команду:
SELECT * FROM myTable
INTO OUTFILE ' mpmyExportFile.csv'
FIELDS ENCLOSED BY '"'
TERMINATED BY ';'
ESCAPED BY '"'
LINES TERMINATED BY '
';
Замените myTable реальным именем таблицы из вашей базы данных. Вы можете заменить mpmyExportFile.csv любым другим именем файла или местоположением. Не забудьте сохранить имя файла .csv в конце.
Примечание. В этом примере используется местоположение файла Linux. Если вы работаете в Windows, вы можете использовать c:/folder/file.csv для вашего местоположения файла.
Дополнительные параметры для экспорта из MySQL
Чтобы указать отдельные наборы данных для экспорта из таблицы:
SELECT column1, column2, column3, column4
FROM myTable
WHERE column2 = 'value';
Замените column1 (и остальные) фактическими именами столбцов, которые вы хотите экспортировать. Обязательно используйте команду FROM, чтобы указать таблицу, из которой вы экспортируете. Оператор WHERE является необязательным и позволяет экспортировать только те строки, которые содержат определенное значение. Замените значение фактическим значением, которое вы хотите экспортировать. Например:
SELECT order_date, order_number, order_status
FROM current_orders
WHERE order_status='pending';
Вы готовы к тому, чтобы узнать больше о различных видах тестирования программного обеспечения?
Как тестировщики, мы знаем о самых разных видах тестирования программного обеспечения. К ним относятся: функциональное тестирование, нефункциональное тестирование, автоматизированное тестирование, гибкое тестирование и их подвиды и другие.
Каждый из нас, изучая процесс тестирования, так или иначе сталкивался в несколькими видами тестирования. Вы могли слышать о некоторых из них или даже могли с ними работать, но маловероятно, что вы знаете обо всех видах тестирования, как и многие другие.
Каждый вид тестирования имеет свои характерные особенности, свои преимущества и недостатки. Тем не менее, в этой статье мы рассмотрели по большей части все виды тестирования программного обеспечения, которые мы используем на регулярной основе.
Давайте взглянем на них!!
Различные виды тестирования программного обеспечения
Ниже представлена общая классификация видов тестирования программного обеспечения.
Мы рассмотрим каждый вид во всех подробностях и приведем примеры.
Функциональное тестирование
Существует четыре основных вида функционального тестирования.
#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 видов тестирований, но они используются не для всех типов проектов. Здесь мы рассмотрели самые распространенные виды тестирования программного обеспечения; именно их в основном используют в процессе тестирования.
Помимо всего прочего, существуют альтернативные понятия и процессы, которые используются в различных организациях, но основная идея везде одинакова. Все эти виды тестирования, процессы и методы их реализации постоянно меняются по мере того, как меняется проект, требования и область.
Что такое парадигмы программирования? Это не более, чем просто замысловатое название для популярных способов и стилей организации процесса написания программного кода.
Я постараюсь разбить эту тему на части и дать простое пояснение по каждой парадигме. Таким образом, вы сможете легко понять, о чем говорят люди, когда произносят такие слова, как «объектно-ориентированный», «функциональный» или «декларативный». Давайте начнем!
Что такое парадигма программирования?
Парадигмы программирования – это различные способы и стили, которые используются для организации программы или языка программирования. Каждая парадигма состоит из определенных структур, функций и взглядов на то, как следует решать известные задачи программирования.
Вопрос о том, почему существует так много различных парадигм программирования, схож с вопросом о том, почему существует так много языков программирования. Определенные парадигмы лучше подходят для определенных типов задач. Именно поэтому имеет смысл использовать разные парадигмы для разных типов проектов.
Кроме того, методики, которые составляют каждую парадигму, развивались с течением времени. Благодаря достижениям как в области программного, так и аппаратного обеспечения появились различные подходы к решению задач, которых раньше просто не было.
И последняя причина – я думаю, это просто творческое начало в человеке. По своей натуре, нам просто нравится создавать новые вещи, улучшать то, что другие когда-то создали, и адаптировать инструменты под себя и свои предпочтения или просто делать их более эффективными (в нашем понимании).
Все это привело к тому, что на сегодняшний день мы имеем огромное количество вариантов, которые могут помочь нам написать и структурировать ту или иную программу.
Чем парадигма программирования не является?
Парадигмы программирования – это не языки и не инструменты. Вы не сможете ничего «создать» с помощью парадигмы. Они больше похожи на некий набор образцов и руководящих принципов, о которых условились большое количество людей, которым они следовали и которые они подробно изложили.
Язык программирования не всегда привязан к определенной парадигме. Есть языки, которые были созданы с учетом определенной парадигмы и имеют функции, которые облегчают программирование в этом контексте больше, чем другие (хороший пример – Haskel и функциональное программирование).
Однако существуют и «многопарадигмальные» языки. Это означает, что вы можете адаптировать свой код, чтобы он подходил под какую-то из парадигм (хороший пример – JavaScript и Python).
При этом парадигмы программирования не являются взаимоисключающими в том смысле, что вы можете без каких-либо проблем использовать приемы из различных парадигм одновременно.
Популярные парадигмы программирования
Теперь, когда вы знаете, что такое парадигмы программирования, а что к ним не относится, давайте рассмотрим самые популярные из них, их характеристики и сравним их.
Имейте в виду, что этот список не полный. Существуют и другие парадигмы программирования, которые мы здесь рассматривать не будем. Здесь я расскажу вам только о самых популярных и широко используемых.
Императивное программирование
Императивное программирование – это набор подробных инструкций, которые даются компьютеру, чтобы тот выполнил их в заданном порядке. Этот тип программирования называется «императивным», потому что мы некоторым образом указываем компьютеру (как программисты), что он должен делать.
Императивное программирование концентрируется на описании того, как программа работает, шаг за шагом.
Допустим, вы хотите испечь торт. Ваша императивная программа для такого рода задачи может выглядеть следующим образом:
1- Pour flour in a bowl
2- Pour a couple eggs in the same bowl
3- Pour some milk in the same bowl
4- Mix the ingredients
5- Pour the mix in a mold
6- Cook for 35 minutes
7- Let chill
Воспользуемся конкретным примером и предположим, что мы хотим отфильтровать массив чисел так, чтобы остались только числа, которые больше 5. Наш императивный код тогда будет выглядеть следующим образом:
const nums = [1,4,3,6,7,8,9,2]
const result = []
for (let i = 0; i < nums.length; i++) {
if (nums[i] > 5) result.push(nums[i])
}
console.log(result) // Output: [ 6, 7, 8, 9 ]
Обратите внимание, что мы указываем программе, что нужно перебрать каждый элемент массива, сравнить каждый из них с 5 и, если элемент больше 5, то поместить его в конечный массив.
Наши инструкции предельно детализированы и конкретны, и именно это и является императивным программированием.
Процедурное программирование
Процедурное программирование – это производное от императивного программирования только с функциями (также известных как «процедуры» или «подпрограммы»).
Процедурное программирования предлагает пользователю разделить выполнение программы на функции, чтобы оптимизировать модульный принцип организации.
Вернемся к нашему примеру с тортом. Процедурная программа для этого примера будет выглядеть следующим образом:
function pourIngredients() {
- Pour flour in a bowl
- Pour a couple eggs in the same bowl
- Pour some milk in the same bowl
}
function mixAndTransferToMold() {
- Mix the ingredients
- Pour the mix in a mold
}
function cookAndLetChill() {
- Cook for 35 minutes
- Let chill
}
pourIngredients()
mixAndTransferToMold()
cookAndLetChill()
Как вы можете видеть, благодаря реализации функций, мы можем просто прочитать три вызова функций в конце файла и понять, что делает наша программа.
Такое упрощение и абстрактное представление является одним из преимуществ процедурного программирования. Однако внутри функций находится все тот же императивный код.
Функциональное программирование
Функциональное программирование продвигает концепцию создания функций немного дальше.
В функциональном программировании функции рассматриваются как «полноправные граждане». Это означает, что их можно присваивать переменным, передавать в качестве аргумента и возвращать в качестве результата других функций.
Еще одна ключевая концепция – это идея чистых функций. Чистая функций – это функция, которая, чтобы получить результат, полагается только на свои входные данные. И при одних и тех же входных данных всегда будет один и тот же результат. Кроме того, эти функции не имеют никаких побочных эффектов (то есть не вносят никаких изменений вне контекста функции).
С учетом всех этих концепций, функциональное программирование призывает писать программы с помощью функций. Оно также поддерживает идею о том, что модульность кода и отсутствие побочных эффектов облегчают определение и разделение обязанностей внутри кодовой базы. Таким образом, это облегчает сопровождение кода.
Вернемся к примеру с фильтрацией массива. В императивной парадигме мы можем использовать внешнюю переменную для хранения результата функции, что по сути может считаться побочным эффектом.
const nums = [1,4,3,6,7,8,9,2]
const result = [] // External variable
for (let i = 0; i < nums.length; i++) {
if (nums[i] > 5) result.push(nums[i])
}
console.log(result) // Output: [ 6, 7, 8, 9 ]
Для того, чтобы преобразовать это в функциональное программирование, мы можем сделать следующее:
const nums = [1,4,3,6,7,8,9,2]
function filterNums() {
const result = [] // Internal variable
for (let i = 0; i < nums.length; i++) {
if (nums[i] > 5) result.push(nums[i])
}
return result
}
console.log(filterNums()) // Output: [ 6, 7, 8, 9 ]
Это практически тот же самый код, но мы проворачиваем все итерации внутри функции, в которой мы также сохраняем и массив результатов. Таким образом, мы можем гарантировать, что функция не будет ничего менять за своими пределами. Она создает переменную только для обработки своей собственной информации, и после завершения своей работы удаляет ее.
Декларативное программирование
Декларативное программирование скрывает всю сложность и приближает языки программирования к человеческому языку и мышлению. Это абсолютная противоположность императивному программированию, хотя бы потому что программист дает инструкции не о том, как компьютеру следует решать задачу, а о том, какой требуется результат.
Будет намного понятнее, если мы приведем пример. Воспользуемся примером с фильтрацией массива. Декларативный подход здесь будет выглядеть следующим образом:
const nums = [1,4,3,6,7,8,9,2]
console.log(nums.filter(num => num > 5)) // Output: [ 6, 7, 8, 9 ]
Обратите внимание, что, используя функцию фильтрации filter, мы явно не указываем компьютеру перебирать массив или сохранять значения в отдельном массиве. Мы просто говорим о том, что мы хотим («filter») и условие, которое необходимо выполнить («num > 5»).
Что хорошего в таком подходе? Его легче читать и понимать, и зачастую он более емкий в записи. Хорошими примерами декларативного кода являются функции filter, map, reduce и sort в JavaScript.
Еще один хороший пример – современные фреймворки/библиотеки JS, такие как React. Посмотрите, например, на этот код:
<button onClick={() => console.log('You clicked me!')}>Click me</button>
Здесь у нас есть кнопка (button) с приемником событий, который запускает функцию console.log при нажатии кнопки.
Синтаксис JSX (то, что использует React) совмещает HTML и JS. Это упрощает и ускоряет написание приложений. Но это не то, что браузеры читают и выполняют. Код React позже преобразуются в обычный HTML и JS, а вот это уже то, с чем работают браузеры.
JSX является декларативным, поскольку его цель заключается в том, чтобы предоставить разработчикам более удобный и эффективный интерфейс для работы.
Здесь также важно отметить, что в декларативном программировании компьютер все равно обрабатывает информацию как императивный код.
Если снова вернуться к примеру с массивом, то компьютер по-прежнему выполняет итерацию по массиву, как в цикле for, но нам, как программистам, не нужно писать это напрямую. Декларативное программирование скрывает всю сложность от программиста.
Объектно-ориентированное программирование
Одной из самых популярных парадигм программирование является объектно-ориентированное программирование (ООП).
Основная концепция ООП заключается в разделении понятий на сущности, которые описываются как некие объекты. Каждая сущность группирует заданный набор информации (свойств) и действий (методов), которые может выполнять эта сущность.
ООП широко использует классы. Классы - это способ создания новых объектов с помощью макета или шаблона, который задает программист. Объекты, которые были созданы с помощью класса, называются экземплярами.
Вернемся к примеру с приготовлением пищи на псевдокоде. Предположим, что в нашей пекарне у нас есть главный повар (по имени Фрэнк) и помощник повара (по имени Энтони). У каждого их них есть определенные обязанности. Если бы мы использовали ООП, то наша программа бы выглядеть следующим образом:
// Create the two classes corresponding to each entity
class Cook {
constructor constructor (name) {
this.name = name
}
mixAndBake() {
- Mix the ingredients
- Pour the mix in a mold
- Cook for 35 minutes
}
}
class AssistantCook {
constructor (name) {
this.name = name
}
pourIngredients() {
- Pour flour in a bowl
- Pour a couple eggs in the same bowl
- Pour some milk in the same bowl
}
chillTheCake() {
- Let chill
}
}
// Instantiate an object from each class
const Frank = new Cook('Frank')
const Anthony = new AssistantCook('Anthony')
// Call the corresponding methods from each instance
Anthony.pourIngredients()
Frank.mixAndBake()
Anthony.chillTheCake()
Преимущество ООП заключается в том, что оно облегчает понимание программы за счет четкого разделения задач и обязанностей.
Итоги
Как мы увидели, парадигмы программирования – это различные способы решения задач программирования и организации нашего кода.
Одними из самых популярных и широко используемых на сегодняшний день парадигм являются императивная, процедурная, функциональная, декларативная и объектно-ориентированная. Знание о том, что они из себя представляют, полезно для общего развития, а также для лучшего понимания других тем, связанных с программированием.