언어 / 데이터베이스 / 시스템에 익숙해 져서 새로운 기능 / 구성 / 쿼리 등을 테스트 할 필요가없는 시점이 있습니까? 시스템에서 구현하기 전에 포함 / 시뮬레이션 된 테스트 (특히 데이터를 수정하는 기능 관련)? 아니면 테스트 환경에서 시뮬레이션 으로 새 쿼리를 테스트하는 것이 항상 필수적 입니까?
더 구체적으로 지정하려면 테스트 하는 것이 항상 가장 안전 하다는 것이 분명합니다 . 그러나 위험을 최소화하여 테스트 할 가치가없는시기를 결정하는 방법이 있습니까? 기능을 구현하기 위해 측정 된 위험을 감수하는 것이 언제 또는 전문적인 관행입니까?
또한 모든 것이 백업되었다고 가정하므로 최악의 시나리오에서는 약간의 노력으로 데이터를 복원 할 수 있습니다.
누군가가이를 해결하기 위해 특정 전문가 경험을 인용 할 수 있습니까? 적절한 / 가능한 경우 참조를 포함하십시오.
답변:
나는 내가하는 모든 일이 SQL Server라고 말함으로써 시작하고 싶습니다. 그러나 일반적으로 이것은 시스템에 관계없이 모든 형태의 코드에 적용됩니다.
이것을 조금 분해하여 시작합시다.
시스템이 있으며 일부 또는 전부를 업그레이드하려고합니다. 예를 들어 인스턴스를 SQL Server 2012에서 2014로 업그레이드합니다.이 시점에서 테스트가 필수적입니다. 불행히도 작은 응용 프로그램의 모든 부분을 테스트하는 것은 불가능할 것입니다. 그 시점에서 나는 "작동"테스트라고하는 것을 할 것입니다. 기본 시스템이 작동합니다. 일반적인 작업을 완료하기 시작하십시오. 모든 옵션을 테스트하지 말고 주 경로 만 테스트하십시오.
SQL Server 업그레이 드를 수행 할 때 약간의 읽기가 필요합니다 . 기본적으로 Backward Compatibility새 버전 의 항목 을 읽으려고합니다 ( 2014 년 버전). 목록에 아무것도 없는지 확인하십시오 (속성 변경, 동작 변경 등).
여기서 우리는 새로운 / 변경되는 응용 프로그램 코드를보고 있습니다 (물론 기존의 모든 것이 이미 테스트 되었기 때문입니까?). 이 경우 모든 것 것이 테스트되어야합니다. 테스트 케이스를 미리 설정하고 최소한 영향을받는 기능을 통해 실행해야합니다. 이 시점에서 다른 사람도 비슷한 검사를 수행해야합니다. 이 코드는 아마도 꽤 오랫동안 사용되어 많은 사람들이 사용하게 될 것입니다. 작동하고 잘 작동하는지 확인하고 싶습니다.
실제로 도움이 될 수있는 것 중 하나 unit tests는 쉽게 반복 할 수 있는 세트를 생성하는 것입니다 . Steve Jones는 tSQLt 를 사용 하여 TSQL 코드를 테스트 할 것을 권장 합니다 (SQL Server 만 해당). 그러나 이렇게하면 고정 된 테스트 세트를 빠르게 실행할 수 있으며 회귀 테스트 (업그레이드를 수행하기 전에 모든 것을 테스트)에 실제로 도움이됩니다.
응용 프로그램 코드 변경 이상으로 새로운 기능과 구성 변경을 철저히 테스트하려고합니다. 예를 들어 columnstore 인덱스 작업을 시작하기로 결정한 경우처음으로 영향을받는 테이블에 닿는 모든 코드를 테스트해야합니다. 생성 한 단위 테스트를 사용하여 애플리케이션을 테스트하십시오. 이러한 기능은 아마도 새로운 기능 일 것이며 (플랫폼에서 새로운 기능 일 수도 있음) 예상치 못한 문제가있을 것입니다. 구성 변경에 관해서는 전체 시스템에 영향을 줄 수있는 것에 대해 이야기하고 있습니다. 경험의 규칙은 테스트하고 신중하게 테스트하는 것입니다. 활성 시스템 (아마도 프로덕션 시스템)에 들어갈 때까지 실제로 볼 수없는 변경 사항이 있지만 테스트 환경에서 먼저 시도하지 않는 것은 변명의 여지가 없습니다.
사용자 데이터에 영향을 미치는 코드가있는 경우 일반적으로 코드를 테스트해야합니다 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당신은 더 많은 응용 프로그램과 쉽고 빠르게 코드를 테스트하는 방법을 볼 수 있습니다. 물론 좋은 테스트 환경과 데이터가 필요하지만 완전히 다른 토론입니다.
나는 당신이 느끼는 것을 알고, 3 년 동안 MySQL을 사용하고 있으며, 모든 경우 항상 모든 테이블 / 데이터베이스 / 슬레이브 복제에 대한 정보를 수정하거나 깰 수 있는 DML 쿼리를 테스트 합니다.
쿼리를 실행하기 전에 항상 테스트하는 것이 가장 안전한 방법입니다.
쿼리가 데이터 정보를 위험에 빠뜨릴 수 있는지 알 방법이 없습니다. 유일한 방법은 데이터베이스 구조 및 구성을 아는 것이므로 하나의 쿼리가 중요한 데이터를 위험에 빠뜨릴 수있는 시점을 쉽게 식별 할 수 있습니다.
에 DELETE, UPDATE, INSERT, 당신은 항상 사용하려고합니다 SELECT당신이 변경 거라고 어떤 정보가 확실하지 않으면 첫 번째. 선택시, 열 데이터 유형과 동일한 조건에 대해 항상 동일한 데이터 유형을 사용하십시오 (일부 경우 EXPLAIN최적화에 사용) .