言語/データベース/システムに精通して、新しい機能/構成/クエリ/などをテストする必要がない時点がありますか。システムに実装する前に、特にデータを変更する機能に関して、封じ込め/シミュレートされたテストによって？または、テスト環境でシミュレーションによって新しいクエリをテストすることは常に不可欠ですか？
さらに指定するには、テストするのが常に最も安全であることは明らかです。ただし、リスクが非常に少ないためにテストに労力をかける価値がない場合を判断する方法はありますか？それを言い換える別の方法：機能を実装するために測定されたリスクを取ることはいつ、またはいつまで専門的に行われていますか？
また、すべてがバックアップされていると仮定しましょう。したがって、最悪の場合のシナリオでは、ある程度の労力でデータを復元できます。
誰かがこれに対処するために特定の専門家の経験を引用できますか？適切/可能な場合は参照を含めてください。
回答:
私がすることはすべてSQL Serverであると言うことから始めたいので、それらは私が与える例です。ただし、一般に、これはシステムに関係なく、あらゆる形式のコードに適用されます。
これを少し分解することから始めましょう。
システムがあり、その一部またはすべてをアップグレードしようとしています。たとえば、インスタンスをSQL Server 2012から2014にアップグレードします。この時点でテストが不可欠です。残念ながら、小さなアプリケーションのすべての部分をテストすることはおそらく不可能です。その時点で、「作業」テストと呼ばれることを行います。基本システムは機能していますか。一般的なタスクを最初から最後まで実行します。すべてのオプションをテストするのではなく、メインパスのみをテストしてください。
SQL Serverのアップグレードを行う際には、いくつかの必読事項もあります。基本的Backward Compatibilityに、新しいバージョンのエントリ（ここでは2014のエントリ）を読み、リストに何も含まれていないこと（重大な変更、動作の変更など）を確認します。
ここでは、新しい/変更中のアプリケーションコードを調べています（もちろん、既存のものは既にテスト済みですから？）。この場合、すべてをテストする必要があります。テストケースを事前にセットアップし、影響を受ける機能の少なくとも大部分を実行する必要があります。この時点で、他の人に同様のチェックを行わせることをお勧めします。このコードは、おそらくかなり長い間、適切な場所に配置され、多くの人々によって使用されます。あなたはそれがうまく機能していることを確認したい。
これに本当に役立つことができるものの1つは、unit tests簡単に再現可能なセットを生成することです。 Steve Jonesは、tSQLtを使用してTSQLコードをテストすることをお勧めします（SQL Serverのみが心配です）。しかし、これを行うことにより、固定された一連のテストをすばやく実行でき、リグレッションテスト（アップグレードを行う前など、すべてをテストする）に非常に役立ちます。
アプリケーションコードの変更だけでなく、新しい機能や構成の変更を徹底的にテストする必要があります。たとえば、列ストアインデックスの使用を開始する場合初めて、影響を受けるテーブルに触れるすべてのコードをテストする必要があります。生成した単体テストを使用して、アプリケーションをテストします。これらの機能はおそらく新しいもので（おそらくプラットフォームでは新しいものです）、おそらく予期しないいくつかの落とし穴があります。構成の変更に関しては、おそらくシステム全体に影響を与える可能性のある何かについて話しています。経験則は、テストし、慎重にテストすることです。アクティブなシステム（おそらく実稼働システムのみ）に入るまで実際には表示されない変更がいくつかありますが、それは最初にテスト環境でそれらを試さないことの言い訳ではありません。
ユーザーデータに影響するコードがある場合は、一般的にテストする必要がありますAd Hoc。異なるパラメーターを使用して同じコードを何度も繰り返し実行している場合は、毎回テストする必要はないでしょう。
たとえば、四半期ごとにAdListテーブルから1つ以上の広告を削除する必要があります。
DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')その時点で、すでにコードをテストしており（固定文字列を変更しているだけです）、おそらくコードを実行するだけでかなり安全です（万が一に備えて適切なバックアップがあると仮定します）。
一つの簡単なテストする方法DELETE、UPDATEまたはINSERTあなたが期待する行の数と種類が返されていることを確認した後、SELECTにそれらを変更し、それらを実行することです。
SELECTs をテストする必要がないと思うかもしれません。実際にはデータを変更しないからです。しかし、あなたは正しい理由でコードを実行していますか？あなたがマネージャーのために調査を行っているとしましょう。マネージャーは、このデータをマネージャーなどに渡します。間違ったデータを取得していないことを確認するためにテストします（または他の人がデータを収集するのをブロックします）。
これは、おそらく「すべてをテストする」ルールの1つの例外です。システムデータに対して情報クエリを実行しています。ここで重要なことは、期待するデータを取り戻すことです。クエリが単純なもの（システムビューのクエリ）である場合は、ビュー/列の実際の意味を確認している限り、おそらく大丈夫です。クエリが複雑な場合（たとえば、返された列の計算で3つまたは4つのシステムビューを押す）、期待するデータが返されることを確認するために、いくつかのテストを実行することができます。
要約すると、はい、すべてをテストする必要があります。作成して実行することが重要である場合は、テストすることが重要です。ただし、すべてのコード行のすべてのブランチをテストするのに膨大な時間を費やす必要があるわけではありません。ただし、ある程度のテストを行う必要があります。
自動化された単体テストはあなたの友人です。出現によりDevOpsとContinuous Integration、あなたはより多くのアプリケーションを迅速かつ簡単にあなたのコードをテストする方法が表示されます。もちろん、それには適切なテスト環境とデータが必要ですが、それはまったく異なる議論です。
私はあなたが何を感じているか知っています。MySQLで3年間働いています。私の場合は、すべてのテーブル/データベース/スレーブレプリケーションの情報を変更または破壊できるDMLクエリを常にテストしています。
クエリを実行する前にテストするのが常に最も安全な方法です。
クエリがデータ情報を危険にさらす可能性があるかどうかを知る方法はありません。唯一の方法は、データベースの構造と構成を知ることです。そのため、1つのクエリが機密データを危険にさらす可能性があるかどうかを簡単に識別できます。
でDELETE、UPDATE、INSERT、あなたは常に使用するようにしてくださいSELECT、あなたが変更しようとしていることをどのような情報がわからない場合は最初に。選択では、列データ型と同じデータ型を条件に常に使用するようにしてくださいEXPLAIN。場合によっては最適化に使用します。