Всегда ли не проверять функцию?

Есть ли какой-нибудь момент, когда вы так хорошо знакомы с вашим языком /базой данных /системой, что нет необходимости , чтобы протестировать новую функцию /конфигурацию /запрос /и т. д. с помощью встроенного /смоделированного тестирования перед его внедрением в вашу систему (особенно в отношении функции, которая изменяет данные)? Или он всегда необходим для тестирования нового запроса путем моделирования в тестовой среде ?

Чтобы уточнить, ясно, что он всегда безопасный для тестирования. Однако есть ли способ определить, когда риск настолько минимален, что тестирование не стоит усилий? Другой способ выражения: когда или когда-либо профессиональная практика измеряет риск для реализации функции?

Кроме того, предположим, что все резервное копирование, так что в худшем случае данные могли бы с некоторым усилием восстановить.

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

12 голосов | спросил ZX9 24 J0000006Europe/Moscow 2015, 17:33:42

2 ответа


9

Я хочу начать с того, что все, что я делаю, это SQL Server, так что это те примеры, которые я даю. В общем случае это относится к любой форме кода независимо от системы.

Начнем с того, что немного сломаем это.

Обновление

У вас есть система и собираетесь обновить некоторые или все из них. Например, обновление экземпляра с SQL Server 2012 до 2014 года. На данный момент тестирование имеет важное значение. К сожалению, тестирование каждой части даже небольшого приложения, вероятно, не будет возможным. В этот момент я буду делать то, что я бы назвал «рабочим» тестом. Работает ли базовая система. Выполнение общих задач начинается. Не проверяйте каждую опцию, просто основной путь.

При выполнении обновления SQL Server существует также обязательное чтение . В основном вы хотите прочитать запись Backward Compatibility для новой версии ( вот 2014 год ) и убедитесь, что у вас ничего нет в любом из списков (нарушение изменений, изменение поведения и т. д.), .

Код приложения

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

Одна из вещей, которая действительно может помочь в этом, - создать набор unit tests, который легко воспроизводится. Стив Джонс рекомендует , используя tSQLt для тестирования вашего TSQL-кода (только для SQL Server). Но, выполняя это, вы можете быстро запустить определенный набор тестов, и это действительно поможет в регрессионном тестировании (тестирование всего, скажем, перед обновлением).

Особенности /Конфигурации

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

Специальные запросы, которые ссылаются /влияют на пользовательские данные

Когда у вас есть код, который влияет на ваши пользовательские данные, вам обычно нужно протестировать его, даже, и, возможно, особенно, потому что это Ad Hoc. Теперь, когда говорят, что если вы используете один и тот же фрагмент кода снова и снова, просто с разными параметрами, вам, вероятно, не нужно каждый раз беспокоиться о тестировании.

Например, каждый квартал нужно удалять одно или несколько объявлений из таблицы AdList.

DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')

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

Один простой способ проверить DELETE,UPDATE или INSERT это изменить их на SELECT и запустите их, а затем подтвердите, что количество и тип ожидаемых строк будут возвращены.

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

Специальные запросы, которые ссылаются /влияют на системные данные

Это, возможно, единственное исключение из правила «проверить все». Вы выполняете информационные запросы по системным данным. Здесь важно вернуть данные, которые вы ожидаете. Если запрос является чем-то простым (запрос системного вида), то вы, вероятно, хорошо, пока вы проверили, что действительно означает представление /столбцы. Если запрос является сложным (например, ударяя 3 или 4 системных представления с расчетами по возвращенным столбцам), вы можете запустить несколько тестов, чтобы убедиться, что вы вернете ожидаемые данные.

Резюме

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

Автоматическое тестирование модулей - ваш друг здесь. С появлением DevOps и Continuous Integration вы будет видеть все больше и больше приложений и методов быстрого и легкого тестирования вашего кода. Конечно, для этого требуется наличие хорошей тестовой среды и данных, чтобы идти вместе с ней, но это совершенно другое обсуждение.

ответил Kenneth Fisher 21 MarpmMon, 21 Mar 2016 20:08:08 +03002016-03-21T20:08:08+03:0008 2016, 20:08:08
4

Я знаю, что вы чувствуете, у меня есть 3 года работы с MySQL, и в моем случае я всегда проверяю DML запросы, которые могут изменять или прерывать любую информацию по каждой таблице /базы данных /Slave-репликации.

Это всегда самый безопасный способ проверить ваш запрос перед его запуском.

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

Вкл. DELETE, UPDATE, INSERT, вы всегда должны использовать SELECT сначала, если вы не уверены, какую информацию вы собираетесь изменить. При выборе, всегда старайтесь использовать тот же тип данных для условий, что и тип данных столбца, в некоторых случаях используйте EXPLAIN для оптимизации.

ответил oNare 24 J0000006Europe/Moscow 2015, 17:51:50

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132