お疲れ様です。

基本アプリケーションの要件によって異なるのでなんとも言えませんが、ただのデーター移行だけという観点からいくと以下のような形になるかと思います。

A.全件データーのアプリケーションからのOpen/Close確認
　→一番確実だが、時間が掛かる
B.移行済みデーターの件数一致とランダムに抜き取りでアプリケーションからのOpen/Close
　→ランダムで抽出する件数を決める必要があること、また完全なテストではない。
C.最初の正常なデーター、エラーが出そうなデーター（特殊文字や文字コードを変えたもの、またデーターの不整合を起こした状態のデーター）を用意し、それを元に調査

と言ったことが考えられるような気がします。
運用されるDBの情報の重要度合いによっても異なると思いますが、私としては、Cをまず事前にテストしておき、ここで問題がないかを確認ておきます。

DB切り替えの時は、最初にユーザー側にテストランさせる日程を組んだ上で、運用時にしか出ないような問題を確認し、問題がなさそうであれば、切り替えを行いBパターンのテストで最終確認といった形にでしなりを書きますね。
もちろん、何かあった際のリカバリができるよう旧環境を残しておくことと、データーの差分がものでせるようにしておくことも大事です。
RDBにおけるデーター差分はなかなか取りづらいので、新 DBに移行後、トリガーを新DBのテーブルに全て仕込んで、データーログを取るようにしておき、もし旧環境に戻す必要がある場合は、このトリガーで生成されたデーターを元に旧環境とマージすると素早く戻すことができます。
（状況によっては、トリガーでINSERT等のイベント情報を、旧DBに即時反映させることで対応するケースもありますが、リスクもありますので、そこは状況によっての判断になると思います）

システム開発系のプロジェクトは最近やっていないですが、私がやっていた時はこんな感じでしたね。

ご参考まで...。

＞doraemonさん

早速のご回答ありがとうございます。

アプリの動作確認として、大体下記の工程が必要な感じと理解しました。
・疎通確認
・CP準備
・結合テスト計画
・運用テスト計画

いずれの方法についてもですが、アプリ側でDB接続を行っている処理全てを検証する必要はあるのでしょうか？
極端な例ですが、「①登録②照会③変更④削除という4処理があった場合、②照会において全データベースから全フィールドの取得処理確認を行えば、DBとの疎通は担保されるため、DB移行が正常に実施できたと担保できる(※場合によってはランダム抜き取り)。それ以外の処理については前環境のテストにより担保されており、DB疎通が確認できれば問題ない。」という考え方でいけるのかご教示いただけますと幸いです。

宜しくお願いします

にっしー2さん

お疲れ様です。
テストについては、品質を一定に保つために行うものであり、かならずこれをしなければならないといった決まりはありません。
今回のSQLServerで稼動するシステムが業務にどのような影響を与えるかや、移行におけるリスクをあらかじめ把握しているのであれば、そのリスクを回避できるまでのテストを行う必要があると考えます。

そのため、今回のテストにおけるゴールをどこに設定するかが重要ではないかと思います。全てが完璧であることというのであれば全件のデーターを見る必要がシナリオによっては出てくるかもしれません。（それが現実的かどうかは別として）

いただいた通り、特定のデーターが参照できるということは、接続ができているのだから問題ないということをいただいていますが、接続してデーターが閲覧できることがゴールであれば、おっしゃる通りそのテストで良いと思います。
では、データーをエントリーした時に採番テーブルの不具合で、キー重複がおきデーターがエントリーできないケースは起き得ないでしょうか？
SQLServerのバージョンも大きく変わっておりますが、特定の機種依存文字等を入力した際に文字化けがおきたり、１フィールドに対して長いデーターを入れた場合に、そのデーターが正しく開けるかといったケースがこの１つのテストで担保できるかというと難しいような気がします。

移行するDBの仕様や要件により、テストすべき内容が異なりますので、どのテストが必要でどのテストが不要かというとそれは、ケースバイケースであり、今回のDB移行における移行シナリオや仕様、テストに対して与えられた時間と、発生しうるトラブル予測とその影響といったそれぞれの要素を元に判断をする形になると思います。

＞doraemonさん
ご回答ありがとうございます。

＞テストに対して与えられた時間と、発生しうるトラブル予測とその影響といったそれぞれの要素を元に判断をする形になると思います
アプリの重要度や対応期限を鑑み、改めて検証範囲を検討してみようと思います。

お忙しいところありがとう御座いました

新旧のアプリを並行稼動できるのであれば　
・ランダムな範囲で検索・抽出して同じ結果になるか
・全件を打ち出して（今時、紙に出す事はないですが）データの頭とシッポが同じデータか　全件数が一致しているか
位のことはやってみましょう

大昔、ですが　ＤＢを移行させて全件を出したら１件違っていてしらべたら．．．
ＣＳＶファイルで受け渡したがデータ項目に カンマ を含む物があり　そこでデータがズレて、行の末尾が次の行に行ってしまった　というものでした
そもそも入力画面で カンマは入力できない（チェックしている）はずなのに　なぜ？　てしらべたら
　もう一つ前のＤＢ移行の時に手入力した部分があり　そこで間違ってカンマを入れた　”らしい”
ということがわかりました　　うーん１０年も前のミスに泣かされたわけです

＞desatoさん

ご回答ありがとう御座います。

新旧データ比較はできそうなので、実施してみようと思います。
貴重なご経験談もありがとうございました。
参考にさせていただきます

新たな環境などをリリースするときは
”受入テスト”
です。（導入時の単体テストレベル がそれにあたるのでしたらごめんなさい）
下記URL参照
http://www.atmarkit.co.jp/ait/articles/1211/12/news012.html

参照ページ内にも書いてますが、
”どこまでテストするのか”
というのは、開発側が”考える”のではなく
ユーザー側の要求を”くみ取り、摺合せする”ものです。

業務への影響度、ユーザーの要望、データ量、割けられるリソースやコスト、検証者のスキル、開発者（ベンダー）のサポート体制
などなど、様々な要素があり正直他社事例を聞いても参考程度にしかならないでしょう。
あなたの会社のその業務（フルスクラッチアプリ）は他社にはないのですから。

ここで聞くよりも、その時間をユーザーからの要望を把握すること注力したほうが正直効率的かと
少し譲っても、まずは開発者（ベンダー）に聞いた方が実践的です。
シス蔵のナレッジにはなるとは思いますが。。。

情シスの仕事は、他社がどうしてるか　ではなく 自社はどうなっているのか
をとことんまで追求する仕事だと思っています。

自社の要素を集めきったうえで、で他社は？というのは大いに正解だと思います。
そういうステータスでしたら失礼しました。

最近、安易に他社はこうだから！というような提案をする人が多く
他社はどう、じゃなくて まずは自社はどうなってるの？
Ans.そこまで調べてませんでした
というようなやり取りが多発し辟易していたもので、失礼しました。

I like SUSHIさん

幅広い範囲でご回答いただきありがとう御座います。

今回はDB移行に際して実施するアプリ稼動確認をどの程度行うものか、
という質問でした。

簡単に当方の状況をご説明しますと、
・小規模のDB移行
・インフラエンジニアはおり、手は動かせるがお客様のニーズに合わせた工程、納品物作成のノウハウがない
・一連のシス開経験あり、インフラ経験無しの私がお客様との取次ぎ及び、エンジニアの管理を担当することになった
といった背景があり、当該個所における皆様のやり方を参考にさせていただき、お客様の事情を鑑みた上でテストのレベルを決めようと考えておりました。

受入テストの考え方等、大変勉強になりましたので、今後の参考にさせていただきます。
ありがとうございました。

皆様沢山のご回答ありがとうございました。

本件ここで締め切らせていただきます。