Тестирование баз данных включает в себя тестирование методом «чёрного ящика», «белого ящика» и набор требований Слово «принципы» может звучать скорее как «почему», чем как «как». Поверьте мне, это две важные практические концепции. Свойства ACID Атомарность (Atomicity) Согласованность (Consistency) Изолированность (Isolation) Устойчивость / долговечность (Durability) Целостность данных Свойства ACID расшифровываются как «атомарность», «согласованность», «изоляция» и «устойчивость». Каждая транзакция при тестировании баз данных должна соответствовать этим принципам. Транзакция — это группа задач. Даже простая реальная транзакция, например банковский перевод, о котором я говорил ранее, будет включать несколько задач более низкого порядка. Свойства ACID призваны подтвердить, что каждая транзакция завершена точно, полно и целостно. Атомарность (A, Atomicity) подразумевает, что каждая транзакция рассматривается как атомарная единица. Это означает, что каждая транзакция должна быть завершена полностью, иначе она потерпит неудачу. Такое отношение к каждой транзакции позволяет избежать неприятной ситуации, когда денежный перевод завершается наполовину. Звучит тревожно, правда? При атомарности, если транзакция завершается наполовину, когда что-то идёт не так — вся транзакция терпит неудачу. Деньги возвращаются. И никакого стресса. Согласованность (C, Consistency) подразумевает, что база данных остаётся согласованной после транзакции. Ни одна транзакция не может негативно повлиять на другие данные в базе. Если вы положите деньги на свой банковский счет, они не будут сняты с чужого счета. Изолированность (I, Isolation) предотвращает пересечение потоков. Она гарантирует, что в случае одновременного проведения нескольких транзакций каждая из них будет рассматриваться так, как будто это единственная транзакция в базе данных. Ничья информация с чужой не смешивается. Устойчивость (D, Durability) подразумевает, что база данных достаточно устойчива, чтобы сохранить все последние транзакции, даже если произойдет сбой в системе. Опять же, есть практические причины требовать от базы данных такой устойчивости. Например, если вы сделаете денежный перевод, а через десять минут база данных выйдет из строя, как вы узнаете, что нужно сделать перевод ещё раз? Наличие таких строгих требований предотвращает путаницу со стороны конечных пользователей. Практика целостности данных направлена на проверку того, что все последние данные обновляются повсеместно. Существует четыре отдельные части, которые в совокупности подтверждают целостность данных. Для достижения высокого уровня целостности данных тестировщик должен убедиться в том, что данные: поддаются проверке можно восстановить являются точными являются полными Если данные не отвечают этим четырём требованиям, то они, скорее всего, не соответствуют стандарту целостности данных. В этом могут помочь инструменты управления данными, но в конечном итоге высокое качество данных должны обеспечить именно вы. Как отметил Хью Прайс в эпизоде The QA Lead Podcast под названием Your Data Quality Sucks, обеспечение работы систем на высококачественных и безопасных данных становится всё более важным, поскольку всё больше компаний создают собственные банки данных. Язык Oracle Data Integrator Тестирование таблиц базы данных Тестирование таблиц выполняет несколько проверок структуры отображения данных. Проверяется совместимость полей на фронтенде и бэкенде. Проверяется длина полей базы данных. Также проверяется, нет ли в базе данных несопоставленных таблиц или столбцов, к которым необходимо обратиться. Проверки сервера базы данных Проверка сервера позволяет убедиться, что конфигурация сервера соответствует требованиям. Она также гарантирует, что все, кто пытается получить доступ к определённым областям сервера базы данных, имеют соответствующую авторизацию. Это важный шаг в обеспечении безопасности базы данных для её пользователей. Наконец, проверка сервера позволяет убедиться в том, что он способен обрабатывать максимальное количество транзакций одновременно. Например, при проверке сервера для банковского приложения необходимо убедиться, что сервер может обрабатывать финансовые операции определённого количества пользователей и что все пользователи могут получить доступ только к своей собственной информации. Мы вернём веселье в функциональное тестирование. Обещаю. Функциональное тестирование — это проверка того, что база данных соответствует спецификациям клиента и что действия конечного пользователя не расходятся с этими требованиями. Это означает, что придётся много притворяться конечным пользователем. Разве это не звучит забавно? Мне кажется, вполне. Тестирование «чёрного ящика» (Black Box) Тестирование «чёрного ящика» — это такая стратегия тестирования ПО, при которой внутренняя структура тестируемой системы тестировщику неизвестна. Не имея таких глубоких знаний, тестировщик будет подходить к нему с теми же ожиданиями, что и конечный пользователь. Тестирование «чёрного ящика» проводится во время тестирования баз данных, поскольку позволяет найти баги в популярных сценариях, с которыми, скорее всего, столкнётся конечный пользователь. Это максимальное тестирование в роли конечного пользователя. Тестирование «белого ящика» (White Box) Это полная противоположность тестированию «чёрного ящика». При тестировании «белого ящика» тестировщик полностью понимает внутреннюю структуру тестируемого программного обеспечения. Он подходит к тестированию как инспектор. Тестирование «белого ящика» иногда называют тестированием «прозрачного ящика», поскольку тестировщик наблюдает за взаимодействием между модулями. В этом случае он не так сильно озабочен пользовательским опытом. Модульное (юнит) тестирование Модульное тестирование — это техника, которая включает в себя тестирование отдельных модулей или компонентов приложения в изоляции от остальной части системы. Этот вид тестирования предназначен для проверки отдельных объектов базы данных, таких как таблицы, представления, хранимые процедуры и функции. Тестируя эти объекты в изоляции, разработчики могут убедиться, что каждый объект функционирует так, как задумано. Модульные тесты для баз данных обычно включают в себя написание автоматизированных тестов, которые выполняют определённые SQL-команды для объекта или модуля базы данных и проверяют, что возвращаются ожидаемые результаты. Например, модульный тест для хранимой процедуры может включать передачу процедуре набора входных параметров и проверку правильности выходных данных. Используя модульные тесты таким образом, разработчики могут убедиться, что каждый объект базы данных работает так, как ожидается, и что любые изменения в схеме базы данных или коде приложения не приведут к непредвиденным последствиям или ошибкам. При нефункциональном тестировании конечный пользователь не имеет ни малейшего значения. Не то чтобы конечный пользователь был не важен, просто у этих тестов другие заботы. Нефункциональные тесты проверяют производительность базы данных под нагрузкой и стрессом, а также ищут возможности для оптимизации производительности. Нагрузочное тестирование Нагрузочное тестирование базы данных — это разновидность тестирования производительности. Его проводят с целью проверить, не окажет ли пользовательская нагрузка резко негативного влияния на производительность базы данных. Тестировщик выполняет множество запросов на нагрузку и запускает их снова и снова, чтобы имитировать активную пользовательскую базу. Стресс-тестирование Стресс-тесты — это более интенсивные тесты, которые не только проверяют производительность базы данных, но и ищут места, где она может сломаться. Что гораздо более разрушительно. И весело. Вы когда-нибудь ждали с нетерпением выхода новой видеоигры или смартфона? Если да, то вам наверняка знакомо ощущение, когда вы загружаете сайт или открываете приложение, чтобы совершить покупку, и сталкиваетесь с необычно длинной загрузкой, неожиданными кодами ошибок и сбоями в обработке информации. Это и есть база данных в стрессовой ситуации. Стресс-тестирование отличается от нагрузочного тестирования тем, что подвергает базу данных внезапному, неожиданно высокому объему трафика. Весьма популярным в последние годы стало автоматизированное тестирование БД. Ручное тестирование базы данных заняло бы слишком много времени, потребовало бы слишком много людей и просто стоило бы слишком много денег. Существует множество способов автоматизации тестирования. В этой статье представлены некоторые инструменты управления базами данных, которые предлагают функции тестирования. > Записаться 17 апреля: «Как составить баг-репорт, чтобы коллеги сказали вам “спасибо”» > Записаться
Принципы тестирования баз данных
Что такое свойства ACID?
Принципы ACID
Целостность данных
Язык управления базами данных
Функциональное тестирование
Нефункциональное тестирование
Автоматизированное тестирование баз данных
Тестирование базы данных с помощью API
ссылка на оригинал статьи https://habr.com/ru/articles/804851/
Добавить комментарий